Blog de Thomas Martin

Il y a quelques semaines de cela, j'ai rencontré quelques difficultés pour intégrer un filer NetAPP FAS2020 sur un contrôleur de domaine Samba. La solution au problème ayant été quelques peu hasardeuse, je la partage ici dans l'espoir que cela puisse épargner quelques heures à certains...

En effet, l'intégration d'un client Windows sur un contrôleur de domaine Samba nécessite généralement la création préalable d'un compte machine. Celui-ci est généralement créé sans définir de mot de passe (champ sambaNTPassword lorsqu'on utilise un backend LDAP), et lors de l'intégration au domaine, le client Windows se charge de le définir.

Or, avec ce filer NetAPP, voici les logs résultant :

[2010/12/16 15:16:58.713732,  2] passdb/pdb_ldap.c:572(init_sam_from_ldap) init_sam_from_ldap: Entry found for user: NETAPP$
[2010/12/16 15:16:58.716788,  0] rpc_server/srv_netlog_nt.c:526(get_md4pw) get_md4pw: Workstation NETAPP$: account does not have a password

Si le compte machine est créé avec un mot de passe aléatoire :

[2010/12/16 15:24:59.641552,  2] ../libcli/auth/credentials.c:307(netlogon_creds_server_check_internal) credentials check failed
[2010/12/16 15:24:59.641572,  0] rpc_server/srv_netlog_nt.c:714(_netr_ServerAuthenticate3) _netr_ServerAuthenticate2: netlogon_creds_server_check failed. Rejecting auth request from client NETAPP machine account NETAPP$

Si le compte machine n'est pas créé :

[2010/12/16 15:16:33.181347,  0] rpc_server/srv_netlog_nt.c:475(get_md4pw) get_md4pw: Workstation NETAPP$: no account in domain
[2010/12/16 15:16:33.181388,  0] rpc_server/srv_netlog_nt.c:692(_netr_ServerAuthenticate3) _netr_ServerAuthenticate2: failed to get machine password for account NETAPP$: NT_STATUS_ACCESS_DENIED

Finalement, au détour d'un forum, j'ai trouvé la solution suivante : le mot de passe doit être initialisé avec une valeur identique au nom de la machine, sans le $ final, et sans majuscule. Dans cet exemple, le mot de passe sera donc netapp. On constate alors :

[2010/12/16 15:28:38.139866,  3] rpc_server/srv_netlog_nt.c:947(_netr_ServerPasswordSet) _netr_ServerPasswordSet: Server Password Set by remote machine:[NETAPP] on account [NETAPP]

Les utilisateurs de RRDtool peuvent un jour être confrontés à l'erreur suivante lors d'une migration d'un serveur à un autre : This RRD was created on another architecture. La raison est que le format RRD est dépendant de l'architecture matérielle : Un RRD créé sur une machine 32 bits ne pourra pas être lu sur une machine 64 bits.

Cependant, il est possible d'extraire le contenu d'un RRD vers un format XML. Cela se fait via la commande suivante à exécuter sur une architecture identique à celle ayant créé le fichier :

rrdtool dump example.rrd >example.xml

On obtient alors un fichier commençant ainsi :

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rrd SYSTEM "http://oss.oetiker.ch/rrdtool/rrdtool.dtd">
<!-- Round Robin Database Dump --><rrd> <version> 0003 </version>
        <step> 300 </step> <!-- Seconds -->
        <lastupdate> 1234211704 </lastupdate> <!-- 2009-02-09 21:35:04 CET -->

Pour le réimporter sur la machine cible :

rrdtool restore example.xml example.rrd

Vous déclarez peut-être un umask restrictif dans le fichier de configuration de votre shell (.bashrc, .cshrc, etc), 077 par exemple.
Si c'est le cas, attention lorsque vous effectuez une mise-à-jour de votre système OpenBSD (ou potentiellement d'un autre système BSD). En effet, si vous utilisez une commande tel que sudo -s pour passer root, afin d'effectuer la copie des nouveaux fichiers de configuration du système de base, ou avant d'exécuter pkg_add -ui pour mettre les packages à jour, votre umask sera pris en compte. La conséquence est que des fichiers qui sont normalement accessibles à tous les utilisateurs, par exemple /etc/mutt/Muttrc ou /etc/screenrc, seront affectés par cet umask, et se retrouveront avec des permissions à priori incorrectes, qui empêcheront leur lecture par un simple utilisateur.

Conclusion : dans ces cas là, utilisez plutôt su(1), sudo -i, ou sudo su, et vérifiez l'umask avant de commencer la procédure d'upgrade. Ou alors attendez-vous à recevoir quelques plaintes de vos utilisateurs, et à devoir effectuer quelques chmod(1) !



J'ai utilisé pendant 2 bonnes années le logiciel Chronicle pour générer ce blog. A l'époque, je l'avais sélectionné pour sa capacité à générer des fichiers statiques HTML à partir de fichiers plats, que je pouvais stocker dans mon dépôt SVN personnel. Cela était intéressant, mais les désavantages se sont fait sentir avec le temps : gestion des commentaires (très) complexe, au point que j'avais rapidement fait le choix de les désactiver, difficultés dès qu'il s'agissait de mettre en place une nouvelle fonctionnalité ou un changement graphique, etc

J'ai donc opté pour une bascule vers le bien connu Dotclear, que j'ai apprivoisé les semaines précédentes, avant de le passer en production aujourd'hui. La fonctionnalité d'import par flux RSS est vraiment très efficace, et il m'a suffit de valider rapidement chaque article importé. Quelques redirections HTTP avec Apache pour conserver la validité des URL de l'ancien blog, et le tour est joué ! J'ai également sélectionné un thème parmi ceux proposés par Dotaddict, qui me parait pas mal pour commencer, mais qui devrait être amené à évoluer d'ici quelques temps...

Quant aux commentaires, ils sont réouverts, donc n'hésitez pas !

Introduction

La sauvegarde de la configuration des équipements réseaux (switch, routeurs, bornes Wi-Fi, etc) est un point souvent négligé. Pourtant, ces équipements jouent souvent un rôle clé, et l'incapacité de restaurer rapidement la configuration suite à un crash matériel peut provoquer la paralysie d'un réseau pendant de longues heures. Cette sauvegarde est parfois faite de façon manuelle après la phase initiale de configuration, avec le risque d'oublier de le faire lors des prochaines modifications. Il est donc préférable, lorsque l'équipement le permet, d'effectuer cette sauvegarde de façon automatique et récurrente vers une machine distante. Voyons comment faire cela sous Cisco IOS, en utilisant le planificateur de tâches Kron, semblable au programme Cron en environnement Unix.

Mise en place

Une fois connecté au Cisco avec Telnet ou SSH, on passe en mode administrateur, puis en mode config :

switch> enable
switch# conf t

On crée une nouvelle policy-list pour Kron, nommée backupConfig, qui sera composée d'une ou plusieurs commandes à exécuter :

switch(config)# kron policy-list backupConfig

On utilise la commande cli pour ajouter une commande dans notre policy. Cette commande utilisera show running-config afin d'écrire la configuration courante sur la sortie standard (on pourrait aussi utiliser show startup-config pour écrire la configuration stockée en mémoire flash). Ensuite, l'opérateur pipe (|) est utilisé pour rediriger cette sortie vers la commande redirect, qui permet de rediriger un flux vers un serveur FTP, HTTP, TFTP, etc. On utilise ici un stockage vers un serveur FTP :

switch(config-kron-policy)# cli show running-config | redirect ftp://<host>/<path>/cisco.txt
switch(config-kron-policy)# exit

On définit maintenant à quel moment exécuter cette policy. Pour cela on créé une occurrence nommée backupConfig_occurence. Dans cet exemple ce sera à 01h15, chaque jour (mot-clé recurring) :

switch(config)# kron occurrence backupConfig_occurence at 01:15 recurring
switch(config-kron-occurrence)# policy-list backupConfig
switch(config-kron-occurrence)# exit
switch(config)# exit

Pour vérifier la bonne prise en compte de notre tâche, et voir le délai avant son exécution :

switch# show kron schedule

Voilà, il ne reste plus qu'à attendre l'heure programmée, et vérifier la présence du fichier envoyé. Le bon fonctionnement de tout cela nécessitant que le Cisco soit pleinement configuré (date et heure, adresse IP, passerelle réseau, DNS, etc).

Enfin, tout cela ne dispense bien sûr pas de sauvegarder cette nouvelle configuration en mémoire flash en prévision d'un futur reboot :

switch# write mem