Certificaten voor Postfix

Voor de website had ik al eerder certificaten van Letsencrypt geinstalleerd. De mailserver heeft echter nog steeds een self signed certificaat dat bovendien ook al lang verlopen is. Niet echt handig, daarom voor de mailserver ook maar een eigen certificaat aanvragen.

Het aanvragen van het certificaat gaat op dezelfde manier als voor de website, alleen de naam is natuurlijk anders. Mijn main.cf bevat al de twee benodigde parameters:

smtpd_tls_cert_file=/root/ssl/certificatefile
smtpd_tls_key_file=/root/ssl/keyfile

Vanaf Postfix versie 3.4 kan de parameter smtpd_tls_chain_files gebruikt worden, maar aangezien ik nog op 3.1 zit, blijf ik nog de 2 oude instelling houden. Nieuwe certificaat in gebruik nemen is naam van het certificaatbestand en key-bestand wijzigen en Postfix herstarten.

Buggy code blokken

Een hele tijd terug heb ik me al eens bezig gehouden met een manier om de formattering die WordPress toepast, aan te passen en naar mijn eigen hand te zetten. Destijds had ik daar een plugin voor die perfect deed wat ik wou, maar die heb ik toen na een aantal jaren weer uitgezet omdat ik met een schone lei wou beginnen.

In de afgelopen dagen is het regelmatig voorgekomen dat bepaalde regels in code blokken niet goed vertaalt worden. Oplossing dat tussen de pre tag staat met een html encoder vertalen en dan die output gebruiken. Maar omdat voor elk bericht te doen waar ik code nodig heb, vind ik wat omslachtig.

Andere oplossing is om mijn oude Steno plugin weer van stal te halen. Heb een korte test gedaan en voor de code blokjes werkt het perfect! Maar helaas wordt dan gelijk alle andere formattering ook ongedaan gemaakt, zoals bijv. de lijstjes die met ul en li gemaakt worden.

Nu kan ik heel veel tijd gaan besteden om zelf iets te maken, maar ik kwam een andere plugin tegen die eigenlijk precies doet wat ik wil. Wel moet ik in alle bestaande berichten de pre tag omzetten naar code, maar dat is met een simpele sql opdracht op te lossen. De spaties voor en na het woordje code moeten natuurlijk weg, die staan er omdat anders de tag afgesloten wordt.

update wp_posts set post_content = replace(post_content, '[ code ]','<pre>');
update wp_posts set post_content = replace(post_content, '[ /code ]','</pre>');

Voordat ik alles ga aanpassen, eerst maar eens bedenken wat ik wil.

Eigen thema

Het is rustig geweest hier afgelopen jaren, maar ben nu weer een beetje met WordPress aan het spelen. Ben wel altijd bijgebleven met updates en heb al die tijd met een standaard thema gewerkt.

Vroeger had ik wel een eigen thema gemaakt, door een bestaand thema flink aan te passen. Op zich kan dat, maar dat is met updates altijd wat extra werk om te zorgen dat alles goed gewijzigd wordt.

Nu maar op de juiste manier gedaan door een child-theme te maken.

Als eerste stap een nieuwe directory twentytwelve-child gemaakt in wp-content/themes. In die nieuwe directory een style.css gemaakt met verwijzing naar het parent theme:

/*
Theme Name: Blank Twenty Twelve Child theme
Theme URI: http://yoursite/yourtheme
Description: A child theme of 2012 default WordPress theme.
Author: Your name
Author url: Your site
Version: 1.0
Tags: black, blue, white, fixed-width, custom-header, theme-options
Template: twentytwelve
*/
@import url('../twentytwelve/style.css');

Tot slot nog functions.php gemaakt, deze heb ik nu nog niet nodig, maar in toekomst mogelijk wel:

<?php
// Add your own functions below this line

Deze vervolgens geactiveerd. Hiermee heb ik een goed uitgangspunt om het uiterlijk van deze site langzaam aan naar mijn smaak te zetten.

Fail2ban installatie and configuratie

Besloten om Fail2ban te gaan gebruiken om het verkeer op vooral de ssh poort te beperken.

Installeren gaat eenvoudig:

# apt-get install fail2ban

Valt me op dat er voor een aantal bestanden worden geplaatst voor zaken die ik niet geinstalleerd heb. Op zich niet erg, maar niet echt netjes. Later maar eens uitzoeken of ik die zonder problemen kan verwijderen.

Daarna status controleren:

# service fail2ban status
[ ok ] Status of authentication failure monitor:[....] fail2ban is running.

Voor Debian geldt dat de configuratie in /etc/fail2ban/jail.conf file en /etc/fail2ban/jail.d/defaults-debian.conf gedaan wordt. Omdat deze 2 bestanden in de toekomst mogelijk kunnen wijzigen, wordt geadviseerd om een eigen bestand te maken met de gewenste instellingen:

# vi /etc/fail2ban/jail.d/jail-debian.local

Tot slot nog een herstart om de wijzigingen actief te maken:

# service fail2ban restart

Om meer details over de status te krijgen, kunnen de volgende commando’s gebruikt worden:

# fail2ban-client status
# fail2ban-client status sshd

Tot slot, een kleine naslag voor mezelf om de huidige bans te tonen en een ban voor een ip op te heffen:

  • Toon gebannede ip’s
  • # iptables -n -L --line-numbers
  • verwijderen banned ip uit de lijst
  • # iptables -D f2b-sshd 

Lets Encrypt

Tot op heden heb ik voor deze site altijd een self signed certificaat gebruikt. Maar met de tijd wordt het gebruik van self signed certificaten behoorlijk afgeraden en browsers geven om de haverklap waarschuwingen. Nu is Let’s Encrypt al enige tijd actief en het is een goede optie voor een gratis certificaat van een CA die in elke grote browser aanwezig is.

Enige nadeel is dat de certificaten maar 90 dagen geldig zijn. Maar daar staat tegenover dat het aanvragen en vernieuwen erg eenvoudig is.

Als eerste stap de backports voor Debian Stretch toegevoegd:

# vi /etc/apt/sources.list
# aptitude update

Daarna certbot geïnstalleerd uit de backports:

# apt-get install certbot python-certbot-apache -t stretch-backports

Als dat gedaan is kan ik een certificaat voor www.zomaarr.nl:

# certbot certonly --webroot -w /var/www/html/zomaarr.nl -d www.zomaarr.nl

Om te controleren of ik eigenaar ben van het domein, heb ik gekozen voor het plaatsen van een document in de webroot. Tijdens het proces wordt een verborgen directory aangemaakt met een challenge, die directory wordt na afloop keurig netjes weer verwijderd. Voor nu gekozen voor maar 1 domeinnaam. Ik kan altijd later nog besluiten om voor alle domeinen een SAN certificaat aan te vragen. Overigens, tegenwoordig kan bijna elke browser met SNI overweg, dus voor mij is het ook geen probleem om per domein een eigen certificaat te gebruiken.

Tot slot nog de configuratie van de webserver aanpassen en een herstart om het nieuwe certificaat actief te maken.

# vi /etc/apache2/sites-enabled/zomaarr.nl
# apache2ctl -t
Syntax OK
# apache2ctl restart

Debian upgrade naar Stretch

Het was al enige tijd nodig, maar eindelijk wat tijd gevonden om de update van Debian Jessie naar Stretch te doen. Heb daarbij mijn gebruikelijke stappenplan gevolgd.

Allereerst zorgen dat alles volledig is bijgewerkt:

# apt-get update
# apt-get upgrade
# apt-get dist-upgrade

Daarna de sources aangepast en naar de Stretch laten wijzen:

# vi /etc/apt/sources.list
--> change jessie in stretch

Vervolgens de upgrade uitvoeren:

# apt-get update
# apt-get upgrade
# apt-get dist-upgrade

Bij een aantal configuratiebestanden kreeg ik de melding dat er een nieuwere versie beschikbaar was. Bij de vraag of de huidige overschreven mocht worden heb ik altijd nee geantwoord. De verschillen tussen mijn configuratie en de nieuwe zoek ik achteraf wel uit.

Daarbij ben ik geen problemen tegengekomen, alles was vrij simpel op te lossen. Had me voorgenomen om die wijzigingen netjes bij te houden voor het blog, maar dat ben ik totaal vergeten. Hopelijk vergeteet ik het niet bij de volgende grote upgrade, want juist dat soort uitzoekklusjes zijn prima voor een berichtje.

Debian Jessie update

Debian Jessie is paar weken geleden uitgebracht, maar was nog niet aan updaten toegekomen.

Heb het vrij simpel aangepakt. Eerst zorgen dat Wheezy helemaal geupgrade is:

# apt-get update
# apt-get upgrade
# apt-get dist-upgrade
# vi /etc/apt/sources.list
--> change wheezy in jessie

Daarna nogmaals voor de echte upgrade:

# apt-get update
# apt-get upgrade
# apt-get dist-upgrade

Tijdens upgrade een flink aantal configuratiefiles waarvoor ik de vraag kreeg of mijn versie overschreven mocht worden. Hier heb ik altijd nee op geantwoord, dit zorgt ervoor dat ik mijn wijzigingen niet kwijt ben en dat de nieuwe default configuratiefiles apart worden weggeschreven.

Heb eigenlijk geen echt grote problemen ondervonden. Alleen de upgrade van Debian bracht ook een upgrade van Apache 2.2 naar Apache 2.4 met zich mee. Dat zorgde ervoor dat Apache niet direct wou starten omdat een aantal parameters gewijzigd waren. Dat was simpel op te lossen door de aanwijzingen in de Apache logs en de output van apachectl configtest te volgen.

Debian upgrade naar Wheezy

Vandaag de upgrade naar Wheezy gemaakt, met vrij simpel stappenplannetje:

Eerst zorgen dat alles bijgewerkt is:

# apt-get update
# apt-get upgrade
# apt-get dist-upgrade
# vi /etc/apt/sources.list
--> change squeeze to wheezy

Daarna nogmaals voor de echte upgrade:

# apt-get update
# apt-get upgrade
# apt-get dist-upgrade

Enkele configuratiefiles moesten worden nagelopen, maar dat was binnen 10 minuten klaar.

IPv6 en netmask

Bij een blade vps van Transip wordt standaard een ipv6 adres uitgegeven met een /64 range. Echter, de gateway die gebruikt moet worden, valt buiten het bereik van die /64 range. Het is dus noodzakelijk om in /etc/network/interfaces bij netmask niet 64, maar 48 in te vullen.

# The loopback network interface
auto lo
iface lo inet loopback

# The IPv4 network interface
allow-hotplug eth0
iface eth0 inet dhcp

# The IPv6 network interface
iface eth0 inet6 static
   address 2a01:7c8:aab1:1c4::1
   netmask 48
   gateway 2a01:7c8:aab1::1

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.