[FRsAG] Re: détecter une tentative de spam sur POSTFIX/DOVECOT (compte mail piraté)
On 02/08, Antoine Durant wrote: > Je cherche un script/commande qui me permet de savoir qui envoi des messages > depuis DOVECOT/POSTFIX. > > En fait, la semaine dernière j'ai un compte utilisateur qui je pense via une > attaque dictionnaire a été utilisé pour envoyer un grand nombre de mail... > Je cherche un moyen plus rapide de savoir à un instant T qui utilise le > service > pour envoyer des mails. Une sorte de compteur d'envoi par compte ou je ne sais > quoi afin de pouvoir identifier le ou les comptes qui posent problèmes ! > > Comment faites-vous, une astuce ou une commande plus ou moins magique ? Ici on utilise mailscore[*], policy daemon de postfix, qui permet de mettre des limites sur l'adresse ip émettrice et/ou sur l'adresse d'enveloppe ou le compte SASL (s'il y a eu authentification). Le daemon utilise une base sql pour garder les scores, donc une requête simple te donne les top spammeurs. * http://mailscore.sourceforge.net/ A+ -- Cyril Bellot France Teaser ___ Liste de diffusion du FRsAG http://www.frsag.org/
[FRsaG] Re: Processeurs Nehalem
Hello, On 22/07, Frédéric VANNIÈRE wrote: > Sur le Supermicro j'ai bossé avec Actualis il y a longtemps, c'était > n'importe quoi, ensuite Dataswift (avant le rachat) mais ça a été la > cata et pour finir j'ai travaillé un bout de temps avec ASinfo mais j'ai > laissé tombé suite aux problèmes matériels et surtout d'assemblage (vis > qui se balade, câble USB sous la CM). > > Supermicro fait du matériel de très bonne qualité et performant mais > tout ce qui est soft (firmware, BIOS, IPMI) est vraiment à chier. > (...) > Maintenant je n'achète que du HP, le matériel est moyen (chipset > broadcom) mais le support est génial. Même expérience ici avec les Supermicro chez ASinfo. On a vite laissé tomber pour retourner à DELL (spécialiste du chipset foireux également). Les accès consoles via les cartes Drac sont pénibles (clavier fucked up) mais ça marche de base (et sans licence) -- Cyril Bellot France Teaser ___ FRsaG mailing list FRsaG@frsag.org http://www.frsag.org/mailman/listinfo/frsag
[FRsaG] Re: Technos utilisées pour les images disques en environnement virtualisé KVM
Bonsoir, On 06/08, Olivier Bonvalet wrote: > Actuellement je gère donc ça via DRBD, directement sur l'host (le > "Dom0 Xen"). Et j'en suis assez satisfait, mais ça fait longtemps > que je n'ai pas fait de bench. Ici, nous avons tourné quelques temps sur une plate-forme similaire : 2 machines en DRBD master/master offrant en partage iscsi des volumes montés par des dom0 sur d'autres machines et faisant tourner les VMs en xen. Côté fonctionnel, il y avait ce qu'il nous fallait (redondance du stockage, bascule à chaud des VMs) à part l'évolutivité (perfs IOs de DRBD) C'était clairement une étape de lancement avant d'avoir des SANs que nous utilisons désormais avec des grappes de machines qui montent les mêmes volumes partagés en iscsi. La gestion des volumes des VMs est faite via CLVMd (du LVM partagé par plusieurs serveurs), les VMs (en KVM) montent donc (en raw) des volumes au sein de ce LVM. Le SAN arrive à faire du thin provisionning malgré les volumes LVM affectés systématiquement. Côté snapshot, c'est donc fait de manière globale sur le SAN. Le snapshot LVM étant beaucoup trop impactant sur les performances, nous ne l'implémentons pas pour chaque volume de VM. Nous regroupons donc les VMs par politique similaire. Nous avons de la réplication asynchrone sur les SANs pour la sécurité des données mais nous testons actuellement la réplication synchrone en utilisant des volumes CLVM mirror répartis sur 2 SANs. Dans ce que nous avons testé/utilisé et abandonné : - Les images de VMs au format qcow2 sur de l'OCFS2 partagé par les grappes de serveurs : trop instables, beaucoups de problèmes de corruption de donnée, probablement plus à cause d'OCFS2 (en tout cas de la version que l'on avait utilisée). Dommage c'était assez plaisant (pour le provisionning par exemple) d'autant que qcow2 permet du snapshot simple. - heartbeat pour migrer/démarrer automatiquement les VMs. Finalement ça génère plus de soucis qu'autre chose. Nous n'avons que rarement besoin de bouger les VMs et le risque de corruption peut être trop important. Ca reste une petite plate-forme de VMs même si apparemment le modèle semble satisfaisant pour évoluer. -- Cyril Bellot France Teaser ___ FRsaG mailing list FRsaG@frsag.org http://www.frsag.org/mailman/listinfo/frsag
[FRsaG] Re: Technos utilisées pour les images disques en environnement virtualisé KVM
On 14/08, Jerome Benoit wrote: > Le Fri, 6 Aug 2010 19:47:49 +0200, > Cyril Bellot a écrit : > > Ici, nous avons tourné quelques temps sur une plate-forme similaire : > > 2 machines en DRBD master/master offrant en partage iscsi des volumes > > montés par des dom0 sur d'autres machines et faisant tourner les VMs en > > xen. Côté fonctionnel, il y avait ce qu'il nous fallait (redondance du > > stockage, bascule à chaud des VMs) à part l'évolutivité (perfs IOs > > de DRBD) > > C'est cette partie de l'architecture que j'ai du mal à comprendre. > Vous aviez un besoin spécifique d'offrir sur le réseau du stockage à > d'autres machines, ces autres machines étant dédiés à la > virtualisation ? (parce que en gros, vous avez flingué toutes les > performances de DRBD en utilisant un serveur iSCSI par dessus ...) Le bottleneck restait DRBD (les IO disques en l'occurence) et pas l'iSCSI. On pouvait monter à pleine capacité réseau quand ça générait peu d'IOs (pour des opérations sur des gros blocs par exemple) -- Cyril Bellot France Teaser ___ FRsaG mailing list FRsaG@frsag.org http://www.frsag.org/mailman/listinfo/frsag
[FRsAG] Re: Performances NFS désastreuses
On 12/01, Julien Escario wrote: > Et j'ai un nombre plutôt importants de threads NFS : > RPCNFSDCOUNT=128 Ça ne fait pas un peu trop ? Ici nous avons constaté des grosses baisses de performance sous forte charge si on augmente trop le nombre de threads. Pour trouver la valeur optimale, il vaut mieux partir de peu et augmenter : nfsd râle quand il a trop de connexions ouvertes. -- Cyril Bellot France Teaser ___ Liste de diffusion du FRsAG http://www.frsag.org/
[FRsAG] Re: Performances NFS désastreuses
On 12/01, Julien Escario wrote: > Le 12/01/2011 19:34, Cyril Bellot a écrit : > >On 12/01, Julien Escario wrote: > >>Et j'ai un nombre plutôt importants de threads NFS : > >>RPCNFSDCOUNT=128 > > > >Ça ne fait pas un peu trop ? > >Ici nous avons constaté des grosses baisses de performance sous forte > >charge si on augmente trop le nombre de threads. Pour trouver la valeur > >optimale, il vaut mieux partir de peu et augmenter : nfsd râle quand il > >a trop de connexions ouvertes. > > J'avais justement un doute ... > J'ai réduit à 32 et rien de mieux pour le moment. Nous n'avons jamais eu besoin de dépasser 16. Tu as déjà des messages dans tes logs du style : increase the number of threads ? Commence peut-être par regarder la charge et les IOs (iostat -x 3) du côté serveur pour voir si ton device est au taquet ou non quand c'est lent; s'il ne l'est pas, laisse tourner nfsstat pour voir le type d'opérations qui te prennent de la ressource -- Cyril Bellot France Teaser ___ Liste de diffusion du FRsAG http://www.frsag.org/
[FRsAG] Re: Performances NFS désastreuses
On 12/01, Julien Escario wrote: > >Nous n'avons jamais eu besoin de dépasser 16. Tu as déjà des messages > >dans tes logs du style : increase the number of threads ? > > Ca ne me dit rien. Ce qui m'a fait augmenter le nombre de threads, > c'est la ligne th dans /proc/net/rpc/nfsd > Le dernier chiffre n'est pas zéro ;-) Ce n'est pas gênant que 100% des threads servent. Tant que le nfsd n'est pas en permanence à 100% d'utilisation de ses threads (un graph munin des sondes de bases est train bien fait pour suivre ça) > >Commence peut-être par regarder la charge et les IOs (iostat -x 3) > >du côté serveur pour voir si ton device est au taquet ou non quand > >c'est lent; s'il ne l'est pas, laisse tourner nfsstat pour voir le type > >d'opérations qui te prennent de la ressource > > Alors précision : c'est toujours lent ... > Par contre, les I/O sont quand même assez hautes, oui fréquemment > autour de 40% et le premier iostat me donne un iowait à 29,46%. > > C'est beaucoup non ? (je n'ai pas d'autre filer sous la main pour > faire une comparaison). > > Ceci dit, même si c'est élevé, je trouve étonnant que ca puisse > dégrader les perfs à ce point là. À priori ce n'est pas ton matériel qui limite, sinon tu le verrais souvent à 100% (ça arrive aussi avec des drivers mal fait) Regarde la répartition des IOs nfs. nfsstat donne aussi des mesures côté client. -- Cyril Bellot France Teaser ___ Liste de diffusion du FRsAG http://www.frsag.org/
[FRsAG] Re: Diagramme réseau/archi/logique
On 19/07, Marc Millien wrote: > Dia avec les bons "shapes" ;) > http://gnomediaicons.sourceforge.net/ > Il est également possible de télécharger les icônes cisco: > http://www.cisco.com/web/about/ac50/ac47/2.html > Et pour les baies: > http://dia-installer.de/shapes/central_data_processing/index.html.en Il y a les OSA aussi : http://www.opensecurityarchitecture.org/cms/library/icon-library/ -- Cyril Bellot ___ Liste de diffusion du FRsAG http://www.frsag.org/
[FRsAG] Re: DELL R320 & Debian squeeze
Hello, On 05/11, Yoann QUERET wrote: > Je viens de recevoir un DELL R320 (nouvelle gamme "12g"de serveur). > > Je galère pour installer une debian squeeze principalement a cause > des chipset réseaux et de la carte controleur. > > reseaux : Broadcom BCM5720 (Ok avec le kernel3.2.0bpo ou wheezy) > controleur : PERC H310 mini (LSI ?) (Ko sur wheezy, Ok sur CentoOS6) > > C'est encore plus galère que je risque d'en avoir pas mal, et que > pour le momment, l'install via PXE s'arrete au momment de la > detection des interfaces réseaux. > > Si vous avez des tuyeaux ... je suis preneur. Même chose ici avec du R720. On a modifié nos installations pxe pour y mettre un kernel 3.2 bpo. Pas de soucis de fonctionnement avec. -- Cyril Bellot France Teaser ___ Liste de diffusion du FRsAG http://www.frsag.org/
