Oui ce serait possible mais, outre le fait que je suis une buse en script shell, j'aurais plutôt tendance à renvoyer la balle à la config de fancontrol :
- depuis "peu" /etc/fancontrol doit obligatoirement contenir le chemin d'accès et le nom du chipset (DEVNAME/DEVPATH)
- ces informations étant ramenées automatiquement par pwmconfig, on ne peut plus éditer soit-même le fichier, fancontrol détectant qu'il n'est plus "à jour"
Et d'un autre côté malgré le nom il réclame encore l'indication de hwmonX ! M'est avis qu'on a un peu (passez-moi l'expression !) le "cul entre 2 chaises" et que, quitte à indiquer DEVPATH/DEVNAME, on pourrait s'abstraire de l'indication de hwmon et ce que tu préconises devrait être embarqué dans le daemon fancontrol (enfin c'est mon avis).
Ok je comprends ce que tu veux dire et ne peux qu'acquiescer.
Il faudrait d'ailleurs que j'aille faire un tour du côté de fancontrol pour rapporter cette histoire parce que bon, c'est bien gentil d'avoir chamboulé pwmconfig pour y inclure le chemin d'accès (et non le lien symbolique) dans /sys...mais de l'autre il faut quand même lui spécifier hwmonX et il est perdu quand ça change !
Ta solution est séduisante et correspond tout à fait à mon besoin mais pourquoi la qualifies-tu de "hack sale" ? Il n'est pas lié à une quelconque version de initramfs et sera régénéré à chaque mise à jour non ?
Alors certes ça ne correspond pas à ce que fait udev pour les /dev mais bon....de là à la considérer comme une vieille rustine...
Merci du tuyau mais est-ce qu'il s'agit bien là d'un périphérique ? je veux dire : j'ai pris l'habitude d'y accéder via /sys/class/hwmon/hwmonX mais il s'agit d'un lien symbolique pointant vers /sys/devices...
Je rejoins le commentaire ci-dessous : udev "marche" t'il aussi pour /sys ?
Je l'ai feuilleté chez mon libraire mais si la configuration y était bien documentée, une seule solution était présentée, sans évoquer les autres possibilités. Je suis resté un peu sur ma faim... (mais je l'ai peut-être feuilleté trop vite, faudra que je rejette un oeil).
Effectivement sur la mailing-list de nut j'avais déjà vu conseillé, pour pareils problèmes de USBDEVFS_CONTROL failed, d'augmenter la valeur de ups.driver.pollfreq directement dans l'onduleur. Apparemment une fréquence d'interrogation trop élevée couplée à un temps de réponse limite peut poser ce genre de problème (cf. http://www.mail-archive.com/nut-upsuser@lists.alioth.debian.(...) et la suite de la discussion).
Malheureusement mon (petit) ups ne me donne pas accès à ce paramètre !
Donc merci d'une part de me confirmer que c'est bien un problème de gestion USB (et pas de configuration de nut ou je-ne-sais-quoi....), et d'autre part de m'avoir montrer comment y "remédier" via la gestion des timeout noyaux. Encore une bonne raison de compiler son noyau soi-même...va falloir que je m'y mette ! ;-)
Je n'avais pas osé me lancer dans udev pour régler mon problème d'autorisation .... (d'ailleurs je me demandais même si ça pouvait marcher avec autre chose que des périphériques de stockage ^^)
Merci du tuyau ! En farfouillant dans /var/log/debug, j'ai d'ailleurs vu un warning concernant une règle udev ajoutée par nut (obsolescence de l'attribut "bus") qui me laisse croire que nut essaye lui-même de faire de la sorte...
Reste à savoir pourquoi il n'a pas marché pour l'instant ! J'ai relancé nut pour voir....
(d'ailleurs, toujours pour ce problème d'autorisation, je me demandais également si l'affectation de l'utilisateur nut au groupe plugdev ne pouvait pas également constituer une rustine... certes bien moins propre qu'une règle udev)
Oui effectivement je l 'avais croisé et elle m'avait semblé dater un peu... En effet, on peut voir directement dans la doc de nut 2.2.0 (http://www.networkupstools.org/doc/2.2.0/) que pour les UPS branchés en USB, il est conseillé de laisser port à "auto".
Pour le mknod j'avoue rester dubitatif... on dirait que l'auteur utilise là une méthode utilisée pour le branchement par port série (ou alors je n'ai strictement rien compris !).
J'avoue n'avoir jamais testé un portable en tant que serveur bien qu'en ayant déjà souvent entendu parler.
Ce qui me fait un peu tiquer dans cette solution c'est le confinement des composants, ce qui peut en particulier être préjudiciable aux disques durs (par exemple un petit hddtemp effectué sur mon portable Toshiba Satellite P200 me montre une température de 55°C au repos).
Alors je sais bien qu'une étude de Google a montré la plus faible corrélation qu'attendue entre (courte) durée de vie d'un disque et (haute) température, mais je ne sais pas si flirter constamment avec les 55-60°C est transparent pour autant !
De plus ça contraint à se contenter d'un seul disque dur (dans la majorité des cas) - pas de RAID donc.
Mais bon si les données ne sont pas sensibles c'est à tenter !
Tout à fait ! C'est ce que je voulais dire aussi en parlant de "bidouilles" comme alternative.
Au temps où je creusais le sujet, j'ai effectivement vu pas mal de sujets autour de ces alimentations Pico PSU. Mais ce n'est pas tant leur rareté/prix qui m'a arrêté que la "peur" (justifiée ou non... je me trompe sûrement) qu'elle me lâche pour une utilisation serveur 24/24 7/7.
C'est certainement faux, mais n'en ayant jamais "testé" j'ai préféré me rabattre sur ce que je connais : le bon vieux format ATX et une marque (ou tout du moins un modèle) réputée.
Mais du coup ça en devient une contrainte très dimensionnante !
...de vouloir absolument réduire la consommation ?
Je m'explique : j'ai été confronté à la même problématique dernièrement et j'en suis arrivé à la conclusion qu'il n'était pas nécessairement judicieux voire totalement contre-productif de rechercher pour chaque composant celui qui consommera le moins.
En effet, même en ne ciblant pas spécifiquement des composants basse-consommation, entre un CPU qui va te consommer 45W (des Athlon II XXXe au Xeon L3426), une carte mère avec chipset graphique intégré et 4Go de RAM qui va t'en coûter disons autant (en ordre de grandeur) et les quelques watts de tes disques durs, tu arrives déjà péniblement à 100W...
(Précisément 101W au repos pour un Athlon 64 3200+ s754 + 2Go de RAM + carte mère DFI LanParty 250gb + 2 Samsung 640 Go + Ati Radeon 7500...attention : mesure effectuée à la prise !).
Or le rendement d'une alimentation est fonction de sa charge.
Et le fait qu'on ne trouve aucune alimentation ATX de qualité (au mini certif 80 "standard") calibrée pour moins de 400W maximum (la Corsair CX400 par exemple), augmenté du fait que le rendement se déprécie considérablement (pour n'importe quelle alim) pour une charge réelle inférieure à 20% de la charge maximum (80W réel pour 400W maxi donc) peut donc entraîner, paradoxalement, une stagnation voire une hausse de la consommation globale lorsqu'on diminue la consommation des composants.
D'autant plus que energy-efficient va souvent de paire avec money-consuming...
Vous allez me dire que mon raisonnement s'appuie tout entier sur le format ATX, ce qui est rigoureusement exact. Sauf qu'à part ce format là il n'y a guère que le format micro-ATX qu'on puisse "facilement" trouver pour les alimentations. Il en existe un modèle certifié 80+ à 150W (Antec je crois) mais encore-faut-il trouver le boîtier qui l'accepte, qui est généralement un boîtier micro-ATX (ou alors on part dans la bidouille).
Et comme tu l'as si bien fait remarquer, la contrainte des instructions de virtualisation écarte un sacré paquet de prétendants, au rang desquels beaucoup d'Atom certes, mais surtout les sheevaplug & co, qui auraient été très bien sinon...parce que leurs alim est correctement dimensionnée !
Bref.... en ce qui me concerne, j'ai opté pour une config dont la consommation devrait tourner (au repos....puisque, comme pour toi, elle végètera 99,9% du temps) autour de ces fameux 20% de charge maximum de l'alim. (Athlon II X3 435 + CM avec chip graphique intégré + 4Go de RAM + 2 DD. L'alim retenue est cette fameuse Corsair CX400).
Je vais peut-être consommer quelques watts en plus, mais au moins je n'ai pas à m'en faire pour la puissance de calcul etc... pour les VM et ça m'a coûté moins cher qu'une config mini-ITX avec des composants energy-efficient et....la même alimentation ou une moins bonne (vendue avec le boîtier, ce qui est souvent le cas avec les boîtier mini-ITX)
Après je ne sais pas ce que vaut mon raisonnement....je suis curieux de voir les autres réponses !
[^] # Re: udev
Posté par weierstrass01 . En réponse au message Ordre de chargement des modules. Évalué à 1.
- depuis "peu" /etc/fancontrol doit obligatoirement contenir le chemin d'accès et le nom du chipset (DEVNAME/DEVPATH)
- ces informations étant ramenées automatiquement par pwmconfig, on ne peut plus éditer soit-même le fichier, fancontrol détectant qu'il n'est plus "à jour"
Et d'un autre côté malgré le nom il réclame encore l'indication de hwmonX ! M'est avis qu'on a un peu (passez-moi l'expression !) le "cul entre 2 chaises" et que, quitte à indiquer DEVPATH/DEVNAME, on pourrait s'abstraire de l'indication de hwmon et ce que tu préconises devrait être embarqué dans le daemon fancontrol (enfin c'est mon avis).
[^] # Re: /etc/initramfstools.d/modules
Posté par weierstrass01 . En réponse au message Ordre de chargement des modules. Évalué à 1.
Il faudrait d'ailleurs que j'aille faire un tour du côté de fancontrol pour rapporter cette histoire parce que bon, c'est bien gentil d'avoir chamboulé pwmconfig pour y inclure le chemin d'accès (et non le lien symbolique) dans /sys...mais de l'autre il faut quand même lui spécifier hwmonX et il est perdu quand ça change !
Merci en tout cas pour l'explication !
[^] # Re: /etc/initramfstools.d/modules
Posté par weierstrass01 . En réponse au message Ordre de chargement des modules. Évalué à 1.
Alors certes ça ne correspond pas à ce que fait udev pour les /dev mais bon....de là à la considérer comme une vieille rustine...
[^] # Re: udev
Posté par weierstrass01 . En réponse au message Ordre de chargement des modules. Évalué à 1.
Je rejoins le commentaire ci-dessous : udev "marche" t'il aussi pour /sys ?
[^] # Re: Tuto dans Linux Pratique de septembre/octobre
Posté par weierstrass01 . En réponse au message QEMU/KVM et problématique réseau. Évalué à 1.
[^] # Re: Une solution parmis d'autres
Posté par weierstrass01 . En réponse au message QEMU/KVM et problématique réseau. Évalué à 1.
Peut-être cette histoire de couche qui me permettrait de garder mon iptables fonctionnel...
# Adopte un chien....?
Posté par weierstrass01 . En réponse au message Distro légère en français?. Évalué à 4.
J'ai entendu parler de Toutou Linux : http://toutoulinux.free.fr/ qui apparemment est la version française de Puppy Linux.
Elle semble souscrire à toutes tes contraintes. J'en ai entendu du bien mais personnellement jamais testée !
Cordialement,
Weierstrass01
[^] # Re: Pour l'usb
Posté par weierstrass01 . En réponse au message Déco USB aléatoire et changement d'adresse pour Onduleur. Évalué à 2.
Malheureusement mon (petit) ups ne me donne pas accès à ce paramètre !
Donc merci d'une part de me confirmer que c'est bien un problème de gestion USB (et pas de configuration de nut ou je-ne-sais-quoi....), et d'autre part de m'avoir montrer comment y "remédier" via la gestion des timeout noyaux. Encore une bonne raison de compiler son noyau soi-même...va falloir que je m'y mette ! ;-)
[^] # Re: Udev
Posté par weierstrass01 . En réponse au message Déco USB aléatoire et changement d'adresse pour Onduleur. Évalué à 1.
Merci du tuyau ! En farfouillant dans /var/log/debug, j'ai d'ailleurs vu un warning concernant une règle udev ajoutée par nut (obsolescence de l'attribut "bus") qui me laisse croire que nut essaye lui-même de faire de la sorte...
Reste à savoir pourquoi il n'a pas marché pour l'instant ! J'ai relancé nut pour voir....
(d'ailleurs, toujours pour ce problème d'autorisation, je me demandais également si l'affectation de l'utilisateur nut au groupe plugdev ne pouvait pas également constituer une rustine... certes bien moins propre qu'une règle udev)
[^] # Re: Peut être ?
Posté par weierstrass01 . En réponse au message Déco USB aléatoire et changement d'adresse pour Onduleur. Évalué à 1.
Pour le mknod j'avoue rester dubitatif... on dirait que l'auteur utilise là une méthode utilisée pour le branchement par port série (ou alors je n'ai strictement rien compris !).
[^] # Re: Pour faire plus simple
Posté par weierstrass01 . En réponse au message Serveur domestique polyvalent et consommation reduite. Évalué à 1.
Ce qui me fait un peu tiquer dans cette solution c'est le confinement des composants, ce qui peut en particulier être préjudiciable aux disques durs (par exemple un petit hddtemp effectué sur mon portable Toshiba Satellite P200 me montre une température de 55°C au repos).
Alors je sais bien qu'une étude de Google a montré la plus faible corrélation qu'attendue entre (courte) durée de vie d'un disque et (haute) température, mais je ne sais pas si flirter constamment avec les 55-60°C est transparent pour autant !
De plus ça contraint à se contenter d'un seul disque dur (dans la majorité des cas) - pas de RAID donc.
Mais bon si les données ne sont pas sensibles c'est à tenter !
[^] # Re: Est-ce une bonne idée....
Posté par weierstrass01 . En réponse au message Serveur domestique polyvalent et consommation reduite. Évalué à 1.
Au temps où je creusais le sujet, j'ai effectivement vu pas mal de sujets autour de ces alimentations Pico PSU. Mais ce n'est pas tant leur rareté/prix qui m'a arrêté que la "peur" (justifiée ou non... je me trompe sûrement) qu'elle me lâche pour une utilisation serveur 24/24 7/7.
C'est certainement faux, mais n'en ayant jamais "testé" j'ai préféré me rabattre sur ce que je connais : le bon vieux format ATX et une marque (ou tout du moins un modèle) réputée.
Mais du coup ça en devient une contrainte très dimensionnante !
# Est-ce une bonne idée....
Posté par weierstrass01 . En réponse au message Serveur domestique polyvalent et consommation reduite. Évalué à 4.
Je m'explique : j'ai été confronté à la même problématique dernièrement et j'en suis arrivé à la conclusion qu'il n'était pas nécessairement judicieux voire totalement contre-productif de rechercher pour chaque composant celui qui consommera le moins.
En effet, même en ne ciblant pas spécifiquement des composants basse-consommation, entre un CPU qui va te consommer 45W (des Athlon II XXXe au Xeon L3426), une carte mère avec chipset graphique intégré et 4Go de RAM qui va t'en coûter disons autant (en ordre de grandeur) et les quelques watts de tes disques durs, tu arrives déjà péniblement à 100W...
(Précisément 101W au repos pour un Athlon 64 3200+ s754 + 2Go de RAM + carte mère DFI LanParty 250gb + 2 Samsung 640 Go + Ati Radeon 7500...attention : mesure effectuée à la prise !).
Or le rendement d'une alimentation est fonction de sa charge.
Et le fait qu'on ne trouve aucune alimentation ATX de qualité (au mini certif 80 "standard") calibrée pour moins de 400W maximum (la Corsair CX400 par exemple), augmenté du fait que le rendement se déprécie considérablement (pour n'importe quelle alim) pour une charge réelle inférieure à 20% de la charge maximum (80W réel pour 400W maxi donc) peut donc entraîner, paradoxalement, une stagnation voire une hausse de la consommation globale lorsqu'on diminue la consommation des composants.
D'autant plus que energy-efficient va souvent de paire avec money-consuming...
Vous allez me dire que mon raisonnement s'appuie tout entier sur le format ATX, ce qui est rigoureusement exact. Sauf qu'à part ce format là il n'y a guère que le format micro-ATX qu'on puisse "facilement" trouver pour les alimentations. Il en existe un modèle certifié 80+ à 150W (Antec je crois) mais encore-faut-il trouver le boîtier qui l'accepte, qui est généralement un boîtier micro-ATX (ou alors on part dans la bidouille).
Et comme tu l'as si bien fait remarquer, la contrainte des instructions de virtualisation écarte un sacré paquet de prétendants, au rang desquels beaucoup d'Atom certes, mais surtout les sheevaplug & co, qui auraient été très bien sinon...parce que leurs alim est correctement dimensionnée !
Bref.... en ce qui me concerne, j'ai opté pour une config dont la consommation devrait tourner (au repos....puisque, comme pour toi, elle végètera 99,9% du temps) autour de ces fameux 20% de charge maximum de l'alim. (Athlon II X3 435 + CM avec chip graphique intégré + 4Go de RAM + 2 DD. L'alim retenue est cette fameuse Corsair CX400).
Je vais peut-être consommer quelques watts en plus, mais au moins je n'ai pas à m'en faire pour la puissance de calcul etc... pour les VM et ça m'a coûté moins cher qu'une config mini-ITX avec des composants energy-efficient et....la même alimentation ou une moins bonne (vendue avec le boîtier, ce qui est souvent le cas avec les boîtier mini-ITX)
Après je ne sais pas ce que vaut mon raisonnement....je suis curieux de voir les autres réponses !
# Intéressé !
Posté par weierstrass01 . En réponse au message [Donne] Opteron 144 (socket 939) et thermaltake sonic tower (et visserie pour socket 939). Évalué à 1.
Ton Opteron pourrait m'intéresser dans la mesure où j'ai justement une carte mère s939 mais pas de CPU pour aller avec.
Ça me permettrait de faire un petit ordi pour surfer à pas cher... Dis-moi si tu ne t'en ais pas encore séparé !
Cordialement,
Weierstrass01