Posté par P.-A. (page perso, ) le 26/09/2008 à 18:35. (lien). Évalué à 1.

Dans ce cas il faut regarder les capacités de ton MDA je suppose.

Par défaut Postfix passe par local (http://www.postfix.org/local.8.html).
Ou sinon vu que t'as déjà courier, tu peux utiliser http://www.courier-mta.org/maildrop/ en supposant qu'il est plus "puissant".

Dans tous les cas ça dépend essentiellement de ton MDA.

[ Répondre ]

Posté par P.-A. (page perso, ) le 26/09/2008 à 14:23. (lien). Évalué à 1.

Je ne saurais pas répondre à toutes les questions mais néanmoins :

Tu dois utiliser $final_spam_destiny = D_PASS pour laisser passer les SPAM détectés. À partir de ce moment seul l'header est rajouté mais le mail est bien délivré.

1 - C'est à ton MDA/LDA de se charger de cela, pas Amavis en lui même. procmail, maildrop, Dovecot LDA en font partie.
2 - Jamais mis ça en place mais idem que pour 1 d'après moi.
3 - Ça devrait être possible mais pour cela il faut que Spamassin maintienne une base de données par utilisateur.

[ Répondre ]

Posté par P.-A. (page perso, ) le 10/09/2008 à 14:56. (lien). Évalué à 3.

Sur un jour uniquement? Ça me parait quand même chelou vu les mécanismes de DNS.

[ Répondre ]

Posté par P.-A. (page perso, ) le 01/09/2008 à 14:51. (lien). Évalué à 2.

J'ai pas l'impression qu'il s'agisse du même problème. Il parle surtout de la possibilité de pouvoir "chaîner" (si vous avez un meilleur terme) les svn move dans la copie locale sans être obligé de commiter à chaque étape.

Par contre il parle clairement du problème de design de l'implémentation du move dans SVN (finalement un svn delete + svn add) et que le problème est complexe : http://subversion.tigris.org/issues/show_bug.cgi?id=898

Sur ce bug on peut également trouver un PPT d'un mec qui fait un état des lieux des problèmes actuels à ce sujet : http://subversion.tigris.org/nonav/issues/showattachment.cgi(...)

[ Répondre ]

Posté par P.-A. (page perso, ) le 01/09/2008 à 14:40. (lien). Évalué à 2.

Au final je me suis avancé un peu vite, le blog Subversion aborde quand même le sujet et reconnaît d'ailleurs le problème : http://blogs.open.collab.net/svn/2008/07/subversion-merg.htm(...) (voir Problems with Reintegrate and Renamed Files)

[ Répondre ]

Posté par P.-A. (page perso, ) le 01/09/2008 à 14:06. (lien). Évalué à 3.

L'exemple décrit est relativement simpliste quand même. Ça prouve que le merge tracking fonctionne et que du coup l'utilisateur n'a plus besoin de noter les numéros de révision pour effectuer les merge.

Le problème le plus important que Temsa aborde (de mon point de vue en tous cas), c'est essentiellement le refactoring dans les branches (donc du svn move après un svn copy) et là, d'après la nightly doc, rien n'a changé. Il ne me semble pas non plus avoir vu qqch à ce sujet sur les articles du blog de subversion.

http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advan(...)

[ Répondre ]

Posté par P.-A. (page perso, ) le 26/08/2008 à 12:37. (lien). Évalué à 2.

EVOLUTION ???? (putain de sac à merde au niveau légèreté par rapport à thunderbird, sylpheed ou autre mailer graphique qui fait tout sans le http over rpc pour parler à un SALEexchange, est-ce une raison d'en faire une usine à gaz pareille ? ) (et je parle meme pas de Kmail qui est convi mais se vautre sur un .INBOX imap de 10.000 mails...).


Tu l'as essayé "récemment"? Tt se passait bien pour moi avec Thunderbird mais plus la taille de ma boîte IMAP augmentait (~ 1Go maintenant, bref rien d'énorme), plus il devenait lent. Je suis donc passé à Evolution (2.22) et c'est bcp plus agréable à utiliser d'un point de vue rapidité.
Sans compter :
- IMAP déconnecté (marche très bien chez moi)
- intégration avec Gnome (selon les goûts)
- Fait un peu (bcp?) plus que juste client Mail

Après tout n'est pas rose :
- Je suis obligé de le killer de temps en temps lorsqu'il ne veut plus m'afficher le contenu des messages (j'ai pas encore compris pourquoi)
- le moteur de rendu HTML est pas terrible d'où des mails avec du HTML complexe qui part en vrac.
- ergonomie laissant à désirer sur certains points

[ Répondre ]

Posté par P.-A. (page perso, ) le 26/08/2008 à 11:12. (lien). Évalué à 1.

euh oui même si j'ai écrit le contraire j'avais compris ce que tu voulais dire :D

Sur ce point j'expérimente la même chose que toi avec le clavier de mon T40p qui surclasse celui de mon T61 (ce dernier étant déjà au dessus du lot par rapport à la plupart des portables qui traînent au boulot). Mais sur ce cas précis il faut également savoir que les Thinkpads ont des claviers de 3 marques : NMB, Alps et Chicony. Si t'as la première marque t'es bénie des dieux, si t'as les 2 autres ce sont juste de bon clavier.

Mis à part cela et qq impression au toucher où je trouvais le T40p mieux j'ai quand même l'impression que le T61 est vachement plus solide.

[ Répondre ]

Posté par P.-A. (page perso, ) le 25/08/2008 à 21:36. (lien). Évalué à 2.

Et en quoi les anciens Thinkpad sont moins bon que les nouveaux? J'ai les 2 donc je me permets de comparer. (Je compare pas par rapport à Pana par contre vu que j'en ai jamais eu entre les mains :D)

[ Répondre ]

Posté par P.-A. (page perso, ) le 01/08/2008 à 12:04. (lien). Évalué à 4.

A ce sujet il me semble que GandiBlog a été un peu une plateforme de test grandeur nature pour Dotclear 2.
Il me semble également que le créateur de Dotclear a été embauché par Gandi essentiellement pour relancer le projet Dotclear 2 et l'améliorer.

http://www.gandi.net/domaine/blog/
http://www.lebardegandi.net/category/GandiBlog

[ Répondre ]

Posté par P.-A. (page perso, ) le 24/07/2008 à 15:23. (lien). Évalué à 1.

Voilà c'est fait. Je l'ai finalement fait à la mano avec rsync. Je sentais pas le pvmove (surtout que avant une taille de PV plus petit) et la récupération sur crash me faisait un peu peur.

Mais j'ai eu quand même qq problèmes ensuite avec /proc, /dev, et /sys mais bon je l'ai un peu cherché sur ce coup là vu que j'ai fait le rsync à partir d'un système live.


Merci de vos indications

[ Répondre ]

Posté par P.-A. (page perso, ) le 24/07/2008 à 11:06. (lien). Évalué à 1.

pour ma part, je me suis tourné vers une surcouche de rsync (ou plutôt de librsync) : rdiffbackup : http://www.nongnu.org/rdiff-backup/

C'est simple à utiliser, ça gère l'historisation et le backup en remote est lisible et l'utilisation est à mon sens plus simple que rsync.

[ Répondre ]

Posté par P.-A. (page perso, ) le 24/07/2008 à 10:33. (lien). Évalué à 1.

Oui finalement c'est peut être la méthode la plus simple et la plus maîtrisé par moi.

Au passage comme ça se passe pour la gestion des UUIDs niveau disque? Pour le moment je me dis qu'il suffit de modifier les entrées de /etc/fstab et de /boot/grub/menu.lst pour remplacer les UUIDs par les périphériques (/dev/sdax). C'est suffisant?



PS : rien à voir mais bon site et merci pour http://linux-attitude.fr/post/Atelier-lecture-bis , j'en ai profité pour mettre à jour mon google reader

[ Répondre ]

Posté par P.-A. (page perso, ) le 24/07/2008 à 10:28. (lien). Évalué à 1.

Si ce n'est pas le cas, alors il faut réduire la taille des partitions jusqu'à ce que cela corresponde. Dans ce cas, il sera peut-être plus simple de créer un nouveau volume groupe, et faire une copie des données (avec cp ou équivalent) de l'ancienne vers la nouvelle partition.

Justement les partitions seront plus petites sur le nouveau disque. Et j'ai un peu peur de me lancer dans un resize comme ça juste avant de faire un pvmove.


Pour la récupération des données sur l'ancien disque, la question n'est pas très claire, tu veux récupérer les données ? Ou t'assurer que ce n'est pas possible ?

Après le pvmove, je voudrais savoir si :
- les données de l'ancien volume LVM sont tjrs lisibles
- si oui, par quel moyen

Le but pour moi et de me servir ensuite de l'ancien disque en tant que backup.

[ Répondre ]

Posté par P.-A. (page perso, ) le 24/07/2008 à 09:57. (lien). Évalué à 1.

Ce serait certainement plus assisté avec moins de risque de faire des erreurs. Bon je voudrais éviter l'utilisation de stockage intermédiaire mais c'est à voir. Je check la doc.

[ Répondre ]

Posté par P.-A. (page perso, ) le 24/07/2008 à 09:55. (lien). Évalué à 1.

Mais justement après le pvmove, il existe un moyen de lire les données sur l'ancien PV? Ce que je veux dire par là c'est qu'une commande type pvcopy serait exactement ce que je cherche :D.
Mais après tout tant que j'ai un moyen de lire les données présente sur l'ancien PV, pas de soucis

[ Répondre ]

Posté par P.-A. (page perso, ) le 14/02/2008 à 14:23. (lien). Évalué à 1.

Pas mieux. C'est simple, léger et c'est fait uniquement pour cela (ça mériterait quand un peu plus d'options de rewrite)

[ Répondre ]

Posté par P.-A. (page perso, ) le 14/02/2008 à 14:15. (lien). Évalué à 1.

J'suis pas super à l'aise sur le sujet mais

T'as configuré LVM pour qu'il soit en mode CLUSTER? Dans le lvm.conf tu dois avoir qqch du genre

locking_library = "liblvm2clusterlock.so"
locking_type = 2
library_dir = "/lib/lvm2"


T'as la suite redhat-cluster installée et de configurée?

[ Répondre ]

Posté par P.-A. (page perso, ) le 15/01/2008 à 15:49. (lien). Évalué à 2.

Par défaut (sous debian like en tt cas), faut configurer syslog pour avoir les logs OpenLDAP

http://anothergeekwebsite.com/fr/2007/03/activer-les-logs-do(...)

[ Répondre ]

Posté par P.-A. (page perso, ) le 23/11/2007 à 16:38. (lien). Évalué à 1.

Oui je comprends bien, uniquement les requêtes DNS.

Mais dans ce cas de figure, quand la connexion VPN lâche les requêtes DNS deviennent plus lentes. J'ai essayé de customiser un peu mon fichier /etc/resolv.conf pour que ce soit rapide même sans VPN actif mais je n'ai pas encore réussi à avoir ce que je veux.

options timeout:0
options attempts:1

nameserver 10.8.0.1
nameserver 91.121.89.164
nameserver 213.186.33.99

Peut être que j'arriverai à avoir le comportement voulu avec un cache DNS? Ou sinon bah je sortirai l'artillerie lourde (bind9 toussa :/). Un resolver comme celui de MacOSX serait quand mm la meilleure solution pour mon cas.

[ Répondre ]