IMPRESSION. 

Les fonctions d'impression étaient prises en charge par un logiciel déjà ancien (TurboPrint) j'ai décidé de passer à CUPS comme pour mes autres machines. 
J'ai donc chargé le paquet cups et configuré (http://localhost:631 pour accéder à la partie administration de CUPS) ma brave imprimante HP950C parfaitement reconnue en standard par le logiciel, il suffit de choisir le fabricant et le modèle dans la liste proposée. Le test d'impression est probant, cela fonctionne parfaitement. 
Il faut ensuite modifier le paramétrage des autres machines du réseau pour laisser tomber le vieux serveur.

• Machines Linux :

Passage par http://localhost:631 puis l'onglet administration qui nous propoe le sympathique bouton "Find new printer" sur lequel je m'empresse d'appuyer, la suite est à peu près "idiot proof" et l'imprimante est configurée dans la foulée. 
Le test est parfait, les couleurs sont impeccables, la vitesse bien meilleure qu'avant ...

• Machines Windows (beurk)

Ici afin de simplifier les choses, il faut d'abord avoir configuré SAMBA sur le serveur d'impression en y mettant la bonne configuration d'impression dans le fichier "/ec/samba/smb.conf" (pour Debian) : 

# CUPS printing.  See also the cupsaddsmb(8) manpage in the 
# cupsys-client package. 
   printing = cups 
   printcap name = cups 

Lorsque ceci est fait un petit restart de samba permettra de "voir" l'imprimante sur les machins Windows pour les configurer à la sauce Microsoft. 

ANNUAIRE LDAP. 

Zimbra possède son propre annuaire LDAP mais je n'ai pas voulu prendre le risque d'intégrer mon annuaire dans celui de ZIMBRA. 
Openldap fonctionne par défaut sur le port 389 (en non sécurisé) et 636 (sécurisé), il faut forcer mon annuaire à utiliser d'autres ports. 
Cela se réalise facilement (merci Debian) par un petit ajout dans le fichier "/etc/default/slapd"  : 

# slapd normally serves ldap only on all TCP-ports 389. slapd can also 
# service requests on TCP-port 636 (ldaps) and requests via unix 
# sockets. 
# Example usage: 
# SLAPD_SERVICES="ldap://127.0.0.1:389/ ldaps:/// ldapi:///" 
SLAPD_SERVICES="ldap://192.168.1.11:489 ldaps://192.168.1.11:736 " 

Un petit coup de "/etc/init.d/slapd start" et c'est OK, mon slapd écoute sur le port 489 : 
lsof -Pn | grep 489 
hald       2732  haldaemon  mem       REG        9,0    548929      28524 /usr/share/misc/pci.ids 
slapd      4452   openldap    8u     IPv4    1645675                  TCP 192.168.1.11:489 (LISTEN) 

Il suffir ensuite de "recharger" une sauvegarde au format "ldif" réalisée sur l'ancien serveur : 
/usr/sbin/slapcat -b "dc=chezmoi,dc=org"  -l 'DumpLDAP.ldif' 

de transférer ce fichier sur le nouveau serveur, de stopper le service "slapd" et de lancer la commande : 

slapadd -f /etc/ldap/slapd.conf -l DumpLDAP.ldif 

Ensuite un redémarrage du service "slapd" permet de récupérer un accès "normal" à tutes mes adresses stockées depuis les clients mail en modifiant le serveur de référence et le port. 
 

La "folie" du port 23 dure encore et toujours, la preuve ce graphe par date des "hits" sur les ports 23 et 2323 depuis le 2 août 2016 jusqu'au 1er novembre 2017.. Une remontée visible sur fin octobre 2017 est visible, se confirmera-t-elle ?

Il semble néanmoins que la période de folie de fin 2016 soit légèrement passée, la baisse fin janvier/début février est due à un défaut d'enregistrement, comme celle de mi-septembre correspondant à des vacances en des lieux assez éloignés. 
Ces chiffres sont obtenus à partir des données enregistrées par NtopNG et concernent actuellement près de 340 000 adresses IP différentes et plus de 45 millions d'événements réseau. Oui la base commence à gonfler sérieusement et je ne fais plus ces statistiques sur la machine de "production".

Par pays (limité aux 25 "premiers") on voit que la Chine et le Brésil on nettement dépassé le Viet Nam depuis les résultats précédents, l'Inde effectue une belle remontée. En bas de peloton (non visible ici) on trouve Nauru, Anguilla et le Lesotho avec une IP et un paquet chacun.