Vous le trouverez à l'adresse http://www.nokia-n900.fr

Le mien est déjà pré-commandé...

Maintenant, la ou les clés valides doivent être présentes dans le répertoire .ssh/login-keys.d :

ln -s  ~/.ssh/id_rsa ~/.ssh/login-keys.d/

Quant aux options dans le répertoire /etc/pam.d/, elles changent.

Tout d'abord, plus de fichier pam-ssh-* (ni ssh-* pour les versions intermédiaires).

Puis dans le fichier /etc/pam.d/common-auth, il faut mettre, avant la première ligne commençant par auth :

 auth sufficient pam_ssh.so try_first_pass

Et enfin dans le fichier /etc/pam.d/common-password, il faut mettre, avant la première ligne commençant par password :

session optional pam_ssh.so

Et voilà, cela fonctionne comme avant

Pour cela il suffit de rajouter, dans la conf, la clé ram_used dans %seuil_alertes et %seuil_alertes_niveau2, en indiquant une quantité de RAM en ko

Je viens aujourd'hui d'en trouver un autre, auquel j'ai trouvé une solution, en anglais, que je précise ici (je ne précise que la solution qui marche partout)

Le problème est le suivant : quand on créé un bouton radio dans internet explorer, en javascript, via document.createElement('input')........ le bouton est bien créé mais on ne peut le cocher.

La solution, la seule, l'unique, est... de ne pas utiliser le dom pour cela, malheureusement. Il faut le créer en html :

<input type="radio" name="truc" id="bidule" value="chose" />

La solution qui semble le mieux fonctionner dans les différents navigateurs est, sans faire de test de navigateur :

elementParent.innerHTML += '<input type="radio" name="truc" id="bidule" value="chose" />'

C'est moche, mais c'est tout ce qui marche.

Autre point, il ne faut pas, pour IE, spécifier ici l'état "checked" car si un radio du même groupe (même attribut "name") est déjà coché, on se retrouvera avec deux boutons radio cochés...

Il faut, une fois nos inserts terminés, faire par exemple :

document.getElementById(input_id).checked = true

Alors il existe bien sur la commande svn propset svn:ignore "*.pyc" le_rep mais il faut non seulement le faire pour chaque projet, mais en plus pour chaque répertoire.

Une solution plus simple, et globale, consiste à dire à svn de toujours ignorer les fichiers qui ne nous intéressent pas, ce dans notre fichier de configuration $HOME/.subversion/config (dans la section miscellany) :

global-ignores = *.pyc .*.swp

Voici trois fonctions pour connaître l'état d'une variable :

• is_null (bon là, ok)
• isset (absence d'underscore)
• empty (sur ce coup là on a même pas le is)

Sans cohérence. Euh je voulais dire : Sans commentaire.

En effet il lui fallait alors un bon paquet de minutes avant de redémarrer, devant reconstruire je ne sais plus quel fichier dont il avait besoin.

J'ai donc rajouté un bloc dans la configuration (demons_brute_stop) qui permet de spécifier pour quels démons on utilise cette fonctionnalité, et combien de tentatives auront lieu au maximum.

J'en ai profité pour rajouter une ligne dans le bloc des process à ne pas tuer si trop long (process_to_keep) :

'sys_alive', # on ne kill pas sys_alive

Voilà tout.

Pas de gros changements dans cette version, juste quelques petits remaniements dans le fonctionnement du mode démon pour que sys_alive puisse être utilisé dans les scripts de démarrage de linux (sous debian, ubuntu... : /etc/init.d/sys_alive.pl et /etc/rcX.d/Ssys_alive.pl via update-rc.d)

Je renseignerai prochainement le wiki du trac associé à sys_alive pour expliquer tout ça plus en détail, sachez juste qu'en mode demon, sys_alive se lance avec comme paramètre start ou stop.

PS : le téléchargement se passe sur http://scripts.twidi.com

Au menu des nouveautés :

• fonctionnement possible en mode démon à la place du mode cron
• force l'arrêt de certains démons qui n'auraient pas été stoppés correctement via l'appel de la commande en conf
• mise en place de trac (sys_alive étant géré via svn depuis la version 1.2.8)

A propos du mode démon

sys_alive tournait jusque là en cron toutes les minutes (ou autre selon votre paramétrage). Ce qui induisait, chaque minute, un process cron et un process perl...

Finalement, un sys_alive qui tourne en démon a plusieurs avantages :

• moins de process, donc moins de charge induite (notamment en cas de forte charge du serveur, j'ai déjà vu une bonne vingtaine de cron et de perl+sys_alive tourner)
• paramétrage du délai plus fin (par défaut à 60 secondes, peut être changé en conf)

La contrepartie c'est que maintenant sys_alive a besoin de deux modules perl : Proc::Daemon et File::Pid (disponibles tous les deux via cpan)

Au niveau de la configuration, un bloc a été rajouté :

 %mode_demon = (
   'actif'    => 1,                            # 0 pour fonctionnement classique en cron, 1 pour fonctionnement en demon
   'pid_file' => '/var/run/sys_alive.pid',     # emplacement du fichier pid (
   'wait'     => 60,                           # délai (en secondes) d'attente entre deux analyses
 );

PS : ce mode démon m'a donné plein d'idées pour une version 2 ;)

SliTaz GNU/Linux est une mini distribution francophone d'environ 25 Mo, distribuée sous forme de LiveCD, elle fonctionne entièrement en mémoire vive (RAM), ce qui permet d'avoir un système rapide avec des applications réactives ...

Plus d'infos sur le lien ci-dessus ou directement sur le site (en français) de SliTaz