Rôle Ansible bertvv.samba

Un rôle Ansible pour configurer Samba en tant que serveur de fichiers.

En raison d'un manque de temps et de ressources, j'ai confié la maintenance de ce rôle à @vladgh. Je ne suis plus en mesure de suivre les problèmes et les demandes de tirage, ni de garantir que les nouvelles versions sont suffisamment de haute qualité pour être réellement utilisables.

• Le nouveau dépôt Github se trouve ici : https://github.com/vladgh/ansible-collection-vladgh-samba
• Page Ansible Galaxy : https://galaxy.ansible.com/vladgh/samba
• Installer avec ansible-galaxy collection install vladgh.samba --upgrade

Merci à tous ceux qui ont montré leur soutien au fil des ans, à tous les contributeurs et en particulier à @vladgh pour avoir gracieusement accepté de reprendre la maintenance.

Les responsabilités de ce rôle sont de :

• Installer les packages nécessaires
• Configurer les paramètres SELinux (lorsque SELinux est actif)
• Créer des répertoires de partage
• Gérer les utilisateurs et mots de passe Samba
• Gérer l'accès aux partages

Les éléments suivants ne sont pas considérés comme des préoccupations de ce rôle, et vous devez les configurer en utilisant un autre rôle (par exemple, bertvv.rh-base) :

• Gestion des paramètres de pare-feu.
• Création d'utilisateurs système. Les utilisateurs Samba doivent déjà exister en tant qu'utilisateurs système.

Si vous aimez/utilisez ce rôle, merci de lui donner une étoile ! Merci !

CVE-2017-7494

Une vulnérabilité d'exécution de code à distance peut affecter votre installation de serveur Samba. Les versions de Samba 3.5.0 et avant 4.6.4 sont concernées. Si SELinux est activé sur votre système, il n'est PAS vulnérable.

Ce rôle vérifiera si la version installée de Samba est affectée par la vulnérabilité et appliquera le contournement proposé : ajouter nt pipe support = no à la section [global] de la configuration. Remarque : cela désactive la navigation dans les partages par les clients Windows.

Vous pouvez désactiver explicitement le correctif si nécessaire, en définissant la variable de rôle samba_mitigate_cve_2017_7494 à false.

Plus d'infos : https://access.redhat.com/security/cve/cve-2017-7494

Exigences

Aucune exigence spécifique

Variables de rôle

Définir des utilisateurs

Pour permettre aux utilisateurs d'accéder aux partages, ils doivent obtenir un mot de passe spécifiquement pour Samba :

samba_users:
  - name: alice
    password: ecila
  - name: bob
    password: bob
  - name: charlie
    password: eilrahc

Malheureusement, les mots de passe doivent être en texte brut pour l'instant. De plus, notez que ce rôle ne changera pas le mot de passe d'un utilisateur existant.

Ces utilisateurs doivent déjà avoir un compte sur l'hôte ! La création d'utilisateurs système ne fait pas partie de ce rôle, donc vous devez le faire séparément. Une possibilité est mon rôle bertvv.rh-base. Un exemple :

rhbase_users:
  - name: alice
    comment: 'Alice'
    password: !!
    shell: /sbin/nologin
    groups:
      [...]

Cet utilisateur n'est pas autorisé à se connecter au système (par exemple avec SSH) et n'aurait accès qu'aux partages Samba.

Définir des partages

Définir des partages Samba et configurer le contrôle d'accès peut être difficile, car cela implique non seulement d'obtenir la configuration Samba correcte, mais aussi les permissions utilisateurs et fichiers, et les paramètres SELinux. Ce rôle tente de simplifier le processus.

Pour spécifier un partage, vous devez au moins lui donner un nom :

samba_shares:
  - name: readonlyshare

Cela créera un partage avec uniquement un accès en lecture pour les utilisateurs enregistrés. Les invités ne pourront pas voir le contenu du partage.

Une bonne façon de configurer un accès en écriture pour un partage est de créer un groupe d'utilisateurs système, d'ajouter des utilisateurs à ce groupe et de s'assurer qu'ils ont un accès en écriture au répertoire du partage. Ce rôle suppose que les groupes sont déjà configurés et que les utilisateurs sont membres des groupes qui contrôlent l'accès en écriture. Supposons que vous avez deux utilisateurs jack et teach, membres du groupe pirates. Cette définition de partage donnera à la fois un accès en lecture et en écriture aux pirates :

samba_shares:
  - name: piratecove
    comment: 'Un endroit pour que les pirates se réunissent'
    group: pirates
    write_list: +pirates

Les invités n'ont pas accès à ce partage, les utilisateurs enregistrés peuvent lire. Vous pouvez ajuster davantage le contrôle d'accès. L'accès en lecture peut être accordé aux invités (ajoutez public: yes) ou restreint à des utilisateurs ou groupes spécifiés (ajoutez valid_users: +pirates). L'accès en écriture peut être restreint à des pirates individuels (par exemple write_list: jack). Les fichiers ajoutés au partage seront ajoutés au groupe spécifié et un accès en écriture au groupe sera accordé par défaut.

Voici un exemple de configuration de plusieurs modules d'objets vfs pour partager un volume glusterfs. Les options d'objet VFS sont optionnelles. Les modules d'objet VFS nécessaires doivent être présents/installer en dehors de ce rôle. Dans ce cas, samba-glusterfs a été installé sur centos. Consultez la documentation samba pour savoir comment installer ou quels sont les modules d'objet VFS par défaut.

samba_shares:
  - name: gluster-app_deploys
    comment: 'Pour samba share du volume app_deploys'
    vfs_objects:
      - name: audit
        options:
          - name: facility
            value: LOCAL1
          - name: priority
            value: NOTICE
      - name: glusterfs
        options:
          - name: volume
            value: app_deploys
          - name: logfile
            value: /var/log/samba/glusterfs-app_deploys.%M.log
          - name: loglevel
            value: 7
    path: /
    read_only: no
    guest_ok: yes
    write_list: tomcat
    group: tomcat

Un aperçu complet des options de partage suit ci-dessous. Seul name est requis, le reste est optionnel.

Les valeurs pour valid_users et write_list doivent être une liste séparée par des virgules d'utilisateurs. Les noms précédés de + ou @ sont interprétés comme des groupes. La documentation pour la configuration Samba donne plus de détails sur ces options.

Ajouter des fichiers de configuration arbitraires

Vous pouvez ajouter des paramètres qui ne sont pas pris en charge par ce rôle directement par le biais de fichiers de configuration personnalisés qui seront inclus dans le fichier de configuration principal. Il existe trois types de fichiers inclus : pour la section globale, pour la section homes, et pour les partages individuels. Placez vos fichiers de configuration personnalisés dans un sous-répertoire templates, relativement à l'emplacement de votre playbook maître. Ensuite, spécifiez-les dans les variables samba_global_include, samba_homes_include ou include_file dans la définition des samba_shares.

Vos fichiers de configuration personnalisés sont considérés comme des modèles Jinja, donc vous pouvez utiliser des variables Ansible à l'intérieur. Les fichiers de configuration seront validés pour s'assurer qu'ils sont syntaxiquement corrects.

Par exemple, pour inclure templates/global-include.conf, définissez :

samba_global_include: global-include.conf

Notez qu'il n'est pas nécessaire de spécifier le répertoire templates/.

De même, pour inclure templates/piratecove-include.conf, spécifique au partage piratecove (voir l'exemple ci-dessus) ; définissez :

samba_shares:
  - name: piratecove
    comment: 'Un endroit pour que les pirates se réunissent'
    group: pirates
    write_list: +pirates
    include_file: piratecove-include.conf

Le playbook de test a quelques exemples. Les fichiers de configuration personnalisés peuvent être trouvés dans la branche docker-tests.

Dépendances

Aucune dépendance.

Exemple de Playbook

Consultez le playbook de test.

Tests

Ce rôle est testé en utilisant Ansible Molecule. Les tests sont lancés automatiquement sur Travis CI après chaque commit et demande de tirage.

Cette configuration Molecule effectuera :

• Exécuter Yamllint et Ansible Lint
• Créer un conteneur Docker
• Exécuter une vérification de syntaxe
• Appliquer le rôle avec un playbook de test
• Exécuter des tests d'acceptation avec BATS

Ce processus est répété pour les distributions Linux prises en charge.

Environnement de test local

Si vous souhaitez créer un environnement de test local, vous pouvez utiliser cette configuration reproductible basée sur Vagrant+VirtualBox : https://github.com/bertvv/ansible-testenv. Étapes pour installer manuellement les outils nécessaires :

1. Docker, BATS et smbclient doivent être installés sur votre machine (supposé être sous Linux). Aucun conteneur Docker ne devrait être en cours d'exécution lorsque vous commencez le test.
2. Comme recommandé par Molecule, créez un environnement virtuel python.
3. Installez les outils logiciels python3 -m pip install molecule docker yamllint ansible-lint
4. Naviguez vers la racine du répertoire du rôle et exécutez molecule test

Molecule supprime automatiquement les conteneurs après un test. Si vous souhaitez consulter les conteneurs vous-même, exécutez molecule converge suivi de molecule login --host HOSTNAME.

Les conteneurs Docker sont basés sur des images créées par Jeff Geerling, spécifiquement pour les tests Ansible (recherchez les images nommées geerlingguy/docker-DISTRO-ansible). Vous pouvez utiliser n'importe quelle de ses images, mais seules les distributions mentionnées dans meta/main.yml sont prises en charge.

La configuration par défaut démarrera un conteneur Centos 7. Choisissez une autre distribution en définissant la variable MOLECULE_DISTRO avec la commande, par exemple :

MOLECULE_DISTRO=debian9 molecule test

ou

MOLECULE_DISTRO=debian9 molecule converge

Vous pouvez exécuter les tests d'acceptation sur les deux serveurs avec molecule verify ou manuellement avec

SUT_IP=172.17.0.2 bats molecule/default/files/samba.bats

Vous devez initialiser la variable SUT_IP, l'adresse IP du système à tester. Le serveur, smb1, devrait avoir l'adresse IP 172.17.0.2.

Contribution

Les problèmes, demandes de fonctionnalités, idées sont appréciés et peuvent être publiés dans la section Problèmes.

Les demandes de tirage sont également les bienvenues. Le meilleur moyen de soumettre une PR est de créer d'abord un fork de ce projet Github, puis de créer une branche thématique pour le changement proposé et de pousser cette branche vers votre propre fork. Github peut alors facilement créer une PR basée sur cette branche. N'oubliez pas de vous ajouter à la liste des contributeurs ci-dessous !

Licence

Licence BSD à 2 clauses, voir LICENSE.md.

Contributeurs

Ce rôle n'aurait pas pu exister sans les contributions des personnes listées ci-dessous. Si vous avez une idée pour l'améliorer encore plus, n'hésitez pas à participer !

Les problèmes, demandes de fonctionnalités, idées, suggestions, etc. peuvent être publiés dans la section Problèmes.

Les demandes de tirage sont également les bienvenues. Veuillez créer une branche thématique pour vos modifications proposées. Si vous ne le faites pas, cela créera des conflits dans votre fork après la fusion. N'hésitez pas à vous ajouter à la liste des contributeurs ci-dessous dans votre PR !

Ben Tomasik, Bengt Giger, Bert Van Vreckem (mainteneur), Birgit Croux, DarkStar1973, George Hartzell, Ian Young, Jonas Heinrich, Jonathan Underwood, Karl Goetz, morbidick, Paul Montero, Slavek Jurkowski, Sven Eeckeman, Tiemo Kieft, Tobias Wolter, Tomohiko Ozawa, Robin Ophalvens.