Be smarter than I am and finish your project early. Doing it at 03:30 the night before isn’t a good idea.
I am testing my hardware by stuffing the RAM (16GB) full of VMs (antiX), or until I have to leave for class, whichever happens first. Each machine is allocated 1 CPU core and 512 MB RAM.
Specs: Host OS: Windows 10 Motherboard: MSI X470 Gaming Plus CPU: AMD Ryzen 7 2700X, stock GPU: Nvidia GeForce RTX 2080 Ti RAM: 16 GB DDR4 3200 MHz
Like the screenshots show, I don’t dare go for more VMs active at once. I had all 20 up, albeit briefly. My PC crashed after running the test.ping, hence the caution with just 12 now. Perhaps I spent too much time trying to find the lightest possible distro that could run SaltStack…
I should retry the test with an SSD, seeing how my HDD joined in the howling when I booted two VMs at once, let alone all twenty. That was a bad idea, the whole system was unresponsive several minutes. “Why not close the web browser?” one might ask. The answer is simple – I’m not giving up Netflix.
Running a typical (fresh) Xubuntu master-minion and minion setup, I started with the guide’s sls files. Instead of redesignating the top file location in the master config, I let them go into the default /srv/salt because I was lazy. I created the top, extras and lamp sls files and ran sudo salt ‘*’ state.highstate and got the following end result after the process was complete:
Since I am not at all familiar with LAMP, I don’t know if this was the desired result. I’m sure my teacher will comment on this sooner or later.
We need to run the command prompt as administrator to properly have control and access.
b) Adjust/use salt without the master-slave architecture. Open a command prompt with admin privileges and type in salt-call –local <command> to use salt directly on the Windows slave. For example, we can run grains for system information:
Using this command structure, you can run anything locally.
c) Change a Windows application’s settings with Salt. Instead of changing anything major, I will be keeping a backup of a game save that I can reapply with one command. The game autosave-overwrites periodically, and restoring a previous save can be used to exploit the game via multiplayer, ie. item duplication.
I transferred the desired file to my salt-master directory on Linux and created an sls file for it. Upon running the state, the save file gets restored.
a) I did some light reading on scripts and decided to go for something simple, something I’ve seen before. I created my script file (minion_script.sh) and wrote the basic commands we know by heart by now.
Upon running the script, it runs the commands within, sequentially. The idea is to have the script install salt minion and open the correct file to edit in the master’s address, so that I can eventually have a live USB that runs the script without any further input after hitting “try linux without installing”.
c) I know very little about Vagrant, so I will have to read up on it and experiment.
sudo apt-get install vagrant seems to do the job. The process is much longer than any other package I have installed so far. I had a few errors trying to create my new machine (error while connecting to libvirt… & The machine with the name…), so I tried sudo apt-get install vagrant-libvirt which didn’t fix them. I see something about SSH keys, so the issue runs deeper.
It appears that I forgot to download the VM file, so… sudo vagrant box add ubuntu/trusty64 should take care of it.
[5 minutes later] It did not fix the error.
I spent a long time googling for this error and other linked issues, but unfortunately I could not find a solution before almost punching my screen. At this state of mind, I do not think it’s productive to continue.
System info Host OS: Windows 10 Home, 1803 Motherboard: X470 MSI Gaming Plus CPU: AMD Ryzen 7 2700X GPU: Nvidia GeForce RTX 2080 Ti RAM: 16 GB 3200 MHz Storage: 1×250 GB SSD, 1x 1 TB HDD Optical drive: No PSU: 650W
Salt master: Ubuntu Server 18.04 LTS Salt minion #1: Xubuntu 18.04 LTS Salt minion #2: Host Windows, inactive
The goal today is to play with package-file-servers. More specifically, installing apache and have minions auto-test if it works. However, we need to install SSH to a different port first.
I have completely forgotten how to manually install and test SSH, so I just installed it on the minion slave$ sudo apt-get install ssh and started on automating it via sls files. I already know my VMs can connect to each other (tested with ping every session) so the connectivity check via ssh feels redundant. If something major fails, I will have to go back to it, but I’d like that to be the last resort.
As per the study material by Tero Karvinen (teacher) I followed the steps and created the sshd.sls file (master$ sudoedit /srv/salt/sshd.sls). See image below.
I then edited my sshd_config file (/etc/ssh/sshd_config) and copied it to my salt directory (master$ sudo cp /etc/ssh/sshd_config /srv/salt/) and applied the state (master$ sudo salt ‘slaveboi’ state-apply sshd). The specific minion (Xubuntu) responded positively to 3/3 parts: It had already installed the ssh package and now it downloaded the sshd_config file with the changes I made to it on the master. However, the last part is giving me an error.
I tried to restart the service manually, but it says “Job for ssh.service failed because the control process exited with error code. See “systemctl status ssh.service” and “journalctl -xe” for details.” Using these command bring up the log, which I do not know how to read.
10 minutes later, I realize I had erroneously edited the sshd_config file wrong. I had written “Port: 2222” instead of “Port 2222”. I had copied the wrong version to my salt directory and I tried to fix the original in /etc/ssh, which obviously failed because I had to edit the copied file as well, or make a new copy. I ran the state again and the minion reports 4 successful operations.
I enabled the firewall (sudo ufw enable) and allowed my two test ports through (sudo ufw allow 2222 and sudo ufw allow 6969) on my Xubuntu minion. The ssh connection from the master works via those two ports, when it didn’t before the firewall exceptions (tested).
Part c): I ran the apache2 install command on the minion and verified the home page displays correctly on localhost, except it doesn’t. I am getting a blank screen, but the website title is correct. I assume the HTML page is empty. Upon a furious clicking rage, I discovered that the page does have the elements. I confirmed this by clicking and dragging on the page, which exposed the semi-transparent image/element.
I removed my apache2 installation and all its files (sudo apt-get purge apache2 apache2-utils apache2.2-bin apache2-common) I was instructed to use during another course in the past. I tested if localhost displayed the default index. It did not, as expected. I ran the state via salt and tested again – all works. The salt method is below.
I used Tero’s apache automation page for guidance, link in the source section. I created a file (master$ sudo mkdir /srv/salt/apache followed by sudoedit /srv/salt/apache/init.sls).
I copied the index file from /var/www/html to salt’s new apache directory. I renamed it to default-index.html by using the move command/function to make it work. I added apache to my top.sls file for ease of use. I do not understand the symlink aspect, so I will leave this here for now.
Step d): Create a different package-file-service. I am a complete potato with Linux, so this will be a simple Chromium browser install. I managed to spend too much time here trying to remember the structure, but I still had to go back and look at my older sls files. It’s a simple chromium.sls in the salt service directory.
It took 22 seconds to finish successfully. I confirmed the new browser on my Xubuntu minion. If I had reserved more time for homework (apparently 6-7 hours is not enough) I would have wanted to try setting the startup pages and given some bookmarks. These settings must be stored somewhere.
My hardware: AMD Ryzen 7 2700X (stock clocks), RTX 2080 Ti, 250 GB Samsung EVO 950 (or 750), 1 TB generic HDD, Asus MG279Q 27″ 2560 x 1440 main screen, some old Fujitsu-Siemens 1680 x 1050 TN panel I don’t know the size of. Mouse and keyboard are “gaming” branded, though that will not matter for these assignments and homework.
I started by installing a fresh Xubuntu virtual machine. I already had an Ubuntu server running Pi-Hole, so I though to save time and just use that as my master. Let’s update the machines and install salt:
sudo apt-get install salt-master sudo apt-get install salt-minion The commands are simple, and the process is fast. Check both IP addresses, you want them to be easily accessible:
After googling why the pings didn’t stop (closing the terminal did not stop sending pings to master) I got back to it. Turns out I didn’t specify amount of pings, so it assumed infinite.
Next, the minion needs to know where the master is. We can specify that by doing minion$ sudoedit /etc/salt/minion and adding a few lines.
We need to restart the minion to make it visible to the master. minion$ sudo systemctl restart salt-minion. Let’s accept the minion on the master: master$ sudo salt-key -A. Run the command again to confirm it was accepted.
I mistakenly put the minion’s name as “pihole”. So be it. Running master$ sudo salt ‘*’ cmd.run ‘whoami’ will return its name; root.
I want to try to give the minion some instructions. I need to create the files to make it happen. master$ sudo mkdir -p /srv/salt/hello and master$ sudoedit /srv/salt/hello/hello.sls.
Day 2: The previous method of creating individual folders for the sls files like instructed during class, I am starting over and doing it as they are in the instructions since I ran into a wall trying to do it fancier. This is a direct continuation of the previous, but without the subdirectories.
A top.sls file has to exist. master$ sudoedit /srv/salt/top.sls. We want the following in it: base: ‘*’: – hello Note that this is two spaces, and then four spaces. Tabs will not work.
Let’s actually create the hello.sls file now, no fancy subdirectories: master$ sudoedit /srv/salt/hello.sls. Type the following into it. /tmp/hello.txt: file.managed: – source: salt://hello.txt
We created the hello.sls, so let’s create the text file for it as well: master$ sudoedit /srv/salt/hello.txt. The text in the file is irrelevant, so write whatever you want in it. Let’s apply it: master$ sudo salt ‘*’ state.apply hello.
We can display the minion’s system and hardware information using the command master$ sudo salt ‘*’ grains.items.
I tested a pre-existing sls as well: master$ sudoedit /srv/salt/test.sls where I copied a part of an example from joonaleppalahti’s github: install_test: pkg.installed – pkgs: – ssh I ran the command to test it: master$ sudo salt ‘*’ state.apply test.
I wanted to change my Windows wallpaper via salt, but I ran out of time. I managed to copy the desired image file where I wanted to in windows, but I could not manage to make it the wallpaper.
Installing Samba is easy, like installing most things on Linux. You just have to know the command, which is sudo apt install samba for Samba.
Let’s create a directory so it can share. mkdir /home/username/sambashare. Now that we have a folder, let’s configure Samba to know it has its own folder: sudo nano /etc/samba/smb.conf should start us off. See the image below and add the same lines to the smb.conf file’s end.
The goal is to share files between out Ubuntu and Windows, so let’s set that up next. Restart Samba by typing sudo service smbd restart into your terminal, followed by sudo smbpasswd -a <username> for security purposes.
Let’s try it out! Map a new network drive and enter \\ip-address\sambashare. You’ll get asked for your credentials we just set. That’s it – The last step.