Author Archive for jkw

WordPressin automaattinen päivitys – autopress-0.1

Ylläpidätkö WordPress-sivustoja? Oletko kyllästynyt toistamaan komentoja wget wordpress.org/latest.tar.gz -> tar -zxf latest.org -> cp/mv wordpress/* /var/www/ ??? Nyt ongelmiisi on ratkaisu, autopress!

Halusin tutustua hieman bash-skriptauksen maailmaan ja olin kyllästynyt toistelemaan noita komentoja, joten tein pienen skriptinpätkän tekemään asian puolestani. Julkaisen sen tässä alla, tee sillä mitä lystäät! Koodi saattaa olla hassusti rakennettua, typerää ja tehotonta – mutta se ajaa jotenkuten asiansa.

Pointtina koko hommassa on tietysti se että skriptin voi ajastaa ajettavaksi vaikkapa parin tunnin välein eikä päivityksistä tarvitse enää huolehtia, joskin asiassa on kaksi aika isoa muttaa:

  1. WordPressin päivittäminen uusimpaan versioonsa saattaa rikkoa sivustosi, varsinkin jos käytössä on erikoisempia teemoja tai lisäosia, joten WordPressin päivittäminen täysin automaattisesti on oikeastaan aika huono idea. Tosin jos ylläpitämäsi sivusto on yhtään henkilökohtaista webbisivua tärkeämpi, on sinulla varmastikin testiympäristö erikseen ja tätä voisi käyttää vaikkapa vain siellä.
  2. WordPressin päivittäminen saattaa vaatia lähtöversiosta ja uudesta versiosta riippuen myös tietokannan päivityksen (joka tapahtuu kirjautumalla WordPressin Dashboardiin admin-tunnuksin), eikä tämä skripi tee sitä. Eli sinun täytyy joka tapauksessa kirjautua WordPressiin päivityksen jälkeen mahdollisimman nopeasti.

Jos haluat kuitenkin ajastaa skriptin suoritettavaksi vaikka tunnin välein, muokkaa crontabiasi komennolla crontab -e ja lisää sinne rivi: “*/60 * * * * /hakemisto/jossa/skripit/on/autopress-0.1″. Lisää ajastamisesta cronilla esimerkiksi täältä.

Copypasteta tuosta alempaa tai lataa tästä: autopress-0.1


#!/bin/bash

############################################
######### AUTOPRESS 0.1 ####################
############################################
#
# Autopress is a bash script to automatically update WordPress.
# For more information check http://jannewaren.fi
#
# Author: Janne Warén (janne.waren@iki.fi)
# License: Public domain
#
# How to use it?
# Just configure the script starting from line X and run it.
# Note: Make sure you have write permission to $wordpress_location
# You still need to do the database update manually by logging in to WP

############################################
######### VERSION HISTORY AND TODO #########
############################################
#
# Version 0.1 Initial release
#  - basic functionality
#    - check for updates, update wordpress files
#  - logging
#  - silent mode
#
# TODO:
#  - Backup before updating
#  - Check only -mode (with e-mail notifications)
#  - WordPress database update
#  - Plugin updates

############################################
######### CONFIGURE HERE ###################
############################################

# Where is the script located?
script_location="/home/user/bin/"

# Where is your WordPress installation located?
wordpress_location="/var/www/"

# Where to check for a new update?
wordpress_url="http://wordpress.org/latest.tar.gz"

# Where to write a log?
# Note: if running with cron, specify full path!
logfile="/home/user/bin/autopress.log"

# Are we running in silent mode?  (0=no, 1=yes)
silent="0"

# Only check for a new version? (and notify via e-mail)
# checkmode="1"
# email="username@example.com"

# Should we do a file backup? (0=no, 1=yes)
# backup_files="1"

# Should we do a database backup? (0=no, 1=yes)
# backup_database="1"

# MySQL username and password (only needed if backup_database=1)
# mysql_username=""
# mysql_password=""

############################################
######### THE ACTUAL SCRIPT ################
############################################

# Get the latest WordPress versions filename from WordPress.org
function latest_file_name {
local latest=$(
curl -s --head $wordpress_url |
tr -d '\r' |
awk -F '=' '/^Content-Disposition/ {print $2}'
)
echo $latest
}

# Compare the latest version from wordpress.org and the latest version in your folder and decide if we need to update
function version_comparison {
output "Checking for a new WordPress version.."
local remote_file=$(latest_file_name)
local local_file=$(current_version)

if [ $remote_file = $local_file ]; then
output "You already have the latest version $remote_file, no need to update, quitting!"
exit
fi

local newer=$(
echo -e "$remote_file\\n$local_file" |
sort -V |
tail -1
)

if [ $newer = $local_file ]; then
output "Either you got beta versions or something went terribly wrong.. Quitting!"
elif [ $newer = $remote_file ]; then
output "Found an update!"
updating_version="$newer"
update_wordpress
else
exitcode="Something went wrong with version comparison"
quit
fi
}

# Determine which of the WordPress tar.gz files is newest version in current folder
function current_version {
# First check if any matching file exist
local count_files=$(
ls $script_location |
grep -c wordpress-
)

if [ $count_files = 0 ]; then
# If files do not exist, skip the rest of version_comparison and just update
output "No previous version detected, will update/install WordPress!"
updating_version="$newer"
update_wordpress
else
# If files exists, return the newest version filename
local file_name=$(
ls $script_location |
grep wordpress- |
sort -V |
tail -1
)
echo $file_name
fi
}

# So we have decided to update, here we go!
function update_wordpress {
if [[ -e "$script_location""latest.tar.gz" ]]; then
output "Removing old latest.tar.gz file"
rm "$script_location"latest.tar.gz
fi

output "Downloading $wordpress_url - this may take a while"
wget -q -P "$script_location" $wordpress_url
tar -zxf "$script_location"latest.tar.gz -C "$script_location"
cp -R "$script_location"wordpress/* $wordpress_location
mv  "$script_location"latest.tar.gz "$script_location""$updating_version"
rm -fr "$script_location"wordpress/
output "Done! Your WordPress has been updated, please log in to update your database!!"
}

# Needed just in case we need to quit, pretty much pointless at the moment though
function quit {
output "Self destruction in 1...2...3...DONE!"
output "Quit reason: $exitcode"
exit
}

# Write a log and echo (if not in silent mode)
function output() {
if [ $silent = 0 ]; then
echo "$1"
fi
local time=$(date +'%Y-%m-%d %H:%M:%S')
echo "$time $1" >> $logfile
}

function initialize {
if [[ ! -e $logfile ]]; then
touch $logfile
output "Created log file: $logfile"
fi
}

function main {
initialize
version_comparison
}

main

Web-palvelimen nopeutus Varnishilla

Tässä artikkelissa asennetaan Apache web-palvelimen rinnalle Varnish ja nopeutetaan näin web-sivujen tarjoilemista palvelimelta.

1. Johdanto

Käänteinen proxy

Käänteisen proxyn toimintaperiaate

Varnish on Apache-palvelimen eteen asennettava cache-palvelin. Varnish toimii käänteisenä proxyna web-palvelimen sisällä. Käänteinen proxy tarjoilee kaikelle kansalle sivuja portissa 80, ja hakee taas itse tarjoilemansa sivut Apachelta joka tarjoilee niitä Varnishille jossain muussa portissa.

Hyöty tästä saadaan ulos siinä, että Varnish pitää staattisia versioita tarjoiltavista sivuista omassa välimuistissaan, eikä Apachen tarvitse jokaisella käyttäjän tekemällä sivunlatauksella suorittaa mahdollista sivuilla olevaa PHP-koodia ja siihen liittyviä tietokantahakuja.

Varnishista on siis oikeaa hyötyä näillä ehdoilla:

  • Palvelimella on paljon liikennettä
  • Palvelimella pidetään dynaamisia sivuja, jotka ilman reverse-proxya rakennetaan jokaisella sivunlatauksella uudestaan.

Ihan kaikille dynaamisille sivuille Varnish ei toki sovi vaan pitää miettiä käyttötarkoitusta. Esimerkiksi WordPressin tai muiden julkaisujärjestelmien nopeuttamiseen Varnish on oiva apu kun artikkelit eivät päivity ihan reaaliaikaisesti, vaan minuuttien tai kymmenien minuuttien päivitysväli on ihan ok. Jos taas palvelimella pidettäisiin jotain reaaliaikaisempaa kuten Etherpadia niin varmasti tulisi ongelmia: sovelluksessa jossa käyttäjät kirjoittavat tekstiä yhteistyössä nähden reaaliaikaisesti muidenkin kirjoitukset, ei minuuttien pituinen päivitysväli riitä.

2. Varnishin asennus ja käyttöönotto

Asennan seuraavassa Varnishin esimerkinomaisesti tälle samaiselle palvelimelle jossa ylläpidän sivustoa www.jannewaren.fi. Käytössä on siis Linoden virtuaalipalvelin Ubuntu 12.04 Server LTS -käyttöjärjestelmällä. Koneen lshw-tiedot: kone.txt.  Alkutilanteessa on asennettuna koko LAMP-pino ja Apache tarjoilee sivuja portissa 80.

Ensimmäiseksi asennetaan Varnish paketti komennolla apt-get install varnish

Varnishin asennus

..ja rivistä “ *Starting HTTP accelerator varnishd  [ OK ]” voimme päätellä kaiken menneen suht ok.

2.1. Varnishin asetukset

Varnishin perusasetukset saadaan tehtyä kahta tiedostoa muokkaamalla: /etc/varmish/default.vcl ja /etc/default/varnish. Oletuksena Varnish tarjoilee sivuja portissa 6081 ja etsii pyytää vastaavia sivuja backendiltä (eli Apache web-palvelimelta) portista 8080.

1) /etc/varnish/default.vcl

Tässä konfiguraatiotiedostossa asetamme Varnishille tiedon backendistä, eli mihin porttiin Varnish lähettää itse pyyntöjä eteenpäin. Oletuksena portti on 8080 ja voimme sen hyvin siinä pitää, meidän pitää vaan muuttaa Apache tarjoamaan sivuja tuossa portissa. Toki voisimme valita jonkun toisenkin portin mutta 8080 on meille ihan ok.

/etc/varmish/default.vcl

2) /etc/default/varnish

Tässä konfiguraatiotiedostossa asetetaan Varnish-daemonin käynnistyksessä käytettävät asetukset. Saman asiat voisi siis tehdä käynnistämällä aina Varnishin itse komennolla varnishd mutta pidän mielummin asetuksen konfiguraatiotiedostossa ja Varnishin käynnistyksen automaattisena.

Tiedostossa on valmiina muutama erilainen malli asetuksille, käytämme mallia numero 2 joka oletuksena onkin käytössä. Eli osa asetuksista haetaan äskeisestä default.vcl tiedostosta ja osa taas asetetaan tässä tiedostossa.

Muutamme tässä tiedostossa ainoastaan porttia jossa Varnish tarjoaa sivuja ulkomaailmaan, asetamme sen tietysti portiksi 80.

/etc/default/varnish

Tämän muutoksen voimaansaattamiseksi varnish pitää uudelleenkäynnistää, mutta ei tehdä sitä ihan vielä. Jos varnish uudelleenkäynnistettäisiin samantien, meillä olisi kaksi daemonia tarjoilemassa sivuja samassa portissa 80.

2.2. Apachen asetukset

Apache laitetaan siis palvelemaan Varnishia portissa 8080, muutokset pitää tehdä tiedostoon /etc/apache2/ports.conf ja sivustosi asetustiedostoon eli tässä tapauksessa /etc/apache2/sites-enabled/jannewaren.fi:

/etc/apache2/ports.conf

Tiedostossa /etc/apache2/ports.conf muutetaan rivejä NameVirtualHost ja Listen

/etc/apache2/sites-enabled/jannewaren.fi

Tiedostossa /etc/apache2/sites-enabled/jannewaren.fi muutetaan riviä <Virtualhost *:80>

2.3. Käyttöönotto

Kaiken pitäisi nyt olla ok asetuksissa, ja saamme muutetut asetukset käyttöön käynnistämällä sekä Apachen että Varnishin uudestaan.

Tässä välissä testataan kuitenkin hieman suorituskykyä vanhoilla asetuksilla eli kun Apache tarjoaa suoraan sivuja ja rakentaa ne jokaisella sivunlatauksella uudestaan. Suorituskykyä testataan komennolla ab -c Y -n X http://osoite.domain. Parametrilla -c määritellään yhtäaikaisten sivunlatausten määrä ja parametrilla -n suoritettavien sivunlatausten kokonaismäärä. Jos haluat nähdä muutoksen suorituskyvyssä Varnishin käyttöönoton jälkeen, tee mittauksia jo nyt ja tallenna tulokset. Lisää aiheesta artikkelin lopussa.

Sitten otetaankin muutokset käyttöön ja käynnistetään sekä Varnish että Apache uudestaan, komennot ovat /etc/init.d/apache2 restart ja /etc/init.d/varnish restart. Näiden kahden komennon välissä voit tietysti testata että tuleehan Varnish oikeasti käyttöön. Kun annat ensimmäisen komennin niin sivustosi lakkaa kokonaan vastaamasta (mutta vastaa portista 8080), ja toisen komennon antamisen jälkeen sivusto vastaa taas normaalisti.

3. Vaikutus suorituskykyyn

Testasin suorituskykyä komennolla ab -c 10 -n 100 http://jannewaren.fi/linux/linuxin-keskitetty-hallinta-puppet-osa-2-testiympariston-pystyttaminen-virtualboxiin/ sekä ennen että jälkeen muutosten.

Ennen muutoksia tulos näytti tältä:

Palvelimen suorituskykyä ilman Varnishia

Ja muutosten jälkeen tältä:

Palvelimen suorituskyky kun Varnish on käytössä

Testituloksia voi tietysti vertailla ja analysoida vaikka miten, mutta selkeiten eron ymmärtää ehkä tässä: ennen Varnishin käyttöönottoa 100 sivunlatauksen suorittamiseen meni aikaa 9,865 sekuntia, ja Varnishin käyttöönoton jälkeen vain 0,449 sekuntia. Ero on valtava. Tällä on suuri merkitys kun palvellaan suuria käyttäjämääriä. Palvelin pystyy palvelemaan huomattavasti enemmän käyttäjiä kyykkäämättä ja tietysti jos palvelimella on muutakin käyttöä niin enemmän resursseja jää sille.

Varoituksen sana: älä testaa suorituskykyä muilla kuin omilla palvelimillasi ja silloinkin mieluiten lokaalisti. Toiminta voi olla rinnastettavissa palvelunestohyökkäykseen.

Reverse-proxyn käyttö palvelimella on myös ekoteko: maalaisjärjellä ajateltuna prosessorin ja kaiken muunkin raudan käyttöaste jää pienemmäksi ja sähköä säästyy. Pitääkin joskus testata näitä vielä laajemmin ja mitata sähkönkulutusta ihan oikeilla laitteilla. Se on kuitenkin eri kirjoitus se.

Linuxin keskitetty hallinta: Puppet (Osa 2) – Testiympäristön pystyttäminen VirtualBoxiin

Artikkelissa Linuxin keskitetty hallinta: Puppet (Osa 1) tutustuimme Puppetiin pintapuolisesti sitä pelkästään yhdellä työasemalla käyttäen. Tässä osassa kerron miten voit pystyttää testiympäristön agent/master -käyttöä ajatellen käyttäen VirtualBoxia.

1. Johdanto

Testiympäristön pystytys tehdään niin että isäntäkoneena on Windows 7 ja virtuaalikoneina ajetaan Ubuntu Serveriä ja Xubuntua, molemmissa käytettävä versio on Oneiric Ocelot 11.10. Tehdäksesi samanlaisen testiympäristön, pitää isäntäkoneesi olle liitettynä reitittimeen joka luo koneiden välille lähiverkon ja antaa jokaiselle koneelle oman lähiverkon IP-osoitteen mallia 192.168.X.X. Tässä tapauksessa reitittimenä toimii A-Link WNAP 3G.

Testiympäristöä varten tarvitset

Voit toki käyttää myös muita haluamiasi versioita, mutta jokin asia saattaa toimia niissä toisin.

2. VirtualBoxin ja virtuaalikoneiden asennus

Tätä osiota en käy sen tarkemmin läpi, VirtualBoxin asennus Windows 7 -käyttöjärjestelmään ja uusien virtuaalikoneiden asennus VirtualBoxin alle ovat sen verran suoraviivaisia ja opastettuja operaatioita että niistä selviää varmasti VirtualBoxin ohjeilla ja Ubuntun yleisillä asennusohjeilla.

Lähtötilanne on siis se että sinulla on VirtualBox ja kaksi virtuaalikonetta (Ubuntu Server ja Xubuntu) asennettuina. Anna koneille nimet puppetserver ja puppetagent1 seurataksesi ohjetta ja helpottaaksesi hahmottamista.

3. VirtualBoxin asetusten muokkaus ja kiinteät lähiverkon IP-osoitteet virtuaalikoneille

Kun olet saanut virtuaalikoneet luotua ja asennettua, käy muokkaamassa niiden verkkoasetuksia VirtualBoxin asetuksista (Kone -> Asetukset -> Verkko) ja valitse kuvan mukaisesti asetuksen Liitetty laitteeseen arvoksi Bridged Adapter.

Tällä tavoin virtuaalikoneille annetaan jokaiselle oma IP-osoite samasta lähiverkosta kuin missä isäntäkoneesikin on. Oletusasetuksella NAT virtuaalikoneilla on kaikilla sama IP-osoite 10.0.2.15 eivätkä ne voi nähdä toisiaan eikä reittittimeesi liitetyt fyysiset laitteetkaan voi niitä nähdä.

Laita VirtualBoxin verkkoasetuksista muistiin kunkin koneen Mac Address eli fyysinen osoite. Oletuksena VirtualBox luo kaikille koneille satunnaiset Mac-osoitteet. Seuraavaksi käydään laittamassa reittimen asetuksita MAC-osoitteiden perusteella virtuaalikoneille kiinteät IP-osoitteet. Oletusasetuksilla reititin antaa jokaiselle yhdistävälle laitteelle automaattisesti kasvavan IP-osoitteen siinä järjestyksessä kun laitteet sitä pyytävät, joten osoite saattaa muuttua riippuen siitä missä järjestyksessä koneet käynnistät ja onko muita laitteita liitettynä verkkoon.

Tämä kohta on tietysti erilainen jokaisella reitittimellä, mutta yritä löytää alla olevan kaltainen TCP/IP / LAN asetusvalikko.

Aseta tässä valikossa Domain Nameksi localdomain. Kohdasta Set Static DHCP päästään määrittämään kiinteät IP-osoitteet kullekkin MAC-osoitteelle. Valitse sellaiset IP-osoitteet jotka ovat DHCP Client Rangen sisällä eli tässä tapauksessa jotain väliltä 192.168.1.100-192.168.1.200.

Virtuaalikoneelle puppetserver asetettiin siis kiinteä IP-osoite 192.168.1.190 ja koneelle puppetagent1 osoite 192.168.1.191. Nyt kun käynnistät koneen puppetserver, pitäisi sen IP-osoitteen olla juuri asetettu. Voit tarkistaa toimivuuden komennolla ifconfig:

Varmista seruaavaksi että koneet näkyvät toisensa, eli pingaa koneella puppetagent1 osoitetta 192.168.1.190 ja toisinpäin pingaa koneella puppetmaster osoitetta 192.168.1.191. Jos saat seuraavanlaisia tuloksia molemmilla koneilla ovat verkkoasetuksesi kunnossa.

4. FQDN eli Fully Qualified Domain Name

Saadaksemme puppetin toimimaan master/agent konfiguraatiolla, pitää koneilla olla oikein asetetut FQDN:t eli absoluuttiset domainnimet. Aiemmassa kohdassa asetimme reitittimet LAN-asetuksissa domainiksi localdomain joten käytetään sitä. Oikealla palvelimella olisi tietysti joku oikea FQDN kuten tämän blogin hostaamiseen käytetty kone limia.jannewaren.fi. Testiympäristössä toimimme kuitenkin vain lähiverkon sisällä joten localdomain on ihan sopiva meille.

Voit tarkistaa koneen hostnamen (koneen nimi) komennolla hostname ja FQDN:n komennolla hostname -f. Oletusasetuksilla molemmat näyttävät samaa eli koneen nimeä:

jkw@puppetagent1:~$ hostname
puppetagent1
jkw@puppetagent1:~$ hostname -f
puppetagent1

Muokkaa koneen FQDN:ää ja koneen näkemiä muita FQDN-osoitteita muokkaamalla tiedostoa /etc/hosts (esimerkiksi komennolla sudo nano /ets/hosts) tällaiseksi koneella puppetmaster..

..ja tällaiseksi koneella puppetagent1:

Nyt voimme testata pingillä että koneet näkevät toisensa ja itsensä myös FQDN nimiä IP-osoitteiden sijaan käytettäessä. Pingin kanssa voit nyt asetusten ollessa kunnossa käyttää joko pelkkään koneen nimeä tai pitempää FQDN-nimeä:

5. Entäs sitten?

Artikkelin ohjeita seuraamalla sinulla pitäisi nyt olla VirtualBoxin sisällä kaksi virtuaalikonetta jotka näkevät toisensa FQDN-osoitteita käyttäen. Seuraavaksi voidaan edetä puppetin agent/master asennukseen. Kirjoitan siitä eri artikkelissa, mutta sillä aikaa koneelle puppetserver voi asentaa paketin puppetmaster ja koneelle puppetagent1 paketin puppet – ja seurata puppetin omia ohjeita :)

Linuxin keskitetty hallinta: Puppet (Osa 1)

Linux palvelimena -kurssi päättyi tällä viikolla ja päällä on mielettömät kotitehtävävajarit, jotain pitäisi päästä tekemään. Siispä teen ja kirjoitan siitä muistiinpanot tämän blogiartikkelin muodossa. Kurssilla on tullut monta kertaa vastaan Puppet, josta en tiedä sen enempää kuin että se liittyy Linux-käyttöjärjestelmien keskitettyyn hallintaan. Ilmeisesti siis vähän samaan tyyliin kuin Windows-ympäristössä voidaan määritellä työasemien asetuksia Group Policyillä.

Yritän tässä artikkelissa asentaa ja konfiguroida Puppetin yritys-erehdys menetelmällä sen kummemmin asiaan etukäteen tutustumatta. Hyvä englanninkielinen ohje saman asian aikaansaamiseksi löytyy Puppetin omasta dokumentaatiosta. Dokumentoin kaikki työvaiheet, tämän artikkelin lukijan kannattaa ehkä lukea loppuun asti ennen kuin yrittää samoja komentoja itse :)

1. Mikä ihmeen Puppet?

Wikipediaa lukemalla selviää hieman lähtötietoja enemmän, mutta kaadun jo ensimmäiseen lauseeseen:

Puppet is a tool designed to manage the configuration of Unix-like and Microsoft Windows systems declaratively.

Siis, Puppetilla voidaan hallinnoida sekä Unixin kaltaisten käyttöjärjestelmien (esim. Linux) että Windowsin asetuksia deklaratiivisesti. Fiksumpi voisi heti tietää mitä ihmettä tuo deklaratiivisuus tarkoittaa, mutta minä joudun turvautumaan ystäväämme Googleen.

Deklaratiivisuus tässä yhteydessä tarkoittaa nähdäkseni sitä että kerrotaan vain mitä halutaan tehtävän, ei sitä miten se tehdään. Jos olen oikeassa niin Puppetia käyttäessä kerrotaan vain että halutaan esimerkiksi koneille a, b ja c asennetuksi ohjelmistot x, y ja z, taustakuvaksi tietty kuva, tai vaikka vakioidut pikakuvakkeet työpöydälle ja Puppetin pitäisi hoitaa loput. Katsotaan miten käy.

2. Puppetin asennus – Ubuntu 12.04 LTS (Precise Pangolin) Beta 1

Puppet on saatavilla suoraan Ubuntun Main-repositorysta, joten asennus onnistuu helposti komennolla sudo apt-get install puppet. Tällä hetkellä asentuva versio on numeroltaan 2.7.11-1.

Asennuksen aikana sain näytölle tekstin “puppet not configured to start, please edit /etc/default/puppet to enable“, joten tutkitaan seuraavaksi tuota tiedostoa.

Kotitehtävä, viikko 6

Tässä artikkelissa kuvaan LAMP-palvelinympäristön ja WordPress-sisällönhallintajärjestelmän asennuksen Ubuntu Server 11.10 ympäristössä. Lisäksi asennan WordPressiin yhden lisäosan, ja otan Permalinksit käyttöön.

1. 1 Tehtävänanto

Lainaus kurssin Moodle-sivuilta:

- Asenna WordPress. Boottaa liverompulta, niin voit tehdä asennuksen aivan alusta.

Lisäksi kaksi seuraavista:
- Asenna uusi wp teema
- Asenna uusi wp plugin
- Ratkaise “Työasemat ja tietoverkot 25″ koe
- Ota PermaLinks käyttöön
- Kirjoita oma wp-teema
- Kirjoita oma wp-plugin

2. 2 Testiympäristö

Aiemmin tällä viikolla hankin käyttööni uuden jannewaren.fi -domainin Viestintävirastolta ja virtuaalipalvelimen Linodelta. Olen aikeissa siirtää tämän blogin sinne, lähinnä harjoituksen ja edellisen palveluntarjoajan (Suncomet) hitauden takia. Haluan myös hallinnoida palvelinta kokonaan, eli siirryn webhotellipalvelusta virtuaalipalvelimeen. Toki voisin siirtää myös vanhan domainnimeni jannewaren.eu uudelle palveluntarjoajalle, mutta päätin kuitenkin vielä vaihtaa .fi domainiin. Vaihdos ihan jo senkin takia että jannewaren.eu on rekisteröity suoraan Suncometin kautta, enkä jaksa alkaa selvittämään mitä tarvitsen siirtääkseni sen johonkin hallinnoidakseni sitä itse.

Teen siis harjoituksen Linoden virtuaalipalvelimella olevalla Ubuntu 11.10 käyttöjärjestelmällä johon olin tietysti yhteydessä ssh:n yli. Mitään lisäpaketteja ei ole tässä vaiheessa asennettu, joten pääsen aloittamaan aivan alusta. En tosin ihan täysin alusta, sillä en asentanut Ubuntua itse, vaan valitsin Linoden valmiin Ubuntu 11.10 -paketin joka asentui webbikäyttöliittymästä muutamassa minuutissa. Tästä johtuen jotain asetuksia ja paketteja on toki valmiina enemmän kuin itse asentaessa. En kuvaa virtuaalipalvelimen pystytystä Linodella sen tarkemmin, mutta täytyy kyllä sanoa että on kyllä hemmetin hyvä systeemi: tilauksesta ssh:lla sisäänkirjautumiseen kesti ehkä 10 minuuttia. Virtuaalikoneen lshw-tiedot liitteenä: kone.txt.

3. 3 Asenna WordPress

3.1. 3.1 LAMP

Wordpressin asennusta varten tarvitaan vielä Apache, MySQL ja PHP – Linux meillä on jo. Seurasin tässä Linoden ohjetta. Koneen hostnamen ja FQDN:n (fully qualified domain name) asetin jo eilen ja ne näyttävätkin olevan nyt kunnossa.

root@limia:~# hostname
limia
root@limia:~# hostname -f
limia.jannewaren.fi

1) 3.1.1 Apache

Seuraavaksi asensin apachen komennolla apt-get install apache2 ja totesin toimivuuden:

Kotitehtävä, viikko 5

1. 1 Tehtävänanto

Lainaus kurssin Moodle-sivuilta:

Asenna LAMP: Linux Apache MySQL PHP.
Tee harjoitus live-rompulla, niin pääset aloittamaan aivan alusta.

Vinkkejä:
http://terokarvinen.com/2008/install-apache-web-server-on-ubuntu-4
http://terokarvinen.com/bilkent.html
PHP kotihakemistoissa: katso: grep -r “php” /etc/apache2/*

Vapaaehtoisia lisätehtäviä: Tee harjoitus Ubuntu 12.04 alphalla. Mittaa tehoa ab:lla. Laita kansio salasanan taakse (.htaccess)

2. 2 Testiympäristö

Tein harjoituksen Xubuntu 11.10:llä VirtualBoxin päällä LiveCD:n sijaan, koska niin ei tarvitse säätää usean näytön konfiguraatiota, joka ei AMD:n näytönohjaimella toimi aina kovin virheettömästi. Eli yhdessä näytössä Xubuntu ja toisessa Windows 7 ja nettiselain jolla kirjoitan raporttia. Asensin kuitenkin tämän Xubuntun ihan puhtaalta pöydältä VirtualBoxiin, joten vaikutus on sama: pääsen aloittamaan aivan alusta.

VirtualBoxissa 8 gigatavun .vdi virtuaalinen kiintolevy Xubuntulle ja 512 megatavua muistia varattuna. Tarkemmat tiedot virtuaalikoneesta liitteenä. Isäntäkoneena Windows 7 SP1 64-bit kone: Intel Core i5 2500K prosessori, AsRock Z68 Pro3 Gen3, LGA1155, Intel Z68 emolevy, 8gb Kingston HyperX DDR3 1600MHz muistia, MSI:n AMD Radeon R6950 Twin Frozr II/OC, 2GB GDDR5 näytönohjain ja Samsung 128GB 830 Series SSD-kiintolevy.

Ennen raportoinnin aloittamista asensin siis Xubuntun levykuvasta http://se.archive.ubuntu.com/mirror/cdimage.ubuntu.com/xubuntu/releases/11.10/release/xubuntu-11.10-desktop-i386.iso ja asennuksen jälkeen asensin vielä VirtualBoxin asiakaslisäosat ja päivitin Xubuntu komennoilla sudo apt-get update ja sudo apt-get dist-upgrade.

3. 3 Asenna LAMP

Avasin komentokehotteen ja komensin sudo apt-get install apache2 mysql-server php5 jolloin paketit apache2 apache2-mpm-prefork apache2-utils apache2.2-bin apache2.2-common libapache2-mod-php5 libapr1 libaprutil1 libaprutil1-dbd-sqlite3 libaprutil1-ldap libdbd-mysql-perl libdbi-perl libhtml-template-perl libmysqlclient16 libnet-daemon-perl libplrpc-perl mysql-client-5.1 mysql-client-core-5.1 mysql-common mysql-server mysql-server-5.1 mysql-server-core-5.1 php5 php5-cli php5-common asentuivat automaattisesti. Paketti mysql-server kysyi salasanaa MySQL:n root-käyttäjälle ja asetin sen. Asennus käynnisti Apachen automaattisesti ja totesin toimivuuden nettiselaimella:

Kotitehtävä, viikko 4

1. 1 Tehtävänanto

Lainaus kurssin ICT4TN003 Moodlesta:

Tee oma metapaketti.
Lisäksi vähintään kaksi seuraavista:

  • tee metapaketteja dependicer:illa
  • allekirjoita paketti (debsign)
  • tee pakettivarasto (reprepro)
  • tee paketti, joka asentaa tekemäsi skriptin (man equivs, Files)
  • (vaikea) tee paketti, joka vastaa kysymyksiin; esim. postfix, mysql-server tms asennuksessa (debconf-get-selections, pre-install script)

2. 2 Testiympäristö

Tein kotitehtävän VirtualBoxissa pyörivällä 32 bittisellä Ubuntu 11.10 käyttöjärjestelmällä. Virtuaalikoneessa 10 gigatavun .vdi kovalevy ja 1024mb muistia varattuna. Tarkemmat tiedot virtuaalikoneesta liiteenä.

Isäntäkoneena Windows 7 SP1 64-bit kone: Intel Core i5 2500K prosessori, AsRock Z68 Pro3 Gen3, LGA1155, Intel Z68 emolevy, 8gb Kingston HyperX DDR3 1600MHz muistia, MSI:n AMD Radeon R6950 Twin Frozr II/OC, 2GB GDDR5 näytönohjain ja Samsung 128GB 830 Series SSD-kiintolevy.

3. 3 Tee oma metapaketti

Seurasin kurssin opettajan ohjeita http://terokarvinen.com/2011/create-deb-metapackage-in-5-minutes. Aloitin asentamalla tarvittavat ohjelmat ja kirjastot komennolla sudo apt-get install equivs. Aloitin luomalla työhakemiston jotta en tee kotihakemistoon sotkua, komensin mkdir jannen-hh2012 ja siirryin hakemistoon komennolla cd jannen-hh2012.

Aloitin metapaketin tekemisen komennolla equivs-control jannen-hh2012.cfg joka ei palauttanut mitään, eli kaikki meni hyvin ja tuon tiedoston pitäisi nyt löytyä työhakemistosta. Metapaketti tehdään siis muokkaamalla valmista pohjaa. Toki sen voisi rakentaa kokonaan ilman equivs-control -komentoa itse, mutta pohjaa muokkaamalla pysytään varmemmin tismalleen oikeassa syntaksissa.

Muokkasin tiedostoa jannen-hh2012.cfg komentorivillä komennolla nano jannen-hh2012.cfg. Valitsemani pakettinimi on tietysti lainattu jo luullakseni unholaan jääneistä Mikrobitin Hyvi&Hyöty rompuista :)

Eli teen metapaketin jolla pystyy kätevästi asentamaan mielestäni tarpeellisia paketteja jotka Ubuntun vakiovalikoimasta puuttuvat. Valitsin listalle sekä huvia että hyötyä.

Kotitehtävä, viikko 3

Viikon 3 kotitehtävä tulee valitettavasti lähes viikon myöhässä. En päässyt viime viikon tunneilla jossa näitä aiheita käsiteltiin, ja kotitehtävän aloittaminen oli hankalaa pelkästään tiedolla “tee honeynet scan of week 15″ joten se jäi tekemättä. Tämän viikon tunneilla katsottiin joidenkin vastauksia, ja asia selkisi edes vähän. Yritän nyt 11.2.2012 tehdä tämän kotitehtävän katsomatta muiden vastauksia tai mallivastauksia.

Tunneilta jäi päähän jo jonkun verran esitietoa: mounttaaminen ja tutkiminen hoituu autopsy -nimisellä ohjelmalla, tiedostossa lk.tgz oli jotain, ilmeisesti poistetuissa Orphan-Fileissa oli jotain ja esimerkiksi stringillä voi tutkia binääritiedostoja.

1. 1 Alkuvalmistelut

Asensin pöytäkoneelleni VirtualBoxin ja siihen Ubuntu 11.10 käyttöjärjestelmän 32 bittisenä. Päivitin tietysti asennuksen jälkeen kaikki paketit, ja asensin VirtualBoxin asiakaslisäosat, jotta hiiri ja näytön koon muuttaminen sujuu paremmin. Seuraavaksi asensin autopsyn komennolla sudo apt-get install autopsy ja käynnistin ohjelman komennolla sudo autopsy.

Seuraavaksi hain tehtävänannon netistä, Google avulla löysin osoitteeseen http://old.honeynet.org/scans/scan15/ joka näytti oikealta. Latasin paketin http://old.honeynet.org/scans/scan15/honeynet.tar.gz kotihakemistooni wgetillä, ja purin tiedoston komennolla tar -xzf honeynet.tar.gz jolloin .dd levynkuva ilmestyi polkuun /home/jkw/honeynet/honeypot.hda8.dd.

2. 2 Autopsy

Seuraavaksi menin autopsyn käynnistyessään ehdottamaan osoitteeseen http://localhost:9999/autopsy Firefox-selaimella. Selaimeen avautui nätisti autopsyn etusivu, josta alalaidan New case -nappulaa klikkaamalla pääsi luomaan uuden tapauksen tutkittavaksi.

Kotitehtävä, viikko 2

1. 1 Tehtävänanto

Viikon 2 kotitehtävänä on seuraavaa:

- Listaa tärkeimmät viestit lokista (laita lokit näytölle ja aiheuta itse lokitapahtumia; tee selkeä kooste)
- Tarina prosessien hallinnasta (tee koneella; nimeä käskyt, prosessit jne)
- Piirrä käyriä koneen tilasta (esim munin)

2. 2 Kotitehtävän palautus

Tein harjoituksen pöytäkoneellani johon on valmiiksi asennettu Ubuntu 11.10. Kone on itse kasattu ja tärkeimmät tiedot ovat: AMD Athlon 64 X2 5200+ prosessori, MSI K9A2-CF-F emolevy AMD790X piirisarjalla, 4gb DDR2 muistia ja nVidia GeForce 9800GTX+ näytönohjain. Tarkemmat tiedot: koneen_tiedot.txt. Koneen verkkonimi on pallokala.

Aloitin asentamalla muninin, jotta sillä on edes hetki aikaa tarkkailla koneen toimintaa ja käppyröiden piirtämisessä on näin ollen jotain mieltä. Asensin sen komennolla [CODE]sudo apt-get install munin[/CODE], komento käynnisty munin-prosessin automaattisesti, ja jätin sen taustalle pyörimään.

2.1. 2.1 Lokiviestit

Aiheutin itse erilaisia lokitapahtumia, seuraavassa kerron minkälaisia merkintöjä ne lokeihin aiheuttivat ja mikä merkinnöissä on oleellista. Tarkkailin kaikkia lokeja siirtymällä hakemistoon /var/log ja antamalla komennon tail -F *.

1) 2.1.1 Nettiyhteyden irtikytkeminen

Sammutin nettiyhteyden yläpalkista löytyvällä Network Connections -työkalulla. Nettiyhteys Wired Connection 1 oli siis aktiivisena, ja kun painoin Disconnect, syslogiin tulostui seuraavaa:

Jan 29 21:46:14 pallokala NetworkManager[1126]: <info> (eth0): device state change: activated -> disconnected (reason 'user-requested') [100 30 39]
Jan 29 21:46:14 pallokala NetworkManager[1126]: <info> (eth0): deactivating device (reason 'user-requested') [39]
Jan 29 21:46:14 pallokala NetworkManager[1126]: <info> (eth0): canceled DHCP transaction, DHCP client pid 1241
Jan 29 21:46:14 pallokala avahi-daemon[1139]: Withdrawing address record for 192.168.1.101 on eth0.
Jan 29 21:46:14 pallokala avahi-daemon[1139]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.1.101.
Jan 29 21:46:14 pallokala avahi-daemon[1139]: Interface eth0.IPv4 no longer relevant for mDNS.
Jan 29 21:46:14 pallokala dbus[1086]: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper)
Jan 29 21:46:14 pallokala dbus[1086]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'

Ensimmäinen rivi kertoo miksi nettiyhteys katkesi, tässä tapauksessa syynä siis user-requested kun itse sen katkaisin. Vertasin tätä nettiyhteyden katkeamiseen kaapelin irtikytkemisen takia. Tämän takia laitoin tietysti ensin nettiyhteyden takaisin päälle aiheuttaen seuraavat lokitapahtumat syslogiin:

Kotitehtävä, viikko 1

1. 1 Tehtävänanto

Tee ja raportoi:

  • Polta itsellesi ubuntu-romppu (tai xubuntu).
  • Boottaa liverompulta ja asenna ssh-palvelin. Luo uusi käyttäjä ja kirjaudu sillä.
  • Julkaise kotisivu haluamassasi paikassa

Kotitehtävät voi julkaista wepissä ja palauttaa pelkän linkin (suositeltavaa).

2. 2 Kotitehtävän palautus

Ihan ensimmäisenä asensin tämän WordPress -sivuston ihan vaan näiden kotitehtävien palautusta varten. Käytin WordPressiä koska olen käyttänyt sitä monesti aiemminkin. WordPressillä tekemiäni nettisivuja löytyy täältä, täältä ja täältä.

2.1. 2.1 Järjestelmän asennus

1) 2.1.1 Esivalmistelut ja käyttöympäristö

Varsinainen tehtävä olisi pitänyt aloittaa polttamalla Ubuntu CD-ROM ja boottaamalla siltä. Koska en halua buuttailla liveromppuja silloin kun haluan tehdä tehtäviä, päätin asentaa Ubuntun pelkän liverompun käyttämisen sijaan. En halunnut sotkea asennuksia ja osioita omalla koneellani enempää, joten päätin asentaa Ubuntun vanhaan tietokoneeseeni jota käytän 32″ television kautta. Koneen tiedot: AMD Athlon XP 2100+, 1gt DDR1 333mhz, 120gt Matrox 7200rpm kiintolevy, Asus A7N8X-X emolevy ja LG 52x/24x/52x polttava cd-asema. Oheislaitteina tosiaan näyttönä Sony 32″ LCD-televisio, ja käytössä Logitech S520 langaton hiiri-näppisyhdistelmä.

Verkkoympäristönä A-LINK WNAP(a) reititin, jonka WAN-portti on yhdistetty DNA Welhon tarjoamaan 100 mbit/s Ethernet-laajakaistaan. Yhdistin koneen reitittimeen reittittimeen WLAN:lla käyttäen A-Link WNU(M) – 802.11n/g/b langatonta sovitinta. WLAN on salattu WPA2-menetelmällä. Reititin on asetettu NAT-tilaan, joten käyttääkseni SSH-palvelinta lähiverkon ulkopuolelta, pitää hiukan säätää reitittimen asetuksia, mutta siitä myöhemmin lisää.

Aloitin lataamalla 32-bittisen Ubuntu 11.10 levykuvan Funetin palvelimelta osoitteesta http://ftp.funet.fi/pub/Linux/INSTALL/Ubuntu/releases/11.10/ubuntu-11.10-desktop-i386.iso. Poltin levykuvan CD-R levylle käyttäen ilmaista ImgBurner ohjelmistoa pöytäkoneellani (Windows 7).

Käytetty aikaAikaa tähän osioon kului noin 10 minuuttia.

2) 2.1.2 Linuxin asennus

Asensin Linuxin käynnistämällä tietokoneen CD-levyltä ja seuraamalla ohjeita. Ubuntussa totuttuun tapaan sekä langattomat hiiri+näppäimistö että WLAN-sovitin toimivat jo asennuksen aikana ilman ongelmia. Hiukan hölmösti asennus ehdotti langattomaan verkkoon yhdistämistä vasta sen jälkeen, kun oli jo pitänyt valita että asennetaanko uusimmat päivitykset jo asennuksen aikana, eikä kyseinen valinta tietenkään ollut mahdollinen ilman internetyhteyttä.

Kiintolevyllä oli jo valmiiksi Windows XP ja jätin varmuuden vuoksi sen sinne, jotta voin halutessani katsoa MTV3 Katsomoa (toimii heikosti Linuxilla, vaikka Silverlight löytyykin). Annoin Ubuntun asennuksen osioida kiintolevyn itse, ja se ehdotti automaattisesti että levytila jaetaan puoliksi Windowsin ja Ubuntun välillä, molemmilla on nyt siis käytössä noin 60 gigatavua tilaa.

Käyttäjätunnukseksi asetin jkw ja koneen nimeksi hauki. (Muut koneeni ovat pallokala ja ruutana :)) Koska internetyhteys oli aktiivisena jo asennuksen aikana, tunnisti Ubuntu automaattisesti aikavyöhykkeeksi Helsingin ja näppäimistöksi suomalaisen näppäimistön.