Awstats logging

Nu draait dit blog al wel een paar maanden maar nog steeds heb ik de statistieken niet voor elkaar. Het wordt hoog tijd om daar verandering in aan te brengen. De keuze is voor mij gevallen op AWStats. Deels omdat ik hier in mijn Freesco verleden al mee gewerkt heb. Deze keer ga ik het echter niet als actieve CGI pagina installeren, de statistieken moeten dagelijks in de nachtelijke uren geupdate gaan worden waarna de statische pagina’s beschikbaar komen op de webserver.

Als eerste Awstats en de geoip plugin installeren vanuit de Debian archieven:

Arkon:~# aptitude install awstats libgeo-ipfree-perl

De configuratie heb ik in de eerste instantie vrij grof gedaan. Simpelweg de basisconfiguratie geconfigureerd naar een apart bestand voor dit domein, dat werdt dus awstats.tecumseh.homeip.net.conf. Hierin de juiste variabelen aanpassen en kijken of ik een statische pagina aanmaken kan.

Ik kom er achter dat de bestanden niet allemaal op dezelfde plek staat. Eerst dus maar zorgen dat het script om de statische pagina’s te maken op dezelfde plaats aangeroepen kan worden als het hoofdscript van awstats:

Arkon:/usr/lib/cgi-bin# ln -s /usr/share/doc/awstats/examples/awstats_buildstaticpages.pl awstats_buildstaticpages.pl

Hierna kan ik een update uitvoeren en een set statische pagina’s aanmaken, dit moet straks vanuit een bash script gedaan worden:

Arkon:~$ /usr/lib/cgi-bin/awstats.pl -config=tecumseh.homeip.net -update
Arkon:~$ /usr/lib/cgi-bin/awstats_buildstaticpages.pl -awstatsprog=/usr/lib/cgi-bin/awstats.pl -config=tecumseh.homeip.net -year=2008 -month=06 -dir=~/awstats/200806

Dit werkt in elk geval, ik krijg statistieken maar het is allemaal wel heel kaal. De icoontjes worden niet gevonden. Deze dus maar aanmaken via een symlink:

Arkon:~/tecumseh.homeip.net/awstats$ ln -s /usr/share/awstats/icon/ icon

Zorg er trouwens wel voor dat de locatie van de icoontjes in de configuratiebestanden aangepast wordt naar deze locatie.

Nu nog even een opschoning doen in het configuratiebestand. Ik wil hier niets meer in hebben staat wat ook in een algemeen configuratiebestand kan staan. We kopieren awstats.conf dus naar awstats.conf.local, hiermee zorgen we ervoor dat er bij een update van het pakket de originele configuratie niet verloren gaat. In dit bestand commenten we een aantal regels die we per domein apart in willen stellen, die regels laten we dus terugkomen in aparte configuratiebestanden:

LogFile="/var/log/lighttpd/access.log"
SiteDomain="tecumseh.homeip.net"
DirData="/var/lib/awstats"
DefaultFile="index.php"
SkipFiles="REGEX[^\/phpmyadmin] REGEX[^\/postfixadmin]"
NotPageList="css js class gif jpg jpeg png bmp ico swf"
MiscTrackerUrl="/js/awstats_misc_tracker.js"
DetailedReportsOnNewWindows=0
LoadPlugin="geoipfree"
Include "/etc/awstats/awstats.conf.local"

Als we nu de statistieken opnieuw aanmaken dan krijgen we ineens de volgende regel bovenaan de pagina te staan:

Warning: Perl versions before 5.6 cannot handle nested includes

Na lang zoeken kwam ik erachter dat ik een fout gemaakt heb in de configuratiebestanden. Het probleem bleek te zitten in awstats.conf.local, deze verwees namelijk naar zichzelf in de laatste regel aangezien dit een kopie is van awstats.conf, door deze regel te commenten verdwijnt de foutmelding.

Nu kunnen we de domeinconfiguratiebestanden copieren en per domein aanpassen.

Als ik vervolgens bij een domein wat ik tot nu toe enkel nog voor testdoeleinden gebruikt heb de statistieken bekijk dan zijn die verdacht gelijk aan mijn hoofdaccount. Ik kan me niet voorstellen dat dit de bedoeling is.

Ik heb namelijk LogFormat op 1 staan, wat de volgende zoekstring opleverd:

# LogFormat = "%host %other %logname %time1 %methodurl %code %bytesd %refererquot %uaquot"

Het 2e veld %other is echter de naam van de virtualhost, als ik het format verander naar:

LogFormat = "%host %virtualname %logname %time1 %methodurl %code %bytesd %refererquot %uaquot"

Dan krijg ik de statistieken wel bij de site waar ze thuishoren.

Er staat nog wel het een en ander op het programma, dit is nog verre van volmaakt.

  • Logrotate aanpassen waardoor ik logbestanden per maand heb.
  • Script maken voor automatische verwerking
  • Statistieken in de site verwerken, deze site publiek en de overige achter een wachtwoord
  • Extra statistieken actief maken door het gebruik te maken van awstats_misc_tracker.js

Nu heb ik voor bovenstaande items wel wat leesvoer gevonden, dit is echter op apache geschreven en ik heb een lighttpd server.

Wordt vervolgt dus.

Snelheidstest glasvezel

Ik heb het in diverse posts al gehad over de snelheid van mijn glasvezelverbinding. Nu is er nog geen test uitgevoerd die voldoende data gebruikt heeft om betrouwbare resultaten te geven. In het laatste glasvezel topic bied Henk aan om een Strato testserver te mogen gebruiken om mijn snelheid op wetenschappelijke wijze te bepalen.

Voor het wetenschappelijke verhaal heb ik een stukje in de mail gekregen van Henk:

> Ik wil dus nog uitzoeken of je met behulp van een script
> snelheidswaarde’s kunt meten op meerdere momenten tijdens een grote
> upload. Ik ga daarbij aannemen dat de 1e 20% van een upload niet
> representatief is. Wellicht heb jij daar nog ideeën over.

Dit klinkt heel goed. Alleen gaat die handshake en window scaling vrij snel, ofwel de eerste 20% gaat wat ver. Zelf neem ik altijd een bestand dat minimaal een minuut kost. Je moet namelijk aannemen dat de gemeten tijdsduur ± 1 seconde is. Ofwel als jij 120 MiB weet te uploaden in een minuut kom je uit op:

120 / 59 = 2,03
120 / 61 = 1,97

Je ziet dat allebei afgerond kan worden op 2,0 MiB/s ofwel één cijfer achter de komma en dat is goed genoeg voor dit soort testen.

Als je snelheid een heel stuk meer is, wordt één minuut mogelijk al te weinig:

240 / 59 = 4,07
240 / 61 = 3,93

Kortom je moet dus zoveel data gebruiken dat met de gevonden tijd een nauwkeurig uitspraak is te doen…

Aangezien mijn theoretische snelheid op 35 mbit zit volgens Concepts ICT heb ik een snelheid van:

35 / 8 = 4,375 MiB/s

Een test die een duur heeft tussen de 1,5 en 2 minuten heeft dus een bestand nodig van minimaal 393,75 MiB (90 * 4,375) en maximaal 525 MiB (120 * 4,375). Aangezien het TCP/IP protocol een verlies van zo’n 10% heeft neem ik de laagste waarde en rond die iets naar boven af en zo kom ik uit op een testbestand van 400 MiB. Deze maak ik dan ook aan:

Arkon:~/test# dd if=/dev/zero of=400MB.test bs=1M count=400
400+0 records in
400+0 records out
419430400 bytes (419 MB) copied, 28.3245 seconds, 14.8 MB/s

Om zeker te zijn dat mijn machine’s de test wel volledig uit kunnen voeren zal ik de test eerst uitvoeren tussen mijn server Arkon en mijn werkstation. Als ik daarmee niet boven de 4,5 MiB/s uitkom dan heeft het verder testen geeneens nut.

Voor het testen maak ik gebruik van een bash script. Na lang zoeken heb ik er een gevonden, zo’n ster ben ik nog niet in het zelf bedenken van scripts. Wel heb ik hierin ondertussen de sed regel gecomment en uiteraard de variabelen aangepast. Er werdt me wel heel veel weggelaten, zoals bijvoorbeeld de snelheid. En daar gaat het uiteindelijk om.

***FTP SERVER UPLOAD SPEED***

220---------- Welcome to Pure-FTPd [privsep] [TLS] ----------
Using binary mode to transfer files.
331 User tecumseh OK. Password required
200 TYPE is now 8-bit binary
local: 400MB.test remote: 400MB.test
226-File successfully transferred
226 39.745 seconds (measured here), 10.06 Mbytes per second
419430400 bytes sent in 39.73 secs (10308.5 kB/s)
221 Logout.

***FTP SERVER DOWNLOAD SPEED***

220---------- Welcome to Pure-FTPd [privsep] [TLS] ----------
Using binary mode to transfer files.
331 User tecumseh OK. Password required
200 TYPE is now 8-bit binary
local: 400MB.test remote: 400MB.test
226-File successfully transferred
226 48.714 seconds (measured here), 8.21 Mbytes per second
419430400 bytes received in 48.21 secs (8495.7 kB/s)
221 Logout.

Ruim 10 MiB/s voor de upload en ruim 8 MiB/s voor de download. Dit ligt ruim 2x boven de hierboven genoemde theoretische snelheid van mijn verbinding. De systemen hier kunnen het dus aan.

MySQL Backup

Ik loop al een tijdje achter met het automatisch correct afhandelen van de backup. Ik heb wel een backup script draaiende maar die functioneerd nog niet naar wens. Eigenlijk wil ik namelijk een dagelijkse, wekelijkse en maandelijkse backup hebben van elke database apart. Het liefst ook nog met de mogelijkheid om de backup extern op te slaan.

Aangezien ik nog maar net begin met het schrijven van bash-scripts ben ik dus een zoektocht begonnen. En daarmee is meteen de kans een stuk groter dat je een script vindt dat heel dicht bij je wensen in de buurt komt. En dat is Automatic MySQL Backup geworden.

Als eerste nog even een aparte database user aanmaken die enkel select rechten heeft:

CREATE USER 'mysqlbackupuser'@'localhost' IDENTIFIED BY '************';

GRANT SELECT ON * . *
TO 'mysqlbackupuser'@'localhost'
IDENTIFIED BY '************'

De rest van de instellingen spreken voor zich, ik heb er even over zitten te denken om me elke keer de backupfiles toe te laten zenden per mail. De meest logische mailbox is dan gmail in verband met het extern opslaan. Bij nader inzien doe ik dat maar niet, je weet nooit wat google ermee zou willen en kunnen doen.

Voor het wegzetten van de backup moet ik dus nog iets anders gaan doen, hiervoor kan ik een apart script gaan gebruiken die ik in dit script aanroep:

# Command to run before backups (uncomment to use)
#PREBACKUP="/etc/mysql-backup-pre"

# Command run after backups (uncomment to use)
#POSTBACKUP="/etc/mysql-backup-post"

Ik zit er dus aan te denken om het backuppen van de gegevens op schijf (/var/www, /etc, /home) in het pre script uit te voeren en om het wegzetten van de data naar een externe locatie in het post script te verwerken.

Na een testrun zie ik dat ik de database-user nog iets meer rechten moet geven. Lock-tables is ook wel handig zodat je geen conflicterende backup krijgt:

REVOKE ALL PRIVILEGES ON * . * FROM 'mysqlbackupuser'@'localhost';

REVOKE GRANT OPTION ON * . * FROM 'mysqlbackupuser'@'localhost';

GRANT SELECT ,
LOCK TABLES ON * . *
TO 'mysqlbackupuser'@'localhost';

Hierna krijg ik na een tweede test netjes een berichtje in mijn mailbox wat me de resultaten verteld:

======================================================================
AutoMySQLBackup VER 2.5
http://sourceforge.net/projects/automysqlbackup/

Backup of Database Server - Arkon
======================================================================
Backup Start Time Fri Jun 6 13:59:17 CEST 2008
======================================================================
Daily Backup of Database ( information_schema )
Rotating last weeks Backup...

Backup Information for
/backup/mysql/daily/information_schema/information_schema_2008-06-06_13h59m.Friday.sql
         compressed        uncompressed  ratio uncompressed_name
                479                1241  66.7%
/backup/mysql/daily/information_schema/information_schema_2008-06-06_13h59m.Friday.sql
----------------------------------------------------------------------
Daily Backup of Database ( database1 )
Rotating last weeks Backup...

Backup Information for
/backup/mysql/daily/database1/database1_2008-06-06_13h59m.Friday.sql
         compressed        uncompressed  ratio uncompressed_name
             130792              669262  80.5%
/backup/mysql/daily/database1/database1_2008-06-06_13h59m.Friday.sql
----------------------------------------------------------------------
Daily Backup of Database ( database2 )
Rotating last weeks Backup...

Backup Information for
/backup/mysql/daily/database2/database2_2008-06-06_13h59m.Friday.sql
         compressed        uncompressed  ratio uncompressed_name
              43350              167174  74.1%
/backup/mysql/daily/database2/database2_2008-06-06_13h59m.Friday.sql
----------------------------------------------------------------------
Daily Backup of Database ( database3 )
Rotating last weeks Backup...

Backup Information for /backup/mysql/daily/database3/database3_2008-06-06_13h59m.Friday.sql
         compressed        uncompressed  ratio uncompressed_name
               1685                8489  80.8%
/backup/mysql/daily/database3/database3_2008-06-06_13h59m.Friday.sql
----------------------------------------------------------------------
Daily Backup of Database ( mysql )
Rotating last weeks Backup...

Backup Information for /backup/mysql/daily/mysql/mysql_2008-06-06_13h59m.Friday.sql
         compressed        uncompressed  ratio uncompressed_name
              95645              315867  69.7%
/backup/mysql/daily/mysql/mysql_2008-06-06_13h59m.Friday.sql
----------------------------------------------------------------------
Daily Backup of Database ( database4 )
Rotating last weeks Backup...

Backup Information for
/backup/mysql/daily/database4/database4_2008-06-06_13h59m.Friday.sql
         compressed        uncompressed  ratio uncompressed_name
               1014                2595  63.1%
/backup/mysql/daily/database4/database4_2008-06-06_13h59m.Friday.sql
----------------------------------------------------------------------
Daily Backup of Database ( database5 )
Rotating last weeks Backup...

Backup Information for
/backup/mysql/daily/database5/database5_2008-06-06_13h59m.Friday.sql
         compressed        uncompressed  ratio uncompressed_name
             141987              652025  78.2%
/backup/mysql/daily/database5/database5_2008-06-06_13h59m.Friday.sql
----------------------------------------------------------------------
Backup End Fri Jun 6 13:59:22 CEST 2008
======================================================================
Total disk space used for backup storage..
Size - Location
944K /backup/mysql

Ik heb in dit overzicht overigens wat bestands- en databasenamen verandert.

Nu nog even dit script in de crontab zetten en dan is ook dat weer geregeld.

ssh automatisch inloggen (2)

In een eerder bericht heb ik al gezorgd dat ik met behulp van een private key kan inloggen op verschillende servers. Ook heb ik toen een aantal alliassen aangemaakt zodat ik niet zoveel typewerk heb. Dat kan echter nog makkelijker omdat openssh daarin al voorziet in de configfiles. Je kan namelijk een naam geven aan een host en daarbij de parameters opgeven die je normaal op de commandline meegeeft. Hier kun je behoorlijk wat mee doen. Er zijn 2 mogelijke bestanden die je kunt aanpassen/bewerken. Een globale (/etc/ssh/ssh_config) of een userspecifieke (~/.ssh/config). Ik neem de laatste om mijn gegevens in te zetten, niet omdat er meerdere gebruikers zijn op mijn werksysteem maar het lijkt me wel de juiste manier.

Een mogelijke configfile:

host=host1
user=root
hostname=10.0.0.1
identityfile=~/.ssh/host1

Vervolgens kan ik inloggen met het commando ssh host1.

Je kunt trouwens elke variabele die je het commando ssh kunt geven in de configfile stoppen. Een afwijkende poort of iets dergelijks is dus ook geen probleem. Voor een overzicht zie de man-pagina

Het Lab backports

Aangezien ik bezig ben om in WordPress een gallery toe te voegen heb ik de php gd library nodig. Als ik die probeer te installeren dan schrik ik echter van de dependency’s:

Arkon:~# aptitude install php5-gd
Reading package lists... Done
Building dependency tree... Done
Reading extended state information
Initializing package states... Done
Writing extended state information... Done
Building tag database... Done
The following NEW packages will be automatically installed:
  defoma file fontconfig-config libexpat1 libfontconfig1 libfreetype6
  libft-perl libgd2-xpm libjpeg62 libpng12-0 libt1-5 libttf2 libx11-6
  libx11-data libxau6 libxdmcp6 libxpm4 ttf-dejavu x11-common
The following packages have been kept back:
  linux-image-2.6.18-6-486
The following NEW packages will be installed:
  defoma file fontconfig-config libexpat1 libfontconfig1 libfreetype6
  libft-perl libgd2-xpm libjpeg62 libpng12-0 libt1-5 libttf2 libx11-6
  libx11-data libxau6 libxdmcp6 libxpm4 php5-gd ttf-dejavu x11-common
0 packages upgraded, 20 newly installed, 0 to remove and 1 not upgraded.
Need to get 6345kB of archives. After unpacking 15.0MB will be used.
Do you want to continue? [Y/n/?] n
Abort.

Ik heb dus blijkbaar X-Windows nodig op mijn server, enkel en alleen om de webserver een plaatje te kunnen laten bewerken. Dat moet ook anders kunnen. Voor de oplettenden, er staat inderdaad ook een kernel upgrade tussen die nog uitgevoerd moet worden. Ik had het mailtje daarover al gehad.

Om een uitgeklede php5 versie te installeren kan ik op zoek gaan naar iemand die dat al gedaan heeft en dan moet ik die persoon nog vertrouwen. Gelukkig heeft Henk van de Kamer dit gedaan en vertrouw ik hem al, anders had ik niet gebruik gemaakt van zijn handleidingen voor de installatie en de bijbehorende configuratiebestanden. Als eerste even het toevoegen van zijn server aan de sources.list:

deb http://backports.armorica.tk/ etch php5

En vervolgens nog zorgen dat apt die sources vertrouwd:

Arkon:~# nano /etc/apt/sources.list
Arkon:~# wget http://backports.armorica.tk/backports.gpg
--23:43:38--  http://backports.armorica.tk/backports.gpg
           => `backports.gpg'
Resolving backports.armorica.tk... 88.198.41.48
Connecting to backports.armorica.tk|88.198.41.48|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1,336 (1.3K) [application/octet-stream]

100%[====================================>] 1,336         --.--K/s

23:43:58 (15.30 MB/s) - `backports.gpg' saved [1336/1336]

Arkon:~# apt-key add backports.gpg
OK
Arkon:~# aptitude update
Get:1 http://ftp.nl.debian.org etch Release.gpg [378B]
Hit http://ftp.nl.debian.org etch Release
Get:2 http://backports.armorica.tk etch Release.gpg [189B]
Get:3 http://backports.armorica.tk etch Release [6848B]
Get:4 http://security.debian.org etch/updates Release.gpg [189B]
Get:5 http://security.debian.org etch/updates Release [37.6kB]
Ign http://ftp.nl.debian.org etch/main Packages/DiffIndex
Hit http://ftp.nl.debian.org etch/main Packages
Get:6 http://backports.armorica.tk etch/php5 Packages [8161B]
Ign http://security.debian.org etch/updates/main Packages/DiffIndex
Hit http://security.debian.org etch/updates/main Packages
Fetched 53.3kB in 21s (2524B/s)
Reading package lists... Done

Hierna voer ik een upgrade uit om alle debian pakketten voor php5 te vervangen door zijn versie’s. Hier komt ook meteen de kernel upgrade mee:

Arkon:~# aptitude upgrade
Reading package lists... Done
Building dependency tree... Done
Reading extended state information
Initializing package states... Done
Building tag database... Done
The following packages will be upgraded:
  linux-image-2.6.18-6-486 php5-cgi php5-common php5-mysql
4 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 21.2MB of archives. After unpacking 0B will be used.
Do you want to continue? [Y/n/?] y

Na het toevoegen van de backports van Henk van de Kamer in mijn sources.list ziet de installatie er een stuk prettiger uit:

Arkon:~# aptitude install php5-gd
Reading package lists... Done
Building dependency tree... Done
Reading extended state information
Initializing package states... Done
Building tag database... Done
The following NEW packages will be automatically installed:
  libfreetype6 libgd2-noxpm libjpeg62 libpng12-0
The following NEW packages will be installed:
  libfreetype6 libgd2-noxpm libjpeg62 libpng12-0 php5-gd
0 packages upgraded, 5 newly installed, 0 to remove and 0 not upgraded.
Need to get 841kB of archives. After unpacking 1982kB will be used.
Do you want to continue? [Y/n/?] y

Toch geen X11 nodig 😀

Nog even de webserver herstarten en we kunnen gebruik maken van de nieuwe library:

Arkon:~# /etc/init.d/lighttpd restart
Stopping web server: lighttpd.
Starting web server: lighttpd.

Helaas moet ik vanwege de kernel update wel even het systeem rebooten. Ik raak dus mijn mooie uptime kwijt:

Arkon:~# uptime
 00:00:49 up 96 days, 11:03,  1 user,  load average: 0.08, 0.24, 0.25

Update taalbestand wordpress

Nu heb ik laatst met succes een update doorgevoerd voor WordPress, helaas worden er geen taalbestanden meegeleverd met dit pakket. Die moeten handmatig toegevoegd worden waardoor je de kans loopt om ze te vergeten. Ik heb dat vandaag maar even rechtgezet.

Aangezien het slechts om 1 bestand gaat heb ik geen diff gedraaid, deze kan ik simpelweg vervangen.

Arkon:~/tecumseh.homeip.net/wp-includes/languages$ mv nl_NL.mo nl_NL.mo.bak
Arkon:~/tecumseh.homeip.net/wp-includes/languages$ wget http://svn.automattic.com/wordpress-i18n/nl/branches/2.5/nl_NL.mo

Nu heb ik ook eindelijk het dashboard van wordpress in het nederlands en niet het halve engels/nederlands wat ik vlak na de upgrade voorgeschoteld kreeg.

Nog even het verwijderen van de oude versie, de nieuwe werkt per slot van rekening:

Arkon:~/tecumseh.homeip.net/wp-includes/languages$ rm nl_NL.mo.bak

Aanpassen mailadressen op Arkon (2)

Nog steeds krijg ik mail op mijn @home adres, deze gaat echter per 1 juni niet meer werken. Ik zal dus nogmaals de configuratie na moeten lopen.

Ik heb de vorige keer in /etc/postfix het bestand aliases aangepast en daarin alle mailadressen verandert naar mijn concepts mailadres. Dit heeft blijkbaar dus niet gewerkt. Nu zie ik ook een ander bestand genaamd aliases.db en een google zoektocht levert me de oplossing op. Ik moet namelijk de database met aliasen nog updaten:

Arkon:/etc/postfix# postalias aliases

Nog even testen:

Arkon:/etc/postfix# mail root
Subject: test mail
Cc:
Null message body; hope that's ok

En even later verschijnt er een mailtje in de juiste mailbox.

Sitemap

Een blog is leuk, maar als er maar weinig mensen langskomen om het te lezen dan is het niet meer dan een dagboek wat je eigenlijk ook offline bij kunt houden. Het is dus handig als je gevonden kunt worden met de zoekmachines. Hiervoor heb ik eigenlijk al een tijd geleden iets mee willen doen en vandaag is het er dan van gekomen. Ik kwam namelijk een plugin tegen die dit automatisch al regelt. Het gaat om de Google Sitemap Generator, hiermee wordt de sitemap.xml aangemaakt en de zoekmachines worden van een update op de hoogte gesteld.

Het installeren is vrij simpel, pak het gedownloade zip bestand uit in de plugins directory en maak een 2-tal lege bestanden aan in de root van je site:

Arkon:~/tecumseh.homeip.net$ touch sitemap.xml
Arkon:~/tecumseh.homeip.net$ touch sitemap.xml.gz
Arkon:~/tecumseh.homeip.net$ chmod 666 sitemap.xml sitemap.xml.gz
Arkon:~/tecumseh.homeip.net$ cd ../archives
Arkon:~/archives$ wget http://downloads.wordpress.org/plugin/google-sitemap-generator.3.0.3.3.zip
Arkon:~/archives$ unzip google-sitemap-generator.3.0.3.3.zip
Arkon:~/archives$ mv google-sitemap-generator ../tecumseh.homeip.net/wp-content/plugins/

Hierna kun je in het WordPress control panel de plugin activeren. De 1e keer zal de sitemap handmatig bijgewerkt moeten worden. Daarna zal bij elke post een update gestart worden die in de achtergrond draait.

Voordat ik dit post is dit de laatste update volgens het controlpanel:

Your sitemap was last built on 21 May 2008 5:52 pm

Een minuut na het posten kom ik deze tijd tegen:

Your sitemap was last built on 21 May 2008 7:51 pm.

Het automagische gedeelte klopt dus inderdaad.

WordPress updaten (2)

Nu we de testomgeving klaar hebben staan kan er begonnen worden met het update proces. Uiteraard doen we dat niet op de manier die WordPress zelf voor ogen heeft. Simpelweg alles overschrijven inclusief de aanpassingen die je eventueel gedaan hebt is niet helemaal de juiste manier.

Als eerste halen we de laatste versie op en hernoemen die. Vervolgens pakken we de originele versie en de laatste versie uit in de archives directory:

Arkon:~/archives$ wget http://wordpress.org/latest.tar.gz
Arkon:~/archives$ mv latest.tar.gz wordpress_2.5.1.tar.gz
Arkon:~/archives$ tar -xzf wordpress_2.3.3.tar.gz
Arkon:~/archives$ mv wordpress wordpress_233
Arkon:~/archives$ tar -xzf wordpress_2.5.1.tar.gz
Arkon:~/archives$ mv wordpress wordpress_251

Vervolgens gaan we met diff een patchbestand aanmaken:

Arkon:~/archives$ diff -crN wordpress_233/ wordpress_251/ > wp233-251.patch

Met dit patchbestand kan ik vervolgens de testinstallatie van wordpress gaan updaten:

Arkon:~/test.homeip.net$ patch -cl -d ./ -p1 < /home/tecumseh/archives/wp233-251.patch

Ik kom meteen al een foutmelding tegen:

can't find file to patch at input line 4
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff -crN wordpress_233/license.txt wordpress_251/license.txt
|*** wordpress_233/license.txt Tue Apr 1 16:12:34 2003
|--- wordpress_251/license.txt Sun Mar 2 22:34:25 2008
--------------------------
File to patch:

Nu staat me inderdaad bij dat ik de license.txt verwijdert heb, en bestanden die niet bestaan zijn wat lastig te updaten. Na een enter verschijnt de vraag of ik deze patch wil overslaan. Zo volgen er nog een paar want de readme en de installatiedirectory zijn niet meer aanwezig.

Na het patchen bekijken we de boel eens in de browser. Na het inloggen krijg ik de melding dat de database een opfrissing nodig heeft, ik geef hierop akkoord waarna de database aangepast wordt. Hiermee is de update ook helemaal klaar.

Na wat rondkijken in de testomgeving kan ik in elk geval concluderen dat ik al mijn posts nog heb en dat in elk geval het meest voor de hand liggende werkt. Ik kan dit dus ook doorvoeren op de live omgeving. De backup houd ik nog even achter de hand voor het geval dit helemaal misloopt.

WordPress updaten

Ik loop al even achter met het updaten van WordPress. Dit is mede omdat het gaat om een major versie (2.3.3 naar 2.5.0, nu zelfs 2.5.1). Dit wil ik dus eerst wel even testen voordat ik dit live ga toepassen.

Dus eerst maar eens een extra domeinnaam aangevraagd bij DynDNS en de juiste directory en symlinks aanmaken zodat lighttpd weet waar die de website vandaan halen moet.

Nu het kopieren van alle bestanden die ik onder de root heb staan.

Arkon:/var/www/homeip.net/tecumseh# cp -R * ../test

Vervolgens het maken van een sql dump:

Arkon:~# mysqldump --databases wordpress -p > wordpress.sql

In deze sql file moet ik nog alle verwijzingen naar de wordpress database veranderen in de databasenaam die ik voor deze test gereserveerd heb. Ik heb dit met nano gedaan hoewel ik weet dat er snellere manieren voor zijn, die zijn voor de oningewijden echter wat lastiger.

Vervolgens in phpmyadmin de database en gebruiker aanmaken en het aangemaakte sql bestand inladen.

Arkon:~# mysql -p test < wordpress.sql

Nog even het configfile van wordpress aanpassen naar de nieuwe database en gebruiker.

Als het goed is dan kan ik dus nu via de dyndns alias naar de backupsite browsen. Helaas wordt ik direct naar deze site teruggestuurd. Blijkbaar regelt wordpress dit en zal ik dus in de database een aantal verwijzingen naar de url moeten aanpassen. Na deze aanpassingen kan ik eindelijk van start met de update.