Re: pbuilder et backports
Hello, Pour la dépendance, tu dois pouvoir t'en sortir en indiquant à pbuilder d'ajouter un repo debian aux repos par défaut. Ça se fait avec l'option OTHERMIRROR dans /etc/pbuilderrc Pour le build taggué backport, la solution la plus simple que je connaisse et de produire un paquet source lui même taggué en backport. Si tu utilises gbp, la commande gbp dch -R --bpo devrait faire le job. ++ JB On 23/01/2017 14:07, Damien TOURDE wrote: > Bonjour, > > J'aimerais me créer un paquet .deb d'un soft dont l'une des BuildDeps ne > se trouve que sur jessie-backports (et sid et testing). > > Donc j'aurais bien aimé savoir si quelqu'un savait comment "simplement" > utiliser pbuilder en lui spécifiant cette dépendance mais en faisant un > build taggué "jessie-backports" et non "sid" comme par défaut. > > > Je ne sais pas si ma demande est très claire, mais pbuilder ne l'est pas > encore vraiment pour moi non-plus :-) >
Re: IP flottante du pauvre
Le 24/01/2017 à 15:35, Olivier a écrit : Bonjour, Bonjour [...] Ça semble répondre à mon besoin mais pas complètement car, si j'ai bien bien compris, ces outils tout comme les ucarp et keepalived, exigent une communication permanente entre une machine active et une machine passive alors que dans mon cas, la machine passive n'existe pas encore et je veux simplement prévoir sa future existence. [...] ucarp avec une seule machine fonctionne: elle sera maitre et ne s'occupe de rien, pas d'autre exigence. C'est la passive qui s'occupe de reprendre la main si l'active ne répond plus. J'ai développé il y a quelques années des scripts afin d'automatiser le up/down des interfaces et la gestion des services à arrêter/redémarrer. Je les tiens à ta disposition si tu es intéressé. -- Daniel
IP flottante du pauvre
Bonjour, Pour une nouvelle machine que je vais bientôt mettre en service, je souhaite mettre en place un mécanisme d'IP flottante qui m'aiderait, le jour venu, à basculer la production de la nouvelle machine vers une autre machine la remplaçant. J'imagine que chaque machine aurait une IP (privée) qui lui soit spécifique et persistante qu'ainsi qu'une IP (privée) qu'elle pourrait un jour accaparer ou abandonner au profit d'une autre machine selon qu'elle aurait ou non à produire certains services. J'ai vu brièvement à l'oeuvre ce genre de basculement avec pacemaker et corosync. Ça semble répondre à mon besoin mais pas complètement car, si j'ai bien bien compris, ces outils tout comme les ucarp et keepalived, exigent une communication permanente entre une machine active et une machine passive alors que dans mon cas, la machine passive n'existe pas encore et je veux simplement prévoir sa future existence. Plus concrètement, j'imaginais simplement: - lister les services qui doivent pouvoir migrer d'une machine à l'autre - vérifier que chacun de ces services peut être configuré pour utiliser l'IP flottante plutôt que l'IP persistante, - trouver un mécanisme pour basculer simplement les ressources (IP flottante) et services d'une machine à l'autre. Pour ce dernier mécanisme, j'imagine rédiger un script pour lancer ou arrêter la production. Bâti à coup d'appels à ifup/idown et systemctl enable/disable/start/stop, le script n'a pas besoin d'être très rapide (20s pour s'exécuter me parait acceptable). Avec un peu de chance, le script pourrait tourner sans modification sur une machine de remplacement dotée d'une version différente de Debian. Qu'en pensez-vous ? Des suggestions ou recommandations ? Slts
