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.

Flash en consorten

Helaas ontkom je er niet meer aan, als je wat zoekt op het internet dan heb je een flashplayer nodig bij steeds meer website’s. Wat het nog frusterender maakt is dat er geen 64-bits linux versie van beschikbaar is. Je hebt dus naast de flashplayer ook een aantal 32-bits bibliotheken nodig om het geheel in 32-bits te kunnen draaien. Gelukkig gaat dat onder (K)Ubuntu tegenwoordig vrij makkelijk:

tecumseh@Athlan:~$ sudo apt-get install kubuntu-restricted-extras
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
  flashplugin-nonfree ia32-libs icedtea-gcjwebplugin lib32asound2 lib32gcc1
  lib32ncurses5 lib32stdc++6 lib32z1 libavformat1d libc6-i386 libdc1394-13
  libk3b2-extracodecs libtunepimp5-mp3 nspluginwrapper
Suggested packages:
  firefox firefox-3.0 libflashsupport ttf-xfree86-nonfree xfs xulrunner-1.9
  libasound2-plugins libtunepimp-bin libtunepimp5-dev
Recommended packages:
  lib32nss-mdns
The following NEW packages will be installed:
  flashplugin-nonfree ia32-libs icedtea-gcjwebplugin kubuntu-restricted-extras
  lib32asound2 lib32gcc1 lib32ncurses5 lib32stdc++6 lib32z1 libavformat1d
  libc6-i386 libdc1394-13 libk3b2-extracodecs libtunepimp5-mp3 nspluginwrapper
0 upgraded, 15 newly installed, 0 to remove and 0 not upgraded.
Need to get 26.2MB of archives.
After this operation, 115MB of additional disk space will be used.
Do you want to continue [Y/n]? y

Mocht je Ubuntu gebruiken dan zul je trouwens het pakket ubuntu-restricted-extras

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!

Virtualbox (3)

Nu we usb op de rit hebben wil ik eigenlijk ook wel wat geluid horen vanuit Windows XP. Wat ik in Windows XP ook verander, het heeft geen effect. Zal er dan een instelling te doen zijn aan de kant van Virtualbox?

Inderdaad, als ik de host driver verander van Null Audio Driver naar OSS Audio Driver dan werkt alles ineens wel. Eigenlijk ook wel logisch als je naar de oorspronkelijke waarde kijkt…

Andere mogelijkheden waren trouwens ALSA en Pulseaudio

Virtualbox (2)

Blijkbaar is de aanpassing in Kubuntu om USB werkend te krijgen niet voldoende geweest. Ik kan namelijk in Windows XP geen USB apparaten actief zetten. Maar eens kijken of we kunnen vinden waar het probleem zit. Via het irc kanaal waar de supporters van virtualbox zitten kom ik iets verder:

tecumseh@Athlan:~$ VBoxManage list usbhost
VirtualBox Command Line Management Interface Version 1.6.0
(C) 2005-2008 Sun Microsystems, Inc.
All rights reserved.

Host USB Devices:

UUID:               9aa0fa6c-86f4-4386-0baf-44f5980bbf5b
VendorId:           0x046d (046D)
ProductId:          0x08a2 (08A2)
Revision:           1.0 (0100)
Address:            /proc/bus/usb/002/003
Current State:      Unavailable

Ik heb het lijstje iets ingekort, er werden namelijk 4 aangesloten apparaten aangetroffen. Allemaal hadden ze als “Current State” Unavailable staan.

Ik had toch echt het bestand /etc/init.d/mountdevsubfs.sh aangepast zoals in dit bericht te lezen is. De pc heeft de afgelopen nacht uitgestaan dus een herstart heeft ie zeker gehad.

Blijkbaar is er of in Kubuntu wat verandert met de versie die ik nu draai (Hardy 8.04 vs Gutsy 7.10) of in virtualbox 1.6.0 vs 1.5.6. Volgens de mensen op irc moet ik in de fstab nog een regel toevoegen en vervolgens herstarten:

cat /etc/group | grep vbox

Hiermee achterhalen we het groepnummer om die vervolgens in de fstab te gebruiken:

none /proc/bus/usb usbfs devgid=120,devmode=664 0 0

Eigenwijs als ik ben wil ik het geheel proberen zonder een reboot. Als eerste dus het afsluiten van de virtualmachine en dan een sudo mount -a ingeven. Hiermee zou toch de boel goed moeten staan. Blijkbaar niet want virtualbox geeft niet thuis. Dan toch maar een herstart doen waarna het geheel helemaal volgens plan werkt.

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.