Harjoitus 1

Harjoitus 2

Harjoitus 3

Harjoitus 4

Harjoitus 5

Harjoitus 6

Harjoitus 7

Harjoitus 7 – Oma moduli

Harjoituksessa pitää tehdä oma moduli. En saanut valitettavasti tehtyä mitään kummoista modulia, koska aika ja osaaminen loppuivat kesken.

Ideana olisi ollut luoda sellainen moduli, jossa pääsisi internettin kautta vain yhteen nettiosoitteeseen (tässä tapauksessa yhden omista virtuaalikoneistani), jossa pystyisi jakamaan tiedostoja. Käyttäjällä olisi oma kansio, joka olisi yhteydessä tähän nettisivuun. Tämä jäi kuitenkin puoleen väliin.

Tekemääni moduulia en pystynyt myöskään testaamaan orjillani, koska ne eivät jostakin syystä olleet päällä. Yritin niitä käynnistää ja uudelleenkäynnistää paikallisesti, mutten onnistunut. Jouduin siis vain testaamaan moduulia masterilla.

Aloitin rajoittamalla pääsyä internetiin. Kokeilin erilaisia tapoja: mene /etc/hosts, jonne kirjoita 127.0.0.1 *.*.*.*. Ei onnistunut. Tee sama /etc/hosts.deny. Ei onnistunut. Kokeile /etc/hosts.deny ALL: *.*.*.*. Ei onnistunut. (*.*.*.* olisi pitänyt tarkoittaa kaikkia ip-osoitteita)

Kokeilin kirjoittaa /etc/hosts tiedostoon 127.0.0.1 hs.fi. Testasin curl hs.fi ja se antoi localhostin sivun. Eli tällä tavalla toimii yhden nettisivun estäminen, mutta halusin saada kaikki estettyä.

Löysin tältä sivulta hyviä iptables-komentoja:

• 1) iptables -I OUTPUT -p tcp -m tcp –dport 80 -j REJECT –reject-with icmp-port-unreachable
• 2) iptables -I OUTPUT -p tcp -m tcp –dport 443 -j REJECT –reject-with icmp-port-unreachable
• 3) iptables -I OUTPUT -p tcp -m tcp -d 142.93.174.232/32 –dport 80 -j ACCEPT
• 4) iptables -I OUTPUT -p tcp -m tcp -d 142.93.174.232/32 –dport 443 -j ACCEPT

1) ja 2) estävät kaiken liikenteen porteista 80 (http) ja 443 (https) ulos. 3) ja 4) taas sallivat kaiken liikenteen ip-osoitteeseen 142.93.174.232, joka on minun oma virtuaalikoneeni.

Testaan curl hs.fi ja saan: curl: (7) Failed to connect to hs.fi port 80: Connection refused. Eli se onnistui.

Kun kokeilen curl 142.93.174.232 saan sen lyhyen tekstin mikä siellä on.

Seuraavaksi yritin tehdä iptables modulia saltilla, mutten onnistunut sitä saamaan liikennetteä estettyä. Se kyllä lisäsi ne uudet säännöt sinne iptablesiin, mutta ei varmaan oikeasti tehtynä. Minulla ei nyt ole tässä niistä kuvia tai kopioita, kun en tajunnut ottaa. Teen ne sitten cmd.run modulina. Helpoimman kautta siis.

Seuraavaksi tein init.sls tilaan seuraavat:

• luo ryhmä exchangefiles
• luo käyttäjä, joka lisätään ryhmään exchnagefiles
• luo hakemisto /var/www/GroupFolder, johon lisätään testuser ja ryhmä exchangefiles. Anna sille myös pääsyoikeudeksi 5 eli read ja execute
• luo hakemisto /var/www/GroupFolder/files, johon lisätään testuser ja ryhmä exchangefiles. Anna sille myös pääsyoikeudeksi 7 eli read, write ja execute
• asenna Firefox
• laite ne neljä iptables-komentoa cmd.run:ina

Siitä tuli tällainen:

exchangefiles:   group.present: – system: True testuser:   user.present: – fullname: Test User – groups:    – exchangefiles – home: /home/testuser /var/www/GroupFolder:   file.directory: – makedirs: True – user: testuser – group: exchangefiles – dir_mode: 5 /var/www/GroupFolder/files:   file.directory: – makedirs: True – user: testuser – group: exchangefiles – dir_mode: 7 firefox:   pkg.installed ’iptables -I OUTPUT -p tcp -m tcp –dport 80 -j REJECT –reject-with icmp-port-unreachable’:   cmd.run ’iptables -I OUTPUT -p tcp -m tcp –dport 443 -j REJECT –reject-with icmp-port-unreachable’:   cmd.run ’iptables -I OUTPUT -p tcp -m tcp -d 142.93.174.232/32 –dport 80 -j ACCEPT’:   cmd.run ’iptables -I OUTPUT -p tcp -m tcp -d 142.93.174.232/32 –dport 443 -j ACCEPT’:   cmd.run

Käytin apuna näitä sivuja:

• https://unix.stackexchange.com/questions/208960/how-to-restrict-a-user-to-one-folder-and-not-allow-them-to-move-out-his-folder
• https://www.tutorialspoint.com/unix/unix-file-permission.html
• https://docs.saltstack.com/en/latest/ref/states/all/salt.states.file.html#salt.states.file.directory

Ajoin sen onnistuneesti paikallisesti komennolla $ sudo salt-call –local state.apply netti

Curl:

Files-hakemisto ja sen oikeudet:

Harjoitus 6 – Yksi totuus

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ä.

Aloitin harjoutuksen tekemisen n. 9.30. Ensiksi luon uuden palvelimen DigitalOceanissa. Valitsin käyttöjärjestelmäksi CentOS.

Otan siihen ssh yhteyten. Teen alkujutut, jotta saan sen suojattua. Luon uuden pääkäyttäjän, annan sille rootin oikeudet ja lukitsen rootin, jottei sillä voi kirjautua sisään.

Käytin neuvona näitä ohjeita: https://www.digitalocean.com/community/tutorials/how-to-add-and-delete-users-on-a-centos-7-server

Tässä joutui käyttämään toista Linuxin käyttöjärjestelmää kuin Ubuntua, joten komentojen kanssa oli vähän ongelmia, mutta onneksi pääsi nopeasti jyvälle.

• adduser emma
• passwd emma
• gpasswd – a emma wheel (tällä laitan käyttäjän sudo/root-ryhmään)

Kirjaudu ulos ja sisään. Seuraavaksi lukitsen rootin (tai ainakin luulen, että lukitsin):

• sudoedit /etc/passwd
• root:x:0:0:root:/root:/bin/bash
• -> root:x:0:0:root:/root:/sbin/nologin

Teen siitä orjan ja lisään masterille sen orjaksi. Käytin ohjeina tätä: https://repo.saltstack.com/#rhel

Asenna se:

• sudo yum install https://repo.saltstack.com/py3/redhat/salt-py3-repo-latest.el8.noarch.rpm
• sudo yum clean expire-cache
• sudo yum install salt-minion
• sudo systemctl restart salt-minion

Sudoedit minion

• master: *ip-osoite*
• id: slave3

Sitten laitan minionin päälle. Käytin ensiksi tätä komentoa: sudo systemctl restart salt-minion.service, mutta sitten tätä: $ systemctl start salt-minion.service. Pyysi authenticationia ja id:n valitsemista.

Masterilla:

• sudo salt-key -A:
• The key glob ’*’ does not match any unaccepted keys.

Tässä kohtaa mietin, että pitää odottaa vähän aikaa, mutta sama viesti tuli. Tajusin, ettei salt-minion ei ollut päällä, joten laitoin sen päälle. Mutta sitten tuli taas ERROR: Error while bringing up minion for multi-master. Is master at 134.122.80.89 responding? Master ei näköjään ollut päällä.

• Unable to bind socket 0.0.0.0:4505, error: [Errno 98] Address already in use; Is there another salt-master running?
• The salt master is shutdown. The ports are not available to bind

Onkohan siellä joku toinen orja tuossa portissa?

Menen masterille kokeilemaan tätä (luin tämän joltakin sivulta, en nyt ottanut ylös sitä):

• sudoedit /etc/salt/master
• interface: 10.0.0.1

Salt-masterin restart komento: Job for salt-master.service failed because the control process exited with error code.

Menen takaisin poistamaan tuon muutoksen.

Kokeilen nyt sammuttaa masterin: sudo service salt-master stop

Laitan sen päälle: sudo systemctl start salt-master.service

Nyt kokeilen: $ sudo salt-key -A: Unaccepted Keys: Centos.

Sen hyväksyin. Nyt onnistui liittämään orjan masteriin.

Kokeilen komentoa sudo salt ’*’ cmd.run ’whoami’. Sain kaikilta orjilta vastauksen.

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

Master-koneella komento: $ sudo salt Centos grains.items|less

Centos: ———- SSDs: biosreleasedate:      12/12/2017 biosversion:      20171212 cpu_flags:      [deleted] cpu_model:      Intel(R) Xeon(R) Gold 6140 CPU @ 2.30GHz groupname:      root host:      Centos id:      Centos init:      systemd ip4_gw:      142.93.160.1 kernel:      Linux kernelrelease      4.18.0-147.3.1.el8_1.x86_64 kernelversion:      #1 SMP Fri Jan 3 23:55:26 UTC 2020 locale_info:      ———-      defaultencoding:          UTF-8      defaultlanguage:          en_US detectedencoding:          UTF-8      timezone:          UTC localhost:      Centos lsb_distrib_codename:      CentOS Linux 8 (Core) lsb_distrib_id:      CentOS Linux lsb_distrib_release:      8 machine_id:      ba7021f6fcf3409d99b4fead5440ab76 manufacturer:      DigitalOcean master:      134.122.80.89 mdadm: mem_total: 821 nodename:      Centos num_cpus:      1 num_gpus:      1 os:      CentOS os_family:      RedHat osarch:      x86_64 oscodename:      CentOS Linux 8 (Core) osfinger:      CentOS Linux-8 osfullname:      CentOS Linux productname:      Droplet saltversion:      3000.2 saltversioninfo:      – 3000      – 2

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.

Katson ensiksi, mitä uusi Centos-orja sanoo osfingeriksi:

• master$ sudo salt Centos grains.item osfinger
• Centos:
• ———-
• osfinger:
• CentOS Linux-8

MOTD nyt Centos-orjalla:

• Activate the web console with: systemctl enable –now cockpit.socket
• Last login: Fri May  8 06:44:22 2020 from

Centos-koneella:

• slave $ sudoedit /etc/motd:
• Moi

Logout ja login:

Mene masterille ja hakemistoon /srv/salt/motd. Siellä on jo valmiiksi motd-tila, jota käytin aiemmassa tehtävässä. Kokeilin ensiksi ajaa tilaa CentOS:ille, mutta se ei onnistunut, koska Centosilla ei ollut motd-kansiota, kun taas toisilla orjillani oli, koska olin ne tehnyt sinne. CentOS:illa on vain motd-tekstitiedosto. Joten muutin motd:n init.sls tilaa.

Lopulta motd init.sls tiedosto:

Sitten ajoin sen Centos:ille, mikä onnistui. Logout ja login:

Nyt menen muokkaamaan sitä /srv/salt/motd/motd.txt tiedostoa, jotta tulee se osfinger-tieto:

Tadaa! Nyt siellä lukee se Osfinger.

Huoh! Nyt sain tämän toimimaan myös toisille orjilleni, jotka ovat ubuntuja. Edellisessä harjoituksessa olin ymmärtänyt yhden asian väärin, joten en ollut saanut omaa motd:ia toimimaan. Luulin, että siellä /etc pitää olla /motd-hakemisto, jonka sisällä motd.txt, mutta riittää siis vain jos /etc itsessään on vain se motd.txt, jolloin kone näyttää sen, kun siihen kirjautuu.

Ten nyt sillein, että menin ubuntu-orjalle, poistin sielä sen /motd kansion ja ajoin tuon motd tilan kaikilla orjilla. Kun menin ubuntu-orjalle ja kirjauduin sisään, nyt motd oli muuttunut:

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.

Pidin tässä välissä tunnin tauon. Jatkoin tämän tekemistä klo 11.40.

Teen ensiksi niin, että se toimii masterilla ilman mitään muuttujia ja if-lauseita.

Tee kansio /srv/salt/tmp. Luo tila: sudoedit init.sls. Kokeilen tällaisella:

Testaa ensiksi paikallisesti: sudo salt-call –local state.apply tmp. Tämä epäonnistui, koska ”Source file salt://tmp/ not found”. Käyn poistamassa tuolta init.sls tilasta sen source kohdan. Ajan paikallisesti taas. Nyt onnistui. Sain kuitenkin varoituksen: [WARNING ] State for file: /tmp/debian – Neither ’source’ nor ’contents’ nor ’contents_pillar’ nor ’contents_grains’ was defined, yet ’replace’ was set to ’True’. As there is no source to replace the file with, ’replace’ has been set to ’False’ to avoid reading the file unnecessarily.

Käyn katsomassa /tmp hakemistoa. Se oli luonut tiedoston sinne eikä kansiota. Tehtävänannossa sanotaan, että luo pelkkä hakemisto. Yritän siis saada sen pelkän hakemiston ilman tiedostoa.

Käytän ohjeena tätä: https://docs.saltstack.com/en/master/ref/states/all/salt.states.file.html

Tuon mukaan file.managedin tilalle file.directory. Koeilen sillä ja ajan tilan paikallisesti.

[!!!! ETA: Olin tässä ymmärtänt tehtävänannon väärin. Olisi siis pitänyt tehdä se tiedosto eikä hakemistoa. Tämän saisi kuitenkin helposti korjatta laittamalla siihen sen file.managed ja source: salt: //tmp/{{ tmpfile }} ja tehnyt sen tmp-tekstitiedoston tuonne /srv/salt/tmp kansioon ]

(sain ensin vastaukseksi ”Specified location /tmp/debian exists and is a file”. Se kummittelee siellä, joten kän poistamassa sen)

Tulos:

Comment: Directory /tmp/debian updated   Started: 08:55:55.572746 Duration: 13.735 ms   Changes:               ———-            /tmp/debian:                New Dir

Sitten se hankala osuus. Käytän apuna tätä: http://terokarvinen.com/2018/configure-windows-and-linux-with-salt-jinja-if-else-and-grains

Käytän tällaista init.sls tilaa:

Huomasin heti, että siellä oli kirjoitusvirhe (& -> %). Korjasin sen ja ajoin orjilla: sudo salt ’*’ state.apply tmp

Sain vastaukskesi: ”Salt request timed out”

Tässä vaiheessa kokeilin kaikkia eri tapoja korjata tilannetta muokkaamalla init.sls tilaa. En nyt viitsi kirjoittaa kaikkea tässä, koska tajusin sitten, että master ei ollut päällä.

Laitan masterin ensiksi pois päältä ja siten uudestaan päälle:

• $ sudo service salt-master stop
• $ sudo systemctl start salt-master.service

Init.sls tässä vaiheessa (olin ottanut if lauseet pois)

Ajoin tämän, mikä onnistui. Ne loivat sen /tmp/*** hakemistot.

Laitoin if lauseet tilaan:

Ajo kaikille epäonnistui:

• ID: tmp/RedHattu
• Function: file.directory
•    Result: False
•   Comment: Specified file tmp/RedHattu is not an absolute path

Se kuitenkin osasi sijoittaa ne os_fingerit sinne, mutta tuo luomisjuttu on vain väärin.

Kokeilin seuraavaksi tällä:

Tällä onnistui. Jee!! Ajoin kaikille kolmelle orjalle ja ne tekivät ne /tmp/*osfinger* hakemistot.

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.

Teen ensiksi kansion tehtävälle: sudomkdir /srv/saltApache. Luon tilan: sudoedit init.sls

Käytän apuna tätä sivua: https://docs.saltstack.com/en/master/topics/tutorials/states_pt3.html

apache:   pkg.installed: {% if grains[’os’] == ’RedHat’ %} – name: httpd {% elif grains[’os’] == ’Ubuntu’ %} – name: apache2 {% endif %}

Testaan ensiksi ajaa tätä pelkästään ennen kuin teen säädöksiä. Ajaminen kestää hetken aikaan, kun se varmaan asentaa niitä- Se oli asennettu jo yhdelle orjalle ja onnistui toiselle ubuntu orjalle. CentOS kuitenkin epäonnistui:

Centos: Data failed to compile: ———- ID ’apache’ in SLS ’apache’ contains a short declaration (pkg.installed) with a trailing colon. When not passing any arguments to a state, the colon must be omitted.

Poistan sen : aksoispisteen pkg-installed jäökeen, mutta se epäonnistui.

Muutin sen [’os’] -> [’os_family’]. Nyt sen ajo onnistui CentOS:ille, mutta ubuntut alkoivat valittaa.

Nyt tajusin, että ubuntun tilalla pitäisi olla debian, koska debian on se perhe. Nyt sen ajo onnistui. Kaikki ovat happy. Yksi iso happy linux perhe.

Lopullinen init.sls:

Tämän varmaan voi tehdä niin, että ne if ja muuttujat on alussa eikä tuolla välissä. Mutta en nyt osannut. Lopetan tässä välissä klo 13.20. Jatkan harjoitusta palautuspäivänä klo 15.25 ja lopetin n. klo 16.

Testaan nyt niin, että laitan ne if-lauseet ovat siinä alussa. Käytin apuna toisen opiskelijan tekemää harjoitusta, koska en ehtinyt nyt alkaa itse säätämään. (https://jannelinux.design.blog/)

Aluksi testasin, että master on päällä (ei ollut, joten laitoin sen päälle).

Menen muokkaamaan sitä /srv/salt/apache/init.sls tiedostoa. Kommentois pois ne aiemman, jotta ne kuitenkin pysyvät siellä.

Kokeilen tällaista:

Tein ne tekstitiedostot: sudoedit centos ja sudoedit ubuntu. Sitten kokeillaan ajoa orjille: sudo salt ‘*’ state.apply apache

Kaikki onnistui muuten, mutta yksi ubuntu orjista valitti service.running-kohdasta. Annoin sen olla, koska sillä oli siis jo Apache asennettu ja säädetty webbisivu. Toinen ubuntu siis onnistui

Slave1:

CentOS:

Harjoitus on osa kurssia Palvelinten hallinta: http://terokarvinen.com/2020/configuration-managment-systems-palvelinten-hallinta-ict4tn022-spring-2020/

h5 Muotteja ja moduleja

Aloitin harjoituksen tekemisen n. klo 9.15 ja lopetin n. klo 13.00.

Jos saisin itse antaa arvosanan harjoituksesta, antaisin itselleni ehkä 3 (asteikolla 1-5), koska, vaikka tein jokaisen tehtävän, en tehnyt niitä kaikkia yhtä hyvin ja joissakin vain jätin kesken ajatuksella, että jatkaisin myöhemmin. Kävi kuitenkin niin, että vähän unohdin jatkaa ja tehtävät jäivät osittain kesken.

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

Tein tämän omalle virtuaalipalvelimelleni. Tämä tehtävä onnistui muutaman mutkan kautta hyvin. Käytin apuna opettajan ohjeita: http://terokarvinen.com/2018/make-a-million-of-those-jinja-templating-salt-states

Tein ensiksi tuon opettajan ohjeiden mukaan muotin, joka loisi tekstitiedostoja ja vasta sitten tein oman muotin. Asensin jinja2, koska sitä tarvitaan näiden muottien tekemiseen.

Seuraavaksi:

• sudo mkdir -p /srv/salt/multi
  • kansio, jonne sijoitan muotin
• sudoedit /srv/salt/multi/init.sls
  • luo ”salt state”

init.sls tekstitiedoston sisälle:

{% 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 %}

Tuo ylempi luo kolme tekstitiedostoa ja luo /tmp -hakemistoon /moikat -hakemiston.

Vielä tehdään tiedostomuotti: $sudoedit /srv/salt/multi/moikka.txt. Tämän sisään kirjoita: Moikka Tämä on {{ file }}.

{{ xxx }} ovat muuttujia, joihin tulee tässä tapauksessa tiedoston nimi.

Testi: $ sudo salt-call –local state.apply multi. Kaikki näytti vihreätä, joten sen ajo onnistui. Menen katsomaan /tmp -hakemistoon, mitä sinne tapahtui. Siellä oli se kansio /moikat, jossa oli ne kolme .txt-tiedostoa: bar, foo, kala. Jokaisessa oli myös oma tiedoston nimi tekstissä:

Seuraavaksi luon oman muotin. Käytin apuna tätä sivua: https://docs.saltstack.com/en/latest/topics/grains/

Katso ensiksi, mitä grainseja orjista on saatavilla: $ sudo salt ’*’ grains.ls. Valitsen listasta ipv4:n ja ipv6:n (jos sellainen tieto on saatavilla).

Luon hakemiston, jonne sijoitan muotin: $ sudo mkdir -p /srv/salt/grains.

Seuraavaksi salt tila: $ sudoedit init.sls (/grains-hakemistossa).

Katsotaan, toimiiko tällainen:

Tämän jälkeen tajusin heti jonkun virheen (mitä en nyt tarkalleen muista): ”ei kun nyt tajusin virheen pitää laittaa sinne ipv4 ja se ipv6” (ote muistiinpanoistani).

Päätin kokeilla ensiksi pelkällä ipv4:lla:

Seuraavaksi ip.txt-tiedoston tekeminen, jonne kirjoitin: {{ ipv4 }} on tämän tietokoneen ipv4-osoite.

Testaa paikallisesti: $sudo salt-call –local state.apply grains. -> ERROR Template was specified incorrectly

Näin nyt heti, että siellä oli kirjoitusvirhe: makedeirs -> makedirs.

Korjaa se ja testaa uudestaan. Taas Error:

• Template was specified incorrectly: False
• local:
• Data failed to compile:
• ———-
• No matching sls found for ’grains’ in env ’base’

En tiennyt, mitä tämä tarkoitti. Arvelin ehkä, että siinä on joku viittausvirhe. Nyt tajusin, että molemmat .sls ja .txt tiedostot olivat /srv/salt hakemistossa eikä /srv/salt/grains hakemistossa. Siirsin ne sinne (tai ensiksi yritin komennolla sudo mv init.sls /grains ja sudo mv ip.txt /grains, mutta ne eivät menneet sinne, vaan katosivat kuka tietää minne, joten lopulta kirjoitin ne uudestaan /grains hakemistoon).

Taas ajo paikallisesti: [ERROR   ] Rendering exception occurred: Jinja variable ’ipv4’ is undefined

Nyt on helpompi korjata tilanne, kun on kyse ipv4 muuttujasta. Käytin apuna tätä sivua: https://stackoverflow.com/questions/18360528/how-to-get-ip-address-of-hostname-inside-jinja-template

Käytin muuttujana tätä: {{ grains[’ipv4’][0] }}

ip.txt-tiedostosta tuli tällainen siis: {{ grains[’ipv4’][0] }} on tämän tietokoneen ipv4-osoite

Lopullisesta init.sls tiedostosta tuli tällainen:

Nyt ajo paikallisesti onnistui.

Käydään katsomassa /tmp -hakemisto. Sinne tuli se ipvt-kansio, jossa sisällä on tekstitiedosto, mutta sen kansion nimi on 10.19.0.7 ja sen sisällä teksti tuon ip-osoitteen kanssa. Tuo on yksityisen verkon ip-osoite.

Kokeilin tämän https://docs.ansible.com/ansible/latest/user_guide/playbooks_filters_ipaddr.html neuvojen mukaan tällaista muuttujaa: {{ ipaddr(’address’) }}

Ajo paikallisesti, mutta tuli erroria: Rendering exception occurred: Jinja variable ’ipaddr’ is undefined

Kokeilin sitten tuota aiempaa ilman sitä [0] siellä perässä. Ajo paikallisesti onnistui, mutta nyt /tmp/ipvt hakemistossa oli uusi tiedosto, jonka nimenä on kolme ipv4-osoitetta, tuo private network, localhost ja julkinen ip-osoite: ’[’\”10.19.0.7’\”, ’\”127.0.0.1’\”, ’\”134.122.80.89’\”]’.

Kokeilin ensin ratkaista ottamalla ne ’ ’ pois sen ipv4 ympäriltä ja laittaa nollan tilalle kaksi (koska ohjelmointikielessä laskeminen aloitetaan nollasta ja haluan tuon kolmannen ip-osoitteen): {{ grains[ipv4][2] }}

Ei taaskaan onnistunut: [ERROR   ] Rendering exception occurred: Jinja variable ’dict object’ has no attribute ’ipv4.txt’

Palaan askeleissa taaksepäin (eli tilanteeseen, jossa se toimi) ja laitan ’ ’ takaisin paikoilleen. Nyt testiajo onnistui!

Mennään katsomaan /tmp/ipvt -> sinne oli tullut taas uusi tiedosto, jonka nimenä on se julkinen ip-osoite. Jee! Vähäisestä koodausosaamisestani oli siis jotakin hyötyä.

Lopullinen tulos:

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.

Tätä en saanut onnistumaan ja ajatuksena oli palata myöhemmin tekemään se loppuun, mutta en sitten tullutkaan. Sain sen joten kuten tehtyä, ja ratkaisu olisi varmasti löytynyt tarpeeksi googlettelemalla.

Tee ensiksi tehtävälle kansio: $ sudo mkdir -p /srv/salt/motd, jonne teen init.sls tiedoston.

Käytin harjoituksessa tätä https://docs.saltstack.com/en/latest/topics/jinja/index.html apuna sekä tätä https://ownyourbits.com/2017/04/05/customize-your-motd-login-message-in-debian-and-ubuntu/

Tuossa toisessa kerrottiin näin: “/etc/motd – The classic, static file. Does not exist anymore in Ubuntu 16.04 LTS, not even as a symbolic link to /var/run/motd. If it is created, however its contents will be printed too.”

Tuon lihavoidun lauseen perusteella ajattelin, että tämän pitäisi onnistua jos saisin luotua sinne sen motd-hakemiston. Olin kuitenkin muistiinpanoihin kirjoittanut, että ”olen vähän hukassa mitä teen, mutta katsotaan.”

/srv/salt/motd/init.sls: (varmaan väärin)

$ sudoedit /srv/salt/motd/motd.txt: Moikka

Testiajo: sudo salt-call –local state.apply motd. Muistiinpanoistani: ”Täh se onnistui :D”

Katsotaan siis, mitä tapahtuu kun kirjaudun sisään: ei tullut sitä Moikka-tervehdystä sinne.

Menin katsomaan /etc -hakemistoa, jonne oli ilmestnyt /motd ja motd.txt.

Käytin seuraavaksi tätä sivua apunani: https://github.com/philwelz/salt-motd-formula/commit/fde7d6e1369496a6b50e85e26deed08332a9597c

Muokkasin init.sls -tiedostoa ja lisäsin sinne: – replace: True. Testiajo paikallisesti ja kirjaudu sisään. Ei tullut Moikka-tervehdystä.

En myöskään tiennyt, saako siitä motd-viestistä poistettua kaiken salt tilalla vai pitääkö se manuaalisesti tehdä. Luin opettajan ohjeista (http://terokarvinen.com/2018/message-of-the-day-on-ubuntu-sudoedit-etcmotd-chmod-ugo-x-etcupdate-motd-d), josta löysin komennon: $ sudo chmod ugo-x /etc/update-motd.d/*

Sitten ajoin motd:n paikallisesti ja kirjauduin sisään. Nyt ei tullut muuta kuin Last login.

Tämän hetkinen motd:n init.sls:

Tässä vaiheessa olin vähän hakusessa, että mitä pitäisi tehdä. Minulla on se /etc/motd-hakemisto, jossa on se motd.txt tiedosto, mutta se ei tule, kun kirjautuu sisään. Se salt moduuli saa sen luotua sinne, mutta mitään ei tapahdu kirjautuessa, vaikka pitäisi.

Löysin aiemman kurssin opiskelijan harjoituksen https://lahdemi.wordpress.com/2018/04/15/3-viikkotehtava/ jossa oli yksinkertaisempi init.sls, jota matkin:

Taas ajo paikallisesti. (*lisäsin tuohon init.sls ensimmäiselle riville /etc/motd/motd). Kirjauduin sisään, mutta ei taaskaan mitään.

Tässä vaiheessa annoin olla ja siirryin seuraavaan tehtävään. Eli tehtävä jäi osittain tekemättä.

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

Jos ymmärsin tehtävänannon oikein, ensiksi teemme bash-tiedoston. Sitten laitamme sen moduuliin, joka sitten antaa saman bashin orjille? Tai ajaa sen komentona orjille? Katsotaan…

Eli ensiksi luo jokin bash-asetus (käytin apuna sivua https://www.linux.fi/wiki/Bash-skriptaus )

Luo kansio tälle tehtävälle: $ cd /srv/salt, $sudo mkdir -p bash, $ cd /bash

Luo bash: sudoedit eka.sh:

#!/bin/bash echo ”Hei, $(whoami), mitä kuuluu” echo ”Olet hakemistossa $(pwd), tiedostolistaus:” ls

Testaus: $bash eka.sh -> listaa kaiken, mitä sen pitikin.

Seuraavaksi käytin apuna tätä sivua: https://stackoverflow.com/questions/47842414/running-a-bash-script-in-salt-minions

, jossa neuvotaan, miten luodaan bash skripti orjille.

Lopputulos:

Aja paikallisesti: sudo salt-call –local state.apply bash

Ajo onnistui.

Sitten ajetaan se orjalle: $ sudo salt emma state.apply bash

Se näytti saman tekstin kun tuossa kuvassa (mutta orjakoneen tiedoilla).

Sitten kirjauduin orjakoneelle ja ajoin $ bash eka.sh, mutta mitään ei tapahtunut. Sitten tajusin, että tässä vain ajetaan se komento orjalla, mutta sitä ei laiteta sen muistiin.

Tai niin ainakin toivon, että tehtiin, koska en tehnyt mitään muuta.

d) Nginx. Tee nginx-weppipalvelimeen asetuksia Saltilla. Voit esimerkiksi tehdä uuden site:n, niin että etusivu vaihtuu. Kun nginx on todennäköisesti sinulle uusi palvelin, tässä tehtävässä on siis ensin laaja osuus valita sopiva asetus nginx:lle ja saada se toimimaan käsin. Vasta toimivaa, käsin kokeiltua kannattaa automatisoida. Muista lopputuloksen testaus käyttäjän näkökulmasta.

Tässä en tiedä, menikö tämän tehtävän tekeminen oikein. En yhtään tykkää luoda www-palvelimia saltilla. En tykkää niistä muutenkaan. Toivotaan, että tämä jotenkin ainakin onnistui.

Käytin apuna tätä sivua: https://www.digitalocean.com/community/tutorials/how-to-install-nginx-on-ubuntu-18-04

Tein tämän kaiken ensiksi master-koneelle. Asensin nginx:n. Tein palomuuriin reiän (sudo ufw allow ’Nginx HTTP’). Testaa, onnistuiko asennus: $ curl localhost ja $ curl *ip-osoite. Molemmissa näkyin nginx default etusivu.

Sitten luomaan salt moduuli. Tein /srv/salt/nginx -hakemiston. Tein init.sls -tiedoston. Tässä kohtaa en tiennyt, pitääkö moduuliin laittaa jotakin palomuurista, mutta annoin asian olla siksi aikaa.

Päätin kokeilla etusivun asettamisa, kun en sitä apachella ollut harjoitellut. Luo /srv/salt/nginx-hakemistoon default-index.html: Heippa hei

Täällä https://www.digitalocean.com/community/tutorials/saltstack-infrastructure-creating-salt-states-for-nginx-web-servers neuvottiin, miten luodaan salt state nginx:lle, mutta se vaikutti aika hankalata, joten kokeilin helpomman kautta.

init.sls tiedosto:

Moduulin ajo paikallisesti: sudo salt-call –local state.apply nginx

Mielestäni nuo molemmat kansiot ja tiedostot löytyivät, mutta en nyt oikein ymmärrä, miksi se antaa tuollaisen kommentin.

Päätin siirtyä tästä vain eteenpäin.

init.sls tiedosto seuraavaksi:

Testiajo: kaksi noista onnistui, kaksi epäonnistui. Service.running oli toinen ja file.symlink oli toinen:

ID: /etc/nginx/sites-enabled/default Function: file.symlink    Result: False   Comment: The following requisites were not found:                               require:                                   file: /etc/nginx/sites-available/default   Changes:

Mutta kun kokeilin $ curl localhost, sain vastaukseksi Heippa hei:n. Eli se oli onnistunut vaihtamaan sen etusivun.

En nyt tiennyt, miksi se ei löydä niitä. Se target näköjään löytyi, mutta ei tuo require, vaikka se on sama. Hmm… Poistan sen siitä .sls tiedostosta sekä laitan service.running omaksi erilleen.

Ajoin sen ilman tuota require ja nyt onnistui (vain service taas epäonnistui). Otan sen service kohdan pois.

init.sls nyt:

Ajo orjalla seuraavaksi: sudo salt emma state.apply nginx

Ajo onnistui mutkitta, ja kun menin orjakoneelle ja ajoin komennon curl localhost sain vastaukseksi sen Heippa hei:n.

Eli onnistuin kai tehtävän tekemisessä? Ei se ollutkaan niin vaikea kuin ehkä odotin.

Harjoitus on osa kurssia: http://terokarvinen.com/2020/configuration-managment-systems-palvelinten-hallinta-ict4tn022-spring-2020/

b) Modulikimara. Asenna 6 saltin tilaa/modulia.

Tässä siis yksi tila/moduli on esimerkiksi Apachen asennus package-file-service rakenteella. Tiloista/moduleista enintään neljä voi olla muiden tekemiä, esimerkiksi verkosta löytyneitä. 

Muista lähdeviitteet ja lisenssit. 

Käytä tiloja, joita et ole aiemmin käyttänyt ja joita ei ole käsitelty tunnilla. 

Tilojen tulee tehdä muutakin kuin pelkästään asentaa yksittäinen paketti, esimerkiksi tehdä sille asetuksia (siis vaikka package-file, ei pelkkä package). 

Asennettavat ja konfiguroitavat ohjelmat voivat olla mitä vain valitset: palvelimia, graafisen käyttöliittymän ohjelmia, komentorviohjelmia, vapaita, suljettuja… 

Muista testata lopputulos käyttämällä ohjelmaa sen pääasiallisessa käyttötarkoituksessa. Jos jäät jumiin, tee kaikki mitä osaat ja dokumentoi ongelmat, niin ratkotaan niitä yhdessä.

---

Käytin aluksi 1 h 10 min siihen, kun valitsin, mitä ohjelmia alkaisin asentelemaan saltilla. Ongelmana tällaisissa harjoituksissa, joissa itse pitää päättää, mitä ohjelmaa asentaa ja säätää, on juuri sopivien ohjelmien löytäminen. Tämän takia en harjoituksessa tehnyt oikeastaan mitään vaativaa (yhtä moduulia lukuunottamatta). En itse käytä Linuxia, joten en voi edes sen kautta löytää säädettäviä ohjelmia.

Jatkoin harjoitusta seuraavana päivänä, ja käytin sen tekemiseen n. 2 h.

Valitsemani ohjelmat:

• youtube-dl
  • nimensä mukaisesti sillä voi ladata videoita ja audioita youtubesta
• Gimp
  • kuvankäsittelyohjelma
• Firefox
  • webselain
• Audacity
  • äänieditointiohjelma
• Calligra
  • toimisto-ohjelmistopaketti
• ClamAV
  • virustorjuntaohjelma

Loin DigitalOcean:issa uuden palvelimen, jolle tein alkumääritykset sekä josta tein salt orjan.

GIMP

• master$ sudo apt-get install gimp
  • asenna gimp master-koneelle
• master$ cd /etc/gimp/2.0/sessionrc
  • mene johonkin asetukset-hakemistoon
• master$ nano /etc/gimp/2.0/gimprc
  • valitse konfiguraatio-tiedosto

Konfiguraatio-tiedostosta etsi sopiva asetus, jota muokata. Valitsin tässä tapauksessa oletusfontin:

# Specify a default font.  This is a string value. # # (default-font ”Sans”)

• master $ sudo cp gimprc gimp_config
  • kopioi siellä hakemistossa se konfiguraatio-tiedosto
• master $ sudo mv gimp_config /srv/salt
  • siirrä kopioitu tiedosto
• master$ cd /srv/salt
• master$ sudoedit gimp.sls
  • tee moduuli:

Testaa paikallisesti: master$ sudo salt-call –local state.apply gimp –state-output terse

local:   Name: gimp – Function: pkg.installed – Result: Clean Started: – 07:23:50.667025 Duration: 761.313 ms   Name: /etc/gimp/2.0/gimprc – Function: file.managed – Result: Clean Started: – 07:23:51.434677 Duration: 14.306 ms Summary for local ———— Succeeded: 2 Failed: 0 ———— Total states run: 2 Total run time: 775.619 ms

En ollut vielä tehnyt muutoksia gimp_config-tiedostoon, joten teen sinne nyt sen oletusfontin vaihdon. Laitan siihen Sans:in tiallle Serif ja poistan # rivien edestä, jotta ne tulevat voimaan.

Taas ajo paikallisesti:

local:   Name: gimp – Function: pkg.installed – Result: Clean Started: – 07:27:12.254506 Duration: 679.719 ms   Name: /etc/gimp/2.0/gimprc – Function: file.managed – Result: Changed Started: – 07:27:12.939139 Duration: 23.127 ms Summary for local ———— Succeeded: 2 (changed=1) Failed: 0 ———— Total states run: 2 Total run time: 702.846 ms

Ei ollut yllätys, että ajo onnistui. Asetus ei ollut mitenkään erityinen eikä moduulissa ollut mitään erikoista.

Sitten moduulin ajo orjalle: master $ sudo salt emma state.apply gimp (emma on orjan ID)

ID: /etc/gimp/2.0/gimprc Function: file.managed    Result: True   Comment: File /etc/gimp/2.0/gimprc updated   Started: 07:29:04.539730 Duration: 43.855 ms   Changes:               ———-            diff:                —                +++                @@ -170,7 +170,7 @@                                  # Specify a default font.  This is a string value.                 #                -# (default-font ”Sans”)                +(default-font ”Serif”)                                # When enabled, the selected brush will be used for all tools.  Possible                 # values are yes and no. Summary for emma ———— Succeeded: 2 (changed=2) Failed: 0 ———— Total states run: 2 Total run time:  36.069 s

---

Audacity

Alkujutut ovat melko samat kuin gimp:in kohdalla.

• master$ cd /usr/share/audacity
• master$ nano EQDefaultCurves.xml

Tuota .xml tiedostosta muutan vain joitakin otsikoiden nimiä. (En oikeasti löytänyt parempia ohjelmia, joita säädellä)

Ajo paikallisesti: sudo salt-call –local state.apply audacity –state-output terse

Aluksi ihmettelin tällaista tulosta, kun siinä oli se : sen file.managed jälkeen.

Tässä nyt jälkikäteen on hankala miettiä, että miten tämän onnistuin ratkaista ja mitä ihmettä muistiinpanoni kertovat:

”hahaa se oli siinä alussa sen .xml lopusa puuttui :DDDD siihen lisäsin sitten ajo onnistui paikallisesti”

Ja nyt tuon tuohon kopsattuani tajusin, mikä oli pielessä. Sen .xml jälkeen puuttui ”:”. Eli olin sen lisännyt siihen.

Sitten ajo orjalle (master$ sudo salt emma state.apply audacity), mikä onnistui ongelmitta.

---

Calligra

Alkujutut taas samat kuin Gimpillä.

• master$ cd /usr/share/calligra/autocorrect
• master$ nano autocorrect.xml

Kopioi tiedosto, siirrä se /srv/salt -hakemistoon. Tee calligra.sls ja muokkaa calligra_config-tiedostoa (lisäsin että (e) muutetaan €:ksi).

Ajo paikallisesti: sudo salt-call –local state.apply calligra –state-output terse

Sitten orjalle: sudo salt emma state.apply calligra. Sen Calligran asentaminen kesti muutaman minuutin, mutta lopulta se onnistui.

ID: /usr/share/calligra/autocorrect/autocorrect.xml Function: file.managed    Result: True   Comment: File /usr/share/calligra/autocorrect/autocorrect.xml updated   Started: 08:13:30.787976 Duration: 41.186 ms   Changes:               ———-            diff:                —                +++                @@ -6,6 +6,7 @@                   <item find=”(c)” replace=”©” />                   <item find=”(r)” replace=”®” />                   <item find=”–” replace=”—” />                +  <item find=”(e)” replace=”€” />                  </items>                  <SuperScript>                   <superscript find=”1st” super=”st” />

---

clamAV

Alkujutut sama kuin Gimp:illä.

Muokattava asetustiedosto:

• /etc/clamav/clamd.conf

Kopioi se, siirrä /srv/salt -hakemistoon. Luo clamav.sls moduuli, muuta clam_config tiedostossa jokin asetus (ScanMail true -> ScanMail false)

Katsotaan onnistuuko. Ajetaan se paikallisesti: master$ sudo salt-call –local state.apply clamav –state-output terse

Kaksi asiaa epäonnistuivat. Clamav ja clamav-daemon täytyy olla erikseen (tätä mietin aluksi, että voiko kahta ohjelmaa asentaa yhdessä pkg.installed kohdassa, muttei näköjään). Toiseksi laitan clamav service.running:ille eri nimen -> clamav1 (luulin tämän olevan oikea ratkaisu).

Ajo uudestaan. Muut onnistuivat, mutta yksi kohta epäonnistui. Se oli tuo service.running:

[ERROR   ] The named service clamav1 is not available Name: clamav1 – Function: service.running – Result: Failed Started: – 08:26:49.734074 Duration: 29.397 ms

Clamav ei taida olla sellainen koko aika pyörivä ohjelma. Se menee kai päälle vain, kun sitä ajetaan, joten poistan tuon servivce.running -kohdan .sls tiedostosta.

Lopullinen clamav.sls:

Ei kuin vain orjalle: master$ sudo salt emma state.apply clamav

Muut onnistuivat, mutta clamav-daemonin kanssa oli ongelma:

ID: clamav-daemon Function: pkg.installed    Result: False   Comment: Problem encountered installing package(s). Additional info follows:                        errors:                – Running scope as unit: run-r91dfbb62e60041b0a2c078443b8e6a96.scope                  FATAL -> Failed to fork.   Started: 08:30:06.369564 Duration: 11771.529 ms   Changes:

Ei yhtään hajua, mikä on ongelmana. Jätin sen sikseen ja ajattelin käydä sitä läpi opettajan kanssa.

---

Firefox

Alkujutut samat kuin gimpillä ja muilla.

Muokattava tiedosto:

• /etc/firefox/syspref.js

jonne laitan oletuskotisivuksi googlen: pref(”browser.startup.homepage”, ”http://www.google.com/”);

Kopioi tuo tiedosto, siirrä /srv/salt. Tee firefox.sls tiedosto ja muokkaa firefox_config tiedostoa.

Aja paikallisesti. Oli taas syntaksivirhe, ( : puuttui). Lisää se, aja uudestaan. Onnistui.

Lopullinen .sls moduuli:

Ajo orjalla: master$ sudo salt emma state.apply firefox. Se onnistui.

---

Youtube-dl

Tässä moduuliaa pääsi vähän tekemään muutakin kuin samaa vanhaa asennusta ja yhden asetuksen muuttamista.

Alkujutut samat kuin Gimpillä ja co.

Mutta nyt pitää itse luoda hakemistot:

• master $ cd /etc
• master $ sudo mkdir youtube-dl
• master $ sudoedit youtube-dl.conf
  • –extract-audio –no-mtime

Tuo viimeisen rivin löysin internetistä esimerkkinä youtube-dl asetuksesta. Katsotaan onnistuuko tämä.

Mene /srv/salt. Luo youtube.sls. Mutta nyt en tiedä, tuleeko se /etc/youtube-dl/youtube-dl.conf tiedosto automaattisesti orjalle, kun se luotiin itse. Katsotaan miten käy.

Ajo paikallisesti: master $ sudo salt-call –local state.apply youtube –state-output terse. Ajo onnistui.

Ajo orjalla: master $ sudo salt emma state.apply youtube. Ei onnistunut.

ID: /etc/youtube-dl/youtube-dl.conf Function: file.managed    Result: False   Comment: Parent directory not present   Started: 08:58:27.159752 Duration: 42.48 ms   Changes:

Aluksi ajattelin jättää asian tähän ja ratkaista ongelman opettajan kanssa, mutta sitten googlettelin ja löysin neuvoa sivulta: https://docs.saltstack.com/en/latest/ref/states/all/salt.states.file.html

Siellä kerrotaan, miten directory luodaan. En ollut varma, tuleeko tiedosto myös sinne. Päätin kokeilla ja katsoa mitä käy.

Lopullinen .sls moduuli:

Tuo keskimmäinen luo sen hakemiston, josta seuraava kohta sitten hakee tuon _config-tiedoston (jonka pitäisi sinne hakemistoon jotenkin mennä).

Ajo orjalla. Kommentti muistiinpanoistani:

”nyt onnistui!!! mitä ihmettä :D”

ID: create_config_dir Function: file.directory      Name: /etc/youtube-dl    Result: True   Comment: Directory /etc/youtube-dl updated   Started: 09:04:50.348565 Duration: 1.089 ms   Changes:               ———-            /etc/youtube-dl:                New Dir ———-        ID: /etc/youtube-dl/youtube-dl.conf Function: file.managed    Result: True   Comment: File /etc/youtube-dl/youtube-dl.conf updated   Started: 09:04:50.349750 Duration: 17.624 ms   Changes:               ———-            diff:                New file            mode:                0644

Menen paikallisesti katsomaan, mitä orjakoneessa on.

Sinne oli ilmestnyt se /etc/youtube-dl -hakemisto, johon oli ilmestynyt se youtube-dl.conf -tiedosto.

Tämä oli muistiinpanojen perusteella onnenhetki:

”hahahahaaaaa mitä ihmettä se onnistui :DDDDDD”

---

Kuva 1:

Kuva 2:

Kuva 3:

Kuva 4:

H2 Package-File-Service

Harjoitus on osa kurssia Palvelinten hallinta (http://terokarvinen.com/2020/configuration-managment-systems-palvelinten-hallinta-ict4tn022-spring-2020/)

Aloitin harjoituksen tekemisen klo. 9.50 ja lopetin klo. 11.00. Harjoitus ei ollut lopulta niin vaikea, kun aluksi pelkäsin. Ongelmana oli enemmänkin se, minkä sopivan ja kohtalaisen helpon säädettävän ohjelman valitsisin harjoituksiin.

a) Demonin asetukset. Säädä jokin demoni (asenna+tee asetukset+testaa) package-file-service -rakenteella. Tunnilla muutettiin ssh:n porttinumeroa, joten tee jotain muuta.

Yritin tehdä tätä tehtävää heti tunnin jälkeen, mutten onnistunut, kun en keksinyt mitä ohjelmaa yrittäisin säätää. Tein harjoituksen omille virtuaalipalvelimilleni (jotka ovat DigitalOceanissa ja joita olen jo aiemmin Linux- ja tällä kurssilla käyttänyt). Käytin yli 20 minuuttia googlettamiseen, kunnes lopulta laitoin pillit pussiin ja lähetin opettajalle viestiä. Opettaja ehdotti, että voisin säätää jotakin toista SSH:n ominaisuutta kuin porttinumeroa (kuten UserAllowed ja GroupsAllowed). Päätin tehdä juuri näin.

Päivän agendalla on siis: 1) tee käyttäjiä, jotka lisään uuteen ryhmään ja 2) luo sinne /srv/salt -hakemistoon ne tarvittavat tiedostot.

Ohjeina käytin opettajan neuvoja: http://terokarvinen.com/2018/pkg-file-service-control-daemons-with-salt-change-ssh-server-port

Alkutoimena testaan, että master-slave-arkkitehtuuri toimii kahdella virtuaalipalvelimellani:

• master$: sudo salt ’*’ cmd.run ’whoami’
  • slave1:
  • root

eli orja kone vastaa.

Ennen kuin yritän muokata, ketkä pääsevät kirjautumaan koneelle, testaan onnistuuko tuo porttinumeron muuttaminen. Koska, jos se onnistuu, silloin onnistuu myös tuo sisäänpääsijöiden muokkaaminen.

Master$:

• cd /srv/salt
• sudoedit sshd.sls
  • openssh-server:
  •  pkg.installed
  • /etc/ssh/sshd_config:
  •  file.managed:
  •    – source: salt://sshd_config
  • sshd:
  •  service.running:
  •    – watch:
  •      – file: /etc/ssh/sshd_config

• sudoedit sshd_config:

Port 8888
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
UsePrivilegeSeparation yes
KeyRegenerationInterval 3600
ServerKeyBits 1024
SyslogFacility AUTH
LogLevel INFO
LoginGraceTime 120
PermitRootLogin prohibit-password
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
IgnoreRhosts yes
RhostsRSAAuthentication no
HostbasedAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
UsePAM yes

• sudo salt ’*’ state.apply sshd

Testaus: kirjaudu ulos slave-koneelta ja yritä kirjautua uudestaan sisään: vastauksena tulee port 22: connection refused. Eli portin muuttaminen onnistui.

Yritin testata kirjautua sisään ”ssh käyttäjä@ip-osoite -p 8888”, mutta mitään ei tapahtunut. Se pyöri siinä ja yritti kirjautua sisään. Pysäytin sen ctrl + c:llä.

Menin takaisin muokkaamaan sitä sshd_config tiedostoa ja muutin portin 22:ksi. Sitten state.apply:ta masterilla ja uudestaan testaamaan sisäänkirjautumista orjalla. Kirjautuminen onnistui nyt normaaliin tapaan.

Nyt varsinaiseen tehtävään: sisäänkirjautujoiden hallintaan.

Ensiksi luon paikallisesti orjakoneella käyttäjän ja liitän sen uuteen ryhmään. (sudo adduser ”username” ja sudo usermod -a -G testi ”username”). Tarkistin vielä, että käyttäjät ovat ryhmässä (vaihda käyttäjää ja kirjoita groups). Testaan vielä, että käyttäjällä pystyy kirjautumaan sisään (onnistui).

(käytin apuna tätä: https://www.ostechnix.com/allow-deny-ssh-access-particular-user-group-linux/)

master-koneella muokkaan sshd_config tiedostoa ja kirjoitin loppuun DenyGroups testi. Sitten state.apply:ta.

Testaus: kirjaudu sisään uudella käyttäjällä. Se pyysi salasanaa, mutta annettuani sen se sanoi, että Permission denied, please try again.

eli sekin onnistui!

(yllä master ja alla slave)

---

---

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.

Tämänkin kanssa oli aluksi vaikeuksia, kun piti keksiä joku ohjelma, jonka voisi asentaa ja jonka asetuksia voisi helposti muokata. Lopulta päädyin Neofetch-ohjelmaan. Se kertoo erilaisia tietoja käyttäjän tietokoneesta. Ajattelin tehdä niin, että muokkaan sitä, missä järjestyksessä se näyttää tietoa, minkä tekeminen on luultavasti helppoa.

Agenda tälle tehtävälle: 1) asenna ja säädä se ensiksi master-koneella ja 2) testaa sitä orjakoneella.

Asensin sen masterille:

(käytin apuna tätä ohjetta: https://github.com/dylanaraps/neofetch/wiki/Customizing-Info)

Seuraavaksi etsi ohjelman asetukset: $ cd /etc/neofetch/conf. Kokeilin nyt muokata sitä tiedostoa ja katsoa tuleeko mitään muutoksia tuohon lopputulokseen. Siirsin OS:n ja Host:in paikkaa. Testasin komennolla $ neofetch, mutta ne eivät olleet vaihtaneet paikkaa. Tässä vaiheessa olin vähän hämilläni ja hetken vianmäärityksen (eli googlettamisen) jälkeen kokeilin komentoa $ neofetch –config none, jolla se onnistui. (tuo komento löytyy tuosta linkittämästäni ohjeesta, mutten ollut lukenut sitä näköjään tarpeeksi hyvin)

[tästä minulla ei ole kuvaa, mutta OS ja Host olivat vaihtaneet paikkaa]

Seuraavaksi alan luomaan sitä .sls tiedostoa ja muokattua asetukset-tiedostoa.

Master:

• $ cd /srv/salt
• $ sudoedit neofetch.sls:
  • neofetch:
  •   pkg.installed
  • /etc/neofetch/config.conf:
  •  file.managed:
  • – source: salt://neofetch_config
  • neof:
  •  service.running:
  • – watch:
  • – file: /etc/neofetch/config.conf

• sudoedit neofetch_config
  • print_info() {
  • info title
  • info underline
  • info ”Peppu” model
  • info ”Pylly” distro

Nuo _config-tiedoston asetukset ovat sen oikean asetustiedoston 7 ensimmäistä riviä, joissa olen siirtänyt distron ja modelin paikkaa sekä nimennyt ne uudestaan.

Sitten testaus. Luulen, ettei se onnistu, mutta toivon parasta. Masterilla state.applytä, joka antaa kaksi vihreätä ja yhden punaisen. Se service.running on turha tuolla .sls tiedostossa, koska neofetch ei pyöri siellä kokoaikaisesti *duh* eli sen voi ottaa sieltä pois.

Sitten komento $ sudo salt ’*’ cmd.run ’neofetch –config none’:

Seuraava on ote muistiinpanoistani:

• luulen että ongelma on se, että se korvaava file niin siinä on vain muutama line; pitäiskö olla kaikki? 
  • joo täytyy
  • ei kuin vain lisäämään 😀

Eli kopion sen neofetchin config tiedoston ja siirsin sen tuonne /srv/salt hakemistoon. Poistin sen aiemman ja nimesin sen uuden tiedoston siihen _config-tiedostoksi. Nuo aiemmat muutokset olivat edelleen siellä,joten muuta ei tarvinnut tehdä. Sitten state-apply:ta (jotta muutokset tulisivat voimaan orja-koneella) ja cmd.run:ia kehiin.

Se onnistui, mutta samanlainen muotoilu ei tullut masterkoneelle. Siellä lukee nyt vähän eri muodossa halutut tiedot, mutta muokattuina kuitenkin.

En tiennyt, oko se muotoilun puutos joku virhe vai toimiiko se nyt niin kuin pitäisi. Käyn vielä katsomassa paikallisesti, miten muotoilu menee slave-koneella. Siellä tuli se oikea muotoilu, joten tämä on varmaan joku salt:n asetus, että se ei näytä niitä muotoiluja.

Tässä vielä kuvakaappaus samasta kuin ylempi, mutta orjakoneella:

---

---

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

En tiedä, teinkö tämän tehtävän oikein. Jotakin komentoja ajoin ja debug-tietoa tuli.

Master:

• sudo salt-call –local state.apply neofetch –state-output terse:

Tällä komennolla ajoin tuon kai paikallisesti (?) ja se onnistui. En tajunnut kokeilla sitä niin, että tekisin virheen .sls tiedostoon ja katsoisin mitä sitten tapahtuisi.

Löysin googlettamalla erilaisia debug-komentoja, joista kokeilin yhtä orjalkoneelle.

Slave:

• sudo salt-call -l debug state.apply

Tämä antoi pitkän tulosteen, jossa kerrottiin kaikkea mitä se teki ja tutki. Seuraavaksi kooste analyysistäni:

• se lukee configuration tiedostoa /etc/salt/minion
• yhdistää masteriin
  • Initializing new AsyncAuth for (’/var/lib/salt/pki/minion’, ’slave1’, ’tcp://134.122.80.89:4506’)
• sitten se tekee jotakin muutoksia ym. ja uudestaan yhdistää masteriin samasta portista
  • esim. lataa minion key, determine pillar cache
• LazyLoaded 
  • jinja.render, yaml.render
• aina, kun tekee jotakin, ottaa lopuksi yhteyden taas masteriin
• tekee paljon juttuja base:n ympärillä
• luo hakemistoja moduuleille ja cacheille
• Rendered data from file: /var/cache/salt/minion/files/base/hello.sls:
  • sitten sen tiedoston tiedot lueteltuna
• SSH-ohjelman salt-tiedostoa ajaa:
  • [INFO ] Running state [ssh.service] at time 07:54:22.494660
  • [INFO ] Executing state service.running for [ssh.service]
  • [INFO ] Executing command [’systemctl’, ’status’, ’ssh.service’, ’-n’, ’0’] in directory ’/home/emma’
  • [DEBUG   ] stdout: * ssh.service – OpenBSD Secure Shell server
  •    Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
  •    Active: active (running) since Mon 2020-04-13 06:29:27 UTC; 1h 24min ago
  •   Process: 3903 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
  •  Main PID: 3904 (sshd)
  • Tasks: 1 (limit: 1152)
  •    CGroup: /system.slice/ssh.service
  •         `-3904 /usr/sbin/sshd -D
• lisää ssh:n ajoa:
  • [INFO ] Executing command [’systemctl’, ’is-active’, ’ssh.service’] in directory ’/home/emma’
  • [DEBUG   ] output: active

---

Lopuksi:

Tehtävät eivät olleetkaan niin kamalia kuin aluksi ajattelin. Ensimmäisen tehtävän kohdalla olin jo valmis lopettamaan koko kurssin, kun ajattelin, etten osaa mitään tai ymmärrä mitään mistään. Lopulta sain tehtävän tehtyä ja ymmärrän nyt salt:in peruskäyttöä niiden .sls ja _config -tiedostojen luomisen osalta.

Palvelinten hallinta kurssi – harjoitus 1

Harjoitus on osa kurssia Palvelinten hallinta (http://terokarvinen.com/2020/configuration-managment-systems-palvelinten-hallinta-ict4tn022-spring-2020/)

h1 Hei maailma, verkon yli ja idempotenssi.

Tein harjoituksen virtuaalipalvelimelle, jotka loin DigitalOceaniin (toinen oli jo olemassa Linux-kurssin jäljiltä).

Aloitin harjoituksen tekemisen n. 16.15 ja lopetin klo 17.35.

a) Asenna Salt ja siihen uusi orja. Voit tehdä ne esimerkiksi uudelle virtuaalikoneelle, niin pääset kokeilemaan puhtaalta pöydältä.

Käytin tätä sivua apuna: http://terokarvinen.com/2018/salt-quickstart-salt-stack-master-and-slave-on-ubuntu-linux

Loin ensin DigitalOceaniin uuden Linux-palvelimen, josta teen masterin. Aiemmalla Linux-kurssilla tehdystä palvelimesta teen sen slaven.

Seuraavat vaiheet tein vuorotellen aina, kun niiden vuoro oli:

Master:

• sudo apt-get -y install salt-master
• sudo ufw allow 4505/tcp
• sudo ufw allow 4506/tcp
• sudo salt-key -A
  • unaccepted keys: slave1
  • proceed? [n/Y]
  • y
  • key for minion slave1 accepted
• sudo salt ’*’ cmd.run ’whoami’
  • slave1:
    • root

Slave

• sudo apt-get -y install salt-minion
• sudoedit /etc/salt/minion
  • master: 134.122.80.89
  • id: slave1
• sudo systemctl restart salt-minion.service

Nyt on molemmissa koneissa asennettuna Salt sekä molemilla niiden oma rooli. ’whoami’ testasi, että slave1 on tuo toinen kone.

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

Ohje: http://terokarvinen.com/2018/salt-states-i-want-my-computers-like-this

Master:

• sudo mkdir -p /srv/salt/
• sudoedit /srv/salt/hello.sls
  • /tmp/hellotero.txt:
  •   file.managed:
  •     – source: salt://hellotero.txt
• sudoedit /srv/salt/hellotero.txt
  • See you at http://TeroKarvinen.com
• sudo salt ’*’ state.apply hello

Tulos:

slave1: ———-        ID: /tmp/hellotero.txt Function: file.managed    Result: True   Comment: File /tmp/hellotero.txt updated   Started: 13:57:37.672878 Duration: 41.099 ms   Changes:               ———-            diff:                New file            mode:                0644 Summary for slave1 ———— Succeeded: 1 (changed=1) Failed: 0 ———— Total states run: 1 Total run time:  41.099 ms

Eli tiedoston ajaminen slave1-koneella onnistui.

Seuraava vaihe tekee niin, että kaikki orja-koneet tekevät tämän komennon: (minulla on nyt vain yksi, joten tästä ei nyt ole niin hyötyä)

• sudoedit /srv/salt/top.sls
  • base:
  •   ’*’:
  •     – hello

Jos en halua odottaa puolta tuntia, jolloin tuo ylempi tulee toimintaan, sen voi laittaa toimimaan heti:

• sudo salt ’*’ state.highstate

Tuloksena onnistunut ajo:

slave1: ———-        ID: /tmp/hellotero.txt Function: file.managed    Result: True   Comment: File /tmp/hellotero.txt is in the correct state   Started: 13:59:37.993508 Duration: 43.517 ms   Changes:    Summary for slave1 ———— Succeeded: 1 Failed: 0 ———— Total states run: 1 Total run time:  43.517 ms

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

(lähde: https://docs.saltstack.com/en/latest/topics/grains/)

”Salt comes with an interface to derive information about the underlying system. This is called the grains interface, because it presents salt with grains of information. Grains are collected for the operating system, domain name, IP address, kernel, OS type, memory, and many other system properties.”

Selvitä slave1:n IP-osoite:

• sudo salt slave1 cmd.run ’hostname -I’
  • slave1:
    • 139.59.154.219 10.19.0.6

Erilaisia teknisiä tietoja slave1:stä:

• sudo salt slave1 grains.items

slave1: ———- pythonexecutable:      /usr/bin/python3 pythonpath:      – /usr/bin      – /usr/lib/python36.zip      – /usr/lib/python3.6SSDs: biosreleasedate:      12/12/2017 biosversion:      20171212 cpu_flags:    [poistettu] cpu_model:      Intel(R) Xeon(R) CPU E5-2650L v3 @ 1.80GHz cpuarch:      x86_64 disks:   [poistettu] dns:      ———-      domain:      ip4_nameservers:          – 127.0.0.53      ip6_nameservers:      nameservers:          – 127.0.0.53      options:          – edns0      search:      sortlist: domain: fqdn: [fully qualified domain name]      harj4 fqdn_ip4:      – 127.0.1.1 fqdn_ip6: gid:      0 gpus:      |_        ———-        model:            QXL paravirtual graphic card        vendor:            unknown groupname:      root host:      harj4 hwaddr_interfaces:      ———-      eth0:          f2:d9:90:b5:3c:7c      lo:          00:00:00:00:00:00 id:      slave1 init:      systemd ip4_interfaces:      ———-      eth0:          – 139.59.154.219          – 10.19.0.6      lo:          – 127.0.0.1 ip6_interfaces:      ———-      eth0:          – fe80::f0d9:90ff:feb5:3c7c      lo:          – ::1 ip_interfaces:      ———-      eth0:          – 139.59.154.219          – 10.19.0.6          – fe80::f0d9:90ff:feb5:3c7c      lo:          – 127.0.0.1          – ::1 ipv4:      – 10.19.0.6      – 127.0.0.1      – 139.59.154.219 ipv6:      – ::1      – fe80::f0d9:90ff:feb5:3c7c kernel:      Linux kernelrelease:      4.15.0-66-generic locale_info:      ———-      defaultencoding:          UTF-8      defaultlanguage:          en_US      detectedencoding:          UTF-8 localhost:      harj4 lsb_distrib_codename:      bionic lsb_distrib_description:      Ubuntu 18.04.3 LTS lsb_distrib_id:      Ubuntu lsb_distrib_release:      18.04 machine_id:      bee8ddc9d0804e818dcfdb9c122ecf62 manufacturer:      DigitalOcean master:      134.122.80.89 mdadm: mem_total:      985 nodename:      harj4 num_cpus:      1 num_gpus:      1 os:      Ubuntu os_family:      Debian osarch:      amd64 oscodename:      bionic osfinger:      Ubuntu-18.04 osfullname:      Ubuntu osmajorrelease:      18 osrelease:      18.04 osrelease_info:      – 18      – 4 path:      /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin pid:      4648 productname:      Droplet ps:      ps -efHww      – /usr/lib/python3.6/lib-dynload      – /usr/local/lib/python3.6/dist-packages      – /usr/lib/python3/dist-packages pythonversion:      – 3      – 6      – 8      – final      – 0 saltpath:      /usr/lib/python3/dist-packages/salt saltversion:      2017.7.4 saltversioninfo:      – 2017      – 7      – 4      – 0 serialnumber:      181796589 server_id:      317551988 shell:      /bin/sh systemd:      ———-      features:          +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid      version:          237 uid:      0 username:      root uuid:      bee8ddc9-d080-4e81-8dcf-db9c122ecf62 virtual:      kvm zmqversion:      4.2.5

Komennolla sai esiin paljon tietoa virtuaalikoneesta.

Selvitä, mikä hypervisor pyörii tällä noodilla:

• sudo salt slave1 grains.item virtual
  • slave1:
• ———-
• virtual:
• kvm’

(KVM = Kernel-based Virtual Machine)

e) Kokeile jotain toista tilaa kuin file.managed. Tärkeitä ovat pkg.installed, file.managed, service.running, file.symlink, user.present, group.present. Ohjeita saa esim ’sudo salt kissa sys.state_doc pkg.installed|less’

Neuvoja sain:

• https://docs.saltstack.com/en/latest/ref/states/all/salt.states.group.html
• https://docs.saltstack.com/en/latest/ref/states/all/salt.states.file.html
• https://docs.saltstack.com/en/getstarted/config/functions.html

Lisäsin tällaista siihen b:ssä tekemääni hello.sls tiedostoon:

Testaus:

• sudo salt ’*’ state.apply hello

Tulos:

slave1: ———-        ID: /tmp/hellotero.txt Function: file.managed    Result: True   Comment: File /tmp/hellotero.txt is in the correct state   Started: 14:25:36.263197 Duration: 29.147 ms   Changes:    ———-        ID: pinta Function: pkg.installed    Result: True   Comment: The following packages were installed/updated: pinta   Started: 14:25:40.534437 Duration: 46137.546 ms   Changes:               ———-           [poistettu] ———-        ID: /tmp/moi.txt Function: file.managed    Result: True   Comment: File /tmp/moi.txt updated   Started: 14:26:26.681403 Duration: 35.177 ms   Changes:               ———-            diff:                New file            mode:                0644 ———-        ID: ssh.service Function: service.running    Result: True   Comment: The service ssh.service is already running   Started: 14:26:28.071702 Duration: 42.664 ms   Changes:    ———-        ID: user account for pete Function: user.present      Name: pete    Result: True   Comment: New user pete created   Started: 14:26:28.117322 Duration: 72.968 ms   Changes:               ———-            fullname:            gid:                1002            groups:                – pete                – sudo            home:                /home/pete            homephone:            name:                pete            passwd:                x            roomnumber:            shell:                /bin/bash            uid:                1002            workphone: ———-        ID: group cheese Function: group.present    Result: False   Comment: Failed to create new group group cheese   Started: 14:26:28.192096 Duration: 13.888 ms   Changes:    Summary for slave1 ———— Succeeded: 5 (changed=3) Failed: 1 ———— Total states run: 6 Total run time:  46.331 s ERROR: Minions returned with non-zero exit code

Positin tuolta tuon pintan asennuksen.

Group failed, koska sitä ei näköjään ole olmassa? Lisäsin sen cheese ryhmän siihen adduser alle, missä luodaan se sudo ryhmä, johon käyttäjä liitetään.

Testaus:

slave1: ———-        ID: /tmp/hellotero.txt Function: file.managed    Result: True   Comment: File /tmp/hellotero.txt is in the correct state   Started: 14:30:42.816061 Duration: 33.407 ms   Changes:    ———-        ID: /tmp/moi.txt Function: file.managed    Result: True   Comment: File /tmp/moi.txt is in the correct state   Started: 14:30:42.849707 Duration: 11.72 ms   Changes:    ———-        ID: ssh.service Function: service.running    Result: True   Comment: The service ssh.service is already running   Started: 14:30:44.097251 Duration: 53.756 ms   Changes:    ———-        ID: user account for pete Function: user.present      Name: pete    Result: False   Comment: The following group(s) are not present: cheese   Started: 14:30:44.153433 Duration: 4.027 ms   Changes:    ———-        ID: group cheese Function: group.present    Result: False   Comment: Failed to create new group group cheese   Started: 14:30:44.158356 Duration: 11.857 ms   Changes:    Summary for slave1 ———— Succeeded: 3 Failed: 2 ———— Total states run: 5 Total run time: 114.767 ms ERROR: Minions returned with non-zero exit code

Edelleen failed. Näköjään ryhmien pitää olla jo valmiina. Niitä ei voi luoda tällä tavalla.

Poistin hello.sls-tiedostosta tuon cheese ryhmän.

Testaus:

• sudo salt ’*’  state.apply hello

slave1: ———-        ID: /tmp/hellotero.txt Function: file.managed    Result: True   Comment: File /tmp/hellotero.txt is in the correct state   Started: 14:31:57.088298 Duration: 26.571 ms   Changes:    ———-        ID: /tmp/moi.txt Function: file.managed    Result: True   Comment: File /tmp/moi.txt is in the correct state   Started: 14:31:57.115059 Duration: 11.86 ms   Changes:    ———-        ID: ssh.service Function: service.running    Result: True   Comment: The service ssh.service is already running   Started: 14:31:58.295491 Duration: 48.768 ms   Changes:    ———-        ID: user account for pete Function: user.present      Name: pete    Result: True   Comment: User pete is present and up to date   Started: 14:31:58.346374 Duration: 4.293 ms   Changes:    Summary for slave1 ———— Succeeded: 4 Failed: 0 ———— Total states run: 4 Total run time:  91.492 ms

Nyt tuli pelkkää vihreätä!

Kävin vielä tarkistamassa, mitä slave1 sanoo:

• less /etc/passwd
  • pete:x:1002:1002::/home/pete:/bin/bash

• cd /tmp
  • ls
  • (siellä ne kaksi teksti tiedostoa ovat:) hellotero.txt ja moi.txt

f) Vapaaehtoinen: Laita Salt Master palvelimelle, joka näkyy Internetiin. Silloin orjat saavat siihen yhteyden tulimuurin läpi, ei-julkisista (NAT) osoitteista ja vaikkapa virtuaalikoneista.

Tein jo!

Prosessinhallintaa ja lokeja

Aloitin harjoituksen tekemisen n. kello 6.35 / 8.35 ja lopetin n. 7.45 / 9.45.

Harjoitus on osa kurssia http://terokarvinen.com/2020/linux-palvelimet-2020-alkukevat-kurssi-ict4tn021-3010/

Tein harjoituksen omalle palvelimelleni, jolle olin jo aiemmin asentanut sysstatin. Valitettavasti en laittanut ohjelmaa ottamaan historiaa ylös, joten en voi jälkikäteen katsella kuormitustietoja. Tein kuitenkin harjoitusten aikana siinä kyseisen komennon kohdalla kuormitustestauksia.

a) Asenna kuormitusohjelma: sysstat

Komennolla $ mpstat -V näki, oliko sysstat asennettuna. Komennolla $ sar -u -o sarfile 2 5, sar luo sarfile tiedoston siihen hakemistoon, jossa nyt olen. ’-u’ kertoo tietoa CPU:sta 2 sekunnin välein ja 5 raporttia.

---

b) Kuormita järjestelmän eri osa-alueita.

Käytin tässä stress-ohjelmaa. (ohjeet: https://www.tecmint.com/sysstat-commands-to-monitor-linux/)

• $ stress -c 2 -i 1 -m 1
  • ”-c 2 : Spawn two workers spinning on sqrt()
  • -i 1 : Spawn one worker spinning on sync()
  • -m 1 : Spawn one worker spinning on malloc()/free()”
  • (en laittanut komentoa pysätyksylle, joten se pyöri siinä muutaman minuutin, kunnes painoin ctrl + C)
• stress: info: [5196] dispatching hogs: 2 cpu, 1 io, 1 vm, 0 hdd

Avasin toisen päätteen, jotta näkisin, mitä sar sanoo:

(http://sebastien.godard.pagesperso-orange.fr/man_sar.html)

• %user 
  • percentage of CPU utilization that occurred while executing at the user level (application)
• %system
  • percentage of CPU utilization that occurred while executing at the system level (kernel). Note that this field includes time spent servicing hardware and software interrupts
• %steal
  • percentage of time spent in involuntary wait by the virtual CPU or CPUs while the hypervisor was servicing another virtual processor.
• %idle
  • percentage of time that the CPU or CPUs were idle and the system did not have an outstanding disk I/O request

Eli, mitä se kertoo, on, että User ja System jakoivat CPU:n käytön keskenään stress-testin aikana.

Seuraavaksi katsotaan, mitä ”uptime” komento sanoo (heti stress-ohjelman asennuksen jälkeen ja stress-komennon ajon jälkeen):

Huomaa, että load average on suurempi ajon jälkeen (alempana kohdassa g) analysoin tätä enemmän).

Katsotaan vielä, mitä sar sanoo, kun stress ei pyöri enää (verrattavissa sar kun stress pyörii ja kun se ei pyöri):

Huomaa heti, että CPU on idle eli ei tee mitään.

---

c) iotop

(lähde: https://www.globo.tech/learning-center/install-iotop-ubuntu-16/ )

“It monitors what input or output is currently happening on your machine, helping you to quickly identify problematic issues of disk usage”

Asensin iotopin ja laitoin sen pyörimään, samalla kun laitoin stress-komennon pyörimään (kuvan oikeassa alakulmassa näkyy komento):

COMMAND-kohdassa näkyy, mitä komentoa cpu suorittaa. Siellä näkyy tuo ”stress”-komento. IO> kertoo koko IO-käytön.

---

d) dstat

(lähde: https://hostpresto.com/community/tutorials/how-to-install-and-use-dstat-on-ubuntu-16-04/ )

”Dstat is one of the most powerful and flexible utilities for generating and monitoring Linux resource statistics. You can easily view your system resources instantly using dstat.”

Asensin dstatin ja ajoin komennon $ dstat:

Tiedoista huomaa, että cpu on toimeton, network eli verkko lähettää ja ottaa vastaan tietoja (minulla oli monta välilehteä avoinna), ja että disk lukee ja kirjoittaa tietoja välillä.

Laitetaan vähän stressia ja katsotaan uudestaan (alemmassa pääteikkunassa on stress-komento).

• ”If you want to display the information about your cpu, disk (sda2) utilisation and system load, run the following command:”
  • $ dstat -cdl -D sda2

dstat:ista huomaa tuon stress-ajon pysähtyminen (kohta, jossa idl-kohta muuttui 0 -> 92 -> 100). Load average myös kolminkertaistui verrattuna aiempaan toimintaan. Tästä näki myös, että user ja system käyttivät molemmat puolet cpu:sta.

---

e) ss –listening

(lähteet: https://www.linux.com/topic/networking/introduction-ss-command/ ja https://www.binarytides.com/linux-ss-command/)

”The ss command is a tool used to dump socket statistics”. TCP ja UDP ovat protokollia.

$ ss –listening –tcp –numeric

— tcp kertoo tcp-yhteydet

”For example apache web server opens a socket connection on port 80 to listen for incoming connections.”

$ ss –listening –tcp

Erona edelliseen on, että portit kerrottiin numeroina, kun nyt ne on protokollan niminä (eli siis, mille protokollalle kyseinen portti on varattu [niitä on etukäteen päätetty tietty määrä]).

$ ss –tcp

Tämä kertoo, mitä yhteyksiä sillä on. Nuo peitetyt ovat minun internetin ip-osoitteita. 222.186.175.140 on taas China Telecom:in antama ip-osoite.

$ ss –listening –udp

Tämä kertoo, ketkä kuuntelevat udp-lähetyksiä.

---

f) grep -i error /var/log/syslog; grep -ir error /var/log/

• $ grep -i error /var/log/syslog
• Mar 19 06:44:52 blingi systemd-resolved[27840]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.

(lähde: https://askubuntu.com/questions/1058750/new-alert-keeps-showing-up-server-returned-error-nxdomain-mitigating-potential)

”This warning is logged by systemd-resolved, whenever a name can not be resolved by the DNS system (e.g. nslookup http://www.kjfoiqaefah34876asdf.com). This can be tolerated and is no reason to be alarmed. This is no error and nothing needs to be fixed.”

Muita erroreita ei tullut.

• $ grep -ir error /var/log

Tämä antoi pitkän listan logeja aiemmilta ajoilta (tässä viimeiset kolme):

• /var/log/apache2/error.log:[Thu Mar 19 07:23:28.235163 2020] [authz_core:error] [pid 30188:tid 139861843470080] [client xxx.xxx.xxx.xx:45402] AH01630: client denied by server configuration: /etc/apache2/\xe2\x80\x9c
• /var/log/syslog.1:Mar 18 14:39:51 blingi systemd-resolved[27840]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.
• /var/log/syslog.1:Mar 18 14:40:05 blingi systemd-resolved[27840]: message repeated 2 times: [ Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.]

Aiemmat errorit liittyivät myös apacheen.

---

g)  Load average näkyy esim ’uptime’, ’top’, ’htop’. Prosessoriydinten määrä näkyy ’nproc’. Miten load average tulkitaan? Miksi prosessoriydinten määrä on tässä kiinnostava?

• $ uptime
• 07:28:23 up 34 days, 22:31,  2 users, load average: 0.00, 0.00, 0.16

Tämä kertoo, kuinka kauan palvelin on ollut päällä, kuinka monta käyttäjää sillä on (kaksi, koska minulla on kaksi pääteikkunaa auki) sekä load averagen.

(lähde: https://www.tecmint.com/understand-linux-load-averages-and-monitor-performance/)

”System load/CPU Load – is a measurement of CPU over or under-utilization in a Linux system; the number of processes which are being executed by the CPU or in waiting state.”

”Load average – is the average system load calculated over a given period of time of 1, 5 and 15 minutes.”

Eli:

• load average over the last 1 minute is 0.00
• load average over the last 5 minutes is 0.00
• load average over the last 15 minutes is 0.16

Eli ei paljon mitään ole cpu:n pitänyt tehdä.

Otetaan aiempi tulos vertailuun:

• stress testin jälkeen:
  • load average over the last 1 minute is 3.97
  • load average over the last 5 minutes is 2.61
  • load average over the last 15 minutes is 1.18

Nyt on huomattavasti enemmän äksöniä tapahtunut.

Jos load average on 1, se tarkoittaa, että cpu:ta käytettiin 100 %:sesti keskimäärin. Yksi prosessi pyöri cpu:ssa viimeisen yhden minuutin ajan. Eli nyt cpu oli 297 %:sesti ylikuormittunut: keskimäärin 2,97 prosessia odottivat cpu:n vuoroa viimeisen minuutin aikana.

Komennolla $ nproc näkee, kuinka monta prosessiydintä palvelimella on (tässä tapauksessa vain 1). Miksi niiden määrä on kiinnostava? Koska yksi cpu pystyy suorittamaan vain yhtä tehtävää kerralla. Eli mitä enemmän cpu:lla on tehtäviä, sitä kuormittuneempi se on (ellei sillä ole tarpeeksi ytimiä, jotka suorittavat niitä).

---

h) Analysoi lopuksi koko ajalta keräämäsi kuormitustiedot. Löydätkö esimerkiksi aiheuttamasi kuormituspiikin?

• $ sar -r -s 06:38:00 -e 07:40:00
  • tämä komento antaisi sar tiedot tuolta ajanjaksolta
• Cannot open /var/log/sysstat/sa19: No such file or directory

😦

Otin kuitenkin kuromitustietoja jokaisen osion yhteydessä, joten toivon niiden riittävän.

Harjoitus 1

Harjoitus 2

Harjoitus 3

Harjoitus 4

Harjoitus 5

Harjoitus 6

Harjoitus 7

Harjoitus 8