- FRsAG - frsag.org

LTSP GNU/Linux et IE
by Christophe Moille 24 Aug '10

24 Aug '10

Salut, Je suis en train de chercher une solution fiable pour mettre en place un service terminal serveur GNU/Linux, avec Internet Explorer utilisable, certains service de la coopérative où je veux installer cette solution nécessitent encore Internet Explorer, version 7 de préférence. J'ai choisis LTSP qui me semble être une excellente solution pour ce faire (sous Ubuntu ou Debian). Par contre, Je ne sais pas comment utiliser élégamment Internet Explorer. J'ai d'abord pensé à mettre en place virtualbox sur le serveur et utiliser une image virtuelle de Windows XP, ça marche, mais sa maintenance me semble bien compliquée. L'image ne semblant pas être partageable entre plusieurs utilisat-eur-rice-s. Ce qui implique qu'il me faille intervenir sur chaque compte à chaque fois qu'il y a une mise à jour, sans compter l'espace disque utilisé... J'ai bien vu qu'il existait IEs4Linux, mais mon expérience avec cette solution n'a pas été concluante, pas réussi à faire tourner IE6 et ça ne me semble pas assez fiable pour être mis en production. J'aimerais bien éviter d'avoir à faire tourner une deuxième machine en serveur windows, juste pour faire tourner de l'IE. Merci pour les pistes que vous pourriez proposer. -- Christophe Moille +33 (0) 950 727 525 Elle est à l’horizon [...]. Je me rapproche de deux pas, elle s’éloigne de deux pas. Je chemine de dix pas et l’horizon s'enfuit dix pas plus loin. Pour autant que je chemine, jamais je ne l’atteindrai. A quoi sert l’utopie ? Elle sert à cela : cheminer. — Eduardo Galeano

4 5

Re: [FRsaG] DNS RPZ (ou comment justifier des réunions oisives ?)
by Stephane Bortzmeyer 23 Aug '10

23 Aug '10

On Sat, Jul 31, 2010 at 12:09:33PM +0200, Jérôme Nicolle <jerome(a)ceriz.fr> wrote a message of 57 lines which said: > C'est séduisant, mais ça va poser un autre problème : la lourdeur > administrative de gestion des identités des délégataires va coûter > des ronds, Tout à fait. Certains registres (suivez mon regard...) ont essayé d'organiser, de policer le DNS, d'en faire un « espace de confiance ». Tous les clients se sont enfuis en courant et les « policeurs » sont revenus à des politiques plus souples.

1 0

Sources de documentation
by Jérôme Nicolle 14 Aug '10

14 Aug '10

Bonjour, Je lance ce thread comme un scrapbook, histoire de lister les différentes sources de documentation / best practices et autres trucs et astuces que vous utilisez. Parce que RTFM n'est pas toujours suffisant, et pour pouvoir quand même le dire plus souvent, à vous de jouer ! J'ouvre le bal avec quelques classiques : *Les généralistes* _howtoforge_ : http://www.howtoforge.com/ Relativement à jour et couvrant pas mal de domaines, c'est une compil de "cut'n paste" multi-distros assez basique. Si ça pas marche, ça n'expliquera jamais pourquoi. Et manque de bol, ça arrive. _linode_ : http://library.linode.com/ Un des plus vieux hébergeurs de VPS XEN, qui a eu la bonne idée de monter une équipe de coumentation pour réduire la charge de support. Les tutos sont nombreux, clairs, rapides, et globalement à jour et testés. Valables en tout cas pour au moins 3 distros mainstream (ubuntu LTS, debian stable et CentOS) _The Linux Documentation Project_ : http://tldp.org/ Ben heu... comment dire... Rarement à jour, couvrant plus le système que l'applicatif, mais pratique pour approfondir certains sujets _admin-linux.org_ : http://blog.admin-linux.org/ Pas exhaustif, mais avec quelques tuyaux sympas *Distro-specific* Pour moi, la meilleure doc est quand même celle de _gentoo_ : http://www.gentoo.org/doc/en/?catid=sysadmin Mais bon, je suis pas allé voir du coté des RPM-based ;) Pour le reste, google indexe assez bien la blogosphère, et quelques blogs d'admin (dont certains d'entre nous) ressortent bien du lot. Par contre on tombe rarement du premier coup dessus, alors pensez à donner les URL de vos sites/blogs/docs, ça finira par atterir sur un planet ! @+ -- Jérôme Nicolle

11 12

Gestion de téléchargement de fichier - méthodes
by Sky Gunning 05 Aug '10

05 Aug '10

Bonjour à tous Désolé, ceci est en partie DEV, mais y'a une partie système que je connais moins bien et qui doit surement répondre à une partie au moins de ma question. Je gère l'intranet de ma boite j'ai dessus un petit service de stockage et partage de fichiers entre nous et nos clients. Au début tout allez bien avec des fichiers pas plus gros que 500mo ... depuis qq temps, on approche des 1go ou 2go régulièrement. L'upload ne pose pas de soucis : je passe par un petit script perl qui turbine pas mal du tout. Le soucis est au téléchargement qui est effectuer en PHP. Les fichiers sont stockers sous la racine public_html (sécurité oblige hein) et c'est donc un script PHP qui fais un simple readfile(); suivit d'un exit. Avec une connexion lente et/ou un gros fichiers, il arrive que le téléchargement se bloque. Je voudrais utiliser apache ou ftp pour le téléchargement tout en conservant les fichiers stocker au même endroit. Comment faire ? Je suis en train de test un système de liens symboliques que je supprimerai après genre x heures. Mais c'est pas très sécurisé si un veux qu'une seul personne puisse accéder au lien. Merci d'avance pour vos idées :) Je suis désolé si ceci est trop dev pour vous, je recommencerai pas... mais vue l'activité de la liste ... me suis dit que mieux ça que rien ... quoique ? ;-) Sky_G.

6 7

DNS RPZ (ou comment justifier des réunions oisives ?)
by Florian MAURY 02 Aug '10

02 Aug '10

Bonsoir, Je viens de lire un post sur le blog de l'ISC (Internet Systems Consortium) à propos d'une annonce faite au Black Hat avant hier et à la DefCon hier : l'introduction d'un système de notation de la réputation des noms de domaines : DNS RPZ. Voici le post: https://www.isc.org/community/blog/201007/taking-back-dns-0 Je me permets de contacter la liste pour relayer l'information d'une part, et que nous puissions discuter de cette technologie et de son intérêt (ou plutôt l'absence d'intérêt, à mes yeux) d'autre part. J'ai beau me torturer, je ne vois pas le moindre intérêt à cette idée : les DNSBL n'ont jamais réussi à juguler le Spam (causant plus de problèmes qu'autre chose (cf. http://www.mail-archive.com/frnog@frnog.org/ conversation sur les antispams), sans parler de la déléguation de sa politique d'email à des inconnus), et pourtant, ils veulent reprendre cette idée afin de permettre la notation des noms de domaines et ainsi limiter les méfaits des "bad guys". Dans la série des problèmes adressés par cette techno, je vois, de prime abord le contenu reconnu universellement illicite (13yo.xxx et autres sites contenant des images que nous ne souhaitons pas voir (?)) et également le phising. Concernant les sites à caractères innopportuns (oui, je tourne autour du pot, mais je ne compte pas prononcer ce mot, affiché trop souvent comme porte-étendard, voire seul mal sur Internet (avec le piratage, évidemment) (http://www.cleanternet.org/ )), nous le savons tous, bloquer le nom de domaine ou la récursion n'est pas une solution pour stopper la diffusion (pour peu que des noms de domaine soient utilisés, ce dont rien n'est moins sur) ; déjà que bloquer les IP ne sert à rien puisque les sysadm s'occupant de ce genre de réseaux sont tout aussi capables que nous de mettre en place des solutions d'hébergement multi-site robustes, avec l'avantage d'utiliser des botnets, donc autant dire des milliers de sites (Tiens d'ailleurs, personne a envisagé de tenter l'hébergement de son site sur un botnet ? ^^ ca coute certainement moins cher qu'un rps/kimsufi/dedibox/digicube). Concernant le phishing – même si je ne suis pas spécialement d'accord avec son approche, puisqu'il arrivera bien un jour où, acculés, ils y viendront – Stéphane Bortzmeyer a publié un billet sur son blog à propos du typosquatting (en l'occurence avec des IDN) et de son manque totale de nécessité vis à vis du phishing ( http://www.bortzmeyer.org/idn-et-phishing.html ) . En effet, M. Michu, en bon luser, ne vérifie pas le nom de domaine employé avant de saisir ses informations personnelles. La solution globale au phishing n'a pas encore été trouvée (HTTPS ne résout rien ; M Michu ne regarde pas plus son certificat que son URL ; du moment que la barre est verte (!) avec le petit cadenas, c'est bon, il met son numéro de CB), mais plusieurs technologies s'occupent déjà de cela, comme elles peuvent ; rajouter une autre technologie ne sert réellement qu'à justifier le temps passé en réunion improductive. On voit donc bien que ce genre de technologie n'apportera rien : le problème est ailleurs ; à mon sens, il se situe au niveau des registrars ; mais ça, ce n'est peut être pas politiquement correct de l'annoncer ouvertement de leur part. "Oh, mon dieu ! Mon nom de domaine à 5 euros a une mauvaise réputation ! Foutu DNS RPZ ! Je vais encore devoir en acheter un autre ! Ils viennent de me faire perdre 1/10000 de mon chiffre d'affaire ! Trop dur !" se diront les hameçonneurs, exactement comme les spammeurs le disent depuis que le domain-tasting a été supprimé. Une solution qui me parait viable serait tout simplement de renforcer le contrôle identitaire à la délégation d'un nom de domaine (notez l'emploi du terme délégation et non achat), par injonction de l'IANA et consort auprès des TLD. Si une personne physique ne peut plus enregistrer de nom de domaine pendant une période de X années après un abus constaté et que l'ensemble de ses noms de domaines sont repris par les registres en cas de faute, mathématiquement le nombre de domaines malicieux va être appelé à descendre. Afin d'empêcher la réservation massive (pour une campagne de spam, au hasard), la limite serait également imposée sur la quantité de noms de domaines réservables sur une période donnée. On résoudrait par ailleurs en parti le problème du Spam, si l'on forcait l'emploi des solutions anti-spoofing comme SPF (avec limitation du nombre de cibles maximum) ou DKIM reposant toutes les deux sur l'emploi de DNS. Si je spam, on me reprend mes domaines et je ne peux plus en demander d'autre => je ne peux plus spammer puisque je n'ai pas la possibilité de configurer des records DNS et qu'ils sont indispensables à la livraison de mes courriers. Si les grands webmail (plouf plouf live, gmail, yahoo) se mettent à appliquer ce genre de politique, on peut être sur de voir une adoption assez rapide et radicale. Bref, après cette digression sur le spam, et pour en revenir au sujet initial, ai-je manqué une étape ? Quel est votre avis sur DNS RPZ ? Cordialement, Florian MAURY

3 2

bonne fête à tous
by Baroiller Pierre-Emmanuel 30 Jul '10

30 Jul '10

http://www.sysadminday.com/ ;)

10 10

550 spam detected chez free.fr
by Greg 30 Jul '10

30 Jul '10

Bonjour, la plupart des membres de la liste qui utilise une adresse @{free,online}.fr, ont été automatiquement désactivé par rejet : host mx1.free.fr[212.27.48.6] said: 550 spam detected (in reply to end of DATA command) Donc si vous voulez continuer à être membre, soit free m'explique ce que je fais de mal, soit ils trouvent une solution, soit les membres concernés changent leur adresse d'abonnement à la liste. -- Greg

2 1

Anti-spam (was: [FRnOG] Antispam : vaderetro, ironport, proofpoint... vos avis.)
by Benjamin Billon 30 Jul '10

30 Jul '10

Hello la liste, Je reprends un sujet d'une autre liste où celui-ci n'avait pas grand chose à faire et que certain d'entre vous a déjà suivi avec plus ou moins de passion. Il est vrai que le suspens est au rendez-vous : Kimberley apprendra-t-elle que Rodrigo a tué son père avant la fin de la saison ? Le début de la discussion portait sur l'intérêt (ou pas) des soft et appliances de filtrage de spams. Je cite: > > A titre d'information, utilisez-vous des appliances du type > antispam/antivirus et si oui quel retour avez-vous au niveau : > > - efficacité, > > - fiabilité au niveau soft/hardware des boîtiers, > > - facilité d'usage pour l'utilisateur final, > > - flexibilité d'administration, > > - etc. Après une malheureuse réponse sur le sujet, comportant le fatal nota bene "l'open source peut le faire", le malheureux poseur de questions n'aura pas droit à d'autres réponses à sa question. Si _VOUS_ avez des réponses qui collent à la question, il serait intéressant d'avoir vos retours d'expérience. Sinon pour partir dans la philosophie, nombre de posts plus tard, quelqu'un a donc dit : > "C'est quoi le SPAM ?" > > Parce qu'on est arrive au point ou le spam c'est un e-mail qu'on a recu > et qu'on aime pas => un spammeur = quelqu'un qui envoie beaucoup > d'emails que beaucoup de gens aiment pas(*). Le bon-sens, l'opt-in (meme > "confirme"), le concept de "relation contractuelle" ou les diverses > "definitions" (UBE, UCE, ....) ne veulent quasiment plus rien dire. Et quelqu'un d'autre a répondu : > - si l'émetteur a acheté son fichier chez biduleProspect => spam > - les mails medoc/montres/logiciels à prix cassé et autres => spam > - les mails qui viennent d'une boite avec qui tu n'as pas de relation, que > ce n'est pas quelqu'un que tu connais qui l'envoi et qui veut en plus te > vendre des volets roulants => spam > - les mails envoyés à des messages-id => spam > - et j'en oublie... > Dans 97% (à la louche) des cas, pas besoin de réfléchir plus d'1 seconde. > > Et par inférence les boites spécialisées (dont c'est le business) dans le > routage de ces saloperies ou autres groupements du même acabit ben on les > appelle des spammeurs. Une définition largement répandue, et acceptée par la plupart des gros receveurs, est que "le spam est ce que le destinataire considère étant un spam". Ca inclut tout un tas de trucs, notamment des messages pour lequel le destinataire s'est bien abonné mais qu'il ne souhaite soudain plus recevoir. Pour cette raison, les receveurs tolères un faible pourcentage de plaintes pour spam par IP, domaine et/ou envoi (en fonction de leur système) et ne requièrent pas le zéro absolu en matière de taux de plaintes. Ca signifie aussi que, même si le message a été envoyé par un utilisateur de escrocProspect, si le destinataire va chercher le message en spambox pour le remettre en inbox, ça ne sera pas un spam. Autrement dit, un même message peut être et ne pas être un spam, la différence étant la personne qui le reçoit. Le problème avec cette définition, c'est que l'on risque de considérer que les "messages" pour le viagra ne sont pas toujours du spam, puisqu'il y a des acheteurs. Je pense donc que cette définition n'est utilisable que pour construire des systèmes de filtrage par réputation (ou scoring des IP, ou scoring des domaines, appelez-ça comme vous voulez), et que des exceptions doivent forcément être faites : "ok, le type est venu chercher le message en spambox, mais il vient quand même d'une IP dynamique, listée dans 4 blacklists et contient des termes qui feraient rougir spamassassin". Une autre définition elle celle de l'UBE: Unsolicited Bulk Email. Là on ajoute une notion de quantité, et donc de "campagne". Je n'ai pas trouvé d'exemple pour contredire cette définition, donc si _vous_ avez de quoi l'écorner, n'hésitez pas. Toutefois, celle-ci ne permet pas de répondre pas aux problèmes du sysadmin qui doit épurer le trafic mail de son réseau : comment savoir si 1) c'est un email (bon ça ça devrait aller) 2) si c'est envoyé en masse* et 3) si il est attendu ou non**. Si on avait la réponse à "comment savoir quand un mail est un spam", la vie serait déjà beaucoup plus belle. * Pour un gros receveur, ce n'est pas très compliqué, mais nous pensons à tous les sysadmins, même ceux qui ne gèrent qu'un seul petit domaine. Certains réseaux rendent publiques leurs statistiques (nombre de messages reçu de tel bloc / telle IP / tel domaine), mais souvent a posteriori, après que la campagne soit terminée ** des solutions comme celles d'Habeas permettent de certifier que le destinataire s'est abonné au message (et de fait faciliter l'arrivée en inbox). Ca n'est toutefois pas à la portée de toutes les bourses. Merci à ceux qui ont lu jusqu'au bout, vous êtes mes plus grands fans. -- Benjamin

3 3

Propagation de kernels sur VM Xen
by Olivier Bonvalet 29 Jul '10

29 Jul '10

Hello la liste, suite à quelques déboires avec depmod qui a évolué entre Lenny et Squeeze, je me demande si ma méthode de propagation des kernels sur les VM est judicieuse. Il arrivera fatalement un moment où le Dom0 et le DomU ne seront pas "compatibles". De plus, si au passage je peux automatiser un peu plus ou améliorer le process, c'est pas plus mal. Le contexte : le kernel utilisé dans la VM est fourni par l'host, mais il faut aussi propager les modules du kernel dans la VM. Actuellement j'utilise un script sur le Dom0 qui coupe la VM, monte son système en local, balance les dossiers de /lib/modules/, mets à jour la version du kernel indiquée dans le fichier ".cfg" et enfin redémarre la VM. Rudimentaire, mais fonctionnel. Problèmes : - le Dom0 doit donc avoir une version de /lib/modules/ compatible avec ce qu'attend le DomU (d'où mon soucis Lenny/Squeeze) - la mise à jour du kernel est donc déclenchée à l'initiative du Dom0... donc pas d'autonomie de ce coté pour le client Solution 1 : déplacer le kernel dans la VM. Cela implique l'utilisation de pygrub (sécurité ?), et d'avoir un outil de propagation simple du kernel sur chaque VM, si possible sans avoir à trop intervenir. On gagne en souplesse, mais pour l'industrialisation c'est un peu rapé. Solution 2 : compiler les modules en statique, et toujours utiliser le même nom de kernel (ou faire pointer un lien symbolique). Ainsi à chaque reboot la VM prend automatiquement la dernière version du kernel qu'on lui propose. J'utilise déjà cette technique dans le cadre d'un projet spécifique, mais manque de bol ici j'ai besoin de l'aspect modulaire de mes kernels. Solution 3 : déployer le kernel et ses modules dans 2 packets Debian adéquat, à fournir pour toutes les distribs utilisées (y compris dérivés Debian), ajouter le repository en question sur chaque VM, et synchroniser comme il faut les mises à jour de paquet Dom0 & DomU... C'est la solution utilisée par défaut avec ce que propose Debian, mais ça ne me semble pas vraiment jouable ici. Solution 4 : utiliser un lien symbolique pour pointer sur le dernier kernel dans le fichier de conf Xen (cf solution 2), et utiliser un système de fichier spécifique pour propager automatiquement mon dossier /lib/modules/ dans la VM. NFS, ou une partition spécifique en read-only commune à toutes les VM et à ajouter dans le fstab de chacune d'elles. Ca me semble tordu comme montage, mais ormis l'aspect bricolage ça semble répondre à tous mes problèmes. Solution 5 : faire comme certains hébergeurs et ne mettre à jour le kernel que tous les 5 ans. Un petit coucou en passant à mon hébergeur préféré qui me fourni un joli 2.6.16 sur ses Xen ;) Et vous, vous faites comment pour déployer vos kernels sur les VM ? Ai-je loupé une solution plus simple / rapide / propre ? Olivier B.

2 3

Analyse des logs PHP
by frantishrek 28 Jul '10

28 Jul '10

Bonjour, Je fais du dev et m'occupe d'une petite infra (5 serveurs) web pour des applis de ma boîte (environ 5000 visiteurs uniques/jour) hébergées par notre hébergeur. J'aimerais avoir votre retour d'expérience sur l'analyse des logs PHP. Je cherche une solution qui : - me permette d'être alertée des erreurs des scripts PHP - des fréquences des différentes erreurs - si possible avec la pile d'exécution (backtrace) - si possible avec l'URL de la page incriminée - si possible avec les variables de session, post, get, ... L'objectif est d'être prévenu des problèmes survenant sur la prod et de les transmettre aux dev (voire alimentation automatique du bug tracker). Nous utilisons pour le moment Zend_Platform qui propose ces fonctionnalités. Nous sommes pleinement satisfaits de la partie monitoring des erreurs PHP (possibilité d'être alertée par mail, interface d'administration qui permet de visualiser la fréquence des erreurs, ...) mais pas du packaging du produit. Le produit est assez fermé. Les extensions sont celles de Zend. Les hébergeurs connaissent mal le produit, nous avons parfois des problèmes de stabilité du produit. On est en train de migrer sur Zend_Server mais on rencontre les mêmes problèmes. Vu le coût des solutions Zend, j'aimerais bien trouver une solution un peu moins chère et un peu moins exotique (remplacement des extensions de Zend par les extensions reconnues, type APC, xdebug,...). J'ai regardé un peu du côté de Logwatch avec un agent PHP. Cela répond à une partie du problème mais l'analyse des erreurs est moins fine (pas l'url posant problème, pas la pile d'exécution - backtrace -, ...). Il existe bien des alternatives Open Source comme Pinba (www.pinba.org) ou APM (http://code.google.com/p/peclapm/) mais le développement semble arrêté. Et vous ? Quelle solution avez-vous mis en place pour monitorer PHP ? Je suis curieux de savoir comment est traité cette question sur de grosses plate-formes genre site de médias, facebook, ... ? Je vous remercie pour vos retours. Bonne journée, frantishrek

6 19