Thomas Hervé a écrit 139 commentaires

> Bon j'ai une erreur encore:
> [snip]

Il faut que tu vois les droits avec lesquels sont lancés ta commande. Si l'utilisateur oxa-test existe, je pense que c'est avec cet utilisateur. Sinon regarde du côté de la conf "default_privs".

Concernant ton fichier de configuration, je trouve que tu ne fais pas assez la distinction entre les domaines virtuels et les domaines locaux. Ca risque de te poser des soucis plus tard.

> Merci beaucoup pour ton aide !

Ya pas de quoi :)

--
Thomas

Tout est là : http://x.guimard.free.fr/postfix/index.php?page=RESTRICTION_CLASS_R(...) .

Les mots-clés : smtpd_recipient_restrictions, check_sender_access, smtpd_restriction_classes, check_recipient_access.

Il faut noter que cette solution est correcte si tu as une certaine confiance dans tes utilisateurs. Si tu veux faire quelque chose de plus rigide (sécurisé) il faut mettre en place un système d'authentification SMTP.

--
Thomas

Alors, ce qu'il me vient à l'esprit :

- As tu mis "virtual_alias_domains = oxalide.com" dans le main.cf ?
- Un petit coup de "append_at_myorigin=yes" et "append_dot_mydomain=yes" peut-être ? Tu as quoi dans mydestination ?
- Tu essayé de mettre "oxa-test@oxalide.com oxa-test@localhost" dans virtual ?

Sinon je ne crois pas que tu puisses dupliquer les valeurs : seule la derniere est prise en compte, ce qui explique le message qu'il te sort. En extrapolant, on peut donc penser qu'il trouve bien l'utilisateur virtuel, mais pas l'utilisateur local. Essaie donc d'abord d'envoyer à l'utilisateur local (oxatest@localhost).

Tu peux remettre une couche en donnant tout tes fichiers, surtout le main.cf en entier.

J'ai une config qui ressemble un peu à ca sous Apache 1.3.

En gros j'ai ca dans mon httpd.conf :

Listen 195.140.143.44:80
Listen 195.140.143.44:443

NameVirtualHost www.xxx.yyy.zzz:80
NameVirtualHost www.xxx.yyy.zzz:443

<VirtualHost www.xxx.yyy.zzz:443>
SSLEngine on
SSLCertificateFile /etc/apache/certs/server_crt.pem
SSLCertificateKeyFile /etc/apache/certs/server_key.pem.unsecure
</VirtualHost>

Bon après ca dépent pas mal si tu utilises des VirtualHost etc... Surtout que si tu as différents hosts ton certificat ssl n'ira pas pour tous les noms et tu aura un méchant avertissement côté browser.

--
Thomas

Ah là là le syndrome du Not Invented Here... Regarde du côté de Dotclear tu as une barre qui fait exactement ce que tu demandes.

Pour faire ca bien il utilise document.selection ou textarea.getSelectionRange.

Bon courage,

--
Thomas

Un petit test qui résoud certains problèmes : augmente la taille initiale de la ram alouée à la JVM (-Xms128m pour mettre 128MB par exemple).

Au cours de tests d'applis Web sous Tomcat, j'ai utilisé un outil pas mal qui s'appelle Jprobe profiler (ca pue c'est pas libre). Pour constater que les latences de mon application étaient dues aux allocations mémoire. En gros quand la JVM augmente (ou diminue) la mémoire disponible, elle ne peut rien faire d'autre ou quasiment... Sachant qu'une application Java est assez consommatrice de mémoire, j'avais des pauses toutes les 10 secondes.

--
Thomas <et voilà que je me met à donner des conseils Java. Tout fout le camp>

Arrête moi si je me trompe, mais AMD64 c'est du x86. Donc tu peux très bien installer une debian x86 dessus.

Franchement changer le plan de sortie de Sarge déjà chaotique pour ajouter le support d'une architecture.. déjà supportée, je ne vois pas l'intérêt. L'optimisation reste très secondaire.

> Le fond du problème n'est pas là.

Effectivement, le fond du problème c'est que Debian ce sont des bénévoles, avec des exigences fortes en terme de qualité et "d'ouverture". Pour moi ils ne prennent pas de retard : ils ne peuvent pas prendre de retard car ils n'ont aucun calendrier à tenir.

Debian fait son boulot, et le fait bien (quand on voit la quantité de distribs qui utilisent leur système ca doit vouloir dire qqch).

La plupart de ceux qui ralent ici ont une démarche desktop/geek : une distrib doit absolument avoir kde3.4 et apache 2.0.53. Mais ce n'est pas le problème de Debian, ni de beaucoup d'utilisateurs qui ne se font peut-être pas assez entendre. Je n'ai pas X.org, et alors ? J'ai un xfree4.3 qui marche très bien et j'en ai strictement rien à faire de ne pas avoir la dernière version de la mort.

Si vous n'êtes pas content de Debian, ne l'utilisez pas, basta.

[détails vie privée]

OK excuse moi on voit trop souvent des personnes ici qui ne font certainement pas l'effort que tu fais.

Mais en fessant cela j'ai l'impression que le thread n'a pas la main
pour écrire sur le terminal et qu'il l'obtient un cour instant quand
j'appuie sur une touche
Je me demande si le fait que le thread qui lit et le thread qui écoute
peuvent écrire dans le même terminal ne pose pas problème.

C'est possible la gestion des threads est toujours sensible, mais en gros ca devrait fonctionner.
J'ai fait un petit exemple qui fonctionne chez moi (en m'inspirant de ton code):


import os
import thread
import time

def run(cmd):
input, output= os.popen2(cmd)
input.close()
return output

def log(output):
th = thread.start_new_thread(viewlog, (output,))

def viewlog(output):
lin = output.readline()
while lin:
print lin
lin = output.readline()

if __name__ == "__main__":
o = run("top -b")
log(o)
o = run("ping google.fr")
log(o)
while 1:
time.sleep(1)
print "wake"


Après les commande que je lance (ping et top) ne sont peut-être pas un bon exemple, mais ca montre que tu peux arriver à sortir des données depuis différents threads.

Si ton objectif est vraiment un contrôle de daemons, utiliser popen n'est pas le bon choix (il faut mieux utiliser un execv/fork et jouer avec les pids et les signaux). Si tu veux t'inspirer, il y a le module zdaemon de Zope qui fait quelque chose dans ce goût (browse, browse... ah : http://cvs.zope.org/Packages3/zdaemon/Attic/zdaemon.py(...) ).

Bon courage en tout cas.

--
Thomas

A mon avis le problème ne vient pas de ton thread de lecture, mais du programme qui est lancé. Pour pouvoir lire le résultat en continu, il faut que ton programme fasse des "flush" assez régulièrement (ce que ton terminal fait plus ou moins tout seul). Sinon ton readline() ne peut pas retourner (il attend un flush ou un retour à la ligne).

En clair, tout dépend de la commande que tu lances. Peut -être que lire par caractères (avec read(x)) fonctionnera mieux dans ton cas.

--
Thomas

PS : ca serait encore plus plaisant de t'aider si tu faisais un petit effort d'orthographe/grammaire :)

Ping n'est pas un très bon exemple, car il ne réagit pas à la fermeture de stdout.

Par exemple si tu fais :


i, o = os.popen2('top -b')
i.close()
o.readline()
# Tu fais les traitements nécessaires
o.close()


Là tu peux voir que la commande top c'est bien arrêtée. Ce n'est pas très clair comme principe, car ca dépend de la manière dont est gérée les sorties dans ton programme. A noter qu'un os.close(o.fileno()) peut mieux marcher dans certains cas (ne me demande pas pourquoi).

Si tu veux agir plus finement, il te faut le pid : regarde alors du coté du module popen2 sous python2.3 ou subprocess sous python2.4. Avec le pid tu peux envoyer les signaux que tu veux.

--
Thomas

Effectivement je suis arrivé à la même conclusion. Au départ je voulais utiliser bencode parce que c'est simple (presque lisible) et qu'il existe des implémentations dans d'autres langages (au moins ruby, php, java, donc un peu mieux niveau interoperabilité que pickle).

Mais cPickle est judicieux. Reste à voir si ca se marrie bien avec longblob, sinon je ferais du dump en string (relire cette fin de phrase pour rigoler).

--
Thomas

Je pertinente, mais j'ajoute que la méthode module-assistant est elle aussi très propre et très facile.

En tout cas, la copie à la mano du module est à éviter, il y a quand même pleins de méthodes sous debian pour faire mieux. Surtout quand la page pointée parle de ces méthodes :).

--
Thomas

Si tu n'utilises pas d'autres composants sous licence GPL écrit par des tiers

J'ai vu cette histoire de clause d'exception à la licence, mais je ne vois pas pourquoi je ne dois pas utiliser d'autres composants sous GPL.. En tout cas j'en utilise.

Sinon effectivement je suis tenté par recoder la bête, je vais éviter de trop regarder ce qu'ils ont fait. Et puis ca permet d'apprendre certaines choses. L'interêt pour moi était d'utiliser une solution éprouvée, tant pis...

Merci en tout cas pour vos réponses.

--
Thomas

Ca marcherait, mais c'est dommage. Si tu as accès à Python 2.4, le module subprocess et en particulier la classe Popen est un vrai bonheur à utiliser.

Sinon fouille du côté de popen2/popen3, ce que tu demandes est faisable (par exemple si le programme est bien fait si tu fermes stdin il doit s'arrêter).

--
Thomas

Openweb le dit mieux que moi, mais le plus important à respecter pour les balises est la sémantique du contenu.

Exemple : tu dis toi -même que tu pourrais passer les div status en p. La raison de cette modification, c'est si dans status tu n'as que du texte. Il paraît alors raisonnable d'utiliser la balise p.

Autre exemple : si ton menu est dans le style de celui d'openweb, il ya de grandes chances que ce soit une liste. Pourquoi ne pas utiliser la balise ul dans ce cas ?

Un petit dernier pour la route : si Ecran et Panneau ne contiennent que des champs de formulaires, la balise fieldset est ton amie.

Il est intéressant de regarder la liste des balise : http://www.w3.org/TR/html4/index/elements.html.(...) On n'utilise jamais trop de balises différentes.

--
Thomas

Un truc dans le genre doit marcher :

Package: ssh
Pin: release a=testing,c=main,o=Manu,l=Manu
Pin-Priority: 1001

Les astuces : 1001 pour obliger apt à downgrader le paquet, et le pin est determiné par le fichier Release du repository cible.

--
Thomas

La patch Reiser4 est maintenu par Andrew Morton dans la branche MM du kernel. Par contre c'est un patch entier, qui comporte pas mal de changements. Tu peux trouver des patchs individuels (browse... browse... ah : http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.(...) mais il faut savoir lesquels installer...

--
Thomas

L'intérêt c'est le même que d'habitude pour Google : diminuer la taille des pages. J'ai regardé vite fait, on retrouve les mêmes principes que pour Gmail : pas de blancs, taille des variables minimale...

C'est plus du "condensed code" que du "obfuscated code" donc.

--
Thomas

C'est une bonne idée, et ca marche sous gecko... mais pas sous IE. La solution de google marche sur le navigateur de MS (pas aussi bien que sous Firefox d'ailleurs).

Faire des interfaces jolies n'est pas (trop) compliqué, mais Google arrive à faire en plus des interfaces réellement multi-plateformes.

--
Thomas

Ca existe déjà : http://popcon.debian.org/.(...)

Les chiffres se passent de commentaires... Mais je ne suis pas forcément d'accord avec ta conclusion : la loi de la majorité ne doit pas tout gouverner. Par contre il pourrait être logique d'opérer des traitements différents aux paquets installé par 90% des utilisateurs par rapport à ceux installés par 2 ou 3 personnes.

--
Thomas

Je suis personnellement utilisateur de Debian sur Sparc, donc je préférerais que le support soit maintenu mais la décision n'est pas illogique.

Ce que je retiens, c'est que par exemple beaucoup de problèmes viennent des mises à jour kernel, or la plupart des gens qui utilisent Debian sur des archis particulières compilent leur noyau. Ensuite voir que les autres problèmes surgissent par exemple du support gtk+2... Qui utilisent Gnome 2.10 ou KDE 3.4 sur une archi ARM ou MIPS ?

Ma conclusion serait qu'il est peut-être plus logique de faire de release d'un coeur d'applications plus ciblées : une espèce de Debian-server contenant les logiciels les plus répandus. Comme d'autres je pense que maintenir 14 CDs de programmes sans bugs est une gageur inutile. On parle de NetBSD, ils ont bien compris que pour tenir beaucoup d'architectures il etait impossible de maintenir beaucoup de paquets. Avoir l'installateur, un kernel stable et un socle de logiciels seraient parfaits.

Petite aparté, c'est incroyable de voir les réactions que provoque Debian : trolls à tout va, critiques acerbes, jugements baclés... Comme toute distrib, elle a ses défauts, ses avantages : vous aimez vous l'utilisez, vous n'aimez pas vous ne l'utilisez pas, point. L'évangélisation forcée et la descente gratuite sont aussi ridicules.

--
Thomas

Bon déjà je vais raler mais je ne trouve pas ca super propre : la définition de ta liste est repartie entre tout tes utilisateurs au lieu d'être centralisée dans un seul objet (qui contiendrait la liste de tous les membres). Intermède passé.

Sinon pour réaliser ton problème, j'utilserais la table alias_maps avec un fichier ldap, et un filtre de ce type :
query-filter = (&(objectclass=<classe utilisateur>)(mailacceptinggeneralid=%s))
result_attribute = maildrop

Un utilisateur serait alors sous cette forme :
dn: uid=user1,ou=People,dc=exemple,dc=com
mailacceptinggeneralid: listegenerale
mailacceptinggeneralid: user1
maildrop: user1

Si ton problème prend de l'ampleur et que la volumétrie commence à être critique, tu as peut-être intérêt à te tourner vers un logiciel spécialisé comme Sympa.

Bon courage !

--
Thomas

> Voilà mes fichiers de config

et raté, je ne vois rien.

> Mais la réception ne marche pas qui accuser
> Cyrus ou Postfix

Ni l'un ni l'autre : c'est toi le fautif :).

Mais on peut tout de même éssailler de t'aider : donne vraiment les fichiers de configuration (pas tout, un peu de main.cf mais surtout cyrus.conf) ainsi que les fichiers de logs lors d'une tentative d'envoi (mail.log).

A priori si l'envoi marche mais pas la reception, c'est Cyrus qui pose problème ou la communication entre Cyrus et Postfix.

--
Thomas

Venema comme tout bon leader a ses bons et ses mauvais côtés :). Il faut tout de même parti des "BDFL" que je respecte beaucoup.

Concernant la feature, c'est plus une facilité par défaut, parce qu'on pouvait tout de même contourner ce problème (avec les correspondances canoniques par exemple).

A propos des fonctionnalités futures, j'espère beaucoup des avis DSN pour la prochaine branche de développement. Venema le promet depuis longtemps tout en répétant que c'est beaucoup de travail... Ca serait un truc auquel j'aimerais bien participer, mais ce n'est pas évident de rentrer dans le code d'un projet tel que Postfix (même si la quantité de code n'est pas affolante).

--
Thomas

Ah excuse moi je n'ai pas été très clair : ton cas est le numéro un même si le port infrarouge prend un port série.

Il faut un pilote irda compatible pour le faire fonctionner.

--
Thomas