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 …

Ubuntu & AMD Radeon RX 580

Ik ben een gamer. Of beter, ik ben iemand met een game-pc. En op gezette tijden moet je die eens een upgrade geven, want anders ben je niet meer “mee” natuurlijk.

Een paar maanden geleden zijn CPU, moederbord en RAM-geheugen vervangen, nu was het de beurt aan de grafische kaart: van een nVidia GeForce 640T naar een AMD Radeon RX 580. Volgens ’t Internet hoef je daarvoor eigenlijk niet veel te doen: oude kaart eruit, nieuwe kaart erin en klaar.

Gigabyte AMD Radeon RX 580

Was het maar waar. nVidia geeft zich niet zo eenvoudig gewonnen: bij een eerste boot is er uiteraard geen beeld en moet je eerst de nvidia-drivers verwijderen:

apt-get remove nvidia-graphics-drivers-375 && apt-get autoremove

En dan is er wel beeld. Maar toch klopt er iets niet. Een cursory check van de output van lsmod leert dat de amdgpu-driver niet is ingeladen: we gebruiken de i915_bpo-driver, wat de driver is van de embedded graphics chip van de CPU, niettegenstaande de kaart wel herkend wordt en het scherm aangesloten is op de uitgang van de kaart. Ik wist niet dat Ubuntu dat kon.

Na een tweetal avonden zoeken (ik bespaar u de details) naar hoe Ubuntu/X11 kan gedwongen worden om de amdgpu-driver te laden heb ik het helaas opgegeven: in plaats van de Open-Source-driver te gebruiken ben ik naar de site van AMD gegaan en heb daar de proprietary AMDGPU-PRO-driver gedownload en geïnstalleerd. En daarmee werkt het wel, afgezien van een vreemde lichtflits helemaal in het begin van het bootproces. Maar zo’n groot probleem is dat nu ook weer niet.

En wat doet een mens dan? Een ouderwetse game-avond organiseren natuurlijk, maar dan met de graphics maxxed-out. Allez, niet dat het bij Civilization V veel uitmaakt, maar de andere games staan op de Windowspartitie. En daar heb ik de driver nog niet geïnstalleerd …

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 …