Reprise du message précédent :
Dommage   j'avais trouvé un truc intéressant en prod ... tant pis ... amuses toi bien et prépares les €€€ pour des solutions "plus commerciales"
 
Bon courage

1/ C'est un peu contradictoire ...  en plus à quoi vont vous servir les noms enregistrés dans le dns s'ils sont "imbitables" ?
 
2/ Le temps ?  parce que tu crois qu'en achetant une solution "toute faite",tout va marcher comme ça "out of the box" sans un minimum d'effort d'adaptation ? Et vous allez vous lancer comme ça sur 2000 postes, sans pilote préalable ?  Et tu parles de minimiser les risques ...    

Tetedeiench> avec des baux d'1 semaine tu peux te permettre que les mises à jour du DNS ne se fassent pas de manière dynamique le temps de remettre le master sur pied. Les DNS secondaires devraient avoir encore l'entrée dans le DNS si ils ne se sont pas synchronisé avec le master juste après que l'IP ait été virée.
 
Tu n'as pas besoin de redondance pour le DHCP parce que les bails cela sert à cela justement.
L'ordi boot et cherche le DHCP, pas de DHCP, si son bail est toujours valable il utilise l'ancienne IP

Si tu pouvais en faire profiter tout le monde ca serait pas mal  

http://www.net.cmu.edu/netreg/  
===> NetReg et NetMon    
Du bricolage ... ben voyons ...
Bizarement, eux aussi ont eu la même idée que moi  
Cé une base de données qui centralise toutes les infos et qui "attaque" les DNS et serveur DHCP  en retour ...
La différence avec ce que je propose ? C'est qu'ils sont allés plus loin encore ... C'est carrément la base avec un outil d'adminitration qui dicte qui a le droit de se connecter au réseau, ouvre l'accès à internet, etc ...
Qd on connecte une machine sur le réseau, on tombe sur une page où on doit décliner son identité ... si elle correspond à qqchose de connu, on a le droit d'accéder au reste du réseau  
Enfin bon, c'est de "la bidouille" ... faite par Carnegie Mellon  

maintenant il va etre grognon

Bookmarked  

idem

 
1/ Pourquoi seraient'ils imbitables ?
2/ On a JAMAIS dit qu'on allait pas faire de pilote, loin de là. Pilote, migration par paliers, tout est prévu. On ne veux juste minimiser les developpements persos afin d'avoir quelque chose de certes basique, mais totalement fonctionnel en un minimum de temps. Développer du script qui attaque une BDD, on a vu plus simple Et surtout, vu notre problématique, on peut s'en passer. La redondance coté DNS maitre est par exemple, après étude, un peu inutile vu la durée de notre bail, vu qu'on peut récupérer les MAJs loupées par le DHCP.
 
Dis mon papy, tu extrapoles à mort, la

 
Quand c'est fait par script ? oui tout a fait.
 
On ne veut pas DEVELOPPER un DHCP/DNS dynamique pour notre entreprise. On veut METTRE EN PLACE une solution. Si on doit payer des licences, on paiera, c'est pas le problème Mais pour le moment, un DHCPD et un Bind9 répondent totalement à notre problématique.
 
En gros : que quelqu'un développe ca lui même, teste, en fasse une solution à part, c'est son souci, et si il fait une tonne de tests, c'est son problème. Nous, on ne préfère pas bricoler, réduire au MINIMUM les risques, et donc, partir sur des processus éprouvés, testés, etc.
 
PS : une fois que la solution est mise en place, on va la sécuriser. J'ai voulu cela car pour diverses raisons, le projet a trainé à cause de cette étude sécuritaire... et comme toute solution de sécurité s'interface sur du DHCP/DNS standard, on va mettre ca en place, et ensuite, on va sécuriser la chose. Mes collègues sont persuadés que sécuriser juste le DHCP par adresse MAC c'est génial, moi je trouve pas, nan... et je suis justement là pour proposer le genre de solution que tu proposes ( j'avais vu une chose identique coté lucent, version plus aboutie, pour sécuriser l'accès au réseau ). Oublie pas que je suis pas dans une PME hein.

1/ Devines ...
2/ En qq lignes ça se fait ... enfin t'es ptet pas doué, aussi je comprends que tu ne veuilles pas t'engager sur ce chemin  
 
Enfin bref, bon courage ... la route et parsemée de Kinders  

 
1/ je ne devine pas non.
2/ Tu ne te rends pas compte des prérequis coté maintenabilité dans le temps, coté robustesse que l'on a,  et des délais que l'on a, ou quoi ?

On a l'exemple PARFAIT qui nous montre que ce que tu proposes est nul. Dans une société que l'on a récupéré, ce genre de solution était mis en place un peu partout, à la va comme je te pousse. Résultat des courses : on se retrouve avec des choses tellement bizarres, incompréhensibles, non documentées, et la personne étant partie bien loin depuis, que l'on doit tout casser et tout refaire.
 
Je ne veux pas tomber dans ce travers. Je peux rester clean, je peux éviter de développer de grosses parties moi même, je le ferai... c'est tout.

1/ Bon courage alors ...
2/ Les délais, ou j'ai pas lu, ou j'ai vu nul part dans tes posts ... mais bon ... tu crois quoi ? que la solution complète se déploie en un jour ? reviens sur terre le iench ...  Même pour un début, un DHCP + BIND "simples", ca s'installe vite ... mais vous allez vous amuser pour la configuration après vu vos contraintes .... Quant à la mise en place de la solution "cible", je sens des "surprises" ...
 
La maintenabilité ? Si tu achètes une solution existante, prends le contrat de maintenance qui va avec et surtout ne touches plus aux DNS et DHCP ... sinon cé cuit niveau contrat ... seulement, si c'est critique et que vous voulez des délais d'intervention genre H+4 ou H+8, vous allez banquer ... enfin bon, vous etes riches apparamment  

Vas y donnes l'exemple en question qu'on rigole un peu tiens    
Vous savez pas gérer des projets ou quoi ? Vous savez pas spécifier ? documenter ? recetter ?  
Faire de la MOA, ca vous dis qqchose ?    
 
La seule chose que tu nous prouves c'est que tu as pas compris où tu mettais les pieds ...
 
Bon courage, je te dis  

1/ c'est bien beau de me dire "c'est imbitable", mais si ca ne l'est pas, je ne vois pas. Nos noms de postes sont fixes et prédéterminés hein. On va pas les générer automatiquement. Et rangés dans une BDD accessible à tout le monde, mise à jour quotidiennement par outil d'inventaire.
2/ coté délais, avec mes autres tâches, je compte mettre en place un pilote fin mars ( j'ai un autre projet à faire avant). Ca me laisse 3 semaines de délai ( arrête d'extrapoler bordel ©® ). Ensuite, le pilote est mis en place ( test sur plusieurs semaines - à déterminer). Les tests de tombage de DNS et de DHCP seront faits, etc, les serveurs étant déjà commandés pour faire le pilote. Bref, tu veux un planning, le voilà. ON veut faire un minimum de dev interne, et si pour ca on doit se passer de script qui interface une BDD, on le fera.
 
Bref, je comprends pas OU se situera notre souci si on a juste un DHCPD redondant balancant ses MAJ sur un maitre isolé qui se réplique sur deux esclaves ( ou plus ).
 
Bref, en gros, je vois pas le problème.
 
Quant à la maintenabilité, y a la maintenabilité externe ( presta) et surtout interne ( nous ! ). c'est de cette dernière que je parlais ( évidemment papy, voyons )

 
Nous si. Eux, non. Ton script SQL n'est pas un prérequis. Un admin linux n'est pas forcément un bidouilleur fini qui doit faire sa propre sauce et réinventer la roue pour faire quelque chose de bien.
 
CQFD.
 
On veut mettre en place une architecture SIMPLE. Pourquoi la développer nous même quand un bind et un DHCPD basique suffisent à répondre à notre problématique ?
 
PS : je vais au taff, je serai de retour dans peu de temps

gna

 
 
Tu as remarque qu'en 2 pages du topic il avait une meilleure vision que toi de la problematique et du projet ?
Nan je te signale juste que lui il n'est pas paye pour le faire et qu'en kkes posts il a vu des points de complexite que tu n'avais apparemment pas trouve...

 
Ca ne m'étonne guère étant donné que je suis en phase d'étude, que je suis sur d'autres projets en ce moment, et que je serai sur ce projet à plein temps courant de la semaine prochaine... la je le fais aussi durant mon "temps libre".
 
Bref, je vois guère le sens de ta remarque dans le problème qui m'entoure, à part essayer de me descendre/me faire chier, ca ne m'avance guère, tu sais.

 
ca ne t'etonne guere qu'un forumeur en trois posts saisisse mieux que toi un projet dont tu es charge
Le sens de ma remarque, c'est plutot que d'engueuler les autres lorsqu'ils te proposent des solutions, tu ferais bien de te poser des questions sur ton projet

 
Je n'engueule pas, je dis qu'une solution proposée ne me convient pas. L'engueulade suivante est de type générale ( bidouille ou non ?).
 
Bref, tes remarques, tu te les carre où je pense, et si je viens ici, c'est pour avoir de l'aide. Donc ca me semble normal qu'on m'apporte des infos. A quoi cela sert de poster un sujet si il faut, pour être crédible, tout savir dés le départ ?
 
Allez, retourne à ton petit cours de 2ème année va, et mèles-toi de ce qui te regarde.

 
Je veux pas mettre les pieds dans le plat, non je veux pas.....Tant pis :  
 
Faut quand même savoir reconnaître ses contradictions, non?
 
T'arrives avec une idée super ambitieuse à mettre en place (en plus c'est un projet plutôt intéressant). Zzozo te propose la solution élégante, déja existante (tu as lu le lien?), juste à adapter. Bon là tu lui dis que c'est pas ça que tu veux, alors que ça répond à ton cahier des charges... Bon mettons, tu connait peut-être pas le perl, et tout et tout!  
Mais aprés, au lieu d'admettre que t'as pas la compétence, tu reviens pour dire que finalement dhcpd + bind tout con ça te suffit, alors que t'as trois semaine pour boucler une maquette, que t'as une BDD existante avec tes noms de machines et que ça a plus rien à voir avec l'idée de départ...  Ben vu de l'extérieur tu donnes pas bien l'image d'un mec professionnel et sérieux.
 
'fin bon ce que j'en dis.

 
Ca ne rentre pas vraiment dans le cadre d'un projet DHCP/DNS que d'avoir une gestion de parc carrée avec un outil d'inventaire journalier déployé... ca me semblait un peu évident qu'on allait pas avoir de nom de poste aléatoire ou que sais-je encore
 
Ensuite, comme je suis dans une grosse structure, il faut bien évidemment que je pense :
-a ce qui se passera quand je serai parti ( oui c'est de l'admin linux ca aussi)
-au support en cas de problème majeur ( monsieur redhat j'ai un problème avec ma solution développée par moi même, pouvez m'aider ? ).
-que cette solution aie été éprouvée : on ne fait guère confiance à un nom ( désolé ).
 
Je suis parti du principe que la redondance coté DNS maitre était vitale... après étude et réflexion, j'ai changé d'avis. Du coup, cela change la donne, n'est-ce pas ? Toute solution à envisager coté redondance DNS peut être oubliée, et un simple bind avec un dhcpd de chez isc suffit. Pas la peine de développer du script à mourrir pour réinventer la roue... et les délais étant très court, on n'a de toute manière pas le temps de le faire.
 
Dieu seul sait que la solution de Zozzo, d'un point de vue admin, me plait :je me ferai plaisir à faire un truc pareil ( on perds pas ses habitudes de dévelo comme ca ), mais il faut etre réaliste : elle repose sur énormément de choses à développer, tellement que ca en devient une solution "bidouillarde" extrémistes. D'autres y ont pensé, mais cela n'a pas été testé. On est partant pour être en avance sur les autres, pas pour être béta-testeurs.
 
J'aurai du préciser directement et de facon beaucoup plus précise les contraintes. Il me reste des points à éclaircir encore :
-comment ( est-ce d'ailleurs souhaitable) d'automatiser la récupération des MAJs loupées quand le DNS maitre tombe
-quelle solution d'admin simple choisir  
 
Le reste étant plus de réflexon en interne ( on créé une nouvelle zone  ? on positionne où les DNS pour limiter le trafic réseau ? comment gère t'on les sites distants ? ).
 
Ce n'est pas parce qu'une solution est élégante qu'elle répond forcément au problème. Soyons objectif : ma boite ne dispose pas à l'heure actuelle du personnel qualifié pour développer et maintenir une telle solution. Nous voulons certes un DHCP/DNS dynamique, pas une usine à gaz qui nécessite un dev en interne lourd, des tests poussés, et une maintenance de folie. On veut une solution fonctionelle, éprouvée, simple, et si possible déjà utilisée ailleurs.
 
Etant dans le contexte, ces prérequis me semblaient un peu évident : j'aurai du être plus explicite, mea culpa.  
 
Si je montre a à mon chef, vous savez quelle va être sa réponse ? "eh, on fout un windows 2003 et en quelques clics c'est torché". Et il aura pas tort. Et je ne veux pas que cette architecture tourne sous Windows, car selon moi, si il y a bien un truc simple qui peut tourner sous linux, c'est bien ca. Donc acte.
 
Bref, arrêtons la dissertation : la solution de papy est jolie, mais pas adaptée à notre contexte.  
 
Vous savez, c'est ce genre d'extrémisme "bidouille linux ca rocks go perl solo on le fait nous même yeah ca tourne génial... et 10 ans après, quelqu'un d'autre regarde ce que ca fait, et doit tout reprendre de 0 car coté standardisation,c'est 0", qui me fait des fois regretter de promouvoir linux. L'admin linux, c'est aussi de penser à l'avenir. C'est aussi de ne pas en faire trop afin de prendre le minimum de risques. C'est tout ca.

pfuiiii tout ça pour ça

Tetedeiench, t'as vraiment pas changé
 
Tu demandes des solutions adapté à ta problèmatique et dès qu'il faut scripter 3 lignes pour corréler le tout ça devient de la bidouille impensable pour toi
 
Et derrière tu te permets de dire que c'est nul à une solution pourtant utilisée par des operateur et proposée par un mec avec une expérience qui rend ton attitude envers ses propositions plutôt insultante
 
Pourquoi venir ici demander une solution éprouvée pour un gros déploiement alors que manifestement ( sans vouloir t'offenser ) tu ne maitrises toi même pas ce domaine d'administration correctement ?
 
Parce que bon franchement personnellement en connaissant bien le domaine, les solutions y'en a comme ce que Zzozo propose et leur limite de fiabilité n'est liée qu'à la maitrise de la personne qui le déploie selon moi, y'a rien de bien sorcier.
 
Après si tu dis que ton problème c'est de faire valider la solution auprès des gens au dessus, ça peut se comprendre, si c'est pour dire que c'est de la bidouille et que c'est nul et inadapté pour une structure comme ça, c'est que tu maitrises pas le système à priori.
 
Si c'est le cas, je conseille de prendre conseil auprès d'une société maitrisant ce type de déploiement, ça permettra de le mettre en place sereinement et d'apprendre des choses au passage, ce qui est toujours un plus ( bon après faut les payer mais bon )
 
Pis franchement le couplet "l'admin linux c'est ..." venant d'une personne qui a moins d'expérience là dedans que la majorité des intervenants du topic, c'est un peu prétentieux
 
Bref ça va encore partir en couille, mais ça fait qq temps que je lis ce topic et voir des solutions intéressantes et structurées proposées se faire balayer d'une remarque irrespectueuse et de considérations pas très réalistes, c'est bien triste.
 

chute de pâtés !

Continuez ce sujet si ca vous chante, ce sera sans moi.
 
Ca ne sert à rien d'aller ici, décidément. Je le saurai à l'avenir. Excellent forum de debug cependant, mais dés qu'on demande de l'aide sur un petit truc, on te propose un truc enooooooooooorme.
 
Désolé de pas avoir envie de réinventer la rue. Désolé de pas vouloir mettre en place un marteau pilon pour écraser un cafard.
 
Et quant à ceux qui ne font que poster pour me dénigrer constamment, ils savent très bien ce que je leur dis, j'imagine
 
Sur ce, messieurs, merci de votre aide, merci de vos suggestions ( heartbeat, etc), et désolé d'avoir mal posé la problématique, désolé d'avoir changé d'avis sur la haute dispo du DNS maitre, et de ne pas avoir le temps, l'envie et tout ca, de mettre en place le marteau-pilon.

Ah bah faudrait savoir, tu veux déployer un truc pro pour 2500 personnes et maintenant c'est un petit truc
 
Et effectivement ça ne sert à rien de venir ici si c'est dans cet état d'esprit
 
Déployer ça dans une structure importante demande une maitrise de ce qu'on fait et des effects de bords.
 
C'est comme monter 2500 posts sur des switchs basiques à la chaine sans structure et sans maîtrise sur des zones, le jour où une merde arrive avec une box verrolée, c'est tout le réseau qui est à terre et c'est pas le bonheur pour remonter à la source ( c'est juste un exemple, je dis pas que c'est comme ça mais juste que ça revient au même que de se lancer dans ce que tu veux sans connaître les effets de bords potentiels )

 
2500 dans un premier temps, le système en aura entre 3500 et 4000 en fin d'année.
 
Le petit truc se rapporte évidemment coté précisions. je demandais de l'aide pour faire une architecture que je voulais simple, et reposant si possible uniquement sur des sujets éprouvés, pas sur un dev interne énorme.
 
D'ou "petit truc".
 
Me dis pas que tu avais pas compris, mauvaise langue !
 
C'est justement pour minimiser les risques que l'on veut partir sur quelque chose d'éprouvé et si possible supporté par Redhat ( distro officielle de ma boite). Bref, rien de transcendental, coté demandes. Après, qu'on me reproche de qualifier une solution proposée de "bidouille", je veux bien, m'enfin... c'est indirectement en voyant ce qui existait sur le sujet que j'ai commencé à me demander si avoir un backup pour le maitre était vital... d'ou la conclusion qui en a découlé.
 
Bref.  
 
PS : faudrait que je perde cette désagréable habitude de répondre quand on me sollicite.

comment récupéer les updates ratées pour le DNS ?
tu fais un renew sur les bécanes non enregistrées ( "ipconfig /renew" sous 2k/XP, "service network restart" ).
 
sinon tu peux faire un script qui analyse le fichier /var/lib/dhcp/dhcpd.leases ( c'est un fichier texte ) et qui vérifie si tous les IP sont dans le DNS. Si une IP n'y est pas, alors elle est ajoutée au DNS.
quand tu remets sur pied ton DNS maîtres, tu lances ce script qui s'occupe de synchroniser ton DNS. et le tour est joué.

Tout ce que je viens de lire là me laisse pantois  

  Tu parles d'extrapolations dans un autre post ... et effectivement, je m'aperçois que tu sais de quoi tu parles, tu en es le champion ... au point d'en faire des amalgames douteux    
 
  Tu comprendras (ou pas ...   ) un jour que l'essentiel n'étaient pas les scripts sur lesquels tu t'es focalisés, mais l'idée sous jacente ...
 
  Dommage, parce qu'en dehors de ce que j'ai pu trouver sur le site de l'université de Carnegie Mellon, j'avais carrément trouvé une solution commerciale, sous RedHat et dont les "auteurs" ne sont pas n'importe qui, et sont vraiment chevronnés en la matière (ceci est une piste ...  la dernière ) et auraient pu vous apporter, non seulement leur produit, mais leur expertise en la matière ...  
 
 
 
  Maintenant, en dehors du sujet qui nous préoccupe, je constate que ce n'est pas la première fois que nous avons des prises de bec tous les deux. Et jusqu'à présent, j'ai fait preuve de beaucoup de compréhension envers toi ... Mais tu n'as, hélas, pas compris grand chose et tu n'as pas changé d'un iota sur un certain nombre de points. Ma patience est grande, mais pas infinie. Tu n'es définitivement pas quelqu'un d'intéressant. Je te laisse donc avec ton ego et ta paranoïa surdimenssionnés pour un esprit si étriqué ...
 
Sur ce, bonne continuation,
 j'ai d'autre chats à fouetter  
 
P.S. : Pour info, en temps cumulé sur tous les posts que j'ai pu faire, la réflexion que j'ai mené, et les recherches que j'ai pu faire, je dois en être à environ 2 heures de mon temps "libre" ... J'offrais mon aide (et de partager mon XP en la matière) ... elle ne te satisfait pas, j'en prend donc acte et je ramasse mes billes ...

kess ke je disais il est grognon

qui ça ?

pépé

et pourquoi personne ne parle de LDAP ici ?
 
il existe des serveurs DHCP et DNS qui savent utiliser un backend LDAP pour stocker leurs données.
 
ensuite il suffit d avoir un LDAP de backup (avec réplication slurpd). haute dispo assurée par VRRP/heartbeat et tout ça. je crois même me souvenir que le dhcpd que javais regardé pouvait accéder d autres IP pour des LDAP de backup ...
 
une url pour débuter :
http://www.lunytune.net/isc-ldap.html

sdu bidouillage ldap, rien ne vaut un bon vieux fichier plat, c'est standard, c'est une techno prouve, les grandes ssii connaissent bien, bref ca roske le fichier plat

 
ah bon ... ben écoute c est ton avis
personnellement je trouve très clean d avoir une séparation entre processus, données et administration
 
par exemple un serveur mail qui utilise un backend ldap pour savoir où mettre les mails, quels sont les quotas, les préférences antivirus/antispam ...
 
cette base ldap est administrée par un outil à part (éventuellement sur une autre machine). elle peut être répliquée à la volée pour haute dispo. elle peut être backupée et restaurée en utilisant le protocole LDAP via le réseau, un protocole léger, souple et standardisé.
 
gérer par fichiers plats 400 domaines de messagerie avec 15000 mailbox ... c est du boulot ! mais c est ça aussi le libre, tu choisis ce que tu préfères

 
euh j'explicite meme si je pensais que stait tres clean, j'etais ironique, en // au fait que tdi disent que des scripts constituent du bidouillage
 
Surtout que vu ce sur quoi je suis en train de bosser en ce moment, ca m'embeterait que ce soit du bidouillage LDAP  

 
ok !
excuse moi, c est vrai que j ai un peu zappé votre troll ;-)
 
mais je suis d accord sur le fait que l export des fichiers leases du dhcp par script etc etc ... c est du bidouillage !