Compte rendu quatrième réunion du 23 Juillet 2012

Participants

terminer avec la supervision des serveurs stratégiques
- créer un compte à JC sur ces serveurs

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._tcp¹"

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 par contre, si on ne veut pas devoir reconfigurer les tél. quand on change le serveur asterisk de réseau ou d'IP, on a tout intérêt à configurer tout le tél. avec des noms DNS uniquement
Machines dans les réseaux intermédiaires²	I	tous doivent avoir des noms cf ZEO/Paris/SitesMoodle/MigrationPhysiqueMoodle DMZ RPV, j'utilise le domaine RPV : fr.auf la DMZ publique, le domaine public : fr.auf.org DMZ interne³, un domaine interne, comme par exemple .site
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)
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

Déja abordé ... Consulter la disposition actuelle ZEO/Paris/ArchitectureBureautique

$/!\$ 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 ⁴
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

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)