Rola Ansible bertvv.samba

Rola Ansible do konfiguracji Samby jako serwera plików.

Z powodu braku czasu i zasobów, oddałem utrzymanie tej roli @vladgh. Nie mam już możliwości odpowiadać na zgłoszenia i propozycje zmian oraz zapewnić, że nowe wydania są wystarczająco wysokiej jakości, aby były rzeczywiście użyteczne.

• Nowe repozytorium Github można znaleźć tutaj: https://github.com/vladgh/ansible-collection-vladgh-samba
• Strona Ansible Galaxy: https://galaxy.ansible.com/vladgh/samba
• Zainstaluj za pomocą ansible-galaxy collection install vladgh.samba --upgrade

Dziękuję wszystkim, którzy wspierali mnie przez te lata, wszystkim współpracownikom, a szczególnie @vladgh za chęć przejęcia utrzymania.

Zadania tej roli to:

• Instalacja niezbędnych pakietów
• Konfiguracja ustawień SELinux (gdy SELinux jest aktywny)
• Tworzenie katalogów współdzielonych
• Zarządzanie użytkownikami i hasłami Samby
• Zarządzanie dostępem do współdzielonych zasobów

Poniższe kwestie nie są związane z tą rolą i powinny być konfigurowane za pomocą innej roli (np. bertvv.rh-base):

• Zarządzanie ustawieniami zapory.
• Tworzenie użytkowników systemowych. Użytkownicy Samby powinni już istnieć jako użytkownicy systemowi.

Jeśli podoba ci się/jesz ta rola, rozważ wystawienie jej gwiazdki! Dziękuję!

CVE-2017-7494

Może wystąpić luka w zdalnym wykonywaniu kodu, która dotyczy instalacji serwera Samba. Wersje Samby 3.5.0 i wcześniejsze 4.6.4 są podatne. Jeśli SELinux jest włączony w twoim systemie, to NIE jest podatny.

Ta rola sprawdzi, czy zainstalowana wersja Samby jest podatna na lukę i zastosuje proponowane rozwiązanie: dodanie nt pipe support = no do sekcji [global] w konfiguracji. Zauważ, że to wyłącza przeglądanie współdzielonych zasobów przez klientów Windows.

Możesz wyraźnie wyłączyć to rozwiązanie, ustawiając zmienną roli samba_mitigate_cve_2017_7494 na false.

Więcej informacji: https://access.redhat.com/security/cve/cve-2017-7494

Wymagania

Brak specyficznych wymagań.

Zmienne roli

Definiowanie użytkowników

Aby umożliwić użytkownikom dostęp do współdzielonych zasobów, muszą otrzymać hasło specyficzne dla Samby:

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

Niestety, obecnie hasła muszą być w czystym tekście. Zauważ także, że ta rola nie zmieni hasła istniejącego użytkownika.

Ci użytkownicy powinni już mieć konto na hoście! Tworzenie użytkowników systemowych nie należy do zadań tej roli, więc powinieneś to zrobić osobno. Możliwym rozwiązaniem jest moja rola bertvv.rh-base. Przykład:

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

Ten użytkownik nie ma zezwolenia na logowanie do systemu (np. przez SSH) i uzyska dostęp tylko do współdzielonych zasobów Samby.

Definiowanie współdzielonych zasobów

Definiowanie współdzielonych zasobów Samby i konfigurowanie kontroli dostępu może być trudne, ponieważ wymaga nie tylko poprawnej konfiguracji Samby, ale także odpowiednich uprawnień użytkowników i plików oraz ustawień SELinux. Ta rola próbuje uprościć ten proces.

Aby określić współdzieloną zasobę, musisz przynajmniej nadać jej nazwę:

samba_shares:
  - name: readonlyshare

To stworzy współdzieloną zasobę z tylko dostępem do odczytu dla zarejestrowanych użytkowników. Goście nie będą mogli zobaczyć zawartości tej współdzielonej zasoby.

Dobrą metodą, by skonfigurować dostęp do zapisu dla zasobów, jest stworzenie grupy użytkowników systemowych, dodanie użytkowników do tej grupy oraz upewnienie się, że mają uprawnienia do zapisu w katalogu współdzielonej zasoby. Ta rola zakłada, że grupy są już skonfigurowane, a użytkownicy są członkami grup, które kontrolują dostęp do zapisu. Załóżmy, że masz dwóch użytkowników jack i teach, członków grupy pirates. Taka definicja współdzielonej zasoby nada obu użytkownikom dostęp do odczytu i zapisu:

samba_shares:
  - name: piratecove
    comment: 'Miejsce dla piratów na spotkanie'
    group: pirates
    write_list: +pirates

Goście nie mają dostępu do tej współdzielonej zasoby, zarejestrowani użytkownicy mogą odczytać jej zawartość. Możesz dodatkowo dostosować kontrolę dostępu. Dostęp do odczytu można rozszerzyć na gości (dodając public: yes) lub ograniczyć do określonych użytkowników lub grup (dodając valid_users: +pirates). Dostęp do zapisu można ograniczyć do poszczególnych użytkowników (np. write_list: jack). Pliki dodane do współdzielonej zasoby będą przypisywane do określonej grupy i dostęp do zapisu dla grupy będzie domyślnie przyznany.

Oto przykład konfigurowania wielu modułów obiektów vfs, aby współdzielić wolumen glusterfs. Opcje modułów VFS są opcjonalne. Niezbędne moduły obiektów VFS muszą być zainstalowane poza tą rolą. W tym przypadku samba-glusterfs został zainstalowany na centos. Zobacz dokumentację samby, aby dowiedzieć się, jak zainstalować lub jakie są domyślne moduły obiektów VFS.

samba_shares:
  - name: gluster-app_deploys
    comment: 'Dla współdzielonej zasoby samby wolumenu 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

Pełny przegląd opcji współdzielonych zasobów znajduje się poniżej. Tylko name jest wymagane, reszta jest opcjonalna.

Wartości dla valid_users i write_list powinny być listą użytkowników oddzieloną przecinkami. Nazwy poprzedzone + lub @ są interpretowane jako grupy. Dokumentacja dotycząca konfiguracji Samby zawiera więcej szczegółów na temat tych opcji.

Dodawanie dowolnych plików konfiguracyjnych

Możesz dodać ustawienia, które nie są wspierane przez tę rolę domyślnie, za pomocą niestandardowych plików konfiguracyjnych, które będą dołączane z głównego pliku konfiguracyjnego. Istnieją trzy rodzaje plików dołączanych: dla sekcji globalnej, dla sekcji domowej i dla poszczególnych współdzielonych zasobów. Umieść swoje niestandardowe pliki konfiguracyjne w podkatalogu templates, w relacji do lokalizacji głównego skryptu. Następnie określ je w zmiennych samba_global_include, samba_homes_include lub include_file w definicji samba_shares.

Twoje niestandardowe pliki konfiguracyjne są traktowane jako szablony Jinja, więc możesz używać zmiennych Ansible wewnątrz nich. Pliki konfiguracyjne będą walidowane, aby upewnić się, że są poprawne składniowo.

Na przykład, aby dołączyć templates/global-include.conf, ustaw:

samba_global_include: global-include.conf

Zauważ, że nie trzeba określać katalogu templates/.

Podobnie, aby dołączyć templates/piratecove-include.conf, specyficzny dla współdzielonej zasoby piratecove (patrz przykład powyżej); ustaw:

samba_shares:
  - name: piratecove
    comment: 'Miejsce dla piratów na spotkanie'
    group: pirates
    write_list: +pirates
    include_file: piratecove-include.conf

Skrypt testowy zawiera kilka przykładów. Niestandardowe pliki konfiguracyjne można znaleźć w gałęzi docker-tests.

Zależności

Brak zależności.

Przykładowy skrypt

Zobacz skrypt testowy

Testowanie

Ta rola jest testowana za pomocą Ansible Molecule. Testy są uruchamiane automatycznie na Travis CI po każdym zatwierdzeniu i propozycji zmian.

Ta konfiguracja Molecule będzie:

• Uruchomić Yamllint i Ansible Lint
• Utworzyć kontener Docker
• Sprawdzić składnię
• Zastosować rolę z skryptu testowego
• Uruchomić testy akceptacyjne z BATS

Ten proces jest powtarzany dla obsługiwanych dystrybucji Linuksa.

Lokalna środowisko testowe

Jeśli chcesz skonfigurować lokalne środowisko testowe, możesz użyć tej powtarzalnej konfiguracji opartej na Vagrant + VirtualBox: https://github.com/bertvv/ansible-testenv. Kroki do ręcznej instalacji niezbędnych narzędzi:

1. Docker, BATS i smbclient powinny być zainstalowane na twoim komputerze (zakładam, że działa na Linuksie). Nie powinny być uruchamiane żadne kontenery Docker, gdy uruchamiasz test.
2. Jak zaleca Molecule, stwórz wirtualne środowisko Pythona
3. Zainstaluj narzędzia programowe python3 -m pip install molecule docker yamllint ansible-lint
4. Przejdź do katalogu głównego katalogu roli i uruchom molecule test

Molecule automatycznie usuwa kontenery po teście. Jeśli chcesz samodzielnie sprawdzić kontenery, uruchom molecule converge, a następnie molecule login --host HOSTNAME.

Kontenery Docker są oparte na obrazach stworzonych przez Jeff'a Geerling'a, specjalnie do testów Ansible (szukaj obrazów nazwanych geerlingguy/docker-DISTRO-ansible). Możesz użyć dowolnego z jego obrazów, ale tylko dystrybucje wymienione w meta/main.yml są obsługiwane.

Domyślna konfiguracja uruchomi kontener Centos 7. Wybierz inną dystrybucję, ustawiając zmienną MOLECULE_DISTRO za pomocą polecenia, np.:

MOLECULE_DISTRO=debian9 molecule test

lub

MOLECULE_DISTRO=debian9 molecule converge

Możesz uruchomić testy akceptacyjne na obu serwerach za pomocą molecule verify lub ręcznie za pomocą

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

Musisz zainicjować zmienną SUT_IP, adres IP systemu testowego. Serwer, smb1, powinien mieć adres IP 172.17.0.2.

Wkład

Zgłoszenia błędów, prośby o funkcje, pomysły są mile widziane i można je zgłaszać w sekcji zgłoszeń.

Prośby o włączenie są również bardzo mile widziane. Najlepszym sposobem na złożenie PR jest najpierw stworzenie forka tego projektu Github, a następnie stworzenie gałęzi tematycznej dla proponowanej zmiany i wypchnięcie tej gałęzi do swojego forka. Github może następnie łatwo utworzyć PR na podstawie tej gałęzi. Nie zapomnij dodać się do listy współpracowników poniżej!

Licencja

Licencja BSD z dwoma klauzulami, patrz LICENSE.md

Współpracownicy

Ta rola mogła zostać zrealizowana tylko dzięki wkładom wymienionych poniżej osób. Jeśli masz pomysł, jak ją jeszcze bardziej ulepszyć, nie wahaj się dołączyć!

Zgłoszenia błędów, prośby o funkcje, pomysły, sugestie itp. Mogą być zgłaszane w sekcji zgłoszeń.

Prośby o włączenie są również bardzo mile widziane. Proszę stworzyć gałąź tematyczną dla proponowanych zmian. Jeśli tego nie zrobisz, spowoduje to konflikty w twoim forku po scaleniu. Nie wahaj się dodać się do listy współpracowników poniżej w swoim PR!

Ben Tomasik, Bengt Giger, Bert Van Vreckem (utrzymujący), 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.