Rage against the Internet (a story of problem solving)

I am so pissed, right now, against the Internet. Its content is now so highly irrelevant and so motivated by easy profit (ads) that you can't find anything valuable when you try to solve a "common" tech problem.
It's like you are back to the pre-Internet days but you will still lose your sanity and you precious time on Earth googling for help. Infuriating.

Yesterday evening, I thought it would be a good idea to play few minutes with Airplay between my iPad (on WIFI) and my new LG TV (on Ethernet). I've tried it before, it worked instantly and it was great. Few minutes became +1h45 of fight.

As a professional Sysadmin I've started to list what could have changed between my initial flawless experience and this huge failure: iPadOS updates (can't roll back for testing), LG TV updates (can't roll back either), Pi-hole installation (can disable very easily). Disabling Pi-hole filtering yielded to zero progress. Then I've started asking Google with queries like "LG TV airplay stopped working" and so many variations I've lost the count.
Every single results page served the same crap to me:

"LG TV AirPlay Not Working (PROVEN Fix!)"
"Airplay Not Working on LG TV | Fix in Easy Methods [2022]"
"AirPlay Not Working on LG TV: How to fix - Blue Cine Tech"
"13 Fixes For LG TV Airplay Not Working - TV To Talk About"
"AirPlay Not Working on LG TV (Do This FIRST!) in 2022"

13 fixes? SERIOUSLY? All these web pages are clickbait copy-pasta of the same semi-automatically generated content that contradicts itself (one fix: you must absolutely use WIFI, other fix: use Ethernet if WIFI does not work…) and conveys false informations.
Internet is failing hard on people.

After more tests and thinking I knew something was going on in the background that was probably not related to Airplay: starting the Airplay mirroring from the iPad made the TV displaying a black screen with a message about an incoming Airplay connection from name of my device and a 4 digits code that I had to type onto the device. Entering the code yielded only to the iPad complaining about Airplay connection failure.

So, to be clear about that particular tech issue of mine and about Airplay in general:

  • Airplay works flawlessly on a mixed network (WIFI+Ethernet) as long as your devices are on the same network ( for example).
  • Your devices don't have to be on the same WIFI network. Every one who writes the opposite is either lying, taking a huge shortcut, or is being clueless about Airplay.
  • I solved my problem by accepting "Viewing Information" item in the "User Agreements" panel of the TV. Those agreements are in blatant violation with the GDPR but I've neither time nor resources to start a legal fight with LG so I trick the TV with Pi-hole so whatever I consent to, they can't use or collect.

Full (unstable) trick:
- shutdown TV, remove power for 1 minute
- disable Pi-hole for 5 minutes
- re-plug TV, start TV
- go to settings>User Agreements
- check "Viewing Information", then hit the "Agree" button
- test Airplay: it works!
- ensure Pi-hole is active
- disable "Viewing Information" in the "User Agreements"
- TV says it must reboot to disable specific content you can access only if you agree blahblah…
- throw your best villain laugh as you watch the TV rebooting and coming back with a functional Airplay but no "Viewing Information" agreement.

Unfortunately this trick will no survive long (next morning Airplay was dead again). If I want a more simple and stable setup I must agree permanently to the "Viewing Information" item and follow this process:
- shutdown TV
- disable Pi-hole 30 or 60 sec.
- Start TV
- initiate Airplay from iPad
- For privacy's sake it's wise to reboot the TV when done with Airplay, to ensure full Pi-hole protection

I don't know what Apple would think of that totally artificial limitation LG has put in it's implementation of an Airplay client/target, but it looks fishy to me.

I probably should have titled this post "What they don't want you to know about Airplay on LG TV".

Related posts

Moving to Borgbackup

I used to have a quite complicated backup setup, involving macOS Time Machine, rsync, shell scripts, ZFS snapshots, pefs, local disks, a server on the LAN, and a server 450 km away. It was working great but I've felt like I could use a unified system that I could share across every systems and that would allow me to encrypt data at rest.
Pure ZFS was a no-go: snapshot send/receive is very nice but it lacks encryption for data at rest (transfer is protected by SSH encryption) and macOS doesn't support ZFS. Rsync is portable but does not offer encryption either. Storing data in a pefs vault is complicated and works only on FreeBSD.
After a while, I've decided that I want to be able to store my encrypted data on any LAN/WAN device I own and somewhere on the cloud of a service provider. I've read about BorgBackup, checked its documentation, found a Borg repository hosting provider with a nice offer, and decided to give it a try.

This is how I've started to use Borg with hosting provider BorgBase.

Borg is quite simple, even though it does look complicated when you begin. BorgBase helps a lot, because you are guided all along from ssh key management to creation of your first backup. They will also help automating backups with a almost-ready-to-use borgmatic config file.

Borg is secure: it encrypts data before sending them over the wire. Everything travels inside an SSH tunnel. So it's perfectly safe to use Borg in order to send your backups away in the cloud. The remote end of the SSH tunnel must have Borg installed too.

Borg is (quite) fast: it compresses and dedup data before sending. Only the first backup is a full one, every other backup will send and store only changed files or part of files.

Borg is cross-plateform enough: it works on any recent/supported macOS/BSD/Linux.

Borg is not for the faint heart: it's still command line, it's ssh keys to manage, it's really not the average joe backup tool. As rsync.net puts it: "You're here because you're an expert".

In the end, the only thing I'm going to regret about my former home-made backup system was that I could just browse/access/read/retrieve the content of any file in a backup with just ssh, which was very handy. With Borg this ease of use is gone, I'll have to restore a file if I want to access it.

I won't detail every nuts and bolts of Borg, lots of documentation exists for that. I would like to address a more organizational problem: doing backups is a must, but being able to leverage those backups is often overlooked.
I backup 3 machines with borg: A (workstation), B (home server), C (distant server). I've setup borgmatic jobs to backup A, B and C once a day to BorgBase cloud. Each job uses a dedicated SSH key and user account, a dedicated Repository key, a dedicated passphrase. I've also created similar jobs to backup A on B, A on C, B on C (but not Beyoncé).
Once you are confident that every important piece of data is properly backed up (borg/borgmatic job definition), you must make sure you are capable of retrieving it. It means even if a disaster occurs, you have in a safe place:

  • every repository URIs
  • every user accounts
  • every SSH keys
  • every repository keys
  • every passphrases

Any good password manager can store this. It's even better if it's hosted (1password, dashlane, lastpass, etc.) so that it doesn't disappear in the same disaster that swallowed your data. Printing can be an option, but I would not recommend it for keys, unless you can encode them as QRCodes for fast conversion to digital format.

You must check from time to time that your backups are OK, for example by restoring a random file in /tmp and compare to current file on disk. You must also attempt a restoration on a different system, to make sure you can properly access the repository and retrieve files on a fresh/blank system. You can for example create a bootable USB drive with BSD/Linux and borg installed to have a handy recovery setup ready to use in case of emergency.

Consider your threat model, YMMV, happy Borg-ing.

Related posts

Écriture inclusive et risques de sécurité

Je ne vais pas rentrer dans le débat du pour ou contre l’écriture inclusive. Mon propos est ici d’étudier l’impact d’une forme de graphie utilisée dans le cadre de l’écriture inclusive française sur la sécurité des systèmes d’information.

Il existe différentes formes ou manière de faire de l’écriture inclusive, utilisant différents artifices typographiques. Malheureusement, une des formes les plus élémentaires - celle qui utilise le point de ponctuation pour séparer les blocs - crée parfois des noms de domaines, comme par exemple : enseignant.es, doctorant.es, etc.

L’auteur d’un texte rédigé avec cette forme d’écriture inclusive peut donc se trouver rapidement à truffer sa prose de noms de domaine espagnols. Dans le cas d’un support totalement maîtrisé comme le papier ou l’image, l’impact est faible car le texte n’est pas immédiatement accessible à la machine. Il faudrait opérer une reconnaissance optique de caractère pour retrouver un texte électronique exploitable.

Malheureusement pour cette forme d’écriture, les supports numériques prévalent de plus en plus, et la maîtrise du support disparaît presque totalement au profit d’intermédiaires, de médias, qui peuvent décider d’améliorer l’expérience utilisateur sans demander son avis à l’auteur initial. Que cet intermédiaire soit un logiciel bureautique, un CMS, une plateforme de réseau social, une application de SMS, une messagerie instantanée, etc. nombreux sont ceux qui vont s’arroger le droit d’activer les URL qu’ils détectent dans les contenus soumis. Ainsi, quand un auteur écrit que « les étudiant.es peuvent se porter candidat.es au concours d’infirmier.es », il est bien possible que le média de publication informe les lecteurs que « les étudiant.es peuvent se porter candidat.es au concours d’infirmier.es ». La différence est de taille : les mots suffixés en .es sont devenus des URL actives.

Qui dit URL actives dit aussi : téléchargement d’un aperçu, possibilité de clic volontaire ou non sur une de ces URL, et dans des cas rares de vulnérabilité logicielle, possibilité de téléchargement de l’URL sans clic de la part du lecteur.

À titre de démonstration et d'expérience j'ai personnellement enregistré les noms étudiant.es et enseignant.es, puis je les ai faits pointer sur une page web que je maîtrise pour mesurer le comportement des utilisateurs en présence de ces noms de domaines. Sur une période de 31 jours, je mesure 5265 requêtes GET tous visiteurs confondus (avec une majorité de robots donc). Sur la même période, je mesure environ 350 visiteurs réels, soit plus de 10 par jour en moyenne, et avec un pic à 54 visiteurs un jour particulier.

Nombre de "GET" par jour sur étudiant.es et enseignant.es

Nombre de "GET" par jour sur étudiant.es et enseignant.es

Estimation du nombre de "vrais visiteurs" par jour sur étudiant.es et enseignant.es

Les traces sur le serveur web montrent aussi qu'un grand nombre des requêtes de robots sont faites par des plateformes de réseau social, au moment où ces plateformes analysent le lien posté par l'utilisateur (création de l'aperçu, de l'URL raccourcie, détection de malware, analyse du contenu promu par l'utilisateur, etc.). Par exemple : Twitterbot, Facebookbot, EveryoneSocialBot, et autres.

L’URL ainsi activée va en général se retrouver sur des supports largement diffusés. On peut penser notamment à un CMS d’institution, mais aussi à des documents PDF, des emails, des messages diffusés sur des plateformes de réseau social comme Facebook, Twitter, Linked’In. Dans une grande université française, un seul auteur peut ainsi toucher directement 20000 à 60000 individus, et indirectement bien plus.

Il est donc normal dans un tel contexte d’envisager ce qu’il se passerait si par exemple quelqu’un décidait d’enregistrer tout ou partie de ces noms de domaines espagnols pour faire des choses avec :

  • Faire du profit (affichage de publicité, vente de contrefaçon, pornographie, etc.)
  • Attaquer les lecteurs de certains contenus en distribuant des malwares
  • Lancer une campagne de phishing contre les lecteurs de ces contenus
  • Porter atteinte à l’image de l’auteur (incitation à la haine, diffamation, etc.)

L’attaque en elle-même est extrêmement simple et économique. La location d’un nom de domaine à l’année coûte une poignée d’euros, et la plupart de ces mots français sont disponibles en .es. Par ailleurs, elle peut se produire à tout moment, et le plus tard est même le mieux : plus le nom de domaine est répandu, plus il est diffusé largement et dans un grand nombre de documents et supports, plus son exploitation devient intéressante.

Comme évoqué ci-dessus, les motivations de l’attaquant peuvent être diverses, néanmoins les effets de l’attaque sur l’auteur ou sur son entreprise/institution sont toujours les mêmes. Inévitablement il se produit un dégât d’image : personne ne trouverait normal en cliquant sur le mot canditat.es dans une communication officielle d’entreprise d’arriver sur un site pornographique (sauf bien évidemment si cette entreprise gère le site en question). Idem si le lecteur voit son antivirus passer au rouge suite à un clic sur infirmier.es.

Ensuite, il peut se produire une perte pour l’entreprise ou pour l’auteur : perte de temps et d’argent car il faut rapidement neutraliser les documents ou les URL dans les documents publiés. Cette opération curative est indispensable, mais impossible en pratique à faire en totalité : en effet il est impossible d’aller modifier les emails déjà envoyés, les documents PDF ou bureautique déjà téléchargés par le public, les SMS, etc.

Si l’attaquant a choisi une posture très offensive en faisant pointer les URL vers des malwares, alors l’auteur des contenus entre dans un nouveau cercle des Enfers : il pourra être amené à découvrir ce qu’il se produit lorsque Google décide de faire disparaître son site web des résultats de recherche, ce qu’il se produit quand tous les antispam de la planète décident de bloquer les emails qu’il envoie. Le blocage ne sera pas immédiat bien sûr, laissant à l’attaquant une fenêtre de tir pendant laquelle il pourra infecter d’innocents lecteurs. D’une pierre deux coups, en quelques sortes. Je n’ai pas de certitude sur le comportement des réseaux sociaux dans ce cas de figure, mais il est possible que certains décident de supprimer les messages contenant des liens vers des malwares, que d'autres suspendent le compte de l'auteur. Autant dire que tout à coup, les choses vont devenir très compliquées pour l’auteur.

À mon avis, il y a ici un risque qui vaut la peine d'être pris en compte. Même si on constate que le nombre de clics volontaires ou non sur ces liens automatiques est relativement faible, il reste très largement supérieur au "taux de conversion" habituel d'une campagne de phishing par email. Et nous protégeons tous nos utilisateurs contre le phishing, n'est-ce pas ?
Ici l'attaque part d'un support légitime, réellement écrit par son auteur : il ne s'agit pas d'un faux message de votre Support utilisateur écrit dans un français approximatif. Non, il s'agit de transformer des contenus légitimes en vecteur d'attaque sans même avoir besoin de modifier ces contenus.

À méditer.

Related posts

Data leak at Elinchrom

As I'm paranoid, I create a brand new email address each time I've got to register on a web site. It's easy enough and allows me to partition usages and detect abuse. If one of those dedicated addresses ends up in the wild (spammers for example), I just destroy it.

CCBY ©Yuri Samoilov via Flickr

CCBY ©Yuri Samoilov via Flickr

So, in 2010 I registered a support account on Elinchrom's web site with a tailored address : elinchrom (@patpro.net of course). Later, during September 2014, I've received a big spam at that address, neither from Elinchrom nor from one of their partner. After a quick search I've found many other spams blocked by my server. The earlier arrived in 2013.
I've contacted the company, explained the problem, and sent extracts from my mail server logs. After few days, they could find no evidence of a compromise or a data leak on their side. Fair enough, that's not the kind of things you can detect easily, especially if it's years old. On a side note: it's not impossible that I've used the same email address for a contest or event registration affiliated with Elinchrom but not run by them. My bad. At least, this time they deserved the benefit of the doubt.
Following this leak, I've changed the address email to elinchrom2014 (still @patpro.net) and changed the associated password.
The 31th of December 2015 I've received my very first email at this new address: a Paypal phishing attempt, out of a hacked web server somewhere…

As I'm super-vigilant since 2014 not to use this address anywhere, the only possible scenario is a data leak at Elinchrom. Going back into my logs, I've found the earliest spam blocked dated from the 24th of October:

Oct 24 17:17:50 postfix/smtpd[84170]: NOQUEUE: reject: RCPT from unknown[]: 550 5.7.1 Client host rejected: cannot find your hostname, []; from=<apache@corp17.net4india.com> to=<elinchrom2014@...> proto=ESMTP helo=<smtp.net4india.com>

I've immediately destroyed this email address, created a new one (longer, with random characters), changed the password again.

Elinchrom: seriously, that's ridiculous, do something. Even the user authentication does not use HTTPS. WAKE UP, it's 2016.

Related posts

Un shell taillé pour le roaming, la 3G et les cages d’ascenseur

Les fans de la ligne de commande, ou ceux qui sont obligés de s'en servir, le savent : garder un shell distant ouvert et réactif peut parfois être très compliqué, voire impossible. Vous lancez une manip un peu longue mais après quelques temps vous devez changer de réseau. Vous devez intervenir d'urgence via une connexion mobile de très mauvaise qualité. Vous êtes coincé dans un ascenseur avec quelques kbps de bande passante sur un WIFI intermittent. Autant de raisons qui vous feront aimer mosh.

Mosh pour Mobile Shell, est un outil client et serveur qui supporte le roaming, et qui fonctionne particulièrement bien sur les connexions de mauvaise qualité.
L'architecture de mosh est bien pensée : elle ne nécessite pas d'intervention lourde sur vos serveurs pour en permettre l'utilisation et elle s'appuie sur un serveur ssh existant pour gérer l'initialisation de la connexion, dont la phase d'authentification.

Vous devez simplement installer mosh sur votre poste et sur votre serveur. À partir de là, la connexion fonctionne selon ce principe :
- vous lancez mosh en pointant sur votre login@serveur
- mosh ouvre une connexion ssh login@serveur ce qui permet de procéder à votre authentification
- dès que vous êtes authentifié, mosh lance mosh-server sur le serveur, sous votre UID
- mosh ferme la connexion ssh, et passe la main au mosh-client
- mosh-client se connecte en UDP sur votre mosh-server distant.

Bien sûr, les paquets UDP sont chiffrés, garantissant la sécurité de la connexion. Mosh dispose aussi d'une fonction local-echo très utile sur les liens à forte latence : vous voyez ce que vous tapez immédiatement, contrairement à ce qu'il se passe sur une connexion ssh, où votre entrée devra arriver sur le serveur, être traitée, être renvoyée à votre terminal puis enfin affichée. Cela ajoute un agrément très appréciable sur les lignes très lente ou de mauvaise qualité.

Aussi, l'utilisation de l'UDP, un protocole non-connecté, autorise une implémentation simple de l'itinérance. Plus de problème quand votre portable change de réseau Wifi, passe de l'ethernet à la 4G, etc. Votre connexion avec le serveur reste ouverte, et utilisable dès que le réseau est disponible.

J'encourage vivement les curieux à approfondir les aspects techniques, c'est intéressant et innovant.
Attention cependant, mosh ne supporte pas les utilisations non-intéractives de ssh : scp, les tunnels, X-Forwarding… C'est vraiment fait - actuellement - pour remplacer la bonne vieille session interactive.

Les binaires sont disponibles pour de nombreuses plateformes, même pour Mac OS X 10.5... vous n'avez plus aucune excuse.

Related posts

Rotation des clés DKIM

La signature des emails par clé DKIM est une composante importante d'un système de messagerie sain et bien géré. Comme tout système cryptographique fonctionnant sur la base d'un couple clé publique / clé privée, il est nécessaire de renouveler les jeux de clés régulièrement.
En effet, plus longtemps une même clé est utilisée, plus elle a de chance d'être cassée. De la même manière, plus elle est petite, plus elle sera facilement cassée.
Comme toujours, avec la correspondance par email, rien n'est instantané. Contrairement à un serveur web par exemple qui pourrait changer de certificat SSL en quelques minutes et faire immédiatement disparaître l'ancien de la circulation, les clés DKIM doivent changer selon un roulement tuilé : quand la nouvelle clé remplace l'ancienne, cette dernière doit rester disponible encore quelques temps pour permettre la validation des signatures présentes dans des messages encore en cours de livraison.
Ainsi, le besoin de faire tourner régulièrement les clés DKIM tout en garantissant un tuilage, ajouté à la complexité (relative) d'une architecture mixte à base de serveur DNS, serveur de mail, logiciel de signature DKIM, rendent nécessaire la mise en place d'une procédure claire, fiable et automatique.

Évolution de l'utilisation de DKIM mesurée au niveau de l'antispam en entrée de mon serveur de mails

Évolution de l'utilisation de DKIM mesurée au niveau de l'antispam en entrée de mon serveur de mails, entre fin 2005 et début 2015

Pour mes propres besoins, j'ai conçu un script shell utilisable pour faire tourner les clés d'un domaine donné. Ce script s'appuie sur un serveur Bind local : la modification des zones DNS se fait par modification directe des fichiers. Il utilise l'implémentation DKIM de OpenDKIM.
Il serait tout à fait possible de concevoir un script qui utilise un serveur DNS distant ou local via la commande nsupdate(8), mais cette approche laisse la main totalement à Bind pour l'écriture des fichiers de zones. Il fait alors disparaître tous les commentaires, il change l'ordre des enregistrements, etc. Ce n'était pas souhaitable pour moi qui stocke des informations en commentaire dans mes fichiers de zones.

Prérequis pour utiliser ce script

- Être root sur le serveur ;
- Disposer d'un serveur DNS Bind, ou compatible (c'est OpenDKIM qui écrit les enregistrements DNS), maître pour les zones concernées par la rotation de clés ;
- Disposer sur la même machine d'une installation OpenDKIM fonctionnelle ;
- Avoir une version de sed qui supporte l'option -i (in place).


Le premier argument obligatoire du script est l'action : renouvellement ("new") ou nettoyage ("clean"). Le second argument obligatoire est le domaine cible et le troisième argument (facultatif) est la longueur des nouvelles clés.
Pour l'action "new" et un domaine donné, le script renouvelle l'ensemble des clés DKIM. Par défaut, il génère des clés de la même longueur que celles qu'il remplace, et les sélecteurs sont nommés en `date "+%Y%m"` suivi d'un tiret et des 8 premiers caractères retournés par la commande uuidgen(1). Si une longueur de clé est imposée en argument, l'ensemble des clés du domaine utilisera cette nouvelle valeur. Pour l'action "clean" et un domaine donné, le script vidange les anciennes clés.
Pour assurer un tuilage d'une semaine par exemple, il faut donc le jour J lancer le script avec "new", et à J+7 lancer le script avec "clean" sur le même domaine. Ainsi, avant le jour J, la clé N est utilisée pour signer les messages. À partir du jour J, la clé N+1 est utilisée pour signer les messages, mais la clé N est encore disponible pour vérifier de vieux messages qui seraient encore en circulation. À partir de J+7, l'ancienne clé N disparaît.

Syntaxe des fichiers de zone DNS

Deux contraintes ici :
- Le numéro de série de la zone doit être seul sur sa ligne et suivi du commentaire " ; Serial" pour que le script puisse facilement le localiser et l'incrémenter.
- Les enregistrements DNS des clés DKIM doivent être en inclusion dans le fichier de la zone et résider respectivement dans le fichier dkim-active.${DOMAIN} pour les clés actives et dans le fichier dkim-retired.${DOMAIN} pour les clés inactives. Cela donne pour le fichier de zone patpro.net :

$INCLUDE "/etc/namedb/master/dkim-active.patpro.net"
$INCLUDE "/etc/namedb/master/dkim-retired.patpro.net"

Ainsi, le script peut très facilement déplacer les clés actives vers le fichier dkim-retired quand de nouvelles clés sont fabriquées et intégrées à dkim-active.


Les clés doivent être rangées par domaine, dans des répertoires qui portent le nom du domaine. Cela donne chez moi :


Les clés utilisées doivent être référencées dans un fichier KeyTable unique que le script analyse pour retrouver les sélecteurs à remplacer, et réécrit avec les nouveaux sélecteurs.


crontab pour renouvellement automatique mensuel :

0 0 1 * *    /usr/local/sbin/rotate-dkim.sh new patpro.net
0 0 8 * *    /usr/local/sbin/rotate-dkim.sh clean patpro.net

ligne de commande pour changer la taille des clés d'un domaine :

rotate-dkim.sh new proniewski.net 2048

Corpus Scripti

# rotate DKIM keys
# settings
NBITS=${3}; NBITS=$(( $NBITS+0 )) # force number

onerror() {
case "$1" in
		echo "usage: $(basename $0) new|clean domain.name [bits]"; exit 1
		echo "\$CHROOT must exist and be a directory"; exit 1
		echo "opendkim-genkey not found or not executable"; exit 1
		echo "KeyTable not found"; exit 1
		echo "\$ZONEROOT must exist and be a directory"; exit 1
		echo "User and group must exist"; exit 1
		echo "\$ARCHIVE must exist and be a directory"; exit 1
		echo "Bits length must be greater than $MINKEY, and should not be greater than $MAXKEY"; exit 1

# Checks
[ $# -ge 2 ] || onerror "args"
[ ${ACTION} = "new" -o ${ACTION} = "clean" ] || onerror "args"
[ -d ${CHROOT} ] || onerror "chroot"
[ -d ${ZONEROOT} ] || onerror "zoneroot"
[ -d ${ARCHIVE} ] || onerror "archive"
[ -x ${GENKEY} ] || onerror "genkey"
[ -f ${KeyTable} ] || onerror "ktable"
pw usershow ${USERGROUP/:*/} >/dev/null 2>&1 || onerror "usergroup"
pw groupshow ${USERGROUP/*:/} >/dev/null 2>&1 || onerror "usergroup"
if [ $NBITS -ne 0 ]; then
	[ $NBITS -gt $MINKEY ] || onerror "nbits"
	[ $NBITS -le $MAXKEY ] || onerror "nbits"

archive() {
	echo "Putting away files for old DKIM selector ${1}"
	mv -v ${CHROOT}/${DOMAIN}/${1}.* ${ARCHIVE}

if [ ${ACTION} = "new" ]; then
	# Keytable: update SELECTOR
	# structure: 
	# arbitrary-name signing-domain:selector:keypath
	# for each line matching DOMAIN: 
	# - get SELECTOR. 
	# - key path derived from CHROOT/SELECTOR

	SELECTORLIST=( $(awk '/^[^#].* '${DOMAIN}':/ {split($2,a,":"); print a[2]}' ${KeyTable}) )

	# for each SELECTOR we must:
	# - destroy/archive private key 
	# - create a new SELECTOR + key + DNS
	# - rewrite KeyTable
	echo ""
	echo "Selector list for domain $DOMAIN has ${#SELECTORLIST[*]} member-s, lets renew each one:"
		if [ $NBITS -ne 0 ]; then
			echo "Bits length set on command line to ${NBITS}, overriding current private key bits length"
			echo -n "Get bits length for private key ${OLDSELECTOR}.private: "
			BITS=$(openssl rsa -in ${CHROOT}/${DOMAIN}/${OLDSELECTOR}.private -text -noout | awk '/Private-Key/ {gsub(/[^0-9]/,"",$2); print $2}')
			echo "$BITS"
		echo -n "Create new selector: "
		SELECTOR="$(date "+%Y%m")-${UUID/-*/}"
		echo "${SELECTOR}"
		echo "Create new private key with ${SELECTOR}:"
		${GENKEY} -v -b ${BITS} -d ${DOMAIN} -D ${CHROOT}/${DOMAIN} -r -s ${SELECTOR}
		# permission adjustments:
		chmod u=r,g=r ${CHROOT}/${DOMAIN}/${SELECTOR}.*
		ls -l ${CHROOT}/${DOMAIN}/${SELECTOR}.*
		echo -n "Update KeyTable: "
		sed -i .bkp -e 's/'$OLDSELECTOR'/'${SELECTOR}'/g' ${KeyTable}
		[ $? -eq 0 ] && echo "OK"
		archive ${OLDSELECTOR}
	echo ""
	echo "End of selector renewal."
	# every SELECTOR for DOMAIN is updated, now deal with DNS

echo ""
# calculate new serial for zone $DOMAIN
echo -n "Get old DNS zone serial for ${DOMAIN} and increment: "
NEWSERIAL=$(date +%Y%m%d%I)
OLDSERIAL=$(awk '/ ; Serial/ {print $1}' ${ZONEROOT}/${DOMAIN})
while [ $OLDSERIAL -ge $NEWSERIAL ]; do
# Update SERIAL of DNS zone.
echo -n "Change serial in zone file: "
sed -i .bkp -e 's/'$OLDSERIAL' ; Serial/'${NEWSERIAL}' ; Serial/g' ${ZONEROOT}/${DOMAIN}
[ $? -eq 0 ] && echo "OK"

if [ ${ACTION} = "new" ]; then
	echo -n "Move old public keys to dkim-retired.${DOMAIN}: "
	cat ${ZONEROOT}/dkim-active.${DOMAIN} > ${ZONEROOT}/dkim-retired.${DOMAIN}
	[ $? -eq 0 ] && echo "OK"
	echo -n "Copy new public keys to dkim-active.${DOMAIN}: "
	cat ${CHROOT}/${DOMAIN}/*.txt > ${ZONEROOT}/dkim-active.${DOMAIN}
	[ $? -eq 0 ] && echo "OK"
elif [ ${ACTION} = "clean" ]; then
	echo -n "Clean old public keys of dkim-retired.${DOMAIN}: "
	echo "" > ${ZONEROOT}/dkim-retired.${DOMAIN}
	[ $? -eq 0 ] && echo "OK"

echo ""
echo "Everything looks good, lets refresh world:"
named-checkzone ${DOMAIN} ${ZONEROOT}/${DOMAIN}
service named restart
[ ${ACTION} = "new" ] && service milter-opendkim restart

Les commentaires dans le code sont suffisants pour expliquer chaque étape du déroulement du script.


M3AAWG DKIM Key Rotation Best Common Practices (PDF)

Related posts