niol a écrit 403 commentaires

   Jun 21 05:25:13 ripley postfix/smtp[12991]: D49476111C: to=<xx@gmail.com>, orig_to=<postmaster@xxx.org>, relay=smtp.free.fr[2a01:e0c:1:1599::10]:25, delay=4.8, delays=0.17/0.01/0.97/3.6, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as XXXXXXXX)

Je pense que ça vient du fait que tu essaye d'utiliser smtp.free.fr à travers ton tunnel, et donc que tu sembles venir de l'extérieur, et donc le relais n'est pas ouvert.

Pareil que ce que j'ai. Donc ce n'est pas un chroot. C'est juste les droits d'accès sur les répertoires (pas de droit de lecture du répertoire mais droit d'exécution pour pouvoir atteindre les fichiers qui sont dedans, par exemple /bin/ls. Ce s'obtient peut-être avec une truc du genre :

# chmod go-r /
# chmod go-r /bin
# (etc.)

(je n'ai pas testé du tout)

Cependant, ça n'est pas très simple à mettre en place, ni très maintenable (il ne faut rien oublier). Il doivent sûrement utiliser des patchs noyau qui permettent de mettre des permissions par défaut (style grsecurity).

Chez OVH, que dit la commande pwd? Si c'est /home/user, c'est que tu n'es pas chrooté.

Ce patch est obsolète depuis l'option ChrootDirectory.

Tout dépend de si tu veux autoriser l'exécution de commandes sur le serveur ou donner un simple accès SFTP :
- exécution de commandes : voir le fichier de configuration OpenSSH et ForceCommand pour restreindre. Il y a aussi des outils pour restreindre les commandes, du genre scponly ou rssh.
- SFTP simple : voir le fichier de configuration OpenSSH et ChrootDirectory pour changer la racine.

Je ne me suis jamais penché sur les méthodes de chroot qui impliquent de recopier les exécutables utiles dans le chroot, ça me paraissait trop difficile à maintenir (mise à jours, etc.).

Aucune idée de comme ça se passe chez OVH, mais l'accès que j'ai chez eux n'est pas chrooté.

• Decreased Productivity
• Image-Show-Hide
• Zap bookmarklet

Par contre si le but est d'économiser de la bande passante et de ne pas charger du tout les images, il faut tester.

A base de git :
git sync - http://code.google.com/p/git-sync/ (script autour de git)
persy - http://persy.digitalkultur.net/ (bien fini, avec interface graphique qui semble intégrée à gnome)

lsyncd http://code.google.com/p/lsyncd/ (semble pas bidirectionnel)

En général pour cela j'utlise rsync --progress.

netstat -nta pourra te donner des informations précieuses.

Je pense que les deux écoutes (PuTTY et le IBM http server) n'utilisent pas la même adresse d'écoute. PuTTY se met normalement sur 127.0.0.1. Ce ne doit pas être le cas de ton programme et du IBM http server.

Je ne comprends pas bien ta problématique, donc je m'en tiens à ce que tu demandes : installer mysql 4.1 sur ubuntu 10.04 (qui normalement a mysql 5).

Je pense que le backport (recompilation du paquet source pour ubuntu 10.04) va être un enfer à cause des dépendances inverses, mais je me trompe peut-être.

Si tu veux quelque chose de rapide, je te conseille de faire un chroot etch pour ton mysql 4.1. Pour avoir un environnement le plus proche de ton environnement de production actuel, tu peux même utiliser un peu mieux que du chroot mais pas bien plus compliqué à mettre en place comme Vserver, OpenVZ ou LXC, sachant que ce dernier a l'avantage d'être utilisable avec le noyau par défaut.

Ce lien est passé par ici il y a pas si longtemps. Ça pourra t'être utile.

http://kevin.denis.free.fr/roaming/roaming-wifi.pdf

D'après ce que j'ai compris, les websockets sont très intéressants pour le développeur d'application web. En effet, il permettent de notifier le navigateur.

Par exemple, plutôt que d'envoyer une requête asynchrone en javascript toutes les minutes pour voir si on ne doit pas afficher un nouvel e-mail dans l'application de webmail, la connexion websockets permet, sans autre plugin, au serveur d'envoyer un message qui dit "nouveau mail" au navigateur qui va ainsi pouvoir faire ce qui est nécessaire pour l'afficher.

On peut ainsi passer du polling à la publication ce qui est beaucoup plus efficace en terme de bande passante et de charge du serveur.

http://home.gna.org/jyraphe/

netconsole peut aussi t'aider pour récupérer les traces sur un autre PC de ton réseau local Ethernet.

Si tu veux faire du SSH, je te conseille de choisir un modèle avec clavier physique (il semblerait que les Android du moment disposant d'un clavier physique soient le HTC Desire Z ou le Motorola Milestone 2).

Pour ce qui est de l'opérateur, si tu choisis SFR, évite les forfaits qui te mettent sur le point d'accès wapsfr car tu n'auras pas la notification des nouveaux mails gmail ainsi que le droit d'installer des applications depuis Android Market en 3G. Mais je ne sais pas si les nouveaux forfaits utilisent encore ce point d'accès... Bref il est très difficile de savoir le bridage d'Internet que tu auras, je te conseille si tu en as la possibilité de tester avec l'abonnement d'un ami si tu en as l'occasion. Les forums et les descriptifs des abonnements ne sont malheureusement que de peu d'aide à ce sujet...

Ça dépends de ton usage mais je pense à :
- rdiff-backup http://www.nongnu.org/rdiff-backup/ qui ne va pas trop t'aider si tu veux pouvoir analyser les différences mais va pouvoir t'aider à récupérer les anciennes versions par la date.
- etc-keeper pour /etc http://kitenet.net/~joey/code/etckeeper/
- Une page qui recense les essais de gestion de /home par un système de gestion de versions http://vcs-home.madduck.net/ , peut-être voir en particulier depuis cette page les outils git-home-history, peut-être la solution si j'ai bien compris ton problème, et git-annex qui permet de gérer un arbre de fichiers dans git mais sans s'intéresser au contenu des fichiers.

C'est le passage aux UUID qui semble te mettre la pagaille (passage à libata pour les drivers de contrôleur de disque dur qui change les noms de par exemple de hdx à sdy). S'il ne trouve pas le système de fichier racine, c'est à mon avis que ta configuration de grub nécessite une mise à jour.

En tout cas, si tu veux creuser ton problème, je cois qu'il faut que tu essayes avec le noyau officiel... Ca permettrait d'isoler le problème.

Et dans tous les cas, tu aurais intérêt à migrer à libata pour tes disque durs, c'est dorénavant la manière de faire dans le noyau vanilla depuis plusieurs versions...

Pour mon information, car je suis curieux, y-a-t-il une option de la compilation officielle qui te pousse à recompiler toi-même?

As-tu essayé avec le noyau compilé par Debian :

# aptitude install linux-image-2.6

Quel est l'extrait de dmesg qui donne l'erreur de chargement de i915? Le log de Xorg ( /var/log/Xorg.log ) donne-t-il quelque chose? Y-a-t-il un OOPS noyau (à éventuellement capturer avec netconsole s'il n'apparait pas dans les logs)?

Merci, j'avais déjà lu des choses sur l'$IFS, mais par la suite ça me semble plus compliqué vu que je veux réutiliser cette variable pour construire une ligne de commande.

Impeccable, je savais qu'il y avait une solution! Merci. Ainsi, je peux invoquer ma commande directement de la façon suivante :

# cowbuilder --create "${COWBUILDER_OPTS[@]}" --basepath=/path

Merci pour la syntaxe =~ que je ne connaissais pas.

A mon avis, la ligne important de l'erreur concerne le fait que le paquet grub-pc est introuvable sur le cd-rom. Il faudrait voir pourquoi.

http://svn.debian.org/wsvn/d-i/trunk/installer/doc/devel/apt(...)

Ce sont des directives de debian-installer.

http://svn.debian.org/wsvn/d-i/trunk/packages/debian-install(...)

Si tu veux améliorer leur filtre, mes logs indiquent http://postmaster.free.fr/#spam_detected qui mène à la procédure suivante pour leur signaler les faux positifs.

http://postmaster.free.fr/#faux_positifs