Arkistot kuukauden mukaan: tammikuu 2014

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