Sendmail fait (à mon goût) un peu partie de l'histoire: peu performant comparativement à ce qui se fait actuellement, sécurité qui laisse à désirer et configuration imbitable.
Non, tout ça c'est fausse rumeurs et compagnies. sendmail est peut-être en dessous des autres niveau performances (c'est pour ca qu'il y a sendmail2 qui est en cours d'élaboration).
Pour la partie sécurité, je demande à voir le "laisser à désirer".
Enfin, la configuration imbittable, évidemment, si tu t'arrêtes à lire le fichier .m4 généré, je comprend que tu ais peur. Mais il y a un fabuleux main.cf clairement lisible, et à la portée de tout le monde, dans lequel on peut configurer tout le m4. Le seul point négatif c'est que la configuration de base est "trop simple", et que passer de cette configuration à une configuration plus élaborée avec ldap/mysql etc. en appoint, bah ça nécessite de lui ajouter des lignes qui ne sont pas dans le fichier de configuration, et il faut plus ou moins les inventer.
Mais un fichier de configuration élaboré, même si complet/complexe, reste tout à fait lisible. C'est de le construire aux petits oignons qui est moins trivial si on n'a pas la documentation adéquate.
Quand je parle de connu, il faut y voir un sous-entendu "intéressant à utiliser actuellement", et désolé de te décevoir, mais sendmail ne fait pas partie de cette liste.
Si. Notamment parce qu'il possède un historique intéressant, et que comme tu dis, il "appartient au passé", un nombre important d'applications l'utilisent de manière avancée. Pour en avoir vu lors de mon stage de l'été dernier, je peux te dire que créer un programme qui se serve de sendmail n'est pas difficile, c'est même plutôt assez simple. Le programme en question était un programme d'appoint qui générait des statistiques. Il possède des avantages qui font que le remplacer sur un serveur n'est pas chose aisée, et comme il remplit très bien son rôle, il n'y a pas à le changer.
sendmail n'est pas seulement là parce que "c'était comme ça avant, on change pas", mais parce qu'il a aussi des qualités. Il faut arrêter de cracher dessus.
Entre autres, et quoi qu'on en dise, il a un avantage certain par rapport aux autres : il est supporté par une entreprise, qui fournit des services. On sait à qui s'adresser quand on a un problème. Tu peux payer pour avoir un support adapté.
Dire que Exim est connu parce que c'est le MTA de debian, c'est un peu réducteur...
C'était voulu aussi, pour créer un effet "phrase choc". Et pourtant, c'est comme ça que j'ai connu exim : à l'installation d'une debian j'ai vu qu'il installait exim par défaut.
Il est aussi connu pour être le MTA le plus utilisé par les spammeurs, grâce à sa facilité de configuration d'ailleurs. Mais ça n'a rien à voir avec des quelconques défauts de conceptions/autres de exim.
Il semblerait que l'utilisation de ce MTA en Angleterre ne soit pas nécessairement liée à Debian. N'étant pas moi-même utilisateur de debian, je me demande alors bien comment j'en ai entendu parler...
N'ayant pas HP-UX chez moi je me demande comment j'en ai entendu parler. Bouche à oreille, etc. Chacun sa petite histoire, moi je l'ai découvert à l'installation d'une debian, d'autres, en cherchant un MTA, d'autres avec la chance.
Et pourtant, si exim est largement implanté sur beaucoup de machines, je pense que Debian y est pour quelque chose.
Amavis n'est pas forcément obligatoire, mais l'est par exemple pour postfix dès que l'on veut faire quelque chose d'un peu évolué... En ce qui concerne les fonctionnalités d'amavis, elles sont toutes utilisables nativement dans exim...
Pourquoi vouloir s'affranchir d'une application tierce ? Si amavis évolue, est-ce que exim évoluera avec ? Difficile à dire. D'où à mon avis un avantage à utiliser amavis de manière séparée et ne pas compter seulement sur les capacités de exim.
Mais bon ça c'est une opinion toute personnelle.
Pour SQL et LDAP, l'intérêt est surtout dans la fléxibilité que l'on peut avoir avec ces recherches.
Tout à fait. De plus, ça permet de s'affranchir du schéma UNIX des comptes.
Un compte mail n'a pas besoin de tout ce qui est rendu disponible avec un compte UNIX. Il a besoin d'un répertoire mail, un login et un mot de passe. LDAP permet de simplifier le schéma et de ne pas toucher à /etc/passwd. En plus, il allège les accès à ce fichier.
SQL pour les mails je n'y ai pas touché, donc je m'abstiendrais de commenter :)
La question n'est pas ici une question de facilité (c'est d'ailleurs par expérience plus "simple" de le faire avec postfix), mais de puissance. Info à part, qmail gère aussi très bien LDAP.
yep. La plupart des MTA gèrent le LDAP, et ils y ont intérêt, justement parce que le LDAP est très utilisé pour la gestion des comptes. Et un MTA qui ne permet pas la gestion de comptes mails via LDAP serait assez vite mis à l'écart pour ce genre de configurations.
Quant à la compatibilité sendmail au niveau ligne de commande, c'est assez anecdotique pour moi, et c'est certainement pas çà qui guiderait le choix d'un MTA :)
C'est un élément parmi d'autres. A considérer si tu as déjà un MTA sous sendmail et que tu veux le mettre à jour, et éventuellement changer le MTA. Parfois tu as justement (cf plus haut) plusieurs applications s'appuyant sur sendmail de façon assez prononcée (avec par exemple les fameuses options passées à sendmail, qui sont, sans documentation, effectivement imbittables). Changer le MTA, ok. Devoir reprogrammer tout l'environnement qui est autour te fait parfois oublier la première idée.
C'est ce qui s'est passé pour moi, et j'ai dû rester sur sendmail dans le dernier cas de configuration. Loin de moi l'idée de dire que cette obligation est valable dans tous les cas. Mais, ça arrive.
Dans tous les cas, Exim peut émuler le fonctionnement de sendmail, comme le fait postfix.
sendmail fait partie de l'histoire, mais on a toujours un /usr/bin/sendmail, sous postfix, exim, etc. Hasard ?
Pour moi, ça prouve une chose : sendmail restera un MTA connu pour longtemps. Il n'y a pas lieu de "l'oublier".
Attention d'ailleurs à mediawiki, il a tendance à demander pas mal de ressources au bout d'un moment (qui a dit usine à gaz ?). Donc je ne le mettrai par exemple pas sur la même machine que, disons, le serveur mail.
Pour le serveur mail, justement, je dirai postfix, pour sa facilité relative d'installation, et capacité d'adaptation. Il monte bien en charge, est bien conçu, et si tu veux passer ensuite à sendmail sans (trop) toucher aux applications annexes, ça peut être un bon choix.
Avec, tu veux tu IMAP, donc courrier-imap, classique...
La configuration d'OpenLDAP n'est pas triviale si on n'a pas de bonnes connaissances au départ, mais ça c'est vrai quelque soit le MTA.
Exim est un des MTA les plus connus avec Postfix et qmail
Non mais t'as un ordre de grandeur un peu... exagéré. Et sendmail dans tout ça ne serait pas un peu en tête du lot ?
Pour info, exim est connu parce qu'il est par défaut sur debian. C'est à mon avis la véritable raison de sa célébrité. Après, ses qualités ont peut-être fait qu'il reste connu, mais pas plus.
qmail est connu parce qu'il n'est pas libre selon les termes de la FSF, et qu'il a voulu renouveller le genre à sa manière.
postfix parce qu'il a voulu renouveller le genre, et y est arrivé. Il est connu pour être plus simple à configurer que sendmail.
Et sendmail, c'est le serveur historique.
----
Pour la suite de fonctionnalités cités comme "killer features", je dirai que :
* amavis n'est pas obligatoire pour certains autres MTA. Et je dirai qu'il y a certains avantages à l'utiliser d'ailleurs... Voir par exemple : http://www.gentoo.org/doc/en/mailfilter-guide.xml(...)
Qui présente amavis d'une manière assez objective.
* pour l'utilisation de SQL et LDAP, tous le font plus ou moins. Maintenant, c'est plus ou moins facile selon les cas. Le cas sendmail est une horreur à traiter si on veut faire les choses bien. Postfix est insuffisamment documenté sur ce point, et quand il y a une documentation, elle est soit incomplète, soit elle ne fonctionne pas. Pour qmail, je ne sais pas.
* pour la robustesse, il a ses qualités, effectivement. Mais ce n'est pas une killer-feature, je dirai plutôt que c'est une raison qui fait qu'il est un bon MTA parmi les autres.
Loin de moi l'envie de vouloir "casser", mais pour choisir un MTA, on ne se base pas toujours sur ce genre de critères. Par exemple, j'ai eu comme critère, une fois : installer un MTA qui puisse être interchangeable avec sendmail au niveau des commandes de base. Bah, je ne sais pas exim, mais postfix le permet (jusqu'à un certain point, tout de même).
Ben si, il t'a été donné juste au dessus, un script shell est *largement* suffisant pour tes besoins. Pourquoi s'obstiner à vouloir une machine à gaz, alors que 5 lignes de shell peuvent venir à bout de ton problème en 2minutes de code et 3 de reflexion ?
Je pense qu'il ne faut pas lire ce document comme un guide d'installation, mais un guide d'appoint pour l'installation. Tu dois donc avoir la documentation officielle, et ce guide, sous les mains.
Et pour cause : les droits sur ce repertoire ont changé "tous seuls".
On dirait que le systeme met automatiquemet les droits d'accès à drwxr-xr-- dans le repertoire /usr.
as quoi cela est il du ? comment faire pour garder mes droits d'accès sur ce repertoire ?
Oui, en fait, dans ton installation de mandrake à un moment, tu as du choisir une politique de sécurité (paranoia, sûre, etc.).
Ce choix se traduit par l'utilisation de démons qui vérifient l'état de ton ordinateur. Notamment, voir si les droits sont bien à leur place comme il faut.
Par exemple, dans /usr, tout programme doit être en 754 (c'est un exemple).
On ne doit pas avoir les droits d'écriture pour tous sur des fichiers dans /home, /usr, etc.
Les droits d'exécution, pareil.
A l'arrivée, là, le démon a vu que tu avais donné trop de permissions à ton programme. Donc, il les a réduites.
Pour pouvoir exécuter ton machin, il faut que ton programme appartienne à root (par exemple) et à un groupe auquel tu appartiens (users ?)
donc un chgrp users tonprog
devrait faire l'affaire, et le démon de sécurité ne devrait pas faire la gueule.
La sortie du programme devient t'elle la sortie du script perl ?
Non. Si tu veux la sortie du programme en question, il te faudra faire un open(FILEHANDLE,"tonexécutiondeprogramme |");
Le prog attent t'il la fin de l'execution du premier programme ou lance t'il tout de suite le second
Ben, il exécutera les programmes dans l'ordre. Mais si tu mets ton programme appelé dans un FILEHANDLE, il sera forké, exécuté, et perl pourra continuer à travailler, tant que tu n'as pas besoin d'accéder à ce FILEHANDLE, pas de soucis. A la première utilisation, il faudra que le programme ait fini (il me semble, à vérifier).
En gros puis-je uttiliser perl plutot qu'un script shell
Bien sûr rien ne t'empêche d'utiliser perl à la place de shell. Mais faut voir l'utilisation, si ton script shell est une suite d'exécution de programmes, je resterai en shell. Passer en perl te donnera plein de system(blabla); c'est laid. Bon, après, ça dépend des exigences et des programmes.
pour lancer plusieurs fois un programme avec des arguments defini par une boucle for Tout en ayant la sortie sur STDOUT ?
Ho ben ça c'est pas un problème, ça se fera tout seul. Les programmes sortiront leur résultat les uns à la suite des autres.
lancera le prog et attendras que le premier se finissent pour remonter dans la boucle ou non ?
oui
Il faut utiliser un compilateur de l'époque, et se mettre dans les conditions de compilation prévue pour que ça ait des chances de marcher. Essaye avec des vieilles versions de compilateur C.
Normalement, tous les vainqueurs ont compilé et ont été exécutés sans problème, donc bon...
Je cite cette dernière RFC : To help prevent confusion between characters that are visually similar, it is suggested that implementations provide visual indications where a domain name contains multiple scripts. Such mechanisms can also be used to show when a name contains a mixture of simplified and traditional Chinese characters, or to distinguish zero and one from O and l. DNS zone adminstrators may impose restrictions (subject to the limitations in section 2) that try to minimize homographs.
Et la partie du blog sur Verisign : Even though we have been asking Verisign registry to implement RFC 3743 (aka JET Guidelines) or to follow ICANN IDN Guidelines (specifically on language tag) for many years, they have not done so, and instead opt to allow any IDN strings to be registered.
lamentable non ?
Surtout que apparemment (toujours sur le même article), la "faille" des IDN est connue depuis... 2002.
Mais non, ne cherche pas un parseur RSS, cherche un parseur XML. Bah oui, le RSS, c'est du XML. Maintenant, un coup de google devrait pouvoir réussir à trouver des bouts de code comme tu les aimes, non ?
Ho, tant que j'en suis dans mes commentaires (voir plus bas). Je ne sais pas si c'est la même chose pour les shuttle et les biostar, mais le heat-pipe des biostar utilise des ventilateurs d'une taille de 60mm, ce qui n'est absolument pas courant. Après, il faut réussir à trouver un remplaçant.
Et si vous souhaitez prendre un 80mm à la place du 60mm, il y aura pas mal de bricolage à faire (découpage de la tour, quelques adaptations à faire, etc.)
J'ai déjà fait du bricolage dans le genre, ce n'est pas forcément ça qui m'arrête, mais disons que maintenant, je préfère clairement ne pas avoir à le faire. Typiquement, pour moi le mac mini est un bon choix, en tout cas, c'est clairement ce que je choisirai pour remplacer mon barebone (qui commence à se faire un peu âgé), si j'en avais les moyens.
J'ose espérer que les iDeq ont fait des progrès niveau ventilos depuis le 200N que j'ai, parce que sinon, très franchement, oublie ça, je n'appelle pas ça du silence, très loin de là. Le mien a près d'un an et demi, et je ne l'allume maintenant *vraiment* quand je dois passer sous linux. Sinon je travaille sur mon ibook.
Etant passé devant un mac mini, j'ai été étonné par le bruit. Enfin, l'absence de bruit.
Un problème à Mac OS X ? Je dirai, le développement perl, y'a des modules qui posent problème, genre ce qui te permet d'accéder à mysql par exemple. C'est quand même vaguement dommage (surtout pour moi qui utilise le perl pour son site :p).
Hmmm... je vais pas en donner 10, mais, au pif, deux que j'utilise régulièrement :
* jedit
* netbeans
Cela dit, voudrais-tu dire par ne concernant pas le développement web que le java est à mettre sur le même point que le... php par exemple, c'est à dire un langage plutôt utilisé pour le wouaib ?
Je veux dire, cite-moi 10 gros projets écrits en php, et ne concernant pas le développement web.
Absurde.
Pourquoi restreindre comme ça ? Pourquoi exclure de facto des gros projets parce que tu ne veux pas qu'on les cite ?
L'utilisation de java n'est pas anecdotique dans la communauté du LL. Simplement, comme tu le proposes, c'est plus souvent utilisé pour des "petits projets". Pour moi, ça n'en fait pas une utilisation anecdotique. Juste un usage différent.
Manque de bindings ? Vu sur freshmeat, on trouve des bindings pour GTK, SDL, OpenGL... Je n'appelle pas ça un manque. Ni des contre-exemples, ou alors, cela sous-entendrait que ces bindings sont "anecdotiques" et "inutiles" ?
Pour C et C++ il est trés simple de tester .. [...]Tu vérifie tes fuites mémoires avec valgrind.
Ahem, attention à ne pas généraliser. Ou alors, je veux bien une version de valgrind pour PPC.
Bon, j'avoue, c'est un cas "particulier", mais quand même. Moi je développe sur PPC, quels sont les outils mis à ma disposition pour tester les fuites mémoire... Bah euuuuh en fait, pas grand chose.
Heureusement, je programme plus en perl qu'autre chose, et donc, les problèmes ne sont pas les mêmes.
Rentrons dans le troll, parce qu'on le vaut bien. Comme dit plus haut, tout ce qui est personnel, je le bacle souvent. Ca marche, très bien, je m'arrête là.
Ce qui l'est moins, en général, je fais plus attention. Notamment, je fais mes tests unitaires, ça ne mange pas de pain. Je commente plus mon code, à tel point qu'il pourrait presque servir de documentation développeur dans certains cas.
Plus concrètement, pour avoir vu du code proprio, et du code libre, j'avoue que la comparaison est très difficile. Le code proprio ne sera pas plus propre qu'un autre hein... Et des exemples, on peut en trouver, pour un peu qu'on ait eu un jour sous la main un bout de proprio.
Non, un test sert à déceler des erreurs. Dans le fonctionnement normal, le code doit fonctionner normalement. Le rôle des tests, c'est d'aller au delà du fonctionnement normal.
Ahem... Autant le post précédent de pbpg me paraissait plein de bon sens, aurant là c'est de la mauvaise foi.
Tu prends la dernière Suse, iso et tout. Bah si t'arrives pas à trouver OOo, KOffice ou Gnumeric dedans, je te propose un occuliste très peu cher.
Tu prends la dernière mouture de Windows, CD et tout. Bah si t'arrives à trouver dedans quelque chose pour ouvrir correctement le .xls, tu m'appelles.
Vu sur un comparatif australien (dont l'accès doit maintenant être payant, il est limité en temps...)
Windows XP was the only operating system that couldn’t recognise and open an imported Excel file — the included office software is very basic so you need to install Microsoft Office or another more advanced program.
Comparatif entre Windows XP SP2, mandrake discovery10.0, Xandros, mac os X, Linspire, et Suse.
C'est un besoin fondamental de lire des .xls pour beaucoup de personnes. Pourquoi le seul à ne pas pouvoir les lire de base, c'est... l'OS de Microsoft ?
Sinon, pour la lecture de video, et écouter de la musique, je me permettrai de dire simplement que la dernière fois que j'ai installé une mandrake (10.1) (par exemple) j'ai rien eu à faire, une fois l'installation du système faite, je pouvais écouter de la musique, et visionner des videos. Je n'ai pas testé les DVD, mais les librairies étaient installée (me semble-t-il), donc ça ne devrait pas poser de problème.
Avec Windows, je te donne un .ogg, et te défie d'arriver à le lire sans installer un logiciel non présent sur les CDs d'installation.
En fait, tout dépend de la législation. Dans mes souvenirs, celle du Japon est proche de celles des US, et il se trouve que ce n'est pas la date d'enregistrement qui est à prendre en compte, mais la date de dépôt de la demande.
Exemple : tu demandes un brevet sur X, à la date t
Tu n'obtiens pas ton brevet, au revoir
Sinon, tu l'obtiens, à t+d. Et alors, le brevet est considéré comme valide à t, et non t+d.
Ce qui fait que parfois, ça pose problème. Mais comme dit plus bas, Apple avait ça en 91... Mais, cf l'article cité :
"Matsushita applied for a patent on the function in 1989. It received one in 1998."
1989 ? Ce serait avant Apple alors ?
En fait, ce que je me demandais, c'est "mais pourquoi il met un timeout, alors qu'il pourrait très bien récupérer son bousin dans un fichier, ce qui évite tout plein de tours de passe passe qui sortent un peu du cadre de flex".
Et puis, j'ai réflechi, et je me suis dit : ha mais si c'est pour un flux, effectivement, ma réflexion n'est pas intelligente. Simplement, hier j'ai oublié de faire part de cette dernière ellucubration de l'esprit, donc c'est fait aujourd'hui.
(sisi, des fois ça me trotte dans la tête pendant quelques jours ces histoires)
Dis moi, t'as pas l'impression de te compliquer la vie pour rien avec l'utilisation de poll() etc. Sachant que tu peux envoyer à yylex() un FILE *, pourquoi ne pas en profiter ?
Sinon, je confirme, flex est un vrai bonheur à utiliser pour ce qui est du parsage de données. Bon, évidemment, ça ne fait pas des miracles et il faut faire attention à ce qu'on écrit, mais on peut faire des choses bien belles :)
C'est bluffant, mais c'est pas forcément utile d'avoir à mettre en place openssi sur toutes ses machines, parce que ça implique un certain nombre de contraintes, tu ne peux plus faire ce que tu veux avec tes machines, le noyau est imposé, la distribution aussi, etc.
Pour son cas, je préconiserai aussi un round robin DNS tout simple. Parfois le plus simple est le mieux en terme d'efficacité.
Pour avoir fait aussi un certain nombre de tests sur openssi, j'avoue que c'est pas trop dur à configurer, pour un peu qu'on a de bonnes bases sur le fonctionnement d'un Linux. Et ça donne de bons résultats.
Au passage, openssi propose une chose qu'openmosix ne propose pas de base : la haute disponibilité. C'est d'ailleurs le point que tu soulèves plus haut, avec le système d'ip virtualisée sur un graphe de machines.
[^] # Re: J'ose espérer que tu rigoles
Posté par iznogoud . En réponse au journal Sortie de Exim 4.50. Évalué à 2.
Sendmail fait (à mon goût) un peu partie de l'histoire: peu performant comparativement à ce qui se fait actuellement, sécurité qui laisse à désirer et configuration imbitable.
Non, tout ça c'est fausse rumeurs et compagnies. sendmail est peut-être en dessous des autres niveau performances (c'est pour ca qu'il y a sendmail2 qui est en cours d'élaboration).
Pour la partie sécurité, je demande à voir le "laisser à désirer".
Enfin, la configuration imbittable, évidemment, si tu t'arrêtes à lire le fichier .m4 généré, je comprend que tu ais peur. Mais il y a un fabuleux main.cf clairement lisible, et à la portée de tout le monde, dans lequel on peut configurer tout le m4. Le seul point négatif c'est que la configuration de base est "trop simple", et que passer de cette configuration à une configuration plus élaborée avec ldap/mysql etc. en appoint, bah ça nécessite de lui ajouter des lignes qui ne sont pas dans le fichier de configuration, et il faut plus ou moins les inventer.
Mais un fichier de configuration élaboré, même si complet/complexe, reste tout à fait lisible. C'est de le construire aux petits oignons qui est moins trivial si on n'a pas la documentation adéquate.
Quand je parle de connu, il faut y voir un sous-entendu "intéressant à utiliser actuellement", et désolé de te décevoir, mais sendmail ne fait pas partie de cette liste.
Si. Notamment parce qu'il possède un historique intéressant, et que comme tu dis, il "appartient au passé", un nombre important d'applications l'utilisent de manière avancée. Pour en avoir vu lors de mon stage de l'été dernier, je peux te dire que créer un programme qui se serve de sendmail n'est pas difficile, c'est même plutôt assez simple. Le programme en question était un programme d'appoint qui générait des statistiques. Il possède des avantages qui font que le remplacer sur un serveur n'est pas chose aisée, et comme il remplit très bien son rôle, il n'y a pas à le changer.
sendmail n'est pas seulement là parce que "c'était comme ça avant, on change pas", mais parce qu'il a aussi des qualités. Il faut arrêter de cracher dessus.
Entre autres, et quoi qu'on en dise, il a un avantage certain par rapport aux autres : il est supporté par une entreprise, qui fournit des services. On sait à qui s'adresser quand on a un problème. Tu peux payer pour avoir un support adapté.
Dire que Exim est connu parce que c'est le MTA de debian, c'est un peu réducteur...
C'était voulu aussi, pour créer un effet "phrase choc". Et pourtant, c'est comme ça que j'ai connu exim : à l'installation d'une debian j'ai vu qu'il installait exim par défaut.
Il est aussi connu pour être le MTA le plus utilisé par les spammeurs, grâce à sa facilité de configuration d'ailleurs. Mais ça n'a rien à voir avec des quelconques défauts de conceptions/autres de exim.
Il semblerait que l'utilisation de ce MTA en Angleterre ne soit pas nécessairement liée à Debian. N'étant pas moi-même utilisateur de debian, je me demande alors bien comment j'en ai entendu parler...
N'ayant pas HP-UX chez moi je me demande comment j'en ai entendu parler. Bouche à oreille, etc. Chacun sa petite histoire, moi je l'ai découvert à l'installation d'une debian, d'autres, en cherchant un MTA, d'autres avec la chance.
Et pourtant, si exim est largement implanté sur beaucoup de machines, je pense que Debian y est pour quelque chose.
Amavis n'est pas forcément obligatoire, mais l'est par exemple pour postfix dès que l'on veut faire quelque chose d'un peu évolué... En ce qui concerne les fonctionnalités d'amavis, elles sont toutes utilisables nativement dans exim...
Pourquoi vouloir s'affranchir d'une application tierce ? Si amavis évolue, est-ce que exim évoluera avec ? Difficile à dire. D'où à mon avis un avantage à utiliser amavis de manière séparée et ne pas compter seulement sur les capacités de exim.
Mais bon ça c'est une opinion toute personnelle.
Pour SQL et LDAP, l'intérêt est surtout dans la fléxibilité que l'on peut avoir avec ces recherches.
Tout à fait. De plus, ça permet de s'affranchir du schéma UNIX des comptes.
Un compte mail n'a pas besoin de tout ce qui est rendu disponible avec un compte UNIX. Il a besoin d'un répertoire mail, un login et un mot de passe. LDAP permet de simplifier le schéma et de ne pas toucher à /etc/passwd. En plus, il allège les accès à ce fichier.
SQL pour les mails je n'y ai pas touché, donc je m'abstiendrais de commenter :)
La question n'est pas ici une question de facilité (c'est d'ailleurs par expérience plus "simple" de le faire avec postfix), mais de puissance. Info à part, qmail gère aussi très bien LDAP.
yep. La plupart des MTA gèrent le LDAP, et ils y ont intérêt, justement parce que le LDAP est très utilisé pour la gestion des comptes. Et un MTA qui ne permet pas la gestion de comptes mails via LDAP serait assez vite mis à l'écart pour ce genre de configurations.
Quant à la compatibilité sendmail au niveau ligne de commande, c'est assez anecdotique pour moi, et c'est certainement pas çà qui guiderait le choix d'un MTA :)
C'est un élément parmi d'autres. A considérer si tu as déjà un MTA sous sendmail et que tu veux le mettre à jour, et éventuellement changer le MTA. Parfois tu as justement (cf plus haut) plusieurs applications s'appuyant sur sendmail de façon assez prononcée (avec par exemple les fameuses options passées à sendmail, qui sont, sans documentation, effectivement imbittables). Changer le MTA, ok. Devoir reprogrammer tout l'environnement qui est autour te fait parfois oublier la première idée.
C'est ce qui s'est passé pour moi, et j'ai dû rester sur sendmail dans le dernier cas de configuration. Loin de moi l'idée de dire que cette obligation est valable dans tous les cas. Mais, ça arrive.
Dans tous les cas, Exim peut émuler le fonctionnement de sendmail, comme le fait postfix.
sendmail fait partie de l'histoire, mais on a toujours un /usr/bin/sendmail, sous postfix, exim, etc. Hasard ?
Pour moi, ça prouve une chose : sendmail restera un MTA connu pour longtemps. Il n'y a pas lieu de "l'oublier".
[^] # Re: Pour le wiki
Posté par iznogoud . En réponse au journal Mise en place d'un serveur privé qui.... Évalué à 2.
Pour le serveur mail, justement, je dirai postfix, pour sa facilité relative d'installation, et capacité d'adaptation. Il monte bien en charge, est bien conçu, et si tu veux passer ensuite à sendmail sans (trop) toucher aux applications annexes, ça peut être un bon choix.
Avec, tu veux tu IMAP, donc courrier-imap, classique...
La configuration d'OpenLDAP n'est pas triviale si on n'a pas de bonnes connaissances au départ, mais ça c'est vrai quelque soit le MTA.
Pour le serveur jabber, j'y connais rien.
[^] # Re: [Mode Mechant ON ] Un jeu limite ?
Posté par iznogoud . En réponse au journal coup de coeur. Évalué à 3.
# J'ose espérer que tu rigoles
Posté par iznogoud . En réponse au journal Sortie de Exim 4.50. Évalué à 2.
Non mais t'as un ordre de grandeur un peu... exagéré. Et sendmail dans tout ça ne serait pas un peu en tête du lot ?
Pour info, exim est connu parce qu'il est par défaut sur debian. C'est à mon avis la véritable raison de sa célébrité. Après, ses qualités ont peut-être fait qu'il reste connu, mais pas plus.
qmail est connu parce qu'il n'est pas libre selon les termes de la FSF, et qu'il a voulu renouveller le genre à sa manière.
postfix parce qu'il a voulu renouveller le genre, et y est arrivé. Il est connu pour être plus simple à configurer que sendmail.
Et sendmail, c'est le serveur historique.
----
Pour la suite de fonctionnalités cités comme "killer features", je dirai que :
* amavis n'est pas obligatoire pour certains autres MTA. Et je dirai qu'il y a certains avantages à l'utiliser d'ailleurs... Voir par exemple :
http://www.gentoo.org/doc/en/mailfilter-guide.xml(...)
Qui présente amavis d'une manière assez objective.
* pour l'utilisation de SQL et LDAP, tous le font plus ou moins. Maintenant, c'est plus ou moins facile selon les cas. Le cas sendmail est une horreur à traiter si on veut faire les choses bien. Postfix est insuffisamment documenté sur ce point, et quand il y a une documentation, elle est soit incomplète, soit elle ne fonctionne pas. Pour qmail, je ne sais pas.
* pour la robustesse, il a ses qualités, effectivement. Mais ce n'est pas une killer-feature, je dirai plutôt que c'est une raison qui fait qu'il est un bon MTA parmi les autres.
Loin de moi l'envie de vouloir "casser", mais pour choisir un MTA, on ne se base pas toujours sur ce genre de critères. Par exemple, j'ai eu comme critère, une fois : installer un MTA qui puisse être interchangeable avec sendmail au niveau des commandes de base. Bah, je ne sais pas exim, mais postfix le permet (jusqu'à un certain point, tout de même).
[^] # Re: bourin et moins bourin
Posté par iznogoud . En réponse au message cherche des mailbomber pour test. Évalué à 2.
[^] # pas d'accord
Posté par iznogoud . En réponse au journal Gentoo Linux sur un iBook G4. Évalué à 1.
# démon de sécurité
Posté par iznogoud . En réponse au message droits d'accès sur /usr. Évalué à 1.
On dirait que le systeme met automatiquemet les droits d'accès à drwxr-xr-- dans le repertoire /usr.
as quoi cela est il du ? comment faire pour garder mes droits d'accès sur ce repertoire ?
Oui, en fait, dans ton installation de mandrake à un moment, tu as du choisir une politique de sécurité (paranoia, sûre, etc.).
Ce choix se traduit par l'utilisation de démons qui vérifient l'état de ton ordinateur. Notamment, voir si les droits sont bien à leur place comme il faut.
Par exemple, dans /usr, tout programme doit être en 754 (c'est un exemple).
On ne doit pas avoir les droits d'écriture pour tous sur des fichiers dans /home, /usr, etc.
Les droits d'exécution, pareil.
A l'arrivée, là, le démon a vu que tu avais donné trop de permissions à ton programme. Donc, il les a réduites.
Pour pouvoir exécuter ton machin, il faut que ton programme appartienne à root (par exemple) et à un groupe auquel tu appartiens (users ?)
donc un chgrp users tonprog
devrait faire l'affaire, et le démon de sécurité ne devrait pas faire la gueule.
# oui et non
Posté par iznogoud . En réponse au message Lancer un programme depuis perl et sortie. Évalué à 1.
Non. Si tu veux la sortie du programme en question, il te faudra faire un open(FILEHANDLE,"tonexécutiondeprogramme |");
Le prog attent t'il la fin de l'execution du premier programme ou lance t'il tout de suite le second
Ben, il exécutera les programmes dans l'ordre. Mais si tu mets ton programme appelé dans un FILEHANDLE, il sera forké, exécuté, et perl pourra continuer à travailler, tant que tu n'as pas besoin d'accéder à ce FILEHANDLE, pas de soucis. A la première utilisation, il faudra que le programme ait fini (il me semble, à vérifier).
En gros puis-je uttiliser perl plutot qu'un script shell
Bien sûr rien ne t'empêche d'utiliser perl à la place de shell. Mais faut voir l'utilisation, si ton script shell est une suite d'exécution de programmes, je resterai en shell. Passer en perl te donnera plein de system(blabla); c'est laid. Bon, après, ça dépend des exigences et des programmes.
pour lancer plusieurs fois un programme avec des arguments defini par une boucle for Tout en ayant la sortie sur STDOUT ?
Ho ben ça c'est pas un problème, ça se fera tout seul. Les programmes sortiront leur résultat les uns à la suite des autres.
lancera le prog et attendras que le premier se finissent pour remonter dans la boucle ou non ?
oui
Merci
de rien.
# man logger
Posté par iznogoud . En réponse au message Logguer dans Syslog. Évalué à 3.
[^] # Re: La poésie
Posté par iznogoud . En réponse au journal Pour les amoureux du C. Évalué à 2.
Normalement, tous les vainqueurs ont compilé et ont été exécutés sans problème, donc bon...
[^] # Re: Tous sauf IE...
Posté par iznogoud . En réponse au journal 01info, mon amour. Évalué à 8.
à propos de la RFC3743 sur les IDN :
http://james.seng.cc/archives/000347.html(...)
à propos de Verisign (encore eux) qui refusent de respecter la RFC3490 :
http://james.seng.cc/archives/2005/02/08/idn_and_homographs_spoofin(...)
Je cite cette dernière RFC :
To help prevent confusion between characters that are visually similar, it is suggested that implementations provide visual indications where a domain name contains multiple scripts. Such mechanisms can also be used to show when a name contains a mixture of simplified and traditional Chinese characters, or to distinguish zero and one from O and l. DNS zone adminstrators may impose restrictions (subject to the limitations in section 2) that try to minimize homographs.
Et la partie du blog sur Verisign :
Even though we have been asking Verisign registry to implement RFC 3743 (aka JET Guidelines) or to follow ICANN IDN Guidelines (specifically on language tag) for many years, they have not done so, and instead opt to allow any IDN strings to be registered.
lamentable non ?
Surtout que apparemment (toujours sur le même article), la "faille" des IDN est connue depuis... 2002.
# RSS ? xml !
Posté par iznogoud . En réponse au message Parser RSS. Évalué à 1.
[^] # Re: nogroup
Posté par iznogoud . En réponse au message chown: `nobody.nobody': invalid group ?!. Évalué à 1.
chown nobody:nogroup
et non
chown nobody.nogroup
[^] # Re: Heatpipe = HeatEntubageCommercial
Posté par iznogoud . En réponse au journal MacMini ou pas ?. Évalué à 2.
Et si vous souhaitez prendre un 80mm à la place du 60mm, il y aura pas mal de bricolage à faire (découpage de la tour, quelques adaptations à faire, etc.)
J'ai déjà fait du bricolage dans le genre, ce n'est pas forcément ça qui m'arrête, mais disons que maintenant, je préfère clairement ne pas avoir à le faire. Typiquement, pour moi le mac mini est un bon choix, en tout cas, c'est clairement ce que je choisirai pour remplacer mon barebone (qui commence à se faire un peu âgé), si j'en avais les moyens.
[^] # Re: Ca dépend de l'OS
Posté par iznogoud . En réponse au journal MacMini ou pas ?. Évalué à 2.
Etant passé devant un mac mini, j'ai été étonné par le bruit. Enfin, l'absence de bruit.
Un problème à Mac OS X ? Je dirai, le développement perl, y'a des modules qui posent problème, genre ce qui te permet d'accéder à mysql par exemple. C'est quand même vaguement dommage (surtout pour moi qui utilise le perl pour son site :p).
[^] # Re: test unitaire en C:C++ et autre
Posté par iznogoud . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 2.
configure: error: Valgrind is operating system specific. Sorry. Please consider doing a port.
Je veux bien faire un port, mais bon, comment dire, faudrait m'allonger mes journées de quelques heures/jour sinon je pourrai pas trouver le temps.
Cela dit, je le garde dans un coin pour le jour où j'utiliserai mon Linux sur ppc :)
[^] # Re: Droit de réponse
Posté par iznogoud . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 2.
* jedit
* netbeans
Cela dit, voudrais-tu dire par ne concernant pas le développement web que le java est à mettre sur le même point que le... php par exemple, c'est à dire un langage plutôt utilisé pour le wouaib ?
Je veux dire, cite-moi 10 gros projets écrits en php, et ne concernant pas le développement web.
Absurde.
Pourquoi restreindre comme ça ? Pourquoi exclure de facto des gros projets parce que tu ne veux pas qu'on les cite ?
L'utilisation de java n'est pas anecdotique dans la communauté du LL. Simplement, comme tu le proposes, c'est plus souvent utilisé pour des "petits projets". Pour moi, ça n'en fait pas une utilisation anecdotique. Juste un usage différent.
Manque de bindings ? Vu sur freshmeat, on trouve des bindings pour GTK, SDL, OpenGL... Je n'appelle pas ça un manque. Ni des contre-exemples, ou alors, cela sous-entendrait que ces bindings sont "anecdotiques" et "inutiles" ?
[^] # Re: test unitaire en C:C++ et autre
Posté par iznogoud . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 1.
Pour C et C++ il est trés simple de tester .. [...]Tu vérifie tes fuites mémoires avec valgrind.
Ahem, attention à ne pas généraliser. Ou alors, je veux bien une version de valgrind pour PPC.
Bon, j'avoue, c'est un cas "particulier", mais quand même. Moi je développe sur PPC, quels sont les outils mis à ma disposition pour tester les fuites mémoire... Bah euuuuh en fait, pas grand chose.
Heureusement, je programme plus en perl qu'autre chose, et donc, les problèmes ne sont pas les mêmes.
Rentrons dans le troll, parce qu'on le vaut bien. Comme dit plus haut, tout ce qui est personnel, je le bacle souvent. Ca marche, très bien, je m'arrête là.
Ce qui l'est moins, en général, je fais plus attention. Notamment, je fais mes tests unitaires, ça ne mange pas de pain. Je commente plus mon code, à tel point qu'il pourrait presque servir de documentation développeur dans certains cas.
Plus concrètement, pour avoir vu du code proprio, et du code libre, j'avoue que la comparaison est très difficile. Le code proprio ne sera pas plus propre qu'un autre hein... Et des exemples, on peut en trouver, pour un peu qu'on ait eu un jour sous la main un bout de proprio.
[^] # Re: pas une preuve
Posté par iznogoud . En réponse au journal couverture de code. Évalué à 2.
[^] # Re: sont gonflés quand meme sur PCInpact...
Posté par iznogoud . En réponse au journal PC portable à prix cassé pour les pays en voie de développement. Évalué à 1.
Tu prends la dernière Suse, iso et tout. Bah si t'arrives pas à trouver OOo, KOffice ou Gnumeric dedans, je te propose un occuliste très peu cher.
Tu prends la dernière mouture de Windows, CD et tout. Bah si t'arrives à trouver dedans quelque chose pour ouvrir correctement le .xls, tu m'appelles.
[^] # Re: sont gonflés quand meme sur PCInpact...
Posté par iznogoud . En réponse au journal PC portable à prix cassé pour les pays en voie de développement. Évalué à 2.
Windows XP was the only operating system that couldn’t recognise and open an imported Excel file — the included office software is very basic so you need to install Microsoft Office or another more advanced program.
Comparatif entre Windows XP SP2, mandrake discovery10.0, Xandros, mac os X, Linspire, et Suse.
C'est un besoin fondamental de lire des .xls pour beaucoup de personnes. Pourquoi le seul à ne pas pouvoir les lire de base, c'est... l'OS de Microsoft ?
Sinon, pour la lecture de video, et écouter de la musique, je me permettrai de dire simplement que la dernière fois que j'ai installé une mandrake (10.1) (par exemple) j'ai rien eu à faire, une fois l'installation du système faite, je pouvais écouter de la musique, et visionner des videos. Je n'ai pas testé les DVD, mais les librairies étaient installée (me semble-t-il), donc ça ne devrait pas poser de problème.
Avec Windows, je te donne un .ogg, et te défie d'arriver à le lire sans installer un logiciel non présent sur les CDs d'installation.
[^] # Re: No.2803236
Posté par iznogoud . En réponse au journal Les brevets: exemple Japonais. Évalué à 2.
Exemple : tu demandes un brevet sur X, à la date t
Tu n'obtiens pas ton brevet, au revoir
Sinon, tu l'obtiens, à t+d. Et alors, le brevet est considéré comme valide à t, et non t+d.
Ce qui fait que parfois, ça pose problème. Mais comme dit plus bas, Apple avait ça en 91... Mais, cf l'article cité :
"Matsushita applied for a patent on the function in 1989. It received one in 1998."
1989 ? Ce serait avant Apple alors ?
[^] # Re: Euuuuuh...
Posté par iznogoud . En réponse au journal Flex mon ami !. Évalué à 1.
Et puis, j'ai réflechi, et je me suis dit : ha mais si c'est pour un flux, effectivement, ma réflexion n'est pas intelligente. Simplement, hier j'ai oublié de faire part de cette dernière ellucubration de l'esprit, donc c'est fait aujourd'hui.
(sisi, des fois ça me trotte dans la tête pendant quelques jours ces histoires)
# Euuuuuh...
Posté par iznogoud . En réponse au journal Flex mon ami !. Évalué à 1.
Sinon, je confirme, flex est un vrai bonheur à utiliser pour ce qui est du parsage de données. Bon, évidemment, ça ne fait pas des miracles et il faut faire attention à ce qu'on écrit, mais on peut faire des choses bien belles :)
[^] # Re: OpenSSI
Posté par iznogoud . En réponse au message Comment faire du clustering ?. Évalué à 2.
Pour son cas, je préconiserai aussi un round robin DNS tout simple. Parfois le plus simple est le mieux en terme d'efficacité.
Pour avoir fait aussi un certain nombre de tests sur openssi, j'avoue que c'est pas trop dur à configurer, pour un peu qu'on a de bonnes bases sur le fonctionnement d'un Linux. Et ça donne de bons résultats.
Au passage, openssi propose une chose qu'openmosix ne propose pas de base : la haute disponibilité. C'est d'ailleurs le point que tu soulèves plus haut, avec le système d'ip virtualisée sur un graphe de machines.