Palvelinten hallinta H6

Yksi totuus.

Distrosta riippumatta kaikki orjat samassa tilassa.

Tein tehtävän kotona pöytäkoneellani, jossa oli mm. Intel i5-3570K prosessori, 8GB RAM-muistia, Asus GTX 1060 (6GB) näytönohjain ja käyttöjärjestelmänä Win 10. Jatkoin tehtävien tekemistä VirtualBoxissa (versio 6.1.4) luomillani virtuaalikoneilla, joita käytin edellisissä harjoituksissa.

Aloitin tehtävän tekemisen 12.5.2020 klo 20:00 (UTC +3).

Tehtävänanto osoitteessa: http://terokarvinen.com/2020/configuration-managment-systems-palvelinten-hallinta-ict4tn022-spring-2020/



a) Asenna jokin toinen Linux-levityspaketti orjaksi Saltille. CentOS on hyvä vaihtoehto. Voit esimerkiksi asentaa CentOS:n VirtualBoxiin ja tehdä koneiden välille virtuaaliverkon. Jos käytät Vagrantia, ’cent.vm.box = ”centos/7″’ on kätevä.

Päätin asentaa tehtävänannossa minitun CentOS:n.
Latasin CentOS-8.1.1911-x86_64-dvd1.iso -tiedoston:
https://www.centos.org/download/


Asensin CentOSin Virtualbox 6.1:lle näiden ohjeiden mukaisesti:
https://linuxhint.com/install_centos8_virtualbox/

CentOS asennettu

Sen jälkeen asensin Guest Additioninsin, jonka avulla VirtualBoxin käyttö on jouhevampaa. Googletin lukuisia eri ohjeita, ja asennukset epäonnistuivat useaan kertaan. Lopulta sain Guest Additionsin toimimaan tätä asennusohjetta noudattamalla:
https://www.if-not-true-then-false.com/2010/install-virtualbox-guest-additions-on-fedora-centos-red-hat-rhel/

Salt minionin asensin tämän ohjeen mukaan:
https://repo.saltstack.com/#rhel
Lisäsin tiedostoon /etc/salt/minion masterin ip:n ja CentOSin id:n:

master: 192.168.0.102
id: CentOSslave

Käynnistin minionin uudestaan, jotta asetukset tulisivat voimaan:

sudo systemctl restart salt-minion

Nyt siirryin Master-koneelle, Tietoturva-aukon vuoksi päivitin aiemmissa tehtävissä käyttämäni masterkoneen Saltin versioon 2019.2.4 näiden ohjeiden ja Aki Ronkaisen neuvojen avulla.

Komennolla salt –versions voi tarkistaa mm. käytössä olevan Saltin version. Salt näytti päivittyneen onnistuneesti.

Annoin masterilla komennon:

sudo salt-key -A

Kyseisen komennon kautta master hyväksyy juuri luomani minionin (CentOSslave) avaimen, ja näin orjakone voi kommunikoida masterin kanssa. Testasin yhteyttä komennolla:

sudo salt '*' cmd.run 'whoami'

CentosOSslavelta tuli vastaus, mutta samalla huomasin, ettei aiemmissa tehtävissäni käyttämäni orja vastannut. Aikani selviteltyäni asiaa huomasin, että toimimattomalla orjalla oli väärä masterin IP-osoite. Osoite oli siis vaihtunut jostain syystä. Korjasin osoitteen, ja hyväksyin Masterilla vanhan orjan avaimen uudestaan. Orja ei silti vastannut.

Löytämääni pingikomentoa testatessani sain kyseisen ilmoituksen, jonka vuoksi aloin tutkia avaimia.

Selvittelin asiaa pari tuntia, ja kun en muuta enää keksinyt, niin poistin orjakoneelta tiedoston /var/lib/salt/pki/minion/minion_master.pub.

Poistin myös masterkoneelta toimimattoman minionin avaimen (käyttämäni orjan id oli XubuntuSlave):

sudo salt-key -d XubuntuSlave

Käynnistin minionin varmuuden vuoksi uudestaan. Hyväksyin masterilla XubuntuSlaven avaimen (sudo salt-key -A), minkä jälkeen homma lähti pelittämään. (Avainten kanssa tapellessa tein myös kolmannesta koneesta orjan, JoniSlaven, mutta sekään ei lähtenyt toimimaan ennen kuin tein saman avaintiedoston poiston kuin CentOSslavelle).

Kaikki orjat vastasivat.

CentOS:n asentamisessa ja säätämisessä, Saltin päivittämisessä sekä Saltin avaimien räpeltämisessä olikin mennyt jo todella monta tuntia, joten tässä vaiheessa oli pakko pitää taukoa.

Lopetin tehtävien tekemisen 13.5.2020 klo 1:30 (UTC +3)



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

Jatkoin tehtävien tekemistä 13.5.2020 klo 12:00.

Ajoin masterilla testimielessä komennon sudo salt ’*’ cmd.run ’whoami’, ja huomasin, ettei CentOSslave vastannut. Poistin masterilta orjan avaimen sudo salt-key -d CentOSslave. Annoni orjalla varmuuden vuoksi komennon sudo systemctl restart salt-minion. Hyväksyin masterilla orjan avaimen sudo salt-key -A. Uuden testin jälkeen CentOSslave vastasi. En oikein tiedä, mikä näissä avainsekoiluissa oli kyse, mutta jatkoin tehtävien tekemistä.

Päätin kerätä grainsin avulla tietoja orjien käyttöjärjestelmistä. Ajoin masterilla komennon:

sudo salt '*' grains.item os_family osfinger
Tietoja orjista


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.

Yritin alkuun asentaa openssh:ta CentosSlavelle. En saanut toimimaan, joten yritin poistaa openssh:ta asentaakseni sen uudestaan uusien ohjeiden mukaan. Virtuaalikone kaatui yllättäen. Uudelleen käynnistymisen jälkeen kone ei käynnistynyt enää graafiseen käyttöliittymään. En tiennyt mikä oli vialla, joten päädyin asentamaan graafisen käyttöliittymän uusiksi näiden ohjeiden mukaan. Olisi ehhhhkä kannattanut ensin yrittää käynnistää graafinen käyttöliittymä ilman uudelleen asentamista…

Pääsin jälleen työpöydälle, ja huomasin ettei CentosSlave vastaa masterille. Uusin jälleen avaimen masterin päässä. Samalla huomasin, että CentosSlavella antamani komento hostname -I antaa kaksi eri IP-osoitetta, kun muut koneeni antavat vain yhden. Mietin, voisiko tämä liittyä jotenkin tuohon avainhässäkkään. En alkanut tässä vaiheessa selvittämään asiaa tämän enempää.


Motd -tila

Olin aiemmassa harjoituksessa tehnyt motd -tilan, jonka tiedostoa nyt muokkasin tämän näköiseksi:

Tervehdys!

Koneen id: {{ grains['id'] }}
Käyttöjärjestelmä: {{ grains['osfinger'] }}
Suorittimen malli: {{ grains['cpu_model'] }}

Itse init.sls -tiedosto säilyi ennallaan. Ajoin tilan antamalla masterille komennon sudo state ’*’ state.apply motd.

Sain tiedon kahdesta onnistuneesta tapahtumasta, joissa motd-tiedostoa muokattiin. Annoni masterilla komennon:

sudo salt '*' cmd.run 'cat /etc/motd'

Terminaliin tulostui molempien orjakoneiden motd-tiedoston sisältö. Kirjauduin XubuntuSlavelle ssh:lla, ja muuttunut motd-teksti tulostui ruudulle. CentOSslaven ssh-testi jäi toistaiseksi tekemättä, mutta yritän mahdollisesti vielä asentaa ssh:ta uudestaan.


Lisäys 14.5.2020 klo 17:10:

Kokeilin uudestaan CentOS:n ssh:ta ja se toimi moitteettomasti. Toimi kyllä aiemminkin, mutta en vain ollut tajunnut kirjautuessani ssh:lle (ssh joni@localhost), että kirjautuminen onnistui, sillä CentOS:ssa ei ole defaulttina kummoista motd:a.

Asensin openssh:n näiden ohjeiden mukaan, ja luomani motd toimi kuten pitikin.

Lisäys päättyy.



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.

Loin masterille tilaa varten uuden kansion:

sudo mkdir /srv/salt/newfile

Kansioon tein newfile -nimisen tiedoston, jonka sisällöksi kirjoitin ”Tämä on tiedosto”.

sudoedit /srv/salt/newfile/newfile

Tein kansioon myös init.sls tiedoston. Tero Karvinen kertoi edellisellä oppitunnilla, miten eri järjestelmille saa saltin avulla asennettua sovelluksia. Mukailin Teron ohjeita, ja pistin tiedoston sisällöksi:

{% if grains['os_family'] == "RedHat" %}
{% set tiedosto = "redhat" %}
{% elif grains['os_family'] == "Debian" %}
{% set tiedosto = "debian" %}
{% endif %}

/tmp/{{ tiedosto }}:
  file.managed:
    - source: salt://newfile/newfile

Kyseinen tila tekee RedHat-perheen järjestelmille tiedoston /tmp/redhat ja Debian perheen järjestelmille tiedoston /tmp/debian. Molempien tiedostojen sisältö on sama, eli masterilla oleva /srv/salt/newfile/newfile.

Ajoin masterilla tilan:

sudo salt '*' state.apply newfile

Molempiin orjakoneisiin luotiin onnistuneesti halutut tiedostot. Kävin myös tarkastamassa kummaltakin koneelta tiedostojen olemassaolon ja oikeellisuuden.

Lopetin tehtävien tekemisen 13.5.2020 klo 17:00 (UTC +3)



d) 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.

Jatkoin tehtävien tekemistä 14.5.2020 klo 12:00 (UTC +3).

Tarkoituksena oli samalla tilalla saada asennettua Apache Debian- ja RedHat-pohjaisille järjestelmille ja tehdä samalla jotain säätöjä.

Testasin ensin CentOSslavella ettei selaimen localhost vastaa. Asensin sitten Apachen käsin näiden ohjeiden mukaan:

sudo yum install -y httpd
sudo systemctl enable httpd
sudo systemctl start httpd

Kirjoitin selaimen osoiteriville ”localhost”, jolloin Apachen testisivu avautui.

Tein uuden default-sivun Apachelle:

sudo nano /var/www/html/index.html

Sivun sisällöksi kirjoitin ”Apachen testisivu”. Selaimeen uudelleen ”localhost”, jolloin luomani testisivu avautui.

Olin jo aiemmin asentanut Apachen Saltin avulla Xubuntulle, joten en lähtenyt sitä enää erikseen käsin testailemaan.

Seuraavaksi yritin muutaman tunnin ajan saada userdiriä ja virtualhostia toimimaan CentOSslavella, mutta en onnistunut. Tuntui, että CentOS:ssa kaikki oli munimutkaisempaa kuin Xubuntulla. En raportoinut, sillä tämä vaihe oli aikamoista säätämistä ja kokeilin niin monia eri asioita ja ohjeita. Päätin lopulta tyytyä siihen, että tilani asentaa Apachen ja vaihtaa default-sivun toiseksi.

Apache-tila

Minulla oli masterilla salt-kansiossa ennestään apache-kansio aiemmin luotua tilaa varten, joten tein nyt uuden kansion nimeltä apacheee.

sudo mkdir /srv/salt/apacheee

Kansioon tein uuden default-sivun nimeltä default-index.html:

sudoedit default-index.html

Sisällöksi kirjoitin ”Apachen testisivu RedHatille ja Debianille”.

Loin myös init.sls tiedoston, jonka sisällöksi kirjoitin seuraavan:

{% if grains['os_family'] == "RedHat" %}
{% set server = "httpd" %}
{% elif grains['os_family'] == "Debian" %}
{% set server = "apache2" %}
{% endif %}

{{ server }}:
  pkg.installed
/var/www/html/index.html:
  file.managed:
    - source: salt://apacheee/default-index.html
{{ server }}.service:
  service.running

Sisältö on mukaelma Tero Karvisen edellisellä oppitunnilla näyttämästä esimerkistä. Salt hakee käyttöjärjestelmäperheen ja asentaa sen perusteella joko apache2:n tai httpd:n (Apache RedHatissa). Sen jälkeen luodaan uusi default-sivu, ja lopuksi varmistetaan Apachen olevan käynnissä.

Kävin poistamassa Apachen molemmilta orjakoneilta ja varmistin vielä sen, ettei selaimen localhost vastaa. Ajoin masterilla tilan komennolla:

sudo salt '*' state.apply apacheee

Hetken kulttua sain ilmoituksen kaikkien toimintojen onnistuneesta suoritttamisesta. Apache käynnistyy Xubuntulla näköjään automaattisesti, joten se oli ilmoituksen mukaan jo käynnissä.

Kävin kirjoittamassa molemmissa orjakoneissa selaimeen ”localhost”, jolloin haluamani uusi Apachen default-sivu avautui.

Lopetin tehtävän tekemisen 14.5.2020 klo 16:00 (UTC +3)

Oli mielenkiintoista huomata, miten paljon Linuxin eri jakelupaketit eroavat toisistaan. Eri distroihin täytyy kyllä perehtyä jatkossa tarkemmin.

Lähteet

Vastaa

Täytä tietosi alle tai klikkaa kuvaketta kirjautuaksesi sisään:

WordPress.com-logo

Olet kommentoimassa WordPress.com -tilin nimissä. Log Out /  Muuta )

Twitter-kuva

Olet kommentoimassa Twitter -tilin nimissä. Log Out /  Muuta )

Facebook-kuva

Olet kommentoimassa Facebook -tilin nimissä. Log Out /  Muuta )

Muodostetaan yhteyttä palveluun %s

Create your website with WordPress.com
Aloitus
%d bloggaajaa tykkää tästä: