Suositeltu

Tehtävä H1

Livetikun tekeminen, sovellusten asentaminen ja sovelluslisenssit

Tein tehtävät kotona pöytäkoneellani, jonka komponentteina olivat mm. Intel i5-3570K suoritin, Asus Dual GTX 1060 6GB näytönohjain sekä 8GB RAM-muistia.

a) Tee oma Linux-livetikku. Kokeile sitä jossain muussa kuin koulun koneessa. 

Aloitin tehtävän suorittamisen menemällä kotitietokoneeni selaimella osoitteeseen https://xubuntu.org/download/ ja lataamalla sieltä koneelleni tiedoston xubuntu-18.04.3-desktop-amd64.iso. Tämän jälkeen latasin osoitteesta https://github.com/pbatard/rufus/releases/ tiedoston nimeltä rufus-3.8.exe. Rufus on ohjelma, jonka avulla aiemmin lataamastani xubuntun .iso -tiedostosta saadaan luotua Linux-livetikku.

Seuraavaksi liitin USB-tikun tietokoneeni USB-porttiin ja käynnistin aiemmin lataamani rufus-3.8.exe -tiedoston. Erillistä ohjelman asennusta ei tarvinnut suorittaa, vaan Rufus käynnistyi välittömästi. Ohjelman valikosta klikkasin ”VALITSE” -painikketta, jonka jälkeen pystyin etsimään ja valitsemaan koneeltani aiemmin lataamani xubuntu-18.04.3-desktop-amd64.iso -tiedoston.

”VALITSE” -painiketta painamalla saa valittua halutun tiedoston. Kuvassa xubuntu-18.04.3-desktop-amd64.iso -tiedosto valittuna.

Tämän tehtyäni jätin kaikki asetukset oletukselle ja klikkasin ohjelman valikosta kohtaa ”ALOITA”. Ruutuun tuli ponnahdusikkuna, jossa kerrottiin vaadittavista latauksista. Valitsin ”Kyllä”, jonka jälkeen tuli uusi ponnahdusikkuna, josta valitsin ”OK”. Tämän jälkeen ohjelma alkoi tekemään itse livetikkua, jonka tekemisessä kesti muutama minuutti. Livetikun valmistuttua suljin Rufus -ohjelman.

Ponnahdusikkuna, jossa ilmoitetaan vaadittavasta latauksesta.

Klikattuani kohdasta ”OK” ohjelma alkoi tekemään livetikkua. Livetikun tekemiseen meni muutama minuutti.

Tässä vaiheessa käynnistin tietokoneeni uudelleen käynnistääkseni Xubuntun livetikulta. Minulta meni muutaman uudelleenkäynnistyksen verran aikaa ennen kuin löysin oikean näppäimen, josta pääsin käsiksi koneeni BIOSiin ja sitä kautta käynnistysasetuksiin. Tietokoneeni käynnistyessä uudelleen, minun täytyi painaa näppäintä F2. BIOSista vaihdoin koneeni käynnistyssijainniksi USB-muistin. Tämän jälkeen tallensin BIOSin asetukset ja poistuin BIOSsta. Näyttöön tuli valikko, josta pystyi valitsemaan kielen, sekä sen, haluatko asentaa Xubuntun vai käynnistää sen kokeilutilassa. Valitsin kieleksi Suomen ja käynnistin Xubuntun kokeilutilassa.

Tietokoneeni näytölle avautui Xubuntun työpöytä. Hiirtä liikuttamalla ja valikoita klikkailemalla totesin hiiren toimivan. Vasemman yläkulman valikosta avasin komentokehotteen, jonne kirjoittamalla totesin myös näppäimistön toimivan. Tehtyäni tämän kaiken, totesin livetikun toimivan ja siirryin suorittamaan seuraavaa tehtävää.

b) Listaa testaamasi koneen rauta (‘sudo lshw -short -sanitize’).

Avasin Xubuntun työpöydältä, vasemmasta yläkulmasta, valikon. Valikosta käynnistin komentokehotteen. Komentokehotteeseen kirjoitin ”sudo lshw -short -sanitize”, minkä jälkeen komentokehotteessa näkyi koneeni tiedot.

Kuvassa komentokehote, jossa näkyy käyttämäni tietokoneen tiedot.

c) Asenna kolme itsellesi uutta ohjelmaa. Kokeile kutakin ohjelmaa sen pääasiallisessa käyttötarkoituksessa.

Asensin kuvankäsittelysovelluksen nimeltä GIMP suoraan Xubuntun komentokehotteesta, johon pääsee aiemmin mainitsemallani tavalla. Komentokehotteeseen kirjoitin ”sudo apt-get install gimp” ja painoin näppäimistöstä Enteriä. Ohjelmaa asentaessa tuli jokin kysymys, johon vastasin ”kyllä” kirjoittamalla komentoriville kirjaimen ”k” ja painamalla enteriä. Asennuksen jälkeen käynnistin GIMPin linuksin työpöydän vasemman yläkulman valikon kautta. Kyseisessä valikossa kirjoitin hakukenttään ”gimp”, minkä jälkeen ohjelman käynnistyskuvake ilmestyi ruudulle. Klikkasin käynnistyskuvaketta ja GIMP käynnistyi. Kokeilin kuvankäsittelyohjelmaa kirjoittamalla sen avulla tekstin ”toimii”. Totesin sovelluksen toimivan, minkä jälkeen suljin sen.

GIMP toiminnassa.

Seuraavaksi asensin Spotify-musiikkisovelluksen. Edellisestä poiketen päätin asentaa Spotifyn Xubuntun graafisen käyttöliittymän kautta. Klikkasin työpöydän vasemmasta yläkulmasta auki valikon (pieni sinivalkoinen ikoni). Kyseisestä valikosta klikkasin auki Software -nimisen sovelluksen. Tämän sovelluksen kautta pystyi etsimään erilaisia sovelluksia Linuxille. Spotify sattui olemaan näkyvillä heti sovelluksen aloitusnäkymässä.

Software -sovellus, jonka kautta voi etsiä ja asentaa sovelluksia.

Klikkasin ruudulla näkynyttä Spotifyn kuvaketta, minkä jälkeen avautui uusi ikkuna, josta näki mm. sovelluksen kuvauksen. Samaisesta ikkunasta painoin painiketta ”Install”, jolloin Spotify lähti asentumaan. Sovelluksen asentamisen jälkeen painoin ruudulla näkynyttä ”Launch” -painiketta, ja ohjelma käynnistyi. Kirjauduin omalla Spotify-tunnuksellani sovellukseen ja pistin musiikin soimaan. Musiikki kuului tietokoneeni kaiuttimista, ja näin totesin sovelluksen olevan toimintakunnossa. Suljin sovelluksen.

Spotify toimii.

Seuraavaksi halusin asentaa Audacity-äänieditointisovelluksen. Käynnistin jälleen työpöydän vasemman yläkulman ikonin (pieni sinivalkoinen) takaa olevan Software -sovelluksen. Sovelluksen avauduttua, klikkasin sovelluksen oikeassa yläkulmassa olevaa suurennuslasin kuvaketta, minkä jälkeen pystyin kirjoittamaan etsimäni sovelluksen nimen. Tässä tapauksessa kirjoitin hakukenttään ”Audacity”. Ohjelma löytyi nopeasti, ja asennus sekä sovelluksen käynnistys tapahtuivat täysin samalla tavalla kuin aiemmin kertomani Spotifyn asennus, joten en mainitse kyseisiä toimenpiteitä tässä uudelleen. Ennen sovelluksen käynnistämistä kytkin tietokoneeseeni mikrofonin. Sovelluksen käynnistyttyä kokeilin tallentaa sillä ääntäni. Ääni tallentui moitteettomasti, minkä jälkeen totesin sovelluksen sekä mikrofonin toimivan. Suljin sovelluksen ja siirryin seuraavaan tehtävään.

Audacity toimii.

d) Mitä lisenssiä kukin näistä ohjelmista käyttää? Selitä lyhyesti, mitä oikeuksia ja velvolisuuksia tuosta lisenssistä seuraa.

GIMP käyttää GNU General Public Licenceä (GPL) (versio 3) Lähde: https://www.gimp.org/about/ Kyseinen lisenssi oikeuttaa käyttämään, muokkaamaan ja jakamaan kyseistä ohjelmaa, mutta kaikkien GIMPistä jaettujen ja kehitettyjen versioiden on käytettävä myös GPL-lisenssiä.

Spotify on yksityisomisteinen, eli toisin sanoen suljetun lähdekoodin, ohjelmisto. Käyttäjällä on oikeus käyttää sovellusta, mutta sovellusta ei saa muokata eikä jakaa edelleen.

Audacity käyttää GNU General Public Licenceä (GPL) (ilmeisesti versio 2) Lähde: https://www.audacityteam.org/about/license/ Audacityä saa käyttää, muokata ja jakaa edelleen, mutta muokattujen ja edelleen jaettujen versioiden on käytettävä myös GPL-lisenssiä (versio 2 tai halutessa uudempi).

e) Listaa käyttämäsi ohjelmat (esim. MS Word), kunkin ohjelman käyttötarkoitus (esim. Tekstinkäsittely) ja vastaava vapaa Linux-ohjelma (esim. LibreOffice Writer). Jos johonkin tarkoitukseen ei löydy vapaata Linux-ohjelmaa, listaa sekin.

Vasemmalla Windowsissa käyttämiäni ohjelmia ja oikealla samaan tarkoitukseen sopivia vapaan lähdekoodin ohjelmia Linuxille.

  • MS Excel, taulukkolaskenta. Vastaava vapaa ohjelma LibreOffice Calc
  • Corel PaintShop Pro, kuuvankäsittely. Vastaava vapaa ohjelma GIMP
  • MS PowerPoint, esitysgrafiikka. Vastaava vapaa ohjelma LibreOffice Impress
  • Käytän myös VLC-mediasoitinta, joka on vapaa ohjelma

f) Vapaaehtoinen lisätehtävä: varmuuskopioi tiedostosi (voit käyttää esimerkiksi ulkoista USB-levyä)

Laitoin ulkoisen kovalevyn tilaukseen. Olen viivytellyt varmuuskopioiden ottamista aivan liian pitkään. Vain tärkeimmät tiedostoni ovat varmuuskopioituina USB-tikuille.

Käyttämiäni lähteitä:

Palvelinten hallinta H7

Oma moduuli. Orjille sovellukset muistin määrän ja orjan id:n perusteella.

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. Käytin aiempien tehtävien orjia, sekä tässä tehtävässä luomiani kahta uutta orjaa. Kaikki orjat oli luotu VirtualBox 6.1:llä. Kaikkiin orjiin oli asennettu Xubuntu 18.04.4 LTS. Muistia orjilla oli joko 1GB tai 2GB.


Oma moduli (iso tehtävä). Ratkaise jokin oikean elämän tai keksitty tarve omilla tiloilla/moduleilla. Voit käyttää Salttia tai muuta valitsemaasi modernia keskitetyn hallinnan ohjelmaa. Esitä tulos viimeisellä opetuskerralla, 5-10 min (keskiviikon ryhmä). Live demo olisi kiva. Raportoi modulisi tarkoitus, koodi ja testit.

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

Aloitin tehtävän tekemisen 19.5.2020 klo 12:00 (UTC +3), mutta en tehnyt sitä yhtäjaksoisesti.



Oma moduuli

Tehtävänä oli luoda oma moduuli. Suurena haasteena oli keksiä, mihin tarkoitukseen moduuli tulisi. Ensikosketukseni Linuxiin tapahtui viisi kuukautta sitten, minkä vuoksi monet ohjelmat ym. ovat minulle vielä tuntemattomia. Oma pöytäkoneeni on jo suhteellisen vanha, minkä vuoksi esimerkiksi RAM-muistia on vähän. Aloin miettimään, toimivatko tietyt Linux-ohjelmat virtuaalikoneillani, joilla on 1-2Gb RAM:a. Tämän mietinnän jatkoksi pohdin, pystyisikö Saltin avulla asentamaan sovelluksia koneiden tehojen perusteella. Monet pelit, kuvankäsittelyohjelmat sekä videoeditointiohjelmat tarvitsevat paljon muistia toimiakseen kunnolla. Tässä kohtaa pohdin myös, miten saisin asennettua tietyille orjille NginX:n ja toisille Apachen.



grains.items

Annoin masterilla grains.items -komennon nähdäkseni, mitä asioita grainsillä voi hakea. Orjilta tuli erilaisia arvoja. Huomasin arvojen joukossa muistin määrän (mem_total). Päätin tehdä tilan, joka asentaisi tietyn kuvankäsittelysovelluksen, mikäli muistia olisi vähän, ja mikäli muistia olisi enemmän, niin asentuisi toinen kuvankäsittelysovellus. Otin hiukan mallia edellisessä harjoituksessa käyttämästäni tilasta, jolla asennettiin Apache Debianille ja RedHatille.


editing-tila

Tein masterille tilaa varten uuden kansion:

sudo mkdir /srv/salt/editing

Tein kansioon tilatiedoston init.sls, jonka sisällöksi kirjoitin:

{% if grains['mem_total'] > 1500 %}
darktable:
  pkg.installed
{% elif grains['mem_total'] < 1500 %}
gimp:
  pkg.installed
{% endif %}

Tilassa asennetaan darktable -sovellus, mikäli muistia on enemmän kuin 1500 (1,5GB) ja gimp, mikäli muistia on alle tuon määrän. Valitsin tuon muistimäärän, sillä aikomuksenani oli testata sen toimivuutta luomalla 1GB ja 2GB virtuaalikoneet. Todellisuudessa tuo raja-arvo olisi varmasti suurempi. Testasin (sudo salt ’*’ state.apply editing) tilan toimivuutta yhdellä orjalla, jossa oli 1GB RAMia. Tila asensi vain Gimpin ilman virheilmoituksia. Kävin testaamassa Gimpin toimivuuden vielä orjakoneelta. Tila vaikutti siis toimivan, vaikka minulla ei ollutkaan 2GB konetta tässä vaiheessa testattavaksi.

Päätin tässä vaiheessa siirtyä seuraavien tilojen luontiin.



Webbipalvelimet

Kuten aiemmin mainitsin, halusin erotella jotenkin, mille koneelle asennetaan Apache ja mille Nginx. Ajatuksenani oli nimetä orjien id tietyllä tavalla. Esimerkiksi sellaisille orjille, joiden id:ssä olisi sana apache, asennettaisiin Apache, kun taas orjalle, jonka id:ssä olisi sana nginx, asennettaisiin gninx. Id:tä voisin ehkä sitten käyttää jollakin tavalla saltin tilassa ohjeistamaan asennuspaketteja oikeisiin koneisiin. Mietin, voisiko grains.item id:tä käyttää jollakin tavalla. Keskusteltuani toisen kurssilaisen, Aki Ronkaisen, kanssa päätin kuitenkin tehdä jaottelun myöhemmin top.sls -tiedostossa, sillä se vaikutti yksinkertaisemmalta keinolta.



Nginx -tila

Olin aiemmissa tehtävissä tehnyt erillisiä tiloja webbipalvelimille, ssh:lle sekä motd:lle. Päätin kasata kyseisiä tiloja yhteen.

Minulla oli jo olemassa kaikki alla näkyvät tilat ja niiden kansiot ja tiedostot valmiina, joten muokkasin nginx-kansiossa ollutta init.sls -tiedostoa.

Kasaamani tila näytti lopulta tältä:

nginx:
  pkg.installed
/var/www/html/index.nginx-debian.html:
  file.managed:
    - source: salt/nginx/testi.html
running:
  service.running
    - name: nginx
openssh-server:
  pkg.installed
/etc/ssh/sshd_config:
  file.managed:
    -source: salt://ssh/sshd_config
sshd:
  service.running:
  - watch:
    - file: /etc/ssh/sshd_config
/etc/motd:
  file.managed:
    - source: salt://motd/motd
    - template: jinja

Tila asentaa nginx:n ja openssh:n ja tarkistaa, että ne ovat käynnissä. Nginx:n oletussivu vaihdetaan toiseen (Sisällöksi kirjoitin ”Tämä on nginx-webbipalvelin” ), ssh:n oletusportti vaihdetaan portiksi 8888 ja motd-viesti kerää templaten avulla orjakoneen tietoja näytettäväksi kun ssh:lla kirjaudutaan sisään.

Testasin tilaa yhdelle vanhoista orjistani, ja tarkastusten jälkeen kaikki vaikutti toimivan.



Apache-tila

Kasasin myös Apache-tilan aiemmista tiloista:

apache2:
  pkg.installed
/var/www/html/index.html:
  file.managed:
    - source: salt://apache/default-index.html
/etc/apache2/mods-enabled/userdir.conf:
  file.symlink:
    - target: ../mods-available/userdir.conf
/etc/apache2/mods-enabled/userdir.load:
  file.symlink:
    - target: ../mods-available/userdir.load
apache2service:
  service.running:
    - name: apache2
    - watch:
      - file: /etc/apache2/mods-enabled/userdir.conf
      - file: /etc/apache2/mods-enabled/userdir.load
openssh-server:
  pkg.installed
/etc/ssh/sshd_config:
  file.managed:
    - source: salt://ssh/sshd_config
sshd:
  service.running:
    -watch:
      - file: /etc/ssh/sshd_config
/etc/motd:
  file.managed:
    - source: salt://motd/motd
    - template: jinja

Tila asentaa Apachen, vaihtaa oletussivun, mahdollistaa käyttäjän luoda sivuja, asentaa ssh:n ja ottaa motd:n templatesta. Varmistaa myös, että apache ja ssh ovat käynnissä ja tarkkailee tiettyjä tiedostoja muutosten varalta. Vaihdettavaan oletussivuun kirjoitin ”Tämä on Apance-webbipalvelin”.

Testasin myös tämän tilan vanhalla orjallani, ja tehtyäni muutamat tarkistukset, kaikki tuntui toimivan.


Orjakoneet

Lopullista testiä varten tein VirtualBoxissa kaksi uutta orjakonetta, joista toiseen laitoin muisimääräksi 1GB ja toiseen 2GB. Orjilla annoin komennot:

sudo apt-get install update
sudo apt-get install upgrade

Asensin koneille Salt-minionin:

sudo apt-get install -y salt-minion

Kävin muokkaamassa molempien orjien konffitiedostoon masterin IP:n sekä orjien ID:n:

sudoedit /etc/salt/minion
master: "masterin ip-osoite"
id: ServerApache
master: "masterin ip-osoite"
id: ServerNginx2

ServerApachessa 2GB RAMia ja ServerNginX2:ssa 1GB RAMia. Muistin määrä on eri, jotta voin testata vielä editing.sls:n toimivuutta.

Käynnistin minionin uudestaan:

sudo systemctl restart salt-minion.service

Kävin hyväksymässä masterilla avaimet:

sudo salt-key -A

Testasin yhteyden toimivuuden:

sudo salt '*' cmd.run 'whoami'



top.sls

Tein top.sls tiedoston /srv/salt -kansioon seuraavalla sisällöllä:

base:
  '*Apache*':
    - apache
  '*Nginx*':
    - nginx
  '*':
    - editing

Tuossa siis apache-tila ajetaan, mikäli orjan id:ssä on jossakin kohtaa sana ”Apache”. Vastaavasti nginx-tila ajetaan, mikäli orjan id:ssä on jossakin kohtaa sana ”Nginx”. Kaikille orjille ajetaan editing-tila. Top.sls:stä lisää tietoa täällä. Ajatuksena tässä oli se, että kaikki koneet, joille halutaan Apache, niin niiden id:n kirjoitetaan apache ja vastaavasti NginX niille orjille, joiden id:ssä on nginx.

Koitin ajaa koko tekeleen komennolla sudo salt ’*’ state.highstate ja sain virheilmoituksen.

Melko pitkään mietin, missä vika. Koitin selvittää ongelmaa tutkimalla tätä sivustoa: https://docs.saltstack.com/en/latest/ref/states/top.html

Minulla oli kaikki tilatiedostot omissa kansioissaan, ja top.sls niiden ulkopuolella. En ole varma ymmärsinkö oikein, mutta kopioin kaikkien kolmen käyttämäni tilan .sls -tiedostot samaan paikkaan, jossa top.sls oli(/srv/salt/). Muutin varmuuden vuoksi niiden nimet (init.sls -> editing.sls, apache.sls ja nginx.sls). Ajoin highstate-komennon uudestaan, ja nyt kone jäi raksuttamaan. Reilun minuutin jälkeen tuli ilmoitukset onnistuneista tilojen suorittamisista. Toiselle koneelle ajettiin apache.sls ja editing.sls:stä darktable, ja toiselle nginx.sls ja editing.sls:stä gimp. Tavallisesti servereille tuskin asennettaisiin kuvankäsittelyohjelmia, mutta orjien rajallisesta määrästä johtuen täytyi hiukan oikoa.

Kävin orjilla tarkistamassa, että kaikki toimii. Ssh:lla pääsee kirjautumaan vain portin 8888 kautta ja motd on templatesta otettu, palvelimien oletussivu on vaihtunut, Apachella käyttäjä pystyy tekemään omia sivuja ja kummallakin koneella on eri kuvankäsittelyohjelma, jotka toimivat niin kuin on tarkoitettu. Kaikki toimi niin kuin pitikin.



En tiedä yhtään, vastasiko tämä tehtävänantoon. Oli jälleen todella haastavaa miettiä, millaisia ongelmia Saltin avulla voisi ratkoa, kun ei ole vielä päässyt käyttämään Linuxia tuotantoympäristössä ja muutenkin Linuxin opettelu on vasta alussa. Oli kuitenkin mielenkiintoista tehdä tätä tehtävää, ja samalla tuli opittua uutta.

Lopetin tehtävän tekemisen 20.5.2020 klo 07:00 (UTC +3). Tehtävää en tehnyt yhtäjaksoisesti, vaan pidin taukoja välissä. Aktiivista aikaa pohtimiseen, selvittelyyn, tekemiseen ja raportointiin meni noin 8-9 tuntia.




Lähteet

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.

  • Motd -tila muokkasi orjien motd-tiedostoja
  • Tulostin masterilla orjien motd-tiedoston sisällön
  • XubuntuSlaven ssh-motd (omat lisäykseni alhaalla)


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.

  • Newfile -tila ajettu onnistuneesti
  • Molemmille orjille luotiin halutun mukaiset tiedostot.

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

  • CentOSslave
  • XubuntuSlave
Kuvissa olevat asennuskellonajat poikkeavat toisistaan, koska ajelin ja säädin tilaa useamman kerran ja otin näköjään kuvat eri asennuskerroilta.

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

Molempien orjien uudet Apache-defaultsivut

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

Palvelinten hallinta H5

Muottien tekoa ja moduulien asentamista

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.

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


Aloitin tehtävän 5.5.2020 klo 18:00 (UTC +3)

Pähkäilin ensin itse melko pitkään miten tehtävä ratkaistaan. Koitin googletella ohjeita, mutta en löytänyt kummoisia ohjeita. Lopulta päädyin selailemaan Tero Karvisen sivuja, sekä kurssilaisten tehtäväratkaisuja, kuten tätä Aki Ronkaisen sivua. Sain sivuilta hyviä vinkkejä, joiden avulla lähdin ratkaisemaan tehtävää.



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

Googletin, mitä arvoja grainsin avulla on saatavilla ja päädyin tälle sivustolle. Komento salt ’*’ grains.ls listaa grainsit. Päätin kokeilla tehdä templaten, joka näyttää orjakoneen id:n. Tein ensin masterille kansion:

sudo mkdir srv/salt/message/

Kansioon loin muotin:

sudoedit message

Muotin sisällöksi:

Tervetuloa!

Käyttämäsi koneen id on {{ grains['id'] }}

Loin kansioon myös init.sls tiedoston:

sudoedit init.sls

Init.sls sisällöksi:

/tmp/message:
  file.managed:
    - source: salt://message/message
    - template: jinja

Kyseinen tila luo muotista message -tiedoston orjalle kansioon /tmp/ (tiedostoon tallentuu orjan id). Valitsin kyseisen kansion, koska arvelin sen olevan tarkoitettu väliaikaisille tiedostoille.

Ajoin tilan testatakseni sitä:

sudo salt '*' state.apply message

Sain ilmoituksen onnistuneesta suorituksesta:

Kävin orjalla testaamassa templaten toimivuuden:

cat /tmp/message

Template näytti viestin ja orjan id:n kuten oli tarkoituskin:



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.

Tarkoituksena oli luoda templatea käyttäen orjalle viesti, joka näytetään kirjauduttaessa sisään ssh:lla.

Loin masterille uuden kansion:

sudo mkdir /srv/salt/motd

Kansioon tiedosto (muotti) nimeltä motd:

sudoedit motd

Tiedoston sisällöksi:

Tervehdys!

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

Samaan kansioon init.sls:

sudoedit init.sls

Init.sls sisällöksi:

/etc/motd:
  file.managed:
    - source: salt://motd/motd
    - template: jinja

Ajoin tilan masterilla:

sudo salt '*' state.apply motd

Tila ajettiin onnistuneesti:

Kävin orjalla tarkistamassa, näkyykö motd kun kirjaudun ssh:lla ja näkyihän se. Motd-tiedoston rivit lisättiin default-viestin loppuun:



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

Googletin aiheesta ja löysin pari sivustoa, joilla on neuvottu promptin säätämistä:
https://vitux.com/how-to-customize-ubuntu-bash-prompt/
https://www.cyberciti.biz/faq/bash-shell-change-the-color-of-my-shell-prompt-under-linux-or-unix/

Testailin ensin masterilla komennoilla värien vaihtamista:

Sivustoilla oli mainittu, että asetustiedosto on sijainnissa /home/käyttäjä/.bashrc. Kävin kurkkaamassa tiedoston sisältöä. Unohdin ottaa kuvan rivistä, jota muutin, mutta muutos näkyy myös myöhemmin ajetussa tilatulosteessa. Muutettu numero alleviivattu keltaisella:

Numero 32 on vihreä väri, jonka siis muutin violetiksi, eli numeroksi 35.

Tein tilalle kansion:

sudo mkdir /srv/salt/bash/

Kansioon init.sls tiedoston:

sudoedit init.sls

Sisällöksi:

/home/slave/.bashrc:
  file.managed:
    - source: salt://bash/.bashrc

Tässä on vain se sama ongelma, jonka takia minulla oli vaikeuksia aiemmissa harjoituksissa olleiden asetustiedostojen kanssa. Asetustiedosto on käyttäjän kotihakemistossa, ja käyttäjänimi ei ole kaikilla orjilla vakio. Laitoin yhden orjan nimen polkuun, joten tila toimii vain kyseisellä orjalla. Katselin muiden kurssilaisten tehtäväratkaisuja, ja he olivat ratkaisseet tämän aika pitkälti samalla tavalla.

Kopioin masterilla asetustiedoston tilakansioon:

sudo cp /home/master/.bashrc /srv/salt/bash/

Ajoin tilan komennolla:

sudo salt '*' state.apply bash

Sain ilmoituksen onnistuneesta rivimuutoksesta:

Kävin orjalla käynnistämässä terminaalin uudestaan, ja promptin väri oli vaihtunut:



d) Nginx. Tee nginx-weppipalvelimeen asetuksia Saltilla. Voit esimerkiksi tehdä uuden site:n, niin että etusivu vaihtuu.

Halusin muokata Nginxin defaultsivua. Kirjoitin ensin masterin selaimeen localhost ja huomasin, että minulla oli Apache asennettuna ja joku Apachelle luotu testisi tehtynä. Poisti ne, ja tarkistin vielä, ettei selaimessa annettu localhost avaa sivua.

Asensin masterille Nginxin:

sudo apt-get install -y nginx

Annoin varmuuden vuoksi komennon systemctl restart gninx, sillä en muistanut pitikö palvelin käynnistää uusiksi asentamisen jälkeen. Avasin selaimen ja kirjoitin osoiteriville localhost, minkä jälkeen Gninxin oletussivu avautui. Unohdin ottaa oletussivusta screenshotin.

Menin katsomaan, olisiko oletussivu samassa sijainnissa kuin Apachen oletussivu oli aiemmissa harjoituksissa. Sijainnista /var/www/html/ löytyi index.gnix-debian.html, eli juuri se sivu jota etsinkin. Muokkasin sivua:

<!DOCTYPE html>
<html>
<head>
<title>Testaillaan...</title>
Testaillaan...
</html>

Kirjoitin jälleen selaimeen localhost, jolloin luomani testisivu avautui:

Tein masterilla tilalle uuden kansion:

sudo mkdir /srv/salt/nginx/

Kopioin testisivun kyseiseen kansioon:

sudo cp /var/www/html/index.nginx-debian.html /srv/salt/nginx/

Uudelleen nimesin kopioimani tiedoston testi.html -nimiseksi, minkä jälkeen tein nginx -kansioon init.sls tiedoston seuraavalla sisällöllä:

nginx:
  pkg.installed

/var/www/html/index.nginx-debian.html:
  file.managed:
    -source: salt://nginx/testi.html

running:
  service.running:
  - name: nginx

Ajoin tilan masterilla komennolla:

sudo salt '*' state.apply nginx

Tilan suorittaminen onnistui lopun serviceä lukuunottamatta.

En tiennyt, mistä virhe saattoi johtua. Minulla oli orjalla Apache asennettuna, joten kävin varmuuden vuoksi pysäyttämässä sen. Olin unohtanut tehdä ennen ennen tilan ajoa testin orjan puolella (localhost selaimeen). Ajoin tilan uudeleen, jolloin servicen suorittaminen onnistui myös.

Minun olisi ollut hyvä testata vielä koko tilan ajaminen uudestaan ”puhtaalta pöydältä”, mutta se jäi tekemättä. Kävin kirjoittamassa orjakoneen selaimeen localhost, jolloin toivottu testisivu avautui.

Lopetin tehtävien tekemisen 6.5.2020 klo 2:20 (UTC +3). Tehtävien tekemiseen meni aikaa noin kahdeksan tuntia.



Lähteet

Palvelinten hallinta H4

Saltin tilojen värkkäilyä

KoTein 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: https://joni.tech.blog/2020/04/07/ph-h1/ sekä https://joni.tech.blog/2020/04/15/ph-h2/ ja https://joni.tech.blog/2020/04/21/palvelinten-hallinta-h3/


Aloitin tehtävien tekemisen 28.4.2020 klo 20:30 (UTC +3)
Koko tehtävänanto osoitteessa: http://terokarvinen.com/2020/configuration-managment-systems-palvelinten-hallinta-ict4tn022-spring-2020/

Modulikimara. Asenna 6 saltin tilaa/modulia.

Alkuun meni hetki miettiessä, mistä sovelluksesta aloittaisin. En muista asentaneeni GIMPiä aiemmin Saltin kautta, joten päätin aloittaa siitä.

sudo apt-get update

GIMP

Asensin aluksi GIMPin master -virtuaalikoneelleni:

sudo apt-get -y install gimp

Kävin etsimässä kyseisen sovelluksen asetustiedostoja ja löysin ne /etc/gimp/2.0/ kansiosta. Kansiossa oli tiedosto nimeltä gimprc, joka vaikutti sellaiselta tiedostolta, jolla pystyisi asetuksia säätämään. Käynnistin GIMPin ja graafisesta käyttöliittymästä menin selailemaan asetuksia. Huomasin kieliasetuksen ja päätin vaihtaa sen ruotsiksi (käyttöliittymä oli asennuksen jäljiltä englannin kielinen).

Annoin juurihakemistossa (onkohan oikea termi?) komennon find -printf ”%T+ %p\n”|sort |grep gimp, joka etsi viimeeksi muokatuttujen tiedostojen sijainnit laittaen ne aikajärjestykseen. Hakua rajasin tuolla |grep gimp määreellä, joka listasi vain ne tulokset, joissa kyseinen sana oli. Viimeisimmät muutokset oli tehty tiedostoihin polussa ./home/master/.gimp-2.8/. Kansio .gimp-2.8 on piilotettu kansio.

GIMPin asetustiedostojen etsiskelyä.

Menin kyseiseen kansioon ja siellä oli saman niminen tiedosto (gimprc), jollaisen olin aiemmin löytänyt polusta /etc/gimp/2.0/. Avasin tiedoston ja huomasin tiedostossa rivin (language ”sv”), joka viittasi selvästi muuttamaani kieliasetukseen. Tekemällä tilatiedoston, joka vaatisi tuon rivin olemassoloa /etc/gimp/2.0/gimprc -tiedostossa, pitäisi pystyä säätämään Saltin avulla GIMPin kieleksi ruotsin. Siirryin tekemään tilatiedostoa.

GIMP -tila

Tilan tavoitteena oli olla GIMP asennettuna ja käyttöliittämän kielenä ruotsi.

Minulla oli aiemmasta harjoituksesta valmiina salt asennettuna masterille sekä orjalle. Tein tilalle uuden kansion /srv/salt/gimp/. Kansioon tein init.sls, jonka sisällöksi kirjoitin:

gimp:
  pkg.installed
/etc/gimp/2.0/gimprc:
  file.managed:
    - source: salt://gimp/gimprc

Tila määrää saltin olevan asennettuna ja gimprc -tiedoston olevan sellainen kuin se on /salt/gimp/ -kansiossa. Kopioin /etc/gimp/2.0/gimprc -tiedoston kansioon srv/salt/gimp/ komennolla sudo cp -r /etc/gimp/2.0/gimprc /srv/salt/gimp/. Avasin kopion ja kirjoitin siihen aiemmin löytämäni asetusrivin: (language ”sv”). Nyt pitäisi kaiken olla valmista, joten testaamaan. Masterille komento: 

sudo salt '*' state.apply gimp

Hetken kuluttua terminaaliin tulostui tieto kahdesta onnistuneesta toiminnosta: gimp asennettu ja gimprc -tiedostoon lisätty rivi (language ’sv’).

GIMP -tila ajettu onnistuneesti.

Avasin orjakoneelta gimpin tarkistaakseni, oliko se ruotsin kielinen ja olihan se. Ensimmäinen tila luotu, nyt pitäisi vielä opiskella ruotsin kieli, jotta pystyy GIMPiä käyttämään.

GIMP ruotsiksi

Kello oli nyt 22:52 (UTC +3). Minulta oli mennyt ekan tilan luomiseen ja raportointiin yli kaksi tuntia ja vielä olisi viisi tilaa jäljellä. Jotenkin tätä hommaa piti nopeuttaa. Päätin, että yritän luoda vielä yhden tilan itse, minkä jälkeen katson muiden opiskelijoiden ratkaisuista loput neljä tilaa, jotka sitten toistan.

Koitin asennella useampaa sovellusta ja etsiä niiden asetustiedostoja. Kaikissa sovelluksissa asetustiedostot näyttivät menevän käyttäjän kotihakemistoon, enkä niitä tahtonut lähteä muokkaamaan. Sattumalta huomasin libreofficen asetuskansion ja päätin tutkailla siellä olevia tiedostoja.

LibreOffice

LibreOfficen asetustiedostoja oli kansiossa /etc/libreoffice/. Kyseisessä kansiossa oli sofficerc niminen tiedosto. Avasin tiedoston ja silmiini pisti rivi ”Logo=1”. Arvelin kyseisen asetuksen säätävän LibreOfficen käynnistyksen yhteydessä näkyvää logoa. Avasin LibreOffice -sovelluksen ja loho latauspalkilla näkyi. Suljin ohjelman ja muutin logoasetuksen nollaksi, ja käynnistin taas LibreOfficen, eikä logoa latauspalkilla enää näkynyt. Päätin tehdä tästä tilan.

LibreOffice -tila

Tilan tarkoituksena oli olla LibreOffice asennettuna ja ohjelman käynnistysvaiheen logo poistettuna käytöstä.

Tein kansion /srv/salt/libreoffice/ ja kansioon tiedoston init.sls. Init.sls tiedoston sisällöksi kirjoitin:

libreoffice:
  pkg.installed
/etc/libreoffice/sofficerc:
  file.managed:
    - source: salt://libreoffice/sofficerc

Kyseessä on samalla kaavalla tehty tila kuin GIMPissäkin: LibreOffice asennettuna ja sofficerc -tiedoston sisältö vastaava kuin /salt/libreoffice -kansiossa olevan saman nimisen tiedoston sisältö.

Annoin komennon:

sudo cp -r /etc/libreoffice/sofficerc /srv/salt/libreoffice/

Kyseinen komento kopioi asetustiedoston salt/libreoffice/ -kansioon. Muutin kopioimastani asetustiedostosta rivin Logo=1 -> Logo=0. Nyt tilan pitäisi olla valmis, joten kokeilemaan. Avasin ensin orjakoneelta LibreOfficen, ja logo näkyi käynnistyksen yhteydessä. Annoin masterilla komennon:

sudo salt '*' state.apply libreoffice

Melko pitkään mietittyään tulostui ilmoitus kahdesta onnistuneesta toiminnosta. LibreOffice oli päivitetty ja asetustiedosto muutettu.

LibreOffice -tila ajettu

Minun olisi pitänyt ensin päivittää LibreOffice käsin ja testata logon muuttaminen vasta sitten. Nyt tämä ei täysin vastannut aiemmin tekeemääni kokeilua. Kello oli tässä vaiheessa 0:45 (UTC +3), ja minulla oli vielä neljä tilaa tekemättä, joten en lähtenyt tekemään testejä uudestaan. Kävin orjalla käynnistämässä LibreOfficen, eikä logoa näkynyt käynnistymisvaiheessa. Testasin vielä kirjoittamista kyseisessä sovelluksessa, ja kaikki tuntui pelittävän normaalisti. Totesin tilan valmiiksi, mutta testit jäivät hiukan puutteellisiksi kuten aiemmin mainitsin.

Tässä vaiheessa siirryin selailemaan muiden kurssilaisten tehtäväratkaisuja. Emma Vaittisen tehtäväratkaisuissa huomasin Firefoxiin liittyvän tilan. Kävin katsomassa /etc/firefox/ kansion sisältöä, ja siellä ei ollut kuin tuo yksi syspref.js -tiedosto, joten päädyin tekemään Firefoxin aloitussivumuutoksen Emman tapaan. Aloitussivuksi halusin http://www.atkins.fi, joten muokkasin sen syspref.js -tiedostoon testatakseni muutoksen toimivuutta ennen tilan luomista. Avasin Firefoxin ja atkins.fi avautui.

Firefox -tila

Tässä vaiheessa aloin yksinkertaistamaan raportointia, jottei hommassa menisi koko yötä. Tilan tarkoituksena oli olla Firefox asennettuna ja aloitussivuna http://www.atkins.fi.

Kansion luonti masterille:

sudo /srv/salt/firefox/

Init.sls firefox -kansioon:

sudoedit init.sls

init.sls sisällöksi:

firefox:
  pkg.installed:
/etc/firefox/syspref.js:
  file.managed:
    - source: salt://firefox/syspref.js

Asetustieodoston kopiointi masterilla:

sudo cp -r /etc/firefox/syspref.js /srv/salt/firefox/

Asetustiedostoon rivi:

pref("browser.startup.homepage", "http://www.atkins.fi");

Kävin orjakoneelta tarkistamassa, ettei Firefoxin aloitussivu ollut http://www.atkins.fi.
Sitten ajoin tilan antamalla masterille komennon:

sudo salt '*' state.apply firefox

Sain ilmoituksen kahdesta onnistuneesta toiminnosta: Firefox oli asennettuna ja syspref.js tiedostoon muutettiin aloitussivuksi atkins.fi. Käynnistin orjalla Firefoxin tarkistaakseni toimiko muutos ja sivuksi aukesi atkins.fi. Tila siis toimi.

Firefox -tila ajettu

Kello 29.4.2020 1:42 (UTC +3). Päätin, että lisään raporttiin vielä ottamani screenshotit ja jatkan loppujen moduulien tekemistä seuraavana päivänä. Tämän tehtävän tekemiseen menikin huomattavasti kauemmin aikaa kuin mitä olin arvioinut. Vaikeinta on etsiä sovelluksia, joista löytäisin asetustiedostot muualta kuin käyttäjän kotihakemistosta.

Jatkoin tehtävien tekemistä 29.4.2020 klo 22:00. Oli vaikea keksiä lisää sellaisia sovelluksia, joita saisin säädettyä. Parin tunnin ohjelmien asentelun ja asetusten penkomisen jälkeen löysin Neofetchin.

sudo apt-get update

Neofetch

Neofetch on terminaalissa toimiva sovellus, joka näyttää järjestelmätietoja. Asensin ensin Neofetchin yhdelle virtuaalikoneistani:

sudo apt-get -y install neofetch

Käynnistin sovelluksen komennolla neofetch, jolloin terminaaliin tulostui seuraava näkymä:

Neofetch defaulttina

Asetustiedostojen sijainti: /etc/neofetch/config.conf

Kyseisestä tiedostosta pystyy poistamaan tai lisäämään sovelluksen näyttämiä tietoja. Kun sovellus käynnistetään ensimmäisen kerran, niin kyseinen asetustiedosto kopioituu käyttäjäkohtaisiin asetuksiin, minkä seurauksena yllä olevien asetusten muuttaminen ei enää vaikuta ohjelman toimintaan. Jos asetukset tekee ennen ensimmäistä käynnistystä, niin kyseiset muutetut asetukset siirtyvät myös käyttäjäkohtaisiin asetuksiin.

Neofetch -tila

Masterille kohteeseen /srv/salt/ uusi kansio ja kansioon init.sls

sudo mkdir neofetch
sudoedit init.sls

init.sls sisältö:

neofetch:
  pkg.installed:
/etc/neofetch/config.conf:
  file.managed:
    - source: salt://neofetch/config.conf

Muokkasin tiedostoa /srv/salt/neofetch/config.conf kommentoiden kaikki muut inforivit pois käytöstä lukuunottamatta OS, Host, Kernel ja Uptime rivejä. Kyseisessä tilassa Neofetchin pitäisi olla asennettuna ja kun ohjelma käynnistyy, niin terminaaliin tulisi tulostua vain nuo kolme tietoa.

Ajoin masterilla tilan komennolla:

sudo salt '*' state.apply neofetch

Tuli tieto kahdesta onnistuneesta toiminnosta: Neofetch asennettu ja asetustiedostoista kommentoitu useita rivejä pois. Kävin orjalla käynnistämässä Neofetchin nähdäkseni, onko näytettävät järjestelmätietorivit vähentyneet:

Rivit, jotka olin halunnut kommentoida pois, olivat myös poissa. Tila siis toimi toivotulla tavalla.

Kello oli 30.4.2020 klo 1:00 (UTC +3), joten jätin loput kaksi tilaa myöhemmin tehtäväksi. Tulen luultavasti toistamaan jonkun toisen tekemät tilat, sillä ohjelmien ja asetusten etsimiseen menee sen verran paljon aikaa.

Ssh -tila

Jatkoin tehtävien tekemistä 19.5.2020 klo 22:30.

Päätin tehdä ssh-tilan Tero Karvisen ohjeiden mukaan. Käytin myös samalla sivulla olevia tila-asetuksia ja ssh-konffeja. Normaalisti SSH käyttää porttia 22, mutta tavoitteena oli muuttaa SSH:n käyttämä portti toiseksi.

Asensin ssh:n ensin käsin:

sudo apt-get install -y openssh-server

Kirjauduin ssh:lla sisään testatakseni:

ssh slave@localhost

Sain kirjauduttua onnistuneesti sisään, minkä jälkeen kävin muuttamassa porttinumeron tiedostosta /etc/ssh/sshd_config. Asetin porttinumeroksi 8888 (Port 8888) ja tallensin tiedoston. Kirjauduin käyttäen uutta porttinumeroa:

ssh -p 8888 slave@localhost

Testasin vielä porttinumeroa 22, ja se ei enää toiminut.

Tein seuraavaksi itse tilan. Loin ensin uuden kansion masterille:

sudo mkdir /srv/salt/ssh

Kansioon init.sls -tiedosto, jonka sisällöksi:

openssh-server:
 pkg.installed
/etc/ssh/sshd_config:
 file.managed:
   - source: salt://ssh/sshd_config
sshd:
 service.running:
   - watch:
     - file: /etc/ssh/sshd_config

Kansioon myös sshd_config -tiedosto, jonka sisällöksi:

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

Ajoin tilan toiselle orjalle:

sudo salt 'JoniOrja' state.apply ssh

Tila suoritettiin onnistuneesti. Kävin testaamassa orjalla:

ssh -p 8888 joni@localhost

Salasanan antamisen jälkeen kirjautuminen onnistui ja tila toimi toivotulla tavalla.

Lähteet

Palvelinten hallinta H2

Package-File-Service, sovellusten asentamista ja säätämistä Saltin avulla

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

Tehtävä on osa Haaga-Helian Palvelinten hallinta -kurssia.



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

H2-harjoitus tuntui yleisvilkaisulta itselleni melko haastavalta. Päätin tehdä tämän a-kohdan Tero Karvisen ohjeiden mukaan saadakseni jonkinlaisen yleiskäsityksen package-file-service -menetelmästä.

Aloitin harjoituksen tekemisen 14.4.2020 klo 20:30 (UTC +3).



Apachen asentaminen

Asensin ensin masterille käsin Apachen, muutin Apachen default-sivun, otin käyttöön userdirin ja tein käyttäjälle sivut. Tein myös kaikki välitestit.

  • Apache asennettu ja default-sivu avautuu
  • Apachen default-sivu korvattu testisivulla
  • Käyttäjän sivu ei avaudu ennen userdirin käyttöönottoa
  • Userdir otettu käyttöön, käyttäjän sivua ei ole vielä tehty
  • Käyttäjän sivu avautuu



Viimeeksi muokattujen tiedostojen tarkastelu

Tarkistin, mitä tiedostoja userdirin käyttöönottaminen oli muokannut. 

find -printf "%T+ %p\n"|sort

Tero Karvinen on sivuillaan avannut kyseisen komennon merkitystä:

“%T+” is the modification time

“%p” is the filename with path

“\n” is newline

Apachen asentamisen jälkeen listassa näkyvät userdir.conf sekä userdir.load.

Alimpana viimeisimpänä muokatut tiedostot

Annoin komennot ls -l userdir.conf ja ls -l userdir.load nähdäkseni lisätietoja tiedostoista. Kyseessä ovat symlinkit tiedostoihin, jotka sijaitsevat mods-available -kansiossa.

Symlinkit



Tilatiedoston luominen

Loin kansion /srv/salt/apache ja sinne tein valmiiksi Apachen oletussivun komennolla sudoedit default-index.html, jonka sisällöksi kirjoitin ”Apachen default-sivu”.

Nyt aloin luomaan itse tilatiedostoa (/srv/salt/apache/init.sls) komennolla sudoedit init.sls. Tiedoston sisällöksi kirjoitin:

apache2:
 pkg.installed
/var/www/html/index.html:
 file.managed:
   - source: salt://apache/default-index.html

Kyseisten komentojen pitäisi asentaa orjalle Apache ja korvata oletussivu aiemmin luomallani sivulla. Kävin slavella tarkistamassa, ettei minulla ollut ennestään Apachea asennettuna, minkä jälkeen ajoin tilan komennolla sudo salt ’*’ state.apply apache, minkä pitäisi asentaa kaikille orjille (minulla yksi) ohjeiden mukaisesti Apache ja Apacheen uusi default-sivu.

Minuutin verran raksuteltuaan, tuli ilmoitus onnistuneesta suorituksesta. Kävin slavella testaamassa tilanteen kirjoittamalla selaimen osoiteriville ”localhost”, jolloin Apachen default-sivu aukesi kuten oli tarkoituskin. Homma siis näytti toimivan toivotulla tavalla.

  • Apache asentui
  • Apachen oletussivu päivitetty
  • Kaksi toimintoa suoritettu, kaksi muutosta tehty
  • Apachen oletussivu avautui

Nyt uskalsin lisätä init.sls tiedostoon userdir-moduulin vaatimat rivit. Kokonaisuudessaan init.sls näytti lisäysten jälkeen tältä:

apache2:
 pkg.installed
/var/www/html/index.html:
 file.managed:
   - source: salt://apache/default-index.html
/etc/apache2/mods-enabled/userdir.conf:
 file.symlink:
   - target: ../mods-available/userdir.conf
/etc/apache2/mods-enabled/userdir.load:
 file.symlink:
   - target: ../mods-available/userdir.load
apache2service:
 service.running:
   - name: apache2
   - watch:
     - file: /etc/apache2/mods-enabled/userdir.conf
     - file: /etc/apache2/mods-enabled/userdir.load

Uudet rivit lisäävät orjille symlinkit userdir -asetustiedostoihin, minkä jälkeen Apache käynnistetään uudelleen.

Annoin jälleen komennon sudoedit salt ’*’ state.apply apache. Hetken miettimisen jälkeen tuli ilmoitus viidestä onnistuneesta suorituksesta, ja yhteensä muutoksia tehtiin kolme. Kaksi symlinkkiä luotiin ja Apache käynnistettiin uusiksi.

  • Symlinkit luotu ja Apache käynnistetty uudestaan.

Tässä vaiheessa tajusin, että olisi ollut hyvä testailla userdir:n toimimattomuutta slavella ennen tilan ajamista. En kuitenkaan ryhtynyt siihen enää tässä vaiheessa.

Menin slavelle ja tein käyttäjälle normaalein käyttäjäoikeuksin sivut, joiden sisällöksi kirjoitin ”Slaven sivut”. Selaimen osoiteriville ”localhost/~slave”, ja slaven sivut avautuivat. Toimii!.

Orjalla käyttäjäoikeuksin luotu sivu



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ässä kohtaa sain oikein tosissaan miettiä, millä ohjelmalla saattaisin osata toteuttaa tehtävänannon. Halusin muuttaa jonkin sovelluksen asetuksia graafisesta käyttöliittymästä ja sitten tarkastella muuttuneita tiedostoja.



VLC:n asetustiedostojen etsintää

Valitsin sovellukseksi VLC:n. Asensin yhdelle virtuaalikoneistani VLC:n komennolla sudo apt-get -y install vlc. Käynnistin VLC:n ja muutin graafisen käyttöliittymän asetuksista soittimen ulkonäköä. Sammutin sovelluksen ja käynnistin sen uudestaan tarkistaakseni, ovatko muuttamani asetukset yhtä voimassa, ja olivathan ne.

Nyt siirryin etsimään, mihin sovellus on asennettuna. Ensiksi /etc/ -kansioon, jossa ei ollut VLC:n tiedostoja. Tässä kohtaa meninkin sitten vaikeaksi. Etsin ensiksi googlaamalla mahdollisia asennussijainteja, ja löysinkin joitakin mm. /usr/bin/ sijainnin. Kyseisessä kansiossa annoin komennon find -printf ”%T+ %p\n”|sort. Yhdenkään hakutuloksen kellonaika ei täsmännyt. Lopulta yritin muistlela mieleeni grepin käyttämistä. Menin kaikkien hakemistojen juureen, jossa annoin komennon find -printf ”%T+ %p\n”|sort |grep vlc ja löysin etsimäni. Asetustiedosto oli /home/joni/.config/vlc/vlc-gt-interface.conf.

Kommentti: Unohdin ottaa screenshotin tekemästäni hausta, joten kävin tekemässä haun myöhemmin uudestaan. Kellonajat eivät siis täsmää:

Kuva grep vlc -hausta. Alimpana etsimäni asetustiedosto

Aikani googlattuani sain selville, että .config on piilotettu kansio. Seuraavaksi aloin miettimään, miten ihmeessä pystyn saltin avulla muuttamaan käyttäjien tiedostoja, kun en edes tiedä tulevien käyttäjien nimiä. Tässä vaiheessa oli todettava, ettei minun osaamiseni riitä tämän homman ratkaisemiseen. Kaiken kaikkiaan touhusin tämän ongelman kanssa pari tuntia.



Sovellusten asentelua ja testailua

Sitten vain miettimään seuraavaa sovellusta ja toivomaan, että sen tiedostot olisivat muualla kuin käyttäjän kotikansiossa. Audacityn asentelin, ja siinä oli sama homma. Kokeilin useita muitakin ohjelmia, mutta asetukset tuntuivat aina olevan käyttäjien kotikansioissa. Lopulta muistin, että olin edellisellä Linux-kurssilla säätänyt sysstatin asetustiedostoja. Asensin sysstatin, ja siellä asetustiedostot olivat /etc/ -kansiossa. En osannut muokkailla sysstatin asetuksia terminaalista käsin, joten päädyin asetustiedostoihin tämän ohjeen perusteella. Tässä vaiheessa kello oli kuitenkin jo niin paljon, että minun oli pakko jättää loput tehtävistä aamuksi. Ne eivät aivan kerkeä annettuun deadlineen, mutta katsoin silti parhaimmaksi palata tehtävän pariin tuoreilla silmillä.

Lopetin tehtävien tekemisen 15.4.2020 klo 03:30 (UTC +3). Aikaa olin käyttänyt tähän mennessä noin 7 tuntia. Aikaa kului eniten eri sovellusten testailuun, asetustiedostojen etsimiseen, ohjeiden tutkimiseen, raportin kirjoittamiseen jne.




Sysstat

15.4.2020 klo 16:00 (UTC +3)

Olin aamuyöllä päätynyt tutkimaan sysstatia ja nyt jatkoin siitä mihin jäin. Asensin masterille ensin sysstatin testatakseni asetusten säätämistä. 

sudo apt-get install -y sysstat

Komennolla sar -A sysstatin pitäisi antaa järjestelmän tiedot, mutta tuli ilmoitus, ettei tietojen kerääminen ole päällä. Näin siis kuuluikin olla, sillä sysstat ei oletusasetuksilla kerää järjestelmätietoja. Seuraavaksi säätämään tiedostoja. Päädyin muokkaamaan tämän ohjeen mukaan kahta eri tiedostoa, jotta saisin sysstatin kerämään järjestelmätietoja kahden minuutin välein.

Ohjeen mukaisesti muutin /etc/default/sysstat tiedostosta kohdan:
ENABLED=”false” --> ENABLED=”true”

Kommentti: Tässä kohtaa olisi ollut hyvä testata sysstatin toiminta ennen ”kahden minuutin muutosta”, mutta se jäi epähuomiossa tekemättä.


Tämän jälkeen siirryin muokkaamaan toista tiedostoa /etc/cron.d/sysstat

Muutin tämän rivin:
5-55/10 * * * * root command -v debian-sa1 > /dev/null && debian-sa1 1 1

Täksi riviksi:
*/2 * * * * root command -v debian-sa1 > /dev/null && debian-sa1 1 1

Sysstat piti käynnistää uudelleen komennolla sudo service sysstat restart
Komennolla sar -A totesin sysstatin todellakin keräävän tietoja kahden minuutin välein.



Sysstat -tilan tekeminen ja asetustiedostot

Kävin ensin tarkistamassa, ettei orjakoneella ole sysstatia asennettuna. (Komento sar -A, antoi ilmoituksen, ettei sysstatia ole asennettu)

Tein masterille kansioon /srv/salt/ tiedoston nimeltä syssat.sls, ja sisällöksi kirjoitin:

sysstat:
  pkg.installed

Ajoin tilatiedoston orjille komennolla sudo salt ’*’ state.apply sysstat ja sain ilmoituksen onnistuneesta sysstatin asentamisesta orjakoneeseen.

Sysstat asentui

Kävin toteamassa asennuksen orjakoneella kirjoittamalla kirjoittamalla terminaaliin sar -A, jolloin sysstat ilmoitti, ettei tietojenkerräystä ole otettu päälle. Ei siis enää ilmoitusta puuttuvasta sysstat -sovelluksesta, joten sysstat oli asentunut.


Asetustiedostot

Loin masterille kansion /srv/salt/sysstat ja sinne tiedoston nimeltä sysstat. Tiedoston sisällöksi kirjoitin:

#
# Default settings for /etc/init.d/sysstat, /etc/cron.d/sysstat
# and /etc/cron.daily/sysstat files
#

# Should sadc collect system activity informations? Valid values
# are "true" and "false". Please do not put other values, they
# will be overwritten by debconf!
ENABLED="true"

Oletusasetuksiin nähden muutin siis vain false -> true.

Toinen asetustiedosto oli täsmälleen saman niminen kuin ensimmäinen, joten pistin sen omaan kansioon /srv/salt/sysstat/cron.d/ ja sisällöksi:

# The first element of the path is a directory where the debian-sa1
# script is located
PATH=/usr/lib/sysstat:/usr/sbin:/usr/sbin:/usr/bin:/sbin:/bin

# Activity reports every 10 minutes everyday
*/2 * * * * root command -v debian-sa1 > /dev/null && debian-sa1 1 1

# Additional run at 23:59 to rotate the statistics file
59 23 * * * root command -v debian-sa1 > /dev/null && debian-sa1 60 2

Kommentti: Olisi kannattanut muuttaa kommenttikohdasta 10 minutes -> 2 minutes. Nyt tiedostoon jäi periaatteessa väärää infoa antava kommentti.

Lisäsin sysstat.sls -tiedostoon rivit asetustiedostoille, ja ajoin tilatiedoston uudestaan. Sain seuraavanlaisen virheilmoituksen:

Olin laittanut liikaa välilyöntejä melkein jokaiselle riville. Poistin turhat välilyönnit, minkä jälkeen lopullinen sysstat.sls näytti tältä:

sysstat:
  pkg.installed
/etc/default/sysstat:
  file.managed:
    - source: salt://sysstat/sysstat
/etc/cron.d/sysstat:
  file.managed:
    - source: salt://sysstat/cron.d/sysstat
sysstatservice:
  service.running:
    - name: sysstat
    - watch:
      - file: /etc/default/sysstat
      - file: /etc/cron.d/sysstat

Annoin jälleen masterilla komennon sudo salt ’*’ state.apply sysstat, jolloin sain tiedot onnistuneesta toiminnasta, minkä mukaan sysstat oli jo valmiiksi asennettu, mutta asetustiedostot päivitettiin, ja sysstat käynnistettiin uusiksi.

Kävin orjakoneelta tarkistamassa sysstatin toimivuuden komennolla sar -A, ja totesin sysstatin keräävän tietoja kahden minuutin välein.

Osa sar -A komennon näyttämistä tiedoista

Lopuksi poistin sysstatin orjakoneelta, ja ajoin sysstat -tilatiedoston masterilta uudestaan nähdäkseni koko tilan toimivuuden. Kaikki kohdat suoritettiin nätisti, ja orjakoneella totesin sysstatin toimivan toivotulla tavalla. Tämä tehtävä oli paketissa.

Tilatiedoston toimivuus testattu vielä lopuksi. Kaikki kohdat suoritettu onnistuneesti.




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

Ajoin masterilla komennon sudo salt-call –local state.apply sysstat –state-output terse testatakseni paikallisesti sysstat -tilan toimivuuden.

Paikallinen ajo

Ekalla riviltä (vihreällä) nähdään, että sysstat oli jo valmiiksi asennettuna, joten sitä ei tarvinnut asentaa. Kahdella seuraavalla rivillä kerrotaan kahden sysstat -tiedoston muokkaamisesta. Neljännellä rivillä sysstat käynnistettiin uudestaan. Lopuksi yhteenveto: Neljä toimintoa ajettiin ja kolmessa tehtiin muutoksia, ei epäonnistumisia. Kaikki tilat siis suoritettiin onnistuneesti. Nähtävillä on myös eri toimintoihin käytetty aika.

Ajoin vielä lopuksi uudestaan saman local -komennon, jolloin kaikki tilarivit muuttuivat vihreiksi, eli muutoksia ei tehty.

Toisella kerralla muutoksia ei tarvinnut tehdä


Tehtävät sain tehdyiksi ja raportin kirjoitetuksi kellon näyttäessä aikaa 20:30 (UTC +3)
Kokonaisuudessaan tehtävien tekemiseen käytin tehokasta työaikaa arviolta 9 tuntia.


Loppukommentit

Tehtäviin tuli käytettyä kyllä todella paljon aikaa. En tiedä raportoinko kaiken liian tarkasti, vai valitsinko itselleni liian hankalan tehtävän (graafisen käyttöliittymän kautta asetusten muokkaaminen VLC:ssä). Harkitsin moneen otteeseen nopeamman tehtävän tekemistä, mutta päädyin nyt sitten kuitenkin tällaiseen lopputulokseen. Jatkossa pitää miettiä tarkemmin, miten teen ja raportoin tehtävät, sillä en pysty joka viikko käyttämään näin paljon aikaa yhden kurssin tehtävien suorittamiseen. Opittua tuli kuitenkin paljon.


Lähteet:

Palvelinten hallinta H1

Saltin asentaminen masterille ja slavelle, hei-maailman luominen, tietojen kerääminen slaveista ja ohjelman asentaminen Saltin avulla.

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. Olin tehnyt VirtualBoxilla valmiiksi kaksi virtuaalikonetta, joihin oli molempiin asennettu Xubuntu 18.04.4 LTS. Kummankin virtuaalikoneen käyttöön oli annettu keskusmuistia 1024MB verran.

Aloitin tehtävän tekemisen klo 16:00 (UTC +3). Kellot olivat kaikissa koneissa samassa ajassa.



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

Olin asentanut VirtualBoxiin valmiiksi kaksi virtuaalikonetta. Toisen oli tarkoitus toimia masterina ja toisen slavena. Päivitin vielä molempiin koneisiin paketit komennolla sudo apt-get update.

Master-koneelle asensin Salt Masterin komennolla sudo apt-get -y install salt-master. Slave-koneelle asensin Salt Minionin komennolla sudo apt-get -y install salt-minion.

Slave-koneen täytyi saada tietää masterin sijainti, jotta slave pystyisi ottamaan yhteyden masteriin. Annoin masterille komennon hostname -I nähdäkseni kyseisen koneen IP-osoitteen. Tämän jälkeen muokkasin slave-koneella Minion -tiedostoa komennolla sudoedit /etc/salt/minion. Lisäsin tiedostoon masterin IP:n ja annoin slave-koneelle id:ksi joni.

master: 192.168.0.101
id: joni

Jotta annetut asetukset tulisivat voimaan, piti slave-demoni käynnistää uudestaan komennolla sudo systemctl restart salt-minion.service. Nyt slaven pitäisi automaattisesti lähettää masterille julkinen avain, joka täytyy hyväksyä master-koneelta. Testataan tämä master-koneella komennolla sudo salt-key -A. Kyseisellä komennolla hyväksytään kaikki masterille tulevat avaimet. Lisää eri salt-key -komennoista voi luke tästä. Terminaali-ikkunaan tulostuu lista avaimista. Listalla oli vain yksi avain, joka näkyi aiemmin Minion -tiedostoon antamallani id:llä ”joni”. Tämä avain hyväksytään antamalla komento y. Nyt masterin ja slaven välille on saatu muodostettua yhteys.

Avaimen hyväksyminen.

Testasin yhteyttä antamalla masterille komennon sudo salt ’*’ cmd.run ’whoami’, jolloin terminaaliin tulostui ”joni: root”. Koneiden välinen yhteys toimi. Saltissa ’*’ tarkoittaa komennon koskevan kaikkia slave-koneita. Minulla on vain yksi slave-kone, joten olisin yhtä hyvin voinut kirjoittaa tähden paikalle slave-koneeni id:n, joka tässä tapauksessa oli joni.

whoami



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

Slavet toimivat masterin ohjeiden mukaan, ja toimintaohjeet sijaitsevat master-koneella kansiossa /srv/salt/. Kyseinen kansio ei ole valmiina, vaan se täytyy ensin luoda. Loin kansion master-koneelle komennolla sudo mkdir -p /srv/salt/. Seuraavaksi loin kyseiseen kansioon tiedoston komennolla sudoedit /srv/salt/hello.sls. Tiedoston sisällöksi kirjoitin:

/tmp/hellojoni.txt:
  file.managed:
    - source: salt://hellojoni.txt

Yllä olevat rivit tarkoittavat, että slave-koneen tmp-kansioon luodaan hellojoni.txt -tiedosto master-koneen slave -kansiossa olevan hellojoni.txt:n pohjalta. Mikäli tiedosto on jo olemassa, niin sen sisällön yhdenmukaisuus lähdetiedostoon verrattuna tarkistetaan.

Komennolla sudoedit /srv/salt/hellojoni.txt tein tekstitiedoston, johon juuri luomassani hello.sls -tiedostossa viitattiin. Tekstitiedostoon kirjoitin vain tekstin ”Tervehdys!”. Hyväksyin luomani hello -tilan komennolla sudo salt ’*’ state.apply hello. Masterin terminaaliin tulostui teksti onnistuneesta muutoksesta slave-koneella.

hellojoni.txt luotu slave-koneelle.

Kävin tarkastamassa tilanteen slave-koneella kirjoittamalla komennon cat /tmp/hellojoni.txt, minkä jälkeen terminaaliin tulostui ”Tervehdys!”. Masterin hello -ohjeen mukaisesti slavelle oli siis luotu hellojoni.txt -tiedosto, jonka sisältönä oli ”Tervehdys!”.

top.sls

Loin vielä masterille top.sls -tiedoston, jonka avulla slave-koneet toimivat annettujen ohjeiden mukaisesti säännöllisin väliajoin. Komentona käytin sudoedit /srv/salt/top.sls ja tiedoston sisällöksi kirjoitin:

base:
  '*':
    - hello

Muutin masterilla olevan hellojoni.txt -tiedoston sisällöksi ”Moi!”. En tiedä, miten usein slavet hyväksyvät top -tiedoston sisällön, mutta sen voi tehdä myös käsin komennolla sudo salt ’*’ state.highstate, jonka sitten annoinkin. Masterin terminaaliin tulostui jälleen viesti onnistuneesta muutoksesta.

joni-slaven hellojoni.txt -tiedostosta poistettu rivi ”Tervehdys!” ja lisätty rivi ”Moi!”.

Kävin vielä tarkistamassa tilanteen slave-koneelta. Slave-koneella antamani komento cat /tmp/hellojoni.txt tulosti tekstin ”Moi!” niin kuin pitikin. Homma paketissa.

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

Antamalla masterille komennon sudo salt ’*’ grains.items voit nähdä slave-koneiden tietoja. Annettuani kyseisen komennon, sain pitkän liudan slave-koneeni tietoja. Alla joitakin poimintoja:

id:
   joni
cpu_model:
    Intel(R) Core(TM) i5-3570K CPU @ 3.40GHz
ip4:
   - 192.168.0.102
lsb_distrib_description:
    Ubuntu 18.04.4 LTS
virtual:
    VirtualBox

Tiedoista kävi ilmi mm. fyysisen koneeni suoritin, virtuaalinen ympäristö (VirtualBox), virtuaalikoneen (slave) id ja IP-osoite, sekä käyttöjärjestelmän distro (Ubuntu 18.04.4 LTS).


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’

Halusin, että slave-koneelleni asennetaan automaattisesti GIMP -niminen sovellus. Tarkistin ensin, ettei slave-koneella ollut GIMP:ä asennettuna. Komennolla sudoedit /srv/salt/hello.sls lisäsin aiemmin luomaani hello.sls -tiedostoon rivit:

gimp:
  pkg.installed

Nyt kun slave tarkistaa top.sls -tiedoston kautta hello.sls tiedoston, niin se huomaa uudet rivit, jotka ohjeistavat asentamaan GIMP -sovelluksen. Testasin toimiiko tämä. Annoin jälleen sudo salt ’*’ state.highstate -komennon. Aikansa mietittyään masterin terminaaliin tulostui tiedot onnistuneesta GIMP:n asennuksesta. Myös hellojoni.txt -tiedosto tarkistettiin, mutta siihen ei ollut tullut muutoksia, joten se pysyi entisellään.

  • GIMP asennettu.
  • hellojoni.txt tarkistettu, ei muutoksia.

Kävin tarkistamassa slave-koneelta, oliko ohjelma varmasti asennettu. Kirjoitin terminaaliin gimp, minkä jälkeen kyseinen sovellus käynnisty. Totesin homman toimivan ja näin ollen tehtävän suoritetuksi.

Lopetin tehtävien tekemisen kello 22:00 (UTC +3). Tein kesken tehtävän kaikkea muutakin. Aikaa itse tehtävän tekemiseen ja raportointiin meni noin 3,5-4 tuntia.



Lähteet:

Tehtävä H8

Järjestelmätietojen tarkastelua sekä järjestelmän kuormittamista

Tein tehtävän kotona pöytäkoneellani, jossa oli mm. Intel i5-3570K prosessori, 8GB RAM-muistia ja Asus GTX 1060 (6GB) näytönohjain. Xubuntua (18.04.3) käytin USB-tikulta kokeilutilassa.

Aloitin tehtävien tekemisen 24.3.2020 klo 20:30 (UTC +2). Xubuntun kello näytti 18:30 (UTC +0).

Tehtävänanto:

Prosessinhallintaa ja lokeja.

a) Kuormitusta yli ajan. Tietysti palvelin hidastelee juuri silloin, kun olet nukkumassa. Seuraisipa joku kuormitusta tuolloin. Asenna heti aluksi jokin ohjelma seuraamaan kuormitusta, jotta voit tarkastella sitä koko tehtävän ajalta. Sopivia ohjelmia ovat esimerkiksi 'munin' ja sysstat ('sar').

b) Kuormita järjestelmän eri osa-alueita. Esim. 'stress'. Etsi prosessi toisesta ikkunasta 'top' tai 'htop', järjestystä voi vaihtaa "P" ja "M".

Kokeile käytännössä, selitä ja analysoi. Muista selittää, mitä komennolla halutaan selvittää ja tulkitse kokeilusi tulokset. Aiheuta tarvittaessa kuormaa tai muuta työkalulla näkyvää tulkittavaa.

c) iotop; iotop -oa

d) dstat

e) ss --listening --tcp --numeric; ss --listening --tcp; ss --tcp; ss --listening --udp; ss --listening --udp;

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

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? Vapaaehtoisena bonuksena voit miettiä, mitä hyötyä on kuormituslukemasta, joka voi mennä yli yhden eli yli 100%.

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

Alkuun laitoin suomalaisen näppäinasettelun, päivitin paketit ja laitoin palomuurin päälle:
setxkbmap fi
sudo apt-get update
sudo ufw enable

a) Asenna heti aluksi jokin ohjelma seuraamaan kuormitusta, jotta voit tarkastella sitä koko tehtävän ajalta. Sopivia ohjelmia ovat esimerkiksi ’munin’ ja sysstat (’sar’).

Asensin sysstatin komennolla sudo apt-get install -y sysstat. Annoin komennon sar 1 3 testatakseni ohjelman toimivuuden. Kyseinen komento antaa kolme kertaa, yhden sekunnin välein, prosessorin tiedot. Ohjelma näytti pelittävän, ja ytimet olivat enimmäkseen levossa (%idle):

$ sar 1 3
Linux 5.0.0-23-generic (xubuntu) 	03/24/2020 	_x86_64_	(4 CPU)

07:53:42 PM     CPU     %user     %nice   %system   %iowait    %steal     %idle
07:53:43 PM     all      2.75      0.00      0.25      0.00      0.00     97.00
07:53:44 PM     all      2.51      0.00      0.25      0.00      0.00     97.24
07:53:45 PM     all      2.01      0.00      0.25      0.25      0.00     97.49
Average:        all      2.42      0.00      0.25      0.08      0.00     97.25

Avasin kaksi uutta terminaali-ikkunaa ja annoin kumpaankin eri komennon. Toisen terminaaliin kirjoitin sar -u 5 10000, jolloin terminaaliin päivittyy prosessorin kuormitus viiden sekunnin välein, 10000 kertaa. Tämän jälkeen annoin toiseen terminaali-ikkunaan komennon sar -r 5 10000, mikä puolestaan aloitti muistitietojen päivittämisen samanlaisissa sykleissä. Molempiin ikkunoihin alkoi päivittymään statistiikat. Tarkoituksenani oli kerätä muistin ja suorittimen rasitustietoja koko harjoituksen ajalta. Tarkastelen tuloksia harjoituksen lopussa.

b) Kuormita järjestelmän eri osa-alueita. Esim. ’stress’. Etsi prosessi toisesta ikkunasta ’top’ tai ’htop’, järjestystä voi vaihtaa ”P” ja ”M”.

Kokeile käytännössä, selitä ja analysoi. Muista selittää, mitä komennolla halutaan selvittää ja tulkitse kokeilusi tulokset. Aiheuta tarvittaessa kuormaa tai muuta työkalulla näkyvää tulkittavaa.

Googlettamalla löysin tällaiset ohjeet. Asensin kuormitussovelluksen komennolla sudo apt-get install stress. Testasin sovelluksen toiminnan antamalla komennon uptime, jolla näin tämän hetkisen keskimääräisen kuormitustason.

$ uptime
 20:27:23 up  4:35,  1 user,  load average: 0.36, 0.32, 0.28

Googletin, mitä load average tarkoittaa ja löysin tällaiset ohjeet. Ensimmäinen load average arvo kertoo keskimääräisen rasituksen kuluneen minuutin ajalta, toinen arvo viimeisen viiden minuutin ajalta ja viimeinen arvo keskimääräisen rasituksen viimeisen 15 minuutin ajalta.

Mikäli ymmärsin oikein, niin rasituksen taso riippuu prosessoriydinten lukumäärästä. Minun koneessani oli neliydinprosessori, joten minun tulisi huolestua rasituksesta vasta, kun keskimääräinen rasitustaso nousisi lähelle arvoa neljä. Mikäli et tiedä prosessoriydintesi lukumäärää, niin voit tarkistaa sen komennolla nproc. Lisätietoja nprocista.

Ajoin komennon stress -c 2 -i 1 -m 1 –vm-bytes 256M -t 15s. C-arvo rasittaa suoritinta, i-arvo I/O:ta ja m-arvo muistia. lopussa oleva -t 15s tarkoittaa rasituksen kestoa sekunneissa. Seurasin rasituksen aikana toisessa terminaali-ikkunassa mahdollisia muutoksia, kirjoittamalla komennon watch uptime. Ensimmäinen load average arvo asettui rasituksen jälkeen arvoon 1.28. Rasitus näkyi selkeästi, mutta suorittimelleni jäi vielä pelivaraa.

Pientä rasitusta havaittavissa

Avasin uuden terminaali-ikkunan, johon annoin komennon top. Käsittääkseni kyseisellä komennolla näkee käynnissä olevat prosessit. Annoin uudelleen aiemman stess-komennon ja seurasin samalla toisesta ikkunasta prosessilistausta. Ikkunaan ilmestyi merkinnät stressiprosesseista, joiden suoritinkäyttö oli melkein 100% (%CPU). Muistin käyttö oli olematonta (%MEM).

Prosesseja top-komennon takana. Ylimpänä valkoisella tekstillä stressitestin prosessit.



c) iotop; iotop -oa

Iotop on sovellus, joka näyttää järjestelmän levyliikenteen määrän.

Asensin sovelluksen komennolla sudo apt-get install iotop ja käynnistin sen omassa ikkunassa komennolla sudo iotop -oa. Jos ymmärsin oikein, niin komennossa -o näyttää vain ne prosessit, jotka vaikuttavat I/O:n. -a määritettä en oikein ymmärtänyt, mutta eri komennoista voi lukea lisätietoa täältä. Komento sudo iotop ei rajaa mitään prosessia pois, vaan näyttää kaikki prosessit.

Iotop -oa

Ajoin taas erillisessä ikkunassa rasitustestin komennolla stress -c 2 -i 1 -m 1 –vm-bytes 256M -t 15s, mutta en huomannut iotopissa muutoksia. Selailin muiden kurssilaisten tehtäväratkaisuja, ja huomasin Arttu Kesannon lisänneen komentoon -d -määreen, jolloin myös levyä rasitetaan. En osannut lisätä d:tä oikeaan kohtaan komennossa, eikä Googlekaan antanut kunnollisia hakutuloksia yrityksistä huolimatta.

Asensin Spotifyn ja käynnistin sen. Nyt iotopissa näkyi Spotifyyn liittyviä prosesseja. DISK READ -kohdassa näkyi luetun datan määrä, mutta mitä se käytännössä tarkoitti, jäi minulle hiukan epäselväksi.

Luetun datan määrä näkyvissä ja I/O-prosenteissa pientä kasvua.



d) dstat

Dstatin avulla voit seurata järjestelmän osien tilaa. Asensin sovelluksen komennolla sudo apt-get install -y dstat ja käynnistin sen komennolla dstat. Ohjelma näyttää mm. suorittimen ja kovalevyn rasituksen. Ajoin jälleen saman stressitestin komennolla stress -c 2 -i 1 -m 1 –vm-bytes 256M -t 15s ja seurasin mahdollisia muutoksia dstatista. Prosessorin siirtymisen levosta rasitukseen näki jälleen selvästi.

  • Suoritin vihreänä levossa
  • Suoritin keltaisella rasituksessa
Vasemmalla sovellus heti asentamisen jälkeen, suoritin levossa (vihreät lukemat vasemmalla). Oikealla suoritin rasituksessa (keltaiset lukemat vasemmalla, suorittimen käyttö yhteenäs 100%).

Halusin nähdä myös verkon kuormituksen ja avasin Youtubesta 4K-videon. Videon katseleminen näkyi verkon kuormituksessa hyvin.

Keskellä recv- ja send -arvot kertovat vastaanotetun ja lähetetyn datan määrän. Ylhäällä ennen videon avaamista. Videon katselun aikana datan vastaanotto nousi jopa 10 megaan (vihreällä keskellä)



e) ss –listening –tcp –numeric; ss –listening –tcp; ss –tcp; ss –listening –udp; ss –listening –udp;

Kyseessä on useamman komennon ketjutus. Tarkemmin eri komennoista voi lukea täältä.

ss –listening –tcp –numeric
Näyttää kuunneltavat TCP-portit (numeroina esim. :80).

ss –listening –tcp
Näyttää kuunneltavat TCP-portit (niminä, esim. :http).

ss –tcp
Näyttää TCP-portit. Ilmeisesti muodostetut yhteydet (ESTAB)?

ss –listening –udp
Näyttää kuunneltavat UDP-portit.

Kokeilin, saisinko näkymään SSH-yhteyden listauksessa. Avasin SSH-yhteyden koneeseeni, ja kappas kummaa, yhteys näkyi myös porttilistauksessa:

SSH-yhteys keskimmäisenä.

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



Komennolla grep -i error /var/log/syslog voit etsiä kyseisestä tiedostosta kaikki rivit, joissa on sana error. Sanan kirjoitusasulla ei ole väliä, mikäli komennossa käytetään -i -määritettä. Terminaalissa hakusana on korostettu punaisella värillä, mikä helpottaa rivien lukemista. Erroreita näkyi, mutta eivät aiheuttaneet ongelmia tehtäviä tehdessä:

$ grep -i error /var/log/syslog
Mar 24 15:52:36 xubuntu kernel: [    6.244415] RAS: Correctable Errors collector initialized.
Mar 24 15:52:36 xubuntu gpu-manager[1427]: Error: can't open /lib/modules/5.0.0-23-generic/updates/dkms
Mar 24 15:52:36 xubuntu gpu-manager[1427]: Error: can't open /lib/modules/5.0.0-23-generic/updates/dkms
Mar 24 15:52:36 xubuntu NetworkManager[1417]: <warn>  [1585065156.8887] Error: failed to open /run/network/ifstate
Mar 24 15:52:36 xubuntu snapd[1409]: helpers.go:146: error trying to compare the snap system key: system-key missing on disk
Mar 24 15:52:40 xubuntu snapd[1409]: stateengine.go:102: state ensure error: cannot decode new commands catalog: got unexpected HTTP status code 429 via GET to "https://api.snapcraft.io/api/v1/snaps/names?confinement=strict%2Cclassic"
Mar 24 15:53:18 xubuntu pulseaudio[4094]: [pulseaudio] bluez5-util.c: GetManagedObjects() failed: org.freedesktop.DBus.Error.TimedOut: Failed to activate service 'org.bluez': timed out (service_start_timeout=25000ms)
Mar 24 15:53:23 xubuntu systemd-resolved[1351]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.
Mar 24 22:26:04 xubuntu snapd[19322]: helpers.go:104: error trying to compare the snap system key: system-key versions not comparable



Komento grep -ir error /var/log/ on muuten sama kuin edellinen, mutta siihen on lisätty -r -määre. Se tarkoittaa sitä, että sanaa error etsitään kohdekansiosta, ja kaikista sen alikansioista. Haku siis kattaa useita tiedostoja, kun edellisessä haussa tarkasteltiin vain yhtä tiedostoa:

/var/log/apt/term.log:Enabling conf localized-error-pages.
/var/log/bootstrap.log:Selecting previously unselected package libgpg-error0:amd64.
/var/log/bootstrap.log:Preparing to unpack .../libgpg-error0_1.27-6_amd64.deb ...
/var/log/bootstrap.log:Unpacking libgpg-error0:amd64 (1.27-6) ...
/var/log/bootstrap.log:Setting up libgpg-error0:amd64 (1.27-6) ...
grep: /var/log/btmp: Permission denied
/var/log/dpkg.log:2019-08-05 18:57:44 install libgpg-error0:amd64 <none> 1.27-6
/var/log/dpkg.log:2019-08-05 18:57:44 status half-installed libgpg-error0:amd64 1.27-6
/var/log/dpkg.log:2019-08-05 18:57:44 status unpacked libgpg-error0:amd64 1.27-6
/var/log/dpkg.log:2019-08-05 18:57:44 status unpacked libgpg-error0:amd64 1.27-6
/var/log/dpkg.log:2019-08-05 18:57:46 configure libgpg-error0:amd64 1.27-6 <none>
/var/log/dpkg.log:2019-08-05 18:57:46 status unpacked libgpg-error0:amd64 1.27-6
/var/log/dpkg.log:2019-08-05 18:57:46 status half-configured libgpg-error0:amd64 1.27-6
/var/log/dpkg.log:2019-08-05 18:57:46 status installed libgpg-error0:amd64 1.27-6
Binary file /var/log/journal/40af2bd02340436792345e8c86eb1f80/system.journal matches
grep: /var/log/lightdm/x-0.log: Permission denied
grep: /var/log/lightdm/lightdm.log: Permission denied
grep: /var/log/speech-dispatcher: Permission denied
grep: /var/log/tallylog: Permission denied
/var/log/Xorg.0.log:	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
/var/log/Xorg.0.log.old:	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
/var/log/installer/dm:	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
/var/log/installer/dm:(panel:1825): Gtk-WARNING **: 15:52:41.070: Theme parsing error: <data>:6:33: The style property GtkWidget:focus-line-width is deprecated and shouldn't be used anymore. It will be removed in a future version
/var/log/installer/dm:(panel:1825): Gtk-WARNING **: 15:52:41.070: Theme parsing error: <data>:7:30: The style property GtkWidget:focus-padding is deprecated and shouldn't be used anymore. It will be removed in a future version
/var/log/installer/dm:xfsettingsd: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.
/var/log/installer/dm:XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":0"
/var/log/kern.log:Mar 24 15:52:36 xubuntu kernel: [    6.244415] RAS: Correctable Errors collector initialized.
/var/log/syslog:Mar 24 15:52:36 xubuntu kernel: [    6.244415] RAS: Correctable Errors collector initialized.
/var/log/syslog:Mar 24 15:52:36 xubuntu gpu-manager[1427]: Error: can't open /lib/modules/5.0.0-23-generic/updates/dkms
/var/log/syslog:Mar 24 15:52:36 xubuntu gpu-manager[1427]: Error: can't open /lib/modules/5.0.0-23-generic/updates/dkms
/var/log/syslog:Mar 24 15:52:36 xubuntu NetworkManager[1417]: <warn>  [1585065156.8887] Error: failed to open /run/network/ifstate
/var/log/syslog:Mar 24 15:52:36 xubuntu snapd[1409]: helpers.go:146: error trying to compare the snap system key: system-key missing on disk
/var/log/syslog:Mar 24 15:52:40 xubuntu snapd[1409]: stateengine.go:102: state ensure error: cannot decode new commands catalog: got unexpected HTTP status code 429 via GET to "https://api.snapcraft.io/api/v1/snaps/names?confinement=strict%2Cclassic"
/var/log/syslog:Mar 24 15:53:18 xubuntu pulseaudio[4094]: [pulseaudio] bluez5-util.c: GetManagedObjects() failed: org.freedesktop.DBus.Error.TimedOut: Failed to activate service 'org.bluez': timed out (service_start_timeout=25000ms)
/var/log/syslog:Mar 24 15:53:23 xubuntu systemd-resolved[1351]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.
/var/log/syslog:Mar 24 22:26:04 xubuntu snapd[19322]: helpers.go:104: error trying to compare the snap system key: system-key versions not comparable
grep: /var/log/boot.log: Permission denied

Ilmeisesti joidenkin tiedostojen/pakettien asentamisen kanssa oli jossain vaiheessa ongelmia: 

/var/log/dpkg.log:2019-08-05 18:57:44 install libgpg-error0:amd64 <none> 1.27-6
/var/log/dpkg.log:2019-08-05 18:57:44 status half-installed libgpg-error0:amd64 1.27-6
/var/log/dpkg.log:2019-08-05 18:57:44 status unpacked libgpg-error0:amd64 1.27-6
/var/log/dpkg.log:2019-08-05 18:57:44 status unpacked libgpg-error0:amd64 1.27-6
/var/log/dpkg.log:2019-08-05 18:57:46 configure libgpg-error0:amd64 1.27-6 <none>
/var/log/dpkg.log:2019-08-05 18:57:46 status unpacked libgpg-error0:amd64 1.27-6
/var/log/dpkg.log:2019-08-05 18:57:46 status half-configured libgpg-error0:amd64 1.27-6
/var/log/dpkg.log:2019-08-05 18:57:46 status installed libgpg-error0:amd64 1.27-6

Tehtäviä tehdessä en kuitenkaan törmännyt ongelmiin. Kaikki toimi niin kuin pitikin. Mikäli ongelmia kuitenkin ilmenisi, olisi niitä hyvä lähteä ratkomaan logien kautta. Grepistä voi lukea lisää esimerkiksi täältä.



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

Lopuksi tarkastelin keräämiäni kuormitustietoja. Kaksi erillistä ikkunaa olivat keränneet koko harjoituksen ajan tietoja suorittimen sekä muistin käytöstä.

Tässä vaiheessa tajusin tehneeni virheen. Ikkunat olivat taustalla kyllä keränneet dataa, mutta sitä dataa näkyi vain viimeiseltä vajaalta kahdelta tunnilta (tai sitten en osannut selata oikein). Olin kuitenkin tehnyt rasitustestit jo useita tunteja aiemmin. Minun olisi pitänyt saada kerättyä data johonkin tiedostoon.

/var/log/sysstat/ sijainnissa oli kaksi sa -tiedostoa, mutta niihin oli tallentunut tietoa vain kahden minuutin välein ja rasitustestin pituudeksi olin höhlänä laittanut vain 15 sekuntia, joten rasitusta oli vaikea todeta. Tulipahan tästäkin virheestä otettua opiksi.

Ajoin kuitenkin lopuksi vielä stressitestin komennolla stress -c 4 -i 3 -m 3 –vm-bytes 256M -t 30s. Suorittimen rasitus näkyi selkeästi, kun idle tippui nollaan. Muistin rasitus nousi vain hieman.

  • Suorittimen rasitus testissä. Idle tipahtaa nollaan ja %system ja %user yhteensä 100%
  • Muisti pienessä rasitustestissä. %memused ja %commit nousevat hiukan.
Sar -u ja sar -r

Lopetin tehtävien tekemisen 25.3.2020 klo 3:30 (UTC +2). Aikaa tähän kaikkeen meni noin 6,5 tuntia.

Lähteet

Tehtävä H7

Ratkaise valitsemasi vanha labraharjoitus

Tein tehtävän kotona pöytäkoneellani, jossa oli mm. Intel i5-3570K prosessori, 8GB RAM-muistia ja Asus GTX 1060 (6GB) näytönohjain. Xubuntua (18.04.3) käytin USB-tikulta kokeilutilassa.

Aloitin tehtävän tekemisen 17.3.2020 klo 11:30 (UTC +2). Xubuntun kello oli näytti aikaa 9:30 (UTC +0).

Valitsin tehtäväkseni kevään 2018 labraharjoituksen, jota voi tarkastella osoitteesta: http://terokarvinen.com/2018/arvioitava-laboratorioharjoitus-linux-palvelimet-ict4tn021-6-torstai-alkukevat-2018-5-op

Tehtävä:

## LAMP
Asenna LAMP (Linux, Apache, MySQL, PHP) ja testaa sen toiminta.
## Kuormitusta
Kerää kuormitustietoja koneelta koko harjoituksen ajalta. Analysoi tiedot tiiviisti aivan
harjoituksen lopuksi.
## Sorkka ja Rauta Oy:n CRM
Tarvitsemme asiakastietokannan. Tee tietokanta, jossa on seuraavat asiakkaat:
- Kulta ja Kaivos ky
- Piilosana ry
- MetalliMake
Tee PHP-ohjelma, joka lukee nämä tietueet. Laita tämä sivu näkyviin osoitteessa
http://sorkkacrm.example.com
Voit simuloida nimipalvelun toimintaa hosts-tiedoston avulla. Tässä harjoituksessa sivulle
pääsyä ei tarvitse rajoittaa salasanalla, vaan sen tule näkyä kaikkialle nettiin.
## Rosvoja porteilla
Onko koneellemme yritetty murtautua? (Kyllä). Etsi omalta paikalliselta koneeltasi todisteet
tapauksesta, jossa koneellesi on yritetty murtatua. Analysoi tiiviisti tähän liittyvät tiedot.
## Sorkan sivut
Tee staattinen HTML5 weppisivu, jonka otsikkona (molemmat title ja h1) on "Sorkka ja Rauta Oy".
Laita sivu näkyviin osoitteeseen http://rauta.example.com/ . Voit simuloida nimipalvelun toimintaa
hosts-tiedoston avulla.
## Einarin esimerkki
Einari Vähä-aho ryhtyy koodaamaan. Tee einarille käyttäjä 'einari'.
Tee einarille esimerkkikotisivu PHP:lla ja laita se näkymään osoitteessa http://localhost/~einari/ .
Esimerkkisivun pitää tulostaa "Einari" käyttäen PHP:n print-funktiota.
[Ohje päivittyi harjoituksen edetessä]

En ollut varma, oliko tarkoitus alkaa opettelemaan täysin uusia juttuja, vai soveltaa jo opittuja asioita. Päätin kuitenkin yrittää PHP:lla ja Sqlite3:lla. Käytin harjoituksessa apuna muiden opiskelijoiden tehtäväratkaisuja. Mm. näitä:

https://jesperikuula.wordpress.com/harjoitus-7/
https://jaanilinux.art.blog/2020/03/17/h7/


Tehtävän aloitus

Päivitin paketit komennolla sudo apt-get update.
Asensin Apachen komennolla sudo apt-get install -y apache2.

Tässä vaiheessa huomasin, että tehtävänannossa pyydettiin keräämään kuormitustietoja koko harjoituksen ajan. GNOME olisi ollut ilmeisesti yksi vaihtoehto monitorointiohjelmaksi, mutta päädyin kuitenkin Muniniin, jota Miia Koskinen käytti aikoinaan omassa harjoituksessaan.

Munin – monitorointiohjelma

Komennolla apt-cache search munin pääsis katselemaan eri asennusvaihtoehtoja. ”munin – network-wide graphing framework (grapher/gatherer)” vaikutti tarpeisiini sopivimmalta, joten asensin sen komennolla sudo apt-get install munin. Komennolla firefox /var/cache/munin/www/index.html selaimessa aukesi sivu, josta eri statistiikkoja pystyi tarkastelemaan.

Munin




Apachen asentaminen

Tässä vaiheessa siirryin takaisin Apacheen. Olin jo asentanut apachen, joten avasin käynnistin palomuurin ja avasin portit komennoilla:
sudo ufw enable
sudo ufw allow 80/tcp
sudo ufw allow 22/tcp

Kirjoitin selaimen osoiteriville ”localhost”, jolloin Apachen oletussivu avautui. Korvasin Apachen oletussivun komennolla echo Apachen oletussivu korvattu|sudo tee /var/www/html/index.html ja tarkistin muutoksen toimivuuden päivittämällä selaimesta localhostin.

Seuraavaksi annoin komennot, joilla mahdollistin käyttäjäkohtaisten sivujen luonnin.

sudo a2enmod userdir
sudo systemctl restart apache2

Testatakseni käyttäjäkohtaisten sivujen toimivuutta, tein käyttäjän Xubuntu kotihakemistoon kansion public_html, ja sinne nano-komennolla tiedoston index.html. Indexin sisällöksi kirjoitin ”Sivut kayttajalle Xubuntu”. Selaimen osoiteriville kirjoitin localhost/~xubuntu, jolloin käyttäjälle luomani sivu avautui.

Kuvia eri vaiheista

Tässä vaiheessa minun oli lopetettava tehtävän tekeminen. Kello oli 15:15 (UTC +2).

Jatkoin tehtävää kello 18:00 (UTC +2) tekemällä kaikki edellä mainitut toimenpiteet uudestaan


.

Sqlite3

Tietokantoja varten asensin Sqlite3:n komennolla sudo apt-get install -y sqlite3.

Käynnistin Sqlite3:n komennolla sqlite3. Tein testimielessä tietokannan alla olevan kuvan mukaisesti. Tuntui toimivan, joten siirryin PHP:n kimppuun.

Testitietokanta




PHP

Asensin PHP:n komennolla sudo apt-get -y install php libapache2-mod-php.

Tein testaamista varten virtualhostin komennolla sudoedit /etc/apache2/sites-available/phpkokeilu.conf. Tiedoston sisällöksi kirjoitin:

Laitoin oletusasetukset pois päältä, pistin phpkokeilu konffin päälle ja käynnistin apachen uusiksi komennoilla:

sudo a2dissite 000-default.conf
sudo a2ensite phpkokeilu.conf
sudo systemctl restart apache2

Tein kansiot /home/xubuntu/testi/kokeilu.com. Kansioon kokeilu.com loin tiedoston komennolla nano index.php, ja sen sisällöksi kirjoitin:

testi-php

Kävin muokkaamassa sudoeditillä hosts tiedostoa kohteessa /etc/hosts. Lisäsin sinne rivin 127.0.0.1 testi.com.

Kirjoitin selaimen osoiteriville testi.com, jolloin selain avasi php sivun näyttäen lukua 3 (1+1+1).

testi-php




Sorkka ja Rauta Oy:n CRM

Muokkasin phpkokeilu.confin seuraavanlaiseksi:

.conf -tiedosto

Restarttasin Apachen komennolla sudo systemctl restart apache2, jotta asetus tulisi voimaan.

Komennolla sudoedit /etc/hosts muokkasin hosts-tiedostoa lisäämällä sinne rivin 127.0.0.1 sorkkacerm.example.com.

Tein index.php -tiedoston seuraavanlaiseen polkuun:
/home/xubuntu/sorkkacrm/sorkkacrm.example.com/index.php

Tein siis sorkka-kansiot ennen tiedoston luomista…

index.php tiedostoon kirjoitin seuraavat rivit:

.php

Testasin sivun toimivuuden kirjoittamalla selaimen osoiteriville sorkka.example.com, jolloin php -sivu avautui.

sorkka.example.com




Sorkka tietokanta

Tein kansioon sorkka.example.com tietokannan nimeltä sorkkacrm.db käyttäen komentoja:

touch sorkkacrm.db
sqlite3 sorkkacrm.db

Olisikohan pelkkä sqlite3 sorkkacrm.db riittänyt komennoksi? Lisäsin asiakkaat tietokantaan kuvan mukaisilla komennoilla:

Muokkasin aiemmin luomaani index.html tiedostoon alla näkyvän koodin:

<?php
        $db = new SQLite3('sorkkacrm.db');
        $tablesquery = $db->query("SELECT nimi FROM Asiakkaat;");
        //$tables = $tablesquery->fetchArray(SQLITE3_ASSOC));

while ($table = $tablesquery->fetchArray(SQLITE3_ASSOC))
 {
                echo $table['nimi'].'<br />';
        }
?>

Menin selaimella osoitteeseen sorkkacrm.example.com, jolla näkyi Sorkka ja Rauta Oy:n asiakkaat.

Asiakastietokanta näkyy sivuilla.




HTML5 webbisivu

Tein index.html tiedoston polkuun /home/xubuntu/rauta/rauta.example.com/index.html.

Indexin sisällöksi kirjoitin:

<!DOCTYPE html>
<html>
<head>
<title> Sorkka ja Rauta Oy</title>
</head>
<body>
<h1>Sorkka ja Rauta Oy</h1>
</body>
</html>

Tein uuden asetustiedoston komennolla sudoedit /etc/apache2/sites-available/rauta.example.conf

<VirtualHost *:80>
        ServerName rauta.example.com
        ServerAlias www.rauta.example.com

        DocumentRoot /home/xubuntu/rauta/rauta.example.com

        <Directory /home/xubuntu/rauta/rauta.example.com>
                require all granted
        </Directory>
</VirtualHost>

Otin asetukset käyttöön komennoilla:

sudo a2ensite rauta.example.conf
sudo systemctl restart apache2

Avasin hosts -tiedoston komennolla sudoedit /etc/hosts ja lisäsin sinne rivin 127.0.0.1 rauta.example.com.

Avasin selaimella osoitteen http://rauta.example.com/, jolloin Sorkka ja Rauta Oy:n sivu avautui.

Firman sivut.




Einarin php-sivu

Kommentoin ensin komennolla sudoedit /etc/apache2/mods-available/php7.2.conf viisi viimeistä riviä pois, jotta käyttäjät voisivat käyttää php-tiedostoja.

Restarttasin sudo systemctl restart apache2.

Loin uuden käyttäjän komennolla sudo adduser einari antaen hyvän salasanan. Kirjauduin einarina sisään su – einari. Tein einarille public_html kansion ja sinne index.php -tiedoston. Tiedoston sisällöksi kirjoitin:

<?php
print"Einari"
?>

Avasin selaimella osoitteen localhost/~einari, jolloin einarin sivu avautui.

Einarin sivut.




Kuormitustietojen analysointi

Ihan koko harjoituksen ajalta en saanut kuormitustietoja, sillä aloitin harjoituksen teon kolme kertaa uudelleen. Komennolla firefox /var/cache/munin/www/index.html pystyin selaimessa tarkastelemaan tietoja. Olin tässä vaiheessa touhunnut tämän tehtävän parissa noin kymmenen tuntia, joten en kovin tarkasti kerennyt enää perehtymään Muniniin. Ei näyttänyt olevan kovinkaan kummoisia kuormituksia. CPU:ssa näkyi hienoisia piikkejä ajoittain, mikä mahdollisesti johtui ohjelmien asennuksista yms.

Munin CPU

Tehtävän tekemisen lopetin 17.3.2020 klo 0:30 (UTC +2), mutta raportoinnin viimeistelyä jatkoin vielä jonkin aikaa.

PHP ja SQL olivat minulle suhteellisen uusia juttuja, ja niiden parissa meni todella paljon aikaa. Kokeilin alkuun Mariadb:tä ja MySQL:ää, mutta jumituin niiden kanssa aina johonkin kohtaan. Hankaluuksia oli sen verran paljon, että niiden raportointiin olisi kulunut monta tuntia lisää aikaa. Apachen error.logia käytin apuna melko paljon. Lopulta sain tehtyä tehtävän SqLite3:lla. Muiden oppilaiden esimerkkiratkaisut olivat suureksi hyödyksi. Aikaa tehtävän tekemiseen meni tosiaan noin kymmenen tuntia, josta raportointiin suurin osa.



Lähteet

Tehtävä H6

Tietokantaa käyttävä ohjelma

Tein tehtävän kotona pöytäkoneellani, jossa oli mm. Intel i5-3570K prosessori, 8GB RAM-muistia ja Asus GTX 1060 (6GB) näytönohjain. Xubuntua (18.04.3) käytin USB-tikulta kokeilutilassa.

Aloitin tehtävän tekemisen klo 10.3.2020 klo 20:30 (UTC +2). Xubuntun kello näytti 18:30 (UTC +0).

a) Tietokanta wepissä. Tee oma yksinkertainen, tietokantaa käyttävä ohjelma. Ohjelmalla tulee olla jokin käyttötarkoitus. Voit tehdä ohjelman muokkaamalla Teron koodia (muista lähdeviite).

b) Laita tietokantaohjelmasi toimimaan mod_wsgi:n kanssa.


Apachen ja Flaskin asennus ja testaus.

Päivitin paketit, asensin Apachen ja availin portin aiemmin tekemäni tehtävän H3 mukaisesti. Tein testisivuja ja testasin niiden toiminnan, kuten tuossa aiemmassa harjoituksessakin.

Asensin Flaskin aiemmin tehdyn tehtävän H5 mukaisesti. Testasin Flaskin toiminnan testiympäristössä, sekä tuotantotyyppisessä ympäristössä samalla tavalla kuin tehtävässä H5.

  • Flask testiympäristössä
  • Flaskin testausta ja käyttäjän luomista
  • Flask tuotantotyyppisessä ympäristössä



Tietokantaa käyttävän ohjelman luominen



Halusin luoda Fiilisseinän, johon käyttäjä voisi kirjoittaa viikonpäivän, fiiliksensä sekä oman nimimerkkinsä. Minulla oli xubuntu-käyttäjän kansiossa Flaskin testauksessa käyttämäni kansio nimeltä flask. Tein kyseiseen kansioon tiedoston nimeltä autoformed.py. Tiedostoon kopioin Tero Karvisen tekemän mallin mukaisen sisällön, jota hiukan muokkasin:

  GNU nano 2.9.3                                                                                                                    autoformed.py                                                                                                                              

#!/usr/bin/python3
"RSVP autoform"
# Copyright 2020 Tero Karvinen http://TeroKarvinen.com

from flask import Flask, render_template, flash, redirect
from flask_sqlalchemy import SQLAlchemy
from wtforms.ext.sqlalchemy.orm import model_form
from flask_wtf import FlaskForm
import wtforms

app = Flask(__name__)
db = SQLAlchemy(app)
app.config["SQLALCHEMY_DATABASE_URI"] = "sqlite:///autoformed.db"
app.config["SQLALCHEMY_TRACK_MODIFICATIONS"] = False
app.config["SECRET_KEY"] = "dUCF)mtd9MAoZ?;R|8*iB^.+TCV//0"

class Reply(db.Model):
        id = db.Column(db.Integer, primary_key=True)
        Viikonpäivä = db.Column(db.String, nullable=False)
        Fiilis = db.Column(db.String, nullable=False)
        Nimimerkki = db.Column(db.String, nullable=False)

field_args = { "email": {"validators": [wtforms.validators.Email()]} }
ReplyForm = model_form(model=Reply, base_class=FlaskForm, db_session=db.session, field_args=field_args)

@app.before_first_request
def beforeFirstRequest():
        db.create_all()

@app.route("/", methods=["GET", "POST"])
def index():
        form = ReplyForm()

        if form.validate_on_submit():
                reply = Reply()
                form.populate_obj(reply)
                db.session.add(reply)
                db.session.commit()
                flash("Kiitos vastauksestasi ja mukavaa päivänjatkoa! :)")
                return redirect("/")
        replies = db.session.query(Reply)
        return render_template("replies.html", form=form, replies=replies)

def main():
        app.run(debug=True)

if __name__ == "__main__":
        main()

Seuraavaksi siirryin /xubuntu/flask/templates/ -kansioon, joka minulla oli valmiina aiemman Flaskin testauksen vuoksi. templates -kansiossa oli myös valmiina base.html -tiedosto, jonka sisällöksi koipioin Tero Karvisen sivuilla olevan mallin mukaiseksi. Muokkasin sisältöä sen jälkeen vielä hiukan:


<!doctype html>
<html lang=en>
        <head>
                <title>Fiilisseinä</title>
                <meta charset="utf-8">
        </head>
        <body>
                {% with messages = get_flashed_messages() %}
                {% if messages %}
                <ul class=flashes>
                        {% for message in messages %}
                        <li>{{ message }}</li>
                        {% endfor %}
                </ul>
                {% endif %}
                {% endwith %}

                {% block body %}
                <h1>Tervehdys!</h1>
                {% endblock %}
        </body>

</html>

Tämän jälkeen loin /xubuntu/flask/templates/ -kansioon tiedoston nimeltä replies.html. Tiedoston sisällön kipioin jälleen Tero Karvisen sivuilta, minkä jälkeen muokkasin sitä mieleisekseni:

{% extends "base.html" %}
{% block body %}
<h1>Mikä on tämän hetkinen fiiliksesi?</h1>
<form method=post action="/">
        {{ form.csrf_token }}
        {% for field in form if not field.name in ["csrf_token"] %}
                <p>{{ field.label }}: {{ field }} <b>{{ " ".join(field.errors) }}</b></p>
        {% endfor %}
        <input type="submit">
</form>

<h2>Vastaukset:</h2>
{% for reply in replies %}
<b>{{ reply.Viikonpäivä }}</b>
<p>{{ reply.Fiilis }}</p>
<p>{{ reply.Nimimerkki }}</p>

{% endfor %}

{% endblock %}



Tietokantaohjelman testaus



Nyt pääsin testaamaan ohjelman toimivuutta. Käynnistin ohjelman python3 autoformed.py -komennolla. Komentokehotteeseen tuli seuraavanlainen virheilmoitus:

sqlalchemy asentamatta.

Minulta puuttui sqlalchemy -moduuli. aloin etsimään sopivaa moduulia komennolla apt-cache search flask_sqlalchemy. Sain listan useista vaihtoehdoista, valitsin python3-flask-sqlalchemyn, jonka asensin komennolla sudo apt-get install python3-flask-sqlalchemy.

Koitin jälleen käynnistää tietokantaohjelmaa, mutta sain taas uuden virheilmoituksen.

wtforms asentamatta.

Minun täytyi vielä asentaa wtforms -moduuli. Etsin sitä komennolla apt-cache search wtforms. Sain taas useita vaihtoehtoja, joista valitsin python3-flashext.wtf:n. Asensin sen komennolla sudo apt-get install python3-flaskext.wtf.

Kokeilin taas käynnistää tietokantaohjelmaa, eikä uusia virheilmoituksia tullut. Kirjoitin selaimen osoiteriville localhost:5000, minkä jälkeen lomake avautui. Täytin vaaditut kentät pariin kertaan, ja kirjoittamani asiat tulostuivat sivulle. /xubuntu/flask/ -kansioon ilmestyi autoformed.db -nimiden tiedosto, mikä kaiketi piti sisällään tietokannan, joka oletettavasti täydentyi sitä mukaa kun kirjoitin lomakkeeseen uusia tietoja.

Fiilisseinä testiympäristössä.



Fiilisseinän kopiointi testiympäristöstä tuotantotyyppiseen ympäristöön



Kopioin testiympäristöstä /home/xubuntu/flask kaikki kolme tiedostoa (autoformed.py, base.html ja replies.html) kansioihin /home/joniwsgi/public_wsgi/ ja /home/joniwsgi/public_wsgi/templates/ (joniwsgi:n olin luonut aiemman Flask-testiasennuksen yhteydessä). joniwsgi-kansiossa olleeseen tiedostoon nimeltä joni.wsgi (Flaskin testiasennuksen jäljiltä), muokkasin tiedoston sisällöstä kohdan hello -> autoformed.

Tiedostot ja niiden lopulliset sijainnit käyvät paremmin ilmi alla olevasta kuvasta:

Siirrettyäni tiedostot testiympäristöstä tuotantotyypiseen ympäristöön, minun olisi pitänyt turvallisuussyistä poistaa autoformed.py tiedostosta debuggaus rivi. En ollut varma, miten kyseinen kohta poistetaan oiekaoppisesti, joten annoin sen olla. (def main riviä ei ollut tehtävän H5 Flask-harjoituksessa.)

Annoin komennon touch joni.wsgi, jotta muutokset tulisivat voimaan, minkä jälkeen käynnistin ohjelman komennolla python3 autoformed.py. Sain komentoriville alla olevan ilmoituksen. 

/usr/lib/python3/dist-packages/flask_sqlalchemy/__init__.py:800: UserWarning: SQLALCHEMY_TRACK_MODIFICATIONS adds significant overhead and will be disabled by default in the future.  Set it to True to suppress this warning.
  warnings.warn('SQLALCHEMY_TRACK_MODIFICATIONS adds significant overhead and will be disabled by default in the future.  Set it to True to suppress this warning.')
 * Running on http://127.0.0.1:5000/ (Press CTRL+C to quit)

En ymmärtänyt mitä kyseinen teksti tarkoittaa. Jos jotain pitäisi arvata, niin veikkaisin kyseisen tekstin liittyvän debuggaukseen, mutta voin olla väärässäkin.

Kirjoitin selaimen osoiteriville localhost, minkä jälkeen Fiilisseinä avautui. Täydensin lomakkeen kohdat, ja täyttämäni tiedot tulostuivat ruudulle.

Fiilisseinä tuotantotyyppisessä ympäristössä.

Kansioon /joniwsgi/public_wsgi/ ilmestyi autoformed.db tietokantatiedosto. Totesin ohjelman toimivan, ja totesin tehtävän suoritetuksi.

Lopetin tehtävien tekemisen 11.3.2020 klo 2:40 (UTC +2). Xubuntun kello näytti aikaa 00:40 (UTC +0).



Lähteet:

Design a site like this with WordPress.com
Aloitus