Bonjour,
 
Savez-vous s'il est possible d'avoir un serveur miroir sur une machine différente ?
 
Par exemple, j'ai une machine Athlon bidule 2.6Ghz 512Mo 120Go et une autre PIV3Ghz/1Go/2x160Go.
Les deux sous Debian etch (par exemple).
 
Le but étant de faire des tests sur la première puis de passer sur l'autre très rapidement quand c'est ok. Ou encore pour de la redondance, si la machine plus puissante tombe, je passe sur l'autre (ici, on aurait donc une réplication temps réel, type raid over ip).
 
Merci.

CARP.

Edit: si tu veux du fail overt sur de l'IP pour des disques, il faut voir des technologies comme NFS4 avec les replicators, ou du SAN (iSCSI, et si t'es riche, du fiber channel).

Edit 2: voir aussi du clustering, avec heartbeat.

DRBD est exactement ce que tu cherche:
 
www.linux-ha.org
www.drbd.org

Je ne suis pas riche, c'est bien une solution du pauvre que je cherche
Et ce n'est pas vraiment de la redondance HD que je cherche (sinon j'irai d'abord sur du simple RAID) mais la possibilité de faire tourner deux machines distinctes.
 
Pour drdb, je connais et c'est là que j'ai lu pour la première (et unique ?) fois le terme de raid over ip.
Mais je n'ai pas compris jusqu'à quel niveau on descendait dans le mirroring.
 
Est-ce que je duplique le système vraiment complet (donc impossibilité de faire ça sur des machines virtuelles, du Xen ou autre), toutes les données et la config système (mais comment est-possible entre deux système et surtout deux config disque différents ?) ou simplement des répertoires/partitions que l'on choisi ?
 
Merci.

DRBD te permet de répliquer une partition en temps réel; c'est-à-dire que la donné sera considéré écrite sur le disque seulement lorsqu'elle le sera sur les deux machines. Ce n'est pas une solution qui permet de cloner deux machines. Par contre tu peux très bien utiliser la virtualisation pour le faire. Tu installe Xen ou VMWare sur les deux machines et tu place ta machine virtuelle sur la partition DRBD. Si le noeud actif (machine physique) plante, heartbeat le détecte et redémarre la machine virtuelle sur le noeud en standby (la deuxième machine physique).
 
http://howtoforge.com/vm_replicati [...] ebian_etch
http://www.howtoforge.org/ganeti_x [...] ebian_etch

Merci, c'est très intéressant. Il faut donc que le lien entre les deux machines soit très rapide pour du DRDB, sans quoi le moindre accès disque sur une partition clonée sera très lent ?

Par contre, si je suis dans le cas d'un serveur virtuel dont je souhaite un miroir (sur un autre virtuel ou sur un "normal" ), sans pouvoir contrôler le serveur réel (donc sans pouvoir accéder à la partition de ma machine virtuelle), quelle solution je peux appliquer ?

Proposition : si je rsync tout à chaque modif réelle (j'entends par là : pas pour des modifs sans conséquence comme un updatedb ou un aptitude update) et que rsync très souvent les répertoires plus sensibles (web, mail, stats, log), ça te semble réaliste ?
Ce qui me fait peur avec ce que tu dis à propos de DRDB, c'est la latence qu'il pourrait y avoir pour des écritures SQL ou des mails : 50 utilisateurs sur MySQL, 70 qui consultent leurs mails en pop ou imap (webmail), ça fait un paquet d'écritures. Si le serveur attend que tout soit dupliqué pour considérer que c'est écrit, le plupart des serveurs (SQL, SMTP, etc.) vont super ramé, non ?

IL faut surtout qu'il soit sans trop de parasites, avec un bon temps d'accès et un débit correct.

Typiquement, du Gigabit fonctionnera très bien, tu satures aisément un ordinateur et son bus ATA en I/O avec du gigabit sans souci.

Miroirs qui tournent en même temps ou pas?

Si tu veux un miroir parfait de chez parfait, tu suspends une VM Xen, tu copies le fichier, et tu relances la VM en question sur deux machines physiques distinctes (et donc, deux dom0 différents).

Mais attention, c'est pas vraiment du miroir pour du failover, c'est juste un bête miroir, sans mécanisme de gestion du failover ou de synchro...

Pour moi non, si tu utilises des bdd, tu peux avoir des surprises. Et rsync, entre le listage des fichiers et leur copie éventuelle, tu peux avoir des modifcations faites sur lesdits fichiers qui feront que tu n'auras jamais une cohérence parfaite entre deux postes. C'est pour ca qu'on fait du raid.

Rsync est bon pour répliquer des données qui ne sont pas en cours d'accès, uniquement. Ca n'est pas le cas des logs.

Faut benchmarker. Ca dépend de beaucoup trop de facteurs.

J'ai plusieurs centaines d'UPDATE sur un bi opteron ici sur une base postgresql par minute, sur de l'iSCSI. Ca passe sans aucun souci.

Oui bon, je vais préciser puisque tu sembles croire que je suis richissime.

Il y a vraiment bcp de monde qui utilise le raid over ip avec du Gigabit ?
En aucun cas j'aurai du gigabit (sinon je n'aurais même pas posé la question !)

Soit ça fait du load balancing (et forcément, si une meurt, tout va sur l'autre), soit du fail over (tout sur le machine la plus puissante, on passe sur l'autre en cas de crash), soit du rien du tout (miroir temps réel mais il faut copier le disque de la machine - si problème disque - ou changer les DNS - si problème machine - donc bcp de temps avant que ça reparte).
Et je rappelle que je ne peux pas malheureusement pas manipuler la VM.

Et unison ? ou d'autres que je ne connais pas ?

Si j'avais un bi-opteron et du gigabit entre eux, je ne me poserais pas la question.
Mais là, le but est d'avoir de la redondance sur de tous petits serveurs et pouvoir faire cette redondance en plusieurs points (donc tu penses bien que la liaison gigabit...)

C'est assez courant le gigabit aujourd'hui. Les cartes ethernet qui valent plus de 15€ sont 10/100/1000.

Edit: pour avoir les idées claires, imagine ce que tu veux faire. Si tu as besoin de garantir ce que tu dis au niveau des blocs physiques (comme les blocs sur les disques durs), sans argent, point de salut. A voir si tu as les capacités pour utiliser DRBD.

Si tu veux avoir des sécurités au niveau d'un système de fichier (et plus à avoir à exporter le stockage sur le réseau), il faut te tourner vers NFS et CIFS. Dans ce cas, tu places la barrière ailleurs, donc tu dois traiter le problème ailleurs: en blindant la machine qui héberge le service.

Si tu veux avoir des sécurités au niveau des services, c'est CARP, VRRP + mécanismes offerts par le service en question (Slony chez postgres par exemple).

Tu veux beaucoup de choses en un coup. Le seul souci, c'est que ca ne fonctionne pas comme ca.

Tu as le clustering, mais il faut que le service s'y prette, et en plus, il te faut l'architecture derrière. On peut mettre en place des clusters avec trois fois rien, mais il faut être bon techniquement (NFS, heartbeat et co).

Pour de la redondance de service, tu as CARP. Ca peut faire du load balancing je pense aussi, même si j'ai jamais essayé.

Exemple typique: tu blindes tes services, mais ton serveur NFS tombe... C'est fini. Tu veux faire de l'espace de stockage sur de l'IP avec failover? C'est de l'iSCSI. Tu peux faire à peu près la même chose avec NFSv4, mais bon courage pour le mettre en place, ca reste de la bidouille.

Unison repose sur le protocole rsync. Si tu veux avoir une parfaite synchro, il te faut un protocole capable de travailler au niveau des blocs de données directement, ce qui implique que l'OS doit aussi contribuer à l'ensemble. Donc, exit tout système qui repose sur des outils purement userland.

Même les dell de moyenne qualité pour du desktop ont du gigabit. C'est loin d'être inaccessible.

Pour faire du raid sur de l'IP, ca demande une architecture spécifique. Si tu n'as pas les moyens comme iSCSI, tu mets un serveur NFS, et tu blindes la machine en protection (raid local).

Tu peux tenter DRBD aussi, mais il faut te documenter un peu.

J'aurais du être clair dès le départ (je pense toujours l'être, mais en fait, j'au du mal à résumer en quelques phrases ce que je veux dire en 2 pages).
 
Pour le gigabit, oui je connais (quoiqu'avec une carte à 15euros, tu feras difficilement du giga constant, même en cat6) mais je parlais du cout du giga *par internet*. Tu connais du monde qui a une LS (ça doit plus existait mais bon) de 1Gb ?!
 
Quand j'évoque LB, redondance, etc. c'est pour dire : n'importe laquelle de ces solutions du moment que c'est réalisable sur le net.
 
Le contexte est le suivant :
 
- j'ai un micro serveur (type kimsufi/dedibox) ou un dédié virtuel.
 
- je souhaite que, si mon serveur tombe (surtout le disque), je puisse absolument tout récupérer au plus vite. Idem si un patch (jamais arrivé sur une Debian stable mais bon...) bloque mon système.
 
- tout = pas besoin de réinstaller le système, le reconfigurer, recréer les comptes et, bien entendu, ne pas perdre les données.
 
- pourquoi tps réel partiel (j'avais dit que, à la rigueur, seul certains répertoires devait être répliqué en tps réel) ? Parce qu'une conf de postfix ou de apache ne change pas toutes les 2 minutes (sur mon serveur en tout cas), ni une structure de site web.
 
- par contre, je peux imaginer perdre 10 minutes de mail mais pas plus. Pas forcément du temps réel donc, mais ce serait l'idéal pour les mails, et bien pour les logs et SQL (sur ce dernier, j'imagine que le tps réel est complexe).
 
 
Je peux me permettre quelques minutes, voire une heure (si le serveur tombe vraiment, ce qui n'arrive pas tous les mois) de coupure. Mais pas de perdre des données et pas de dépasser cette heure limite.
 
Voilà pourquoi je considère un peu toutes les solutions existantes.
Je pensais à du rsync mais, comme tu dis, pour les fichiers ouverts c'est peut-être pas terrible.
Pour les mails, tout simplement faire du forwarding sur un second serveur, mais je ne vois pas comment faire ça.
 
En fait, l'idéal serait un deamon qui surveillerait certains répertoires (j'utilise le format maildir, bien plus pratique même si plus lent pour mon cas) et copierait les nouveaux fichiers ou fichiers modifiés (pour les config) instantanément.
Quant aux logs et à SQL, se contenter peut-être d'un copie (mais comment puisque tout cela est locké ?) toutes les 5, 10 ou 15 minutes.  
 
Qu'est-ce que "des outils purement userland" ?
 
Pour l'instant, j'imagine (et teste), une solution à base de dédié virtuel. Mais j'avais aussi imaginé 2 dédiés : un "normal" et un pourritos (dediboxkimsufi).
 
Si tu as des idées, des pistes, en espérant que mon but soit clair ...
 
Merci.

- Carte à 15€, sans souci, c'est le switch à l'autre bout qui va trinquer.
- je doute que tu consommes de l'I/O à plein pot sur un lien Gb sur tes serveurs. Ou alors, tu dois déjà avoir du SCSI ou du SAS pour tenir une telle charge.
- tu n'as jamais fait mention que ton système de miroir devait se faire via le réseau Internet. Par défaut, on considère que c'est local.

Récupérer quoi? Avec quelles contraintes de temps, de délais? Sauvegardes incrémentales, ok? Pas ok? L'uptime à garantir, c'est quoi? 95%? 99%? 99,9%?

Ben sauvegardes régulières. Si tu veux un truc plus costaud, soit tu te plonges dans DRBD, CARP et tu lis des docs:
http://www.linux-ha.org/
http://www.linux.com/articles/35482

soit tu fais appel à de la prestation. Pour ce que tu veux, tu n'as pas de solution clé en main, qui va tout faire, même le café. C'est une combinaison de protocoles et technologies, et ca sera pareil du coté propriétaire aussi (je fais fi des blablas de marketeux bien évidemment).

Ben oui, mais on prend le plus petit commun multiple . Si tu veux du miroir en temps réel, partiel ou pas, ca sera du miroir en temps réel. Le fait que tu ne le fasses que sur certaines arborescence ne simplifie pas la chose...

Solution du pauvre: DNS round robin
Solution plus technique: VRRP/CARP

L'instantanéité, ca n'existe pas ici. D'ou la complexité des protocoles. Pour une simple raison: pour qu'un daemon puisse voir les modifs sur le fs, il n'y a que deux possibilités:
- soit il fait du polling (actif ou passif), dans ce cas, l'opération ne sera _jamais_ atomique au niveau du fs, de part les multiples changement de contextes.
- soit il controle toute l'information des écritures disques: c'est ce que font les daemons de bdd comme postgres, mysql, oracle...

Les logs, ce sont la tes moindres soucis. Un syslogd bien configuré sait faire ca très bien, rebalancer les logs ailleurs...

Des outils qui tournent en userland, c'est a dire dans un mode non privilégié. A distinguer du kernel land, qui lui est privilégié. Les deux communiquent via des appels systèmes, et c'est une opération non atomique au regard du kernel.

Ca n'est pas clair, car tu n'as pas qu'un seul but. C'est un condensé de technos que tu dois utiliser, il n'y en a pas une seule qui suffit pour tout faire. Donc commence à petit pas, en distinguant:
- la problèmatique de stockage
- la problèmatique de services (== redondance de daemons)
- la problèmatique de sauvegarde (qui n'est pas la même chose qu'un raid, un raid n'est _pas_ là pour éviter les sauvegardes)

Si déjà c'est plus clair à ce niveau, ca sera un beau progrès.

 
Récupérer un serveur disponible avec les données !
Je n'ai pas vraiment d'uptime à garantir. Comme je disais, l'essentiel est que la coupure ne dépasse pas grand max 1 heure (et, bien évidemment, que ça se reproduise rarement, mais ça, il n'y a pas de raison - il n'y en a pas eu jusqu'à maintenant -).
Donc 5 minutes pour un serveur qui remédarre, je m'en fous, mais en moins d'une heure (idéalement en - de 30 minutes), je doute avoir le temps de  réinstaller un serveur avec toute la config (serveur web, comptes smtps, pops et imaps, ssh, ftp, iptables, fail2ban, mrtg, etc.) et les données du serveur d'origine.
 
En fait, ce n'est pas la peur de perdre les données dans l'ensemble (un rsync par jour dans la nuit sur mon serveur local et un RAID 1 suffiront largement pour mon usage) mais plutôt de mettre des heures (voire des jours, l'horreur !) à avoir un autre serveur en place.
 
J'aime bcp le concept de drbd (je ne connais pas CARP, je vais aller voir, et il faudrait que j'aille voir du côte de enbd), mais je doute du résultat sur un lien moyen débit.
 
Je me fourvoie alors peut-être complètement, mais je pensais que drbd utilisait mon de BP si le contenu à dupliquer est faible. C'est pourquoi je voulais donc limiter le mirroring temps réel
 

 
Heu non, je pensais encore plus simplement à un forwarding des messages : chaque mail reçu sur le serveur1 est envoyé sur le serveur2. Le problème, c'est que l'on forward du compte à un autre, différent. Donc je cherche comment je pourrais, lorsqu'un mail arrive sur S1, le faire copier vers S2 (sans donc utiliser un processus lourd tel que rsync ou drdb).
 

 
Ok, le tps réel requiert donc que l'on travail à plus bas niveau, donc drdb, endb.
 

 
En fait, si la diffusion des DNS se faisait en quelques minutes, j'aurais moins de problème.
J'ai vu que OVH proposait des IP fail-over, ce qui est très intéressant (pourquoi les autres ne le font pas ?).
Mon problème est hybride dans la mesure où il pourrait ressemble à du HA mais n'en est pas.
Tu dis que le RAID n'évite pas les backup, certes, mais dans mon cas, il est une partie de la solution. Car s'il ne les évite pas, il en est une (de sauvegarde) ; c'est une redondance HD, point. Vu mon cas, si les deux disques tombent en même temps (je sais, ça arrive parfois si HD de même série) , on met ça dans les cas exceptionnels. En parallèle, j'ai un backup quotidien des bdd et sites, et je vais ajouter les rép mails. Ainsi, dans le cas rare ou les 2 HD sont down, je perds au pire 23h59m de données. J'en suis pas à faire du RAID5 sur 5 disques.
 
Bon, merci pour tes messages, je vais voir ce que je peux faire. Me renseigner sur la BP min pour drbd, voir un peu enbd aussi.
Sinon, je vois en lançant un rsync global quels sont les fichiers qui posent problèmes et savoir s'il sont capitaux. Si c'est la cas, voir si je peux interrompre leur accès un court instant.

 
C'est pour ca qu'on utilise plusieurs machines, ca réduit d'autant le risque de panne.
Et des machines virtuelles aussi. VMWare ou Xen.
 

 
Si y'a un socle technique normalisé avec de la doc écrite, ca prend pas longtemps.
 
Avant de penser à faire du clustering, amha, autant commencer par là: faire de la doc. Réinstaller un serveur web si on a la doc, ca prend 5 min.
 

 
Ce sont des technos de clustering en local (comprendre: sur un même sous réseau, on avec très peu de hops).
 
Par le nain ternet, même pas la peine d'y penser: entre 100 et 200 ms de latence, c'est l'horreur.
 
Juste pour te donner une idée, essaie déjà de voir ce que donne un NFS/CIFS sur réseau internet, ca te donnera une idée des perfs auxquelles il va falloir t'attendre.
 

 
Utiliser des alias?
 
=> man newaliases
 

 
Par sauvegarde, on entend backup des données. Le RAID n'est pas une solution de backup de donnée, c'est uniquement matériel: failover et/ou perfos.
 

 
Et c'est de l'incrémental comme sauvegarde? Rotatif? Parce qu'on peut voir ca autrement: tu ne peux revenir en arrière que de 24h. Ca peut être emmerdant quand ce délai est dépassé et qu'il faut restaurer...
 

 
Bon courage.

 
Je suis entièrement d'accord et c'est bien pour ça que j'ai commencé à le faire. Mais ça ne change rien au problème des données : si les données sont sur S1, soit les 2 serveurs sont chez le même prestataire et il faut alors qu'on me réanime S1 (donc aucun intérêt d'avoir un second serveur), soit ils sont chez deux prestataires différents, ce qui préférable pour la redondance, et je n'ai aucun moyen de récupérer les données.
Bref, en documentant parfaitement, je suis capable de remonter mon serveur relativement rapidement (on va dire qu'on compile rien donc) mais je dois toujours trouver un moyen d'avoir une copie très récente de mes données.
 

 
Putain c'est con ! Je n'y avais pas pensé ! Cool    
 

 
Ah non, je déteste ça (j'ai toujours peur de m'y perdre au restore) et vu les volumes et les diff quotidiennes, je fais un full avec versioning.
Le problème (et c'est pour ça que je cherche), c'est que je ne connais pas d'outils sous linux pour faire la même chose. rdiff-backup peut-être ?  
 

 
Chiffres?
 

 
Amanda?

 
De ? Du volume ?
Quelques bases MySQL (migration vers des posgre pour certaines) allant de quelques Mo à une cinquantaine de Mo pour la plus grosse (on arrivera à 100Mo grand grand max).
Et une dizaine de sites qui font de quelques Mo à une centaine de Mo (les "gros" sites ou des galeries de photos).
Pour les diff quotidiennes, rien à quelques centaines de ko pour SQL et quelques centaines de ko (voire quelques Mo) pour les sites (modifs de photos).
On met les mails à part (là, y'en a qui bouffent 250Mo par compte).
 

 
Oula, j'avais déjà entendu ça y'a presque 10 ans ! Ce n'est pas une usine à gaz ?

j'utilise ce genre de trucs avec rsync pour le moment (syncro à la main...)
mais j'ai entendu parler d'unisson qui pourrait faire des syncros d'après les dates de modifications des fichiers

 
Ah ouais d'accord, c'est une toute petite volumétrie Je pensais que ca tournait dans le Go voire To...
 
Plutot que de faire ca niveau du fs, je ferai ca avec des scripts maison rsync pour les fichiers de conf, et les fichiers à géométrie variable de bdd, une bête réplication (genre slony-I)... Si jamais ca demande des modifs de conf fréquente, se tourner vers cvs/svn, et faire un miroir de l'arbre.
 

 
Certainement pas plus que ce que tu envisageais au départ avec du miroir temps réel de disques sur IP.

 
Je ne m'amuserais pas à jouer à l'économie si je gérais des tera de données !
Par contre, si le giga est possible prochainement, ce sera du stockage de documents, donc aucune difficulté technique.
 
Le problème majeur pour moi est, je le rappelle, la possibilité de maintenir deux serveurs identiques du point de vue de la configuration *mais pas forcément du matériel*. Ca reste quand même délicat et on a peu à peu dérivé vers la backup de données, ce qui est le moindre de mes soucis (car c'est simple) dans cette histoire.
Donc, pour résumer :
- j'installe un autre serveur.
- qd je fais une modif système sur l'un, je dois faire la même sur l'autre, manuellement. C'est pas top, mais pas trop long, donc ça va.
- pour les fichiers conf, les logs, les données, un rsync ou équivalent
- pour les mails, faire un forward de tous les comptes sur des comptes "miroir" placés sur l'autre serveur. Et alias du premier compte sur le second pour basculer. L'idée semble bonne mais en y réfléchissant, faudrait déjà pouvoir l'automatiser (sinon c'est vraiment galère et risques d'oublis) et le basculement est également plus que hasardeux : si S1 tombe, je passe sur S2, donc toto@foo.bar est toujours up, mais le contenu de cette boite sera sur toto_foo_bar@miroir.bak donc il faudra vider le contenu de cette dernière sur la première. Ok pour une adresse, très long ou gros travail de script pour automatiser ça.
- pour le basculement rapide, aucun solution. Or le soucis était là. Soit j'ai un hébergeur qui fourni une IP fail-over (je n'ai vu que OVH), soit ce sont des heures d'attentes de propag DNS. Sauf si Heartbeat permet de ne gérer que le changement d'IP...
 

 
Tiens... Pour moi cvs c'est pour le dev, je n'avais pas du tout pensé à utiliser ça pour de la sauvegarde.

Shell scripts.

Shell scripts.

Ca peut se configurer ca. Si tu veux que S1 tombe et que plus rien ne passe sur S2, tu garderas un système cohérent entre S1 et S2, mais plus de redondance de service SMTP... Voila, on en retourne à mes remarques au dessus.

Dans ce cas, t'auras juste une copie de sauvegarde. Attention cependant aux pannes prolongées sur S2.

Ca se fait sans problème avec des connaissances en shell scripts et des mails stockés au format maildir.

Heartbeat gère le changement d'IP, mais au regard de ton infrastructure. Ca ne résoud pas les problèmes pour les IPs accessibles de l'extérieur, il faut attendre les propagations DNS et l'expiration des caches client.

VRRP/CARP est justement fait pour ca.

CVS n'est pas pour la sauvegarde ici, il n'implémente aucun mécanisme de ce genre intrinsèquement.

C'est juste un versioning efficace de configurations, opérations d'administration (changement de config, modif d'un arbre LDAP...).

CVS/SVN ne sert pas que pour du dev (cf son nom). Il fut un temps ou je gérais les opérations dans un arbre LDAP avec CVS, ca me permettait de savoir qui, quand et quoi m'avait demandé telle opération tel jour telle heure, sans avoir à me piffrer un log book de 350 pages, ou une archive de 2500 mails, alors qu'en 10s avec CVS, je retrouvais l'info. Et dans une certaine mesure, faire du rollback.

Ca sera à toi de mirrorer l'arbre CVS pour gérer ça...

Bon, je vais digérer tout ça. C'est la fête du script !
 
Par contre, je vois mal comment je peux scripter des commandes que je réalise sur un serveur en ssh. Aucune envie de mettre un mot de passe avec privilèges en clair !
Par exemple, je fais un aptitude upgrade (je suis sympa, j'aurais pu compiler un truc), je vérifie que c'est ok ; c'est bon donc je veux la même chose sur S2. Je ne vois pas comment scripter ça (mais c'est pas trop grave).
 
En tout cas merci pour le temps passé à répondre à mes messages. Je vais lire un peu à propos de CARP (UCARP apparemment sous linux) qui semble très intéressant.

 
Clés RSA. man ssh-agent, man ssh-add, man ssh-keygen.
 

 
Méthode stupide: reproduire exactement les mêmes commandes?
Méthode un peu moins stupide: savoir ce que l'on fait, donc demande une bonne connaissance d'un système unix?
Méthode plus chiadée: utiliser le gestionnaire de package?
 

 
A oui, pour nunux, obligation d'être en userland. "Évidemment" je dirais, VRRP/CARP n'est implémenté que sur des OS dignes de ce nom

Pour les clés RSA, en cas de compromission de S1, S2 y passe : super.
Certificat + passphrase (+ controle ip et mac avec un fail2ban comme il faut, car même s'ils sont faciles à usurper, encore faut-il savoir quelle identité prendre) = ok. Donc toujours problème de mot de passe.
 

 
En quoi l'utilisation du gestionnaire de package solutionne-t-il le problème ?  
 

 
Debian (stable) n'est pas un OS digne de ce nom ? Ne penses-tu pas que c'est l'administrateur qui fait une bonne partie de la qualité de l'OS (j'ai bossé sur W2K3 pendant quelques années, dans une grosse boite qui gère bcp de sous et de transactions, avec un intranet et un site public, je n'ai *jamais* eu le moindre soucis - une fois une panique à cause d'un débordement pour une faille MSSQL je crois -).
Nessus d'un côté, snort, cacti, nagios, bcp de snmp, iptables (sur un OS pas digne de ce nom donc, puisque slackware minimale) de l'autre.
Etait-ce grâce à W2K3 ou à ma plateforme sous linux (et bien sûr les switches qui encaissaient parfois quelques tempêtes et le solide routeur Cisco) ? Un peu tout surement.

 
Ah bon, et pas avec les mdps? Un mot de passe différents sur chacun?
 
Ok, alors mets un jeu de clés différents sur chacun...
 
Sinon, commencons proprement, quelques lectures qui te seront amha très utiles:
 
man ssh-add, man ssh-agent, man screen
 

 
Super. Moi je te réponds: certificat fait maison + fail2ban = man in the middle.
 
Sans compter que fail2ban à ses limites aussi: le filtrage par IP, en 2008, avec les NATs en plus, c'est vraiment un tir dans le pieds. Même Kerberos a laissé tombé le filtrage de tickets par IP. Si sshd ne le met pas en place par lui même, c'est pour une bonne raison.
 

 
Parce qu'il gère le versioning, l'installation et la suppression proprement, bien plus qu'un make install des familles? Les conflits aussi?
 

 
Pas suivant mes idées, non. Elle mélange paquets service et paquets système, donc si on met à jour le système, risque de casse élevé. Les anciens qui ont passé Linux du format a.out au elf s'en souviennent encore, et debian n'a rien arrangé à la chose. La montée des glibc est toujours aussi flippante avec cet OS, chose que je n'ai jamais eu sous un Net ou Free (mergemaster et postinstall, apt a du mal...).
 
Mais bien sur, y'aura toujours quelqu'un pour contredire et dire que c'est mieux. Chacun son point de vue.
 

 
Un bon ouvrier avec de bons outils. L'un sans l'autre, sans ordre de priorité.
 
Ah si peut être, avec windows, administrer un parc sérieusement revient à acheter des solutions clés en main qui coutent bonbon, ou à installer 36000 freewares/sharewares/logiciels libres pour en compenser sa médiocrité administrative. Donc je considère que c'est un OS à qui il manque par défaut pas mal d'outils: joker pour celui là, il est hors course.
 

 
Moi je gère le SI d'un gros site privé, avec un intranet de ouf, des transactions et un uptime de 99,999%. Y'a pas un seul windows. Chercher l'erreur?
 
Cherche pas, j'aurais aussi toujours la plus grosse à ce jeu là

Concernant la sécurité, tu prends un peu ce qui t'intéresse dans mes propos. Et il est aussi vrai que l'on entend souvent dire, *parfois* à juste titre, que le ban d'IP est inutile.
Tout comme snort était inutile quand je l'utilisais. Et cacti bouffait du cpu.
Le ban d'IP est très efficace. Problème avec le NAT ? Ouah ! Imagine la catastrophe : un coréen (bon allez, un gars très très doué - ironie - qui passe par un zombie coréen) qui tente 15000 fois par minute de venir te voir. Je le bloque. MON DIEU !!! J'avais pas vu : j'ai aussi bloqué ma mamie et son frère qui partage d'accès !
Soyons sérieux : fail2ban (et autres régles iptables - ou ipfilter si ce n'est pas digne -) se configure et bloquer une IP qui tente 3 accès dans la même seconde, pdt 2 minutes, ça ne fera aucun mal à mémé et ça allegera ton serveur (et les logs !).
Idem pour snort, même si tu n'en parles pas. Un snort mal configuré, personne ne passe et le CPU est en pleine charge. Une arme très facile à retourner contre son propriétaire. Mais bien utilisé, c'est allège considérablement stress (du CPU et de l'admin).
 
Pour les pass, je n'ai bien évidemment *en aucun cas* dit que cela suffisait. Mais la base me semble être certificat + mdp.
Tu n'aimes pas la vérif d'IP et de MAC@ ? Pourtant c'est une protection qui ne coute rien et renforce largement la sécurité. Même en interne puisque l'arp spoofing, ça se détecte (très) facilement.
Alors MiM, parfois ça me fait bien marrer. Tant qu'à faire, il utilisera ICMP redirect, c'est ça
Bon, trêve de déconnades, explique moi comme un méchant va faire pour récupérer gentillement (ou pas) mes clés (on se fout de la taille dans ce cas, mais les miennes font 4k je crois) et mon mot de passe. Pas théoriquement : je sais très bien ce que sont les attaques MiM, mais dans les faits. Il opère comment ?
 
Bon, pour ssh-*, j'utilise déjà cela comme je le disais aussi.
Par contre pourquoi tu me parles de la donc de screen ? Qu'est-ce que je peux faire de particulier avec ça (je veux bien aller voir le man, mais comme j'ai aussi un peu l'impression d'être pris pour un gros benêt, j'aimerai savoir où est l'intérêt) ?
 
Quant aux gestionnaire de packages, ça confirme un chouia ma crainte ci-dessus, mais bon, pas grave, j'ai l'habitude avec les unix-users (quoique windows aussi)... Bon bref, je n'utilise plus make (sauf si nécessaire) depuis longtemps, mais si j'ai résisté. J'utilise apt (aptitude, pratique pour le classement) et je ne vois toujours pas en quoi ça règle le problème de synchronisation des systèmes sur les 2 serveurs. Me suis taper la doc "par ta faute" en espèrant qu'il existait un mécanisme de synchro des packages ! Que nenni !
 
Bon, pour les *BSD, c'est pire que les admin sous Win et maintenant sous Mac (forcément), donc je laisse la main. C'est un débat d'expert que je laisse à d'autres (qui ne sont jamais vraiment d'accord... et c'est leur problème.)
On ne compte pas le nombre de gros sites internet qui sont sous linux quoiqu'il en soit (et même sous IIS j'imagine).
Théoriquement, le modèle peut être discuté, mais dans la pratique, peu de différence au final.
 
Tu sais, entre le raindow tables surdimensionnées, les détections de temps de réponse pour faciliter le cassage de clés et autres possibilités très perfectionnées, je doute fortement qu'un bon admin soit plus sûr sous unix que linux. Il faut parfois être capable de prendre de la distance et considérer autre chose que le coeur du système. Même un CPU ça se compromet.
 
Pour ton truc sans win, il n'y avait que ça dans la boite où j'étais et un uptime identique, extranet mondial (c'est une multinationale), un nombre de requêtes qui, je te l'assure, à toutes les chances de dépasser très très fortement celle de ton site, aussi gros soit-il. Et seul mes 2 PC étaient sous linux... J'exagère puisque les dev étaient sous linux et une partie transactions aussi (enfin BSD, pour te faire plaisir).

 
Et tu fais comment si - comme dans la plupart des cas réels - la majorité de tes clients se connectent depuis quelques providers avec des ADSL à IP dynamique ?
Parce que ça allège peut-être tes logs, mais en perdant ne serais-ce qu'une infime partie de tes clients, c'est ton porte-sousous que tu allèges.
 

 
 
Peace

Si un de ces clients se retrouve avec l'IP bannie et tente de se connecter, et cela durant les quelques minutes du ban, ben il peut aller jouer au loto, parce que ca veut dire que le hasard est avec lui

Ou les statistiques si il se connecte via un réseau gprs/umts/...
Y'a plein d'applications ou tes clients se retrouvent dans un range d'ip très limité.

C'est comme le filtrage des paquets icmp: inutile et néfaste.

Puis, c'est facile de faire un DoS avec ces trucs de ban ip, et ça se contourne facilement avec des proxys ou un botnet

 
Si c'est pour utiliser fail2ban dans cette optique, autant le faire avec iptables.
 
Le loto n'a rien à voir la dedans non plus: forger des paquets existe depuis la nuit des temps. Ca serait même une des premières attaques, les antiques spoof sur les .rhosts reposent la dessus, pour contourner les protections qui vérifient l'adresses IP.
 
Si vraiment c'est pour dégager les attaques par brute forcing sur sshd, changer de port... C'est bien plus simple.

mouai... personnellement j'aime pas changer les ports par défaut... Autant utiliser la match recent pour ce genre de service. Ca calme rapidement les bots

Ah oui tiens, je vais bouger mon serveur SMTP sur le port 2525, y aura vachement moins de problèmes forcément

Ouais, c'est tous des emmerdeurs d'abord.

Port knocking is the mighty way  

Aucun souci.

Et surtout, n'oublie pas d'y mettre sshd à la place.

 
PasswordAuthentication no [/sshd_config]

Bon, finalement je n'ai pas (comme tjrs) d'exemple de Mim.
fail2ban et iptables, même combat au fait.
 
Pour le ban d'ip dynamique, très très drole : alors déja, le type, manque de pot, ça tombe sur LUI (le cooréen aura décidé de spoofer SON adresse parmis quelques centaines de millions) et ensuite, s'il est banni, je m'en fous royalement puisque mon client ne se connecte pas au serveur !
Donc, comme toujours, remarques vite fait, qu'on peut lire sur le net un peu partout...
 
Changement de port ? C'est une plaisanterie ? Pour qq un qui gère un gros site, c'est limite... (10 sec à quelques minutes avec nmap)
Le changement de port a un seul interet : réduire les logs.
 
Port knocking ? Voila qui nous confirme qu'on est en présence d'un relayeur de bonnes pratiques made in newbies-forum
C'est gentil le pk, mais ça n'élimine que quelques script-kiddies, pas plus.

J'ai du mal à saisir cette partie de ton post... Si c'est comme le reste, tu tentes de te mousser en cassant les éventuelles solutions que les personnes proposent, c'est ca ?

1. fail2ban se base sur les logs de /var/log/auth.log. Donc tu auras compris que la personne aura monter une session TCP entière (ie. il aura réussit à spoofer correctement les numéros de séquences et d'acknowledgment) ainsi que le handshake SSL (du moins pour SSH)... ce qui n'est pas permis à n'importe quel script kiddies.
Autant sur un LAN c'est éventuellement réalisable, autant sur Internet... c'est nettement plus compliqué.

2. pour la match recent, elle se base sur le statut des connexions TCP, donc tu auras à spoofer correctement la session TCP. donc plus basique que fail2ban certes mais ca fait très bien son office... suivant l'implémentation de la pile TCP de l'OS c'est plus ou moins facile.

La génération des numéros de séquence sur les kernel linux est très correcte. Sur un LAN, plus précisément, sur un meme lien réseau (en fonction de la sécurité mise en place sur le switch) c'est plus ou moins faisable, sur internet... c'est "légèrement" différent...

Ensuite, les tentatives de bruteforce sur du SSH sont généralement effectuées par automatisation. Ce genre de procédé sont efficace. Je (et bien d'autre personne qui lisent "autres choses" que des forum) l'utilise depuis plusieurs années sur un nombre conséquents de machine. A en croire les logs... c'est efficace, ou alors j'ai vraiment de la chance, ou bien l'intégralité de ces machines s'est faites avoir...

Tu mérites pas

Ah, je suis quand même un peu rassuré de voir qu'il y a quelqu'un qui a eu la même idée; la moitié des posts du topic (depuis la moitié en fait) sont trollogènes.

Merci d'être passé, et de m'avoir fait bien rire charlot

Heureusement que ta grande expérience vient me remettre sur le droit chemin

 
Heu mais vous vous foutez de moi ou quoi ? C'est un poisson de mai ?    
Je défends justement fail2ban que j'utilise !
Pour le bruteforce de ssh, je ne comprends même pas pourquoi tu me dis ça ! Tu veux m'expliquer quoi ? Que c'est facile ? Sans clés et avec un mot de passe de 3 lettres, c'est sûr, sinon, je ne vois pas. Et pour le port, je reste sur mes positions (mais je commence à penser qu'on ne lit pas vraiment ce que je réponds, ou alors très très vite et mal).
 
D'autre part, ma question portait sur de la redondance de serveur (question non complète puisque j'oubliais des critères importantes que j'ai précisé par la suite). Question à laquelle Gfx a pris du temps pour répondre - parfois un peu à côté mais c'est en partie à cause de moi - et je l'en remercie.
Quand il s'agit de sécu, je n'ai posé aucune question car les questions que je me pose sont hautement plus complexes et j'ai, je pense, suffisamment d'expérience dans ce domaine pour être relativement tranquille avec mon petit serveur (je m'en suis sorti avec bcp bcp bcp bcp plus gros, donc mes sites dont tout le monde se fout, ça devrait aller).
 
Des questions ?

Je t'en prie. Merci à toi (réellement, ce serait pas contre mieux si tu lisais plus correctement les réponses des autres : s'il est très sympa à toi de répondre, ça fait assez hautain de répondre sans prendre en compte les propos précédent - cf. make install, ssh-agent, etc. -).
Et bravo pour les arguments de dernière partie (apparemment la sécurité informatique n'est pas trop ton domaine mais merci pour le reste).

PS : comme je suis une merde à tes yeux d'expert, j'attends toujours une grosse leçon sur le MiM, sur l'utilisation de gestionnaire de paquet pour synchro sur 2 serveurs (pas vu dans la doc, ça doit être en... svn :> ), sur  

Malheureusement si, je suis le RSI de ma boite. Je sais à quoi m'en tenir avec fail2ban. Mais je suis trop incompétent pour savoir m'en servir, malheureusement

Amha, tu devrais te procurer le dernier MISC. Tu risques d'apprendre pas mal de choses. C'est déjà mieux que rien comme lecture, ou voir si tu as des connaissances qui pourraient te donner accès aux revues sécu mensuelles du CNRS.

Cordialement.