Logiciel de gestion basique d'un onduleur "bete" sous Debian
16 réponses
Pascal Hambourg
Salut à tous,
Disposant d'un vieil onduleur "bête" ("dumb") Merlin Gerin, avec signaux
de contrôle tout ou rien qu'on peut interfacer sur un port série RS-232
via un câble adaptateur) relié à un petit serveur sous Debian lenny, je
cherche un logiciel de surveillance basique pour :
- surveiller le signal de coupure du secteur et déclencher un shutdown
au bout d'un certain temps,
- surveiller le signal de batterie faible et déclencher un shutdown
immédiat,
- envoyer un signal d'arrêt à l'onduleur lors du shutdown.
Pas besoin de fonctions réseau pour commander l'arrêt automatique
d'autres machines et autres raffinements.
J'ai identifié les paquetages suivants disponibles dans Debian
(Provides: ups-monitor) :
apcupsd - APC UPS Power Management (daemon)
genpower - Monitor UPS and handle line power failures
nut - The core system of the nut - Network UPS Tools
powstatd - Configurable UPS monitoring daemon
upsd - UPS Monitor Program via serial interface
J'exclus a priori nut qui dépend d'udev dont je ne veux pas sur ce
serveur, et apcupsd qui semble prévu spécifiquement pour les onduleurs
de marque APC et qui dépend de snmp dont je n'ai que faire. Restent
genpower, powstatd et upsd, plus éventuellement d'autres qui m'auraient
échappé. Je suis preneur d'avis de personnes connaissant ou ayant
utilisé l'un ou l'autre, sur leurs qualités et défauts éventuels.
Question subsidiaire aux utilisateurs d'onduleurs :
Comment gérez-vous le redémarrage automatique des machines secourues ?
J'explique : en cas de secteur qui fait le yoyo, si la machine secourue
redémarre immédiatement à chaque retour (provisoire) du secteur, la
batterie de l'onduleur risque de ne pas se recharger suffisamment entre
deux coupures et finir par se décharger au point que l'autonomie
pourrait ne pas suffire pour un redémarrage+arrêt complet. Y a-t-il
quelque chose de prévu pour ne redémarrer que si la batterie est
suffisamment chargée ?
Le Thu, 09 Sep 2010 18:07:30 +0200, Pascal Hambourg a écrit:
J'exclus a priori nut qui dépend d'udev dont je ne veux pas sur ce serveur,
Il va falloir s'y faire, il est devenu impossible de faire sans udev, et nut est vraiment le mieux et de loin.
-- The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man. George Bernard Shaw
Le Thu, 09 Sep 2010 18:07:30 +0200, Pascal Hambourg a écrit:
J'exclus a priori nut qui dépend d'udev dont je ne veux pas sur ce
serveur,
Il va falloir s'y faire, il est devenu impossible de faire sans udev, et
nut est vraiment le mieux et de loin.
--
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore, all
progress depends on the unreasonable man.
George Bernard Shaw
Le Thu, 09 Sep 2010 18:07:30 +0200, Pascal Hambourg a écrit:
J'exclus a priori nut qui dépend d'udev dont je ne veux pas sur ce serveur,
Il va falloir s'y faire, il est devenu impossible de faire sans udev, et nut est vraiment le mieux et de loin.
-- The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man. George Bernard Shaw
Arol
Le Thu, 09 Sep 2010 18:07:30 +0200, Pascal Hambourg a écrit:
J'exclus a priori nut qui dépend d'udev dont je ne veux pas sur ce serveur
C'est quoi le prob avec udev sur un serveur ? Il est fourni d'office avec un kernel 2.6
Le Thu, 09 Sep 2010 18:07:30 +0200, Pascal Hambourg a écrit:
J'exclus a priori nut qui dépend d'udev dont je ne veux pas sur ce
serveur
C'est quoi le prob avec udev sur un serveur ?
Il est fourni d'office avec un kernel 2.6
Le Thu, 09 Sep 2010 18:07:30 +0200, Pascal Hambourg a écrit:
J'exclus a priori nut qui dépend d'udev dont je ne veux pas sur ce serveur
C'est quoi le prob avec udev sur un serveur ? Il est fourni d'office avec un kernel 2.6
Pascal Hambourg
Arol a écrit :
Le Thu, 09 Sep 2010 18:07:30 +0200, Pascal Hambourg a écrit:
J'exclus a priori nut qui dépend d'udev dont je ne veux pas sur ce serveur
C'est quoi le prob avec udev sur un serveur ?
Je n'en ai pas besoin sur *ce* serveur et je me méfie des surprises qu'il peut provoquer. Peut-être plus tard, quand je le maîtriserai, mais pas maintenant.
Il est fourni d'office avec un kernel 2.6
Non, la preuve.
Emmanuel Florac a écrit :
Il va falloir s'y faire, il est devenu impossible de faire sans udev
J'ai pourtant réussi à faire sans jusqu'ici. Même charger les firmwares à la demande du noyau, cf. fil récent ici (grâce à l'aide de Nicolas George).
Sur ce, si on se concentrait sur le sujet, concernant les trois logiciels que j'ai retenus ? Merci.
Arol a écrit :
Le Thu, 09 Sep 2010 18:07:30 +0200, Pascal Hambourg a écrit:
J'exclus a priori nut qui dépend d'udev dont je ne veux pas sur ce
serveur
C'est quoi le prob avec udev sur un serveur ?
Je n'en ai pas besoin sur *ce* serveur et je me méfie des surprises
qu'il peut provoquer. Peut-être plus tard, quand je le maîtriserai, mais
pas maintenant.
Il est fourni d'office avec un kernel 2.6
Non, la preuve.
Emmanuel Florac a écrit :
Il va falloir s'y faire, il est devenu impossible de faire sans udev
J'ai pourtant réussi à faire sans jusqu'ici. Même charger les firmwares
à la demande du noyau, cf. fil récent ici (grâce à l'aide de Nicolas
George).
Sur ce, si on se concentrait sur le sujet, concernant les trois
logiciels que j'ai retenus ? Merci.
Le Thu, 09 Sep 2010 18:07:30 +0200, Pascal Hambourg a écrit:
J'exclus a priori nut qui dépend d'udev dont je ne veux pas sur ce serveur
C'est quoi le prob avec udev sur un serveur ?
Je n'en ai pas besoin sur *ce* serveur et je me méfie des surprises qu'il peut provoquer. Peut-être plus tard, quand je le maîtriserai, mais pas maintenant.
Il est fourni d'office avec un kernel 2.6
Non, la preuve.
Emmanuel Florac a écrit :
Il va falloir s'y faire, il est devenu impossible de faire sans udev
J'ai pourtant réussi à faire sans jusqu'ici. Même charger les firmwares à la demande du noyau, cf. fil récent ici (grâce à l'aide de Nicolas George).
Sur ce, si on se concentrait sur le sujet, concernant les trois logiciels que j'ai retenus ? Merci.
Kevin Denis
Le 09-09-2010, Pascal Hambourg a écrit :
Disposant d'un vieil onduleur "bête" ("dumb") Merlin Gerin, avec signaux de contrôle tout ou rien qu'on peut interfacer sur un port série RS-232 via un câble adaptateur) relié à un petit serveur sous Debian lenny, je cherche un logiciel de surveillance basique pour : - surveiller le signal de coupure du secteur et déclencher un shutdown au bout d'un certain temps, - surveiller le signal de batterie faible et déclencher un shutdown immédiat, - envoyer un signal d'arrêt à l'onduleur lors du shutdown.
Pas besoin de fonctions réseau pour commander l'arrêt automatique d'autres machines et autres raffinements.
J'ai identifié les paquetages suivants disponibles dans Debian (Provides: ups-monitor) :
apcupsd - APC UPS Power Management (daemon) genpower - Monitor UPS and handle line power failures nut - The core system of the nut - Network UPS Tools powstatd - Configurable UPS monitoring daemon upsd - UPS Monitor Program via serial interface
J'exclus a priori nut qui dépend d'udev dont je ne veux pas sur ce serveur, et apcupsd qui semble prévu spécifiquement pour les onduleurs de marque APC et qui dépend de snmp dont je n'ai que faire. Restent genpower, powstatd et upsd, plus éventuellement d'autres qui m'auraient échappé. Je suis preneur d'avis de personnes connaissant ou ayant utilisé l'un ou l'autre, sur leurs qualités et défauts éventuels.
Il y a fort longtemps, j'avais utilisé genpower sous slackware et un onduleur monitoré par port série (je ne me souviens plus de la marque). A l'époque udev n'existait pas :) De mémoire ça marchait bien, j'avais juste suivi la doc. Si ce n'est les tests "manuels" pour la validation, je crois qu'il n'a jamais servi en vrai.
Question subsidiaire aux utilisateurs d'onduleurs : Comment gérez-vous le redémarrage automatique des machines secourues ? J'explique : en cas de secteur qui fait le yoyo, si la machine secourue redémarre immédiatement à chaque retour (provisoire) du secteur, la batterie de l'onduleur risque de ne pas se recharger suffisamment entre deux coupures et finir par se décharger au point que l'autonomie pourrait ne pas suffire pour un redémarrage+arrêt complet. Y a-t-il quelque chose de prévu pour ne redémarrer que si la batterie est suffisamment chargée ?
Le programme /sbin/genpowerfail est un script shell. Il doit être possible de l'améliorer dans ce sens. Ceci dit, il est nécessaire que le script se lance, donc que la machine démarre pour qu'il s'exécute... C'est peut-être plutôt à voir du côté de l'onduleur lui-même. Si la batterie n'est pas chargée à plus de x% alors il ne faut pas réalimenter la prise. Je ne sais pas si cela existe comme option. -- Kevin
Le 09-09-2010, Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> a écrit :
Disposant d'un vieil onduleur "bête" ("dumb") Merlin Gerin, avec signaux
de contrôle tout ou rien qu'on peut interfacer sur un port série RS-232
via un câble adaptateur) relié à un petit serveur sous Debian lenny, je
cherche un logiciel de surveillance basique pour :
- surveiller le signal de coupure du secteur et déclencher un shutdown
au bout d'un certain temps,
- surveiller le signal de batterie faible et déclencher un shutdown
immédiat,
- envoyer un signal d'arrêt à l'onduleur lors du shutdown.
Pas besoin de fonctions réseau pour commander l'arrêt automatique
d'autres machines et autres raffinements.
J'ai identifié les paquetages suivants disponibles dans Debian
(Provides: ups-monitor) :
apcupsd - APC UPS Power Management (daemon)
genpower - Monitor UPS and handle line power failures
nut - The core system of the nut - Network UPS Tools
powstatd - Configurable UPS monitoring daemon
upsd - UPS Monitor Program via serial interface
J'exclus a priori nut qui dépend d'udev dont je ne veux pas sur ce
serveur, et apcupsd qui semble prévu spécifiquement pour les onduleurs
de marque APC et qui dépend de snmp dont je n'ai que faire. Restent
genpower, powstatd et upsd, plus éventuellement d'autres qui m'auraient
échappé. Je suis preneur d'avis de personnes connaissant ou ayant
utilisé l'un ou l'autre, sur leurs qualités et défauts éventuels.
Il y a fort longtemps, j'avais utilisé genpower sous slackware et un
onduleur monitoré par port série (je ne me souviens plus de la marque).
A l'époque udev n'existait pas :)
De mémoire ça marchait bien, j'avais juste suivi la doc. Si ce
n'est les tests "manuels" pour la validation, je crois qu'il n'a
jamais servi en vrai.
Question subsidiaire aux utilisateurs d'onduleurs :
Comment gérez-vous le redémarrage automatique des machines secourues ?
J'explique : en cas de secteur qui fait le yoyo, si la machine secourue
redémarre immédiatement à chaque retour (provisoire) du secteur, la
batterie de l'onduleur risque de ne pas se recharger suffisamment entre
deux coupures et finir par se décharger au point que l'autonomie
pourrait ne pas suffire pour un redémarrage+arrêt complet. Y a-t-il
quelque chose de prévu pour ne redémarrer que si la batterie est
suffisamment chargée ?
Le programme /sbin/genpowerfail est un script shell. Il doit être possible
de l'améliorer dans ce sens. Ceci dit, il est nécessaire que le script
se lance, donc que la machine démarre pour qu'il s'exécute...
C'est peut-être plutôt à voir du côté de l'onduleur lui-même. Si
la batterie n'est pas chargée à plus de x% alors il ne faut pas réalimenter
la prise. Je ne sais pas si cela existe comme option.
--
Kevin
Disposant d'un vieil onduleur "bête" ("dumb") Merlin Gerin, avec signaux de contrôle tout ou rien qu'on peut interfacer sur un port série RS-232 via un câble adaptateur) relié à un petit serveur sous Debian lenny, je cherche un logiciel de surveillance basique pour : - surveiller le signal de coupure du secteur et déclencher un shutdown au bout d'un certain temps, - surveiller le signal de batterie faible et déclencher un shutdown immédiat, - envoyer un signal d'arrêt à l'onduleur lors du shutdown.
Pas besoin de fonctions réseau pour commander l'arrêt automatique d'autres machines et autres raffinements.
J'ai identifié les paquetages suivants disponibles dans Debian (Provides: ups-monitor) :
apcupsd - APC UPS Power Management (daemon) genpower - Monitor UPS and handle line power failures nut - The core system of the nut - Network UPS Tools powstatd - Configurable UPS monitoring daemon upsd - UPS Monitor Program via serial interface
J'exclus a priori nut qui dépend d'udev dont je ne veux pas sur ce serveur, et apcupsd qui semble prévu spécifiquement pour les onduleurs de marque APC et qui dépend de snmp dont je n'ai que faire. Restent genpower, powstatd et upsd, plus éventuellement d'autres qui m'auraient échappé. Je suis preneur d'avis de personnes connaissant ou ayant utilisé l'un ou l'autre, sur leurs qualités et défauts éventuels.
Il y a fort longtemps, j'avais utilisé genpower sous slackware et un onduleur monitoré par port série (je ne me souviens plus de la marque). A l'époque udev n'existait pas :) De mémoire ça marchait bien, j'avais juste suivi la doc. Si ce n'est les tests "manuels" pour la validation, je crois qu'il n'a jamais servi en vrai.
Question subsidiaire aux utilisateurs d'onduleurs : Comment gérez-vous le redémarrage automatique des machines secourues ? J'explique : en cas de secteur qui fait le yoyo, si la machine secourue redémarre immédiatement à chaque retour (provisoire) du secteur, la batterie de l'onduleur risque de ne pas se recharger suffisamment entre deux coupures et finir par se décharger au point que l'autonomie pourrait ne pas suffire pour un redémarrage+arrêt complet. Y a-t-il quelque chose de prévu pour ne redémarrer que si la batterie est suffisamment chargée ?
Le programme /sbin/genpowerfail est un script shell. Il doit être possible de l'améliorer dans ce sens. Ceci dit, il est nécessaire que le script se lance, donc que la machine démarre pour qu'il s'exécute... C'est peut-être plutôt à voir du côté de l'onduleur lui-même. Si la batterie n'est pas chargée à plus de x% alors il ne faut pas réalimenter la prise. Je ne sais pas si cela existe comme option. -- Kevin
Erwan David
Emmanuel Florac écrivait :
Le Thu, 09 Sep 2010 18:07:30 +0200, Pascal Hambourg a écrit:
J'exclus a priori nut qui dépend d'udev dont je ne veux pas sur ce serveur,
Il va falloir s'y faire, il est devenu impossible de faire sans udev, et nut est vraiment le mieux et de loin.
Mais attention sa config nut sous debian est bugguée...
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Emmanuel Florac <eflorac@imaginet.fr> écrivait :
Le Thu, 09 Sep 2010 18:07:30 +0200, Pascal Hambourg a écrit:
J'exclus a priori nut qui dépend d'udev dont je ne veux pas sur ce
serveur,
Il va falloir s'y faire, il est devenu impossible de faire sans udev, et
nut est vraiment le mieux et de loin.
Mais attention sa config nut sous debian est bugguée...
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
Le Thu, 09 Sep 2010 18:07:30 +0200, Pascal Hambourg a écrit:
J'exclus a priori nut qui dépend d'udev dont je ne veux pas sur ce serveur,
Il va falloir s'y faire, il est devenu impossible de faire sans udev, et nut est vraiment le mieux et de loin.
Mais attention sa config nut sous debian est bugguée...
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Raphaël 'SurcouF' Bordet
Le vendredi 10 septembre 2010 à 19:58 +0200, Erwan David a écrit :
Emmanuel Florac écrivait :
> Le Thu, 09 Sep 2010 18:07:30 +0200, Pascal Hambourg a écrit: > > >> J'exclus a priori nut qui dépend d'udev dont je ne veux pas sur ce >> serveur, > > Il va falloir s'y faire, il est devenu impossible de faire sans udev, e t > nut est vraiment le mieux et de loin.
Mais attention sa config nut sous debian est bugguée...
Étonnant quand on sait que l'auteur de NUT et le développeur Debian du paquet ne sont qu'une seule et même personne...
Peux-tu développer le problème ?
-- Raphaël SurcouF
Le vendredi 10 septembre 2010 à 19:58 +0200, Erwan David a écrit :
Emmanuel Florac <eflorac@imaginet.fr> écrivait :
> Le Thu, 09 Sep 2010 18:07:30 +0200, Pascal Hambourg a écrit:
>
>
>> J'exclus a priori nut qui dépend d'udev dont je ne veux pas sur ce
>> serveur,
>
> Il va falloir s'y faire, il est devenu impossible de faire sans udev, e t
> nut est vraiment le mieux et de loin.
Mais attention sa config nut sous debian est bugguée...
Étonnant quand on sait que l'auteur de NUT et le développeur Debian du
paquet ne sont qu'une seule et même personne...
Le vendredi 10 septembre 2010 à 19:58 +0200, Erwan David a écrit :
Emmanuel Florac écrivait :
> Le Thu, 09 Sep 2010 18:07:30 +0200, Pascal Hambourg a écrit: > > >> J'exclus a priori nut qui dépend d'udev dont je ne veux pas sur ce >> serveur, > > Il va falloir s'y faire, il est devenu impossible de faire sans udev, e t > nut est vraiment le mieux et de loin.
Mais attention sa config nut sous debian est bugguée...
Étonnant quand on sait que l'auteur de NUT et le développeur Debian du paquet ne sont qu'une seule et même personne...
Peux-tu développer le problème ?
-- Raphaël SurcouF
Erwan David
Raphaël 'SurcouF' Bordet écrivait :
Le vendredi 10 septembre 2010 à 19:58 +0200, Erwan David a écrit :
Emmanuel Florac écrivait :
> Le Thu, 09 Sep 2010 18:07:30 +0200, Pascal Hambourg a écrit: > > >> J'exclus a priori nut qui dépend d'udev dont je ne veux pas sur ce >> serveur, > > Il va falloir s'y faire, il est devenu impossible de faire sans udev, et > nut est vraiment le mieux et de loin.
Mais attention sa config nut sous debian est bugguée...
Étonnant quand on sait que l'auteur de NUT et le développeur Debian du paquet ne sont qu'une seule et même personne...
Peux-tu développer le problème ?
le device reste à root et j'ai des erreurs dans le log, disant que la syntaxe est mauvaise ou obsolète.
C'est peut-être moi qui ne connais pas bien udev aussi, mais je n'ai pas trouver comment lister les devices comme vu par udev (et le man de udevadm est bien insuffisant pour l'utiliser), ni comment tester tracer, bref udev ça marche ou ça marche pas et quand comme là ça ne arche pas on est dans la merde parceque rien n'indique pourquoi ça ne marche pas...
mon ups 0463/ffff est bien listé dans les règles udev, si je comprends bien (mais je n'ai pas trouvé de doc de la syntae des règles udev) et devraitavoir un device en 664 et groupe nut, mais le /dev/bus/usb/005/002 (j'ai eu ça en faisat un lsusb pour savoir où est mon onduleur) est en root/root 640. Si je change les droits à la main, nut marche mais ce n'est pas pérenne.
C'ets le bug 595953
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Le vendredi 10 septembre 2010 à 19:58 +0200, Erwan David a écrit :
Emmanuel Florac <eflorac@imaginet.fr> écrivait :
> Le Thu, 09 Sep 2010 18:07:30 +0200, Pascal Hambourg a écrit:
>
>
>> J'exclus a priori nut qui dépend d'udev dont je ne veux pas sur ce
>> serveur,
>
> Il va falloir s'y faire, il est devenu impossible de faire sans udev, et
> nut est vraiment le mieux et de loin.
Mais attention sa config nut sous debian est bugguée...
Étonnant quand on sait que l'auteur de NUT et le développeur Debian du
paquet ne sont qu'une seule et même personne...
Peux-tu développer le problème ?
le device reste à root et j'ai des erreurs dans le log, disant que la
syntaxe est mauvaise ou obsolète.
C'est peut-être moi qui ne connais pas bien udev aussi, mais je n'ai pas
trouver comment lister les devices comme vu par udev (et le man de
udevadm est bien insuffisant pour l'utiliser), ni comment tester tracer,
bref udev ça marche ou ça marche pas et quand comme là ça ne arche pas
on est dans la merde parceque rien n'indique pourquoi ça ne marche
pas...
mon ups 0463/ffff est bien listé dans les règles udev, si je comprends
bien (mais je n'ai pas trouvé de doc de la syntae des règles udev) et
devraitavoir un device en 664 et groupe nut, mais le
/dev/bus/usb/005/002 (j'ai eu ça en faisat un lsusb pour savoir où est
mon onduleur) est en root/root 640. Si je change les droits à la main,
nut marche mais ce n'est pas pérenne.
C'ets le bug 595953
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
Le vendredi 10 septembre 2010 à 19:58 +0200, Erwan David a écrit :
Emmanuel Florac écrivait :
> Le Thu, 09 Sep 2010 18:07:30 +0200, Pascal Hambourg a écrit: > > >> J'exclus a priori nut qui dépend d'udev dont je ne veux pas sur ce >> serveur, > > Il va falloir s'y faire, il est devenu impossible de faire sans udev, et > nut est vraiment le mieux et de loin.
Mais attention sa config nut sous debian est bugguée...
Étonnant quand on sait que l'auteur de NUT et le développeur Debian du paquet ne sont qu'une seule et même personne...
Peux-tu développer le problème ?
le device reste à root et j'ai des erreurs dans le log, disant que la syntaxe est mauvaise ou obsolète.
C'est peut-être moi qui ne connais pas bien udev aussi, mais je n'ai pas trouver comment lister les devices comme vu par udev (et le man de udevadm est bien insuffisant pour l'utiliser), ni comment tester tracer, bref udev ça marche ou ça marche pas et quand comme là ça ne arche pas on est dans la merde parceque rien n'indique pourquoi ça ne marche pas...
mon ups 0463/ffff est bien listé dans les règles udev, si je comprends bien (mais je n'ai pas trouvé de doc de la syntae des règles udev) et devraitavoir un device en 664 et groupe nut, mais le /dev/bus/usb/005/002 (j'ai eu ça en faisat un lsusb pour savoir où est mon onduleur) est en root/root 640. Si je change les droits à la main, nut marche mais ce n'est pas pérenne.
C'ets le bug 595953
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Pascal Hambourg
Kevin Denis a écrit :
Il y a fort longtemps, j'avais utilisé genpower sous slackware et un onduleur monitoré par port série (je ne me souviens plus de la marque). A l'époque udev n'existait pas :) De mémoire ça marchait bien, j'avais juste suivi la doc. Si ce n'est les tests "manuels" pour la validation, je crois qu'il n'a jamais servi en vrai.
Merci de ton témoignage, je note.
quelque chose de prévu pour ne redémarrer que si la batterie est suffisamment chargée ?
[...]
C'est peut-être plutôt à voir du côté de l'onduleur lui-même. Si la batterie n'est pas chargée à plus de x% alors il ne faut pas réalimenter la prise.
Ou envoyer un signal de démarrage de type wake-on-ring seulement quand la batterie est suffisamment rechargée.
Je ne sais pas si cela existe comme option.
Je ne sais pas si le mien le fait par défaut, mais en tout cas il n'a aucune option. A défaut j'ai pensé utiliser le signal de niveau de charge batterie soit pour piloter soit l'entrée wake-on-ring du PC, soit un contacteur (relais) entre la sortie de l'onduleur et l'alimentation du PC.
Kevin Denis a écrit :
Il y a fort longtemps, j'avais utilisé genpower sous slackware et un
onduleur monitoré par port série (je ne me souviens plus de la marque).
A l'époque udev n'existait pas :)
De mémoire ça marchait bien, j'avais juste suivi la doc. Si ce
n'est les tests "manuels" pour la validation, je crois qu'il n'a
jamais servi en vrai.
Merci de ton témoignage, je note.
quelque chose de prévu pour ne redémarrer que si la batterie est
suffisamment chargée ?
[...]
C'est peut-être plutôt à voir du côté de l'onduleur lui-même. Si
la batterie n'est pas chargée à plus de x% alors il ne faut pas réalimenter
la prise.
Ou envoyer un signal de démarrage de type wake-on-ring seulement quand
la batterie est suffisamment rechargée.
Je ne sais pas si cela existe comme option.
Je ne sais pas si le mien le fait par défaut, mais en tout cas il n'a
aucune option. A défaut j'ai pensé utiliser le signal de niveau de
charge batterie soit pour piloter soit l'entrée wake-on-ring du PC, soit
un contacteur (relais) entre la sortie de l'onduleur et l'alimentation
du PC.
Il y a fort longtemps, j'avais utilisé genpower sous slackware et un onduleur monitoré par port série (je ne me souviens plus de la marque). A l'époque udev n'existait pas :) De mémoire ça marchait bien, j'avais juste suivi la doc. Si ce n'est les tests "manuels" pour la validation, je crois qu'il n'a jamais servi en vrai.
Merci de ton témoignage, je note.
quelque chose de prévu pour ne redémarrer que si la batterie est suffisamment chargée ?
[...]
C'est peut-être plutôt à voir du côté de l'onduleur lui-même. Si la batterie n'est pas chargée à plus de x% alors il ne faut pas réalimenter la prise.
Ou envoyer un signal de démarrage de type wake-on-ring seulement quand la batterie est suffisamment rechargée.
Je ne sais pas si cela existe comme option.
Je ne sais pas si le mien le fait par défaut, mais en tout cas il n'a aucune option. A défaut j'ai pensé utiliser le signal de niveau de charge batterie soit pour piloter soit l'entrée wake-on-ring du PC, soit un contacteur (relais) entre la sortie de l'onduleur et l'alimentation du PC.
xavier
Pascal Hambourg wrote:
Question subsidiaire aux utilisateurs d'onduleurs : Comment gérez-vous le redémarrage automatique des machines secourues ?
Bonjour Pascal,
C'est bien tout le problème, et c'est pourquoi je me permets de rebondir sur ton message :
Cequi est compliqué n'est pas tant de gérer un serveur/un UPS. En général les logiciels fournis (APC pour ma part) savent faire tout le boulot. Mais dans une salle machines, on a un ou plusieurs gros onduleurs (typiquement un par baie). Donc, en cas de coupure, ce qui importe est d'envoyer au bon moment un shutdown à toutes les machines de la baie. Et, d'après mon expérience, seul MacOSX comprend le flag "-u" (unattended, je suppose) de la commande shutdown, ce qui éteint la machine, mais laisse le gestionnaire d'alim en standby. Là, pas de problème. Mais cette option de shutdown n'existe ni sous Windows 2003/2008, ni sous Linux, ni sous FreeBSD, qui font un shutdown propre, complet et définitif.
Ce qui fait qu'avant de songer à la recharge des batteries, j'en suis à chercher comment redémarrer les machines non-MacOSX. Et ça, j'ai pas trouvé...
Enfin, pour les Linux/FreeBSD, j'ai une ruse crade : je ne fais pas un shutdown : je passe en single-user, démonte toutes les partitions, fais deux sync(8), remonte / en r/o. Puis j'attends. C'est crade, je sais. En plus, ça vide la batterie de l'onduleur pour rien.
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear. (Jethro Tull)
Question subsidiaire aux utilisateurs d'onduleurs :
Comment gérez-vous le redémarrage automatique des machines secourues ?
Bonjour Pascal,
C'est bien tout le problème, et c'est pourquoi je me permets de rebondir
sur ton message :
Cequi est compliqué n'est pas tant de gérer un serveur/un UPS. En
général les logiciels fournis (APC pour ma part) savent faire tout le
boulot. Mais dans une salle machines, on a un ou plusieurs gros
onduleurs (typiquement un par baie). Donc, en cas de coupure, ce qui
importe est d'envoyer au bon moment un shutdown à toutes les machines de
la baie. Et, d'après mon expérience, seul MacOSX comprend le flag "-u"
(unattended, je suppose) de la commande shutdown, ce qui éteint la
machine, mais laisse le gestionnaire d'alim en standby. Là, pas de
problème. Mais cette option de shutdown n'existe ni sous Windows
2003/2008, ni sous Linux, ni sous FreeBSD, qui font un shutdown propre,
complet et définitif.
Ce qui fait qu'avant de songer à la recharge des batteries, j'en suis à
chercher comment redémarrer les machines non-MacOSX. Et ça, j'ai pas
trouvé...
Enfin, pour les Linux/FreeBSD, j'ai une ruse crade : je ne fais pas un
shutdown : je passe en single-user, démonte toutes les partitions, fais
deux sync(8), remonte / en r/o. Puis j'attends. C'est crade, je sais. En
plus, ça vide la batterie de l'onduleur pour rien.
--
XAv
In your pomp and all your glory you're a poorer man than me,
as you lick the boots of death born out of fear.
(Jethro Tull)
Question subsidiaire aux utilisateurs d'onduleurs : Comment gérez-vous le redémarrage automatique des machines secourues ?
Bonjour Pascal,
C'est bien tout le problème, et c'est pourquoi je me permets de rebondir sur ton message :
Cequi est compliqué n'est pas tant de gérer un serveur/un UPS. En général les logiciels fournis (APC pour ma part) savent faire tout le boulot. Mais dans une salle machines, on a un ou plusieurs gros onduleurs (typiquement un par baie). Donc, en cas de coupure, ce qui importe est d'envoyer au bon moment un shutdown à toutes les machines de la baie. Et, d'après mon expérience, seul MacOSX comprend le flag "-u" (unattended, je suppose) de la commande shutdown, ce qui éteint la machine, mais laisse le gestionnaire d'alim en standby. Là, pas de problème. Mais cette option de shutdown n'existe ni sous Windows 2003/2008, ni sous Linux, ni sous FreeBSD, qui font un shutdown propre, complet et définitif.
Ce qui fait qu'avant de songer à la recharge des batteries, j'en suis à chercher comment redémarrer les machines non-MacOSX. Et ça, j'ai pas trouvé...
Enfin, pour les Linux/FreeBSD, j'ai une ruse crade : je ne fais pas un shutdown : je passe en single-user, démonte toutes les partitions, fais deux sync(8), remonte / en r/o. Puis j'attends. C'est crade, je sais. En plus, ça vide la batterie de l'onduleur pour rien.
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear. (Jethro Tull)
Pascal Hambourg
Xavier a écrit :
Et, d'après mon expérience, seul MacOSX comprend le flag "-u" (unattended, je suppose) de la commande shutdown, ce qui éteint la machine, mais laisse le gestionnaire d'alim en standby.
Qu'entends-tu précisément par "gestionnaire d'alim en standby" ?
Xavier a écrit :
Et, d'après mon expérience, seul MacOSX comprend le flag "-u"
(unattended, je suppose) de la commande shutdown, ce qui éteint la
machine, mais laisse le gestionnaire d'alim en standby.
Qu'entends-tu précisément par "gestionnaire d'alim en standby" ?
Et, d'après mon expérience, seul MacOSX comprend le flag "-u" (unattended, je suppose) de la commande shutdown, ce qui éteint la machine, mais laisse le gestionnaire d'alim en standby.
Qu'entends-tu précisément par "gestionnaire d'alim en standby" ?
