Arkisto syyskuu 2012

Harjoitustehtävä 5: Apache

24.9.2012

Harjoitustehtävän aiheena oli nimipohjaisten “virtuaalipalvelimien” (name based virtual host) määritteleminen Apache HTTP palvelimella.
Harjoituksessa määriteltiin neljä virtuaalipalvelinta, joille annettiin erilaisia asetuksia liittyen PHP:n käyttöön sekä automaattiseen
hakemistolistaukseen. Lisäksi tutkittiin Apachen lokitiedostoista erilaisia HTTP statuskoodeja.

Harjoitusympäristö

Harjoitus suoritettiin 23.09.2012 opiskelijan kotona käyttäen henkilökohtaista tietokonetta. Internet-yhteytenä oli Elisa Oyj:n tarjoama VDSL tyyppinen 100/10 mbit kiinteä laajakaistayhteys. Harjoituksessa käytettiin Lenovo R60 kannettavaa tietokonetta, johon oli asennettu Xubuntu versio 12.04 32-bittinen Linux käyttöjärjestelmä.

Lenovo R60 kokoonpano:

  • Suoritin: Intel Core 2 Duo T56000 @1.83 Ghz
  • Keskusmuisti: 4 Gt DDR2
  • Kiintolevy: 100 Gt SATA150 54000rpm
  • Käyttöjärjestelmä: Xubuntu versio 12.04 32-bittinen

Virtuaalipalvelimen määrittely Apache palvelimessa

Aloitin harjoitustehtävän tekemisen päivittämällä Ubuntun pakettivarastot komennolla:

$sudo apt-get update

Pakettivarastojen päivitys kesti muutamia sekunteja.

Apache palvelin oli jo valmiiksi asennettuna koneella ja siihen oli otettu käyttöön käyttäjäkohtaiset public_html kansiot. Tein omaan kotihakemistooni kansion Apachen “virtuaalipalvelinta” varten komennolla:

$mkdir ~/public_html/eliimatt.com

Seuraavaksi siirryin muokkaamaan /etc/hosts tiedostoa komennolla:

$sudo nano /etc/hosts

Määrittelin /etc/hosts tiedostoon “virtuaalipalvelimen” nimitiedot lisäämällä rivit:

192.168.xxx.xxx www.eliimatt.com
192.168.xxx.xxx eliimatt.com

Määrittelyn mukaan “www.eliimatt.com” ja “eliimatt.com” viittaavat harjoitusympäristön tietokoneen paikalliseen IP-osoitteeseen.

Seuraavaksi ryhdyin muokkaamaan Apache:n asetustiedostoja. Siirryin Apache:n asetuskansioon sites-available, johon Apachen “virtuaalipalvelimet” määritellään:

$cd /etc/apache2/sites-available/

Tein Apachen oletuspalvelimen default tiedostosta eliimatt.com nimisen kopion:

$sudo cp default eliimatt.com

Muokkasin eliimatt.com tiedostoa nano editorilla:

$sudo nano eliimatt.com

Tiedoston sisällöksi tuli:

<VirtualHost *:80>
        ServerName www.eliimatt.com
        ServerAlias eliimatt.com
        DocumentRoot /home/eino/public_html/eliimatt.com
</VirtualHost>

Apachen asetusdirektiivit tarkoittavat seuraavaa:

• VirtualHost lohkon sisällä on varsinainen “virtuaalipalvelimen” määrittely. Asteriskimerkki * merkitsee kaikkia tietokoneen IP-osoitteita ja “:80″ TCP porttia 80, josta tämä “virtuaalipalvelin” ottaa vastaan HTTP liikennettä.

• ServerName on “virtuaalipalvelimen” nimi, jolle osoitettuun HTTP liikenteeseen tämä virtuaalipalvelin “vastaa”.

• ServerAlias on “virtuaalipalvelimen” vaihtoehtoinen nimi, johon “virtuaalipalvelin” myös reagoi.

• DocumentRoot viittaa tiedostojärjestelmän polkuun, jossa “virtuaalipalvelimen” sisältö sijaitsee.

Seuraavaksi tein testisivun “virtuaalipalvelimelle” komennolla:

$sudo nano ~/public_html/eliimatt.com/index.html

Tiedosto sisällön pohjana käytettiin Tero Karvisen lyhyttä HTML5 testisivua:

<!doctype html>
<html>
<head>
	<title>www.eliimatt.com</title>
	<meta charset="utf-8" />
</head>
<body>
	<h1>www.eliimatt.com</h1>
	<p>Terve, maailma! Tämä on Apachen nimipohjainen "virtuaalipalvelin"</p>
</body>
</html>

Tämän jälkeen otin käyttöön uuden “virtuaalipalvelimen” komennolla:

$sudo a2ensite eliimatt.com

Käynnistin Apache palvelimen uudelleen komennolla:

$sudo service apache2 reload

Testasin “virtuaalipalvelimen” toimivuutta Firefox selaimessa avaamalla osoitteen “www.eliimatt.com” sekä “eliimatt.com”:


Testi osoitti, että “virtuaalipalvelin” toimii molemmilla nimillään.

PHP:n asentaminen Apache palvelinta varten

Asensin PHP:n komennolla:

$sudo apt-get install libapache2-mod-php5

Seuraavaksi muutin Apachen PHP lisäosan asetuksia niin, että PHP:tä voidaan ajaa käyttäjäkohtaisesta public_html kansiosta:

$sudo nano /etc/apache2/mods-enabled/php5.conf

Asetustiedostosta kommentoitiin ulos seuraavat rivit lisäämällä rivien alkuun ristikkomerkki #:

<IfModule mod_userdir.c>
      <Directory /home/*/public_html>
           php_admin_value engine Off
      </Directory>
</IfModule>

Käynnistin Apache palvelimen uudelleen komennolla:

$sudo service apache2 reload

Testakseni PHP:n toimivuutta, tein kotihakemistoni public_html kansioon index.php tiedoston komennolla:

$nano ~/public_html/index.php

Tiedoston sisällöksi tuli:

<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=UTF-8">
<?php
print_r('<h1>Terve maailma</h1>');
print_r('<p>Käyttämäsi selaimen tiedot:</p>');
echo $_SERVER['HTTP_USER_AGENT'] . "\n\n";
?>

Seuraavaksi avasin Firefox selaimessa osoitteen “localhost/~eino”:

Testi osoitti, että PHP sivut toimivat käyttäjäkohtaisessa public_html kansiossa.

Virtuaalipalvelinten lisääminen Apachen käyttöön

Harjoitustehtävää jatkettiin ottamalla käyttöön lisää Apachen virtuaalipalvelimia. Tehtävänä oli määrittää virtuaalipalvelin,jossa voitiin suorittaa PHP koodia sekä toinen, jossa se oli kiellettyä. Palautin aikaisemmin tekemäni Apachen PHP lisäosaan tekemäni asetuksen, joka salli käyttäjäkohtaisessa public_html kansiossa ajettavan PHP koodin. Tein kaksi uutta virtuaalipalvelinta tätä tarkoitusta varten samalla tavoin kuin ensimmäisenkin. Lisäsin molempien virtuaalipalvelimien asetustiedostoihin <Directory> lohkon, jossa määriteltiin PHP kieltäminen tai salliminen asetusdirektiivillä php_admin_value engine Off/1(On):

1. Virtuaalipalvelin nonphp.com – PHP koodin suoritus kielletty

Sisältökansion luominen:

$mkdir ~/public_html/nonphp.com

Nimitiedot /etc/hosts tiedostossa:

192.168.xxx.xxx www.nonphp.com
192.168.xxx.xxx nonphp.com

/etc/apache2/sites-available/nonphp.com tiedoston sisältö:

 <VirtualHost *:80> 
    ServerName www.nonphp.com 
    ServerAlias nonphp.com 
    DocumentRoot /home/eino/public_html/nonphp.com 
        <Directory /home/eino/public_html/nonphp.com>
            php_admin_value engine Off
        &lt/Directory>

</VirtualHost>

Käyttöön ottaminen komennolla:

$sudo a2ensite nonphp.com
2. Virtuaalipalvelin phpsite.com – PHP koodin suoritus sallittu

Sisältökansion luominen:

$mkdir ~/public_html/phpsite.com

Nimitiedot /etc/hosts tiedostossa:

192.168.xxx.xxx www.phpsite.com
192.168.xxx.xxx phpsite.com

/etc/apache2/sites-available/phpsite.com tiedoston sisältö:

 <VirtualHost *:80> 
    ServerName www.phpsite.com 
    ServerAlias phpsite.com 
   DocumentRoot /home/eino/public_html/phpsite.com 
        <Directory /home/eino/public_html/phpsite.com>
            php_admin_value engine 1
        &lt/Directory>
</VirtualHost>

Käyttöön ottaminen komennolla

$sudo a2ensite phpsite.com

Kopioin molempiin virtuaalipalvelinten sisältökansioihin aikaisemmin tekemäni index.php tiedoston komennoilla:

$cp ~/index.php ~/nonphp.com/
$cp ~/index.php ~/phpsite.com/

Käynnistin Apache palvelimen uudelleen komennolla:

$sudo service apache2 reload

Testasin virtuaalipalvelinten PHP asetuksia Firefox selaimessa avaamalla osoitteen “www.nonphp.com” sekä “www.phpsite.com”:

Testi osoitti, että virtuaalipalvelimille määritellyt PHP asetukset toimivat kuten oli suunniteltu.

Hakemistolistauksen kieltäminen virtuaalipalvelimessa

Tein kolmannen Apache virtuaalipalvelimen, jossa estettiin automaattisen hakemistolistauksen näyttäminen kun index.html tiedostoa ei löydy. Automaattinen hakemistolistaus estetetään asetusdirektiivillä Options -Indexes.

3. Virtuaalipalvelin noindex.com – automaattinen hakemistolistaus estetty

Sisältökansion luominen:

$mkdir ~/public_html/noindex.com

Nimitiedot /etc/hosts tiedostossa:

192.168.xxx.xxx www.noindex.com
192.168.xxx.xxx noindex.com

/etc/apache2/sites-available/noindex.com tiedoston sisältö:

 <VirtualHost *:80> 
    ServerName www.noindex.com 
    ServerAlias noindex.com 
   DocumentRoot /home/eino/public_html/noindex.com 
        <Directory /home/eino/public_html/noindex.com>
            Options -Indexes
        </Directory>
</VirtualHost>

Käyttöön ottaminen komennolla

$sudo a2ensite noindex.com

Käynnistin Apache palvelimen uudelleen komennolla:

$sudo service apache2 reload

En tehnyt virtuaalipalvelimen sisältökansioon mitään tiedostoja. Testasin virtuaalipalvelinta avaamalla Firefox selaimessa osoitteen “www.noindex.com”:

Testi osoitti, että virtuaalipalvelimen asetukset estivät automaattisen hakemistolistauksen tekemisen.

HTTP statukset lokitiedostossa

HTTP Status 200 – OK

• Avasin Firefox selaimella osoitteen “www.eliimatt.com”. Sivu latautui normaalisti:


Lokitiedosto /var/log/apache2/other_vhosts_access.log sisältää merkinnän:

eliimatt.com:80 192.168.100.102 - - [24/Sep/2012:00:07:38 +0300] "GET / HTTP/1.1" 200 517 "-" "Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:15.0) Gecko/20100101 Firefox/15.0.1"

Osoite eliimatt.com viittaa virtuaalipalvelimen nimeen. GET / viittaa HTTP pyyntöön, jolla pyydetään juuridokumenttia kun erillistä sivua ei ole määritelty selaimen osoiterivillä. 200 viittaa HTTP statukseen, joka kertoo että sivupyyntöön on vastattu onnistuneesti. Loppuosassa näkyvät selaimen tiedot.

HTTP Status 404 – Not Found

• Avasin Firefox selaimella osoitteen “www.eliimatt.com/omasivu”. Selain ilmoitti, että sivua ei löydy:


Lokitiedosto /var/log/apache2/other_vhosts_access.log sisältää merkinnän::

eliimatt.com:80 192.168.100.102 - - [24/Sep/2012:00:23:45 +0300] "GET /omasivu HTTP/1.1" 404 503 "-" "Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:15.0) Gecko/20100101 Firefox/15.0.1"

Osoite eliimatt.com viittaa virtuaalipalvelimen nimeen. GET /omasivu viittaa HTTP pyyntöön, jolla pyydetään omasivu nimistä dokumenttia. 404 viittaa HTTP statukseen, joka kertoo että sivua ei löydy. Loppuosassa näkyvät selaimen tiedot.

HTTP Status 403 – Forbidden

• Avasin Firefox selaimella osoitteen “www.noindex.com”. Selain ilmoitti, että oikeudet sivun avaamiseen puuttuvat:


Lokitiedosto /var/log/apache2/other_vhosts_access.log sisältää merkinnän::

www.noindex.com:80 192.168.100.102 - - [24/Sep/2012:00:37:59 +0300] "GET / HTTP/1.1" 403 499 "-" "Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:15.0) Gecko/20100101 Firefox/15.0.1"

Osoite eliimatt.com viittaa virtuaalipalvelimen nimeen. GET / viittaa HTTP pyyntöön, jolla pyydetään juuridokumenttia kun erillistä sivua ei ole määritelty selaimen osoiterivillä.. 403 viittaa HTTP statukseen, joka kertoo että oikeudet sivun avaamiseen puuttuvat. Loppuosassa näkyvät selaimen tiedot.

HTTP Status 500 – Internal Server Error

• Tein “huonoa” koodia sisältävän PHP tiedoston badcode.php, jonka sisältö oli:

<?php echo !"#%; ?>

Kopioin tiedoston kotihakemistoni ~/public_html/phpsite.com kansioon. Avasin Firefox selaimella osoitteen “www.phpsite.com/badcode.php”. Selain näytti vain tyhjää ikkunaa:


Lokitiedosto /var/log/apache2/other_vhosts_access.log sisältää merkinnän::

phpsite.com:80 192.168.100.102 - - [24/Sep/2012:01:08:14 +0300] "GET /badcode.php HTTP/1.1" 500 275 "-" "Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:15.0) Gecko/20100101 Firefox/15.0.1"

Osoite eliimatt.com viittaa virtuaalipalvelimen nimeen. GET /badcode.php viittaa HTTP pyyntöön, jolla pyydetään badcode.php nimistää dokumenttia. 500 viittaa HTTP statukseen, joka kertoo että sivun lataamisessa sattui serverin sisäinen virhe. Loppuosassa näkyvät selaimen tiedot.

Lähteet

The Apache Software Foundation 2012. Apache HTTP Server Version 2.4 Documentation.
http://httpd.apache.org/docs/2.4/

Cohen, James 2011. How to Avoid Character Encoding Problems in PHP.
http://webmonkeyuk.wordpress.com/2011/04/23/how-to-avoid-character-encoding-problems-in-php/

Edwards, Christer 2008. Setting Up Name Based Virtual Hosting.
http://ubuntu-tutorials.com/2008/01/09/setting-up-name-based-virtual-hosting/

Emphatic Nonsense 2011. Enabling Apache’s PHP execution in User Directories on Ubuntu Lucid.
http://emphaticnonsense.com/2011/10/06/enabling-apache-php-execution-in-user-directories-on-ubuntu-lucid/

Karvinen, Tero 2012a. Short HTML5 page.
http://terokarvinen.com/2012/short-html5-page

Karvinen, Tero 2012b. Linux palvelimena ICT4TN003-4 kurssin kotisivu.
http://terokarvinen.com/2012/aikataulu-linux-palvelimena-ict4tn003-4-ja-ict4tn003-6-syksylla-2012

PHP Manual 2012. Runtime Configuration.
http://php.net/manual/en/apache.configuration.php#ini.engine

Stackoverflow 2012. How to trigger 500 Internal Server Error in PHP?
http://stackoverflow.com/questions/8687390/how-to-trigger-500-internal-server-error-in-php

Ubuntu Community Help Wiki 2012. ApacheMySQLPHP.
https://help.ubuntu.com/community/ApacheMySQLPHP

About

Tätä dokumenttia saa kopioida ja muokata GNU General Public License (versio 2 tai uudempi) mukaisesti.
http://www.gnu.org/licenses/gpl.html
Pohjana Tero Karvisen Linux-kurssi, www.iki.fi/karvinen

Avainsanat:, , , , ,
Kategoria(t): ICT4TN003-4 Linux palvelimena | 5 Kommenttia »

Harjoitustehtävä 4: Paketinhallintaa

19.9.2012

Harjoitustehtävän aiheena oli metapakettien tekeminen ja oman pakettivaraston (repository) luominen. Harjoituksessa tehtiin yksi DEB metapaketti, johon koottiin tarpeellisia Ubuntun ohjelmapaketteja. Oma metapaketti julkaistiin sitten omassa pakettivarastossa.

Harjoitusympäristö

Harjoitus suoritettiin 19.09.2012 opiskelijan kotona käyttäen henkilökohtaista tietokonetta. Internet-yhteytenä oli Elisa Oyj:n tarjoama VDSL tyyppinen 100/10 mbit kiinteä laajakaistayhteys. Harjoituksessa käytettiin Lenovo R60 kannettavaa tietokonetta, johon oli asennettu Xubuntu versio 12.04 32-bittinen Linux käyttöjärjestelmä.

Lenovo R60 kokoonpano:

  • Suoritin: Intel Core 2 Duo T56000 @1.83 Ghz
  • Keskusmuisti: 4 Gt DDR2
  • Kiintolevy: 100 Gt SATA150 54000rpm
  • Käyttöjärjestelmä: Xubuntu versio 12.04 32-bittinen

Metapaketin tekeminen

Harjoituksen tekeminen aloitettiin asentamalla pakettityökalu equivs. Aloitin asennuksen päivittämällä Ubuntun pakettivarastot komennolla:

$sudo apt-get update

Pakettivarastojen päivitys kesti muutamia sekunteja.

Asensin equivs ohjelman komennolla:

$sudo apt-get install equivs

Asennus kesti parikymmentä sekuntia.

Siirryin omaan kotihakemistooni ja tein metapaketti nimisen kansion työskentelyä varten:

$cd
$mkdir metapaketti
$cd metapaketti

Seuraavaksi tein metapaketin asetustiedoston pohjan equivs-control komennolla:

$equivs-control eliimatt-metapaketti.cfg

Siirryin editoimaan metapaketin asetustiedostoa nano editorilla:

$nano eliimatt-metapaketti.cfg

Lisäsin Package, Version, Depends ja Description kenttiin paketin luomiseen tarvittavat tiedot ja poistin
kommentinmerkin # näiden rivien alusta. Package kenttään tuli paketin nimi; Version kenttään versionumero; Depends kenttään metapaketissa asennettavat paketit ja Description kenttään kuvaus paketin sisällöstä. Valitsin tähän metapakettiin asennettaviksi ohjelmiksi graafisen diff työkalun meld, tekstieditorin geany sekä linja-analysaattorin wireshark. Tutkin asetustiedoston sisältöä grep komennon avulla, jolla sain
suodatettua pois kaikki kommenttirivit:

$grep -v '^#' eliimatt-meta.cfg

Paketin asetustiedoston sisältö oli seuraava:

Section: misc
Priority: optional
Standards-Version: 3.9.2

Package: eliimatt-metapaketti
Version: 0.1
Depends: meld,geany,wireshark
Description: eliimatt's basic tools 
 long description and info
 .
 second paragraph

Tein metapaketin komennolla:

$equivs-build eliimatt-metapaketti.cfg

Lopputuloksena sain  eliimatt-metapaketti_0.1_all.deb paketin.

Seuraavaksi asensin gdebi ja lintian työkalut paketin testaamista varten:

$sudo apt-get install gdebi lintian

Testasin ensiksi paketin oikeellisuutta lintian työkalulla komennolla:

$lintian eliimatt-metapaketti_0.1_all.deb

Lintian ilmoitti, että paketin ylläpitäjän sähköpostiosoite ei ole validi:

Muutin nano editorilla asetustiedoston Maintainer kenttään nimen sekä oikean sähköpostiosoitteen ja päivitin
Version kenttään 0.2 uudeksi versionumeroksi. Tein uuden version paketista equivs-build komennolla
ja testasin uutta pakettia lintian komennolla:

$nano eliimatt-metapaketti.cfg
$equivs-build eliimatt-metapaketti.cfg
$lintian eliimatt-metapaketti_0.2_all.deb

Tällä kertaa lintian tarkistus meni läpi ilman huomatuksia. Seruraavaksi kokeilin asentaa metapaketin gdebi komennolla:

$gdebi eliimatt-metapaketti_0.2_all.deb

Asennus onnistui ja ohjelmat ilmestyivät käynnistysvalikkoon. Käynnistin sieltä wireshark ohjelman ja totesin sen latautuvan:

Metapaketin digitaalinen allekirjoittaminen

Seuraavaksi päätin tehdä metapaketilleni digitaalisen allekirjoituksen. Aloitin tekemällä itselleni julkisen ja yksityisen avaimen parin gpg työkalulla:

$gpg --gen-key

Valitsin avaimen tyypiksi RSA and RSA, avaimen pituudeksi 2048 bittiä ja avaimen voimassaoloajaksi 10 vuotta.
Annoin avainparin nimeksi ja sähköpostiosoitteeksi samat kuin paketin asetustiedostossa. Komenttirivin jätin tyhjäksi.

Seuraavaksi muutin paketin asetustiedostosta versionumeroksi 0.3 ja tein uuden paketin käyttäen equivs-build työkalun
full asetusta (-f):

$nano eliimatt-metapaketti.cfg
$equivs-build -f eliimatt-metapaketti.cfg

Testasin vielä uutta versiota lintian työkalulla ja asensin sen gdebi työkalulla:

$lintian eliimatt-metapaketti_0.3_all.deb
$gdebi eliimatt-metapaketti_0.3_all.deb

Pakettivaraston tekeminen

Aloitin pakettivaraston tekemisen asentamalla reprepro työkalun.

$sudo apt-get install reprepro

Pakettivarasto tehtiin oman käyttäjätunnukseni public_html hakemistoon. Olin jo aikaisemin asentanut Apache palvelimen ja ottanut käyttöön käyttäjäkohtaiset public_html hakemistot, joten aloitin tekemällä kansion pakettivarastolle:

$cd
$cd public_html
$mkdir -p metapaketit/conf

Seuraavaksi tein pakettivaraston asetustiedoston komennolla:

$nano repository/conf/distributions

Tiedoston sisällöksi tuli:

Codename: precise
Components: main
Suite: precise
Architectures: i386 amd64 source

Sana precise viittaa Ubuntu versioon 12.04 Precise Pangolin. Seuravaksi tein DEB paketeille oman kansion ja kopioin oman  metapakettini sinne:

$mkdir eliimatt-meta
$cp ../metapaketti/eliimatt-metapaketti_0.3_all.deb eliimatt-meta/

Lisäsin metapaketin pakettivarastoon komennolla:

$reprepro -VVVV -b metapaketit/ includedeb precise eliimatt-meta/eliimatt-*.deb

Pakettivaraston käyttöönotto

Testasin pakettivaraston toimivuutta lisäämällä oman pakettivarastoni APT:n pakettilähteeksi komennolla:

$sudoedit /etc/apt/sources.list.d/repository.list

Asetustiedostoon lisättiin rivi:

deb http://192.168.xxx.xxx/~xxx/metapaketit precise main

HTTP-osoite viittaa tietokoneen omaan IP-osoitteeseen ja käyttäjätunnukseeni, jonka julkisessa public_html kansiossa pakettivarasto sijaitsee. Seuraavaksi päivitin pakettivarastot komennolla:

$sudo apt-get update

Lopuksi kokeilin asentaa oman metapakettini apt-get komennolla:

$sudo apt-get install eliimatt-metapaketti

Asennus onnistui ja totesin pakettivarastoni toimivan.

Käytetyt ohjelmistot

Geany http://www.geany.org/
Meld  http://meldmerge.org/
Wireshark http://www.wireshark.org/

Lähteet

DebianSick 2011. Creating metapackages with equivs.
http://www.debian-administration.org/users/DebianSick/weblog/1

Cowie, Jon 2011. Creating your own Signed APT Repository and Debian Packages
http://blog.mycrot.ch/2011/04/26/creating-your-own-signed-apt-repository-and-debian-packages/

Karvinen, Tero 2011a. Create deb metapackage in 5 minutes.
http://terokarvinen.com/2011/create-deb-metapackage-in-5-minutes

Karvinen, Tero 2011b. Update All Your Computers with a .DEB Repository.
http://terokarvinen.com/2011/update-all-your-computers-with-a-deb-repository

Karvinen, Tero 2012. Linux palvelimena ICT4TN003-4 kurssin kotisivu.
http://terokarvinen.com/2012/aikataulu-linux-palvelimena-ict4tn003-4-ja-ict4tn003-6-syksylla-2012

PurpleFloyd 2009. Signing .deb packages.
http://purplefloyd.wordpress.com/2009/02/05/signing-deb-packages/

About

Tätä dokumenttia saa kopioida ja muokata GNU General Public License (versio 2 tai uudempi) mukaisesti.
http://www.gnu.org/licenses/gpl.html
Pohjana Tero Karvisen Linux-kurssi, www.iki.fi/karvinen

Avainsanat:, , , ,
Kategoria(t): ICT4TN003-4 Linux palvelimena | Jätä kommentti »

Harjoitustehtävä 3: Rosvoja ja kunnon kansalaisia

10.9.2012

Harjoitustehtävän aiheena oli tutkia rootkit-tyyppisen haittaohjelman saastuttamaa Linux-levykuvaa. Harjoitus tehtiin käyttäen netistä vapaasti saatavaa Honeynet Project: Scan Of Month 15 tehtävää ja siinä annettua levykuvaa.  Tehtävässä kuvattiin levykuvan sisältämä poistetun rootkit ohjelman palautustoimenpiteet  ja analysoitiin siihen kuuluvia tiedostoja.

Harjoitusympäristö

Harjoitus suoritettiin 09.09.2012 opiskelijan kotona käyttäen henkilökohtaista tietokonetta. Internet-yhteytenä oli Elisa Oyj:n tarjoama VDSL tyyppinen 100/10 mbit kiinteä laajakaistayhteys. Harjoituksessa käytettiin Lenovo R60 kannettavaa tietokonetta, johon oli asennettu Xubuntu versio 12.04 32-bittinen Linux käyttöjärjestelmä.

Lenovo R60 kokoonpano:

  • Suoritin: Intel Core 2 Duo T56000 @1.83 Ghz
  • Keskusmuisti: 4 Gt DDR2
  • Kiintolevy: 100 Gt SATA150 54000rpm
  • Käyttöjärjestelmä: Xubuntu versio 12.04 32-bittinen

Levykuvan lataaminen ja Autopsy ohjelman asentaminen

Harjoituksen tekeminen aloitettiin lataamalla tutkittava levykuva honeynet.tar.gz Honeynet Project:n sivulta. Levykuva purettiin omaan Documents kansioon käyttäen XFCE:n graafisia työkaluja Thunaria ja Archive Manageria. Lopptulokseksi saatiin honeynet kansio, joka sisälsi dd ohjelmalla tehdyn levykuvan saastuneen järjestelmän / eli  juuri tiedostojärjestelmästä. Levykuvan analysointia varten asennettiin Autopsy Forensic Browser, joka toimii graafisena käyttöliittymänä digitaalisen rikostutkinnan Sleuth Kit työkalulle. Aloitin asennuksen päivittämällä Ubuntun pakettivarastot komennolla:

$sudo apt-get update

Pakettivarastojen päivitys kesti muutamia sekunteja.

Asensin Autopsy ohjelman komennolla:

$sudo apt-get install autopsy

Asennus kesti parikymmentä sekuntia.

Autopsy ohjelman käynnistäminen

Käynnistin Autopsy  ohjelman komennolla:

$sudo autopsy

Autopsy käynnistyi ja kehotti avaamaan käyttöliittymän selaimella:

Avasin Firefox selaimen ja ensiksi otin turvallisuussyistä JavaScript tuen pois käytöstä selaimen asetuksista:

Seuraavaksi siirryin Autopsyn käyttöliittymään kirjoittamalla selaimeen osoitteen http://localhost:9999/autopsy

Levykuvan avaaminen

Aloitin levykuvan avaamisen valitsemalla linkin Open Case. Seuraavasta ikkunasta valitsin linkin New Case. Syötin seuraavan ikkunaan tapauksen nimeksi SOTM_15:

Seuraavassa ikkunassa lisäsin tutkittavan tapauksen isäntäkone valitsemalla linkin Add Host. Seuraavassa ikkunassa jätin oletusarvon isäntäkoneen nimelle host1 ja muihin kenttiin:

Seuraavassa ikkunassa lisäsin tutkittavan levykuvan valitsemalla linkin Add Image File:

Seuraavassa ikkunassa määritin kenttään Location levykuvan polun tiedostojärjestelmässä. Levykuvan tyypiksi annoin Partition ja levykuvan importointimenetelmäksi Copy:

Seuraavassa ikkunassa jätin oletusasetukset päälle ja valitsin linkin Add. Levykuvan lataaminen Autopsy ohjelmaan kesti muutamia sekunteja ja valitsin seuraavassa ikkunassa linkin Ok.

Levykuvan analysointi

Scan Of Month 15 tehtävän lähtötiedoissa kerrottiin, että levykuvassa olevan järjestelmään ladattiin rootkit-ohjelma 15. maaliskuuta 2001, joka sen jälkeen poistettiin (delete) järjestelmästä. Annettua päivämäärä voidaan hyödyntää rootkitin tiedostoja etsittäessä. Analyysin taustaoletuksena on että rootkitin tiedostoja löytyy nimenomaan poistettujen, mutta vielä palautettavissa olevien tiedostojen joukosta ja niiden päivämäärätiedot viittaavat 15. maaliskuuta 2001 (+/- 1 päivää aivavyöhykkeiden erot huomioon otettaessa).

Aloitin levykuvan tutkimisen tarkastelemalle yleisesti levykuvan hakemistorakennetta ja tiedostoja. Avatun levykuvan valintaikkunassa valitsin linkin Analyze:

Valitsin seuraavasta ikkunasta linkin File Analysis, jolla pääsin tutkimaan levykuvan hakemistorakennetta. Juurihakemistosta paljastuu heti kaksi poistettua epäilyttävää tiedostoa: kansio last ja TGZ muotoinen  last.tgz pakettitiedosto. Tiedostoissa on epäilyttävää niiden poikkeava sijainti tiedostojärjestelmässä, joka ei ole Linuxissa yleisesti käytetyn FHS standardin mukainen. Epäilyksiä lisää myös, että tiedostot ovat poistettuja. Koska tiedostojen varaama tilaa ei ole allokoitu uudestaan (kirkas punainen väri), ne voidaan palauttaa tarkempaa tutkimusta varten:

Ennakkotiedoissa kerrottiin, että rootkit-ohjelma on poistettu järjestelmästä. Edellä kuvattujen tiedostojen oletetaan kuuluvan rootkitin tiedostoihin. Levykuvan tiedostolistauksessa näkyy kansio nimeltä $OrphanFiles. Se on Autopsyn taustalla toimivan Sleuth Kit ohjelmiston muodostama virtuaalinen kansio, joka sisältää osittainen poistetut, “orvot” tiedostot, joilla ei ole enää hakemistopolkua ja nimeä. “Orpojen” tiedostojen varsinainen data on kuitenkin vielä tallessa, mikäli kyseisiä tiedostojärjestelmän lohkoja ei ole varattu uuteen käyttöön. Tälläisiä tiedostoja voi jäädä levylle kun ohjelmat “kaatuvat” tai kun tiedosto poistetaan, mutta se on vielä avattuna jollakin prosessilla. Tarkistin $OrphanFiles kansion sisällön ja havaitsin sen sisältävän useita tiedostoja, joiden päivämäärissä näkyy 15. tai 16. maaliskuuta 2001. Näiden voidaan olettaa sisältävän rootkitin tiedostoja:

$OrphanFiles kansion analysointi

Kävin läpi kaikki $OrphanFiles kansion tiedostot ja tutkin niiden sisältöä, jonka saa näkyviin valitsemalla tiedoston nimen edellä kuvatussa ikkunassa. Käytin binääritiedostojen kohdalla ASCII Strings valintaa, joka tulostaa binääritiedoston sisältämät merkkijonot. Tein seuraavia huomioita tiedostoista, jotka ovat nimetty on EXT tiedostojärjestelmän metadatan mukaisilla inode numeroilla.

Inodeen viittava tiedostonimi Lyhyt analyysi tiedostosta
/1/$OrphanFiles/OrphanFile-16110 /etc/pam.d/passwd asetustiedosto, joka määrittää PAM autentikointijärjestelmässä tapahtuvaa salasanojen tarkistusta
/1/$OrphanFiles/OrphanFile-2039 ajettava binääriohjelma, rsh komento, jolla voidaan ajaa shell komentoja toisena käyttäjänä tai verkon yli toisella koneella, kuuluu luultavasti rootkitin tiedostoihin
/1/$OrphanFiles/OrphanFile-2040 1 tavun mittainen binääritiedosto, joka sisältö heksakoodina on 0x0A
/1/$OrphanFiles/OrphanFile-2041 oletettu rootkin asennukseen käytetty omatekoinen shell skripti, erittäin epäilyttävä
/1/$OrphanFiles/OrphanFile-2042 ajettava binääriohjelma, joka sisältää ainoastaan linkkauksen järjestelmäkirjastoon /lib/ld-linux.so.1, mahdollisesti haittaohjelma
/1/$OrphanFiles/OrphanFile-2043 järjestelmän lokeja hävittävä omatekoinen shell skripti, jonka komenttirivillä käytetään nimeä “sauber”, vaikuttaa epäilyttävältä
/1/$OrphanFiles/OrphanFile-2044 /etc/inetd.conf asetustiedosto, inetd (Internet service daemon) on Internet-palvelujen hallintaan käytetty taustaprosessi, jota käyttävät esim. telnet ja ftp palvelut, kuuluu luultavasti rootkitin tiedostoihin
/1/$OrphanFiles/OrphanFile-2044 omatekoinen lyhyt shell skripti, joka käyttää linsniffer nimistä ohjelmaa, luultavasti kuuluu rootkitin tiedostoihin
/1/$OrphanFiles/OrphanFile-2046 /etc/services asetustiedosto, jota inetd käyttää yhdistämään Internet-palveluiden porttinumerot ja protokollat palvelunimiin, luultavasti kuuluu rootkitin tiedostoihin
/1/$OrphanFiles/OrphanFile-2047 PERL kielinen skripti, jonka kommenttirivillä on kuvaus # Sorts the output from LinSniffer 0.03 [BETA] by Mike Edulla <medulla@infosoc.com>
/1/$OrphanFiles/OrphanFile-2048 SSH:n ssh_config asetustiedosto, joka sisältää SSH asiakkaan järjestelmänlaajuiset asetukset, kuuluu luultavasti rootkitin tiedostoihin
/1/$OrphanFiles/OrphanFile-2049 SSH RSA1 tyyppinen yksityinen avain, email osoite root@dil2.datainfosys.net
/1/$OrphanFiles/OrphanFile-2050 SSH known_hosts tyyppinen yhden julkisen avaimen sisältävä tiedosto, avaimen email osoite root@dil2.datainfosys.net
/1/$OrphanFiles/OrphanFile-2051 lyhyt binääritiedosto, oletettavasti SSH kryptografisiin funktioihin käyttämä random_seed tiedosto
/1/$OrphanFiles/OrphanFile-2052 SSH:n sshd_config asetustiedosto, joka sisältää SSH palvelimen järjestelmänlaajuiset asetukset, kuuluu luultavasti rootkitin tiedostoihin
/1/$OrphanFiles/OrphanFile-2053 ajettava binääriohjelma, ASCII Strings työkalulla tutkittuna oletetaan palvelunesto (DoS) hyökkäykseen käytettäväksi haittaohjelmaksi, kuuluu luultavasti rootkitin tiedostoihin
/1/$OrphanFiles/OrphanFile-2054 ajettava binääriohjelma, jonka sisällä HTML-koodia sisältäviä merkkijonoja, oletetaan HTML-koodin perusteella CGI:tä käyttäväksi backdoor haittaohjelmaksi, kuuluu luultavasti rootkitin tiedostoihin
/1/$OrphanFiles/OrphanFile-2058 ajettava binääriohjelma, prosessienhallintaan käytetty top komento, kuuluu luultavasti rootkitin tiedostoihin
/1/$OrphanFiles/OrphanFile-2059 omatekoinen shell komentoja sisältä tekstitiedosto, käyttää linsniffer ohjelmaa, kuuluu luultavasti rootkitin tiedostoihin
/1/$OrphanFiles/OrphanFile-2060 SSH:n sshd_config asetustiedosto,joka sisältää SSH palvelimen järjestelmänlaajuiset asetukset, kuuluu luultavasti rootkitin tiedostoihin
/1/$OrphanFiles/OrphanFile-2061 ajettava binääriohjelma, sshd palvelin, kuuluu luultavasti rootkitin tiedostoihin
/1/$OrphanFiles/OrphanFile-30188 ajettava binääriohjelma, netstat komento, jota käytetetään verkkoyhteyksien diagnosoimiseen, kuuluu luultavasti rootkitin tiedostoihin
/1/$OrphanFiles/OrphanFile-30191 ajettava binääriohjelma, ps komento, jolla listataan prosesseja, kuuluu luultavasti rootkitin tiedostoihin
/1/$OrphanFiles/OrphanFile-48284 ajettava binääriohjelma, ifconfig komento, jota käytetään verkkoadapterien konfiguroimiseen, kuuluu luultavasti rootkitin tiedostoihin
/1/$OrphanFiles/OrphanFile-56231 binääritiedosto, joka sisältää 0×0 arvoisia tavuja
/1/$OrphanFiles/OrphanFile-8100 tekstitiedosto, joka sisältää shell komentojen nimiä ja lyhyitä kuvauksia, oletetaan liittyvän komentotulkkiin (bash)

$OrphanFiles kansion analysoinnissa löydettiin todennäköinen rootkitin asentava shell skripti (inode 2041); rootkitin käyttämiä väärennettyjä versioita järjestelmäkomennoista (inodet 2039,30188,30191,48284) sekä väärennettyjä versioita asetustiedostoista(inodet 2044,2046); rootkitin todennäköisesti asentama SSH palvelin ja siihen liittyviä asetustiedostoja (inodet 2048-2052, 2060,2061 ); palvelunesto hyökkäykseen käytettävä haittaohjelma (inode 2053).

/etc kansion analysointi

Kansiosta /etc löytyi epäilyttävä poistettu tiedosto mtab~, jonka sisältö ei ollut normaalin mtab tiedoston mukainen. Kyseisen tiedoston pitäisi sisältää tiedot järjestelmään mountatuista tiedostojärjestelmistä:

Tiedoston sisältöö viittaa rootkitin asentamiin haittaohjelmiin, joita on tarkoitus piilottaa. Lisää epäilyttäviä tiedostoja löytyy init taustaprosessin asetustiedostoista /1/etc/rc.d/ kansion alta. Runlevel 3 asetustiedostoista löytyy poistettu tiedosto /1/etc/rc.d/rc3.d/K83ypbind, jonka sisältö ei näytä oikealta init skriptiltä:

Sisältö viittaa $OrphanFiles kansiosta löytyneeseen PAM asetustiedostoon (inode 16110). Saman niminen poistettu löytyy myös toisesta kansiosta /1/etc/rc.d/rc0.d/K83ypbind. Sisältö on erilainen verrattuna toiseen samannimiseen ja tämäkään ei vaikuta tavalliselta:

Tutkittaessa kaikkien init taustaprosessin run level kansioita (/etc/rc.d/rc0.d … rc6.d) havaitaan että K83ypbind tiedosto on löytyy poistettuna jokaisesta kuudesta kansiosta. Tiedoston nimi viittaa ypbind taustaprosessiin, joka liittää palvelimen NIS hakemistopalvelun toimialueeseen. NIS on vanhentunut hakemistopalveluprotokolla, jonka LDAP/Active Directory on korvannut. Poistettujen tiedostojen epäillään liittyvän rootkitin toimintaan. Lisäksi /etc/rc.d/rc.sysinit tiedostossa havaitaan epäilyttävä rivi tiedoston lopussa:

/usr/bin/lsattr -t1 -X53 -p

Komennon tarkoitus ei käy selville eikä sitä ole kommentoitu mitenkään.

/dev kansion analysointi

Kansiosta /dev löytyi epäilyttävä hakemisto /dev/ida, jota epäillään heti rootkin luomaksi kansioksi. Sen sisältää löytyy epäilyttävä /dev/ida/.drag-on kansio ja /dev/ida/”..”  kansio, joita rootkit käyttää piilottamaan omia tiedostojaan. Hämäävästi nimetty “..” kansio sisältää rootkitin tiedostoja, joita löytyi myös $OrphanFiles kansiosta:

Tiedostojen havaitaan sisältävän Ethernet-liikennettä nuuskiva linsniffer työkalu, piilotetty sshd palvelin (tiedosto mkxfs), skripti logien tyhjentämiseen (tiedosto logclear) ja haittaohjelma palvelinestohyökkäyksien toteuttamiseen (tiedosto sl2). Kansio /dev/ida/.drag-on sisältää samat tiedostot kuin edellä mainittu kansio. Tarkoituksena lienee hämätä palvelimen ylläpitäjää ja vaikeuttaa rootkitin poistamista.

Epäilyttävästä tiedosto /dev/last löytyy rootkitin tekijän käyttämiä IP-osoitteita ja TCP-protokollien portteja. Tiedoston sisältämien IP-osoitteet sijaitsevat Ubuntun geoiplookup työkalun mukaan Romaniassa, Azerbaidžanissa ja Tanskassa. Porttien numeroita ovat 48744, 3666, 31221, 22546 ja 2222. Tiedostonimien perusteella oletan, että rootkitin tekijä käyttää itsestään pseudonyymiä last.

Epäilyttävästä tiedostosta /dev/rpm löytyy viittauksia rootkitin käyttämiin haittaohjelmiin, joita on tarkoitus piilottaa. Tiedostolla on samanlainen sisältö kuin edellä mainitulla tiedostolla /etc/mtab~.

Keyword Search haku levykuvasta

Käytin Autopsyn tarjoamaa Keyword Search toimintoa, jolla hain hakusanalla “last” suoraan levykuvan sisällöstä. Tiedostojärjestelmän fragmentista 90417 löytyi rootkitin tekijälleen lähettämä sähköpostiviesti, johon oli kerätty tietoja kaapatusta koneesta:

Rootkitin asennuspakettti last.tgz

Käytin Autopsyn Export toimintoa, jolla pystyin palauttamaan levykuvan juurihakemistosta poistetetun tiedoston last.tgz. Tarkastelemalla pakettia Xubuntun Archive Manager työkalulla, havaitsin sen sisältävän kaikki rootkitin käyttämät tiedostot:

Yleisesti ottaen totean levykuvan sisältämän rootkitin toiminnaltaan ja tiedostorakenteeltaan vastaavan Anton Chuvakinin analyysiä (Chuvakin 2003) ensimmäisen sukupolven binääri rootkitista. Levykuvan sisältämä rootkit on Chuvakisin esittelemän rootkitin variantti tai suora kopio.

Käytetyt ohjelmistot

Autopsy Forensic Browser  http://www.sleuthkit.org/autopsy/desc3.php

Lähteet

Chuvakin, Anton 2003. An Overview of Unix Rootkits.
http://www.rootsecure.net/content/downloads/pdf/unix_rootkits_overview.pdf

Dittrich, Dave 2002. “Root Kits” and hiding files/directories/processes after a break-in.
http://staff.washington.edu/dittrich/misc/faqs/rootkits.faq

Grundy, Barry J. 2008. The Law Enforcement and Forensic Examiner’s Introduction to Linux.
http://linuxleo.com/Docs/linuxintro-LEFE-3.78.pdf

Honeynet Project 2001. Scan Of Month 15.
http://old.honeynet.org/scans/scan15/

Karvinen, Tero 2012. Linux palvelimena ICT4TN003-4 kurssin kotisivu.
http://terokarvinen.com/2012/aikataulu-linux-palvelimena-ict4tn003-4-ja-ict4tn003-6-syksylla-2012

Khoo, Martin 2001. P0st-M0rt3m 0f 4 R00tk1t 4tt4ck.
http://www.blackhat.com/presentations/bh-asia-01/khoo.ppt

Neary, David 2004. PAM and password control.
http://www.linux.ie/articles/pam.php

Tweedie, Stephen 2000. EXT3, Journaling Filesystem.
http://olstrans.sourceforge.net/release/OLS2000-ext3/OLS2000-ext3.html

UNSEKURITY TEAM, s.a. HACKING DE WEB.
http://www.ataliba.eti.br/sections/old-hacking/unsekurity/texto1/detonaweb.txt

About

Tätä dokumenttia saa kopioida ja muokata GNU General Public License (versio 2 tai uudempi) mukaisesti.
http://www.gnu.org/licenses/gpl.html
Pohjana Tero Karvisen Linux-kurssi, www.iki.fi/karvinen

Avainsanat:, , , , ,
Kategoria(t): ICT4TN003-4 Linux palvelimena | Jätä kommentti »

Harjoitustehtävä 2: Prosessinhallintaa

2.9.2012

Harjoitustehtävän aiheena oli Linux tavallisten prosessinhallinnan työkalujen käytön harjoitteleminen. Lisäksi harjoitustehtävässä testattiin kuorman lisäämistä stress työkalulla ja palvelimen toiminnan monitorointia munin työkalulla.

Harjoitusympäristö

Harjoitus suoritettiin 02.09.2012 opiskelijan kotona käyttäen henkilökohtaista tietokonetta. Internet-yhteytenä oli Elisa Oyj:n tarjoama VDSL tyyppinen 100/10 mbit kiinteä laajakaistayhteys. Harjoituksessa käytettiin Lenovo R60 kannettavaa tietokonetta, johon oli asennettu Xubuntu versio 12.04 32-bittinen Linux käyttöjärjestelmä.

Lenovo R60 kokoonpano:

  • Suoritin: Intel Core 2 Duo T56000 @1.83 Ghz
  • Keskusmuisti: 4 Gt DDR2
  • Kiintolevy: 100 Gt SATA150 54000rpm
  • Käyttöjärjestelmä: Xubuntu versio 12.04 32-bittinen

Munin työkalun asennus

Munin on palvelimen jatkuvaan monitorointiin tarkoitetu työkalu, joka kerää säännöllisin väliajoin tietoa järjestelmän suorituskyvystä ja generoi kerämästään datasta graafisen esityksen HTML sivuina. Aloitin asennuksen päivittämällä Ubuntun pakettivarastot komennolla:

$sudo apt-get update

Pakettivarastojen päivitys kesti muutamia sekunteja.

Muninin tuottaman grafiikan tarkastelemiseen tarvitaan myös WWW-palvelin. Asensin Apache palvelimen komennolla:

$sudo apt-get install apache2

Asennus kesti parikymmentä sekuntia. Testasin Apache asennuksen toimivuuden avaamalla localhost osoitteen Firefoxilla:

Seuraavaksi asensin Munin työkalun Ubuntun pakettivarastosta komennolla:

$sudo apt-get install munin munin-node

Asennus kesti puolisen minuuttia. Sen jälkeen muokkasin Munin noden eli “asiakkaan” asetustiedostoa:

$sudo nano /etc/munin/munin.conf

Asennustiedostoon muokattiin seuraava asetus:

# Which address to bind to;
#host *
 host 127.0.0.1

Näillä asetuksilla Munin seuraa localhostia eli Linux järjestelmään paikallista ip-osoitetta.Päätin Muninin konfiguroinnin uudelleenkäynnistämällä munin-node palvelun ja apachen:

$service munin-node restart
$service apache2 restart

Testasin Munin asennuksen toimivuuden avaamalla Firefoxilla osoitteen localhost/munin

Graafiset esitykset saatiin näkyville valitsemalla linkki localhost.localdomain

Valitun prosessin tarkastelua: Gimp kuvankäsittelyohjelma

Valitsin tarkasteltavaksi prosessiksi Gimp kuvankäsittelyohjelman, jonka latasin käynnistysvalikon polusta Graphics–> GIMP Image Editor:

Latasin GIMP ohjelmalla netistä lataamaani valokuvatiedoston ja pari kuvankaappauskuvaa editointia varten. Seuraavaksi selvitin GIMP
ohjelman prossesitunnuksen ps ja grep komentojen avulla:

Tulosteesta tulkitsin, että GIMP ohjelman pääprosessin tunnus on 11183. Seuraavaksi tarkastelin prosessia top työkalulla käyttäen komentoa:

$ top -p 11183

Muistin kulutus oli 3,9 % koneen muistin määrästä. Seuraavaksi asensin iotop ohjelman komennolla:

$sudo apt-get install iotop

Tarkastelin samaa prosessia iotop työkalulla käyttäen komentoa:

$sudo iotop -p 11183

Tuloste kertoo, että prosessi ei käytä kiintolevyä tällä hetkellä ollenkaan.

Tämän jälkeen tarkastelin prosessien avaamien tiedostoja lsof työkalulla. Käytin grep komentoa suodattamaan pois järjestelmäkirjastot listauksesta:

$lsof -p 11183 | grep -v '.so'

Tulosteesta voidaan havaita GIMP ohjelman avanneen useita fonttien välimuistitiedostoja.

Selvitin myös netstat komennolla aktiiviset Internet-yhteydet ja käyttöjärjestelmän Unix socketit.

$netstat -l

Tulosteesta voidaan päätellä, että GIMP ohjelma ei ota yhteyksiä Internettiin. Samoin voidaan päätellä että se ei tarjoa omia palvelujaan käyttöjärjestelmässä.

Lopetin valitun prosessin tarkastelun tappamalla prosessin komennolla:

$kill -p 11183

Prosessi lopetti toimintansa ilman ongelmia ja kaikki GIMP ohjelman avaamat ikkunat sulkeutuivat.

Kuorman luominen stress työkalun avulla

Aloitin asentamalla stress työkalun Ubuntun pakettivarastosta:

$sudo apt-get install stress

Käynnistin klo 20:43 stress työkalun komennolla:

$stress --cpu 12 --io 4 --vm 2 --vm-bytes 512M -d 1 --timeout 3600s &

Komento muodostaa vaihtelevaa kuormaa tunnin ajan. Ampersandi merkillä annettiin komentotulkille kehotus ajaa ohjelmaa taustalla ja
palata takaisin komentotulkkiin.

Tarkastelin kuorman määrää top työkalulla. Ensiksi havannoin prosessorikuorman määrää Shift-P näppäinoikotiellä:

Tulosteesta voidan nähdä prosessorikuormituksen olevan noin 80 %. Seuraavaksi tarkastelin muistin kulutusta Shift-M näppäinoikotiellä:

Tulosteesta voidaan nähdä stress työkalun käyttävän noin 30% muistiresursseista.

Tarkasteli levy-IO:n käyttöä iotop työkalulla:

 $sudo iotop

Tuloste kertoo prosessien kirjoittavan levylle 21.60 megatavun nopeudella. Kiintolevyn käyttöaste on yli 90%.

Yleisesti ottaen mielestäni stress työkalulle annetut parametrit eivät synnyttäneet “tarpeeksi” kuormaa järjestelmän todellisen kuormituskyvyn tutkimiseen. Linuxin graafinen käyttöliittymä pysyi lähes täysin responsiivisena koko ajoaikana. Etenkin muistin ja levy-IO kuormituksen lisääminen olisi voinut antaa luotettavamman tuloksen. Myös ajoaikaa olisi kasvatettava useisiin tunteihin mahdollisten vikatilanteiden aikaansaamiseksi.

Muninin tuottaman tiedon tarkastelua

Munin asennuksen sattuneen hakemistojen polkumäärityksessä olleen virheen vuoksi HMTL muotoiset tilastot eivät päivittyneet ensimmäisen ajon jälkeen. Huomasin virheen harmillisesti vasta stress työkalun lopettaessa ajoaan. Korjasin Muninin www-hakemiston polkumäärityksen tiedostossa /etc/munin/munin.conf oikeaan muotoon:

htmldir /var/cache/munin/www

Käynnistin uudelleen palvelut apache2 ja munin-node komennoilla:

$service munin-node restart
$service apache2 restart

Käynnistin stress työkalun uudestaan edellä mainituilla parametreilla, jotta saisin enemmän tilastotietoja Munin kerättäväksi.

Muninin prosessorin käyttöastetta kuvaavassa tilastossa voidaan nähdä prosessikuorman äkillinen nouseminen kun stress työkalu käynnistetään uudelleen:

Muistin käyttöä kuvaavassa tilastossa vastaavan kaltaista muutosta ei ole selkeästi havaittavissa:

Prosessorin kellotaajuuden skaalautumista kuvaava tilasto kertoo että prosessorin molemmat ytimet toimivat 1 Ghz taajuudella:

Tilastoa voidaan tulkita siten että ACPI virransäästön automatiikka pitää prosessorin kellotaajuutta selvästi alempana kuin maksimi 1,83 Ghz.Prosessikuormaa lisäämällä kellontaajuuden pitäisi skaalautua korkeammalle.

Käytetyt ohjelmistot

GIMP versio 2.6.12 http://www.gimp.org/

Lähteet

FreePhotosBank 2012.
http://www.freephotosbank.com/12418.html

How-To: Monitoring a Server with Munin 2006.
http://www.debuntu.org/how-to-monitoring-a-server-with-munin

Karvinen, Tero 2012. Linux palvelimena ICT4TN003-4 kurssin kotisivu.
http://terokarvinen.com/2012/aikataulu-linux-palvelimena-ict4tn003-4-ja-ict4tn003-6-syksylla-2012

Stress project page 2009.
http://weather.ou.edu/~apw/projects/stress/

Ventura, Luis 2010. Install Munin In Five Minutes On Ubuntu 10.04.
http://linhost.info/2010/06/install-munin-in-five-minutes-on-ubuntu-10-04/

About

Tätä dokumenttia saa kopioida ja muokata GNU General Public License (versio 2 tai uudempi) mukaisesti.
http://www.gnu.org/licenses/gpl.html
Pohjana Tero Karvisen Linux-kurssi, www.iki.fi/karvinen

Avainsanat:, , , , , , , ,
Kategoria(t): ICT4TN003-4 Linux palvelimena | Jätä kommentti »

Seuraa

Get every new post delivered to your Inbox.