Edito
Voila voila, je refais mon infra…
Et j'ai donc envie de participer a une oeuvre commune :
Antoine.
Pub
Désolé de vous incommoder avec cela, c'est un mal aujourd'hui nécessaire. Je le souhaite juste utile, on verra.
Différences
Cette page vous donne les différences entre la révision choisie et la version actuelle de la page.
|
docs:home-made:i-net [2009/09/16 22:59] adlp |
docs:home-made:i-net [2012/04/29 21:23] (version actuelle) |
||
|---|---|---|---|
| Ligne 11: | Ligne 11: | ||
| En fait il s agit juste d un fichier de documentation quand a un projet mis en œuvre par deux comparses: | En fait il s agit juste d un fichier de documentation quand a un projet mis en œuvre par deux comparses: | ||
| - | Antoine DELAPORTE adlp@adlp.org | + | Antoine DELAPORTE inet@adlp.baball.eu |
| http://adlp.org/cv.html | http://adlp.org/cv.html | ||
| Frederic MADROLLE fmadrolle@zr7.adlp.org | Frederic MADROLLE fmadrolle@zr7.adlp.org | ||
| Ligne 91: | Ligne 91: | ||
| * minimiser le dialogue sur les tunnels, et éviter la notion de noeud maitre de i ! | * minimiser le dialogue sur les tunnels, et éviter la notion de noeud maitre de i ! | ||
| pour simplifier, pour le moment tout Intranet a son dns... (ou utilisation du DNS interne le plus proche) tout le monde est maitre de ca zone "x.i." et est slave de la zone i. la zone i ne déclare que le dns de chaque réseau, ainsi le nœud maitre est inexistant | pour simplifier, pour le moment tout Intranet a son dns... (ou utilisation du DNS interne le plus proche) tout le monde est maitre de ca zone "x.i." et est slave de la zone i. la zone i ne déclare que le dns de chaque réseau, ainsi le nœud maitre est inexistant | ||
| - | De plus le maitre (réel...) de la zone i a l'option notify a yes afin de notifier a tout les slaves la modification de la zone i. Ils viendront donc suite a cela chercher tout seuls comme des grands la nouvelle mouture de la zone i | + | De plus le maitre (réel...) de la zone i a l'option notify a yes afin de notifier a tout les slaves la modification de la zone i. Ils viendront donc suite a cela chercher tout seuls comme des grands la nouvelle mouture de la zone i |
| - | Ainsi, lorsqu'un poste d un réseau x.i désireras accéder a un poste de la zone y.i il interrogeras son dns, qui ira interroger le dns de la zone en question. | + | Ainsi, lorsqu'un poste d un réseau x.i désireras accéder a un poste de la zone y.i il interrogeras son dns, qui ira interroger le dns de la zone en question. |
| * le reverse !! :))) | * le reverse !! :))) | ||
| il est toujours utile de savoir d'où viens une personne qui se connecte sur votre machine (qu'il vienne d un réseau interne ou non) pour cela il existe le reverse ip | il est toujours utile de savoir d'où viens une personne qui se connecte sur votre machine (qu'il vienne d un réseau interne ou non) pour cela il existe le reverse ip | ||
| + | |||
| ==== état des lieux: ==== | ==== état des lieux: ==== | ||
| * on est pas tld -> pas de maitrise sur la zone arpa | * on est pas tld -> pas de maitrise sur la zone arpa | ||
| Ligne 128: | Ligne 129: | ||
| ===== Serveurs de mails ===== | ===== Serveurs de mails ===== | ||
| - | .l interfacage mail de l intranet/l'internet | + | * l interfaçage mail de l intranet/l'internet |
| - | .rappel rapide d'un des objectifs: | + | * rappel rapide d'un des objectifs: tout clients du réseau I devra accéder de façon transparente a l'Internet, comme à l'I |
| - | tout clients du reseau I devra acceder de facon transparante | + | * il faut donc que ces personnes disposent d'une email externe, voire propre a leur zone sur I . |
| - | a l'Interntet, comme a l'I | + | * Pour avoir un MX sur une zone il faut une IP fixe. |
| - | .il faut donc que ces personnes disposent d'une email externe, | + | * on a déclare un une machine MX de toutes les machines/domaines représentant les domaines/machines de I, vis avis des mails échanges avec l'Internet (les échanges au travers de I restent a la bonne volonté de chacun des administrateurs de chaque réseaux) |
| - | voire propre a leur zone sur I . | + | * La difficulté étant de rendre le délais de livraisons des mails le plus court possible, sans pour autant interdire les coupures de plus de 10 jours... |
| - | .Pour avoir un MX sur une zone il faut une IP fixe. | + | * Il nous a donc fallut mettre en plus du relayage de mail (via une mailertable) |
| - | .on a declare un une machine MX de toutes les machines/domaines | + | * le relayage smtp en pointant sur une machine de l'internet fonctionne parfaitement, mais si l'intranet, pour une raison ou une autre se déconnecte, les émetteurs des mails peuvent recevoir une Warning, et si la machine n'est pas remonte apres une duree configurée, le mail est efface... |
| - | represeantant les domaines/machines de I, vis avis des mails | + | * nous avons donc opte pour le relayage par des feed uucp. |
| - | echanges avec l'Internet (les echanges au travers de I restent a | + | * le problème apparaissant étant maintenant autre: l'uucp n est pas |
| - | la bonne volontee de chacuns des administrateurs de chaques | + | * un mode connecte, bref soit on force le transfert, soit on passe par une crontab... |
| - | reseaux) | + | * ni l un ni l autre ne sont intéressant et reste un pb. |
| - | .La difficultee etant de rendre le delais de livraisons des mails | + | * comment savoir quand forcer i ? |
| - | le plus court possible, sans pour autant interdire les coupures | + | * a quels heures est il judicieux de tester le feed ? (pas très économes en bp...) |
| - | de plus de 10 jours... | + | * a cela a ete trouve une autre solution, le programme plaçant le mail dans le feed uucp a été détourner sur un programme qui effectivement place le mail dans le feed en attente, mais qui ensuite tente l'interconnexion uucp... |
| - | .Il nous a donc fallut mettre en plus du relayage de mail (via | + | * si le site est connecté, le mail arrive a destination immédiatement |
| - | une mailertable) | + | * sinon il sera relevé au prochain mail émis en direction du domaine, ou par commande faites par l'administrateur de la zone lors de sa reconnexion, ou lorsque bon lui semble.... |
| - | .le relayage smpt en pointant sur une machine de l'internet | + | * les mails a direction de l internet sont émis par les smtp de chaque zones, directement vers l internet |
| - | fonctionne parfaitement, mais si l'intranet, pour une raison | + | * les mails en provenance de l'internet ne sont pas perdus. |
| - | ou une autre se deconnecte, les emetteurs des mails peuvent | + | |
| - | recevoir une Warning, et si la machine n'est pas remonte apres | + | |
| - | une duree configuree, le mail est efface... | + | |
| - | .nous avons donc opte pour le relayage par des feed uucp. | + | |
| - | .le probleme apparaissant etant maintenant autre: l'uucp n est pas | + | |
| - | un mode connecte, bref soit on force le transfert, soit on passe | + | |
| - | par une crontab... | + | |
| - | . ni l un ni l autre ne sont interessant et reste un pb. | + | |
| - | .comment isavoir quand forcer i ? | + | |
| - | .a quels heures est il judicieux de tester le feed ? | + | |
| - | (pas tres economes en bp...) | + | |
| - | .a cela a ete trouve une autre solution, le programme placant le | + | |
| - | mail dans le feed uucp a ete detourner sur un programme qui | + | |
| - | effectivement place le mail dans le feed en attente, mais qui | + | |
| - | ensuite tente l'interconnection uucp... | + | |
| - | .si le site est connete, le mail arrive a destination immediatement | + | |
| - | .sinon il sera releve au prochain mail emis en direction du | + | |
| - | domaine, ou par commande faites par l'administrateur de la zone | + | |
| - | lors de sa reconnection, ou lorsque bon lui semble.... | + | |
| - | .les mails a direction de l internet sont emis par les smtp de | + | |
| - | chaques zones, directement vers l internet | + | |
| - | .les mails en provenance de l'internet ne sont pas perdus. | + | |
| ====== Etat des lieux: ====== | ====== Etat des lieux: ====== | ||
| - | .soucis sur le mail | + | **soucis sur le mail** |
| - | .bien qu il n y ai strictement aucune perte de mail, une | + | |
| - | erreure est produite (mailer-daemon) lors d'une tentative | + | * bien qu il n y ai strictement aucune perte de mail, une erreur est produite (mailer-daemon) lors d'une tentative aborde de balancer le feed uucp... |
| - | aborde de balancer le feed uucp... | + | * visiblement uniquement un pb de droits, car cela n apparaissait que lors du mail en local depuis la machine fédératrice du mail... |
| - | .visiblement uniquement un pb de droits, car cela | + | * pour éviter cette erreur, il suffit de mettre a la fin du prog simulant le uux, un exit 0.... le mieux serait de récupérer le code de sortie du vrai uux, mais il est dit nul de sortie... |
| - | n apparaissait que lors du mail en local depuis la machine | + | |
| - | federatrice du mail... | + | |
| - | .pour eviter cette erreure, il suffit de mettre a la fin | + | |
| - | du prog simulant le uux, un exit 0.... le mieux serait | + | |
| - | de recuperer le code de sortie du vrai uux, mais il est | + | |
| - | dit nul de sortie... | + | |
