Categorie: Debian

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.

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.

SSH beveiligen

Aangezien ik de ssh-server op Arkon nu ook vanaf externe adressen wil kunnen benaderen zal ik moeten zorgen dat er geen ongewenste bezoekers binnenkomen. Nu kan ik een aantal ip-adressen opgeven vanwaar ingelogd mag worden maar ik kies voor een andere route.

Ik gebruik namelijk al een systeem met public en private keys, als ik opensshd nu aanpas dat er enkel nog ingelogd mag worden met behulp van een key dan kunnen ze proberen wat ze willen maar gaat het niet lukken.

Als eerste heb ik gisteravond de router ingesteld om de juiste poort te forwarden naar Arkon. Daardoor kan ik nu tijdens de pauze Putty instellen en de boel dichttimmeren.

Als eerste met behulp van Puttygen een rsa2 key van 2048 bits aangemaakt. Het publieke deel heb ik met nano toegevoegd aan de authorized_keys. In Putty heb ik vervolgens een profiel (Saved Session) met daarin de hostname en poort. De instellingen van het toetsenbord heb ik omgezet naar unix. Ook controleer ik op Putty probeert om de key te laden vanuit Pageant (Putty Authentication Agent)

De private key die ik aangemaakt heb met Puttygen heb ik voorzien van een (sterk) wachtwoord. Door eerst Pageant.exe op te starten kan ik daarin een key inladen waarbij ik het wachtwoord moet opgeven.

Hierna kan ik met Putty inloggen op Arkon, er wordt me om een gebruikersnaam gevraagt en Pagent doet de rest door de key te vergelijken.

login as: tecumseh 
Authenticating with public key "tecumseh.homeip.net" from agent

Nu de ssh server nog verder dichttimmeren. Door in /etc/ssh/sshd_config 2 waarden aan te passen kan er niet meer ingelogd worden met behulp van een wachtwoord:

PasswordAuthentication no 
UsePAM no

En dan nu het moment van de waarheid, het herstarten van de ssh server en kijken of ik er nog inkan.

Arkon:~# /etc/init.d/ssh restart 
Restarting OpenBSD Secure Shell server: sshd.

Vervolgens kan ik na het afsluiten van Putty nog steeds inloggen. Nu Pageant eens afsluiten en nog een keer proberen.

PuTTY Fatal Error 
Disconnected: No supported authentication methods available

Dat werkt dus prima!

Openssl in Debian en afgeleiden voorspelbaar

Aangezien recent gebleken is dat de Debian ontwikkelaars een bug ingevoegd blijken te hebben in openssl zijn de aangemaakte keys niet betrouwbaar.

Wat ik ervan begreep gebruikt openssl een variabele op een ongebruikelijke manier. De Debian ontwikkelaars hebben dat dus aangepast zonder te weten dat dit de basis is voor het aanmaken van random gegevens die een key onvoorspelbaar maken. Dat ze dit gedaan hebben komt mede doordat de code op dit punt niet gedocumenteerd was en er blijkbaar geen reactie geweest is na het submitten van deze patch naar de ontwikkelaars van openssl.

Nu gebruikt onder andere openssh deze aangemaakte keys en aangezien ik inlog met behulp van deze methode zal ik de oude keys moeten weggooien en opnieuw aanmaken. Het bijwerken van de pakketten op zowel de Debian als de Kubuntu systemen heb ik al gedaan.

Als eerste maar eens zorgen de oude keys niet meer gebruikt worden. Per machine log ik in met behulp van de key en hernoem het bestand authorized_keys. In een extra terminalvenster kan ik vervolgens op mijn machine een nieuwe key aanmaken op de vertrouwde methode. En het testen hiervan. Als dat lukt dan kan ik de hernoemde authorized_keys file gaan verwijderen.

Gelukkig heb ik slechts 4 machines waarbij ik op deze manier inlog en gebruik ik nog geen certificaten dus het blijft binnen de perken. Het schrijven van dit bericht heeft me in elk geval meer tijd gekost.

Aanpassen mailadressen op Arkon

In verband met de overstap van @home naar concepts ICT verdwijnt binnenkort mijn mailadres bij @home. Ik zal dus op Arkon een aantal dingen moeten aanpassen zodat ik nog steeds op de hoogte gehouden wordt over de stand van zaken op mijn systeem.

Nu krijg ik regelmatig mailtjes over 2 dingen. De 1e is het update script wat dagelijks gedraaid wordt, in dit script zit ook het mail commando en het mailadres dus dat levert geen zoektocht op.

Wat wel zoekwerk geeft is het backupscript wat me bij het falen een mailtje stuurt. Ik krijg namelijk dagelijks nog een mailtje met de volgende inhoud:

tar: Removing leading `/' from member names

Dit mailtje is afkomstig van de crondaemon. De foutmelding hoor ik trouwens netjes af te vangen zodat ik enkel mail krijg bij het falen van de backup. Staat nog op mijn todo lijstje.

Cron heb ik niet geconfigureerd met een MAILTO adres. Dit mailtje vindt zijn oorsprong dus elders. Maar eens kijken wat postfix als configuratie heeft. In het bestand aliases vindt ik waarschijnlijk de hoofdschuldige. Alle mail gericht aan de root user wordt automagisch doorgestuurd naar mijn @home adres. Even aanpassen en postfix herstarten en dan hoort het voor elkaar te zijn.

Lighttpd staakt (2)

Zowel gisteren als vandaag begon de webserver weer kuren te vertonen. Na het updaten van een aantal posts op dit blog kreeg ik geen reactie meer terug. Dus toch maar weer eens de logbestanden nageplozen. Vreemd genoeg is er niets te vinden wat een probleem zou kunnen geven.

Als laatste redmiddel dan toch maar een mailtje gewaagd aan Henk van de Kamer, ik heb tenslotte van hem afgekeken hoe ik de server opzetten kan.

Gelukkig tref ik het want ik heb dezelfde avond nog een mailtje terug ontvangen. Henk was dus beschikbaar en hij had een oplossing voor me. Hij heeft hetzelfde probleem namelijk al eens eerder ondervonden. En aangezien ik zijn configuratie bestanden overgenomen en dus ook zijn achteraf gezien wat ongelukkig instelling:

http://www.hetlab.tk/asterix/tunen-webserver

Wat hier dus gebeurt is dat bij sommige handelingen er door php teveel tijd besteed wordt. Doordat er maar maximaal 1 proces mag zijn volgens de configuratie kom je in de problemen als dit proces ermee ophoud door geheugenproblemen. Door dus het maximale aantal processen te verhogen voorkom je dat de server in  staking gaat.

Na het aanpassen van het php configuratiebestand en het herstarten van lighttpd draait de webserver deze keer hoogstwaarschijnlijk een stuk langer.

Bedankt Henk!

Dovecot update

Zo moet je ruim een week wachten om je update script te testen en zo krijg je er meteen een paar extra voor je kiezen:

Arkon wil update
Date: Today 07:00:19

dovecot-common dovecot-imapd

Meteen maar installeren dus:

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:
  dovecot-common dovecot-imapd
2 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 1680kB of archives. After unpacking 20.5kB will be used.
Do you want to continue? [Y/n/?] y
Get:1 http://security.debian.org etch/updates/main dovecot-common 1.0.rc15-2etch4 [1133kB]
Get:2 http://security.debian.org etch/updates/main dovecot-imapd 1.0.rc15-2etch4 [547kB]
Fetched 1680kB in 3s (437kB/s)
debconf: delaying package configuration, since apt-utils is not installed
(Reading database ... 15696 files and directories currently installed.)
Preparing to replace dovecot-common 1.0.rc15-2etch3 (using .../dovecot-common_1.0.rc15-2etch4_i386.deb) ...
Stopping mail server: dovecot .
Unpacking replacement dovecot-common ...
Preparing to replace dovecot-imapd 1.0.rc15-2etch3 (using .../dovecot-imapd_1.0.rc15-2etch4_i386.deb) ...
Stopping mail server: dovecot .
Unpacking replacement dovecot-imapd ...
Setting up dovecot-common (1.0.rc15-2etch4) ...

Configuration file `/etc/dovecot/dovecot.conf'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : background this process to examine the situation
 The default action is to keep your current version.
*** dovecot.conf (Y/I/N/O/D/Z) [default=N] ?
You already have ssl certs for dovecot.
Starting mail server: dovecot.

Setting up dovecot-imapd (1.0.rc15-2etch4) ...
Starting mail server: dovecot.

Nog meer updates, lighttpd

Wederom staat er een update voor lighttpd klaar. Hopelijk lost dit meteen het niet reageren van de website op.

Arkon wil update
From: root
To: anywhere@localhost.net
Date: Today 07:00:22
lighttpd
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:
lighttpd
1 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 289kB of archives. After unpacking 0B will be used.
Do you want to continue? [Y/n/?] y
Get:1 http://security.debian.org etch/updates/main lighttpd 1.4.13-4etch6 [289kB]
Fetched 289kB in 1s (247kB/s)
debconf: delaying package configuration, since apt-utils is not installed
(Reading database ... 15696 files and directories currently installed.)
Preparing to replace lighttpd 1.4.13-4etch5 (using .../lighttpd_1.4.13-4etch6_i386.deb) ...
Stopping web server: lighttpd.
Unpacking replacement lighttpd ...
Setting up lighttpd (1.4.13-4etch6) ...
Starting web server: lighttpd.

Lighttpd staakt

Op de een of andere manier is me vanmorgen na het plaatsen van het update bericht lighttpd aan het staken geslagen. Totaal geen reactie meer.

Voor zover ik kan zien draait ie echter wel gewoon:

Arkon:~# ps -e | grep light
19975 ?        00:00:02 lighttpd

Zometeen de logs dus maar eens doorspitten om te kijken of ik daar nog iets in kan vinden. Met het volgende commando herstellen we de zaak weer:

Arkon:~# /etc/init.d/lighttpd restart
Stopping web server: lighttpd.
Starting web server: lighttpd.
Arkon:~# ps -e | grep light
29021 ?        00:00:00 lighttpd

Toevoeging 07-03-2008 om 20:08

Blijkbaar heb ik last gehad van een conflict tussen Lighttpd en aptitude. Na het posten of bewerken van een bericht bleef de webserver stil. Het process bleef lopen en ik kan in de logs niets vinden. Na het uitvoeren van de update reageert de webserver echter weer zoals het hoort.