Logrotate en compressed

Vooral als aantekening voor mezelf, omdat ik hier gisteren best wel naar heb lopen zoeken.
Als de sharedscript optie gebruikt wordt in de logrotatie, dan wordt de compressie pas uitgevoerd nadat het postrotate gedeelte gedaan is.

Dit heb ik nu:

/var/log/apache2/*.log {
        daily
        missingok
        rotate 35
        compress
        sharedscripts
        postrotate
        day=`date -d 'yesterday' +%Y%m%d`
        mv access.log.1 access.log-$day
        mv error.log.1 error.log-$day
        if [ -f /var/run/apache2.pid ]; then
        /etc/init.d/apache2 restart > /dev/null
        fi
        chmod 640 /var/log/apache2/*.log
        endscript
}

In het postrotate gedeelte hernoem ik dus de geroteerde bestanden zodat er de datum van gisteren in voorkomt. Daarmee komen ze wel buiten het bereik van de logrotatie, maar dat los ik wel op een andere manier op.

Heb ook nog even gekeken naar de dateext optie, maar daarmee kan ik niet aangeven dat het de datum van gisteren moet zijn.

Na de crash

Een dag na de crash zijn een aantal belangrijke zaken weer ingericht:

  • apache, php en mysql geinstalleerd
  • logrotatie voor apache opnieuw ingesteld
  • webstatistieken
  • backup databases (nu nog lokaal, nog aanpassen naar opslag extern)

Staat nog heleboel te doen komende weken, maar voorlopig is belangrijkste weer up en running.

Crash

Het kan zomaar ineens gebeuren, een harddisk die overlijdt. Het komt altijd ongelegen en ondanks alle goede voornemens waren mijn backups niet al te recent meer (ongeveer 3 maanden oud). Dondermiddag begonnen de problemen met de harddisk en donderdagavond hield alles er opeens mee op.

Inmiddels weer op het punt dat ik in ieder geval weer mijn belangrijkste website in de lucht kan brengen. Weliswaar met de stand van begin februari, maar dat is niet anders.

Komende dagen dus druk met weer alles op te zetten en in te regelen.

Apache 2.4 voorbereiden compilatie

Al enige tijd zit ik er aan te denken om te upgraden van Apache 2.2 naar versie 2.4. Enige probleem, deze zit niet in de repositories van Debian Squeeze. Nu kan ik een precompiled binary downloaden, maar waarom zelf niet compileren? Ben vooral benieuwd naar de nieuwe mpm event.

Wat ik voor Apache 2.4 in ieder geval nodig heb:

Als eerste maar eens alle archieven uitpakken (archieven staan bij mijn in /opt/dsl/sources):

$ cd /tmp/
$ tar xzf /opt/dsl/sources/apr-1.4.6.tar.gz
$ tar xzf /opt/dsl/sources/apr-util-1.5.1.tar.gz
$ tar xzf /opt/dsl/sources/httpd-2.4.3.tar.gz

Apr en apr-util zijn nodig voor Apache, dus die compileren we eerst:

$ cd /tmp/apr-1.4.6
$ ./configure --prefix=/opt/apr
$ make
# make install
$ cd /tmp/apr-util-1.5.1
$ ./configure --prefix=/opt/apr-util ---with-apr=/opt/apr
$ make
# make install

Ik kies hier bewust voor een prefix om alles een eigen directory onder /opt te geven. Op die manier weet ik zeker dat alle bestanden netjes bij elkaar staan. Nu nog alles netjes in een archief stoppen:

$ tar czvf /opt/dsl/apr-1.4.6-bin.tar.gz /opt/dsl/apr/
$ tar czvf /opt/dsl/apr-util-1.5.1-bin.tar.gz /opt/dsl/apr-util/

Mooiste zou zijn om zelf een deb package te maken, maar daar moet ik me eerst nog in verdiepen. En aangezien het toch voornamelijk voor mezelf is, is deze werkwijze voldoende.

Edit 28-01-2013
Wat ik vergat, ik moet php waarschijnlijk ook opnieuw compileren omdat de geinstalleerde versie van php tegen Apache 2.2 gecompileerd is.

Nog maar eens goed over nadenken wat ik ga doen.

Nieuw domein

Het stond al een tijdje op mijn te doen lijstje, maar had er nooit tijd voor gemaakt. Vandaag maar eens het blog verhuisd naar een nieuw domein, http:///www.zomaarr.nl.

Overzetten ging vrij simpel:

  • verplaatsen documentroot naar nieuwe directory
  • aanpassen apache configuratie voor 301 redirect van http://www.zomaarroland.nl naar http://www.zomaarr.nl
  • aanpassen apache configuratie voor zomaarr.nl, extra rewriterules
  • aanpassen van WordPress uri en Site address in de database

Aangezien er verder niets wijzigt, ben ik nu klaar. Nu maar zien of met de zoekmachines alles goed gaat.

ipv6 en windows 7 (2)

Twee maand terug heb ik een tunnel ingesteld. Direct na het instellen had ik al een vermoeden dat het openen van sommige sites flink trager was dan normaal. Nu ik er twee maanden mee getest heb en het aantal sites dat traag opende flink toenam, heb ik het ipv6 adres weer verwijderd. Dan voorlopig maar geen ipv6 sites.

Ga later wel eens nadenken of ik een simpel routertje met custom firmware ga inzetten om op die manier ipv6 te krijgen. Of misschien dat upc binnenkort eindelijk eens ipv6 gaat aanbieden.

ipv6 en windows 7

Vandaag heb ik me maar weer eens bezig gehouden met ipv6. Echt noodzaak heb ik daar nog niet voor, maar was gewoon nieuwsgierig naar hoe dat tegenwoordig geregeld is. Vorige keer dat ik me er mee bezig hield is al waar 1,5-2 jaar terug.

De vorige keer had ik een tunnel bij Sixxs. Op zich werkte die altijd goed, maar omdat ik nu langere tijd niet online ben geweest heb ik -100 credits. Bovendien vind ik het bij Sixxs allemaal nodeloos ingewikkeld.

Toen herinnerde ik me, ik heb ook nog een account bij Hurricane Electric (tunnelbroker.net). Daar maar eens ingelogd en mijn gegevens bijgewerkt, want ik ben inmiddels ook verhuisd.

De configuratie ging eigenlijk vrij simpel, vooral vergeleken met Sixxs is de uitleg bij tunnelbroker veel beter.

Ik zit achter een router, dus in plaats van het externe ip gebruik ik mijn interne ip als het beginpunt van mijn tunnel. Daarnaast heb ik mijn vaste lan-verbinding ook een ip gegeven uit de ipv6-reeks die ik toegewezen heb gekregen:

netsh interface teredo set state disabled
netsh interface ipv6 add v6v4tunnel IP6Tunnel 192.168.1.10 216.66.84.46
netsh interface ipv6 add address IP6Tunnel 2001:470:1f14:18::2
netsh interface ipv6 add route ::/0 IP6Tunnel 2001:470:1f14:18::1

netsh interface ipv6 add address "LAN-verbinding" 2001:470:1f14:18::3

Dat levert op http://kame.net een bewegende schildpad op. Wel heb ik het idee dat het openen van sommige sites nu langer duurt dan anders. Wordt dus even uitzoeken of dat kan komen doordat eerst ipv6 gebruikt wordt en pas dan ipv4…

Eigen ca

Al een tijdje loop ik met het idee om een eigen ca te gaan gebruiken. Voor mijn eigen sites vind ik het zonde van het geld om een duur certificaat van een officiele provider aan te schaffen. Mijn eigen ca zit weliswaar niet in elke browser, maar elke bezoeker kan wat mij betreft prima voor zichzelf uitmaken of hij mij vertrouwt ja of nee. Enige dat ik nodig heb is standaard aanwezig op bijna elke unix c.q. linux machine, namelijk Openssl.

Opzetten basisstructuur

Allereerst de opzet van de directory structuur en het aanmaken van de benodigde bestanden. Op zich maakt het niet uit waar het staat. Ik heb er voor nu voor gekozen om het in een subdirectory van de home van root te doen.

# mkdir /root/ssl/ca
# mkdir /root/ssl/ca/certs
# mkdir /root/ssl/ca/private
# mkdir /root/ssl/ca/requests
# touch certindex.txt
# echo '100001' > /root/ssl/ca/serial
# cp /etc/ssl/openssl.cnf /root/ssl/ca/openssl.cnf
# chmod -R 0700 /root/ssl/ca/

Wijzig hierin in ieder geval de volgende variabelen naar de voor u correcte waarden:

dir = /root/ssl/ca
database = $dir/certindex.txt
new_certs_dir = $dir/certs
certificate = $dir/certs/ca.crt
serial = $dir/serial
private_key = $dir/private/ca.key
default_days = 730
default_bits = 2048

Bij [ req_distinguished_name ] Vul de gewenste standaardwaarden in

Aanmaken ca private key en ca root certificaat

Nu we de basis hebben opgezet, kunnen we ons eigen root certificaat aanmaken.

/root/ssl/ca# openssl req -new -x509 -extensions v3_ca \
-keyout private/ca.key -out certs/ca.crt -days 3650 -config ./openssl.cnf

Belangrijk is om bij de common name een herkenbare tekst in te vullen, bijvoorbeeld de eigen naam. Het hoeft geen url te zijn. De naam die we hier invullen, is zichtbaar in de browser als we de lijst met gecertificeerde organisaties bekijken.

Daarnaast is het van belang om een goede passphrase te kiezen als beveiliging voor de private key.

We hebben nu twee bestanden:

  • /root/ssl/ca/private/ca.key: de private key van het root certificaat dat niet in verkeerde handen mag vallen
  • /root/ssl/ca/certs/ca.crt: het root certificaat dat aan de browser wordt aangeboden

Aanmaken certificate request en private key

We hebben nu ons eigen root certificaat dat we kunnen gebruiken om de requests te ondertekenen. Dat doen we met de volgende opdracht:

/root/ssl/ca# openssl req -new -nodes -out requests/www.zomaarr.nl.csr \
-keyout private/www.zomaarr.nl.key -config ./openssl.cnf

Als alles goed gaat, hebben we twee bestanden:

  • /root/ssl/ca/requests/www.zomaarr.nl.csr: het request voor onze site
  • /root/ssl/ca/private/www.zomaarr.nl/key: de private key voor onze site

Ondertekenen certificate request

Nu zijn we zover dat we het request kunnen gaan ondertekenen:

/root/ssl/ca# openssl ca -out certs/www.zomaarr.nl.crt -config ./openssl.cnf \
-infiles requests/www.zomaarr.nl.csr

Omdat we nu de private key van ons root certificaat benaderen, wordt gevraagd om de passphrase die we hebben ingevuld.

We hebben nu een aantal nieuwe bestanden:

  • /root/ssl/ca/certs/www.zomaarr.nl.crt: het certificaat dat op de webserver geplaatst kan worden
  • /root/ssl/ca/certindex.txt: overzicht van de ondertekende requests
  • /root/ssl/ca/serial: dit bestand bevat het serienummer dat de eerstvolgende keer gebruikt gaat worden
  • /root/ssl/ca/100001.pem: voor elk ondertekende request wordt naast het bestand in de -out parameter, ook een certificaat aangemaakt met het serienummer in de naam

Al met al niet heel ingewikkeld, maar het is wel zaak om helder te hebben welk bestand waarvoor dient en een naamgeving te gebruiken die precies aangeeft waar elk bestand voor gebruikt wordt.

Natuurlijk kan het verder uitgebreid worden door een shell scriptje te maken dat als parameter de domeinnaam nodig heeft, zodat via een paar simpele Openssl opdrachten alles automatisch verloopt. Maar dat is voor een volgende keer.

Moeilijke mail termen

Om nu voor eens en voor altijd voor mezelf helder te krijgen wat nu al die verschillende afkortingen betekenen, een overzichtje van de belangrijkste termen die je tegen komt als je zelf een mailserver gaat beheren.

  • MUA Maul User Agent
    Oftewel het programma waarmee je mail kunt ophalen en versturen, bijvoorbeeld Outlook.
  • MTA Mail Transport Agent
    De naam zegt het eigenlijk al, de MTA zorgt voor het transport van de mail, dus van bijvoorbeeld Outlook naar de verzendende en de ontvangende mailserver.
  • MDA Mail Delivery Agent
    De MDA neemt de mail in ontvangst van de MTA en levert het af in de juiste postbus. Hierna kan het dus met een MUA weer opgehaald worden.
  • MSA Mail Sending Agent
    Een MSA is in feite niets meer of minder dan het versturen van mail, bijvoorbeeld providers maken hier gebruik van om voor al hun gebruikers de mail te kunnen versturen. Anders gezegd, het is een MTA met daarbij de taak om voor geauthenticeerde gebruikers mail te versturen.
  • MRA Mail Retrievel Agent
    De MRA is verantwoordelijk voor het ophalen van mail van een externe mailbox, zodat het lokaal gebruikt kan worden. Dit gaat in samenwerking met de MDA.

Courier vervangen door Dovecot

Omdat ik af wil van het pakket saslauthd dat voor Courier nodig is, ben ik eens gaan kijken hoe makkelijk het is om over te stappen op Dovecot. En dat bleek eenvoudiger dan gedacht.

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=, 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.