Palvelinten hallinta loppumoduuli (Syksy 2017)


Palvelinten hallinta loppumoduuli (Syksy 2017)

Lähde  Tero Karvinen 2017: Palvelinten Hallinta, http://terokarvinen.com

Harjoitusympäristönä Windows 10 Pro 64-bit

Harjoituskoneen tiedot:

Emolevy X79A-GD65 (8D)

Prosessori Intel(R) Core(TM) i7-3930K

16GiB RAM

 

Harjoituksen tavoitteena oli luoda kokonaisuus, jonka avulla oli mahdollista asentaa Windows 10 tyhjälle koneelle, asettaa käyttöjärjestelmä

Puppetin orjaksi ja ajaa Puppet-moduuli joka ottaa käyttöön halutut ohjelmat ja asetukset. Tavoitteena oli, että käyttäjän ei tarvitsee puuttua asennukseen mahdollisimman vähän.

Kohdelaitteena oli koodinimi “Pelikone” ,jota varten halutaan mahdollisimman pelkistetty Windows-ympäristö ilman Microsoftin bloatwarea.

 

Automatisoitu Windows 10 asennus

 

Windows 10 ISO-tiedoston muokkaukseen käytettiin WinReducer -ohjelmaa. Ohjelman avulla luotiin unattended.xml -tiedosto, jota tarvitaan Windowsin automatisoituun asennukseen.

Lisäksi lisättiin asennettavan Windowsin rekisteriin viittaus, joka poisti UAC:n käytöstä sekä määriteltiin skripti, joka luotiin kun käyttäjä kirjautuu ensimmäistä kertaa asennettuun käyttöjärjestelmään.

 

Harjoituksessa käytettiin apuna WinReducer EX-100 ohjelman kokeiluversiota. Ohjelman käynnistyksen jälkeen valittiin Start -> ISO -> valittiin aiemmin ladattu Windows 10 ISO (en_windows_10_education_version_1703_updated_march_2017_x64_dvd_10189297).

Seuraavaksi ohjelma avasi ISO-tiedoston sisällön muokkausta varten. Ohjelman avulla on mahdollista lisätä, poistaa ja muokata Windowsin asetuksia ja ominaisuuksia. Tavoitteena oli muokata asetuksia Puppetin avulla, joten asennukseen tehtiin ainoastaan ne muutokset, jotka olivat välttämättömiä.

 

UAC:n poisto käytöstä

UAC:n käytöstä poisto onnistuu esimerkiksi rekisteriä muokkaamalla. Lähteenä käytettiin TechNetin artikkelia, jonka perusteella muutos tehtiin ensin omaan tietokoneeseen jonka jälkeen ks. kohta rekisterissä tallennettiin .reg -tiedostoksi (…export). Ohjelman System -> WinReducer Registry Integrator

-välilehden alta lisättiin .reg -tiedosto asennukseen (Add a Registry File -> Save in a Registry File).

 

Ohjelmien asennusskripti

System -> WinReduce Post Installation -> OOBE muokattiin .cmd -tiedostoa, joka ajetaan sen jälkeen kun Windows on asennettu. Add a File -napin avulla lisättiin puppet.bat ja puppet-3.8.7-x64.msi -tiedostot asennukseen, jonka jälkeen muokattiin skriptiä.

@ECHO OFF
for %%i in (C D E F G H I J K L M N O P Q R S T U V W X Y Z) do if exist %%i:\sources\install.wim set CDROM=%%i:
if not defined CDROM goto :eof
echo Detected CDROM as drive %CDROM%
cd\

Title WINDOWS PUPPET SLAVE SETUP
Color F0

@echo ********** Welcome **********
@echo ********** Installing Puppet Agent with master at puppet.simosuominen.com **********
msiexec /qn /norestart /i %CDROM%\WinReducerEX100PI\puppet-3.8.7-x64.msi PUPPET_MASTER_SERVER=puppet.simosuominen.com
timeout 10
start "PuppetWindow" cmd /c %CDROM%\WinReducerEX100PI\puppet.bat
@echo ********** Connecting to the Puppetmaster **********
cd "C:\Program Files\Puppet Labs\Puppet\bin"
timeout 2
puppet agent -tdv
@echo ********** Done **********

 

Skripti tunnistaa asennusmedian (jota ei saa poistaa ennen kuin koko asennus on valmis) ja asentaa medialta Puppetin puppet.simosuominen.com. Asennuksen jälkeen skripti ajaa puppet.bat -tiedoston, joka odottaa 45 sekuntia ja ajaa puppet agent -tdv -komennon. Skripti ajaa samaan aikaan ks. komennon uudestaan. Käyttäjälle jää n. 35 sekunttia aikaa käydä hyväksymässä uuden Puppet-orjan sertifikaatti. Alla näkyy puppet.bat -tiedoston sisältö.

:: puppet.bat file for unattended Windows 10 Puppet slave installation
@echo ********** You now have 45 seconds to accept the certificate **********
timeout 45
cd C:\Program Files\Puppet Labs\Puppet\bin
puppet agent -tdv

 

Unattended.xml

Lopuksi otettiin käyttöön automatisoitu asennus kohdasta Unattended -> Activate Unattended Options.

Seuraavat kohdat muuttamalla asennus kysyi ainoastaan mille levylle Windows asennetaan.

Administrator Account -> ON

Administrative Password -> "salasana"

Activate Autologon -> ON

Turn Off Password Expiration -> ON

Accept EULA -> ON

Hide Cortana Setup -> ON

Hide Local Account -> ON

Hide Online Account -> ON

Hide Wireless Setup -> ON

Protect your PC -> Turn off Express settings

Power schemes -> High Performance

System Language -> United Kingdom

System Keyboard -> Finnish

Text Size (DPI) -> 100%

Time Zone (UTC +02:00) Helsinki, ....

ISO-tiedoston luonti suoritettiin loppuun ohjelman avulla valitsemalla Finish ja seuraamalla ohjelman ohjeita. Lopputuloksena Windows 10 ISO-tiedosto, joka asentaessa kysyy ainoastaan mille kiintolevylle käyttöjärjestelmä asennetaan. Loppuasennus toimii automaattisesti. Asennuksen jälkeen käyttäjä Administrator kirjataan automaattisesti sisään ja luotu skripti käynnistyy.

Moduulit

 

Moduulien ajoa varten tarvitaan Puppetmasterilla seuraavat Windows Puppet moduulit:

puppetlabs/powershell

puppetlabs/registry

councyl/windows

chocolatey/chocolatey

 

Vasta asennetun Windows 10 asetusten muokkausta varten luotiin kaksi moduulia. winsteam -moduulin tehtävänä oli asentaa ja käynnistää Steam -pelialusta haluttuun kohteeseen. winsetup -moduuli asensi tarvittavat ohjelmat ja poisti ylimääräisiä ohjelmia ja asetuksia. Lisäksi winsetup muokkasi päivitysten asennusta sekä rekisteriä. Moduulit määriteltiin Puppetmasterilla ajettavaksi järjestyksessä winsteam -> winsetup. Ensimmäinen moduuli käynnistää ohjelmia, joiden päivitys vie aikaa ja toinen moduuli käynnistää koneen uudelleen moduulin lopuksi. Tavoitteena oli ajoittaa moduulien ajon valmistuminen niin, että päivitykset olisivat valmistuneet siinä vaiheessa, kun kone käynnistyy uudestaan.

 

Käytetyt moduulit winsteam ja winsetup GitHubissa.

PS. winsetup-moduuliin lisättiin GitHubista skripti, joka muokkaa Windows 10 asetuksia rajusti. Skriptiin kannattaa tutustua, ennen kuin käyttää moduulia.

 

Testaus

 

Windows-asennusta ja moduuleja testattiin Hyper-V virtuaalikoneella, johon oli lisätty toinen kiintolevy. Asennus nauhoitettiin Windows 10 oman Game DVR -työkalun avulla. Nauhoitus katkesi joka kerta, kun virtuaalikone käynnistyi uudelleen, joten videoita on useampi kappale.

 

Winpuppet 1: Asennuksen aloitus, asennuskohteen valinta

 

Winpuppet 2: Asennus jatkuu, moduuleja edeltävä tilanne, skriptin toiminta ja moduulien ajo

 

Winpuppet 3: Moduulien ajon jälkeinen tilanne

 

Moduulien ajon jälkeen voitiin todeta, että halutut ohjelmat olivat asentuneet ja asetukset olivat voimassa. Windowsin “modernit” ohjelmat oli poistettu, OneDrive kadonnut sekä Cortana piilotettu. Syystä tai toisesta Virtuaalikoneen Windowsin verkkoyhteys oli mennyt epäkuntoon. Tätä ei tapahtunut muilla testauskerroilla ja ongelma korjaantui joko ajamalla virheiden selvityksen tai käynnistämällä virtuaalikoneen uudestaan.

 

Olin varsin tyytyväinen lopputulokseen, vaikka kehitettävää jäi. Koko asennusprosessiin meni aikaa n. 30 minuuttia, josta varmasti saadaan vielä aikaa pois kun käyttöjärjestelmä asennetaan oikealle nopealle raudalle.

 

Jatkokehitys

 

  1. Perehdyttävä Windows-asennuksen muokkauksen ilman ohjelmistoa. Käytännössä asennukseen ei vaadita kuin unattended.xml -tiedosto USB-aseman juureen sekä joku tapa ajaa skriptiasennuksen jälkeen. Windows Answer File Generatorin avulla unattended.xml -tiedoston luonti onnistuu ilman XML-osaamista.
  2. Edelliseen liittyen Windows -asennusmedian /sources/install.wim -tiedoston voi purkaa ja lisätä tiedostoja Windows-asennukseen. Lisäämällä skriptin kansioon C:\ProgramData\Windows\Start Menu\Programs\Startup voidaan ajaa ks. skripti joka kerta kun käyttäjä kirjautuu sisään. Skripti pitää poistaa ensimmäisen kirjautumisen jälkeen esim. Puppet-moduulin avulla. WinReducer -ohjelman avulla luotua skriptiä pitää muuttaa tätä tarkoitusta varten.
  3. Luotava ylläpitomoduuli Windowsia varten. winsteam ja winsetup -moduuleja ei voi ajaa useampaa kertaa kovinkaan onnistuneesti. Ylläpitomoduuliin ohjelmien päivitykset, Win10.ps1 -skripti sekä muut poistot.
  4. Lisättävä ajurien asennukset siinä vaiheessa, kun kohderauta on hankittu.
  5. Muita korjauksia, esim. “rumat ratkaisut pois

 

 

 

Muut lähteet:

Windows 10 Initial Setup Script

Windows 10 Annoyance-free Automated Install

Mount and Modify a Windows Image Using DISM

 

 

Tätä dokumenttia saa kopioida ja muokata GNU General Public License (versio 3 tai uudempi) mukaisesti. http://www.gnu.org/licenses/gpl.html

Simo Suominen


Palvelinten hallinta kotitehtävät 5 (Syksy 2017)


Palvelinten hallinta kotitehtävät 5 (Syksy 2017)

Lähde  Tero Karvinen 2017: Palvelinten Hallinta, http://terokarvinen.com

Harjoitusympäristönä asennettu sekä livetikulta ajettu kustomoitu Xubuntu 16.04 LTS 3 64-bit

Windows-harjoitusympäristönä Windows 10 Pro 64-bit

Harjoituskoneen tiedot:

Emolevy X79A-GD65 (8D)

Prosessori Intel(R) Core(TM) i7-3930K

16GiB RAM

 

a) Asenna Puppetin orjaksi vähintään kaksi eri käyttöjärjestelmää. (Tee alusta, pelkkä tunnilla tehdyn muistelu ei riitä).

 

Tavoitteena oli asentaa Lenovo Ideapadin 64-bittinen Windows 10 Home -kone Puppet-orjaksi. Lähteenä harjoitukseen käytettiin Tero Karvisen kirjoitusta sekä tunnilla Tatu Erkinjuntin kanssa tehtyjä moduuleja.

Harjoitus aloitettiin poistamalla UAC käytöstä. Poisto onnistuu esim. siirtymällä Control Panel -> User Accounts -> Change User Account Control Settings. Kun asetus on muutettu kuvan mukaiseksi, tietokone täytyi käynnistää uudestaan.

 

 

Seuraavaksi ladattiin Puppet asennuspaketti Puppetlabsin sivuilta. Tiedoston versio oli puppet-3.8.7-x64.msi. Puppet asennettiin järjestelmänvalvojan oikeuksilla oletuskansioon. Asennusvaiheessa ohjelma kysyi Puppet masterin domainosoitetta, joksi määriteltiin aikaisemmin luotu puppet.simosuominen.com. Asennuksen jälkeen testattiin puppettia siirtymällä Windowsin Command Promptiin, jälleen järjestelmänvalvojan oikeuksilla (Run as Administrator).

Command Promptissa ajettiin vanha kunnon komento puppet agent -tdv. Vastauksena saatiin tieto, että sertifikaattia ei vielä löytynyt, joten siirryttiin Puppet master-virtuaalipalvelimelle hyväksymään sertifikaatti.

 

Sertifikaatin hyväksymisen jälkeen luotiin yksinkertainen hellosimo -moduuli testausta varten. Moduuli lisättiin masterkoneen site.pp -tiedostoon ja ajettiin orjakoneella uudestaan puppet agent -tdv -komento. Moduulin luoma hellosimo.txt -tiedosto löytyi C: juuresta niin kuin pitikin.

 

Toiseksi orjajärjestelmäksi valittiin ensimmäinen Linux distro, joka sattui tulemaan vastaan. Tällä kertaa valituksi tuli Linux Mint 18.2 64-bittinen Hyper-V virtuaalikoneen kautta ajettuna. Valitettavasti puppetin asennus ks. käyttöjärjestelmään ei poikennut mitenkään Xubuntun Puppetin asennuksesta. Lopputuloksena kaksi uutta käyttöjärjestelmää puppet.simosuominen.com Puppetmasterin orjana.

 

b) Säädä Windows-työpöytää. Voit esimerkiksi asentaa jonkin sovelluksen ja tehdä sille asetukset.

 

Jatkettiin Puppet-orja Lenovo-läppärin kanssa säätämistä asentamalla orjakoneelle ohjelmia. Ensin asennettiin master-konelle puppetlabs/windows -moduuli, joka sisältää pakettienhallintaohjelman (Chocolatey) ja muita Windows-orjan tarvitsemia työkaluja.

$ sudo apt-get update

$ sudo puppet module install puppetlabs/windows

Seuraavaksi luotiin uusi moduuli ohjelmien asennusta varten. Moduuliin tuli lisätä viittaus pakettienhallintaohjelmaan, jotta asennus onnistuu.

 

Moduulia ajettaessa saatiin virheilmoitus:

notice: Run of Puppet configuration client already in progress; skipping (C:\ProgramData\PuppetLabs\puppet\var\state\agent_catalog_run.lock exists)

 

Aloin tutkimaan käynnissä olevia prosesseja ja palveluita ja kokeilin ajaa moduulin kahden minuutin päästä uudestaan. Tällä kertaa moduuli asensi ohjelmat ilman virheilmoituksia.

Windows-orjakoneen kustomointi jatkuu kurssin loppumoduulissa.

 

 

 

Tätä dokumenttia saa kopioida ja muokata GNU General Public License (versio 3 tai uudempi) mukaisesti. http://www.gnu.org/licenses/gpl.html

Simo Suominen


Palvelinten hallinta kotitehtävät 4 (Syksy 2017)


Palvelinten hallinta kotitehtävät 4 (Syksy 2017)

Lähde  Tero Karvinen 2017: Palvelinten Hallinta, http://terokarvinen.com

Harjoitusympäristönä asennettu sekä livetikulta ajettu kustomoitu Xubuntu 16.04 LTS 3

Harjoituskoneen tiedot:

Emolevy X79A-GD65 (8D)

Prosessori Intel(R) Core(TM) i7-3930K

16GiB RAM

 

Viikon harjoitusten tavoitteena oli kokeilla Puppetin lisäksi kahta muuta keskitetyn hallinnan järjestelmää, Ansiblea ja Salt:ia.

Molemmat järjestelmät asennettiin ja niiden toimintaa testattiin yksinkertaisen “moduulin” avulla.

 

a) Kokeile Ansiblea

 

Testilaitteistona kaksi kappaletta Hyper-V:llä luotuja virtuaalikoneita, joille oli asennettu 64-bittinen Xubuntu 16.04.3 LTS versiot. Tavoitteena oli asentaa koneelle 1 Ansible ja määritellä asetukset niin, että luotu yksinkertainen moduuli voitiin ajaa koneella 2.

Harjoitus aloitettiin asentamalla “herra” -koneelle Ansible ja OpenSSH suojausavainten luontia varten

$ sudo apt-get update

$ sudo apt-get -y install openssh-server openssh-client ssh ansible

Seuraavaksi määriteltiin “orja” -virtuaalikoneen IP-osoite Ansiblen hosts -tiedostoon ryhmän [orja] alle

$ sudoedit /etc/ansible/hosts

 

Toiselle virtuaalikoneelle asennettiin samat SSH-ohjelmat, mutta Ansiblea ei tarvinnut asentaa kohdelaitteelle. Tässä vaiheessa varmistettiin vielä, että herra pystyi pingaamaan orjaa.

Seuraavaksi luotiin herrakoneelle salausavain, joka siirrettiin orjakoneelle. Avaimen toiminta testattiin ottamalla SSH-yhteys herrakoneelta orjakoneelle.

ssh-keygen -t rsa

ssh-copy-id orja@192.168.1.175

ssh orja@192.168.1.175

SSH-yhteys onnistui ilman salasanaa, mistä voitiin päätellä että avaimen siirto onnistui. Jatkettiin harjoitusta testaamalla orjakoneen pingausta Ansiblen avulla.

$ ansible orja -m ping

Tuloksena saatiin seuraava virheilmoitus

 

Lisäämällä -vvvv komentoon saatiin lisätietoja virheilmoituksesta.

 

Virheilmoituksesta ei suoraan saatu selvää, mikä ongelmana oli. Virheilmoituksen google-hakutulosten perusteella ongelman voi kiertää lisäämällä käyttäjän komentoon. Testausta jatkettiin seuraavalla komennolla:

$ ansible orja -m ping -u orja

Tällä kertaa komento meni läpi. Oletettavasti käyttäjää ei tarvitse lisätä komentoon jos käyttäjänimi on sama kummallakin laitteella. Seuraavaksi luotiin yksinkertainen Ansible playbook ajettavaksi orja-koneella.

$ nano hellosimo.yml

Tiedostoon määriteltiin hostit, joilla ks. playbook ajetaan sekä tehtävät jotka halutaan ajettavan. Tällä kertaa tehtävä oli luoda tekstitiedosto halutulla sisällöllä haluttuun kohteeseen.

---
- name: hellosimo
  hosts: orja
  tasks:
  - name: Luo /tmp/hellosimo.txt tiedosto halutulla sisällolla
    copy: content="Hello Simo!\n" dest=/tmp/hellosimo.txt

Luotu playbook ajettiin komennolla ansible-playbook hellosimo.yml -u orja. Komento meni läpi ilman ongelmia ja Ansiblen tulostus paljasti, että hostiin 192.168.1.175 tehtiin muutoksia. Siirtymällä orjakoneelle ja hakemalla tiedoston /tmp/hellosimo.txt voitiin todeta, että luotu playbook oli ajettu onnistuneesti orjakoneella.

 

Lähteet:

Ansible – A “hello world” Playbook

Joona Leppälahti – CCM/Ansible raportti

b) Kokeile Salt:tia

 

Tavoitteena oli luoda Vagrantin ja Virtualboxin avulla virtuaalikone, josta tehtäisiin rautakoneen Salt-minion, eli orjakone. Harjoitus aloitettiin poistamalla edelliset virtuaalikonekokeilut.

$ vagrant destroy
$ rm Vagrantfile
$ vagrant init bento/ubuntu-16.04
$ vagrant up
$ vagrant ssh

Seuraavaksi asennettiin luodulle virtuaalikoneelle salt-minion ja määriteltiin sen herraksi testikoneen IP-osoite.

$ sudo apt-get update && sudo apt-get -y install salt-minion
$ sudoedit /etc/salt/minion

$ sudo service salt-minion restart

minion -asetustiedosto sisältää pelkkää kommenttia, jonka voi tyhjentää tai säästää myöhempää käyttöä varten. Virtuaalikoneen minion -tiedosto tyhjennettiin ja lisättiin rivi master: IP-osoite osoittamaan rautakoneen IP-osoitteeseen. Lopuksi käynnistettiin salt-minion -palvelu uudestaan, jotta orja ymmärtäisi hakea uutta määriteltyä isäntää. Tämän jälkeen siirryttiin testikoneelle asentamaan salt-master ja muokkaamaan asetuksia.

$ sudo apt-get update && sudo apt-get -y install salt-master
$ sudo salt-key list

vagrant.vm -orjakone löytyi hyväksymättömien avainten listasta (ks. kuva). Avaimen hyväksymisen jälkeen ajettiin komento, jolla hyväksytyillä orjakoneilla voitiin ajaa komentoja.

 

$ sudo salt-key --accept vagrant.vm
$ sudo salt '*' cmd.run "hostname -I"

Komennolla ajettiin siis kaikissa (‘*’) hyväksytyissä salt-slave -koneissa komento “hostname -I”. Tällä kertaa orjia ei ollut kuin yksi. Lopputuloksena voitiin todeta, että herra- ja orjakoneen asetukset toimivat ja harjoitusta voitiin jatkaa. Lopuksi testailtiin komentoja orjakoneille. Paketin asennus ja tietojen hankkiminen orjakoneelta onnistuivat mainiosti.

$ sudo salt '*' pkg.install tree    //paketin asennus
$ sudo salt '*' disk.usage    //kovalevyn tietoja

Lähteenä käytettiin SaltStackin Salt in 10 Minutes -tutoriaalia ja Tero Karvisen kirjoitusta.

 

 

 

Tätä dokumenttia saa kopioida ja muokata GNU General Public License (versio 3 tai uudempi) mukaisesti. http://www.gnu.org/licenses/gpl.html

Simo Suominen


Palvelinten hallinta kotitehtävät 3 (Syksy 2017)


Palvelinten hallinta kotitehtävät 3 (Syksy 2017)

Lähde  Tero Karvinen 2017: Palvelinten Hallinta, http://terokarvinen.com

Harjoitusympäristönä asennettu sekä livetikulta ajettu kustomoitu Xubuntu 16.04 LTS 3

Harjoituskoneen tiedot:

Emolevy X79A-GD65 (8D)

Prosessori Intel(R) Core(TM) i7-3930K

16GiB RAM

a) Asenna useita orjia yhteen masteriin. Ainakin yksi rauta- ja useampia virtuaalisia orjia.

c) OrjaSkripti: Tee skripti, joka muuttaa koneen Puppet-orjaksi tietylle masterille.

d) (vapaaehtoinen) Laita skripti Vagrantfile:n provisointiskriptiksi.

 

Harjoituksen tavoitteena oli asentaa useampi orja yhteen masteriin. Harjoitusta varten luotiin Vagrantin avulla 5kpl virtuaalikoneita, joille määriteltiin Puppet isäntä Vagrantfilen provisiointiskriptin avulla. Lisäksi otettiin vielä 1kpl rauta-orjia.

$ sudo apt-get -y install vagrant virtualbox

Todettiin, että molemmat oli asennettu. Seuraavaksi muokattiin Vagrantfile -tiedostoa käyttäjän kotihakemistossa. Apuna käytettiin Tero Karvisen kirjoitusta.  

 

 

Käytetty Vagrantfile oli kuvan mukainen. Slavesetup-Puppet-moduuli (sekä Vagrantfile) löytyy Simo Suomisen GitHubista. Moduuli muokkaa /etc/puppet/puppet.conf -tiedostoa ja määrittelee masterkoneeksi virtuaalipalvelimen, jonka asetukset on määritelty aiemmassa tehtävässä. Seuraavaksi käynnistettiin Vagrant-boksit.

$ vagrant up

Ensimmäisen virtuaalikoneen käynnistysvaiheessa saatiin seuraava virheilmoitus:

Error: Could not request certificate: Failed to open TCP connection to puppet.simosuominen.com:8140 (Connection refused - connect(2) for "puppet.simosuominen.com" port 8140)

Siirryin SSH-yhteydellä virtuaalikoneelle ja tarkistin palomuurin asetukset, jotka olivat kunnossa. Kävi ilmi, että puppetmaster-palvelu oli pysäytetty, joten se käynnistettiin uudelleen. Seuraavaksi saatiin eri virheilmoitus:

==> slave03: Error: puppet agent -tdv returned 1 instead of one of [0]
==> slave03: Error: /Stage[main]/Slavesetup/Exec[puppet-agent]/returns: change from notrun to 0 failed: puppet agent -tdv returned 1 instead of one of [0]

 

Virheilmoitus ei vaikuttanut niin kriittiseltä, joten harjoitusta päätettiin jatkaa ja siirryttiin taas masterkoneelle tutkimaan, saadaanko orjakoneiden sertifikaatit hyväksyttyä.

$ sudo puppet cert list

 

Sertifikaatit hyväksyttiin komennolla sudo puppet cert sign slave0x (jossa x on muuttuva numero). Seuraavaksi siirryttiin testikoneelta SSH-yhteyden kautta Vagrant-koneelle slave05.

$ vagrant ssh slave05
$ cat /tmp/helloworld.txt

Cat-komennolla varmistettiin, että Puppetmasterin site.pp -tiedostoon määriteltyä helloworld-moduulia ei oltu vielä ajettu orjakoneella. Tämä oli itsestään selvää, joska slavesetup-moduuli ajettiin ennen kuin orjakoneen sertifikaatti oli hyväksytty. slave05 -koneella ajettiin vielä pari komentoa, jotta moduulin ajo onnistui.

$ sudo puppet agent -tdv
$ sudo puppet --enable$ sudo puppet agent -tdv
$ cat /tmp/helloworld.txt

Ongelmaksi täysautomaation kannalta jäi, että orjakoneiden sertifikaatit täytyy hyväksyä käsin. Automaattinen sertifikaattien hyväksyminen on mahdollista, mutta koska masterkoneena toimi virtuaalipalvelin, jätin tämän vaihtoehdon kokeilematta tietoturvasyistä. Orjakoneiden automatisointi toimi sinänsä mainiosti.

Rautakoneen lisääminen orjaksi

Testikoneena Lenovon kannettava, käyttöjärjestelmänä kustomoitu 64-bittinen live-USB Xubuntu 16.04.3. Kannettavalle asennettiin Git ja Puppet, haettiin käyttäjän GitHubista moduulit ja ajettiin slavesetup-moduuli.

$ sudo apt-get update && sudo apt-get -y install git puppet
$ git clone https://github.com/suomisim/puppet
$ sudo puppet apply --modulepath /home/suomisim/puppet/modules -e "include slavesetup"

Moduulin ajo antoi saman virheilmoituksen kuin virtuaalikoneella ajettaessa. Puppetmaster-palvelimella hyväksyttiin sertifikaatti, jonka jälkeen testikoneella ajettiin sudo puppet –enable ja sudo puppet agent -tdv -komennot, jotta yhteys toimisi ja helloworld.txt -tiedostoon päästiin käsiksi. Nyt samalla Puppetmaster-palvelimelle oli 5 virtuaalikonetta ja 1 rautakone orjana.

b) Kerää tietoa orjista: verkkokorttien MAC-numerot, virtuaalinen vai oikea… (Katso /var/lib/puppet/)

 

Jatkettiin harjoitusta ja kirjauduttiin masterkoneelle. Kansiosta /var/lib/puppet/yaml/facts löytyi reilusti tietoja orjakoneista. Kuvan orja “1001px” oli viime kevään tehtävässä lisätty läppäri, jonka lisäksi oma .yaml -tiedosto löytyi Xubuntulle sekä viidelle luoduille Vagrant-virtuaaliorjille. is_virtual -tietueesta voitiin päätellä, että kuvan kone oli fyysinen laite. Alempana tiedostosta löytyi laitteen mac-osoite.

 

 

 

f) Vapaaehtoinen: Unelmien tikku. Tee unelmiesi USB-live-tikku.

 

Päivitetään myöhemmin

 

 

 

 

e) Vapaaehtoinen: Oikeaa elämää. Ratkaise jokin kurssin ulkopuolinen asia Puppetilla.

 

Tätä dokumenttia saa kopioida ja muokata GNU General Public License (versio 3 tai uudempi) mukaisesti. http://www.gnu.org/licenses/gpl.html

Simo Suominen


PHP-ohjelmointitehtäviä


Web-ohjelmointi PHP:llä

Kurssin kotisivu

 

Oppimistehtävä 1

Web-sovellus, jonka lomakkeen tiedot tarkastetaan luotujen sääntöjen mukaan. Kenttien käsittely on toteutettu luokan avulla. Luokka sisältää konstruktorin,

omat attribuutit joka tekstikentälle sekä set-, get- ja check-metodit jokaiselle attribuutille.

 

Harjoituksessa käytetty HTML5, PHP, Bootstrap, regex

Linkki

 

Oppimistehtävä 2

Oppimistehtävä 1:n sovellukseen lisätty tietojen näyttösivu. Tiedot tallennetaan laittamalla olio istuntoon (session). Näyttösivulla on mahdollisuus korjata annettuja tietoja.

Asetukset-sivulle lisätty mahdollisuus asettaa käyttäjänimi, joka tallennetaan cookieen.

Linkki

 

 

Oppimistehtävä 3

Oppimistehtävä 2:n sovellukseen lisätty tietokantayhteys. Luodun henkilön tiedot voi nyt tallentaa tietokantaan. Lisäksi tietokannasta voidaan hakea kaikki henkilöt

sekä hakea Jsonin avulla henkilöitä sukunimen perusteella (ääkköset eivät toimi haussa). Tietokannasta voi myös poistaa henkilöitä.

Linkki

 

 

 

 

Tätä dokumenttia saa kopioida ja muokata GNU General Public License (versio 3 tai uudempi) mukaisesti. http://www.gnu.org/licenses/gpl.html

Simo Suominen


Palvelinten hallinta kotitehtävät 2 (Syksy 2017)


Palvelinten hallinta kotitehtävät 2 (Syksy 2017)

Lähde  Tero Karvinen 2017: Palvelinten Hallinta, http://terokarvinen.com

Harjoitusympäristönä asennettu sekä livetikulta ajettu kustomoitu Xubuntu 16.04 LTS 3

Harjoituskoneen tiedot:

Emolevy X79A-GD65 (8D)

Prosessori Intel(R) Core(TM) i7-3930K

16GiB RAM

 

h2a) Gittiä livenä: Tee ohjeet ja skriptit, joilla saat live-USB -tikun konfiguroitua hetkessä – ohjelmat asennettua ja asetukset tehtyä.

 

Harjoituksen tavoitteena oli saada Xubuntun live-USB -tikku käyttökuntoon mahdollisimman nopeasti. Harjoituksessa päätettiin luoda kustomoitu live-USB -tikku, johon sisällytettäisiin tarvittavat ohjelmat ja tiedostot. Ohjeena käytettiin AskUbuntun ohjetta.

 

Kustomoitu live-USB -tikku

Käyttöjärjestelmän kustomointia varten haettiin Cubic-ohjelma.

$ sudo apt-add-repository ppa:cubic-wizard/release

$ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 6494C6D6997C215E

$ sudo apt-get update

$ sudo apt-get install cubic

Tämän jälkeen ohjelma ajettiin käynnistysvalikosta ja valittiin projektille oma kansio. Jos käytössä on monta eri projektia, niille kaikille tulee luoda oma kansio.

Seuraavaksi valittiin muokattava ISO-tiedosto, joka oli ladattu Xubuntun lataussivulta. Lisäksi valittiin luotavalle custom-levykuvalle nimi.

Tämän jälkeen ohjelma purki ISO-tiedoston sisällön ja avasi komentokehotteen, jonka kautta live-USB -käyttöjärjestelmää oli mahdollista muokata. Muutokset tehtiin chroot-ympäristössä, joten sudo -etuliitettä ei tarvittu komentoihin.

$ apt-get update

$ apt-get install git puppet

$ adduser suomisim

$ adduser suomisim sudo

$ setxkbmap fi

$ nano /etc/rc.local

$ nano /etc/hosts

Ylläolevilla komennoilla muokattiin tiedostoja rc.local ja hosts. rc.local -tiedostoon lisättiin komento, joka ajetaan joka kerta, kun Xubuntu käynnistetään livetikulta. Hosts-tiedostoa muokkaamalla voitiin asettaa uusi hostname.

 

Kun muutokset, valittiin Next. Seuraavaksi valittiin kernelversio, jota käytetään kun käyttöjärjestelmä ajetaan livetikulta. Jos edellisessä vaiheessa ei lisätty kerneleitä, vaihtoehtoja on vain yksi. Tämän jälkeen oli mahdollista valita ohjelmiston asennuksen jälkeen poistettavat paketit. Annoin ohjelman käyttää oletusasetuksia.  Seuraavaksi ohjelma loi uuden ISO-tiedoston annettujen asetusten perusteella. Lopuksi voitiin poistaa muokatun projektin tiedostot, pl. luotu ISO-tiedosto.

Luodusta ISO-tiedostosta tehtiin livetikku Unetbootin -ohjelman avulla. Tikku bootattiin testikoneella onnistuneesti ja ilman virheilmoituksia. Seuraavaksi ajettiin testejä, joilla voitiin päätellä mitä onnistui ja mitä ei. Kirjautuessa huomattiin, että luotu käyttäjä toimi oletuksena, mutta hostname oli yhä Xubuntu. Terminal Emulatoria käytettäessä huomattiin, että näppäimistön asetukset olivat väärin.

 

Epäonnistumisesta huolimatta päätettiin yrittää uudestaan täydellisen livetikun luontia. Tällä kertaa annettiin seuraavat komennot muokkausvaiheessa:

$ apt-get update

$ apt-get install git puppet

$ adduser suomisim

$ adduser suomisim sudo

$ nano /etc/rc.local

$ nano /etc/default/keyboard

Keyboard -tiedostoon muutettiin XKBLAYOUT=”us” kohtaan “fi” ja muokattiin rc.local -tiedostoon yllä olevan kuvan lisäksi rivi hostctl set-hostname itlabra. Tiedosto luotiin ja siirrettiin USB-tikulle kuten aiemminkin ja bootattiin testikoneella.

Testivaiheessa voitiin todeta, että näppäimistön asetukset ovat oikein. Hostname ei muuttunut, joten se täytyy korjata skriptin tai Puppet-moduulin avulla. GitHubista rc.local -tiedoston avulla haettu Puppet-moduulien kansio löytyi luodun käyttäjän kotihakemistosta. Kansioon oli aiemmin luotu skriptit moduulien kopiointia ja ajamista varten. Harjoituksen lopputuloksena oli Xubuntu 16.04 LTS 3 livetikku, joka oli helppo ottaa käyttöön oppituntien alussa.

 

h2b) Kokeile Puppetin master-slave arkkitehtuuria kahdella koneella. Liitä raporttiisi listaus avaimista (sudo puppet cert list) ja pätkä herran http-lokista (sudo tail -5 /var/log/puppet/masterhttp.log).

 

Harjoitus toteutettiin testikoneen 64-bittisen Windows 10-käyttöjärjestelmän kautta luomalla Hyper-V:n kautta kaksi virtuaalikonetta. Toisessa virtuaalikoneessa oli asennettuna 64-bittinen Ubuntu Server 16.04.3 ja toisessa koneessa ajettiin Xubuntu 16.04.3 livetikkua. Virtuaalikoneille oli määritelty verkkoyhteys ja ping-komento toimi.

 

Masterkoneen asetukset

Ensin määriteltiin masterkoneen asetukset. Puppetmaster -ohjelmiston asennuksen jälkeen ohjelman palvelu pysäytettiin ja alkuperäiset sertifikaatit poistettiin.

$ sudo apt-get update

$ sudo apt-get install puppetmaster

$ sudo service puppetmaster stop

$ sudo rm -r /var/liv/puppet/ssl

Tämän jälkeen muokattiin /etc/hosts -tiedostoa kuvan mukaisesti. Näin master-palvelimelle saatiin domain-osoitetta vastaava osoite Puppettia varten.

Tämän jälkeen muokattiin /etc/puppet/puppet.conf -tiedostoa, jonne lisättiin [master] -rivin alle viittaus luotuun DNS-osoitteeseen.

[master]

dns_alt_names = itlabra.local

Lopuksi käynnistettiin puppetmaster -palvelu uudestaan, jolloin uudet sertifikaatit luodaan automaattisesti.

$ sudo service puppetmaster start

 

Orjakoneen asetukset

Orjakoneelle asennettiin Puppet, jonka palvelu pysäytettiin ja muokattiin jälleen /etc/puppet/puppet.conf -asetustiedostoa.

$ sudo apt-get update

$ sudo apt-get install puppet

$ sudo service puppet stop

$ sudoedit /etc/puppet/puppet.conf

 

puppet.conf -tiedostoon lisättiin viittaus masterkoneeseen [agent] -tietueen alle. Tämän jälkeen käynnistettiin palvelu uudestaan ja testattiin yhteyttä.

$ sudo service puppet start

$ sudo puppet agent -tdv

Komennon ajo onnistui ilman virheilmoituksia. Viimeisellä rivillä ohjelma totesi, että sertifikaatteja ei löydy. Seuraavaksi siirryttiin takaisin masterkoneelle katsomaan,

onnistuisiko sertifikaattien lisäys.

 

Sertifikaatit ja moduulin testaus

Masterkoneella haettiin orjakoneen sertifiointipyyntö ja hyväksyttiin se. Tämän jälkeen haettiin käyttäjän GitHubista yksinkertainen moduuli, joka lisättiin ajettavaksi kaikille orjakoneille.

$ sudo puppet cert list

$ sudo puppet cert --sign xubuntu

$ cd

$ git clone https://github.com/suomisim/puppet

Tämän jälkeen siirrettiin haluttu moduuli /etc/puppet/modules -kansioon ja muokattiin /etc/puppet/manifests/site.pp -tiedostoa, jotta moduuli otetaan käyttöön orjakoneilla. Alla olevassa kuvassa näkyy, kuinka “helloworld” -moduuli otettiin käyttöön.

 

Lopuksi siirryttiin takaisin orjakoneelle ja ajettiin taas komento sudo puppet agent -tdv. Tuloksena kolmas, informatiivinen virheilmoitus, joka neuvoi ottamaan puppet agentin käyttöön, sillä ks. palvelu on oletuksena pois käytöstä. Jatkettiin antamalla suositeltu komento ja testaamalla jälleen yhteys ja moduulin toiminta.

$ sudo puppet agent --enable

$ sudo puppet agent -tdv

$ cat /etc/helloworld.txt

Tällä kertaa ei saatu enää virheilmoituksia, ja hellowowrld.txt -tiedosto löytyi halutusta kansiosta. Näin ollen voitiin todeta, että master-slave -arkkitehtuuri toimi kahden testilaitteen välillä.

Lähteenä käytin aiempaa harjoitustani samasta aiheesta.

 

 

Tätä dokumenttia saa kopioida ja muokata GNU General Public License (versio 3 tai uudempi) mukaisesti. http://www.gnu.org/licenses/gpl.html

Simo Suominen


Palvelinten hallinta kotitehtävät 1 (Syksy 2017)


Palvelinten hallinta kotitehtävät 1 (Syksy 2017)

Lähde  Tero Karvinen 2017: Palvelinten Hallinta, http://terokarvinen.com

Harjoitusympäristönä asennettu Xubuntu 16.04, Xenial Xerus

Harjoituskoneen tiedot:

Emolevy X79A-GD65 (8D)

Prosessori Intel(R) Core(TM) i7-3930K

16GiB RAM

 

H1. Asenna jokin muu demoni kuin Apache. Raportoi, miten rakensit, selvitit ja testasit kunkin osan (esim. sudo puppet resource, puppet describe, lähteet…). Julkaise myös modulisi lähdekoodi niin, että sen voi helposti ottaa käyttöön.

 

Osa 1: Packet

Harjoituksen tavoitteeksi otettiin UFW-palomuurin asennus ja asetusten muokkaus Puppetin avulla. UFW (Uncomplicated Firewall) on helppokäyttöiseksi tarkoitettu työkalu Netfilter-palomuurin hallintaan. Harjoitus aloitettiin poistamalla testikoneesta UFW ja sen asetukset purge-komennolla.

$ sudo apt-get purge ufw

Seuraavaksi luotiin skriptin avulla uusi Puppet-moduuli ufwmod ja tarvittavat kansiot ja tiedostot. Luodut tiedostot ja kansiot näkyvät raportin lopussa olevassa kuvassa (readme.md -tiedosto ei ole tarpeellinen). Jatkettiin harjoitusta muokkaamalla luotua init.pp -tiedostoa. Ensimmäiseksi lisättiin moduuliin asennettava paketti ufw.

class ufwmod {
    package { 'ufw':
        ensure => 'installed',
    }
}

Seuraavaksi varmistettiin, että luotu moduuli toimi oikein. Moduuli kopioitiin /etc/puppet/modules -kansioon ja ajettiin alla olevalla komennolla.

$ sudo puppet apply -e  ‘class {“ufwmod”:}’

Moduulin käynnistys sujui ongelmitta ja UFW asennus varmistettiin komennolla sudo ufw status. UFW oli asennettu, mutta tilassa inactive, sillä ohjelman käyttöönotto vaatii erillisen komennon.

 

Osa 2: Exec

Harjoitusta jatkettiin poistamalla UFW asennus koneelta ja lisäämällä init.pp -tiedostoon komento, jolla UFW otettaisiin käyttöön asennuksen jälkeen.

class ufwmod {
 
 # Komentojen polun määrittely
 Exec { path => [ '/bin/', '/sbin/' , '/usr/bin/', '/usr/sbin/' ] }
 
 # Paketin asennus
     package { 'ufw':
         ensure => 'installed',
     }
 
 # Komennon ajo
    exec { 'ufw-enable':
         command => 'ufw enable',
         require => Package['ufw'],
    }
}

Tiedostoon lisättiin komento ufw enable, joka vaatii, että paketti ufw on asennettuna. Moduuli todettiin toimivaksi, sillä paketin asennus onnistui ja UFW oli tilassa active.

 

Osa 3: File

Seuraavaksi tehtiin reikiä palomuuriin, jotta haluttu liikenne pääsisi muurista läpi. Ubuntu Wikin mukaan käyttäjän tekemät asetukset tallentuvat tiedostoihin /etc/ufw/user.rules ja user6.rules.

Harjoitusta varten päätettiin avata portit 22, 80 ja 443 TCP. Muutokset tehtiin ensin käsin, jonka jälkeen asetustiedostoista otettiin kopiot moduulin templates -kansioon. Moduuliin lisättiin tämän jälkeen osa, joka siirtää asetustiedostot oikeaan paikkaan kun moduuli ajetaan.

$ sudo ufw allow 22/tcp$ sudo ufw allow 80/tcp
$ sudo ufw allow 443/tcp
$ sudo ufw status
$ cd /etc/ufw/$ sudo cp user.rules /home/suomisim/puppet/modules/ufwmod/templates/user.rules.erb
$ sudo cp user6.rules /home/suomisim/puppet/modules/ufwmod/templates/user6.rules.erb
$ sudo apt-get purge ufw

Seuraavaksi muokattiin jälleen init.pp -tiedostoa.

class ufwmod {
 
 # Komentojen polun määrittely
 Exec { path => [ '/bin/', '/sbin/' , '/usr/bin/', '/usr/sbin/' ] }
 
 # Paketin asennus
     package { 'ufw':
         ensure => 'installed',
     }
 
 # Komennon ajo
     exec { 'ufw-enable':
         command => 'ufw enable',
         require => Package['ufw'],
     }
 # Asetustiedoston muokkaus (IPv4)
     file {'/etc/ufw/user.rules':
         content => template('ufwmod/user.rules.erb'),
         require => Package['ufw'],
     }
 # Asetustiedoston muokkaus (IPv6)
     file {'/etc/ufw/user6.rules':
         content => template('ufwmod/user6.rules.erb'),
         require => Package['ufw'],
     }
}

Moduuli toimi ongelmitta, mutta portit pysyivät kiinni. Moduuliin päätettiin lisätä palomuurin service, joka voitiin potkaista käynnistymään uudelleen aina, kun asetustiedostoja muokataan.

 

Osa 4: Service

Muokattiin init.pp -tiedostoa (toivottavasti) viimeistä kertaa. Tiedostoon lisättiin viittaus UFW palveluun, joka vaatii UFW paketin asennuksen. Asetustiedostojen siirtoon lisättiin huomautus palveluun, joka käynnistyy uudelleen kun asetustiedostot siirretään.

class ufwmod {
 
 # Komentojen polun määrittely
 Exec { path => [ '/bin/', '/sbin/' , '/usr/bin/', '/usr/sbin/' ] }
 
 # Paketin asennus
     package { 'ufw':
         ensure => 'installed',
     }
 
 # Komennon ajo
     exec { 'ufw-enable':
         command => 'ufw enable',
         require => Package['ufw'],
     }
 # Asetustiedoston muokkaus (IPv4)
     file {'/etc/ufw/user.rules':
         content => template('ufwmod/user.rules.erb'),
         require => Package['ufw'],
         notify => Service['ufw'],
     }
 # Asetustiedoston muokkaus (IPv6)
     file {'/etc/ufw/user6.rules':
         content => template('ufwmod/user6.rules.erb'),
         require => Package['ufw'],
         notify => Service['ufw'],
     }
 # Servicen toiminnan varmistaminen
     service { 'ufw':
         ensure => 'true',
         enable => 'true',
         require => Package['ufw'],
     }
}

Moduulin testaamista varten UFW poistettiin jälleen, moduuli siirrettiin /etc/puppet/modules -kansioon ja ajettiin skriptin avulla (tai raportin alussa käytetyllä komennolla). Moduulin ajon jälkeen palomuurin tilanne tarkistettiin sudo ufw status -komennolla.

Voitiin todeta, että moduuli toimii niin kuin pitääkin. Asetustiedostojen syntaksi oli aika yksinkertainen, joten uusien sääntöjen luominen onnistuu ilman, että niitä tehdään ensin käsin.

Alla olevassa kuvassa näkyy moduulin rakenne ja tarvittavat tiedostot + ylimääräinen readme.md -tiedosto.

Lopuksi projekti vietiin GitHubiin käyttäjän omaan puppet-repositoryyn. Koska moduulia muokattiin käyttäjän kotihakemistossa ja repon omassa kansiossa, tiedostoja ei tarvinnut siirrellä tässä vaiheessa mihinkään.

git add .

git commit -m 'Update ufwmod module'
git pull && git push

Moduuli löytyy Githubista Linkki

 

Tätä dokumenttia saa kopioida ja muokata GNU General Public License (versio 3 tai uudempi) mukaisesti. http://www.gnu.org/licenses/gpl.html

Simo Suominen


Palvelinohjelmointi – tehtäviä


Kurssin kotisivu

Tehtäviä GitHubissa

Huom. GitHubiin ei ole siirretty .properties -tiedostoja tietoturvasyistä. Näin ollen suurin osa tehtävistä ei toimi suoraan.

Huom2. Tietokantaa käyttävät harjoitukset antavat ensimmäisellä ajokerralla HTTP Status 500 virheilmoituksen, joka liittyy tietokantayhteyteen.

Harjoitukset toimivat kun ohjelman ajaa uudestaan.

Viikko 1

Jsp-sivu, joka sisältää lomakkeen, johon syötetään kirjan nimi, tekijätiedot ja ISBN-koodi. Luotiin servlet, joka poimii tarvittavat tiedot http-pyynnöstä ja tallentaa ne Kirja-olioon requestin attribuutiksi.

Sivu ohjaa http-pyynnön servletiltä toiselle jsp-sivulle, joka osaa tulostaa Kirja-olion tiedot html-muotoiltuna.

Kirja-Ohjelma

 

Viikko 2

 

PreparedStatement, SQL Injection

Jsp-sivu, joka lukee tietokannasta käyttäjänimiä. Käyttäjiä voi lisätä sekä poistaa tietokannasta.

Käyttäjänimet

 

Viikko 3

Maven, JUnit

Demo sisältää kaksi sovellusta, laskimen ja kellon. Laskin-luokan metodeita on testattu JUnit-yksikkötesteillä. SuomiKello-luokan metodeita on myös testattu yksikkötesteillä ja ulkoinen KelloLahde on rajattu testistä pois käyttäen Mock-oliota.

Viikkotentin harjoitusta varten Kello-sovellukseen on lisätty GmtIsoKello -luokka, joka näyttää GMT-ajan ISO-standardin mukaan. GmtIsoKello-luokan metodeita on myös testattu yksikkötestillä ja testi on lisätty AllTests-suiteen

Demo 11

 

Viikko 4

Spring Framework, Spring JDBC

Komentorivisovellus, joka hakee levyjen tietoja tietokannasta.

Viikkotentti 4 harjoitus 13 (GitHub)

 

Viikko 5

Spring Web MVC, Anonyymi sisäluokka, Callback, GeneratedKeyHolder

Lomake, jonka avulla käyttäjä luodaan tietokantaan. Kun lomakkeen avulla on luotu uusi henkilö tietokantaan, käyttäjä siirretään sivulle, joka hakee tietokannasta juuri lisätyn henkilön tiedot ja näyttää ne. Lisätty toiminnallisuus: henkilöt/lista -linkistä sivu hakee tietokannasta kaikkien henkilöiden tiedot.

Viikkotentti 5 harjoitus 11

 

Viikko 6

Internationalization (I18n), Localization (L10n), Bean validation (JSR 303), Custom annotation, Custom validator

Käyttäjä voi vaihtaa käyttöliittymän kieltä napin painalluksella. Kaikki kieliriippuvaiset tekstit on tallennettu kielikohtaisiin properties-tiedostoihin. Henkilön ominaisuuksia on laajennettu. Mikäli syötetty data ei ole validia, käyttäjä ohjataan takaisin lomakesivulle ja häntä opastetaan korjaamaan virheet.

Lisätty toiminnallisuus: Luotu demosovellukseen uusi validaattori kenttiin etunimi, sukunimi ja lahiosoite tarkastamaan, että merkkijono alkaa isolla kirjaimella. Toteutettu validointi uudella annotaatiolla, jonka nimi on @AlkaaIsollaKirjaimella.

Viikkotentti 6 harjoitus 12

 

Harjoitustehtävä

Spring Web MVC, Anonyymi sisäluokka, Callback,GeneratedKeyHolder, Internationalization (I18n), Localization (L10n),

Bean validation (JSR 303), Custom annotation, Custom validator

Käyttäjä voi kirjata järjestelmään painokirjauksia ja hakea kaikki tai tiettynä päivänä tehdyt kirjaukset. Validointia käytetään havaitsemaan tyhjät kentät ja väärässä muodossa annetut tiedot.

PainoOhjelma.v1


Apache Tomcat 8 asennus virtuaalipalvelimelle


Apache Tomcat 8 asennus virtuaalipalvelimelle

 

Tavoitteena oli asentaa Apache Tomcat 8 Palvelinohjelmoinnin kurssin harjoitustöiden esittelyä varten. Lähtötilanteessa käytössä oli virtuaalipalvelin, jossa oli asennettuna Ubuntu 16.04 LTS käyttöjärjestelmä ja LAMP-stack

WordPress-sisällönhallintajärjestelmää varten. Lähteenä käytettiin DigitalOceanin mainiota tutoriaalia.

 

Esivalmistelut

Tomcat vaatii Java Development Kitin asennuksen, joten se asennettiin ensimmäisenä.

$ sudo apt-get update
$ sudo apt-get install default-jdk

Seuraavaksi luotiin oma käyttäjä Tomcatille. Käyttäjä luotiin turvallisuussyistä ilman sudo-oikeuksia sekä mahdollisuuksia kirjautua sisään. Käyttäjän kotihakemistoksi annettiin /opt/tomcat/, minne Tomcat ohjelmisto asennettaisiin.

$ sudo groupadd tomcat
$ sudo useradd -s /bin/false -g tomcat -d /opt/tomcat tomcat

Tomcat 8 asennus

Seuraavaksi haettiin Tomcat 8 uusimman version osoite ohjelman lataussivuilta. Asennusta varten ladattiin Core version tar.gz -paketti.

$ cd /tmp
$ curl -O http://www.nic.funet.fi/pub/mirrors/apache.org/tomcat/tomcat-8/v8.5.20/bin/apache-tomcat-8.5.20.tar.gz
$ sudo mkdir /opt/tomcat
$ sudo tar xzvf apache-tomcat-8.5.20.tar.gz -C /opt/tomcat --strip-components=1

Kansioiden käyttöoikeudet

Tämän jälkeen päivitettiin kansioiden käyttäjäoikeuksia. käyttäjälle tomcat annettiin omistajuus koko asennuskansiolle. tomcat-ryhmälle annettiin lukuoikeus conf-kansioon ja sen sisältöön ja suoritusoikeus itse kansioon.

Lopuksi tomcat käyttäjälle annetaan omistajuus kansioille webapps, work, temp ja logs.

$ sudo chgrp -R tomcat /opt/tomcat

$ sudo chmod -R g+r conf

$ sudo chmod g+x conf

$ sudo chown -R webapps/ work/ temp/ logs/

systemd asetukset

systemd asetuksia muokkaamalla Tomcat 8:a voidaan ajaa palveluna ja se voidaan asettaa käynnistymään automaattisesti. Tomcatille täytyy myös kertoa, mihin kansioon Java on asennettu (JAVA_HOME -polku)

$ sudo update-java-alternatives -l

Tarvittava JAVA_HOME polku oli kuvan mukainen polku, jonka perään liitettäisiin /jre kansio eli tässä tapauksessa:

/usr/lib/jvm/java-1.8.0-openjdk-amd64/jre

Seuraavaksi luotiin Tomcat 8 asetukset systemd kansioon

$ sudoedit /etc/systemd/system/tomcat.service

Tiedoston sisältöön kopioitiin seuraavat tiedot, varmistaen että JAVA_HOME muuttuja viittasi oikeaan kansioon.

[Unit]
Description=Apache Tomcat Web Application Container
After=network.target

[Service]
Type=forking

Environment=JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk-amd64/jre
Environment=CATALINA_PID=/opt/tomcat/temp/tomcat.pid
Environment=CATALINA_HOME=/opt/tomcat
Environment=CATALINA_BASE=/opt/tomcat
Environment='CATALINA_OPTS=-Xms512M -Xmx1024M -server -XX:+UseParallelGC'
Environment='JAVA_OPTS=-Djava.awt.headless=true -Djava.security.egd=file:/dev/./urandom'

ExecStart=/opt/tomcat/bin/startup.sh
ExecStop=/opt/tomcat/bin/shutdown.sh

User=tomcat
Group=tomcat
UMask=0007
RestartSec=10
Restart=always

[Install]
WantedBy=multi-user.target

 

Seuraavaksi käynnistettiin Tomcat palvelu ja testattiin sen toimivuutta.

$ sudo systemctl daemon-reload
$ sudo systemctl start tomcat
$ sudo systemctl status tomcat

 

Palomuurin konfigurointi ja Tomcat serverin testaus

Tomcat käyttää porttia 8080, joka avattiin UFW-palomuurista liikennettä varten.

$ sudo ufw allow 8080

Tämän jälkeen voitiin testata serverin toimintaa siirtymällä osoitteeseen http://serverinosoite:8080

Tomcatin oletuskotisivu saatiin näkyviin, joten asennus oli onnistunut.  Manager App ja Host Manager sivut eivät vielä toimineet,

koska ne vaativat asetusten muokkausta. Tässä vaiheessa voitiin kuitenkin asettaa Tomcat palvelu käynnistymään automaattisesti järjestelmän käynnistyessä.

$ sudo systemctl enable tomcat

Lisäasetukset

Manager App ja Host Manager hallintaa varten Tomcatille täytyi seuraavaksi luoda käyttäjiä. Kuten kotisivulla näkyy, käyttäjiä hallitaan $CATALINA_HOME/conf/tomcat-users.xml -tiedostossa.

$ sudoedit /opt/tomcat/conf/tomcat-users.xml

Luotavalle käyttäjälle annettiin roolit manager-gui ja admin-gui, jolloin käyttäjällä pääsee hallitsemaan Manager App ja Host Manager toiminnallisuuksia. Käyttäjätiedot luotiin tomcat-users.xml -tiedostoon alla olevan kuvan mukaisesti

(luonnollisesti käyttäjätunnus ja salasana muutettiin…)

Oletusasetuksena Tomcat estää Manager App ja Host Manager toiminnallisuuksien käytön, jos niitä ohjataan suoraan serveriltä. Asetus otettiin pois päältä muokkaamalla kahta context.xml -tiedostoa.

$ sudoedit /opt/tomcat/webapps/manager/META-INF/context.xml
$ sudoedit /opt/tomcat/webapps/host-manager/META-INF/context.xml

Molemmista tiedostoista kommentoitiin ulos kuvan mukaiset kaksi riviä, jolloin Manager App ja Host Manager toiminnallisuuksia voi käyttää mistä tahansa. Vaihtoehtoisesti asetustiedostoista voi määritellä halutut IP-osoitteet, jotka voivat käyttää toiminnallisuuksia.

Asetusten muokkaamisen jälkeen Tomcat palvelu käynnistettiin uudestaan.

$ sudo systemctl restart tomcat

Tämän jälkeen sekä Manager App että Host Manager toimivat annetuilla käyttäjätunnuksilla. /opt/tomcat/webapps -kansioon siirretyt .war tiedostot voitiin ottaa käyttöön Manager App:in kautta.

 

 

Tätä dokumenttia saa kopioida ja muokata GNU General Public License (versio 3 tai uudempi) mukaisesti. http://www.gnu.org/licenses/gpl.html

Simo Suominen


Kesäopintoja 2017


Kesäopintoja 2017

 

Opiskelin kesän 2017 aikana täydentäviä opintoja Professional Summer School 2017 kautta. Opinnot olivat osa Haaga-Helia, Metropolia- ja Laurea-ammattikorkeakoulujen tarjoamia kesäopintoja. Kesäopinnot ovat erinomainen tapa laajentaa omaa osaamista ja opintokokonaisuutta kursseilla, joita oma oppilaitos ei välttämättä tarjoa. Kurssien toteutus oli hyvin suunniteltu ja voin suositella niitä kaikille kiinnostuneille! Kurssien suorituskieli oli englanti.

Professional Summer School (Haaga-Helia)

Alla olevasta linkistä löytyvät suorittamani kurssit ja niiden lyhyet kuvaukset. Pyrin mahdollisuuksien mukaan lisäämään kursseja varten toteutettuja yksinkertaisia projekteja.

Simo Suominen – Kesäopintoja 2017