J'ai matté la doc plus en profondeur, et surtout j'ai trouvé des exemples sur le net... je vais surement essayer de faire un compromis avec mon collegue.. pas de bloquage pour les RBL, mais les utiliser dans SA.
Pour info, voici comment ajouter une RBL dans SpamAssassin:
header IN_NJABL_ORG rbleval:check_rbl('njabl','dnsbl.njabl.org.')
describe IN_NJABL_ORG Received via a relay in dnsbl.njabl.org tflags IN_NJABL_ORG net
header NJABL_OPEN_RELAY rbleval:check_rbl_results_for('njabl', '127.0.0.2') describe NJABL_OPEN_RELAY DNSBL: sender is Confirmed Open Relay tflags NJABL_OPEN_RELAY net
header NJABL_DUL rbleval:check_rbl_results_for('njabl', '127.0.0.3') describe NJABL_DUL DNSBL: sender ip address in in a dialup block tflags NJABL_DUL net
header NJABL_SPAM_SRC rbleval:check_rbl_results_for('njabl', '127.0.0.4') describe NJABL_SPAM_SRC DNSBL: sender is Confirmed Spam Source tflags NJABL_SPAM_SRC net
header NJABL_MULTI_STAGE rbleval:check_rbl_results_for('njabl', '127.0.0.5') describe NJABL_MULTI_STAGE DNSBL: sent through multi-stage open relay tflags NJABL_MULTI_STAGE net
header NJABL_CGI rbleval:check_rbl_results_for('njabl', '127.0.0.8')
describe NJABL_CGI DNSBL: sender is an open formmail tflags NJABL_CGI net
header NJABL_PROXY rbleval:check_rbl_results_for('njabl', '127.0.0.9') describe NJABL_PROXY DNSBL: sender is an open proxy tflags NJABL_PROXY net
Pour CRM114, j'ai modifier amavis pour que celui-ci passe le mail a un wrapper pour CRM114 qui retourne un score du type de ceux de SA....
Pour le grey listing, je ne pense pas que cela puisse s'appliquer chez nous:
- au final on aura environ 40 000 comptes mails, donc je suppose plusieurs centaines de milliers de mails par jours.. je ne crois pas que refuser le mail une premiere fois soit une bonne option.
- nous partons avec 3 MX de poids egal, un mail qui est d'abord refusé (par le grey listing) sur un MX ne sera pas forcement renvoyé sur le meme.. . à moins d'avoir un spool commun.
Je n'ai pas vraiment envisagé cette solution, en fait.. peut être l'ai-je éliminée trop tot... si qq'un l'a mise en oeuvre sur une structure équivalente, je suis preneur de feedback.
C'est sur que toutes les RBLs ne sont pas dignes de confiance!
Certaines RBL se contentent de quelques mails de spam envoyé d'un domaine pour justifier le blacklistage de tout le domaine (dans ce cas, byebye hotmail, caramail, wanadoo, etc)
Certaines, au contraire, se basent sur l'open-relay. Dans ce cas, les machines sont testés avant d'etre blacklistées.
Il y a aussi le pire, comme osirusoft a oser le faire: Mettre la clé sous la porte apres faillite ou après en avoir eu marre des procès de spammeurs mécontant d'être blacklisté et pour que les utilisateurs pensent a virer leur RBL de leur config, ben osirusoft a eu la bonne idée de toujours envoyer une réponse positive aux requètes.
Résultat: tous les serveurs de mails du monde étaient blacklistés!
Perso, je suis pour l'utilisation minimale des RBL, n'en prendre que qq unes spécialisées et dignes de confiance.. atuellement je n'utilise que
relays.ordb.org (open relay), dnsbl.njabl.org (open relay, listes d'ip dynamiques), et korea.services.net (specialisé dans le spam asiatique)
mynetworks = /etc/postfix/reseaux
smtpd_client_restrictions = permit_mynetworks, reject_rbl_client ...
ah.. ben c'est comme ca que l'on fait.. le probleme des rbl pas joignables en cas de coupure réseau n'est pas mon argument mais celui de mon collegue anti-RBL.. j'ai jamais eu ce problème la personnellement.. j'ai pas vérifié la config de leur serveur de mail.
Concretement, on aura postfix (peut etre avec spf via postfix-policyd) amavis avec SpamAssassin et peut-etre CRM114 qui sera alimenté par les admins (CRM114 qui est actuellement en test, est largement plus performant que les filtres bayesiens que nous avons testé) le score de CRM114 donnera un score à amavis, qui sera ajouté au score de Spamassassin pour le calcul du score final, cela permet de minorer/majorer SpamAssassin.
Nous avons aussi testé avec le filtre bayesien de SA, mais cela ne nous convenait pas...il faut lui apprendre les bons et les mauvais mails, or les mails que recoit un admin ne sont pas forcement représentatifs des mails recu par un chercheur ou un étudiant.
Avec CRM114, c'est bcp plus simple.. tu ne lui donnes que des corrections: t'as un faux-positif, alors tu lui dis "tu t'es trompé, c'est pas un spam", si t'as un faux-negatif, alors tu lui dis "en fait, ca c'est un spam", on peut alors l'éduquer au cas par cas via une interface que l'on est en train de développer (on envoie un mail a une adresse donnée, si le mail est un spam, alors CRM114 l'apprend comme faux-positif et vis-versa). Avec une 10aine de corrections, CRM114 donne déja de très bons résultats ce qui permettra aux admins de maintenir un bon niveau de reconnaissance.
Tu rajoute une règle avant RBL qui laisse passer les mails internes.
Tu fais ca comment avec postfix? les rbls ne sont pas locales.. je ne gère pas leur contenu.
Personnelement, je recois plus de virus que de vrai spams.
Exactement, c'est la nouvelle tendance.. de plus en plus de virus servent à envoyer du spam et contre cela, les rbls antirelay sont inutiles.. C'est pour cela que j'utilise aussi un antispam classique derriere
Pour bogofilter, même raison que pour dspam, je ne veux/peux pas utiliser procmail vu que cela se passe sur un serveur relai.
De plus, avec plusieurs milliers d'utilisateurs, je ne peux pas me premettre d'utiliser un flitre bayesien (je veux pas qu'un utilisateur décide qu'un mail de pub quelconque est un spam et qu'un autre décide que cela n'en est pas un)
l'avantage d'amavis, c'est que cela sert d'interface postfix/antivirus aussi... de plus j'ai developper une interface CRM114/amavis qui permet d'utiliser CRM114 en plus de Spamassassin.
De plus, les serveurs frontaux (les MX) n'ont aucun compte linux, si ce n'ai root, tout les comptes mail sont ldap et ne sont pas des comptes shell. Je crois que pour dspam, il faut utiliser procmail.. pas de comptes shell, pas de procmail (procmail etant assez gourmand, pour gerer 40 000 comptes, ca fait un peu peur)
Dspam n'est pas une alternative à amavis (qui utilise l'API perl de SpamAssassin et fait l'interface postfix/anvirus) mais plutot un remplacant de spamd dans une architecture spamc/spamd (et donc avec procmail, encore)
Pour ce qui est de DCC et Razor2, il y a eu un temps ou j'utilisais ca.. le probleme etant que cela ralenti enormement le traitement du mails.. d'apres les timings d'amavis: 200ms avec les RBL mais sans DCC ni Razor, 1s avec les rbls et Razor et 1600ms avec RBL, DCC et Razor...
J'avais des problèmes avec Razor, certains mail de mailing lists etaient répertoriés sur les serveurs de Razor.. y compris des ML de la nasa... les chercheurs n'ont pas trop aimé.
Pour DCC, le problème est un peu le même.. certains mail en provenance de ml très répandue sont scoré sur DCC..
On a l'impression que la résponsabilité de l'interet du site revient exclusivement aux utilisateurs. Si ils veulent un site interessant, qu'ils proposent des news interessantes qui plaisent aux moderos.
On dirait que l'equipe de linuxfr dégage toute résponsabilité en cas de désaffectation du site. Les modéros ne sont la uniquement pour relire les news proposées et ne peuvent, eux, proposer des news. Chacun sa résponsabilité. je sais que cela n'est pas exactement le cas, mais c'est quand même l'impression qui se dégage du système.
Par exemple, je sais qu'il y a ici bcp de lecteurs de osnews. Qu'est ce qui fait l'interet de ce site? le nombre de news, du au fait que Eugenia poste bcp de news elle même, elle fait vivre Osnews et je suppose qu'elle se sent résponsable du succès de son site.
C'est peut être ca qu'il manque à linuxfr: une équipe de "journalistes" qui serait affiliés à linuxfr, au même titre que les relecteurs et les moderos, dont le "boulot" serait de proposer des news. Mais celles-ci serait validées tout de suite, sachant qu'ils seraient garant du bien fondé de ces dépèche sur linuxfr alors que les news proposées par les visiteurs passeraient par le chemin actuel: relecture, moderation, publication ou refus.
Tu veux démontrer quoi?
Que gdesklet est buggé? la, je suis d'accord, d'après la trace que tu donnes, il manque une lib python, le mec a probablement installé gdesklet a partir du source, le source n'ayant meme pas pris soin de vérifer que tous les modules python etaient bien installés.
De toute facon il n'y a pas de package gdesket dans la fedora. Il existe bien des RPMS tiers noatemment ceux de Dag Wieers qui marchent très bien:
tu peux aussi noter que dans les dépendances du rpm gdesklet on a:
python >= 2.2, gnome-python2 >= 1.99.17, gnome-python2-gconf >= 2.0
Sinon je suis bien d'accord avec la majorité, la FC1 etait vraiment branlante quand elle est sortie, ca a été résolu rapidement, mais elle est jeune, trop jeune probablement. c'est pas Redhat, mais bon, faut lui laisser du temps, perso je participe activement à son developpement, c'est comme ca qu'on fait bouger les choses.
pourquoi (je sais, toujours cette meme question) utiliser apt-get avec la fedora quand elle fournit yum, outil faisant la même chose mais en mieux et développé nativement pour les rpm.
yum install
yum groupinstall "Gnome Desktop Enviromment" (ou un yum grouplist pour la liste des groupes dispo)
il y a énormement de repositories yum (mozilla.org en a un officiel, ximian aussi, tous les mirroirs fedora sont des repository yum, etc), faire un repository yum c'est une seule commande à taper sans parametre particulier, vraiment très simple.
Pour ce qui est des problèmes avec la FC1, il est vrai qu'elle etait buggée, mais les bug fix sont arrivés très vite.
Je conseille d'ailleurs d'utiliser l'applet rhn qui n'a plus besoin d'inscription chez redhat et qui est désormais compatible avec les repositories yum et apt (conf dans /etc/sysconfig/rhn/sources). Elle vous permet de maintenir à jour votre système sans trop vous fouler.
Je vois pas pourquoi migrer... avant vous vouliez du pas cher en provenance de chez RH, avec des updates gratuite en provenance de chez RH.
Maintenent vous pouvez garder vos RH pas cheres et utiliser les updates gratuites du projet Fedora Legacy (qui a pour but de proposer les updates des RH de la 6.2 a la 8 apres leur fin de vie) ou d'un autre projet identique. C'est pas la mort.
Ca fait quand meme la 3ieme news sur le sujet... pourquoi un tel tolé? Suse et Mdk aussi passent leur vieilles releases à la trappe, non? et pour ces distrib, je suis pas sur qu'on puisse encore trouver des updates.. meme payantes.
Si tu as plusieurs sections ayant le même nom (par exemple dans mon yum.conf ci-dessus, 2 [base] et 2 [updates]) yum utilisera le second si le premier ne repond pas.
Pour ne pas avoir à vérifier les headers sur les serveurs avant toute operation: yum -C
C'est censé être un test, mais le gars installe apt-get plutot que d'utiliser (et tester à la même occasion) yum, l'outil équivalent qui est inclu dans la distribution. Je trouve ca d'autant plus nul que yum offre des fonctionnalités que apt-get ne propose pas (gestion des groupes d'installation, yum grouplist pour avoir une idée).
Pour ceux que cela interesse, mon yum.conf bien fourni:
La meilleure solution est de migrer vers une autre distrib??
Probablement pas, de très nombreuses personne sur la ml fedora-dev ont exprimé leur envie de s'occuper de gérer les erratas et security updates pour les distrib en bout de vie de RH.
Cela va même jusqu'a la 6.2!
Je pense que c'est simplement le service « up2date » qui ne sera plus gratuit...
Erreur, up2date été repris par les gens de chez Redhat qui participe à Fedora et modifié:
- Il n'a plus besoin d'inscription à RHN
- Il supporte les repository apt
- Il supporte les repository yum
Même l'applet rhn a été modifiée pour fonctionner sans rhn et utiliser les repos yum et apt.
De plus, une bonne partie des gens de RedHat (Cox, Veillard, Nottingam, etc) participe au developpement de Fedora.
Vu qu'ils bossent aussi pour la RHEL, il porteront les erratas sur Fedora dès leur applications à RHEL.
Mettez un Fan de RedHat ou Mandrake devant apt-get et on en reparle ( troll ???? ou réalité !)
Quand tu veux...
Fedora utilise yum qui est un equivalent de apt en python, avec un système un peu plus avancé de gestion des rpms. (Possibiliter de faire des install groupées sans utilisation de meta packages, gestion des signatures des packages, les repositories sont très simples à mettre en place)
Je pense que RedHat et Mandrake avancent à peu près dans la même direction.
C'est à dire que d'un côté, il y a Fedora et de l'autre cooker.
Pas exactement, Il y a toujours eu Rawhide chez RedHat qui est exactement l'equivalent de Cooker.
Fedora c'est encore autre chose, la mise à disposition de RedHat Linux à la communauté ( c'est pas encore tout a fait vrai vu que les serveurs de soumission de RPM tiers ne sont pas encore en service, il manque aussi pas mal de guidelines). Fedora permettra a tout un chacun de proposer d'inclure ses propres rpms dans ce qui etait RedHat Linux.
Je crois que l'analogie avec Debian s'arrete(ra) au fonctionnement communautaire. Le but de Fedora c'est de permettre a RedHat d'avoir une distribution de base pour ses RedHat Linux Enterprises qui aient été testées et approuvées sans que RH s'investisse commercialement dedans.
Pour l'instant, je pense que la seule chose a faire c'est wait and see... ou mieux: Test, Report, Wait and See.
A propos de kde et de kde-redhat.sf.net voici la reponse de Havoc Pennington (Redhat/Fedora) sur fedora-devel-list@redhat.com:
"kde-redhat.sf.net would be welcome to either hack on the KDE packages in
Fedora Core or offer their own alternate KDE packages in Fedora
Alternatives, if they're interested. Of course first we have to get the
infrastructure set up."
Donc c'est plutot positif, et il y a des chances que tu auras un packaging propre pour ta redhat.
[^] # Re: RBLs dans Spamassassin
Posté par ArnY (site web personnel) . En réponse au journal Pour ou Contre les RBL?. Évalué à 3.
Pour info, voici comment ajouter une RBL dans SpamAssassin:
header IN_NJABL_ORG rbleval:check_rbl('njabl','dnsbl.njabl.org.')
describe IN_NJABL_ORG Received via a relay in dnsbl.njabl.org tflags IN_NJABL_ORG net
header NJABL_OPEN_RELAY rbleval:check_rbl_results_for('njabl', '127.0.0.2') describe NJABL_OPEN_RELAY DNSBL: sender is Confirmed Open Relay tflags NJABL_OPEN_RELAY net
header NJABL_DUL rbleval:check_rbl_results_for('njabl', '127.0.0.3') describe NJABL_DUL DNSBL: sender ip address in in a dialup block tflags NJABL_DUL net
header NJABL_SPAM_SRC rbleval:check_rbl_results_for('njabl', '127.0.0.4') describe NJABL_SPAM_SRC DNSBL: sender is Confirmed Spam Source tflags NJABL_SPAM_SRC net
header NJABL_MULTI_STAGE rbleval:check_rbl_results_for('njabl', '127.0.0.5') describe NJABL_MULTI_STAGE DNSBL: sent through multi-stage open relay tflags NJABL_MULTI_STAGE net
header NJABL_CGI rbleval:check_rbl_results_for('njabl', '127.0.0.8')
describe NJABL_CGI DNSBL: sender is an open formmail tflags NJABL_CGI net
header NJABL_PROXY rbleval:check_rbl_results_for('njabl', '127.0.0.9') describe NJABL_PROXY DNSBL: sender is an open proxy tflags NJABL_PROXY net
score IN_NJABL_ORG 0.38
score NJABL_DUL 0.62
score NJABL_MULTI_STAGE 0.75
score NJABL_PROXY 3.00
score NJABL_OPEN_RELAY 3.00
score NJABL_CGI 1.50
score NJABL_SPAM_SRC 3.00
source: http://dbmscan.com:3455/poss/58(...)
[^] # Re: arguments.
Posté par ArnY (site web personnel) . En réponse au journal Pour ou Contre les RBL?. Évalué à 1.
Pour le grey listing, je ne pense pas que cela puisse s'appliquer chez nous:
- au final on aura environ 40 000 comptes mails, donc je suppose plusieurs centaines de milliers de mails par jours.. je ne crois pas que refuser le mail une premiere fois soit une bonne option.
- nous partons avec 3 MX de poids egal, un mail qui est d'abord refusé (par le grey listing) sur un MX ne sera pas forcement renvoyé sur le meme.. . à moins d'avoir un spool commun.
Je n'ai pas vraiment envisagé cette solution, en fait.. peut être l'ai-je éliminée trop tot... si qq'un l'a mise en oeuvre sur une structure équivalente, je suis preneur de feedback.
[^] # Re: RBLs dans Spamassassin
Posté par ArnY (site web personnel) . En réponse au journal Pour ou Contre les RBL?. Évalué à 1.
Si t'as un tuyau, sans devoir changer les fichiers internes de SA, bien sur (maintenance plus aisée)
[^] # Re: arguments.
Posté par ArnY (site web personnel) . En réponse au journal Pour ou Contre les RBL?. Évalué à 2.
Si t'es chez un FAI, tu utilises le smtp du FAI
mail provenant d'une adresse ip dynamque = virus, spam
pour cette rbl, si c'est une ip dynamique postfix genère un warning et non un reject.
[^] # Re: arguments.
Posté par ArnY (site web personnel) . En réponse au journal Pour ou Contre les RBL?. Évalué à 1.
Certaines RBL se contentent de quelques mails de spam envoyé d'un domaine pour justifier le blacklistage de tout le domaine (dans ce cas, byebye hotmail, caramail, wanadoo, etc)
Certaines, au contraire, se basent sur l'open-relay. Dans ce cas, les machines sont testés avant d'etre blacklistées.
Il y a aussi le pire, comme osirusoft a oser le faire: Mettre la clé sous la porte apres faillite ou après en avoir eu marre des procès de spammeurs mécontant d'être blacklisté et pour que les utilisateurs pensent a virer leur RBL de leur config, ben osirusoft a eu la bonne idée de toujours envoyer une réponse positive aux requètes.
Résultat: tous les serveurs de mails du monde étaient blacklistés!
Perso, je suis pour l'utilisation minimale des RBL, n'en prendre que qq unes spécialisées et dignes de confiance.. atuellement je n'utilise que
relays.ordb.org (open relay), dnsbl.njabl.org (open relay, listes d'ip dynamiques), et korea.services.net (specialisé dans le spam asiatique)
[^] # Re: arguments.
Posté par ArnY (site web personnel) . En réponse au journal Pour ou Contre les RBL?. Évalué à 2.
smtpd_client_restrictions = permit_mynetworks, reject_rbl_client ...
ah.. ben c'est comme ca que l'on fait.. le probleme des rbl pas joignables en cas de coupure réseau n'est pas mon argument mais celui de mon collegue anti-RBL.. j'ai jamais eu ce problème la personnellement.. j'ai pas vérifié la config de leur serveur de mail.
Concretement, on aura postfix (peut etre avec spf via postfix-policyd) amavis avec SpamAssassin et peut-etre CRM114 qui sera alimenté par les admins (CRM114 qui est actuellement en test, est largement plus performant que les filtres bayesiens que nous avons testé) le score de CRM114 donnera un score à amavis, qui sera ajouté au score de Spamassassin pour le calcul du score final, cela permet de minorer/majorer SpamAssassin.
Nous avons aussi testé avec le filtre bayesien de SA, mais cela ne nous convenait pas...il faut lui apprendre les bons et les mauvais mails, or les mails que recoit un admin ne sont pas forcement représentatifs des mails recu par un chercheur ou un étudiant.
Avec CRM114, c'est bcp plus simple.. tu ne lui donnes que des corrections: t'as un faux-positif, alors tu lui dis "tu t'es trompé, c'est pas un spam", si t'as un faux-negatif, alors tu lui dis "en fait, ca c'est un spam", on peut alors l'éduquer au cas par cas via une interface que l'on est en train de développer (on envoie un mail a une adresse donnée, si le mail est un spam, alors CRM114 l'apprend comme faux-positif et vis-versa). Avec une 10aine de corrections, CRM114 donne déja de très bons résultats ce qui permettra aux admins de maintenir un bon niveau de reconnaissance.
[^] # Re: arguments.
Posté par ArnY (site web personnel) . En réponse au journal Pour ou Contre les RBL?. Évalué à 1.
Tu fais ca comment avec postfix? les rbls ne sont pas locales.. je ne gère pas leur contenu.
Personnelement, je recois plus de virus que de vrai spams.
Exactement, c'est la nouvelle tendance.. de plus en plus de virus servent à envoyer du spam et contre cela, les rbls antirelay sont inutiles.. C'est pour cela que j'utilise aussi un antispam classique derriere
Pour bogofilter, même raison que pour dspam, je ne veux/peux pas utiliser procmail vu que cela se passe sur un serveur relai.
De plus, avec plusieurs milliers d'utilisateurs, je ne peux pas me premettre d'utiliser un flitre bayesien (je veux pas qu'un utilisateur décide qu'un mail de pub quelconque est un spam et qu'un autre décide que cela n'en est pas un)
[^] # Re: Mon point de vue
Posté par ArnY (site web personnel) . En réponse au journal Pour ou Contre les RBL?. Évalué à 4.
De plus, les serveurs frontaux (les MX) n'ont aucun compte linux, si ce n'ai root, tout les comptes mail sont ldap et ne sont pas des comptes shell. Je crois que pour dspam, il faut utiliser procmail.. pas de comptes shell, pas de procmail (procmail etant assez gourmand, pour gerer 40 000 comptes, ca fait un peu peur)
Dspam n'est pas une alternative à amavis (qui utilise l'API perl de SpamAssassin et fait l'interface postfix/anvirus) mais plutot un remplacant de spamd dans une architecture spamc/spamd (et donc avec procmail, encore)
Pour ce qui est de DCC et Razor2, il y a eu un temps ou j'utilisais ca.. le probleme etant que cela ralenti enormement le traitement du mails.. d'apres les timings d'amavis: 200ms avec les RBL mais sans DCC ni Razor, 1s avec les rbls et Razor et 1600ms avec RBL, DCC et Razor...
J'avais des problèmes avec Razor, certains mail de mailing lists etaient répertoriés sur les serveurs de Razor.. y compris des ML de la nasa... les chercheurs n'ont pas trop aimé.
Pour DCC, le problème est un peu le même.. certains mail en provenance de ml très répandue sont scoré sur DCC..
[^] # Re: une chtite question...
Posté par ArnY (site web personnel) . En réponse à la dépêche Évolution de la modération, création d'une nouvelle équipe. Évalué à 5.
On dirait que l'equipe de linuxfr dégage toute résponsabilité en cas de désaffectation du site. Les modéros ne sont la uniquement pour relire les news proposées et ne peuvent, eux, proposer des news. Chacun sa résponsabilité. je sais que cela n'est pas exactement le cas, mais c'est quand même l'impression qui se dégage du système.
Par exemple, je sais qu'il y a ici bcp de lecteurs de osnews. Qu'est ce qui fait l'interet de ce site? le nombre de news, du au fait que Eugenia poste bcp de news elle même, elle fait vivre Osnews et je suppose qu'elle se sent résponsable du succès de son site.
C'est peut être ca qu'il manque à linuxfr: une équipe de "journalistes" qui serait affiliés à linuxfr, au même titre que les relecteurs et les moderos, dont le "boulot" serait de proposer des news. Mais celles-ci serait validées tout de suite, sachant qu'ils seraient garant du bien fondé de ces dépèche sur linuxfr alors que les news proposées par les visiteurs passeraient par le chemin actuel: relecture, moderation, publication ou refus.
[^] # Re: gueulante contre Fedora
Posté par ArnY (site web personnel) . En réponse à la dépêche Dans la série "Une semaine avec...", aujourd'hui la SuSE 9.0. Évalué à 0.
Que gdesklet est buggé? la, je suis d'accord, d'après la trace que tu donnes, il manque une lib python, le mec a probablement installé gdesklet a partir du source, le source n'ayant meme pas pris soin de vérifer que tous les modules python etaient bien installés.
De toute facon il n'y a pas de package gdesket dans la fedora. Il existe bien des RPMS tiers noatemment ceux de Dag Wieers qui marchent très bien:
http://dag.wieers.com/packages/(...)
tu peux aussi noter que dans les dépendances du rpm gdesklet on a:
python >= 2.2, gnome-python2 >= 1.99.17, gnome-python2-gconf >= 2.0
Sinon je suis bien d'accord avec la majorité, la FC1 etait vraiment branlante quand elle est sortie, ca a été résolu rapidement, mais elle est jeune, trop jeune probablement. c'est pas Redhat, mais bon, faut lui laisser du temps, perso je participe activement à son developpement, c'est comme ca qu'on fait bouger les choses.
[^] # Re: gueulante contre Fedora
Posté par ArnY (site web personnel) . En réponse à la dépêche Dans la série "Une semaine avec...", aujourd'hui la SuSE 9.0. Évalué à 2.
yum install
yum groupinstall "Gnome Desktop Enviromment" (ou un yum grouplist pour la liste des groupes dispo)
il y a énormement de repositories yum (mozilla.org en a un officiel, ximian aussi, tous les mirroirs fedora sont des repository yum, etc), faire un repository yum c'est une seule commande à taper sans parametre particulier, vraiment très simple.
j'avais mis un exemple de yum.conf (un peu plus à jour du tout maintenant) ici:
http://linuxfr.org/comments/304925.html(...)
Pour ce qui est des problèmes avec la FC1, il est vrai qu'elle etait buggée, mais les bug fix sont arrivés très vite.
Je conseille d'ailleurs d'utiliser l'applet rhn qui n'a plus besoin d'inscription chez redhat et qui est désormais compatible avec les repositories yum et apt (conf dans /etc/sysconfig/rhn/sources). Elle vous permet de maintenir à jour votre système sans trop vous fouler.
Allez hop, -1, on est censé parler de Suse, non?
A.
[^] # Re: De la fin de vie chez redhat
Posté par ArnY (site web personnel) . En réponse à la dépêche De la fin de vie chez Redhat. Évalué à 3.
Maintenent vous pouvez garder vos RH pas cheres et utiliser les updates gratuites du projet Fedora Legacy (qui a pour but de proposer les updates des RH de la 6.2 a la 8 apres leur fin de vie) ou d'un autre projet identique. C'est pas la mort.
Ca fait quand meme la 3ieme news sur le sujet... pourquoi un tel tolé? Suse et Mdk aussi passent leur vieilles releases à la trappe, non? et pour ces distrib, je suis pas sur qu'on puisse encore trouver des updates.. meme payantes.
# Re: Savannah et Gentoo attaqués également
Posté par ArnY (site web personnel) . En réponse à la dépêche Savannah et Gentoo attaqués également. Évalué à 8.
c'est pas ce que je lis dans l'alerte gentoo:
"On December 2nd at approximately 03:45 UTC, one of the servers that makes up
the rsync.gentoo.org rotation was compromised via a remote exploit."
02/11 pour savannah (soit un mois entre la compromission et sa découverte)
02/12 pour gentoo (soit 1 jour entre la compromission et sa découverte)
# Re: Yum, fedora, problème
Posté par ArnY (site web personnel) . En réponse au journal Yum, fedora, problème. Évalué à 1.
un repository yum chez mozilla et hop!
[mozilla-seamonkey]
name=Mozilla SeaMonkey Releases
baseurl=http://ftp.mozilla.org/pub/mozilla.org/mozilla/yum/SeaMonkey/releas(...)
c'est prevu pour fedora 0.95 mais cela marche sur la 1.0
ArnY
[^] # Re: Test de la Fedora Core 1.0
Posté par ArnY (site web personnel) . En réponse à la dépêche Test de la Fedora Core 1.0. Évalué à 1.
Pour ne pas avoir à vérifier les headers sur les serveurs avant toute operation:
yum -C
# Re: Test de la Fedora Core 1.0
Posté par ArnY (site web personnel) . En réponse à la dépêche Test de la Fedora Core 1.0. Évalué à 10.
Pour ceux que cela interesse, mon yum.conf bien fourni:
[base]
name=IN2P3 - Fedora Core $releasever - $basearch - Base
baseurl=ftp://ftp.fr.freshrpms.net/pub/linux/freshrpms/ayo/fedora/linux/1/i386/core/
[base]
name=Fedora Core $releasever - $basearch - Base
baseurl=http://mirror.dulug.duke.edu/pub/fedora/linux/core/$releasever/$basearch/os/
[updates]
name=IN2P3 - Fedora Core $releasever - $basearch - Updates
baseurl=ftp://ftp.fr.freshrpms.net/pub/linux/freshrpms/ayo/fedora/linux/1/i386/updates/
[updates]
name=Fedora Core $releasever - Updates
baseurl=http://mirror.dulug.duke.edu/pub/fedora/linux/core/updates/$releasever/$basearch/
[updates-testing]
name=Fedora Core $releasever - Testing Updates
baseurl=http://mirror.dulug.duke.edu/pub/fedora/linux/core/updates/testing/$releasever/$basearch/
[fedora.us-stable]
name=Fedora.us Project Stable RPMS
baseurl=http://download.fedora.us/fedora/fedora/$releasever/$basearch/yum/stable/
[fedora.us-unstable]
name=Fedora.us Project Unstable RPMS
baseurl=http://download.fedora.us/fedora/fedora/$releasever/$basearch/yum/unstable/
[livna-stable]
name=Livna.org Fedora Compatible Packages (stable)
baseurl=http://rpm.livna.org/fedora/$releasever/$basearch/yum/stable
[livna-unstable]
name=Livna.org Fedora Compatible Packages (unstable)
baseurl=http://rpm.livna.org/fedora/$releasever/$basearch/yum/unstable
[^] # Re: Red Hat arrête le support gratuit
Posté par ArnY (site web personnel) . En réponse à la dépêche Red Hat arrête le support gratuit. Évalué à 4.
Probablement pas, de très nombreuses personne sur la ml fedora-dev ont exprimé leur envie de s'occuper de gérer les erratas et security updates pour les distrib en bout de vie de RH.
Cela va même jusqu'a la 6.2!
Je connais déja au moins 3 projets qui visent à maintenir ces produits:
Fedora Legacy -> http://www.fedora.us/wiki/FedoraLegacy(...)
Univ-Linux -> http://linux.duke.edu/projects/univ-linux/(...)
RH-Consortium -> http://www.quantumlinux.com/mailman/listinfo/rh-consortium(...)
[^] # Re: Red Hat arrête le support gratuit
Posté par ArnY (site web personnel) . En réponse à la dépêche Red Hat arrête le support gratuit. Évalué à 5.
Erreur, up2date été repris par les gens de chez Redhat qui participe à Fedora et modifié:
- Il n'a plus besoin d'inscription à RHN
- Il supporte les repository apt
- Il supporte les repository yum
Même l'applet rhn a été modifiée pour fonctionner sans rhn et utiliser les repos yum et apt.
Cette version de up2date est dispo ici:
http://people.redhat.com/~alikins/up2date/(...)
l'applet rhn la:
http://people.redhat.com/~veillard/testing/yum/rhn-applet/2.1.0/(...)
De plus, une bonne partie des gens de RedHat (Cox, Veillard, Nottingam, etc) participe au developpement de Fedora.
Vu qu'ils bossent aussi pour la RHEL, il porteront les erratas sur Fedora dès leur applications à RHEL.
[^] # Re: SuSE Linux 9.0 est sortie
Posté par ArnY (site web personnel) . En réponse à la dépêche SuSE Linux 9.0 est sortie. Évalué à 7.
La prochaine RedHat, elle, sera RedHat Enterprise ou RedHat Avdanced Server 3.
[^] # Re: Red Hat Linux / Fedora Core - Entretien et captures d'écran
Posté par ArnY (site web personnel) . En réponse à la dépêche Red Hat Linux / Fedora Core - Entretien et captures d'écran. Évalué à 8.
Quand tu veux...
Fedora utilise yum qui est un equivalent de apt en python, avec un système un peu plus avancé de gestion des rpms. (Possibiliter de faire des install groupées sans utilisation de meta packages, gestion des signatures des packages, les repositories sont très simples à mettre en place)
bref: http://linux.duke.edu/projects/yum/(...)
Autre chose, l'updateur de RedHat up2date inclu dans Fedora est compatible avec les repositories rpm de yum et apt.
[^] # Re: Red Hat Linux / Fedora Core - Entretien et captures d'écran
Posté par ArnY (site web personnel) . En réponse à la dépêche Red Hat Linux / Fedora Core - Entretien et captures d'écran. Évalué à 4.
C'est à dire que d'un côté, il y a Fedora et de l'autre cooker.
Pas exactement, Il y a toujours eu Rawhide chez RedHat qui est exactement l'equivalent de Cooker.
Fedora c'est encore autre chose, la mise à disposition de RedHat Linux à la communauté ( c'est pas encore tout a fait vrai vu que les serveurs de soumission de RPM tiers ne sont pas encore en service, il manque aussi pas mal de guidelines). Fedora permettra a tout un chacun de proposer d'inclure ses propres rpms dans ce qui etait RedHat Linux.
Je crois que l'analogie avec Debian s'arrete(ra) au fonctionnement communautaire. Le but de Fedora c'est de permettre a RedHat d'avoir une distribution de base pour ses RedHat Linux Enterprises qui aient été testées et approuvées sans que RH s'investisse commercialement dedans.
Pour l'instant, je pense que la seule chose a faire c'est wait and see... ou mieux: Test, Report, Wait and See.
A.
[^] # Re: PC sans OS et vente liée: la répression des fraudes indécise
Posté par ArnY (site web personnel) . En réponse à la dépêche PC sans OS et vente liée: la répression des fraudes indécise. Évalué à 2.
Il y a des années que DELL propose avec ses serveurs Windows, Linux ou rien.
Nous achetons 2 à 3 serveurs DELL par an et toujours sans OS (on installe notre mouture de linux dessus apres)
[^] # Re: Red Hat Linux annonce la naissance du projet Fedora
Posté par ArnY (site web personnel) . En réponse à la dépêche Red Hat Linux annonce la naissance du projet Fedora. Évalué à 1.
"kde-redhat.sf.net would be welcome to either hack on the KDE packages in
Fedora Core or offer their own alternate KDE packages in Fedora
Alternatives, if they're interested. Of course first we have to get the
infrastructure set up."
Donc c'est plutot positif, et il y a des chances que tu auras un packaging propre pour ta redhat.
ArnY
# Re: J'ai trop bu ...
Posté par ArnY (site web personnel) . En réponse au journal J'ai trop bu .... Évalué à 1.
J'ai trop bu aussi...
... du coup je suis bourré aussi
bonne nuit journal de jal
# Re: J'ai trop bu ...
Posté par ArnY (site web personnel) . En réponse au journal J'ai trop bu .... Évalué à 1.