Allereerst maar de benodigde pakketten installeren:

aptitude install dovecot-common dovecot-imapd

Hiermee werden de geinstalleerde Courier pakketten verwijderd. Volgende stap is dan het configureren van Dovecot. Allereerst maar even een kopie gemaakt van de default configuratie:

cp /etc/dovecot/dovecot.conf /etc/dovecot/dovecot.conf.default

Vervolgens is het een kwestie van de volgende bestanden configureren:

• /etc/postfix/main.cf
• /etc/postfix/master.cf
• /etc/dovecot/dovecot.conf
• /etc/dovecot/dovecot-sql.conf

Een van de problemen die ik tegen kwam, was de volgende foutmelding in de mail.log:

echo postfix/pipe[28624]: AC7AB11BA168: to=<mailaddress>, relay=dovecot, delay=56, delays=56/0.01/0/0.01, dsn=4.3.0, status=deferred (temporary failure. Command output: Can't open log file /var/log/mail.log: Permission denied )

De oplossing voor dit probleem was -na een uurtje gezocht en nagedacht te hebben- eigenlijk vrij simpel. In /etc/dovecot/dovecot.conf had ik de volgende regel opgenomen:

log_path = /var/log/mail.log

Deze heb ik verwijderd en na een herstart was het probleem verholpen. Het is immers niet nodig om expliciet een aparte logfile op te geven, als ik het weglaat komt het automatisch wel in de mail.log terecht.

Volgende issue was de volgende melding:

deliver(mailaddress): Fatal: setgid(1001(vmail)) failed with euid=5000(vmail), gid=5000, egid=5000: Operation not permitted (This binary should probably be called with process group set to 1001(vmail) instead of 5000)

Deze fout werd veroorzaakt door het feit dat in de dovecot.conf twee regels niet opgenomen waren:

mail_uid=5000
mail_gid=1001

De rest van de configuratie kon zonder problemen worden ingesteld door de voorbeeld configuratie door te nemen. Aangezien ik met Courier ook het ssl/tls gedeelte werkend had, was het een kleine moeite om ook Dovecot te laten werken met ssl/tls. Al met al heeft het twee avonden gekost om het weer tot een werkende configuratie te brengen.

Volgende stap is het opschonen van de configuratie, maar dat komt later. Eerst even een tijdje laten draaien.

Dat levert het volgende lijstje op:

• een AAAA-record toevoegen aan de waarde van mijn mx-record
• reverse dns instellen voor mijn mx-record voor het ipv6 adres
• parameters in Postfix toevoegen c.q. wijzigen

De eerste is geen probleem, in het controlepanel van Transip kan ik een AAAA-record toevoegen. Echter, de reverse dns voor ipv6 kan ik zelf niet instellen. Wordt dus een puntje om uit te zoeken.

In het bestand /etc/postfix/main.cf gaat het om twee parameters:

inet_protocols = ipv4, ipv6
smtp_bind_address6 = 2001:..:1

Hierna is een stop-start van Postfix voldoende om zowel mail te ontvangen als te versturen via ipv6.

ssh -L 3306:127.0.0.1:3306 user@server

Na het ingeven van mijn wachtwoord, kan ik vervolgens op mijn werkstation in mijn databaseprogramma verbinding maken met 127.0.0.1:3306 en kan ik aan de slag.

Ben nog wel even aan het rondkijken wat voor programma ik lokaal ga gebruiken. Voorlopig is mijn keuze gevallen op Database browser portable.

Edit 03-12-2010:
Inmiddels is de oude server opgeruimd en is de verhuizing compleet.

Oct 20 18:33:54 echo suhosin[28058]: ALERT - script tried to increase memory_limit to 268435456 bytes which is above the allowed value (attacker '82.75.246.231', file '/var/www/blog/wp-admin/admin.php', line 96)

Er wordt dus geprobeerd om de memory limit op 256mb te zetten. Aangezien in de php.ini de limit is ingesteld op 128mb komt er dus een alert. Ga nog even bedenken wat ik hiermee ga doen, of verlagen of gewoon laten staan. Het is weliswaar alleen een alert en de setting wordt niet actief, maar vanuit beheersoogpunt is elke foutmelding er een te veel.

Toevoeging 21-01-2011
Heb even het bijbehorende bug ticket erbij gezocht, maar het lijkt er niet op dat het snel gefixed gaat worden .

Allereerst heb ik een scriptje aangemaakt:

#!/bin/sh
user=$1
realm=$2
pass=$3

hash=`echo -n "$user:$realm:$pass" | md5sum | cut -b -32`

echo "$user:$realm:$hash" 

Dit kan dan als volgt worden gebruikt:

$ htdigest.sh 'user' 'realm' 'secret'
user:realm:8364d0044ef57b3defcfa141e8f77b65

Daarna de configuratie in Lighttpd toegevoegd:

# statistieken pagina afgeschermd
$HTTP["url"] =~ "^/statistieken/" {
auth.backend = "htpasswd"
auth.backend.htpasswd.userfile = "/path/to/.htpasswd"
auth.require = ("/webstats" => (
"method"  => "basic",
"realm"   => "anything",
"require" => "valid-user"
))
}

Nu ik bezig ben met het overstappen naar Lighttpd, ben ik aan het uitzoeken of (en vooral hoe) alles dat ik gebruik in Lighttpd geconfigureerd moet worden. Na een half uurtje puzzelen kwam ik tot het volgende:

$HTTP["host"] == "www.domein.nl" {
 magnet.attract-physical-path-to = ( "/etc/lighttpd/gallery.lua" )
}

En de gallery.lua bevat weer:

attr = lighty.stat(lighty.env["physical.path"])
if (not attr) then
   path = "/gallery.php"
   uri = string.sub(lighty.env["request.uri"],10)
   lighty.env["uri.query"] = "g=" .. uri
   lighty.env["uri.path"] = path
   lighty.env["request.uri"] = path .. "?" .. lighty.env["uri.query"]
   lighty.env["physical.rel-path"] = path
   lighty.env["physical.path"] = lighty.env["physical.doc-root"] .. path
end

En het leuke is nu, de originele url blijft in tact!

Nu wordt met de standaardinstallatie de module mod_simple_vhost gebruikt. Dat werkt weliswaar, maar er is een andere module die wat krachtiger is, mod_evhost. Mijn eerste gedachte was als volgt:

# vi /etc/lighttpd/lighttpd.conf
-> toevoegen module mod_evhost
-> toevoegen evhost.path-pattern  = "/var/www/%0/%3/"
# /etc/init.d/lighttpd force-reload

Hierna zou het dus zou moeten zijn dat als de directory bestaat, de virtualhost dus wijst naar de directory zoals die in het pattern is opgegeven (%0 is domein+tld, %3 is 1e sub). Als de directory niet bestaat, wordt de default documentroot gebruikt.

Echter, wat ik ook probeerde, voor alle verzoeken werd de content uit de default documentroot getoond en niet uit de directory voor dat specifieke domein. Oplossing hiervoor was eigenlijk best wel simpel. Het blijkt dus dat er maar 1 vhost module geladen mag zijn. Inderdaad, ik had zowel de mod_evhost als de mod_simple_vhost geladen. Weliswaar had ik alleen configuratie voor de mod_evhost, maar het simpelweg geladen zijn van beide is al voldoende om het niet te laten werken.

Kan ik nu verder met de mysql module en de verdere fine-tuning.

# IPv6 Config
$SERVER["socket"] == "[::]:80" {
        accesslog.filename = "/var/log/lighttpd/ipv6.access.log"
        server.document-root = "/var/www/"
}

Installatie is als volgt:

# aptitude install lighttpd php5-cgi

Na afloop krijg ik een waarschuwing dat het geheel niet gestart kan worden, maar dat natuurlijk omdat poort 80 al in gebruik is door Apache.

Volgende stap is nu de configuratie aanpassen en een simpele statische html site beschikbaar maken.

# vi /etc/php5/cgi/php.ini
-> enable: cgi.fix_pathinfo = 1
# 

Vervolgens is er nog een <a href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=564556">probleem</a> met het starten in combinatie met ipv6.
<pre>
# /etc/init.d/lighttpd start
Starting web server: lighttpd2010-10-06 18:49:22: (network.c.358) can't bind to port: :: 80 Address already in use
 failed!

Geen idee waar dit nu weer vandaan komt. Want alhoewel ik voor heb ingesteld dat het geheel op poort 81 moet luisteren, toch wordt geprobeerd om op poort 80 een socket te openen. Ik vermoed dat het iets met ipv6 te maken heeft, getuige ook de bug.

Onderstaande regels geven in elk geval een startende Lighttp voor ipv4:

server.use-ipv6 = "enable"
# listen to ipv4
server.port               = "81"
server.bind               = "::"
# listen to ipv6
# $SERVER["socket"] == "[::]:81" {  }

De ipv6 heb ik uitgezet, omdat die een foutmelding geeft dat poort 81 al in gebruik is. Gelijktijdig ipv4 en ipv6 op dezelfde poort kan blijkbaar niet in Lighttpd.