This time I’m taking a look at Jinja, a template engine for Python. I’m going to use it with YAML to write SaltSatck state files. I already have a minion and master setup but in case want to learn how to set them up by yourself, you can check out my earlier post. If you’re eager to learn more about Jinja, you should pay a visit to the Jinja site: http://jinja.pocoo.org/

In this task I used two laptops, my HP EliteBook 2570p and an older HP Pavilion DV6 with a Linux live USB stick, both running Xubuntu 16.04.3. I’m using both machines in my local network.

This post is part of a server management course I’m attending, taught by Tero Karvinen.

Using Jinja to edit the content of a single file

Here my goal was to use Jinja in a state file so, that it would alter the contents of a single file on a minion machine. I decided to create a simple text file in my minion machine, that I could edit with the master. I used nano tekstitesti.txt to create a text file in the user Xubuntu’s home folder and wrote a simple phrase inside:

After this, I switched to the master. Here I used Tero Karvinen’s instructions on Jinja to attain some inspiration and wrote the following init.sls state file:

I also added a text.txt file to the same folder on the master with a small difference compared to the file on the minion:

Here, the state file would take a look at the file on the master and rename the {{ world }} part with everybody, after which it would overwrite the file on the minion with the new file on the master. And indeed it worked just as intended when I applied the state with sudo salt ‘testi’ state.apply text:

Here we can see the lines that are changed.

For-in loops in Jinja – Creating multiple text files

My next task was to create multiple files to a folder on the minion machine with a state file containing Jinja. I started by creating a folder called multi with the command sudo mkdir /srv/salt and created two files inside; a state file and a text file. For the state file, I used Tero Karvinen’s code:

{% for file in [‘foo.txt’, ‘bar.txt’, ‘kala.txt’] %}

/tmp/moikat/{{ file }}:
file.managed:
– source: salt://multi/moikka.txt
– makedirs: True
– template: jinja
– context:
file: {{ file }}
{% endfor %}

I changed a few things accommodate my situation:

With sudo salt ‘testi’ state.apply I applied the newly created state and it executed perfectly:

I of course checked things out on the minion and the folder and the files had been created according to instructions:

Changing the SSH port with Jinja

The most challenging task here was to change the port used by SSH with a state file containing Jinja. I started with a manual installation on the minion so I could be sure that SSH works as intended. A simple sudo apt-get install openssh-server command installed SSH and ssh xubuntu@localhost connected well enough (Note: I changed the user Xubuntu’s password earlier since SSH requires a password for access and the user on a live USB doesn’t come with one on default). I already knew that SSH uses port 22 on default, so I decided to change the port to 8888. This was accomplished by editing the config file with the command sudoedit /etc/ssh/sshd_config. Here I changed the port 22 to 8888 and restarted the SSH process with sudo systemctl restart ssh.service. After this I tried using SSH locally as I did before, but was rejected. The command ssh -p 8888 xubuntu@localhost yielded the results I wanted and I concluded that the manual changing of the port was completed. I deleted the SSH installation with sudo apt-get purge openssh-server. It was time to move on to the master and start with the state file.

I created a folder called sshport in /srv/salt and wrote the following init.sls:

In a nutshell the state performs three tasks: it sees if the openssh-server is installed on the minion and installs it if it isn’t, it overwrites the default SSH config file on the minion with the one on the master by changing the port statement on the file AND if the default config file gets changed (as it does), it restarts the SSH process. This enables the usage of SSH from the port 8888 on the minion.

Now I needed to copy the SSH config file that I had on the master (in its default state). So I transferred it to the sshport folder as defined on the new state file and edited the port part a bit:

Basically I used the same method as I did with the first task so that using Jinja the state file could change the port number. Now all that remained was to apply the state. I used sudo salt ‘testi’ state.apply sshport:

All parts were executed successfully! To test the results, I switched back to the minion and tried to connect with ssh xubuntu@localhost. This however did not work, so I tried with ssh -p 8888 xubuntu@localhost and connecting was successful. With this I concluded that the state file did everything I wanted.

Using a state made by someone else

This was a lighter look at using states. All I needed to do was to take a look at a state file made by another student. After a bit of browsing, I decided to implement the state file made by Johannes Laatu (styling Joona Leppälahti). This changes the wallpaper on the minion machine. Simple but actually a really nice feature!

I created a folder called background to the Salt state folder and added an image file and a init.sls to it. I used the code that Johannes had used:

The state uses the default Xubuntu wallpaper path and replaces the wallpaper file with the one in the source path. By applying this state with sudo salt ‘testi’ state.apply background I got positive results:

The picture on my master replaced the one on the minion by default. However, I sadly couldn’t verify the completion since I learned that for the change to actually happen you’d need to restart the minion machine, but since I was running Xubuntu from a live USB I couldn’t restart it because all changes I had done would’ve been erased. Oh well, I’ll be sure to test this out when I gain access to two machines with more permanent OS installations!