peck a écrit 565 commentaires

Le plus probable c'est quand meme une erreur de manip :

* Appel d'un commande au mauvais endroit avec *
* Appel d'un script qui fait des choses que tu ne sais pas
* Soft buggé
* Une cron a fait le travail à ta place

s/- récupération de la sauvegarde/- rsync de l'acienne version/

En effet c'est tout le contraire.
Mais ça ne veut pas dire que la méthode n'est pas bonne, il suffit juste de la précéder d'une restauration de la sauvegarde.

- tar du home
- recupération de la sauvegarde
- untar du home sans les droits

Non, tu ne crée pas de serveur esclave. Tu active simplement les logs sur le serveur. Il sont en théorie destiné à un esclave, mais rien ne t'oblige à en mettre un, d'ailleurs on n'utilise plus cette méthode pour faire des esclaves maintenant.

C'est tout à fait jouable en utilisant les logs de réplication. Tu les actives sur le serveur ldap (man slapd.conf, section loglevel) :

Ensuite tu les parse avec un script perl / php / le langage que tu veux pour le transformer en requête sql. C'est assez facile, le format c'est du ldiff documenté ici http://www.openldap.org/software/man.cgi?query=slapd.replog&(...) par contre ça peut être un peu laborieux selon la structure de ta base.

Au bout d'un moment, apt-get install -f ne me renvoie plus qu'une liste de dépendances non-satisfaites et me signale que le sous processus dpkg -i a renvoyé une erreur.


Tout est ici, il faut lire la sortie en détail, trouver le paquet fautif et le corriger. Après c'est du cas par cas : corriger un paquet deb et l'installer à la main, changer le droit d'accès à un fichier, supprimer un fichier ...

Attention //noeud cherche tous les noeuds dans tous le document.

N'empêche qu'il faut quand même écrire le code.

Je t'aurais bien aidé coté packaging et finitions, mais je ne pense pas avoir le temps pour faire du code.

Cela se fait avec @, ton expression est donc quelque chose comme :

//noeud/@*


Sinon pour les < et > cela se fait avec &lt; &gt;

Attention, si ton script tourne en safe mode, il se peut qu'il n'ai pas le droit d'exécuter des commandes.

La commande exec() exécute la commande, point. La sortie standard n'est pas redirigée. Utilise plutôt passthru() ou popen().

Directx9, ça va être lourd à porter sous d'autres OS.

Finalement c'est pas idiot de détourner son utilisation.
Il sait déjà faire le filtrage, le tri, accepter des messages d'une machines distante et écrire le tout dans un fichier.

Au pire tu doit pouvoir ajouter un filtre si tu veux modifier les informations reçues avant de les écrire sur le fichier.

C'est simplement lié aux droits d'accès au serveur X, même problème qu'une question récente : http://linuxfr.org/forums/10/25698.html

La réponse doit être dans les logs du serveur, peut-être que tu as interdit l'authentification par clé genre avec une directive "PubkeyAuthentication no"

debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/pampryl/.ssh/identity
debug1: Offering public key: /home/pampryl/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/pampryl/.ssh/id_dsa
debug1: Next authentication method: password


Clairement il y a eu une erreur lors de la copie de ta clé publique sur le serveur distant.

Sauf que la ta commande essaie de se connecter au serveur X de la machine d'où tu viens.

Essaie en précédant ta commande de

export DISPLAY=:0


Si ça ne marche pas, c'est qu'il faut autoriser la connexion. Pour ça, soit sur le serveur X de destination (mais il faut l'avoir prévu à l'avance)
xhost +local:

Revérifie que tuas bien copié les clés dans le bon sens (un espace est vite oublié dans un commande qui la mettrait en local.

D'autre part, authorized_keys peut contenir plusieurs clés, cp n'est pas une bonne idée. Il y a beaucoup plus simple pour les 2 manip :

poste1$ ssh-keygen -t rsa
poste1$ ssh-copy-id poste2


Après il te reste les logs du serveur ssh pour analyser (et l'option -v de ssh).

http://invisible-island.net/xterm/xterm.faq.html#how2_fkeys

Je crois que la différence ne tient qu'au nom, mais je ne suis pas sur.

Un tube nommé c'est un pipe (comme ca |) mais qui a un nom dans le système de fichier (comme /tmp/toto). La seule fonction d'un tube (ou pipe) c'est de lire toute ce que tu lui envoie et de le ressortir tel quel. Ainsi tu peux faire croire à une application qu'elle lit un fichier alors qu'elle lit un flux que tu lui envoie au fur et a mesure.

Et en effet, avec cette méthode tu ne peux pas connaître la position du curseur puisque tu ne lis que des evenements de déplacement de souris qui sont interpretés après par le serveur X. Et dans ce cas tu n'as pas de meilleur source d'information que X -> voir le message en dessous sur vnc.

Pas tout à fait. C'est justement l'intérêt des dev/input, le noyau formate les messages.
Donc à part différencier clavier / souris ... (et seulement s'il a besoin) l'utilisateur n'a pas complexité à gérer.

Oui en se mettant en filtre.

Tu lis /dev/input/mice puis tu ressort le tout telquel dans un pipte nommé (commande mkfifo) et tu utilise ce pipe dans la config de X comme device de souris.

Pour la lecture je connais http://search.cpan.org/~beppu/Linux-Input-1.02/lib/Linux/Inp(...) en perl, mais je ne sais pas quelle est la lib C qui est en dessous.

C'est probablement ton serveur dns qui timeoute.
Regarde le contenu de /etc/resolv.conf

Le cn=* n'est pas accepté par tous les navigateurs.

Pour une solution multidomaine je vais faire ma pub :-)

http://linux-attitude.fr/post/Et-la-marmotte

export lit la variable a exporter ->
"export RANDOM=12" == "RANDOM=12 && echo $RANDOM > /dev/null"

Sinon, je n'ai pas le même problème que toi pour la méthode 4

crontab - te permet de remplir ta crontab avec un pipe.

Donc un truc du genre :
crontab -l | script_de_modif | crontab -