FRsAG October 2013

frsag@frsag.org

107 participants
29 discussions

IBM Websphere
by ANIS El Achèche 07 Oct '13

07 Oct '13

Bonjour, Je cherche à suivre une formation WSAS 8.5, mais je trouve pas quel est la bonne formation pour un SysAdmin. Vous avez quelques recommandations? -- Best Regards, El Achèche ANIS Linux user *#486664 * Ubuntu user *#32379 * ubuntiste-msakni <http://ubuntiste-msakni.legtux.org>

2 1

Des retours d'expériences de Skyline?
by nap 07 Oct '13

07 Oct '13

Bonjour tout le monde, Je me demandais si certains d'entre vous aviez déjà joué avec https://github.com/etsy/skyline en test ou en prod sur des cas réels? (pour les fainéants du click, c'est un outil de détection d'aberration se basant sur la métrologie genre dans Graphite). C'est pas mal sur le principe, mais j'ai comme l'impression qu'il ne sait détecté les déviations que sur des courbes "plates", quelqu'un pour confirmer? Merci de vos retours :) Jean Gabès

1 0

Re: [FRsAG] config de la liste
by Greg 05 Oct '13

05 Oct '13

Bonsoir, la liste n'est pas mal configurée, elle est configurée ainsi, nuance. C'est pour pallier à la majorité qui "répond" au lieu de "répondre à la liste". Maintenant s'il faut changer ce paramètre reply_goes_to_list [1] je suis ouvert à la discussion ;) [1] http://www.gnu.org/software/mailman/mailman-admin/node11.html Greg Le 26 septembre 2013 14:07, Florent Fourcot <frsag(a)flo.fourcot.fr> a écrit : > Le 25/09/2013 12:59, David Sinquin a écrit : > > Et un échec de plus pour répondre avec Thunderbird. > > Désolé pour le spam… > > > > Pourquoi blâmer Thunderbird, alors que la vraie cause est une mauvaise > configuration de la liste qui force un reply-to sur frsag(a)frsag.org ? > Thunderbird fait parfaitement son boulot avec "répondre/répondre à la > liste", pour peu que la liste n'impose pas elle même des choses inutiles. > > -- > Florent. > > _______________________________________________ > Liste de diffusion du FRsAG > http://www.frsag.org/ >

20 32

Re: [FRsAG] Faux Enregistrement MX
by Stephane MANHES - OKTEY 03 Oct '13

03 Oct '13

Bonjour, Attention, sur le livre de l'OCDE la problématique n'est pas la même que celle qui vous intéresse, il s'agit de mettre un MX (même faux) sur un domaine susceptible d'envoyer des emails pour ne pas que les mails soient bloqués à la réception. Car certains serveurs vérifient la présence de MX sur le domaine expéditeur à la réception d'emails, cela permet de contrôler que le domaine est bien en mesure de recevoir des emails en retour (notamment sur abuse et postmaster). Concernant votre question générale : l'utilisant de faux MX en complément des vraies. De manière générale je ne vous recommande pas cela et ne suis pas d'accord avec les arguments du wiki de Spamassassin (d'ailleurs ils ne s'appliquent pas à eux même ces propositions Cf. conf. MX apache.com). Nous avions fait des tests, il y a plusieurs années, afin de voir si cela avait une incidence sur le trafic global de réception de mails, ce n'est pas le cas (faible proportion). D'autre part, je considère cela comme risqué en terme de génération de faux-positifs (ou plutôt perte de mails) : 1) Si vous ajoutez un faux MX, il faut impérativement qu'il pointent vers une véritable IP, car certains serveurs (cf. cas présenté par l'OCDE ci-dessus) pourraient refuser vos emails en entrées si le MX ne pointe pas vers une IP valide. 2) Cette IP ne doit pas être en écoute sur le port TCP/25, sinon vous perdrez des emails dans tous les cas : retour 500 = le mail est refusé, retour 200= le mail est accepté, mais vous ne le récupérerez pas, car c'est un serveur inutilisé. Si par malheur, le serveur en question fermé sur TCP/25, se retrouve en écoute à un moment donné, vous allez perdre des emails. 3) Ne considérez pas qu'en le mettant avec un poids MX élevé il ne recevra que des spams et aucun emails légitime. Même avec une configuration 10 MX ok1, 20 MX ok2, 30 MX ok3, 1000 MX Fake. Le serveur Fake recevra quand même quelques mails légitimes (très peu soit, mais quelques-uns) et ceci même si les tous serveurs "ok" sont toujours Up. 4) D'autre part, contrairement à la logique et la théorie SMTP, certains serveurs n'arrivent pas à switcher de MX. Dès lors qu'ils essaient sur un MX ils vont persévérer dessus, attendre et réessayer indéfiniment (tant que le délai de réexpédition configuré n'est pas dépassé). Ceci est rare, concerne plus les cas de rejets temporaires que les indisponibilités franches, mais ça existe (retour d'expérience, non théorique). En résumé, il est moins risqué de configurer normalement les MX en y associant des vrais relais filtrant qui fonctionnement. Je trouve que ça ne vaut pas le coup de prendre le risque de perdre des emails en voulant réduire le trafic (d'autant que si vous passez par un tiers comme nous, peu importe pour vous le trafic traité ;-) ). Stephane MANHES Oktey - Altospam (PS/ Merci pour votre pub) > -------- Message original -------- > Sujet: [FRsAG] Faux Enregistrement MX > Date : Thu, 03 Oct 2013 17:02:14 +0200 > De : Séb <seb(a)isostorm.com> > Pour : French SysAdmin Group <frsag(a)frsag.org> > > Bonjour, > > Je suis actuellement à la recherche d'une potentielle solution Online > pour protéger un serveur mail en scannant via un système type AltoSpam > ou similaire. > > Il se trouve que lors de cette recherche, je suis tombé sur de nombreux > tips qui propose d'ajouter sur le serveur DNS des faux enregistrements MX : > - https://wiki.apache.org/spamassassin/OtherTricks > - http://goo.gl/EtqiEX > - http://goo.gl/iXeKa0 > - http://www.hermes-project.com/pages/fakehermes > > Je me demande tout de même si il n'y a réellement aucun risque de perte > de mail avec l'utilisation d'une telle "astuce". > > Si vous avez des retours, n'hésitez pas, et merci d'avance :) > > Bonne fin de journée. >

1 0

Apéro Lyonnais - Septembre
by cam.lafit＠azerttyu.net 02 Oct '13

02 Oct '13

Bonjour tout le monde, Comme vous le savez tous le mois de septembre dure un peu plus que les autres et compte 32 jours. Je vous propose donc de lever notre verre à cet exceptionnel mois, ce mercredi 32 septembre. Certains agenda maintiennent que ce serait en fait un mercredi 2 octobre, nous ne laissons par perturber par ces mauvaises langues. Pour le point de chute, je vous propose Le Tono à cordeliers déjà connu :) Bien entendu je vous invite à vous inscrire sur le framadate : http://framadate.org/studs.php?sondage=ijdz2c6147e27q7a Bon week end à tous :) Km

1 1

Centralisation/analyse de logs
by Rémy Sanchez 02 Oct '13

02 Oct '13

Bonjour à tous, Je déploie actuellement avec grand plaisir des applications Java en charge de faire du traitement de masse sur des données. Actuellement, on utilise log4j pour sortir ces logs, configuré grosso modo comme tel : * Les messages de debug sortent dans un fichier debug.log qui est rotaté dès qu'il dépasse 100 Mo * Les messages autres vont dans des fichiers info.log, warn.log, error.log, qui sont rotatés sur base de la date * Quand une erreur arrive, on envoie un mail Donc pour les messages de debug, tout va bien, par contre pour le reste comment dire... Quand on a une erreur lancée pour chaque ligne de donnée (ce qui est arrivé plus d'une fois), alors on a grosso modo la même exception qui monte des millions de fois (mais pas exactement la même). Cela a plusieurs effets de bord : d'une part faire tomber le serveur mail, et d'autre part saturer les disques et empêcher le fonctionnement du service. L'idée serait donc d'externaliser la gestion des logs pour 2 raisons : * Empêcher que les logs nuisent à l'exécution du programme en saturant l'espace disque * Être capable de gérer les erreurs par lot : si une même exception arrive 2 millions de fois, générer une seule alerte et l'envoyer par mail à la team de maintenance, par exemple Je cherche donc un système en mesure d'absorber des gros pics de logs, de ne pas consommer des gigas et des gigas de stockage, et de préférence avec une interface de visualisation web sympa. Possiblement compatible avec syslog ou en tout cas avec un appender log4j. Pour l'instant j'ai trouvé http://three.kibana.org/ qui semble convenir approximativement à ces besoins. Il y a aussi un vieux thread (http://www.frsag.org/pipermail/frsag/2010-July/000226.html) qui liste pas mal de choses, mais qui n'ont pas l'air d'être adaptées au besoin de traiter les choses en bloc. À part Facebook Scribe éventuellement, mais ça a l'air trop perché par rapport au temps que je peux y consacrer. Je suis preneur de toute proposition/retour d'expérience :) Merci, -- Rémy Sanchez http://hyperthese.net/

10 16

Fwd: Re: config de la liste
by Maât 02 Oct '13

02 Oct '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Oup's erreur toussa fallait pas cliquer sur reply... sans doute l'inconscient :-P Forward à la liste (Désolé Geg) Maât - -------- Message original -------- Sujet: Re: [FRsAG] config de la liste Date : Wed, 02 Oct 2013 12:05:42 +0200 De : Maât <maat(a)grenouille.com> Pour : Greg <greg-frsag(a)duchatelet.net> Le 02/10/2013 11:43, Greg a écrit : > On est d'accord pour dire que la config actuel (qui vient de > changer) est standard ? > > (On repasse en natural posting ^^) Hé bien en fait non elle ne l'est pas. Pierre tout à l'heure a mis un lien très intéressant (je le remets pour les flemmards*: http://woozle.org/~neale/papers/reply-to-still-harmful.html) Cette "tentative" pour mettre fin au débat repose sur un postulat foireux qui consiste à décider que le système de listes n'est pas l'émetteur des mails reçus (je dis bien reçus). Or en vrai si : Quand j'envoie un mail à frsag(a)frsag.org je n'envoie pas un mail à Pierre (ni au Paul d'ailleurs je ne sais pas s'il y en a parmi nous, ni spécifiquement à toi...) Et c'est parce que tu es abonné à la liste que Mailman (ou Sympa ou whatever) décide de t'envoyer à toi (ainsi qu'à plein d'autres) un mail qui contient ma prose. En fait potentiellement au moment ou j'écris je ne sais même pas que tu existes, et au moment où tu t'abonnes tu ne sais potentiellement rien de moi donc tu n'es pas plus destinataire de mon mail que Paul ou Jacques (Pour changer) parce que j'écris à la liste et je ne suis pas plus l'émetteur du mail que tu reçois parce que c'est un système de liste qui émet le mail. De la même façon que quand on fait un forward, on fait une action volontaire pour pousser un mail à quelqu'un... et c'est pas l'émetteur d'origine qui doit être dans le reply-to Sauf qu'un système de listes fais du forwarding à tour de bras et dans tous les sens... et que c'est pour ça qu'on s'y abonne (ça et parce qu'il y a des gens bien qui écrient des trucs intéressants à forwarder et à lire ^^) => C'est donc bien le système de listes qui est le vrai émetteur des mails que chacun reçoit (c'est lui qui est dans les adresses de bounce aussi preuve^Windice de plus qui conforte l'idée que l'émetteur est bien là)... ce qui veut dire à la lecteure de la RFC 2822 que le reply-to par défaut (qui est, au passage, décrit dans la norme comme une _proposition_ faite au client mail pas un truc qui doit obligatoirement être suivi... d'ailleurs nos clients mails sont souvent paramétrables et permettent d'ignorer les reply-to) est supposé être l'adresse de la liste... C'est quand on déroge à ça qu'on fait du "munging" et qu'on sort du standard en réalité... My 2 cents Maât * Ne le prenez pas mal c'est la qualité n°1 que je recherche chez un sysadmin ^^ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJL8IMACgkQRqFGaA6Bzx1yeQCfU3O8Hp5uhB0CncxUnPGcim+r KFAAn2tnlHH2KvVeNZZZePQ28GE3FdZv =kjYq -----END PGP SIGNATURE-----

2 1

Beer event Vendredi 5 juillet 19h
by seb astien 02 Oct '13

02 Oct '13

Salut, On se retrouve le vendredi 5 juillet à 19h au café rouge paradis, 7 rue de paradis, paris 10éme, metro gare de l'est. La chouffe est abordable et le patron sympa. Utilisons mappy à la place de google maps<http://fr.mappy.com/#/5/M1/TDiscovery/N195.63621,-14.09942,2.35436,48.87459…> Avis aux intéressés. Sébastien

2 3

Choix routeur cisco.
by gpkfr 01 Oct '13

01 Oct '13

Bonjour la liste, Pour un boite d'environ 50~70 personnes auriez-vous quelques conseils sur le choix d'un routeur Cisco à brancher dérrière une liveboxPro Fibre ; Guillaume

4 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

FRsAG October 2013