Hobgoblins Master a écrit 726 commentaires

Ça me parait intéressant à première vue, même si j’ai encore du mal à voir toutes les implications sans avoir joué avec :-)

Ah, et j’avais oublié, serait-il possible d’utiliser des requêtes AJAX pour les bouton lu/non lu, favoris et supprimer ? on y gagnerait beaucoup sur mobile dans le train avec une connexion poussive ;-)

Je viens de l’installer, avec l’appli android et le xpi pour firefox, et du même coup, j’ai migré et supprimé mon compte pocket.

Ça marche bien, ça fait le boulot, juste quelques suggestions pour les futures versions 

• Pouvoir avoir plusieurs comptes sur une instance (une pour chaque membre de la famille par exemple.
• La possibilité d’ajouter des tags.
• La consultation hors ligne (à mon avis en html5 plutôt que dupliquer le travail entre les différents extensions (xpi,apk…)).

J’en ai profité pour signaler un bug en https… ☺

En navigant avec le clavier (< > et [ ]), la différence peut rester subtile dans la feuille de style…

Ce fichier lock (le lien symbolique est créé par thunderbird/icedove au démarrage, et supprimé à l’arrêt, c’est justement ce qui lui permet de savoir qu’il est déjà lancé. Après pourquoi ils se prennent la tête à créer un lien symbolique vers un fichier qui n’existe pas et dont le nom est l’IP de la machine et le PID du process thunderbird/icedove…

Petite question, lors de ton transfert, thunderbird n’était pas arrêté ?

À supprimer si tu n’as aucune instance de icedove démarrée

Avec mon icedove qui tourne, j’ai un lien symbolique dans mon répertoire de profile de lock vers echo $(getent hosts $(hostname) |cut -f1 -d' '):+$(pgrep icedove).

Pour la lib en effet si les AXFR et nsupdates sont fait en backends, il vaut mieux utiliser le module python équivalent, je m’attendais à ce que ce soit fait directement par le frontend php.

Si je trouve un peu de temps, je regarderais les code des classes SSH…

Pour la partie DNS, je ne sais pas si les ACLs Bind permettent d’atteindre une granularité intéressante sans devenir d’une complexité sans nom, je pense qu’il faut que les fichiers de conf restent lisibles par un humain. Côté conf, il n’y a pas tant de type de clusters que ça, il faut prévoir je pense une conf master / slave classique et une où le maître est caché. Il faut penser aussi à la possibilité de faire du ou des serveurs des caches récursifs référencés dans le DHCP.

Une fois que le DNS fonctionne, je pense qu’il serait judicieux de ne plus référencer l’IP, mais le FQDN dans les réservations DHCP :

host XXXXXX {
hardware ethernet DE:AD:BE:EF:CA:FE;
fixed-address XXXXXX.YYYYYY.tld;
}

Pour la réplication de zone, si elle doit être continue, tu as regardé les enregistrements DNAME ?

Le projet semble intéressant, je vois sur le site qu’il est prévu d’ajouter la gestion de DNS bind, ça me permettrait peut-être à terme de fusionner netdisco et dynamic-dnsupdate que j’utilise aujourd’hui séparément. D’ailleurs, si tu ne connais pas, la bibliothèque utilisée par ce projet doit permettre de faire à peut-près toutes les récupérations et mises à jour de zones utilise.

Est-il possible d’ajouter soit même de nouveaux types de switchs, ou des « images de face avant » ? Est-il également possible d’utiliser des clés SSH pour les connexions aux serveurs et switchs à la place du mot de passe ?

Pour les sms, j’utilise smsd du paquet sms-tools sous debian, c’est vraiment super simple à utiliser avec les outils de supervision, il suffit de poser un fichier dans le répertoire d’envoi.
Il peut également recevoir des messages pour par exemple acquitter les alarmes…

Xtel est dispo dans les repos debian, peut-être même que le paquet debian serait installable sous Ubuntu…

Merci de débroussailler un peu le terrain, j’avais déjà entendu parler de domogik et rfxcomm. Ce dernier m’intéresse car il semble pouvoir lire les valeur de la sonde Oregon (temp, hygro et horloge) que je possède et qui n’est aujourd’hui utilisée que pour une station météo non communicante.

En effectuant des recherches supplémentaires à partir de tes indications, je suis tombé sur ça : http://maison-et-domotique.com/books/zwave-et-fil-pilote-domotiser-son-radiateur/, par contre, si je suis ça, il va me manquer au moins un module de commande à brancher sur mon serveur, et ça n’a pas l’air compatible avec rfxcomm (lequel serait le mieux d’ailleurs sachant que mon serveur est sensé rester toujours allumé et dispose d’un onduleur) ou tellstick. Le même montage serait-il possible avec 2 modules Chacon CH54755? Sachant qu’un montage complet comme celui-ci s’appuie sur le thermostat interne du radiateur (mode confort et éco), serait-ce plus intéressant de ne gérer que les mode confort et arrêt avec le thermostat interne à fond et un capteur de température externe, dans ce cas, quel type de capteur utiliser ?

Le domaine de la domotique fait vraiment jungle, il y a énormément de systèmes, mais rien ne semble compatible avec rien, et côté libre, ça me semble difficile de ne pas sortir le poste à souder…

Cette page propose des modules, mais je ne sais pas s’il sont pilotables facilement à bas de logiciels libres.

Le projet m’intérresse, parce que le but à terme, c’est de contrôler ma conso électrique, mais pour le pilotage, ça n’as pas l’air gagné sans investissement électronique, et vue que mes cours d’élec et d’embarqués sont loin, et que je n’ai pas même de quoi souder correctement une résistance sur un circuit imprimé…

J’aurais aimé éviter un montage maison, surtout que le fil pilote travaille en 230V / 50Hz, donc même s’il ne doit pas consommer trop d’intensité, je pense qu’on travaille en électronique de puissance…

Pour ce qui est de l’asservissement, je pensais mettre une sonde de température dans chaque pièce et gérer la position du radiateur (confort / éco / éteint) en fonction. Du coup, soit je laisse le thermostat du radiateur à fond, soit à une valeur un peu supérieure à la température max que je veux atteindre.

J’ai un GPS de rando garmin, je le charge avec des cartes OSM, il y a de nombreuses sources suivant les pays dont une partie est référencée ici.
Celles-ci couvrent le monde entier : http://garmin.openstreetmap.nl/.
J’aime bien celles-ci : http://www.frikart.no/garmin/index.html

Vérifie quand même avant de partir que le pays soit suffisamment avancé, que tes villes étapes soient toutes là, et avec les noms de rues renseignés. À vue de nez, l’Islande à l’air correcte, mais je ne connais pas le terrain.

Ce sont les critères d'entrée d'un algorithme d'apprentissage. Du type réseau de neurones à 8 entrées et 2 sorties je suppose. Ils ont dû le nourrir avec des AS identifiés manuellement. Puis injecté toute la base. Il en est ressorti 2 groupes, les français et les autres.

Dans le § Déploiement d’IPv6 sous l’angle du DNS, il manque <domaine> devant les .fr, j’avais dû mettre les chevrons directement et non leurs entités html…

On peut avoir un ordre de grandeur du nombre de serveurs (physiques / virtuels) et une idée des technologies client / serveur utilisées (Bases de données, serveurs d’applis web, autres technos…) ?

Le load average sous Linux représente en gros le nombre moyen de processus en attente de ressource (CPU, I/O disque, pages, I/O réseau…) sur une fenêtre glissante.
En cas de charge à 1.00, ce que j’ai vu le plus souvent :

• Un processus qui occupe un cœur à 100%
• Un problème sur un montage NFS ou autre disque (iSCSI ?)

Il faudrait voir un peu plus de la sortie de top, peut-être triés par temps processeur. Et un ps auxfe et cat /proc/mounts, voir carrément un dmesg pourraient aider à trouver le coupable…

La commande aptitude ne renvoie pas les paquets installés automatiquement en tant que dépendances (~i!~M == paquets installés non marqués auto), d’où la liste beaucoup plus modeste. De plus, l’option d’affichage -F%p évite d’avoir à traiter la sortie si on veux la réinjecter autrement que via un dpkg --set-selections && apt-get -f install. Enfin, dpkg --get-selections à tendance à tronquer certains noms de paquets un peu longs.
Si les options apt restent les mêmes concernant recommands et suggest, on doit se retrouver avec la même liste de paquets installés avec les 2 méthodes. Par contre, niveau maintenance future, je préfère ne pas perdre la marque auto, ça évite des deborphans…

Lancer une requête Livestatus, récupérer le résultat et placer ça dans un mail doit pouvoir se faire une ligne cron je pense. Comme ça, ils reçoivent à intervalle bien régulier l’état réel de leur machine.

Si tu utilises Thruk, il me semble que les dernières versions sont capables de générer des rapports PDF par mail programmables, ça peut aussi être intéressant, comme ça, ils reçoivent non seulement l’état, mais aussi l’historique sur une période donnée.

Pour Debian et dérivés, j’utilise (dans mes scripts de sauvegarde) la combinaison suivante :

# List installed aptitude packages
aptitude search -F%p ~i\!~M > /var/backups/aptitude-installed.bak

# Debconf dump
debconf-get-selections > /var/backups/debconf.bak

# Modified conf files
debsums -ce 2>/dev/null | xargs cp -vt /tmp > /var/backups/debsums.bak

/var/backups/ est à sauvegarder en entier.

Debsums zappe quand même quelques fichiers et répertoires à sauvegarder en plus par précaution :
- /etc/network/interfaces
- /etc/fstab
- /etc/lvm/backup
- /etc/apt

Bien sûr, il ne faut surtout pas oublier les données !

Pour la réinstallation, faire une installation minimale, installer le paquet debconf, exécuter debconf-set-selections debconf.bak, copier les fichiers de config à leur place et réinstaller tous les paquets avec :

aptitude install < aptitude-installed.bak

Visiblement, ça n’a pas vraiment changé… À voir si le nouvel installeur pose plusieurs versions du noyau sur le disque et si le nouveau boot manager sait sélectionner le bon, mais je n’y crois pas beaucoup.
http://en.wikipedia.org/wiki/Ntoskrnl.exe
http://en.wikipedia.org/wiki/Architecture_of_Windows_NT
http://msdn.microsoft.com/en-us/library/windows/hardware/ff547188%28v=vs.85%29.aspx

Le processus de boot et de chargement des pilotes n’a pas vraiment beaucoup évolué non plus sous Linux.

Et les différents retours d’expériences que je présente plus haut datent d’avant la sortie de Vista. Je fais des déplacements de disques, upgrades de CM sur serveurs et desktop sous Linux depuis bien 10 ans…

La grande différence entre Linux et Windows dans le cas du déplacement d’un disque d’une machine à une autre est justement dans la détection du matériel et le chargement des pilotes.

Sur une même classe de matériel, sur lequel le même noyau peut tourner (c’est à dire que pour la version X de la distribution Y, on peut installer le même paquet linux-image ou kernel-image), la détection du matériel reste dynamique et le chargement des pilotes automatique. À part dans quelques rares cas de pilotes propriétaires dont on force le chargement ou d’obscures options des modules (options au démarrage du noyau dans Grub ou /etc/modprobe.conf), la migration ne pose aucun souci. Et ces cas sont rares. Pour X, c’est de plus en plus la même chose, auto-configuration dans l’immense majorité des cas…
Et en cas de problèmes, on a presque toujours un accès en console les modifications sont souvent simples.

Le chargement des pilotes sous Windows fonctionne différemment, déjà, il y a plusieurs versions du noyau suivant le type de chipset présent sur la carte mère (4 de mémoire sous XP, en mixant 2 types de HAL avec ou sans I/O APICs), donc en gros 75 % de chances de se prendre un BSOD ;-). En suite, si la détection du matériel est automatique, les pilotes à charger sont listés dans la base de registre et Windows est capable de charger des pilotes qui ne fonctionnement pas (de belle anecdotes à la désinstallation d’un antivirus qui oubliait une fois sur deux de supprimer de la base de registre le chargement de son pilote de la pile réseau : la moitié d’un parc de 400 machines sans réseau après le reboot, création en urgence d’un script utilisant autoruns sur un cd pour nettoyer tout ça…). Il est toujours possible de récupérer le système avec un CD de rescue, installer le bon noyau, changer les options du boot.ini, installer les pilotes manquants et nettoyer les autres avec Autoruns, mais c’est loin d’être aussi simple.

Donc oui, il y a des systèmes qui se prêtent plus facilement que d’autres à la migration d’un matériel à l’autre, et c’est en grande partie structurel. Il n’y a qu’a regarder le boulot que doivent utiliser les outils de P2V suivant les Os pour faire leur boulot correctement…

Tout ça peut aussi être testé très simplement sous Virtualbox en changeant les types de matériels (notamment l’onglet « motherboard »), prévoyez les snapshots ;-)