|
Taille: 5157
Commentaire:
|
← Version 3 à la date du 2012-07-26 14:47:57 ⇥
Taille: 5203
Commentaire: précision
|
| Texte supprimé. | Texte ajouté. |
| Ligne 35: | Ligne 35: |
| ||Machines dans les réseaux intermédiaires<<FootNote(En général des serveurs))>> ||I||tous doivent avoir des noms cf [[ZEO/Paris/SitesMoodle/MigrationPhysiqueMoodle]] <<BR>> DMZ RPV, j'utilise le domaine RPV : fr.auf <<BR>>la DMZ publique, le domaine public : fr.auf.org <<BR>> DMZ interne<<FootNote(DMZ qui n'est utilisée que sur le site, pas depuis Internet, pas depuis le RPV mais si et si un autre bout du RPV ou d'Internet devait y accéder, cela se ferait via un webservice, avec des contrôles d'accès fins, jamais du MySQL direct)>>, un domaine interne, comme par exemple .site <<BR>>|| | ||Machines dans les réseaux intermédiaires<<FootNote(En général des serveurs))>> ||I||tous doivent avoir des noms cf [[ZEO/Paris/SitesMoodle/MigrationPhysiqueMoodle]] où chaque CT a un nom dans 1 zone : `.openvz`<<BR>> DMZ RPV, j'utilise le domaine RPV : fr.auf <<BR>>la DMZ publique, le domaine public : fr.auf.org <<BR>> DMZ interne<<FootNote(DMZ qui n'est utilisée que sur le site, pas depuis Internet, pas depuis le RPV mais si et si un autre bout du RPV ou d'Internet devait y accéder, cela se ferait via un webservice, avec des contrôles d'accès fins, jamais du MySQL direct)>>, un domaine interne, comme par exemple .site <<BR>>|| |
Sommaire
Compte rendu quatrième réunion du 23 Juillet 2012
Participants
- Alex
- JC
- Willy
Programme
- Terminer avec les questions autour du DNS
- architecture de la bureautique du point de vue des serveurs
- la supervision
Notes
terminer avec la supervision des serveurs stratégiques
- créer un compte à JC sur ces serveurs
DNS
quelle zone DNS vous avez choisi pour les postes fixes, la ToIP, le WiFi, la visio, ...?
réponse d'alexandre : fixe bureautique.fr.auf et le reste aucun
il faut déterminer quand c'est indispensable ou utile
- indispensable quand des services se basent sur le nom DNS (NFS,MySQL)
c'est utile quand ça nous permet d'éviter de reconfigurer quand on change d'adresse IP pour des noms génériques tels que "gw","proxy" ou pour des services comme "_ldap._tcp" ou "_wpad._tcp1"
Zone ou périmètre |
Indispensable(I) / Utile (U) |
Commentaire |
Wifi |
U |
|
Lan bureautique |
I |
il faut un DNS au modèle Lucid au moins |
TOIP |
U |
ça dépend des modèles de téléphones : la plupart prennent leurs options en DHCP et les config se basent sur l'adresse MAC => pas besoin de nom DNS pour chaque tél |
Machines dans les réseaux intermédiaires2 |
I |
tous doivent avoir des noms cf ZEO/Paris/SitesMoodle/MigrationPhysiqueMoodle où chaque CT a un nom dans 1 zone : .openvz |
DNSSEC |
U |
pour plus tard |
Pour le cas de la TOIP dès qu'ils seront dans un réseau isolé derrière asterisk , ils ne seront plus dans le domaine bureautique et le nom utilisé => Il faudra créer une vue DNS ou un mini-service DNS sur astérisk pour que ça soit autonome
- DNSSEC à considérér plus tard
Au final :
- pour le public
- ns1.refer.org (interne)
- ns1.ca.auf.org (interne)
- pour l'interne et RPV
- ns1.bureautique.fr.auf (interne NFS) , le principe étant que la zone bureautique soit la plus autonome possible
NS bureautique doit utiliser le NS fr.auf comme forwarder
- ns1.fr.auf (pour tout ce qui ne ferait pas partie de la bureautique)
- ns1.bureautique.fr.auf (interne NFS) , le principe étant que la zone bureautique soit la plus autonome possible
- Sécurité à l'extrême ? séparer les services DNS autorité de zones d'un côté et les services DNS récursif (pour l'usage interne) de l'autre, sinon faire avec des ACL
Architecture bureautique
Déja abordé ... Consulter la disposition actuelle ZEO/Paris/ArchitectureBureautique
Supervision
![/!\](/static/gugiel/img/alert.png "/!\"){kind=small}
le plus urgent :
rsyslog partout, avec une ligne '*.* @log.site' dans /etc/rsyslog.conf partout,
- un CT "log" dans le réseau DMZ interne (.site) qui a également un rsyslog mais configuré avec séparation des logs arrivant par hôte.
- Installer logcheck sur le CT log et y rapatrier le maximum de règles logcheck trouvées dans les autres serveurs
Objectifs |
Outils |
avoir des données sur l'instant présent et le passé (historique) pour pouvoir réagir sur des pannes |
munin |
être prévenu en cas de problème, tenter de prévoir les problèmes à l'avance |
munin 4 |
retrouver des traces des opérations qui ont mené à un problème |
logcheck + rsyslog sur un(e) CT(ou machine physique) qui reçoit absolument tous les logs |
Pour les mises à jour munin permet d'afficher un graphique du nb de paquets à installer chaque jour monit oui ça pourrait être en complément de munin afin de surveiller l'état des services s'exécutant dans un serveur
à ce sujet ce n'est pas tant l'état des services qu'il faudrait surveiller directement mais plus souvent le dépassement de limites au sein d'un hôte OpenVZ par exemple
Messagerie et smarthost
- exim4 partout où il n'y a pas un service SMTP complet
tous les exim4 devrait pointer sur un smarthost
- typiquement.. tout courriel dans un CT devrait passer par le Exim4 local
- une suggestion pour les alias de réception d'infos techniques
technique@xx.auf.org => contact général
technique-logs@xx.auf.org => les logs à lire de temps en temps
technique-alert@xx.auf.org => les alertes à lire et traiter
qui permettent l'auto-détection de service d'annuaire ou de proxy, pour les machines qui le supportent, de plus en plus d'équipement mobiles => génial pour les invités de passage (1)
En général des serveurs) (2)
DMZ qui n'est utilisée que sur le site, pas depuis Internet, pas depuis le RPV mais si et si un autre bout du RPV ou d'Internet devait y accéder, cela se ferait via un webservice, avec des contrôles d'accès fins, jamais du MySQL direct (3)
quand on le configure jusqu'au bout sinon passer à Nagios (4)