OVH Cloud OVH Cloud

Comment éteindre un serveur proprement pour permettre le redémarrage automatique ?

30 réponses
Avatar
Olivier
Bonjour,

J'envisage de protéger des serveurs distants (de type NUC) avec un
"onduleur administrable". Mon objectif est d'éviter d'endommager un
disque (toujours de type SSD ou NVMe) Í  cause d'une coupure brutale de
courant.

J'accepte que les services soient interrompus tant que dure la panne
de courant mais j'aimerai qu'idéalement, les services redémarrent sans
intervention humaine quand le courant revient (si par chance, celui-ci
devait revenir sans action humaine).


Imaginons qu'un serveur distant protégé par cet onduleur
administrable, reçoive de ce dernier ou d'ailleurs, la notification
d'une panne de courant prolongée.

Quelle commande d'extinction-hibernation doit-il émettre afin :
1- qu'il consomme le minimum d'énergie tant que dure la panne de courant
2- qu'il re-démarre dès que le courant revient.

J'ai vu dans le BIOS une option "After Power Failure: Stay Off/Power
On Normal Boot/Power On PXE". Je l'ai essayé mais elle ne fonctionne
après une commande poweroff, ce qui me semble logique.

Une idée ?

Slts

10 réponses

1 2 3
Avatar
Olivier
Le sam. 12 mars 2022 Í  00:30, Daniel Caillibaud a écrit :
Bonjour,
Je reviens sur ce thread parce que :
Le 04/03/22 Í  17:21, Olivier a écrit :
Mon objectif est d'éviter d'endommager un disque (toujours de type SSD ou NVMe) Í  cause d'une
coupure brutale de courant.

m'étonne un peu.
Un disque ssd est vraiment sensible Í  une coupure brutale ?
Je me souviens™ du devoir de parquer les disques avant d'éteindre un PC, mais c’était au siècle
dernier !

La question est vraiment très intéressante.
Merci beaucoup de la poser.
Au 21ème siècle, j'ai eu de multiples pannes de machines refusant de
démarrer Í  cause d'une incohérence dans le système de fichier.
La solution était souvent de déclencher un simple fsck.
C'est une opération assez difficile sur des machines headless sans
aucun informaticien aux alentours.
Par contre, si ma mémoire ne me trompe pas, je crois n'avoir rencontré
ce cas qu'avec des disques SATA.
Je sais que j'ai eu des coupures électriques sauvages et sans
conséquence avec des disques NVMe mais je ne sais pas si on peut
attribuer l'absence de conséquence Í  la chance ou Í  autre chose.
Néanmoins, je crois que des disques NVMe ont des mécanismes qui les
protègent contre les coupures sauvages.
Couplés Í  des onduleurs télé-administrables et des cartes mères
supportant la fonction "Power ON: Last State", on a peut-être une
solution simple re-démarrant automatiquement même si la route est
longue (cf [1])
[1] https://www.tomshardware.com/news/sk-hynix-sabrent-rocket-ssds-data-loss
Avatar
Daniel Caillibaud
Le 15/03/22 Í  10:33, Mathias Dufresne a écrit :
Je suis par contre assez surpris de lire que tu as besoin de fsck
régulièrement vu que (selon moi, c'est pas une vérité gravée dans le marbre
; ) le problème est forcément lié Í  l'écriture et que les systèmes
n'écrivent pas grand chose hormis leurs logs

Je sais pas si c'est fsck, mais il scanne pas le FS (ça prend qq ms lors du boot), je pensais
que c'était juste le journal du FS qui avait encore dans son buffer des données non écrites, et
qu'il commençait par les écrire Í  leur place avant de monter le filesystem, d'o͹ les messages
"recovered inode …".
--
Daniel
L'idée d'une armée européenne est vraiment intéressante,
mais pourquoi ne pas aller plus loin en créant une armée
mondiale dont le principal intérêt serait qu'elle n'aurait
pas d'ennemis.
Philippe Geluck, Le chat
Avatar
Mathias Dufresne
--000000000000e7dcc505da547e34
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
En provenance directe du man (7) de fstab :
*The sixth field (**fs_passno**).*
This field is used by fsck(8)
<https://man7.org/linux/man-pages/man8/fsck.8.html> to determine the
order in which
filesystem checks are done at boot time. The root filesystem
should be specified with a *fs_passno* of 1. Other filesystems
should have a *fs_passno* of 2. Filesystems within a drive will be
checked sequentially, but filesystems on different drives will be
checked at the same time to utilize parallelism available in the
hardware. Defaults to zero (donÍ¢€™t check the filesystem) if not
present.
Ensuite, quel fsck (fsck.ext[234], fsck.vaft, .minix ...) est r̓©ellement
d̓©pend du FS en question.
Quant ̓  savoir si c'est li̓© au buffer ou non, je ne me suis simplement
jamais attaqu̓© ̓  obtenir une r̓©ponse de ce type. Trop bas niveau ̓  mon sens
et je n'en jamais ressenti le besoin en plus de 20 ̓  jouer les sysadmins : )
Le mer. 16 mars 2022 ̓  09:58, Daniel Caillibaud a
̓©crit :
Le 15/03/22 ̓  10:33, Mathias Dufresne a
̓©crit :
Je suis par contre assez surpris de lire que tu as besoin de fsck
r̓©guli̓¨rement vu que (selon moi, c'est pas une v̓©rit̓© grav̓©e dans le
marbre
; ) le probl̓¨me est forc̓©ment li̓© ̓  l'̓©criture et que les syst̓¨mes
n'̓©crivent pas grand chose hormis leurs logs

Je sais pas si c'est fsck, mais il scanne pas le FS (̓§a prend qq ms lors
du boot), je pensais
que c'̓©tait juste le journal du FS qui avait encore dans son buffer des
donn̓©es non ̓©crites, et
qu'il commen̓§ait par les ̓©crire ̓  leur place avant de monter le
filesystem, d'o̓¹ les messages
"recovered inode Í¢€¦".
--
Daniel
L'id̓©e d'une arm̓©e europ̓©enne est vraiment int̓©ressante,
mais pourquoi ne pas aller plus loin en cr̓©ant une arm̓©e
mondiale dont le principal int̓©r̓ªt serait qu'elle n'aurait
pas d'ennemis.
Philippe Geluck, Le chat

--000000000000e7dcc505da547e34
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir="ltr"><div>En provenance directe du man (7) de fstab :</div><div><pre> <b>The sixth field (</b><i>fs_passno</i><b>).</b>
This field is used by <a href="https://man7.org/linux/man-pages/man8/fsck.8.html">fsck(8)</a> to determine the order in which
filesystem checks are done at boot time. The root filesystem
should be specified with a <i>fs_passno</i> of 1. Other filesystems
should have a <i>fs_passno</i> of 2. Filesystems within a drive will be
checked sequentially, but filesystems on different drives will be
checked at the same time to utilize parallelism available in the
hardware. Defaults to zero (donÍ¢€™t check the filesystem) if not
present.</pre></div><div><br></div><div>Ensuite, quel fsck (fsck.ext[234], fsck.vaft, .minix ...) est r̓©ellement d̓©pend du FS en question.</div><div><br></div><div>Quant ̓  savoir si c&#39;est li̓© au buffer ou non, je ne me suis simplement jamais attaqu̓© ̓  obtenir une r̓©ponse de ce type. Trop bas niveau ̓  mon sens et je n&#39;en jamais ressenti le besoin en plus de 20 ̓  jouer les sysadmins : )<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le͂ mer. 16 mars 2022 ̓ ͂ 09:58, Daniel Caillibaud &lt;<a href="mailto:"></a>&gt; a ̓©crit͂ :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Le 15/03/22 ̓  10:33, Mathias Dufresne &lt;<a href="mailto:" target="_blank"></a>&gt; a ̓©crit :<br>
&gt; Je suis par contre assez surpris de lire que tu as besoin de fsck<br>
&gt; r̓©guli̓¨rement vu que (selon moi, c&#39;est pas une v̓©rit̓© grav̓©e dans le marbre<br>
&gt; ; ) le probl̓¨me est forc̓©ment li̓© ̓  l&#39;̓©criture et que les syst̓¨mes<br>
&gt; n&#39;̓©crivent pas grand chose hormis leurs logs<br>
<br>
Je sais pas si c&#39;est fsck, mais il scanne pas le FS (̓§a prend qq ms lors du boot), je pensais<br>
que c&#39;̓©tait juste le journal du FS qui avait encore dans son buffer des donn̓©es non ̓©crites, et<br>
qu&#39;il commen̓§ait par les ̓©crire ̓  leur place avant de monter le filesystem, d&#39;o̓¹ les messages<br>
&quot;recovered inode Í¢€¦&quot;.<br>
<br>
-- <br>
Daniel<br>
<br>
L&#39;id̓©e d&#39;une arm̓©e europ̓©enne est vraiment int̓©ressante,<br>
mais pourquoi ne pas aller plus loin en cr̓©ant une arm̓©e<br>
mondiale dont le principal int̓©r̓ªt serait qu&#39;elle n&#39;aurait <br>
pas d&#39;ennemis.<br>
Philippe Geluck, Le chat<br>
<br>
</div>
--000000000000e7dcc505da547e34--
Avatar
Olivier
Suite Í  une nouvelle sollicitation, je déterre ce vieux fil de discussion.
J'ai expérimenté avec un NUC, dont l'option After Power Failure du
BIOS était valorisée Í  Last Stateroot
1. J'exécute echo freeze > /sys/power/state
La machine s'arrête (brutalement, semble-t-il)
Je débranche puis rebranche l'alimentation (comme si un onduleur l'avait fait)
Le serveur démarre avec un boot quasi normal car il affiche
"Recovering journal".
2. Idem avec echo standby > /sys/power/state
3. L'option After Power Failure est changée Í  StayOn et l'hibernation
est déclenché par poweroff.
La machine est dans un état inabituel: le bouton power reste allumé
mais l'écran est quasi-vide (un simple tiret en haut Í  gauche).
Je débranche puis rebranche l'alimentation (comme si un onduleur l'avait fait)
Le serveur démarre avec un boot normal (il n'affiche pas "Recovering journal").
A. Existe-t-il une commande ou option de configuration sous Linux pour
que le passage Í  l'état freeze évite le "Recovering journal" ? Qu'en
pensez-vous ?
B. Comme l'a pointé Sébastien, un point important dans mon scenario
est que dans tous les cas, l'onduleur coupe le courant en aval une
fois qu'il a avertit d'une coupure puis respecte une temporisation
avant de le rétablir en avant, même si le courant en amont est revenu
la coupure en aval.
Le mar. 15 mars 2022 Í  10:40, Sébastien Dinot
a écrit :
Le 2022-03-15 10:16, Mathias Dufresne a écrit :
Une option peut être le wake-on-lan si le problème du redémarrage
automatique ne fonctionne pas. Malheureusement ça nécessite une machine
allumée donc soit par un démarrage manuelle, soit une machine qui
arrive a se réveiller toute seule après retour de l'électricité.
P't'être même qu'un vieux PC qui s'allume quand le courant revient pour
lancer des paquets wake-on-lan et qui s'éteigne une fois sa tÍ¢che
terminée pourrait faire l'affaire : Í  la fin de la prochaine coupure,
cette machine devrait se réveiller et lancer les paquets...

Sur mon onduleur, j'ai :
* des prises secourues et qui offrent une protection contre la foudre ;
* des prises *non* secourues, qui offrent une protection contre la
foudre.
Je pense qu'en branchant sur une prise *non* secourue une carte
minimaliste, du genre Raspberry Pi Zero W :
https://www.kubii.fr/cartes-raspberry-pi/1851-raspberry-pi-zero-w-kubii-3272496006997.html
On peut aisément – et Í  moindre cout – fournir le service attendu.
Si le wifi n'est pas disponible, il faudra opter pour un modèle plus «
luxueux » (au regard de l'usage qui en est fait), disposant d'une
interface Ethernet, du genre Raspberry Pi 3 :
https://www.kubii.fr/home/1628-raspberry-pi-3-modele-b-1-gb-kubii-5060214370264.html
Il semblerait que l'on puisse même faire cela avec un simple ESP32 :
https://github.com/mkttanabe/ESP32_WakeOnLan
Sébastien
--
Sébastien Dinot
Ne goͻtez pas au logiciel libre, vous ne pourriez plus vous en passer !
https://www.palabritudes.net/
Avatar
Th.A.C
Le 20/10/2022 Í  15:27, Olivier a écrit :
Suite Í  une nouvelle sollicitation, je déterre ce vieux fil de discussion.
J'ai expérimenté avec un NUC, dont l'option After Power Failure du
BIOS était valorisée Í  Last Stateroot
1. J'exécute echo freeze > /sys/power/state
La machine s'arrête (brutalement, semble-t-il)
Je débranche puis rebranche l'alimentation (comme si un onduleur l'avait fait)
Le serveur démarre avec un boot quasi normal car il affiche
"Recovering journal".

Le freeze ne fait que mettre la machine en 'pause'.
le système ne vide pas ses caches et donc couper le courant ensuite te
fera sÍ»rement perdre des données.
Pour répondre Í  ton scénario en tenant compte du point 3 B, il faut
changer la façon dont ton serveur répond Í  un signal d'avertissement de
l'onduleur.
la commande shutdown a plusieurs options dont une qui arrête bien le
serveur mais ne coupe pas l'alimentation:
shutdown -H ........
dans ce cas, le serveur reste allumé mais le système linux est
complètement arrêté.
Quand l'onduleur coupera le courant, il n'y aura aucune 'casse'.
Et au rétablissement du courant, la machine se rallumera normalement.
Sinon, un passage en hibernation profonde est aussi valable.
2. Idem avec echo standby > /sys/power/state

normal, le système est simplement 'suspendu' et ne vide pas ses caches
ni tout le reste, c'est tout aussi risqué que le freeze.
3. L'option After Power Failure est changée Í  StayOn et l'hibernation
est déclenché par poweroff.
La machine est dans un état inabituel: le bouton power reste allumé
mais l'écran est quasi-vide (un simple tiret en haut Í  gauche).
Je débranche puis rebranche l'alimentation (comme si un onduleur l'avait fait)
Le serveur démarre avec un boot normal (il n'affiche pas "Recovering journal").

Attention de bien attendre que le système ait fini sa procédure de mise
en hibernation.
Suivant ce qui est chargé en mémoire, ca peut prendre du temps pour tout
écrire dans le swap.
Si l'hibernation s'est bien déroulée, c'est que l'acpi n'est pas
correctement géré par ton système qui ne coupe alors pas l'alimentation.
Ou qu'un paramétrage est incorrect...
Un moyen de vérifier si l'hibernation fonctionne est de laisser un ou
plusieurs logiciels ouverts avant l'hibernation.
Au rallumage, tu dois voir des messages indiquant une reprise suite Í 
hibernation et le système doit te remettre exactement ce que tu avais
avant d'hiberner
A. Existe-t-il une commande ou option de configuration sous Linux pour
que le passage Í  l'état freeze évite le "Recovering journal" ? Qu'en
pensez-vous ?

Si tu peux exécuter une commande avant, un 'sync' devrait déja améliorer
la situation.
Il est peut-être possible de forcer le système Í  vider ses caches très
régulièrement, mais ce n'est clairement pas propre.
Sinon il faut démonter les systèmes de fichiers.
Jouer avec le feu ne t'amènera que des problèmes.
B. Comme l'a pointé Sébastien, un point important dans mon scenario
est que dans tous les cas, l'onduleur coupe le courant en aval une
fois qu'il a avertit d'une coupure puis respecte une temporisation
avant de le rétablir en avant, même si le courant en amont est revenu
la coupure en aval.

voir ma réponse du début (point 1)
A noter que la règle est plutÍ´t de configurer l'onduleur pour qu'il ne
rétablisse le courant qu'Í  partir d'un niveau de charge considéré comme
'safe'.
Si tu préfères, le niveau de charge doit garantir qu'en cas de coupure
inopinée
- il y ait assez de courant pour que ton serveur ait le temps de démarrer.
- que le service NUT soit actif pour recevoir les alertes de l'onduleur
- que ton serveur ai le temps de s'arrêter
.
Je n'ai jamais eu Í  travailler sur ce point, mais si l'onduleur envoie
un signal quand il tombe Í  10 %, on peut considérer que qu'il en faut
bien plus pour un rallumage en toute sécurité...
Sinon, un point qui ne concerne que l'onduleur, il faut vraiment tester
la batterie:
j'ai déjÍ  eu des onduleurs qui coupaient sauvagement bien avant
d'atteindre le seuil minimum.
Je n'ai pas eu le temps d'analyser le problème, mais cela pouvait venir:
- soit d'une batterie défectueuse
- soit d'un besoin de recalibrage de l'onduleur.
Avatar
Basile Starynkevitch
On 20/10/2022 21:08, Th.A.C wrote:
Si tu peux exécuter une commande avant, un 'sync' devrait déja
améliorer la situation.
Il est peut-être possible de forcer le système Í  vider ses caches très
régulièrement, mais ce n'est clairement pas propre.

Pourquoi ne serait-ce pas propre?
Pour ceux que ça intéresse, j'ai codé en C un petit utilitaire (sous
licence GPLv3+) qui appelle sync périodiquement:
https://github.com/bstarynk/misc-basile/blob/master/sync-periodically.c
(et je cherche des partenaires intéressés par un consortium
HorizonEurope ou ANR finançant et utilisant le logiciel d'IA symbolique
RefPerSys en http://refpersys.org/ - qu'ils me contactent par courriel
aussi au bureau, CEA LIST, en ....)
--
Basile Starynkevitch
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/
Avatar
Olivier
CÍ´té serveur, je pense utiliser la combinaison "After Power Failure
valorisée Í  StayOn /arrêt par Poweroff".
Pour éteindre mon serveur, il faut lui demander de s'arrêter puis
quelques secondes après lui couper sa prise de courant.
Pour le remettre en service, il faut et il suffit "d'allumer" sa prise
de courant.
CÍ´té onduleur, il me faudrait un onduleur, outre ses qualités propres
(puissance, facilité d'entretien des batteries, ...):
A- qui sache immédiatement notifier un arrêt du courant en amont
B- qui sache notifier avec un certain retard un rétablissement du
courant en amont (*)
C- qui sache alerter un serveur quand son niveau de batterie passe
sous un certain seuil et sache arrêter des prises de courant en aval,
un certain temps après l'envoi d'alerte (tant pis si l'alerte n'a pas
été reçue ou si courant en amont est revenu entre temps)
D- qui sache rétablir des prises de courant en aval quand le courant
en amont est revenu et quand la batterie est au dessus d'un certain
seuil.
Avec une interface Ethernet sur l'onduleur, les notifications
pourraient s'opérer par courriel et les alertes par SNMP ou autre
(HTTP ?). Il resterai Í  vérifier que les exigences ci dessus soient
satisfaites.
La A me parait facile Í  satisfaire.
La B n'est pas si importante que cela.
La C et la D me paraissent difficile Í  lire sur une datasheet.
Peut-être qu'en consultant un manuel ?
(*) Si je n'ai pas de réseau hors bande, il est probable que les
moyens de transmissions des notifications ne soient pas encore
rétablis quand le courant en amont vient juste de se rétablir
Le jeu. 20 oct. 2022 Í  21:16, Basile Starynkevitch
a écrit :
On 20/10/2022 21:08, Th.A.C wrote:
Si tu peux exécuter une commande avant, un 'sync' devrait déja
améliorer la situation.
Il est peut-être possible de forcer le système Í  vider ses caches très
régulièrement, mais ce n'est clairement pas propre.

Pourquoi ne serait-ce pas propre?
Pour ceux que ça intéresse, j'ai codé en C un petit utilitaire (sous
licence GPLv3+) qui appelle sync périodiquement:
https://github.com/bstarynk/misc-basile/blob/master/sync-periodically.c
(et je cherche des partenaires intéressés par un consortium
HorizonEurope ou ANR finançant et utilisant le logiciel d'IA symbolique
RefPerSys en http://refpersys.org/ - qu'ils me contactent par courriel
aussi au bureau, CEA LIST, en ....)
--
Basile Starynkevitch
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/
Avatar
Olivier
Dans la documentation Eaton, je découvre le paramètre Redémarrage
forcé, qui activé, me semble bien correspondre Í  l'exigence C
"Si le réseau est rétabli pendant une séquence
d'arrêt :
- s'il est activé, la séquence d'arrêt se termine
et attend 10 secondes avant le redémarrage
- s'il est désactivé, la séquence d'arrêt ne
se termine pas et le redémarrage a lieu
immédiatement."
Le ven. 21 oct. 2022 Í  10:36, Olivier a écrit :
CÍ´té serveur, je pense utiliser la combinaison "After Power Failure
valorisée Í  StayOn /arrêt par Poweroff".
Pour éteindre mon serveur, il faut lui demander de s'arrêter puis
quelques secondes après lui couper sa prise de courant.
Pour le remettre en service, il faut et il suffit "d'allumer" sa prise
de courant.
CÍ´té onduleur, il me faudrait un onduleur, outre ses qualités propres
(puissance, facilité d'entretien des batteries, ...):
A- qui sache immédiatement notifier un arrêt du courant en amont
B- qui sache notifier avec un certain retard un rétablissement du
courant en amont (*)
C- qui sache alerter un serveur quand son niveau de batterie passe
sous un certain seuil et sache arrêter des prises de courant en aval,
un certain temps après l'envoi d'alerte (tant pis si l'alerte n'a pas
été reçue ou si courant en amont est revenu entre temps)
D- qui sache rétablir des prises de courant en aval quand le courant
en amont est revenu et quand la batterie est au dessus d'un certain
seuil.
Avec une interface Ethernet sur l'onduleur, les notifications
pourraient s'opérer par courriel et les alertes par SNMP ou autre
(HTTP ?). Il resterai Í  vérifier que les exigences ci dessus soient
satisfaites.
La A me parait facile Í  satisfaire.
La B n'est pas si importante que cela.
La C et la D me paraissent difficile Í  lire sur une datasheet.
Peut-être qu'en consultant un manuel ?
(*) Si je n'ai pas de réseau hors bande, il est probable que les
moyens de transmissions des notifications ne soient pas encore
rétablis quand le courant en amont vient juste de se rétablir
Le jeu. 20 oct. 2022 Í  21:16, Basile Starynkevitch
a écrit :
On 20/10/2022 21:08, Th.A.C wrote:
>
>
> Si tu peux exécuter une commande avant, un 'sync' devrait déja
> améliorer la situation.
> Il est peut-être possible de forcer le système Í  vider ses caches très
> régulièrement, mais ce n'est clairement pas propre.
Pourquoi ne serait-ce pas propre?
Pour ceux que ça intéresse, j'ai codé en C un petit utilitaire (sous
licence GPLv3+) qui appelle sync périodiquement:
https://github.com/bstarynk/misc-basile/blob/master/sync-periodically.c
(et je cherche des partenaires intéressés par un consortium
HorizonEurope ou ANR finançant et utilisant le logiciel d'IA symbolique
RefPerSys en http://refpersys.org/ - qu'ils me contactent par courriel
aussi au bureau, CEA LIST, en ....)
--
Basile Starynkevitch
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/
Avatar
Sébastien Dinot
Olivier a écrit :
Dans la documentation Eaton, je découvre le paramètre Redémarrage
forcé, qui activé, me semble bien correspondre Í  l'exigence C

Ça m'intéresse. O͹ as-tu trouvé cette information ? Pour ma part, je
n'ai jamais trouvé mieux qu'un succinct manuel en 9 pages.
Sébastien
--
Sébastien Dinot,
http://www.palabritudes.net/
Ne goͻtez pas au logiciel libre, vous ne pourriez plus vous en passer !
Avatar
Olivier
https://www.eaton.com/content/dam/eaton/products/backup-power-ups-surge-it-power-distribution/backup-power-ups/eaton-5p-ups/eaton-5p-manuel-d-installation-et-d-utilisation.pdf
page 11
Le sam. 22 oct. 2022 Í  01:29, Sébastien Dinot
a écrit :
Olivier a écrit :
Dans la documentation Eaton, je découvre le paramètre Redémarrage
forcé, qui activé, me semble bien correspondre Í  l'exigence C

Ça m'intéresse. O͹ as-tu trouvé cette information ? Pour ma part, je
n'ai jamais trouvé mieux qu'un succinct manuel en 9 pages.
Sébastien
--
Sébastien Dinot,
http://www.palabritudes.net/
Ne goͻtez pas au logiciel libre, vous ne pourriez plus vous en passer !
1 2 3