Pénates : monter un petit SI rapidement - Page 1

V'là un beau projet un peu geek qui ne sera pas fini avant 2042 :-D Cela dit, j'ai du temps devant moi vu que je ne pense pas l'utiliser avant un an.
Bref, depuis quelque temps, j'ai envie de reconstruire mon réseau domestique, mais avec quelques contraintes :

* une installation totalement automatisée des machines et des services,
* ce que je peux en termes de sécurité (on évite les mots de passe et chiffrement de toutes les connexions),
* passage possible à l'IP v.6,
* structure assez simple, avec par exemple deux catégories de personnes (les admins et les utilisateurs), un seul réseau local, un seul domaine DNS, …
* machines clientes sous OS X ou Ubuntu.


L'installation des machines se fera avec une ISO contenant les réponses aux questions.
Je pense faire les choses en plusieurs étapes, avec d'abord un socle avec les services suivants :

* PKI avec un certificat racine, pour délivrer des certificats propres pour tout (services, machines, utilisateurs, …),
* LDAP pour stocker les utilisateurs et les groupes,
* Kerberos pour l'authentification (utilisateurs, machines, services),
* serveur DHCP et DNS (avec enregistrement automatique des nouveaux services et machines),
* DNSSEC et DANE pour sécuriser le DNS,
* mail (SMTP/IMAP avec opensmtpd et dovecot),
* ntp,
* logs centralisés et supervision (pas encore fait).

À terme, je rajouterais volontiers pour compléter ce socle du 802.1x (si mon imprimante le permet )

Au-dessus de ça, je pense mettre quelques services applicatifs :

* CardDAV, CalDAV (via Radicale),
* XMPP (avec Prosody),
* SIP (Asterisk ?),
* génération des profils pour les Mac et les iPhone ^^
* un Gitlab et ce qui va avec (Jenkins, notamment)
* Plex (partages multimédia) et Seafile (partage et synchro de fichiers),
* proxy HTTP,
* plein d'autres choses…

Je n'ai pas encore trouvé comment faire de l'authentification sans mot de passe sur Plex et Seafile (Qt ne connaît même pas Kerberos)
L'autre problème, c'est que l'iPhone ne supporte pas Kerberos du coup, je vais être obligé de conserver des mots de passe.
Actuellement, j'en suis encore au socle qui sera basé sur du Ubuntu 15.04 Server.


Ça n'avance pas très vite, tout automatiser prend un peu de temps, et surtout le manque de doc est assez incroyable.
Les messages d'erreur aident beaucoup également : par exemple, quand kerberos dit « incorrect password », il faut comprendre que l'horloge du serveur retarde trop.
Quand le serveur LDAP est injoignable, c'est évidemment qu'il y a un problème de certificat.

En pratique, on crée un fichier avec la liste des machines à utiliser et quelques paramètres (le nom de domaine, les mots de passe), on a une machine (ou plusieurs) avec une Ubuntu Server nue (uniquement ssh), et on lance :

ansible-playbook -i servers_1504.ini common_pass_1.yml
ansible-playbook -i servers_1504.ini auth_servers.yml
ansible-playbook -i servers_1504.ini dhcp_servers.yml
ansible-playbook -i servers_1504.ini common_pass_2.yml
ansible-playbook -i servers_1504.ini mail_servers.yml

À partir de là, on a une PKI, un LDAP, Kerberos, DHCP, smtp, imap, ntp … configurés et fonctionnels sur les bonnes machines.

Bon, c'est très loin d'être fini, mais je pense avoir fait le plus dur.


Pour me simplifier la vie, j'ai fait un petit service web (penates-server), qui simplifie la vie. On va pouvoir enregistrer un service avec un seul webservice de smtp://mail01.example.org:993 vers server.example.org fait différentes actions :

* le certificat SSL (récupéré avec un appel ultérieur),
* l'enregistrement DNS CNAME,
* l'enregistrement DNS DANE (avec le certificat), et les NS / MX / DKIM et SPF si besoin est,
* l'enregistrement DNS SRV si nécessaire,
* le keytab pour l'authent' kerberos (récupéré avec un appel ultérieur).

Autre exemple, on peut enregistrer une machine avec un seul webservice :

* un keytab machine renvoyé à l'enregistrement,
* certificat SSL machine,
* enregistrement A ou AAAA,
* enregistrement des SSHFP pour enregistrer les clefs SSH publiques des machines,
* enregistrement des adresses MAC et IP dans le DHCP.

Ah ! Bon, pour les gens qui voudraient commencer par rattraper le retard Ansible avant de pouvoir accrocher la suite du projet, tu as suivi un tuto particulier ou bien tu as juste appris avec la documentation officielle ?

J'ai suivi la doc officielle, mais uniquement la partie playbook ^^

C'est franchement facile à utiliser, un peu plus long à maîtriser. En deux mots : tu as un fichier avec des groupes de machines à utiliser (ou leur alias dans ~/.ssh/config) et des variables définies pour chaque groupe.
À côté, tu as un fichier .yml avec la liste des choses à faire et sur quel groupe de machines :

---
- hosts: mail_servers
  remote_user: root
  vars:
    mail_fqdn: "mail{{ '%02d' % (groups['auth_servers'].index(inventory_hostname) + 1) }}.{{ penates_domain }}"
  tasks:
  - apt: pkg=amavisd-new
  - template: src=templates/mail_servers/amavis_05-node_id.conf dest=/etc/amavis/conf.d/05-node_id owner=root group=root mode=0644
  - template: src=templates/mail_servers/amavis_99-local.conf dest=/etc/amavis/conf.d/99-local owner=root group=root mode=0644
  - service: state=restarted name=amavis

Là, je dis que je veux exécuter sur le groupe de machines « mail_servers », dans ce groupe je définis la variable mail_fqdn qui sera unique à chaque machine (toutes les commandes sont en fait des templates Jinja2), puis j'installe amavisd-new, j'écris deux fichiers de conf' et je relance le service.

Après, tu as des milliards de commandes possibles, et c'est facile d'en créer de nouvelles

Je n'ai peut-être pas compris ce que tu décrivais pas "automatisation", mas as-tu regardé du côté de Chef ? C'est assez puissant tout en étant très simple au niveau du concept (tu écris une recette, et le chef la "cuisine"). Je n'ai moi-même pas de compétences dessus, mais il y a beaucoup d'administrateurs système Linux qui utilisent ça dans mon environnement pro.

oui, je connais chef (comme puppet ou salt, d'ailleurs j'ai du salt actuellement chez moi), mais ça demande un serveur chef installé, ce qui veut dire en plus : ldap, kerberos, pki, dns et dhcp.

Ansible permet de s'affranchir de ce problème d'initialisation du réseau, sans compter que c'est nettement plus simple.
Le problème de chef/puppet/salt, c'est qu'il est très compliqué de passer à l'échelle (quand tu as beaucoup de services différents) quand tu veux organiser correctement tes classes. Ansible permet de conserver un fichier ansible par projet, sans empiéter sur le socle commun.

Ok (Cela dit, Chef peut aussi fonctionner sans serveur, mais je ne sais pas ce que ça implique au niveau pré-requis)

Mais si on fait du chef (ou puppet, ou salt, ils ont tous un mode sans serveur) sans serveur, on perd leur avantage, alors que je trouve leur syntaxe bien plus pénible que celle d'Ansible, tout en étant bien plus compliqué quand on veut avoir des classes bien factorisées.

Tout ça juste pour chez toi ?!

bah quoi ? c'est déjà en bonne partie le cas depuis pas mal de temps

Ah c'est sûr que de ce que j'ai vu de Chef, c'est vite verbeux et lourd x_x

Flan > chépas, j'y connais rien mais tout ça me paraît super complexe pour un usage personnel

bah je veux avoir en interne un certain nombre de services (calendrier, carnet d'adresse, forge logicielle), et un peu de sécurité (centralisation de mots de passe, certificats, kerberos).
du coup, quand tu veux faire les choses proprement, il faut rapidement pas mal de services, mais à l'usage c'est bien plus simple.

Ben voilà, par exemple, je connais pas beaucoup de gens qui ont du Kerberos chez eux ^^

C'est pourtant super pratique à l'usage de ne pas avoir à entrer des mots de passe sur les applications ^^

Après, plein de choses ne sont pas compatibles, comme l'iPhone ou Qt

Perso j'aimerais bien avoir le courage de refaire toutes mes configurations sous Ansible ou Chef ou autre, pke devoir passer une demi journée à chaque réinstallation c'est quand même bien pénible

Je suis bien d'accord, c'est quand même agréable de pouvoir réinstaller l'ensemble en une seule ligne de commande (je le fais tous les jours sur ma VM de test) ^^

Le problème d'Ansible, c'est qu'ils sont bloqués à l'âge de Python 2.

Kevin Kofler (./17) :
Le problème d'Ansible, c'est qu'ils sont bloqués à l'âge de Python 2.

C'est bien dommage, mais en pratique ce n'est pas si grave que ça. Les quelques plugins que j'écris sont compatibles 2 et 3, et le passage d'Ansible à Python 3 sera indolore.


Par contre, je trouve souvent délicat de trouver de la doc fiable sur pas mal de sujets (coucou SASL).
Je suis en train de regarder les logs, vu que j'aimerais centraliser tous les logs des différentes machines sur une seule. Du coup, j'aimerais utiliser journald (qui me semble plus moderne que syslog, rsyslog ou syslog-ng), mais il n'y a pas grand-chose expliquant comme faire.

j'avais oublié les liens https://github.com/d9pouces/Penates pour la partie Ansible, et https://github.com/d9pouces/Penates-Server pour le serveur web/pki. C'est très loin d'être finalisé, ça ne doit pas encore être utilisable sur n'importe quelle VM. Accessoirement, j'hésite à passer à du CentOS en remplacement d'Ubuntu Server.

Mais d'abord, je continue à travailler les logs (avec en parallèle du rsyslog et du journald, je pense) et fail2ban.

Au final, je dois développer quelques outils en plus d'Ansible pour faire fonctionner le tout.
Le premier (penates-server) qui s'occupait uniquement des certificats et des enregistrements LDAP/Kerberos/DNS génère maintenant les fichiers de conf DHCP et DNS et la conf de supervision.
Le prochain outil fera de la synchro entre un LDAP et une base SQL pour les utilisateurs, les groupes et surtout les administrateurs. Pas mal d'outils ne savent pas se synchroniser nativement avec un LDAP.

Étape actuelle, maintenant que la sup fonctionne : mise en place d'une machine d'installation, avec serveur de boot et miroir ubuntu officiel et miroir debian générique pour les paquets maison.

Ensuite installation de Plex, Jabber XMPP, Seafile puis Gitlab, CardDAV, CalDAV, Asterisk.

J'ai quand même laissé de côté certains trucs : mise en place des sauvegardes, réinstallation depuis une sauvegarde, SMTP avec kerberos.

J'aimerais bien que ça soit opérationnel pour avril ou mai

flanker (./20) :
Le prochain outil fera de la synchro entre un LDAP et une base SQL pour les utilisateurs, les groupes et surtout les administrateurs. Pas mal d'outils ne savent pas se synchroniser nativement avec un LDAP.

On a plus souvent le problème inverse
Sinon, il y a des ETL qui font ça très bien

(Je suis le seul à avoir un seul pc tout simple sans imprimante ? — cela dit c'est certainement formateur, c'est pas la question ; simplement j'ai ni les besoins ni les machines ni la place de faire ça )

Ah, je ne sais pas, moi j'ai pas tout ça à la maison (mon NAS suffit à mes besoins actuels ^^). Par contre, c'est au boulot que je gère l'annuaire centralisé et les synchronisations, du coup j'ai un point de vue assez différent

Nil (./21) :

flanker (./20) :
Le prochain outil fera de la synchro entre un LDAP et une base SQL pour les utilisateurs, les groupes et surtout les administrateurs. Pas mal d'outils ne savent pas se synchroniser nativement avec un LDAP.

On a plus souvent le problème inverse
Sinon, il y a des ETL qui font ça très bien

Le problème est essentiellement de faire le mapping LDAP-SQL, et j'ai de toute façon du Python installé ; je préfère limiter les technos à installer ^^

Pen^2 (./22) :
(Je suis le seul à avoir un seul pc tout simple sans imprimante ? — cela dit c'est certainement formateur, c'est pas la question ; simplement j'ai ni les besoins ni les machines ni la place de faire ça )

Je vais sûrement le réutiliser au boulot où je dois installer quelques machines en circuit fermé ^^
Sinon, j'ai un serveur chez moi, deux dédiés chez OVH, un fixe et un portable. Ce n'est pas énorme non plus

flanker (./24) :
Le problème est essentiellement de faire le mapping LDAP-SQL, et j'ai de toute façon du Python installé ; je préfère limiter les technos à installer ^^

Ben le souci c'est que soit tu as de la pertes de données, soit tu fais de l'objet-relationnel pour compenser (et du coup, tu te retrouves rapidement avec des structures complexes).
Ici, on a découpé le traitement en Source / Individu /Ressource
Un individu vient de une ou plusieurs sources et finit dans une ou plusieurs ressources.
Une des ressources (l'annuaire LDAP principal) référence toutes les ressources d'un individu.
Chaque ressource vient avec des méthodes de traitement permettant une gestion des comptes automatisées en lien avec les données issues dans l'annuaire principal.

On n'a pas réussi à faire mieux :
- pour les ressources développées localement, on essaye d'avoir une gestion des droits faite dans l'annuaire, mais on a quand-même la gestion des données à faire par scripts
- pour les ressources autres, ça dépend... on peut se baser sur du LDAP (ou sur une couche de SSO basée sur l'annuaire), mais c'est parfois pas possible (soit qu'il y ait une gestion parallèle du compte dans une base de données, soit qu'il n'y ait pas du tout de brique LDAP/SSO). Du coup, toute la gestion se fait par scripts, et on a un attribut multivalué de l'annuaire qui dit {NOM_RESSOURCE}id_du_compte
- lors d'un événement (début d'activité, fin d'activité, reprise d'activité, fin de vie du compte, blocage administratif/technique, charte signée, charte révoquée...), les opérations nécessaires (s'il en existe dans les méthodes associées à chaque ressource) sont exécutées

Je suis justement en train de réécrire totalement notre outil pour coller à ça (jusqu'à présent, il fait ça mais de façon incomplète, les ressources hors annuaire principal ne sont pas gérées de façon souple, et on n'a pas de possibilité d'appliquer correctement les politiques liées aux événements).

J'ai un gros avantage : je pars du principe que la structure visée est petite, ce qui simplifie énormément les groupes d'utilisateurs. En gros, il y aura les admins, et les autres

Cette discrimination au faciès

flanker (./26) :
J'ai un gros avantage : je pars du principe que la structure visée est petite, ce qui simplifie énormément les groupes d'utilisateurs. En gros, il y aura les admins, et les autres

Jusqu'à ce qu'une décision politique t'oblige à intégrer 4000 comptes de partenaires administratifs externes, issus de bases non consolidées, avec des doublons possibles par rapport aux comptes déjà existants

J'ai toujours un gros avantage à ce niveau : je mettrai moins de temps pour modifier la synchro que ce qui est nécessaire pour vérifier l'habilitation de chacun des 4 000 comptes, un par un

idée à la con : implémenter la synchro sous forme de check nagios pour avoir le résultat directement dans la sup'
je me demande si ce n'est pas une idée que je vais généraliser pour toutes les tâches régulières, en fait