ICT4TN022 - Kurssiraportit

Palvelinten hallinta -kurssin harjoitustöiden yhteysloota. Tarkempi kuvaus kurssista ja sen tehtävistä löytyy täältä.
- Juho Hakala

Pikalinkit:
H1
H2
H3
H4
H5
H6
H7

Harjoitus 1

Takaisin ylös

a) Asenna Salt ja siihen uusi orja.

Käytössä:
- Oracle VirtualBox 6.1.4
- Xubuntu 18.04
- 4096 MB RAM
- 20 GB kiintolevy


Ohje Saltin asennuksiin
Aloitin komennolla "sudo apt-get update", jonka jälkeen latasin Salt-masterin "sudo apt-get install -y salt-master". Palomuuri päälle komennolla "sudo ufw enable" ja siihen kaksi reikää masteria varten "sudo ufw allow 4505/tcp" ja "sudo ufw allow 4506/tcp".
Salt-minion asennetaan samalle koneelle komennolla "sudo apt-get install -y salt-minion", jonka asetustiedostoa muokataan "sudoedit /etc/salt/minion". Tiedoston jokainen rivi on oletuksena kommentoituna, joten tarvittavien rivien kommenttirisuaidat poistetaan. Kaksi riviä kiinnostaa tässä kohtaa: master ja id. Masterin kohdalla kirjataan masterin IP-osoite ja id on yksilöllinen tunniste slavelle. "master: 10.0.2.15" ja "id: pekka". Muutosten jälkeen käynnistetään slave uudelleen komennolla "sudo systemctl restart salt-minion.service". Slave tietää nyt masterin osoitteen ja yhdistäminen pitää vielä masterin puolesta hyväksyä. Komennolla "sudo salt-key -A" master hyväksyy slaven. Vastataan "y" ja seuraavaksi voidaan kokeilla slaven toimintaa esimerkiksi komennolla "sudo salt '*' cmd.run 'whoami'", joka tuottaa seuraavaa:

b) Tee saltille idempotenssi hei maailma (siis tiedostosta, foo.sls)

Seuraamani ohje.
Luodaan masterin ohjeille kansio: "sudo mkdir -p /srv/salt" ja luodaan hei maailmamme: "sudoedit /srv/salt/hello.sls", johon tein seuraavanlaisen ohjeen:



Ensimmäinen rivi kertoo kohde tiedoston sijainnin. "file.managed" on saltin "state", jolla voidaan ladata masterilta tiedostoja slavelle. Kolmas rivi kertoo, mistä tiedosto ladataan. "salt://" viittaa masterin saltin asennussijaintiin eli "/srv/salt". Seuraavaksi luodaan äsken mainittu "hellopekka.txt": "sudoedit /srv/salt/hellopekka.txt":



Komento "sudo salt '*' state.apply hello" suorittaa "hello.sls"-tiedoston ohjeistuksen slaveille ja tämän jälkeen "hellopekka.txt" löytyy nyt sijainnista "/tmp/hellopekka.txt". Lopputulos näyttää seuraavalta:

d) Kerää tietoa koneesta saltin avulla (grains.items)

Komennoilla "sudo salt '*' grains.items" ja "sudo salt '*' grains.items|less" näyttävät paljon erilaista tietoa slavesta, joita voi yksittäin tarkastella esimerkiksi "sudo salt '*' grains.item" -komennolla.

e) Kokeile jotain toista tilaa kuin file.managed.

Ohjeita salt-tiloihin
Muokkaan aiemmin luotua "hello.sls"-tiedostoa. "sudoedit /srv/salt/hello.sls" ja kokeilen seuraavanlaista:



Ja tulos oli:

Lähteet:
http://terokarvinen.com/2018/salt-quickstart-salt-stack-master-and-slave-on-ubuntu-linux
http://terokarvinen.com/2018/salt-states-i-want-my-computers-like-this
http://terokarvinen.com/2020/configuration-managment-systems-palvelinten-hallinta-ict4tn022-spring-2020/
https://docs.saltstack.com/en/latest/ref/states/all/salt.states.file.html

Harjoitus 2

Takaisin ylös

a) Demonin asetukset. Säädä jokin demoni (asenna+tee asetukset+testaa) package-file-service -rakenteella.

Tehtävässä seurasin Tero Karvisen ohjetta.
Alkutilanteessa koneelta löytyy edellisen harjoituksen a-kohdan mukainen Salt master-slave -asennus.
Asennetaan Apache ajamalla komennot "sudo apt-get update" ja "sudo apt-get install -y apache2". Localhost palauttaa Apachen oletussivun, joten asennus on onnistunut. Luodaan apache-kansio salttia varten komennolla "sudo mkdir /srv/salt/apache". Tämän kansion sisään loin ylempänä mainitun ohjeen mukaisen "init.sls"-tiedoston.



Ensimmäinen komento varmistaa, että minionilla on apache asennettuna, toinen komento varmistaa, että minionin "index.html"-tiedosto vastaa masterin omaa tiedostoa, kolmas ja neljäs komento luovat tarvittaessa symlinkit userdir-modin käyttöä varten ja viimeinen komento varmistaa apache2servicen käynnissäolon ja uudelleenkäynnistyksen, jos "userdir.conf" tai "userdir.load" -tiedostot muuttuvat.
Seuraavaksi luon toisessa komennossa mainitun "default-index.html"-tiedoston.



Komennolla "sudo salt '*' state.apply apache" ajetaan äsken luotu käsky kaikille minioneille.



Tulokset näkyvät odotetulla tavalla:

b) Uusi ohjelma. Asenna + tee asetukset + testaa jokin sovellus, jota ei ole käsitelty tunnilla. Asenna ensin käsin, ja käytä sen jälkeen find-komentoa etsiäksesi muuttuneet tiedostot.

Seurasin tässä tehtävässä löytämääni ohjetta.
Päätin ajaa COBOL-ohjelman. Ensin asensin open-cobolin komennolla "sudo apt-get install -y open-cobol". Komennolla "whereis cobc" selvisi mihin se asennettiin:



Aiemman tehtävän ohjeista käyttämälläni find-komennolla sain seuraavanlaisia whereis-komennon osoittamista paikoista:



Seuraavaksi loin uuteen kansioon "hello.cbl"-tiedoston:



Jonka jälkeen suoritin sen seuraavien komentojen avulla: "cobc -free -x -o hello hello.cbl" ja "./hello".

c) Aja jokin tila paikallisesti ilman master-slave arkkitehtuuria. Tutki debug-tulostetta. 'sudo salt-call --local state.apply hellotero --state-output terse'



Tulosteesta käy ilmi tilan suorituksen eri vaiheet:
Name kertoo, mitä tarkastettiin, result kertoo tuloksen, joka kaikissa "Clean" eli oletettavasti ei vaatinut toimenpiteitä, started ilmaisee aloitusajan ja duration toimenpiteen keston. Lopuksi yhteenveto kertoo onnistuneiden toimenpiteiden määräksi 5, joka vastaa suoritettujen komentojen määrää. 2.

Lähteet:
http://terokarvinen.com/2020/configuration-managment-systems-palvelinten-hallinta-ict4tn022-spring-2020/
https://askubuntu.com/questions/287180/how-to-compile-and-run-a-cobol-program

Harjoitus 3

Takaisin ylös

Harjoitus 3

Harjoitus 4

Takaisin ylös

b) Modulikimara. Asenna 6 saltin tilaa/modulia.

Lähdin rakentamaan salt-tilojani ajatuksena luoda työasema uudelle käyttäjälle. Tila luo uuden käyttäjän, asentaa gitin, kloonaa projektin Githubista ja muokkaa config-tietoja sekä asentaa ohjelmointikielen ja editorin.

Sain saltin dokumentaatiota seuraamalla aikaiseksi alla näkyvän tilaläjän, joka siis ensin varmistaa, että tietynlainen käyttäjä on olemassa, git on asennettuna, git-repo on kloonattu, git-configissa on name ja email valmiiksi asetettuna sekä Python-kieli ja Geany-editori ovat asennettuna. Käyttäjän salasanan hash-muoto on tehty "openssl passwd -1"-komennolla.



Kun ajoin tilan, käyttäjän luonti onnistui, gitin asennus onnistui, mutta kloonaus ja config-tietojen asettamiset eivät onnistuneet. Python ja Geany asentuivat ilman ongelmia. Virheilmoitus näytti seuraavanlaiselta.



Tovin pähkäilyn jälkeen katsoin Saltin version kommennolla "salt --version", joka oli 2017.7.4. Saltin dokumentaatiosta kävi ilmi, että "git.cloned"-tila tuli vasta 2018.3.3-versiossa. Niinpä lähdin päivittämään Saltin versiota suoraan saltin ohjeita seuraamalla ja päivitin salt-masterin ja salt-minionin tuoreimpaan versioon (3000). Asennettuani uudet versiot salt-masterista ja salt-minionista, minionin avain piti hyväksyä uudelleen, jonka jälkeen suoritin tilani uudelleen ja se meni läpi ilman virheilmoituksia.





Uudelle Matti-käyttäjälle kirjautuminen onnistuu SSH-yhteydellä, git-repo kloonautui onnistuneesti ja sekä Python että Geany toimivat kuten niiden odotinkin.



Lähteet:
http://terokarvinen.com/2020/configuration-managment-systems-palvelinten-hallinta-ict4tn022-spring-2020/
https://docs.saltstack.com/en/latest/ref/states/all/salt.states.user.html
https://docs.saltstack.com/en/latest/ref/states/all/salt.states.git.html
https://repo.saltstack.com/index.html#ubuntu

Harjoitus 5

Takaisin ylös

a) Hello templates! Tee muotilla esimerkkitiedosto, jossa on muuttujien (esim grains) arvoja.

Loin Salttiin uuden tilan, joka kopioi minionille (sama kone tässä tapauksessa) grains-arvoja näyttävän template-tiedoston. Templatemoottorina toimii Jinja, jonka määrittelin "init.sls"-tiedostoon. "makedirs"-kohta luo halutun "/tmp/grainstemplate"-kansion, mikäli sitä ei jo ole olemassa.



Itse template-tiedosto näyttää personalisoidun viestin grains-arvojen avulla:



Loppullinen tuotos onnistui odotetusti ja näyttää seuraavalta:

b) Message of the Day. Sisäänkirjautuessa näytetään päivän viesti. Lisää päivän viestiin tietoa ympäristöstä käyttäen muotteja. Sopiva tiedosto on /etc/motd.

SSH:lla kirjautuessa Ubuntun oletusnäkymä on seuraavanlainen:



Aloitin luomalla "motd"-tiedoston "/etc"-hakemistoon, joka näytti tältä:



Nyt SSH:lla kirjautuessa luomani tiedoston sisältö tulostuu muun "motd"-viestin mukana.



Loin "/srv/salt"-hakemistoon uuden "motdtemplate"-kansion ja sen sisälle "init.sls"-tiedoston:



Itse "motd"-tiedosto kertoo koneen käyttöjärjestelmän ja sen version:



Ajoin tilan komennolla "sudo salt '*' state.apply motdtemplate" kahteen kertaan, ensimmäisellä kerralla "/etc/motd" päivittyi ja toisella kerralla mitään muutoksia ei tapahtunut. Kokeilin tulosta kirjautumalla SSH:n kautta ja tulos vastasi odotuksiani:

c) Bash. Tee bashiin asetuksia Saltilla. Ensin käsin, vasta toimivaa automatisoidaan. Muista testata lopputulos käyttäjän näkökulmasta.

Käytin tehtävässä apunani HowToGeek-sivustola löytyvää ohjetta.
Käyttäjän bash-asetukset löytyvät kotihakemistosta ".bashrc"-tiedostosta. Bash-asetukset on tallennettu tiedostosta löytyvään PS1-muuttujaan. Seurasin ohjetta ja kokeilin aluksi manuaalisesti bashin muokkaamista tallentamalla oletusasetukset ensin komennolla "DEFAULT=$PS1". Tällöin kykenin koska tahansa palauttamaan asetukset alkuperäiseen tilaan komennolla "PS1=$DEFAULT". Alla kuvattuna kokeilujani:



Lopulta päädyin käyttämään tyyliä "\[\033[1;31m\][\t - \H]\n\u\w\[033[00m\]\$". Alun "\[\033[1;31m\]"-osa määrittelee punaisen värin ja lihavoi sen. Tätä seuraa ensimmäisen rivin tiedot "[\t - \H]\n", jossa "\t" on kellon aika "HH:MM:SS"-muodossa, " - " on pelkkää tyylimuotoilua, "\H" tarkoitaa hostnamea ja "\n" aloittaa uuden rivin. Toiselle riville tulee "\u\w\[033[00m\]\$", jossa "\u" näyttää käyttäjänimen, "\w" näyttää käytössä olevan hakemiston ja "\[033[00m\]\$" määrittelee kaiken lopun ja kirjoitettavat komennot ja tulosteet valkoiseksi.

Loin uuden kansion "/srv/salt/custombash", johon kopioin kotihakemistosta ".bashrc"-tiedoston. Kopioituun tiedostoon kävin muuttamassa PS1-muuttujan sisällön vastaamaan edellisessä kappaleessa selitettyä. "init.sls"-tiedosto näyttää tältä:



Ajettuani tilan, seuraava muutos tapahtui odotetusti:



Odottamani tulos näkyi avatessani uuden terminaali-ikkunan:

d) Nginx. Tee nginx-weppipalvelimeen asetuksia Saltilla.

Aloitin asentamalla Nginx-palvelimen komennolla "sudo apt-get install -y nginx" ja totesin asennuksen onnistuneen:



Tutkin "/etc/nginx"-hakemiston sisältöä ja totesin sen muistuttavan hyvin pitkälti Apachea. "/etc/nginx/sites-available/default"-tiedostosta löysin esimerkin yksittäisen sivun asetustiedostosta. "default"-tiedosto löytää sivulla näytettävän tiedoston "index index.html index.htm index.nginx-debian.html;" rivin avulla. Tästä päättelin, että jos jokin näistä sattuu löytymään, kaikki myöhemmät jätetään huomiotta.

Lähdin luomaan saltilla tilaa, joka asentaisi tarvittaessa Nginx:n, poistaa oletus sivun "/var/www/html"-hakemistosta ja lisää samaan hakemistoon uuden "index.html"-tiedoston.



"index.html"-tiedosto testaa, että ääkköset toimivat:



Ajoin tilan kahteen kertaan ja totesin, että kaikki toimenpiteet suoritetttiin onnistuneesti eikä toiselle kerralla tapahtunut enää mitään.



"localhost"-osoite tarjoaa nyt halutun sivun ja ääkkösetkin toimivat.



Tarkistin vielä, että "/var/www/html"-hakemisto sisältää vain sitä, mitä sen pitääkin.

Lähteet:
http://terokarvinen.com/2020/configuration-managment-systems-palvelinten-hallinta-ict4tn022-spring-2020/
https://www.howtogeek.com/307701/how-to-customize-and-colorize-your-bash-prompt/

Harjoitus 6

Takaisin ylös

a) Asenna jokin toinen Linux-levityspaketti orjaksi Saltille.

Latasin CentOS:in iso-tiedoston ja loin VirtualBoxilla uuden virtuaalikoneen vakioasetuksilla. Loin VirtualBoxilla myös uuden "Host-only network" -adapterin "Host Network Manager" -ikkunassa (aukeaa Ctrl + H).



Ja vaihdoin uuden CentOS vm:n ja olemassaolleen Xubuntu vm:n Network-asetukset alla olevaksi. Näin nämä kaksi virtuaalikonetta kykenevät löytämään toisensa eikä niitä näe kuin niitä hostaava eli minä.



Testasin verkon toimivuuden pingin avulla ja homma pelitti:





Koneet eivät kuitenkaan saaneet yhteyttä internettiin. Tämä korjaantui lisäämällä virtuaalikoneen Netwrok-asetuksiin toinen adapter, jonka asetin NAT-verkoksi. En alkuun tajunnut, että CentOS ei automaattisesti yhdistä verkkoon ja tämä tuotti turhaa vian etsintää. Lopulta kuitenkin sain sen asetettua yhdistämään automaattisesti käynnistyksen yhteydessä graafisen Settings-ohjelman kautta Network-osiossa.



Yhteyksien nyt toimiessa, lähdin asentamaan salt-minionia CentOS:iin. Saltstackin sivulta löysin RedHat/CentOS-osion ja valitsin versioksi 8. Komennoilla "sudo yum install https://repo.saltstack.com/py3/redhat/salt-py3-repo-latest.el8.noarch.rpm" ja "sudo yum install salt-minion" sain asennuksen käyntiin, vastasin kaikkiin kyselyihin kyllä ja lopulta asennus päättyi onnistuneesti. Lähdin muokkaamaan "/etc/salt/minion"-tiedostoa, johon kirjasin masteriksi Xubuntu-koneeni IP-osoitteen ja id-arvoksi "matti". Käynnistin minionin komennolla "sudo systemctl start salt-minion". Xubuntu-koneella ajoin komennon "sudo salt-key status" ja matti-orja näkyi ei-hyväksyttyjen avaimien joukossa. Hyväksyin liittymisen komennolla "sudo salt-key -A" ja testasin, toimiiko yhteys.

b) Kerää grains.items avulla tiedot orjista, joissa on eri levityspaketti.

Komento "sudo salt '*' grains.items" palauttaa ison listan arvoja, joista iso osa on molemmilla koneilla täysin samoja, johtuen virtuaalikoneympäristöstä. Yksittäisiä tietoja vertailun vuoksi:



c) Tee päivän viesti (motd), jossa koneen tyyppi tulee grains osfinger -muuttujasta. Kokeile, että saat eri levityspaketeilla eri tuloksen. Voit hyödyntää aiemmin tekemääsi motd:ia.

Käytin aiemmin tekemääni tilaa, joka luo "/etc/motd"-tiedoston minioneille, joka esittää tietoja kyseisestä koneesta. Tämä viesti näkyy, kun koneelle kirjaudutaan SSH-yhteyden avulla.





Ajoin tilan komennolla "sudo salt '*' state.apply motdtemplate" kahteen kertaan, ensimmäisellä kerralla CentOS loi uuden "/etc/motd"-tiedoston, toisella mitään ei enää tapahtunut. Kokeilin tulosta kirjautumalla SSH-yhteydellä kummallekin koneelle:





Lopputulos näytti miltä odotinkin sen näyttävän.

d) Tee tila, joka tekee RedHat-perheellä (esim. CentOS) tiedoston /tmp/redhat ja Debian-perheellä (esim Ubuntu) tiedoston /tmp/debian. Voit käyttää mitä vain eri perheiden levityspaketteja.

Lähdin luomaan tilaa, joka lukee "grains["os_family"]"-arvon ja käyttää sitä tiedostonimen luomiseen. Löysin Jinjan dokumentaatiosta, kuinka muuttaa "osfamily"-arvo pieniksi kirjaimiksi. Lopullinen tila näyttää seuraavalta:



Ajoin tilan kahteen kertaan, toisella mitään ei enää odotetusti tapahtunut. Lähdin tutkimaan lopputulosta, joka osoittautui onnistuneeksi:

e) Tee tila, joka asentaa ja konfiguroi Apachen kahteen erilaiseen järjestelmään, esim. CentOS ja Ubuntu. Paketin nimi on CentOS:ssa "httpd". Käytä Salt-koodin generointia muoteilla.

Loin uuden tilan, joka lukee "grains["os_family"]"-arvon ja sen perusteella valitsee RedHat-perheelle "httpd"-paketin ja Debian-perheelle "apache2"-paketin. Jokin perhe saattaa käyttää Apachelle jotain muuta nimeä, joten en luonut mitään yleispätevää "else"-kohtaa. Lisäksi tila korvaa Apachen oletussivun.



Ajoin tilan ja pääsin heti korjaamaan kaksoispisteen puutteita. Yllä oleva kuva on näiden korjausten tulos. Kirjoitusvirheiden korjausken jälkeen ajoin tilan kahteen kertaan, kaikki hyvin. Lähdin testaamaan lopputulosta "curl"-komennon avulla. Minion, joka pyörii master-koneella:



Minion, joka pyörii CentOSilla:



Ei yhdistä. Arvelin tämän johtuvan palomuurista. Löysin Linuxconfig-artikkelin CentOSin porttien avaamiseksi. Komento "sudo firewall-cmd --zone=public --list-ports" palautti tyhjää eli portteja ei ole auki. Komennolla "sudo firewall-cmd --zone=public --permanent --add-port 80/tcp" lisäsin HTTP-portin ja "sudo firewall-cmd --reload" käynnisti palomuurin uudelleen ja muutokset tulivat voimaan:



Tämän seurauksena "curl"-komento palautti halutun sivun minionilta:

Lähteet:
http://terokarvinen.com/2020/configuration-managment-systems-palvelinten-hallinta-ict4tn022-spring-2020/
https://www.centos.org/download/
https://repo.saltstack.com/#rhel
https://jinja.palletsproject.com/en/2.11.x/templates/#lower
https://linuxconfig.org/redhat-8-open-and-close-ports

Harjoitus 7

Takaisin ylös

b) Oma moduli (iso tehtävä). Ratkaise jokin oikean elämän tai keksitty tarve omilla tiloilla/moduleilla.

Suunnitelmana on luoda tila, joka asentaa minionille Vagrantin avulla uuden virtuaalikoneen, johon asennetaan Apache näyttämään nettisivua.

Aloitin asentamalla Vagrantin ja VirtualBoxin käsin master-koneelle komennolla "sudo apt-get install -y vagrant virtualbox". Seurasin Vagrantin ohjeita ensimmäisen virtuaalikoneen pystyttämisessä. Loin aluksi Vagrantille uuden kansion kotihakemistoon "mkdir vagrantprojekti". Kansion sisällä ajoin kommennon "vagrant init 'hashicorp/bionic64'", joka luo koneen Ubuntu 18.04 -boxin pohjalta. Erilaisia boxeja oli suuri määrä. Komennolla "vagrant up" lähdin käynnistämään konetta, mutta ohjelma valitti "libvirtin" puuttumisesta. Ongelma korjaantui käyttämällä komentoa "vagrant up --provider virtualbox". Komento kuitenkin hetken käytyään epäonnistui, koska koneeseen ei saatu yhteyttä. Komennolla "vboxmanage list runningvms" selvitin, että virtuaalikone oli käynnissä, mutta yhteyttä ei voinut ottaa. Löysin samantapaisen ongelman ja kokeilin ehdotettua tapaa, jolla näkisi mitä koneella tapahtuu graafisen käyttöliittymän kautta. "Vagrantfile"-tiedostossa kävin seuraavien rivien kohdalta poistamassa kommentti-merkit:



Tämän seurauksena sain "vagrant up"-komennon jälkeen heti selville, mikä oli ongelmana:



Virtualisoinnin luultavasti saa päälle jostain, joten lähdin tutkimaan VirtualBoxin asetuksia ja löysin etsimäni prosessorin asetuksista. Laitoin raksin ruutuun kohdassa "Enable Nested VT-x/AMD-V":



Käynnistin master-koneen ja ajoin "vagrant up"-komennon uudelleen. Hetken odottelun jälkeen käynnistys onnistui ilman virheitä ja sain "vagrant ssh"-komennolla yhteyden:



Vagrantin nyt toimiessa lähdin tutkimaan, miten voisin hyödyntää tätä Salt tilassa. Asensin ensin Saltstackin ohjeiden mukaan uusimman version ajamalla komennon "wget -O - https://repo.saltstack.com/py3/ubuntu/18.04/amd64/latest/SALTSTACK-GPG-KEY.pub | sudo apt-key add -", kopioimalla "deb http://repo.saltstack.com/py3/ubuntu/18.04/amd64/latest bionic main" "/etc/apt/sources.list.d/saltstack.list"-tiedostoon ja ajamalla "sudo apt-get update" ja "sudo apt-get install -y salt-master" master-koneella sekä "sudo apt-get install -y salt-minion" minion-koneella. Lopuksi testasin toimivuuden:



Loin uuden Salt-tilan, joka asentaa minionille tarvittaessa Vagrantin ja Virtualboxin, kopioi "Vagrantfile"-tiedoston minionille sekä määrittelee ja käynnistää uuden VM:n. Ajoin tilan ja virheilmoituksia ei tullut. Mutta hetkinen! Minion-koneelle kyllä asentui Vagrant ja Virtualbox sekä ilmestyi "Vagrantfile"-tiedosto, mutta Vagranttia ei pistettä käyntiin.



Salt-dokumentaation mukaan "vagrant.running"-tilan pitäisi ajaa "vagrant up" -komento, joka ei kuitenkaan näytä toimivan. Pähkäilyn täyteisen hetken jälkeen keksin ajaa itse manuaalisesti "vagrant up" -komennon minion-koneella ja tämän seurauksena ongelma paljastuikin heti:



Ei riittäviä oikeuksia. "ls -l" -komento paljasti tiedostojen ja kansion olevan rootin omistamia. Niinpä korjasin tilan "init.sls"-tiedostoa laittamaan oikeudet halutuiksi ja lopullinen versio näytti seuraavalta:



Ajoin tilan ja viiden minuutin odottelun jälkeen, se päättyi onnistuneesti. Testasin lopputulosta ottamalla SSH-yhteyden minion-koneelle ja siltä SSH-yhteyden Vagrant-koneelle:



Jotta Vagrantin luomalla koneella olisi jotain hyötyarvoa, päätin saada sen asentamaan Apachen ja näyttämään master-koneelle nettisivun. Vagrantin sivuilta löysin, miten Vagrantin luomalla koneella voidaan ajaa komentoja luonnin yhteydessä. Lisäksi, jotta sivun sisältö näkyisi master-koneelta, lisäsin porttiohjauksen Vagrant-koneen hostin 8080-portista Vagrantin 80-porttiin. Lopulliset asetustiedostot:



Tilan ajaminen kesti 912 sekuntia eli noin 15 minuuttia. Lopulta tila ajoi itsensä läpi ja pääsin tutkimaan tuloksia. Selaimella minion-koneen IP-osoitteella haettaessa "192.168.200.4:8080" palautti Vagrant-koneen hostmaan nettisivun. Eli Apachen asennus, oletussivun sisällön muutos ja porttiohjaus kaikki onnistuivat haluamallani tavalla.



Lähteet:
http://terokarvinen.com/2020/configuration-managment-systems-palvelinten-hallinta-ict4tn022-spring-2020/
https://www.vagrantup.com/intro/getting-started/index.html
https://app.vagrantup.com/boxes/search
https://stackoverflow.com/a/22575302
https://repo.saltstack.com/#ubuntu
https://docs.saltstack.com/en/latest/ref/states/all/salt.states.vagrant.html
https://www.vagrantup.com/intro/getting-started/provisioning.html
https://www.vagrantup.com/docs/networking/forwarded_ports.html