Back-ups met Duplicity

Back-ups maken is zoals naar de tandarts gaan. Iedereen weet dat het moet, maar er is altijd wel een reden om het niet te doen. Tot het te laat is natuurlijk …

Na het opruimen van de server room was dit het volgende project. Uiteraard volgens de regels van de kunst: 2 verschillende locaties, waarvan één lokaal (voor snelle recovery) en één elders (tegen overstromingen, inbraken of andere rampen).

Lokaal is op de NAS in de server room, met een simpel rdiff-backup-script. Het werkt wel nog niet helemaal, maar het is simpel en efficiënt (en natuurlijk automatisch en regelmatig, maar wat had u gedacht).

De kopie elders (ofte de remote) is bij Backblaze, met hun B2 Cloud Storage-product. Waarom? Omdat een server speciaal voor back-ups te huren een hassle is, ik hen al gebruik voor persoonlijke back-ups en er content van ben en omdat ze, in tegenstelling tot Crashplan, wel back-ups van Linux-servers ondersteunen.  Hun back-end integreert immers mooi met Duplicity, dat meteen ook de back-ups versleutelt. Dubbele win!

Het proces is simpel:

  1. Je maakt een GPG-sleutel aan (opgelet: gebruik gpg, niet gpg2!).
  2. Je voert de back-up uit.
  3. (Optioneel, maar aangeraden) Maak een back-up van je GPG-sleutels. Geen sleutels = geen back-ups.

Het zal u goed doen om te horen dat ik stap 2 geautomatiseerd heb; het script is beschikbaar op Github.

Wat is de catch?

  • GPG loopt niet over de gebruiksvriendelijkheid.
  • Je moet je sleutel bijhouden (back-uppen) en importeren voor je het script kan uitvoeren.
  • Duplicity ondersteunt geen GPG2. Het kostte mij een halve dag om dat uit te vissen.
  • Je moet de exclude-opties goed configureren, want opladen gaat traag. Tenzij je een symmetrische verbinding hebt natuurlijk. In dit geval: I want!

Maar toch, better safe than sorry!

“Man Cave” for nerds

Nerds hebben geen “man cave”, die hebben een datacenter. In hun huis. En uiteraard … In iets wat eigenlijk de traphal naar de zolder moet worden. En vandaag, vrije dag, helemaal opgeruimd!

Orde!

Kabels, DVD’s , USB-kabels (een mens vindt die overal) en genoeg RAM-geheugen voor een PC of tien.

Orde!

Rommel-om-computers-mee-samen-te-steken (langlopend project).

Discipline!

Ik heb absoluut niet te veel computers. Alleen te weinig stopcontacten (maar één in gebruik). En ze werken ook niet allemaal …

Dovecot & certificaten

Zoals ik al vertelde, was het nodig om het SSL-certificaat van mijn e-mailserver (post.helptux.be) te vernieuwen.

En natuurlijk moet je dan ook alle applicaties aanpassen. Postfix was mooi aangepast, maar toen weigerde Thunderbird plots mijn e-mails op te halen. En wat vond ik in het logbestand?

May 12 18:01:52 post dovecot: imap-login: Disconnected (no auth attempts in 0 secs): user=<>, rip=<>, lip=<>, TLS: SSL_read() failed: error:SSL routines:SSL3_READ_BYTES:sslv3 alert certificate revoked: SSL alert number 44, session=<>

Oeps! Gelukkig snel gefixt.

ssl_cert = </etc/ssl/private/ssl-chain.2017.pem
ssl_key = </etc/ssl/private/2017.key

En maar meteen ook de rest van de SSL-opties wat verbeterd (geïnspireerd door deze fantastische site).

ssl_cipher_list = AES128+EECDH:AES128+EDH
ssl_protocols = !SSLv2 !SSLv3
ssl_prefer_server_ciphers = yes

DNS @ OSX

Blijkbaar gebruikt OS X zowel udp als tcp om met de DNS-server te verbinden. Maar Linux gebruikt enkel tcp. Zo is het niet moeilijk dat het voor mij wel werkt en voor anderen niet.

Ook. In Puppet doet:

firewall { '609 DNS ACCEPT':
        proto => ['tcp', 'udp']

niet wat je zou verwachten.

Ask me how I know.

OpenVPN: interne router

Ik ben bezig met een OpenVPN-beheernetwerk. U zal dus regelmatig VPN-gerelateerd materiaal zien voorbijkomen.

Om systemen in OpenVPN-VPN met elkaar te laten praten, moet je twee dingen doen: de firewall(s) aanpassen (op de VPN server en op beide hosts); maar ook de route 10.8.0.0/24 naar de clients doorsturen. Anders hebben ze enkel een route voor 10.8.0.1 (de VPN-server), maar niet voor bv. 10.8.0.10.

Een extra route (technisch: het VPN-subnet 10.8.0.0/24 beschikbaar maken voor alle clients) doe je in /etc/openvpn/server.conf:

push “route 10.8.0.0 255.255.255.0”

Hiermee kunnen de clients elkaar in principe zien, maar enkel wanneer je dat op de VPN-sever toelaat in de firewall (tabel FORWARD). En natuurlijk moet de firewall op de client verbindingen via de OpenVPN-interface (of het subnet) toelaten.

OpenVPN op een server

Het internet staat vol met tutorials om een OpenVPN-server op te zetten, maar hoe je dan een andere server (zonder GUI dus) verbindt met die OpenVPN, dat is dan weer moeilijk te vinden.

Het moet zo:

  1. Kopieer uw client.ovpn (met alle nodige certificaten) naar /etc/openvpn op de andere server.
  2. Hernoem client.ovpn naar iets met een duidelijke naam (bv. mijn.vpn.netwerk.conf), maar zorg ervoor dat de bestandsextensie .conf is (en niet .ovpn).
  3. service openvpn start

Blijkbaar pikt OpenVPN automatisch alle configuratiebestanden in /etc/openvpn op (client en server), maar moeten ze de extensie .conf hebben.

Vanaf Ubuntu 16.04/systemd moet het zo:

  1. service openvpn@mijn.vpn.netwerk start

Dit spaart u weer wat tijd en zoekwerk …

[GANDI] Expiration of the certificate SSL Standard (post.helptux.be) in 29 days

Het is weer de tijd van het jaar …

Bijna al mijn certificaten gebruiken Let’s Encrypt, maar voor de e-mailserver (sommige mensen draaien dat nog) gebruik ik een betaald certificaat. Ik zou het waarschijnlijk kunnen omzetten, maar voor e-mailservers ben ik nogal conservatief. Zonder e-mail zal ik niet ver lopen.

Alleen spijtig dat ik er (nog) niet ben toe gekomen om Postfix achter Puppet te steken. Dat wordt dus manueel certificaten vervangen …