PH – h2

H2 Package-File-Service

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

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

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

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

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

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

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

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

eli orja kone vastaa.

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

Master$:

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

• sudoedit sshd_config:

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

• sudo salt ’*’ state.apply sshd

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

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

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

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

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

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

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

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

eli sekin onnistui!

(yllä master ja alla slave)

---

---

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

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

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

Asensin sen masterille:

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

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

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

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

Master:

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

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

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

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

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

Seuraava on ote muistiinpanoistani:

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

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

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

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

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

---

---

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

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

Master:

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

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

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

Slave:

• sudo salt-call -l debug state.apply

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

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

---

Lopuksi:

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