Palvelinten hallinta – kurssityö sekä h6

Kurssityön tehtävänä oli asentaa jokin vapaasti valittava ohjelma  Saltin kautta. Valitsin aiheekseni pilvipalvelu NextCloudin asentamisen.

Ohessa linkki projektiin GitHubissa:

https://github.com/Miikkb/nextcloudwithsalt

Tässä myös video, missä esittelen lyhyesti tilan toiminnan:

c) Käyttäjäryhmä:

Moduuli sopii henkilöille, jotka haluavat testimielessä kokeilla oman pilvipalvelun asentamista. Tilaa on myös hyödyllistä käyttää tilanteissa, missä tarvitaan pikaisesti pilvipalvelutilaa, kuten esimerkiksi tilanteessa, jossa pitää siirtää tiedostoja netin välityksellä.

Lopuksi lyhyt tekstiarvostelu luokkatoverin moduulista: https://github.com/kristiansyrjanen/teamspeak3-salted, Kristian Syrjäsen TeamSpeak 3 palvelimen asennus.

Heti aluksi tilasta voi sanoa, että README.md selittää sen toiminnan ja tekoprosessin hyvin. Ei jää epäselväksi, mitä tila oikeasti tekee. Asennusprosessi etenee loogisessa järjestyksessä, ensiksi asennetaan ja konfiguroidaan asennukseen tarvittavat ohjelmat, eli siis salt-master ja salt-minion.

Ennen itse TeamSpeakin asennusta tila varmistaa, että palomuuri on asennettu, ja syöttää omat porttitietonsa hyväksyttyjen listalle. Tiedot lisätään mielenkiintoisesti .rules tiedostoina, eikä vain komentoriville syötettävinä komentoina, kuten esim. sudo ufw allow xxxx.

Kristianin tila hoitaa TeamSpeakin asennustiedostojen käsittelyn paljon järkevämmin kuin minä omassa tilassani. Erona tosin se, että itse yritin hoitaa sitäkin salt staten kautta, kun taas Kristian tekee sen bash-skriptin kautta, jolloin se näyttäisi olevan yksinkertaisempaa.

Koko prosessi näyttää tilan kautta melko vaivattomalta. Asennus on tehty helpoksi. Se on hiukka erikoista, että asennus toimii vain livetikulta, mutta ilmeisesti sitä on yritettykin korjata melkolailla.

Tila näyttäisi toimivan oikein siitä huolimatta. Kehitysmahdollisuutena tietysti se, että tilan voisi ajaa muullakin koneella kuin livetikulla.

Posted in Uncategorised | Leave a comment

Palvelinten hallinta – h5

http://terokarvinen.com/2018/aikataulu-%e2%80%93-palvelinten-hallinta-ict4tn022-4-ti-5-ke-5-loppukevat-2018-5p#h5

Tehdään viides tehtävä, tarkoituksena on valita aihe kurssityölle, julkaista MarkDownilla raportti sekä suorittaa jokin salt suoraan gitistä.

Teen harjoituksen virtuaalipalvelimellani, jossa pyörii Ubuntu 16.04.4. Muodostan hallintayhteyden SSH:lla.

a) Varasin aiheen NextCloudin asennuksen.

b) Seuraavaksi julkaistaan MarkDownilla raportti GitHubiin.

Aloitetaan tekemällä tyhjä GitHub repo.

Kun on kirjauduttu sisään, voidaan uusi repo tehdä aloitussivulta, New repository.

Harjoituksessa tein repon nimeltä Harkka, tein siitä yksityisen ja lisäsin lisenssiksi GPL v3, jotta repo ei ole täysin tyhjä.

Tehdään kotihakemistoon uusi kansio, harkka.

$ mkdir harkka && cd harkka

Jotta saadaan git tulille, ajetaan komennot:

$ git init && git add .

Nyt git hakemisto on luotu. Kirjoitetaan README tiedosto MarkDownia hyväksikäyttäen.

$ nano README.md.

Tiedosto sisältää seuraavan:

This is a README file created with MarkDown.

MarkDown is enabled automatically, when the file ends with .md.

# Hello

## Hello

### Hello

Line

*****

Line

Tehdään vielä huvinvuoksi tyhjä tekstitiedosto, jotta saadaan lisää commitattavaa.

$ touch foo.txt

Lisätään muutokset committiin, tehdään commit, ja tungetaan muutokset gittiin:

$ git add . && git commit

$ git pull && git push

Nyt kun muutokset on ajettu gittiin, yhdistetään tehty git GitHubiin.

Tämä tapahtuu seuraavasti:

$ git remote add origin https://github.com/Miikkb/Harkka

$ git remote -v

$ git push origin master

Jos kaikki on mennyt onnellisesti oikein, GitHubissa pitäisi olla luodut tiedostot:

Homma toimii, ja MarkDownilla tehty raportti näkyy READMEnä.

Seuraavaksi c):

Käytän tehtävän pohjana omaa Sirottimen kaltaista tilaa, joka on kesken ja huomattavasti pienempi.

GitHubista repo voidaan ladata komennolla:

$ git clone https://Miikkb/Miikkb

Kun repo on kloonattu, ajetaan tila ohjeiden mukaisesti:

$ sudo bash run.sh

Salt asennetaan tilan mukana jos sitä ei ole, ja salt ilmoittaakin, että 5 muutosta onnistui. Listaa selaamalla selviää, että kun on ajettu komento sudo apt update, niin app-repositoryn tiedot ovat päivittyneet.

Tila on kloonattu GitHubista ja ajettu onnistuneesti.

Posted in Uncategorised | Leave a comment

Palvelinten hallinta – h4

H4

http://terokarvinen.com/2017/multiple-virtual-computers-in-minutes-vagrant-multimachine

http://terokarvinen.com/2018/aikataulu-%e2%80%93-palvelinten-hallinta-ict4tn022-4-ti-5-ke-5-loppukevat-2018-5p#h4

Tehtävänä on tehdä kahdella orjalla esimerkki, jossa orjat saavat eri muuttujan pilarista. Tarkista ‘pillars.items’, että kummallekin orjalle mene eri tieto.

Harjoitus tehdään omalla koululäppärillä, jossa Xubuntu 16.04.4, vagrantia hyväksikäyttäen. Orjat siis tehdään vagrantin kautta virtuaalisesti. Ohjeet vagrantin käyttöönottoon löytyy Tero Karvisen sivulta http://terokarvinen.com/2017/multiple-virtual-computers-in-minutes-vagrant-multimachine.

Tehdään tehtävä niin, että tmp kansioon ilmestyy molemmalle orjalle tiedosto, mutta tiedoston sisältö on orjilla eri. c) kohta vaatii, että tilaan lisätään oletusarvo, mikäli jollekkin orjalle ei anneta omaa arvoa pilarin kautta. Tehdään kohta c) samalla, kuin b).

Aloitetaan tekemällä kansiot ja tarvittavat tiedostot:

$ sudo mkdir /srv/salt/pillartest

$ sudo nano /srv/salt/pillartest/init.sls

/tmp/pillartest.txt:
  file.managed:
    - source: salt://pillartest/pillartest.txt
    - template: jinja
    - context:
      sana: {{ pillar.get(’sana’, lintu) }}

Lintu täyttää siis oletusarvon virkaa, mutta tässä vaiheessa kaikille orjille annetaan arvo pilarin kautta, joten sitä ei pitäisi näkyä missään.

Ennen pillarien tekemistä, tehdään pillartest.txt:

$ sudo nano /srv/salt/pillartest/pillartest.txt

Sup! This file is called pillartest. Here's a test word:

sana: {{ sana }}

Tehdään seuraavaksi pillar kansio, ja sinne top.sls tiedosto:

$ sudo mkdir /srv/pillar

$ sudo nano /srv/pillar/top.sls

base:
  vagrant1
    - vagrant1
  vagrant2
    - vagrant2

Tehdään molemmille .sls tiedostot:

$ sudo nano vagrant1.sls

sana: kissa

$ sudo nano vagrant2.sls

sana: koira

Kun tiedostot ja kansiot on tehty, voimme kokeilla toimintaa komennolla:

$ sudo salt ’*’ state.apply pillartest

Ruutu täyttyy vihreästä ja sinisestä tekstistä, joten kaikki on oletettavasti mennyt nappiin. Tarkistetaan tilanne orjakoneilta:

Pillareita on siis hyödynnetty oikein, orjille on mennyt eri sana.

Tässä vaiheessa kohta b) on täytetty, c) kohdan voimme luultavasti tehdä niinkin helposti, kuin että poistamme vagrant2.sls tiedoston. Silloin orjan pitäisi käyttää oletusarvoa, joka on lintu.

Poistettuani tiedoston yritin ajaa tilan uudestaan, ja kakkosorja heittää virheviestiä, joka on seuraava:

Rendering SLS ’base:pillartest’ failed: Jinja variable ’lintu’ is undefined

Koska ainoastaan kakkosorja heittää virhettä, se luultavasti johtuu siitä, että oletusarvoa ei jostain syystä lueta oikein. Luonnollisesti tiedostoissa ei ole tapahtunut mitään muutosta.

Konsultoin Jaakko Veijosta, http://veijonen.com, joka huomautti init.sls tiedostoni sisällöstä: oletusarvo lintu tulisi myös laittaa hipsuihin, eli ’lintu’. Jätin alunperin hipsut laittamatta, koska seurasin viimetunnilla käytyjä esimerkkejä, joissa ssh:n porttia vaihdettaessa oletusarvo 22 kirjoitettiin ilman hipsuja. Arvelen, että hipsuja ei tarvita mikäli oletusarvo on numero, sen ollessa string, hipsut tarvitaan.

Korjattu init.sls näyttää siis tältä:

/tmp/pillartest.txt:
  file.managed:
    - source: salt://pillartest/pillartest.txt
    - template: jinja
    - context:
      sana: {{ pillar.get(’sana’, ’lintu’) }}

Korjattuna tila menee läpi, ja näyttää seuraavalta:

Tehtävä c) on siis suoritettu.

Posted in Uncategorised | Leave a comment

Blogin siirto valmis / Blog transfer complete

Postaukset on siirretty uudelle sivulle. Uudella sivulla näkyy, että jokainen postaus olisi tehty yhdessä päivässä, mikä ei tietenkään pidä paikkaansa, joten lisään postauksiin alkuperäiset päivämäärät.

Posts have now been moved to the new site. The dates on the posts are wrong, because I moved them on the same day, so I will include the original dates in them.

Posted in Uncategorised | Leave a comment

Palvelinten hallinta h3

H3

http://terokarvinen.com/2018/aikataulu-%e2%80%93-palvelinten-hallinta-ict4tn022-4-ti-5-ke-5-loppukevat-2018-5p#h3

Käytän tehtäviin Masterina vuokrattua virtuaalipalvelinta, jossa Ubuntu 16.04.4. Minionina toimii koululäppäri tuoreelta livetikulta, jossa Xubuntu 16.04.3.

Aloitetaan tilanteesta, missä hallintasuhde on jo muodostettu.

HUOM. WordPress on hyvä tuhoamaan sisennyksiä, kiinnitä huomiota niihin, mikäli kopioit tekstiä suoraan. Sisennys = 2 väliä.

 

b)

Tehdään kohtaa varten oma kansio, jinja1:

$ sudo mkdir /srv/salt/jinja1

Jonne seuraavat tiedostot:

$ sudo touch /srv/salt/jinja1/init.sls && sudo touch /srv/salt/jinja1/testi.txt

Init.sls tiedoston sisällöksi laitamme seuraavan:

{% for file in ['testi.txt'] %}

/tmp/testi/{{ file }}:
  file.managed:
    - source: salt://jinja1/testi.txt
    - makedirs: True
  - template: jinja
  - context:
  file: {{ file }}

{% endfor %}

Koodin pitäisi paikata jokainen {{ file }} tekstillä testi.txt, eli siis sen pitäisi luoda tiedosto testi.txt.

Tehdään testi.txtille sisältöä:

This is {{ file }}!

Kokeillaan tilaa:

$ sudo salt ’*’ state.apply jinja1

Tiedosto on ilmestynyt onnistuneesti, joten tila toimii.

c)

Kohdassa c) tehdään lähes samaa, mutta kerralla useampia tiedostoja. Muokataan aikaisemmin tehtyä tiedostoa init.sls:

{% for file in ['testi.txt', 'joonas.txt', 'marko.txt', 'kissa.txt', 'tero.txt'] %}

/tmp/testi/{{ file }}:
  file.managed:
    - source: salt://jinja1/testi.txt
    - makedirs: True
    - template: jinja
    - context:
    file: {{ file }}

{% endfor %}

Muokataan vielä tiedostoa testi.txt, jotta tiedämme että muutos on oikeasti tapahtunut:

For loops with jinja

This is {{ file }}!

Nyt tilan pitäisi luoda 4 uutta tiedostoa, ja muokata viimeksi tehtyä testi.txt tiedostoa.

Kokeillaan samalla komennolla kuin aikaisemminkin:

$ sudo salt ’*’ state.apply jinja1

Tila menee läpi ja tiedostot muuttuvat, homma siis toimii.

d)

Seuraavaksi pitää konfiguroida SSH-demoni toiseen porttiin jinjan avulla. Tehdään aluksi uusi kansio:

$ sudo mkdir /srv/salt/jinja2 && cd /srv/salt/jinja2

Kopioidaan sshd_config tiedosto, jotta voidaan tehdä muutoksille pohja:

$ sudo cp /etc/ssh/sshd_config /srv/salt/jinja2/

Muutetaan tiedoston sisällä porttinumero 1337:ksi.

Laitetaan init.sls tiedosto kuntoon:

{% for port in ['1337'] %}

ssh:
  pkg.installed

/etc/ssh/sshd_config:
  file.managed:
  - source: salt://jinja2/sshd_config
  - makedirs: True
  - template: jinja
  - context:
  file: {{ port }}

{% endfor %}

Tiedostoa ajettaessa salt heittää parsing erroria, virheilmoituksen saat näkyviin oheisesta painikkeesta :

 

Tutkittuani virhettä, löysin seuraavan keskustelun:

https://github.com/saltstack/salt/issues/8549

Sivu neuvoi kiinnittämään huomiota tiedoston sisennyksiin, mutta mielestäni se oli kunnossa, joten arvelen virheen johtuvan context: kentästä. Pyörittelin myös muita ratkaisuja, joita etsin sivulta http://terokarvinen.com/2018/make-a-million-of-those-jinja-templating-salt-states, niin että lopulta tiedosto näytti tältä:

{% for port in ['1337'] %}

ssh:
  pkg.installed

/etc/ssh/sshd_config:
  file.managed:
    - source: salt://jinja2/sshd_config
    - makedirs: True
    - template: jinja
    - context:
    port: {{ port }}

{% endfor %}

Luulen, että tarkemmin vika johtui context: kentästä. En täysin ymmärrä, mistä ensimmäinen port tulee, mutta {{ port }} on looginen. Joka tapauksessa tila meni onnistuneesti läpi korjattuna.

Testataan yhdistämistä paikallisesti livetikkukoneelta, jotta vältytään porttien avaamiselta

Minionilla:

$ ssh xubuntu@xubuntu -p 1337

Yhteys menee läpi ja kysyy salasanaa, tila siis asentaa SSH:n oikein ja muuttaa portin 1337:ksi.

e)

Lopuksi kokeillaan toisen opiskelijan tekemää salt-tilaa.

Lainaan Jaakko Veijosen tilaa, jossa asennetaan ja konfiguroidaan sysstat.

http://veijonen.com/h2p.html

Toimin raportoinnin mukaan.

Raportoinnista valitan sen verran, että itseäni ärsyttää se, etten pysty dokumentoinnin perusteella toimimaan suoraan, sillä raportointi jättää mahdollisuuden käyttäjävirheisiin esimerkiksi kohdassa:

Kopioin /etc/default/sysstat -tiedoston /srv/salt/sysstat -kansioon nimellä “default”, ja /etc/cron.d/sysstati:in samaan kansioon nimellä “cron.d”.”

Ohjeet käyvät kansioluonnit melko nopeasti, ja jää hieman epäselväksi, miten kansiorakenne oikeasti menee. Sysstat kansion init.sls tiedostossa tuntuu olevan pieniä ristiriitoja raportoinnin kanssa.

Mielestäni raportoinnin olisi helposti voinut tehdä niin, että annetut komennot tekevät kansiot automaattisesti niin, että lukijan täytyy apinoida komennot, ja asiat toimivat suoraan.

Keskusteltuani asiasta Jaakon kanssa, tulimme siihen tulokseen, että ohjeet ovat hiukka epäselvästi kirjoitettu ja ymmärsin niitä väärin.

Joka tapauksessa, viilasin init.sls tiedoston ja kansiorakenteen sellaiseksi, kuin miten sen itse ymmärsin ja sen perusteella tekisin:

sysstat:
  pkg.installed

/etc/default/sysstat:
  file:
    - managed
    - source: salt://sysstat/default/sysstat

/etc/cron.d/sysstat:
  file:
    - managed
    - source: salt://sysstat/default/cron.d

sysstatservice:
  service.running:
    - name: sysstat
    - watch:
      - file: /etc/default/sysstat
      - file: /etc/cron.d/sysstat

 

Kansiorakenne on seuraava:

/srv/salt/
├── jinja1
│   ├── init.sls
│   └── testi.txt
├── jinja2
│   ├── init.sls
│   └── sshd_config
├── sysstat                       
│   ├── default             
│   │   ├── cron.d     
│   │   └── sysstat  
│   └── init.sls
└── top.sls

Muokattuna tila toimii. Luultavasti tila olisi myös toiminut Jaakon tavalla, mikäli tiedostot saa oikeille paikoilleen, toisin kuin itse sain.

Posted in Uncategorised | Leave a comment

Palvelinten hallinta h2

Alkuperäinen päivämäärä 8.4.2018

H2

http://terokarvinen.com/2018/aikataulu-%e2%80%93-palvelinten-hallinta-ict4tn022-4-ti-5-ke-5-loppukevat-2018-5p#h2

http://terokarvinen.com/2018/apache-user-homepages-automatically-salt-package-file-service-example

https://github.com/saltstack/salt/wiki/Cheat-Sheet suosittelen tätä cheat sheettiä kaikille saltista kiinnostuneille, tiivistää tehokkaasti kaikki yksinkertaiset asiat, ja mukana myös muuta jännää.

Harjoituksissa on tehty virtuaalipalvelimesta master, ja koulukannettavasta minion. Palvelimella on käytössä ubuntu 16.04, kannettavalla xubuntu 16.04 jota käytetään livetikulta. Virtuaalipalvelinta hallitaan SSH-yhteydellä.

b), c) ja e) Laita käyttäjien kotisivut toimimaan Apachella, laita PHP toimimaan käyttäjien kotisivuilla, tee tila, joka laittaa esimerkkisivun uusille käyttäjille.

Ensimmäisenä tehtävänä on saada käyttäjien kotisivut toimimaan automaattisesti saltin tilan kautta.

Lähdetään tilanteesta, missä tarvittavat ohjelmistot, salt-minion ja salt-master, ovat jo asennettu tietokoneille, joita halutaan hallita, ja että hallintayhteys on jo muodostettu.

Hallintatietokoneelle tehdään tarvittavat kansion apachen asennusta varten:

$ sudo mkdir /srv/salt/apache

Tehdään samalla esimerkkikotisivu, joka kopioidaan vapaavalintaisella tekstillä:

$ sudo nano /srv/salt/apache/index.php

Tehdään apache kansioon tiedosto init.sls:

$ sudo nano /srv/salt/apache/init.sls

Asetetaan tila niin, että se asentaa apache2, php-moduulin, sekä luo esimerkkisivun. Lisäksi tila muokkaa skeliä niin, että uudet käyttäjät saavat käyttäjäsivun valmiiksi ja pystyvät käyttämään PHP:tä halutessaan. HUOM. Koko teksti kuuluu yhteen pötköön, välissä olevat kommentit selittävät sen toimintaa, eivätkä tarkoita ylimääräisiä välejä missään.

install_apache:
  pkg.installed:
    - pkgs:
      - apache2
      - libapache2-mod-php

/var/www/html/index.php:
  file:
    - managed
    - makedirs: true
    - source: salt://apache/index.php

/var/www/html/index.html:
  file:
    - absent

Tämä osa varmistaa apachen asennuksen, ja luo esimerkkisivun, samalla poistaen index.html tiedoston, minkä tilalle .php päätteinen tulee.

/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

/etc/apache2/mods-enabled/php7.0.conf:
  file:
    - managed
    - source: salt://apache/php7.0.conf

Tämä aktivoi käyttäjähakemistomoduulin, sekä PHP:n käyttäjähakemistoissa.

/etc/skel/public_html/index.php:
  file:
    - managed
    - makedirs: true

Lopuksi automatisoidaan käyttäjähakemistojen tekeminen siten, että käyttäjille luodaan valmiiksi sivu skelin kautta. Apache uudelleenkäynnistetään myöhemmässä vaiheessa.

HUOM! YAMLissa sisennykset toimivat välilyönneillä, joten ole tarkkana, että sisennykset säilyvät mikäli kopioit suoraan. Sisennys = 2 väliä.

Luodaan /srv/salt kansioon tiedosto top.sls:

base:
  '*':
    - apache

Tila ajetaan minionille komennolla:

$ sudo salt ‘*’ state.highstate

Jos kaikki menee oikein, esimerkkisivun tulisi näkyä, kun minionin selaimeen laitetaan localhost.

d) Rakenna tila, joka tekee Apachelle uuden nimipohjaisen virtuaalipalvelimen.

Luodaan aluksi kansio /srv/salt/hosting, johon tiedosto init.sls:

/etc/apache2/sites-available/www.example.com.conf:
  file:
    - managed
    - source: salt://hosting/www.example.com.conf

/etc/apache2/sites-enabled/www.example.com.conf:
  file.symlink:
    - target: ../sites-available/www.example.com.conf

/var/www/html/example/index.php:
  file.managed: 
    - makedirs: True
    - source: salt://hosting/index.php

/etc/hosts:
  file:
    - managed
    - source: salt://hosting/hosts

Huom. Kokeillessani koko settiä lopussa, huomasin, että edelleenkään www.example.com ei ohjannut oikeaan sivuun. En löytänyt nopeilla hauilla mitään ratkaisua, mutta onneksi ratkaisu löytyi Axel Rusaselta: Apache2.service pitää tietysti käynnistää uudestaan, kun muokataan enablettuja sivuja… Tässä komento, millä se tehdään, mikä lisätään myöhempänä.

apache2-restart:
  cmd.run:
    - name: 'sudo systemctl restart apache2.service'

Tehdään hosting kansioon index.php, joka lisätään minionille example kansioon yllä olevassa tilassa:

$ sudo nano index.php

Kopioidaan default sivu hosting kansioon, josta muokataan www.example.com.conf

$ sudo cp /etc/apache2/sites-available/000-default.conf /srv/salt/hosting/
$ sudo mv /srv/salt/hosting/000-default.conf /srv/salt/hosting/www.example.com.conf

Tiedoston sisältä muokataan ServerName, ServerAlias ja DocumentRoot seuraavanlaiseksi:

ServerName www.example.com

ServerAlias example.com

DocumentRoot /var/www/html/example/index.php

Seuraavaksi luodaan oma versio hosts –tiedostosta joka kopioidaan minionille:

$ sudo cp /etc/hosts /srv/salt/hosting/

Muokataan tiedostoon uusi osoite:

$ sudo nano hosts

Lisätään rivin 127.0.0.1 localhost alle rivit

127.0.0.1 www.example.com
127.0.0.1 example.com

Lopuksi muokataan top.sls ottamaan hosting kansio huomioon:

$ sudo nano /srv/salt/top.sls

Lisätään apachen alle hosting:

base:
  '*':
    - apache
    - hosting

Nyt kaikki asetukset on tehty, kokeillaan ajoa:

$ sudo salt ‘*’ state.highstate

Komento menee onnistuneesti läpi. Nimipalvelimen toimintaa voidaan kokeilla kirjoittamalla minionin selaimen hakukenttään www.example.com tai example.com, jolloin pitäisi näkyä eri teksti. Tässä tapauksessa sekin toimii.

Kokeillaan vielä lopuksi käynnistää kannettava uudestaan tikulta, jotta voidaan kokeilla tilan asennusta puhtaalta pöydältä minioniksi lisäämisen jälkeen.

Jotta säästytään avainsotkuilta poistetaan aikaisempi minionin avain:

$ sudo salt-key -d minion-id

Hyväksytään minion uusiksi, ja syötetään ainoastaan komento:

$ sudo salt ‘*’ state.highstate.

Ajamisessa kestää vähän kauemmin, ja selviää, että nimipalvelin ei hoida tehtäväänsä. Tämä korjaantuu, kun lisätään ../hosting/init.sls tiedoston loppuun seuraava:

apache2-restart:
  cmd.run:
    - name: 'sudo systemctl restart apache2.service'

Tällä muutoksella tila toimii. Cmd.run on tuskin kuitenkaan suositeltava tapa, mutta mennään sillä, kun se kerta toimii.

f) Asennetaan minionille sysstat, kytketään se päälle ja asetetaan sen päivitystahti minuutiksi. Vastaus olettaa, että sysstat on asennettu masterille, jolloinka haluttavat tiedostot löytyvät masterilta.

Aluksi tehdään kansio /srv/salt/sysstat. Kopioidaan sinne sisään sysstatin asetustiedosto:

$ sudo cp /etc/default/sysstat /srv/salt/sysstat/sysstat

Kopioidaan samalla ajastuksen konfigurointitiedosto, mutta laitetaan sen perään numero 2, jottei aikaisempi tiedosto ylikirjoitu:

$ sudo cp /etc/cron.d/sysstat /srv/salt/sysstat/sysstat2

EDIT 16.4.: Korjasin tiedostopolun kopiointeihin, kiitos Axel. https://axellinux.wordpress.com/

Tehdään tiedostoihin tarvittavat muutokset, sysstatiin muutetaan seuraava:

ENABLED=”true”

Seuraavaan, sysstat2, muutetaan 5-55/10 tekstiksi */1, lopullinen rivi on siis:

*/1 * * * * root command -v debian-sa1 > /dev/null && debian-sa1 1 1

Seuraavaksi luodaan sysstat kansioon init.sls:

sysstat:
  pkg.installed

/etc/default/sysstat:
  file.managed:
    - source: salt://sysstat/sysstat

/etc/cron.d/sysstat:
  file.managed:
    - source: salt://sysstat/sysstat2

sysstatservice:
  service.running:
    - name: sysstat
    - watch:
     - file: /etc/default/sysstat
     - file: /etc/cron.d/sysstat

EDIT 16.4.: Lisäsin tilaan watchin, jotta sysstat.service käynnistyy uudestaan automaattisesti, kiitos Axel. https://axellinux.wordpress.com/

Lisätään tehty tila top.sls tiedostoon:

base:
  '*':
    - apache
    - hosting
    - sysstat

Sitten voidaankin lähteä ajamaan tilaa:

$ sudo salt ‘*’ state.highstate

Jos tila halutaan ajaa yksinään ilman highstatea, voidaan käyttää komentoa:

$ sudo salt '*' state.apply sysstat

Tila menee läpi, eli sysstat on konfiguroitu onnistuneesti oikein tilan kautta.

Sysstatin keräämiä tietoja voidaan selata komennolla

$ sar -A

 

Posted in Uncategorised | Leave a comment

Palvelinten hallinta h1

Alkuperäinen päivämäärä: 4.1.2018

H1

Lähteitä & muita linkkejä:

http://terokarvinen.com/2018/aikataulu-–-palvelinten-hallinta-ict4tn022-4-ti-5-ke-5-loppukevat-2018-5p#h1

http://terokarvinen.com/2018/quick-fix-for-useless-salt-warning-add-file_ignore_glob-to-etcsaltmaster

http://terokarvinen.com/2018/run-salt-sls-file-locally-sudo-salt-call-local-state-apply-foo

Jatkokurssilla pyrin pitämään dokumentaatiot yksinkertaisempina.

 

Harjoitus tehtiin Digital Oceanin virtuaalipalvelimella, jossa 64-bittinen Ubuntu 16.04.4. Virtuaalipalvelinta ohjataan PuTTyllä.

 

c) Asennetaan Salt virtuaalipalvelimelle.

Salt asennetaan komennolla

$ sudo apt install salt-master salt-minion 

Komento asentaa masterin sekä minionin.

Tehdään virtuaalipalvelimesta itsensä orja:

$ sudoedit /salt/etc/minion

Minion tiedoston loppuun sijoitetaan masterin ip-osoite sekä orjalle tunnus, id:

master: 10.19.0.5

id: slave

rzsgxc

Tiedoston muokkaamisen jälkeen salt-minion daemon täytyy käynnistää uudestaan;

$ sudo systemctl restart salt-minion.service

Hyväksytään orjan salt-key:

Tarkistetaan ensiksi löytyykö avain:

$ sudo salt-key

kdjybx

Avain löytyy, siispä hyväksytään komennolla:

$ sudo salt-key -A

Testataan hallintaa komennolla:

$ sudo salt ’*’ cmd.run ’hostname -I’

lqomak

Vastauksena saadaan orjatietokoneen ip-osoite, komento ja hallinta siis toimii.

d) Kokeillaan Laineen MySQL tilaa, eli siis tiedostoa mysql.sls.

Tehdään kansio /srv/salt, mihin tiedosto mysql.sls. Tiedoston sisään kopioidaan sisältö sivulta https://github.com/joonaleppalahti/CCM/blob/master/salt/srv/salt/mysql.sls

Kokeillaan tilan syöttämistä paikallisesti komennolla:

$ sudo salt-call –local state.apply mysql

emgdds

Komennon olisi siis pitänyt asentaa mysql, joten kokeillaan komennolla:

$ sudo mysql -u root -p

Ja salasanaksi tilatekstissä näkyvä ’silli’.

cyspdv

MySQL aukeaa, joten asennus on onnistunut, kuten saltin antama viesti kertoi.

e) Tehtävässä e kerätään orjakoneelta tietoja grains-komennolla.

Tietoja voidaan kerätä komennolla:

$ sudo salt ’*’ grains.items

Komento listaa kaikki mahdolliset tiedot, jotain tiettyä voidaan hakea komennolla:

$ sudo salt ’*’ grains.item cpu_model

rumqsa

Mikä palauttaa prosessorin mallin. Haku siis toimii.

f) Seuraavaksi tehdään tila, joka asentaa ohjelman cmatrix.

Tehdään tiedosto /srv/salt/cmatrix.sls.

Sisällöksi seuraava:

install_cmatrix:
  pkg.installed:
    - pkgs:
      - cmatrix

Tehdään tiedosto /srv/salt/top.sls

Sisällöksi seuraava:

base:
  '*':
    - cmatrix

Tila ajetaan komennolla:

$ sudo salt ’*’ state.highstate

qvtmcs

Vastaus kertoo asennuksen onnistuneen, mutta asennusta voi kokeilla komennolla:

$ cmatrix

Ja homma toimii.

Posted in Uncategorised | Leave a comment

Linux palvelimet h7

Alkuperäinen päivämäärä: 12.3.2018

H7 – Harjoitus 7 Linux palvelinten kurssilta: http://terokarvinen.com/2017/aikataulu-%e2%80%93-linux-palvelimet-ict4tn021-7-ti-ja-6-to-alkukevat-2018-5-op#h7

  1. a) Ratkaise valitsemasi vanha arvioitava laboratorioharjoitus tältä (Löytyy DuckDuckGolla tai Googlella sekä linkeistä tältä sivulta).

 

Valitaan sivulta ensimmäinen vastaantuleva labraharjoitus: http://terokarvinen.com/2017/arvioitava-laboratorioharjoitus-linux-palvelimet-ict4tn021-4-tiistai-alkusyksy-2017-%E2%80%93-5-op

 

Tehtävänä on siis suorittaa seuraavat toimenpiteet:

  1. asentaa LAMP -stack ja tehdä lyhyt ohjelma yrityksen nettisivulle jossa käytetään tietokantaa.
  2. asentaa ja käyttöönottaa ssh.
  3. tehdä yrityksen työntekijöille käyttäjät ja esimerkkikotisivut.
  4. kytkeä palomuuri päälle.
  5. tehdä lyhyt skripti joka tulostaa tervehdyksen, IP-osoitteen ja käyttäjän nimen.

Lopuksi katsotaan josko jokin valinnainen tehtävä vaikuttaisi mukavalta.

 

Aloitetaan tehtävien teko tuoreelta livetikulta joka on tehty aiempien tehtävien mukaisesti. (https://mvaltonenblog.wordpress.com/2018/01/22/h1/)

 

Ennen ohjelmien asentamista tehdään käyttäjän kotihakemistoon salasanat.txt, johon kirjataan harjoitusta varten tehdyt salasanat. Asennetaan samalla salasanageneraattori pwgen komennolla sudo apt-get install pwgen. Palataan salasanoihin myöhemmin. Tehdään salasanasta yksityinen niin, että vain luoja voi lukea sitä. Mennään kotihakemistoon, jossa salasanat.txt sijaitsee. Syötetään komennot sudo chown xubuntu, jonka jälkeen komennot sudo chmod u=rwx,g-rwx,o-rwx salasanat.txt.

Asennetaan ensiksi Apache komennolla sudo apt-get update && sudo apt-get install apache2. Joissakin tapauksissa, kuten tässä, livetikku ei osaa käyttää tietokoneen langatonta verkkokorttia, jolloinka tietokone täytyy yhdistää hetkeksi piuhan päähän. Itse jaan netin tietokoneeseen puhelimelta tetheringin kautta.

Langattoman verkkokortin ajuri asennetaan valitsemalla starttivalikosta Settings > Software & Updates, jonka jälkeen Additional Drivers. Valikosta valitaan oikea ajuri, oikean tunnistaa helposti valmistajan nimellä, jonka jälkeen Apply. Tämä kuitenkaan ei livetikulla onnistu, koska ajurien asennus vaatii uudelleenkäynnistämistä, joten jatketaan tetheringilä.

LAMP                    Source: http://terokarvinen.com/2016/read-mysql-database-with-php-php-pdo

Ajetaan komento sudo apt-get update && sudo apt-get install apache2. Apache2:n toimivuus voidaan kokeilla laittamalla selaimeen localhost. Sivulla näkyy Apachen vakiosivu, eli sivu siis toimii.

NZ42RCw

Navigoidaan hakemistoon /var/www/html/ muokkaamaan tiedostoa index.html siten, että sivulle jää vain teksti Hei Maailma!

Asennetaan seuraavaksi Apachen moduuleja myöhempää käyttöä varten, palvelimen PHP sekä käyttäjähakemistot komennoilla sudo apt-get install libapache2-mod-php7.0 ja sudo a2enmod userdir. Lopuksi käynnistetään palvelin uudelleen komennolla sudo systemctl apache2.

MySQL asennetaan komennolla sudo apt-get install mysql-server. Ohjelma kysyy asennuksen aikana root-käyttäjän salasanaa, generoidaan se pwgenillä avaamalla uusi terminaali ja syöttämällä komento pwgen 20 1. Komento antaa 20 kirjaimisen salasanan. Ensimmäinen parametri määrittelee salasann pituuden. Jos halutaan generoida monta salasanaa kerralla, viimeinen parametri kertoo salasanojen määrän, eli pwgen 10 5 antaisi viisi 10 kirjaimista salasanaa. Tallennetaan generoitu salasana aiemmin luotuun salasanat.txt tiedostoon, ja annetaan se asennukseen salasanaksi.

MySQL asennuksen toimivuus tarkistetaan komennolla mysql -u root -p. Pääsemme palveluun sisään, joten MySQL voidaan julistaa toimivaksi.

luJp29X

Asennetaan suoraan perään PHPMyAdmin, eli MySQL hallintapaneeli, komennolla sudo apt-get install phpmyadmin. Ohjelma asennetaan aikaisempien harjoitusten mukaisesti (https://mvaltonenblog.wordpress.com/2018/02/05/h3/). Asennus pyytää taas salasanaa. En ole täysin varma tarvitaanko tätä salasanaa mihinkään, mutta generoidaan kuitenkin samaan tapaan salasana, ja kirjataan se ylös.

PHPMyAdminin toimivuus tarkistetaan menemällä osoitteeseen localhost/phpmyadmin. Aloitus sivu näkyy, eli palvelun pitäisi toimia, mutta kirjaudutaan varmuuden vuoksi sisään root tunnuksilla. Palvelu toimii.

C0Sw5HK

Seuraavaksi tehdään lyhyt testiohjelma, jossa kaivetaan esiin rivejä MySQL tietokannasta PHP:n kautta. Testiohjelman oppaana ja lähteenä käytän seuraavaa: http://terokarvinen.com/2016/read-mysql-database-with-php-php-pdo.

Ensiksi tarvitaan tietysti taulukko. Tehdään taulukko myöhemmän lisätehtävän mukaan. Tarkoitus on luoda Eijalle esimerkkisivu, jossa testiohjelma ajetaan.  Aluksi kirjaudutaan mySQL:ään sisään, mysql -u root -p.

Luodaan Eijalle tietokanta komennolla CREATE DATABASE evahakaa CHARACTER SET utf8;, jonka jälkeen GRANT ALL ON evahakaa.* TO evahakaa@localhost IDENTIFIED BY salasana’; Kenttään salasana kopioidaan käyttäjän evahakaa talletettu salasana. Seuraavaksi kirjaudutaan ulos ja takaisin sisään Eijana, jotta testataan tunnukset ja muutenkin toimitaan vähemmillä oikeuksilla. Mysql -u evahakaa -p., jatketaan ohjeen mukaan:

USE evahakaa;

CREATE TABLE ninjamoves(id INT AUTO_INCREMENT PRIMARY KEY, move VARCHAR(1024), difficulty INT);

INSERT INTO ninjamoves(move, difficulty) VALUES (‘Hyppykiertopotku’, ‘27’);

INSERT INTO ninjamoves(move, difficulty) VALUES (‘Kuperkeikka’, ‘3’);

INSERT INTO ninjamoves(move, difficulty) VALUES (‘Karjaisu’, ‘1’);

Syötetyt tiedot voi tarkistaa komennolla SELECT * FROM ninjamoves;

FugVYeX

Tiedot ovat oikein, joten jatketaan.

Kaivetaan esiin webpalvelimen sivu /var/www/html/. Annetaan komento sudo mv index.html index.php, sudo nano index.php. Lainataan Teron kirjoittamaa koodia, mutta korjataan koodiin käyttäjänimi sekä muut muuttujat oikeiksi.

Tarkistetaan toimivuus menemällä osoitteeseen localhost/~ evahakaa. Kuinka ollakaan, sivu toimii.

xW85tE8

LAMP -stack on nyt asennettu ja testattu, siirrytään seuraavaan kohtaan.

ETÄTYÖSKENTELY

Seuraavaksi tehtävänä on mahdollistaa etätyöskentely. Etätyöskentelyyn käytetään SSH:ta, asennetaan komennolla sudo apt-get install ssh. Tehdään heti perään palomuuriin aukko komennolla sudo ufw allow 22/tcp.

Koska livetikun Xubuntu käyttäjällä ei ole salasanaa, emme voi kokeilla ssh:ta sillä käyttäjällä. Luodaan testausta varten uusi käyttäjä, sshtest, salasana generoidaan ja kirjataan ylös. Yritetään yhdistää komennolla ssh sshtest@localhost. Nyt yhdistäminen onnistuu koska salasana on olemassa, joten SSH toimii. Etätyöskentely on mahdollista.

KÄYTTÄJÄT

Seuraavaksi tehtävänä on luoda käyttäjätilejä. Koska käyttäjille täytyy tehdä esimerkkisivut, päästään helpolla mikäli käymme muuttamassa /etc/skel lisäämällä sinne public_html kansio, jonka sisään tiedosto index.html. Tiedostoon voi kirjoittaa mitä haluaa, siitä tulevat käyttäjien esimerkkisivut. Skel:n sisältö kopioidaan uusien käyttäjien kotihakemistoihin luomisvaiheessa, joten nyt ei tarvitse käydä jokaisella käyttäjällä luomassa sivuja.

Nyt luodaan käyttäjät. Tässä prosessissa ei ole mitään erikoista, muuta kuin se, että Nakke Nertolan tietoihin kirjoitetaan, että käyttäjä on toimitusjohtaja. Käyttäjien salasanat generoidaan ja kirjataan ylös.

Kun käyttäjät on tehty, voimme tarkistaa käyttäjäsivujen toimivuus laittamalla selaimeen localhost/~kayttaja, eli esim. localhost/~ evahakaa. Nettisivulle ilmestyykin hakemistolistaus, joten jokin on pielessä.

40PZIA2

Yhdistämällä sisään käyttäjällä nnertola voimme huomata, että olen epähuomiossa laittanut index.html tiedoston public_html kansion ulkopuolelle. Ongelma korjataan komennolla mv index.html public_html/, mutta ongelma täytyy korjata jokaisen käyttäjän kohdalla. Eli yhdistetään jokaisella käyttäjällä sisään SSH:lla, jottei tiedostojen oikeudet hajoa.

Kun virhe on korjattu, käyttäjien sivut toimivat oikein, esimerkki sivu näkyy.

PALOMUURI

Palomuuri kytketään päälle komennolla sudo ufw enable. Ennen sitä on kuitenkin hyvä varmistaa, että portit 22 sekä 80 ovat auki, sudo ufw allow 22/tcp && sudo ufw allow 80/tcp.

TERVEHDYS        Source: http://terokarvinen.com/2007/shell-scripting-4

Tervehdysskriptiä varten navigoidaan hakemistoon /usr/local/bin, jonne avaamme tekstitiedoston sudo nano ninja, johon seuraava teksti:

#!/bin/bash

Echo Hello Ninja!

Hostname -I

Whoami

Tiedosto tulee tallentaa ilman tiedostopäätettä. Tallentamisen jälkeen komennolla sudo chmod a+x ninja annamme kaikille käyttäjille oikeuden suorittaa skripti. Koska skripti sijaitsee /usr/local/bin hakemistossa, sen voi kutsua milloin vain ja mistä vain. Testataan skriptiä helposti kirjautumalla millä tahansa käyttäjällä sisään SSH:lla, ja kutsumalla skriptiä komennolla Ninja. Skripti toimii.

B10jXp6

UUSI YLLÄPITÄJÄ

Uusi ylläpitäjä on helppo luoda. Syötetään komento sudo adduser jlaitava. Salasana generoidaan kuten aiemmin. Kun käyttäjä on luotu lisätään käyttäjä vielä admin ja sudo ryhmiin. Sudo adduser jlaitava adm && sudo adduser jlaitava sudo. Nyt jlaitava pystyy lukemaan lokitiedostoja ja toimimaan tarvittaessa root oikeuksilla, kuten muutkin ylläpitäjät.

Lopuksi harjoitus pyytää pakkaamaan tiedostot palautusta varten, mutta jääköön se kunnon labraharjoitukseen, onhan oikeat tehtävät tehty lukuunottamatta Eijan alidomainin tekoa.

Tehtävä oli mielenkiintoinen ja melko vaativa, siinä mielessä että se vaati kaikkia tähän asti opittuja taitoja. Toisaalta tehtävä oli myös helpohko siinä mielessä, että asiat olivat melko tuttuja. Koen, että viimeisimpien tehtävien aikana ylipäätänsä ymmärrys Linuxin toiminnasta ja käytöstä on parantunut huomattavasti.

Uskon labraharjoituksen menevän hyvin, mikäli siinä on samankaltaisia tehtäviä.

Lähteitä:

https://www.w3schools.com/sql/sql_create_db.asp

http://terokarvinen.com/2007/shell-scripting-4

http://terokarvinen.com/2016/read-mysql-database-with-php-php-pdo

https://www.computerhope.com/unix/uchmod.htm

Posted in Uncategorised | Leave a comment

Linux palvelimet h6

Alkuperäinen päivämäärä: 5.3.2018

H6

terokarvinen.com/2017/aikataulu-–-linux-palvelimet-ict4tn021-7-ti-ja-6-to-alkukevat-2018-5-op#h6

 

Harjoituksessa 6 tehdään seuraava: Kirjoita ja suorita “Hei maailma” kolmella kielellä. Asenna tarvittavat ympäristöt.

 

Aion suorittaa tehtävän kielillä C:llä, Pythonilla ja Perlillä. Aluksi varmistetaan, että kaikki koodien ajamiseen tarvittavat ohjelmat on asennettu.

Tiedän ennestään, että nykyisin käytettävä Pythonin versio on versio 3, joten komennolla sudo apt-get install python3 saamme Pythonin asennettua, mutta käykin ilmi että tarvittava ohjelma onkin Xubuntussa jo valmiina.

Seuraavaksi asennetaan C kääntäjä. C:stä en tiedäkkään kääntäjän nimeä, sillä sudo apt-get install c ei ole mikään, ja tabulaattorista tulevia ehdotuksia on reilut 1600. Konsultoidaan siis internettiä: http://www.codecoffee.com/tipsforlinux/articles/18.html. Ohjekomennoissa näkyy ajettavana ohjelmana gcc, joten kokeillaan onnea sen kanssa. Asennus menee läpi, testataan sen toimivuus myöhemmin.

Yhtälailla Perl asentuu komennolla sudo apt-get install perl. Perl on näköjään kuitenkin asennettu Xubuntuun valmiiksi, kuten Pythonin kohdalla.

 

Aloitetaan ohjelmien kirjoittaminen. Ensiksi luodaan käyttäjän kotihakemistoon tiedosto pythonhw, python hello world. Tiedostoon kirjoitin seuraavan koodin:

KuoeloS

Tiedoston nimeämisessä kannattaa tietääkseni olla tarkkana, .py pääte vaaditaan, mikäli haluaa kääntäjän toimivan. En kuitenkaan ole ihan täysin varma tästä. Joka tapauksessa nimetään tiedosto pythonhw.py:ksi.

Kokeillaan koodin kääntämistä. Arvelen, että kääntäjä toimii niinkin helposti, että python3 pythonhw.py.

LsELFiD

Ja sehän onnistuu. Siirrytään siis seuraavaan kohtaan, C:hen. Tässä kohtaa minulla loppuu ennakkotietämys kesken, ja konsultoin C:n käyttöopasta osoitteesta https://www.programiz.com/c-programming/examples/print-sentence. Tekstitiedostoon kirjoitan seuraavan tekstin:

WO4iN4s

Tiedosto on tässäkin tapauksessa syytä nimetä oikein, joten nimetään tiedosto chw.c:ksi, eli c hello world.

C-kääntäjä toimii luultavasti samalla tavalla kuin Pythoninkin, joten kokeillaan komentoa gcc chw.c. Samalla tulemme testanneeksi onko gcc oikeasti oikea ohjelma.

azNJ8Rz

Gcc on selkeästi oikea ohjelma, mutta koodissa on näköjään virheitä. Laiskuuttani koitin oikaista ja jättää ohjeessa mainitun rivin #include <stdio.h>. Pakko nöyrtyä ja lisätä pätkä koodiin.

Uudelleen ajettuna homma menee läpi, jonka jälkeen kansioon ilmestyy a.out tiedosto. Oppaan mukaan ohjelma olisi pitänyt nimetä ensin lisäämällä komentoon -o sekä ohjelman nimi. Poistetaan a.out komennolla rm a.out, ja syötetään komento  gcc -o chw chw.c. Käännös toimii jälleen, jonka jälkeen ohjelma voidaan ajaa komennolla ./chw.

HPJZDHL

Lopputulos näkyy vähän oudosti, mutta se toimii.

Lopuksi siirrytään Perliin. Perl ei myöskään ole minulla ennestään tuttu, joten käytän seuraavaa opasta: https://www.thegeekstuff.com/2009/09/perl-hello-world-example-how-to-write-and-execute-perl-program-on-unix-os/

Oppaan mukaan luodaan tiedosto perlhw.pl.

5eDQIqa

Kääntäjä toimii samalla tavalla kuin aiemmatkin, perl perlhw.pl.

ih5VwZg

Perlikin siis toimii.

Tässä tämän viikon tehtävät. Alla lähdeluettelo.

 

https://en.wikibooks.org/wiki/Non-Programmer%27s_Tutorial_for_Python_3/Hello,_World

http://www.codecoffee.com/tipsforlinux/articles/18.html

https://www.programiz.com/c-programming/examples/print-sentence

Perl Hello World Example: How To Write and Execute Perl Program on Unix OS

Posted in Uncategorised | Leave a comment

Linux palvelimet h5

Alkuperäinen päivämäärä: 26.2.2018

H5  – http://terokarvinen.com/2017/aikataulu-%e2%80%93-linux-palvelimet-ict4tn021-7-ti-ja-6-to-alkukevat-2018-5-op#h5

Harjoitus on tehty kolmea tietokonetta käyttäen, koululäppäriä, Digital Oceanin virtuaalipalvelinta sekä omaa Windows kotikonettani. Koululäppäriä ja virtuaalipalvelinta ohjattiin enimmäkseen Puttyn kautta etänä kotikoneeltani.

a) SSH:n asennus tapahtuu helposti komennolla sudo apt-get update && sudo apt-get install -y ssh.

b) Seuraavaksi avataan palomuuriin aukko SSH:ta varten, ja kytketään palomuuri pää On erittäin hyödyllistä avata portti ennen palomuurin aktivoimista, jotta konfigurointiin käytettävä SSH-yhteys ei katkea välittömästi. Siispä:

Aukko luodaan komennolla sudo ufw allow 22. Portti aukeaa sekä IPv4 sekä IPv6 protokolliin.

Kun aukko on luotu, voidaan palomuuri ottaa käyttöön komennolla sudo service ufw enable.

c) Seuraava tehtävä on siirtää tiedostoja SSH:lla. Testinä siirrän Scan of the Month 15 Honeypot -levykuvan koululäppäriltäni virtuaalipalvelimelle. Eli siirrän hda8.dd ssh yhteyden kautta.

Levykuvan voi ladata osoitteesta http://old.honeynet.org/scans/scan15/honeynet.tar.gz.

Extractasin tiedoston Downloads kansioon, jolloin levykuva löytyy honeynet kansion sisältä. Kopioin tiedoston vastaanottavan koneen hakemistoon /home/miikkb/honeynet. Käytän apuna seuraavaa linkkiä: http://www.hypexr.org/linux_scp_help.php, sillä tiedän, että scp:llä voi helposti tuhota tietoja vahingossa, enkä sitä virhettä halua tehdä.

Aloitetaan prosessi paikalliselta koululäppäriltä. Navigoidaan hakemistoon /home/mvaltonen/Downloads/honeynet.

Syötetään komento scp mvaltonen@kissa:/home/mvaltonen/Downloads/honeynet/honeypot.hda8.dd miikkb@159.89.5.3:/home/miikkb/honeynet. Syöttämisen jälkeen kehote kysyy paikallisen tietokoneen salasanaa. Tämän jälkeen ei tapahdukaan enää mitään, ja vähän pelottaa että tein jotain pieleen. Odotin muutaman minuutin, peruutin komennosta pois CTRL+C. Seuraavaksi tarkistin virtuaalipalvelimelta, ja tiedosto kuitenkin löytyy honeynet kansiosta. Luultavasti kaikki on siis mennyt oikein kummajaisista huolimatta.

dhwxtn

d) Seuraavaksi luon SSH avainparin kotikoneen puttyn ja virtuaalipalvelimen vä SSH yhteys virtuaalipalvelimeen on avattu, kirjoitetaan komento ssh-keygen. Tämän jälkeen hakataan entteriä pari kertaa, kunnes kehote kertoo, että avain on tehty ja tallennettu. Tässä vaiheessa konsultoin ystävääni, koska minulla ei ole aavistustakaan, miten avain lisätään puttyyn. Jotta saan avaintiedoston puttyyn, minun täytyy navigoida WinSCP:llä kansioon /home/miikkb/.ssh/, josta kopioin tiedoston id_rsa kotikoneelleni, josta saan sen luettua puttyyn. Avain lisätään puttyyn kuvien mukaan.

Yllättäen ratkaisu ei toimi. Vasta nyt aloin miettimään, että eihän salaus voi missään nimessä mennä niin, että yksityinen avain jaetaan yhtään mihinkään. Syvän huokauksen ja pettymyksen jälkeen päätin ratkaista ongelman itse ja hain netistä apua. Löysin seuraavan ohjeen: https://www.howtoforge.com/ssh_key_based_logins_putty_p2. Avain täytyy tehdä Puttyn Key Generatorin kautta, eikä Key Agentin kautta.

kdugxx

Aluksi painetaan Generatea, jonka jälkeen ohjelma pyytää heiluttelemaan hiirtä, jotta avaimesta saadaan sattumanvarainen. Yksityinen avain tallennetaan paikalliselle koneelle piiloon, kun taas public key täytyy siirtää palvelimelle /home/miikkb/.ssh/ kansioon. Luodaan hakemistoon uusi tekstitiedosto authorized_keys2. Tiedostoon kopioidaan Puttyn Keygenistä saatu julkinen avain. Lopuksi vielä muutetaan tiedoston oikeuksia siten, että vain me voimme lukea tai kirjoittaa siihen. Tämän jälkeen avain pitää vielä puttyn puolella kytkeä käyttöön:

svcgkg

Nyt yhdistettäessä palvelin kysyy vain avaimen luonnissa laitetun passphrasen, mutta sen voisi jättää laittamatta halutessaan, jolloin yhdistäminen tapahtuu automaattisesti. Luultavasti generoin avaimen ilman passphrasea kun kyllästyn kirjottelemaan salasanoja.

bwmwiz

j) Sysstat asennetaan komennolla sudo apt-get install -y sysstat. Asennuksen jälkeen monitorointi täytyy kytkeä päälle hakemistosta /etc/default/ tiedostosta Enabledin arvo pitää muuttaa trueksi.

dmtmrt

Seuraavaksi tutkitaan eri lokimerkintöjä.

Ensiksi käydään läpi sar. Loki pitää kirjaa ilmeisesti kaikesta rasituksesta, eräänlainen yhteenveto.

tcyhqe

Lista päivittyy 10 minuutin välein ja pitää siis kirjaa ihan kaikesta.

Ensiksi loki näyttää tapahtuman kellonajan.

CPU tarkoittaa luultavasti, että mitä ytimiä tehtävään käytettiin. Nähtävästi kaikkeen käytetään kaikkia ytimiä, eli sitä yhtä mikä on saatavilla.

%user liittyy varmaan käyttäjien luomaan rasitukseen, esim. tiedosto tai kansiosiirtoihin. Vaikea uskoa, että miksi tästä pidettäisi erikseen kirjaa, mutta ei tule muutakaan mieleen.

%nice liittyy ehkä jotenkin prosessien priorisointiin, mutta tämä on vain arvaus.

%system sisältää luultavasti kaikki järjestelmän omat toimenpiteet. Tähän sisältyy varmaan myös ohjelmien asennukset.

%iowait iowaitilla mitataan sitä kuinka paljon asioiden suorittamisessa odotellaan kovalevyjen kirjottamista tai muuta toimintaa.

%steal on tietääkseni vain virtuaalikoneissa, joten se luultavasti mittaa jotenkin virtuaaliprosessorin fyysisen oikean prosessorin rasitusta, mikä vaikuttaa virtuaaliprosessorin rasitukseen.

%idle paljonko järjestelmässä on resursseja jotka eivät tee mitään.

Myös järjestelmän uudelleenkäynnistyksen.

Seuraavaksi käsitellään iostattia.

lkoypr

Iostat pitää kirjaa kovalevyjen käytöstä.

Device on partition tunniste, tässä tapauksessa vda, koska kyseessä on virtuaalilevy.

Tps tarkoittaa luultavasti jotain per second, eli kyseessä on luultavasti tehtäväpyynnöt per sekuntti.

kB_read/s, kB_wrtn/s liittyvät keskimääräiseen luku- ja kirjoitusnopeuteen.

kB_read, kB_wrtn kuinka paljon yhteensä on luettu ja kirjoitettu sysstatin asennuksen jälkeen.

Lopuksi käydään vielä läpi pidstat.

rbikxx

Pidstat taitaa pitää kirjaa aktiivisesti käynnissä olevista prosesseista.

UID eli user ID, tarkoittaa käyttäjää joka prosessin on aloittanut. ID 0 on luultavasti järjestelmä itse.

PID eli process ID on prosessin yksilöivä ID.

%usr en tiedä mihin liittyy. Jos jotain pitäisi arvata, niin ehkä kuinka paljon yksi käyttäjä aiheuttaa rasitusta, mutta en oikein usko tähän.

Tässä vaiheessa pohdin tarkemmin, miksi esimerkiksi käyttäjien ja järjestelmän luomaa rasitusta tarkkailtaisi erikseen, joten etsinkin googlesta selitystä. Vastaan tuli seuraava artikkeli: http://sebastien.godard.pagesperso-orange.fr/man_pidstat.html. Artikkelin mukaan %usr ja %system erottelevat sovellus- ja kerneltason kulutusta.

%system ylemmän artikkelin mukaan tarkoitetaan kerneltason käyttöä.

%guest liittyy virtualisointiin, artikkelin jälkeen jää epäselväksi, tarkoitetaanko tällä virtuaalipalvelimella tapahtuvaa virtualisointia, vai itse virtuaalipalvelimen virtualisointia.

%CPU näyttää lopuksi kokonaiskäytön riippumatta siitä, millaista käyttöä se on.

CPU määrittää käytettävän ytimen, ydin 0 tarkoittaa ensimmäistä ydintä, eli sitä ainutta mikä käytössä on.

Command määrittelee komennon, mikä prosessin on avannut.

i) Seuraavaksi siirrytään Scan of the Month 15:n ratkaisuun. http://old.honeynet.org/scans/scan15/

Tavoitteena on siis löytää vastaukset seuraaviin kysymyksiin:

  1. Show step by step how you identify and recover the deleted rootkit from the / partition.
  2. What files make up the deleted rootkit?

Bonarina vielä:

Was the rootkit ever actually installed on the system? How do you know?

Levykuva saadaan auki Sleuthkitin avulla, sudo apt-get install sleuthkit. Hyvät ohjeet levykuvan purkamiseen löytyy täältä: http://terokarvinen.com/2013/forensic-file-recovery-with-linux.

Ohjeiden mukaan seuraavaksi luodaan kansiot levykuvasta poistetuille ja muille tiedostoille, mkdir allocated deleted. Tämän jälkeen tiedostot voidaan purkaa komennolla tsk_recover -a honeypot.hda8.dd allocated. Poistetut tiedostot puretaan komennolla tsk_recover honeypot.hda8.dd deleted.

Deleted hakemistosta löytyy uusi .tar tiedosto. Puretaan tiedosto komennolla tar -xf lk.tgz.

Uskon, että tämä .tar sisältää asennetun rootkitin. Seuraavaksi käyn kansion sisältöä läpi etsien todisteita väitteeni tueksi.

Heti ensiksi listaamalla luodun last kansion sisällön, voidaan huomata, että kansio sisältää monia skriptejä ja ssh konfigurointitiedostoja. Uskon, että nämä ohjelmat muodostavat rootkitin ”työkalusetin”, jota hyökkäyksessä on käytetty. Muita konfigurointitietoja ja tekstitiedostoja luultavasti käytetään siten, että niillä paikataan tietokoneessa olevia tiedostoja omilla versioilla, jotta voidaan piilottaa rootkitin olemassaolo.

phpbkm

Lähes kaikissa näistä tiedostoista esiintyy se ongelma, että kun tiedostot ovat alun perin poistettuja, niitä ei saa välttämättä palautettua täysin. Siispä tiedostoissa saattaa esiintyä paljon mössöä ja ovat muutenkin pahimmillaan hyvin vaikeaselkoisia.

uebhbd

Aloitetaan ohjelmien purkaminen cleanerista. Komennolla nano cleaner pääsemme lukemaan skriptiä.

Sisällön ja tiedoston nimen perusteella skripti tyhjentää logista tiettyjä rivejä ja koittaa siten pitää hyökkäyksen piilossa.

ejribt

Seuraavana on ifconfig. Tiedoston sisällöltä en osaa sanoa oikeastaan mitää. Mössön välistä nousee esiin paljon erilaisia virheitä, mutta en osaa ottaa niihin kantaa. En osaa myöskään sanoa, että vaikuttavatko virheet yhtään mihinkään.

Seuraavaksi päästään jännän äärelle, install tiedosto sisältääkin sitten itse hyökkäyksen. En ymmärrä kaikkea ihan tarkkaan, mutta luulen, että skripti poistaa tiedostoja, ja laittaa tilalle omia versioita, jotka piilottavat rootkitin.

Myöhemmin skripti kopioi työkalujaan jonnekkin, mutta en osaa sanoa, mihin suuntaan työkaluja kopioidaan, ja jääkö ne johonkin olemaan, kun näyttäisi siltä, että ne poistetaan jostain kopioinnin jälkeen.

ppehmw

Seuraavaksi ilmeisesti ohjelmasta lsattr kopioidaan mukautettu versio ja se asetetaan käynnistymään aina käynnistyksen yhteydessä.

Lopuksi skripti kerää tiedostoista tietokoneen perustietoja, hostnamea ja prosessorivalmistajaa yms. ja lähettää ne itselleen. Tämän jälkeen skripti poistaa luodut kansiot ja .tar tiedoston, jota nyt luemme.

crepeq

Tämä viimestään paljastaa sen, että luemme rootkitin oikeita tiedostoja. Computer kansiota tosin ei näytä löytyvän mistään, mutta se saattaa liittyä tuohon tiedonkeruuseen ja tietojen lähettämiseen.

Hyökkäyksen tekotavasta osaan arvata sen verran, että hyökkäys on luultavasti tehty vanhalla SSH-versiolla jossa on ollu jokin haavoittuvuus liittyen liian pitkiin salasanoihin tai käyttäjänimiin. Jotenkin on ehkä tätä kautta päästy sisään, ja luotu avainparit käyttämällä ennaltasäädettyjä hyökkääjän laatimia seedejä, jolloin saadaan tehtyä sellainen avain, minkä hyökkääjä tietää. Tällä luultavasti turvataan jatkuva sisäänpääsy.

Mietin myös sitä, kun eräs päällekirjoitettavista tiedostoista vaikuttaisi kytkevän jotenkin telnetin päälle, mikä puolestaan sisältää omat heikkoutensa, mutta ei niitäkään voi käyttää hyväksi ilman, että on ensin päästy sisään jotenkin muuten.

Nyt, kun olen päätynyt omaan ratkaisuun, selaan jonkin mallivastauksen läpi.

http://old.honeynet.org/scans/scan15/som/som6.txt

Hyökkäysmenetelmästä olen näköjään väärässä, mutta siltä osin oikeassa, että rootkit oli asentanut haavoittuvan version ssh-palvelimesta, joten jokin siinä oli vialla. Linkkaamani vastaus ei myöskään osannut nimetä varmuudella hyökkäysmenetelmää, mutta hyökkäys oli tapahtunut joko päivityksen tai käyttöjärjestelmäasennuksen jälkeen, joten on mahdollista että asennus oli vaarantunut jo ennen kuin se pääsi koneeseen käsiksi.

Lopputoteamana huomasin mielestäni hyvin tiettyjä asioita rootkitin toiminnasta. Tunnistin rootkitin nopeasti ja pysyin aika hyvin kärryillä siitä, mitä rootkit teki. Oli kuitenkin myös paljon asioita ja kohtia, joita en edes huomannut, kuten se, että järjestelmä oli joko asennettu tai päivitetty hetki ennen rootkitin asennusta.

Tehtävä oli hyvin mielenkiintoinen, oli mielenkiintoista nähdä miten tämänlainen hyökkäys tehdään. Sekin oli jännä, miten toisaalta hyökkäys näytti hyvin tehdyltä, kun hyökkäystavasta ei saatu varmuutta, mutta mallivastausten perusteella rootkit oli muuten tehty melko huolimattomasti, sillä se jäi kiinni melko pian, ja jätti itsestään hyvin selkeitä jälkiä.

Posted in Uncategorised | Leave a comment