sevos site

Serwer grup dyskusyjnych

Wstęp

W firmie często potrzeba wymieniać informacje i pomysły między pracownikami, czasem ktoś wymaga pomocy. Z początku wysyłaliśmy sobie e-maile adresowane do wszystkich pracowników. Pomysł dobry na krótką metę. Nie trzeba wchodzić na forum (otwierać przeglądarki), wszystko mamy w jednym programie służącym do wymiany wiadomości, żadnych też dodatkowych programów. Rewelacja. Z czasem dojdziemy do wniosku, że takie rozwiązanie nie jest zbyt wygodne. Duża liczba listów, dyskusji, brak centralnego archiwum sprawia, że ciężko jest zapanować nad bazą wiedzy, którą z pewnością mogłyby się te wiadomości stać. Przykłady: ogłoszenia nowych projektów, dyskusje projektantów, wsparcie techniczne wewnątrz ekipy programistów etc.

Czytając jakiś czas temu notatnik Marcina Kasperskiego natrafiłem na artykuł poświęcony zagadnieniom grupowej komunikacji w firmie, projekcie wspomaganej serwerem grup dyskusyjnych INN. Marcin wyjaśnił w nim, jak można wykorzystać taki serwer do usprawnienia komunikacji i rozwiązywania problemów. Nie będę się więc rozpisywał na ten temat. Dodam tylko, że postanowiłem zaimplementować testowo to rozwiązanie w swojej grupie roboczej.

Artykuł ten ma w założeniu przedstawić w jednym miejscu sposób rozwiązania, do którego po kilku godzinach googlowania (może źle szukałem?) doszedłem i póki co mnie satysfakcjonuje. Nie chcę sobie w żaden sposób przypisywać monopolu na prawdę, czy też twierdzić, że nie dało się tego zrobić lepiej. Na pewno się da. Rozwiązanie to jednak sprawdza się i mnie oraz moim Współpracownikom wystarcza. Jeżeli by ktoś kiedyś z niego skorzystał, to dobrze. Ktoś może stwierdzić, że artykuł jest niepotrzebny, że jest wiele HOWTO. Przyznam, że brakowało mi przykładu działającej konfiguracji.

Do dzieła!

Dalej przedstawię przykład konfigurowania prostego serwera INN z przeznaczeniem do wewnętrznego użytku dla grupy roboczej, firmy czy też nawet korporacji. Ograniczę liczbę grup roboczych do minimum, aby nie zaśmiecać sensu. Poruszę wyłącznie aspekty, które wydają mi się istotne do sprawnego uruchomienia serwera INN z autoryzacją użytkowników.

Instalacja

W każdej dystrybucji programy instaluje się w nieco inny sposób. Należy zainstalować serwer INN w wersji drugiej. Jest to istotne dla tego przykładu. W starszej wersji nie doszukałem się możliwości przechowywania haseł użytkowników w osobnym pliku w postaci, która uniemożliwia ich poznanie w przypadku włamania na serwer.

W Debianie zainstalujemy serwer poprzez

~# apt-get install inn2

Wstępna konfiguracja

Po instalacji należy wykonać podstawową konfigurację, czyli wyedytować plik /etc/news/inn.conf. Ja wyedytowałem jeszcze plik expire.ctl komentując wszystkei linie i wpisując:

*:A:never:never:never

Dzięki temu nagłówki wiadomości nie będą się przedawniały.

Uruchomienie serwera i dodanie grup

Czas uruchomić serwer grup dyskusyjnych. Wraz z aplikacją serwera dostarczona jest aplikacja ctlinnd dzięki której można m. in. dodawać nowe grupy. W Debianie innd uruchomimy poleceniem:

~# /etc/init.d/inn2 start

Aby dodać nową grupę o nazwie firma.ogloszenia, nalezy wydać polecenie:
ctlinnd newgroup firma.ogloszenia
Postępując w ten sposób łatwo jednak o pomyłkę przy tworzeniu hierarchii grup. W dodatku zauwazyłem, że w INN usuwanie grup nie sprowadza się jedynie do wydania polecenia ctlinnd rmgroup nazwa_grupy. Później przy dodawaniu nowych grup pojawiają się kłopoty z przyjmowaniem postów do grup powstałych po usunięciu jakiejś grupy (sam to naprawiłem, usuwając z katalogu /var/spool/news/articles katalog grupy, usunąłem problematyczną grupy i dodałem ją ponownie, ale nie jestem pewien jaka jest prawidłowa procedura). Polecam zatem drugi sposób.

Hurtowe dodawanie grup

Przygotujmy plik tekstowy zawierający listę grup do dodania - każdą w osobnej linii:

~# cat group.list
firma.ogloszenia
firma.dev
firma.pogawedka

Do przetworzenia takiej listy użyjemy poniższego skryptu:

#!/bin/bash
ctlinnd throttle przerwa
cat - | while read G; do ctlinnd newgroup $G; done
ctlinnd go przerwa

Należy zapisać go sobie na przykład w katalogu domowym root-a i nadać mu prawa wykonywania. Później przekierowujemy plik do skryptu:

~# cat group.list | ./dodaj-grupy

i cieszymy się nowymi grupami na naszym serwerze :). Sposób ten pozwala na uniknięcie pomyłek w nazwach i porządku grup, co zapobiega potencjalnym niedogodnościom.

Autoryzacja

Nad tą częscią konfiguracji spędziłem najwięcej czasu. Autoryzacja w inn odbywa się po adresie hosta lub poprzez parę użytkownik/hasło przesyłanych przez klienta. Do sprawdzania hasła służy program ckpasswd. Ustawień uprawnień dokonuje się w pliku readers.conf. Ja zdecydowałem się na uwierzytelnianie za pomocą hasła. ckpasswd pozwala na wykorzystanie systemowej bazy użytkowników mieszczącej się w plikach /etc/passwd i /etc/shadow, jednak w związku z tym, że mój serwer jest maszyną współdzieloną przez inne usługi i użytkowników, zrezygnowałem z tej możliwości. Wykorzystując program htpasswd dołączony do serwera Apache utworzyłem plik z bazą użytkowników.

Nazwy użytkowników

Aby ułatwić sobie zarządzanie grupami użytkowników (przydałbyby się przynajmniej dwie grupy - tych bardziej uprzywilejowanych i tych mniej) zastosowałem małe oszustwo. Nazwy użytkowników zapisywałem do pliku z bazą haseł jako użytkownik@wirtualna_grupa, np.

~# htpasswd -c /etc/news/passwd.db kazio@firma
~# htpasswd /etc/news/passwd.db jasio75@firma
~# htpasswd /etc/news/passwd.db maciek@firma
~# htpasswd /etc/news/passwd.db sevos@admin
~# htpasswd /etc/news/passwd.db krzysiek@admin

Utworzyłem sobie w ten sposób dwie wirtualne grupy użytkowników: firma i admin. Dla wyjaśnienia dodam, że tych grup nigdzie nie trzeba konfigurować, to tylko umowna konwencja nadawania nazw użytkownikom naszego serwera news.

Należy upewnić się, że właścicielem pliku z bazą użytkowników jest użytkownik, z jakiego prawami uruchamiany jest serwer innd, przeważnie news:

~# chown news /etc/news/passwd.db

readers.conf

W pliku readers.conf znajdują się sekcje odpowiedzialne za autoryzację i za przydzielanie uprawnień użytkownikom. Pierwszy rodzaj sekcji to auth. Tu ustala się reguły autoryzacji użytkowników i rozpoznawanie ich nazwy. Drugi - access, która na podstawie rozpoznanej nazwy użytkownika przydziela odpowiednie uprawnienia. Plik jest przetwarzany z góry do dołu, to znaczy, że ostatnia pasująca sekcja access nada kształt uprawnieniom użytkownika dla tych grup, które opisuje.

Sekcja auth

W tej sekcji serwer rozpoznaje użytkownika, który się z nim łączy. Autoryzacja może odbywać się na podstawie adresu hosta lub przez parę użytkownik/hasło przesłane przez klienta. W moim przypadku skorzystałem z wcześniej przygotowanej bazy użytkowników:

auth haslo {
auth: "ckpasswd -f /etc/news/passwd.db"
}

Ważne! Niektóre źródła podają, że należy, badź można podawać ścieżkę bewzględną do programu ckpasswd. Jest to błąd, ponieważ przy wywołaniu doklejana jest z przodu ścieżka do katalogu, gdzie się ten program znajduje (ustawienie z pliku inn.conf).

Jeżeli klient zostanie rozpoznany to nazwa użytkownika zostaje zachowana w pamięci do dalszego przetworzenia przez sekcję access.

Sekcja access

W sekcjach access przydzielane są prawa użytkownikowi do odczytu i pisania do określonych grup na podstawie jego nazwy (można używać maski *). Przykład:

access firma {
users: "*@firma"
read: firma.*
post: firma.*, !firma.ogloszenia
}

Tutaj użytkownik nalezący do naszej wirtualnej grupy firma otrzymuje dostęp do odczytu do wszystkich podgrup firma.* i do zapisu z wyłączeniem grupy firma.ogloszenia.

Przykładowy plik

Podczas przeglądania sieci najtrudniej było mi znaleźć przykładowy plik do tego własnie zastosowania.

# domyślnie odcinamy anonimowych
auth anonymous {
hosts: *
default: "anonymous"
}
access anonymous {
users: "anonymous"
newsgroups: "!*"
}
# sprawdzamy bazę
auth haslo {
auth: "ckpasswd -f /etc/news/passwd.db"
}
# użytkownicy z grupy firma
access firma {
users: "*@firma"
read: firma.*
post: firma.*, !firma.ogloszenia
}
# użytkownicy z grupy admin - pełny dostęp
access admin {
users: "*@admin"
read: firma.*
post: firma.*
}

Podsumowanie

Taka konfiguracja powinna pozwolić osiągnąć nam zamierzony efekt: konieczność zalogowania użytkownika na serwer news i przydzielenie mu stosownych uprawnień. Mam nadzieję, że się komuś przyda.

W niedalekiej przyszłości opisze jeszcze mój, dość prymitywny ale działający, sposób na pozwolenie użytkownikom na zmianę swoich haseł do serwera news. Jednak skrypt to umozliwiający wymaga kilku poprawek przed upublicznieniem

Tagi: autoryzacja, grupy dyskusyjne, inn, przykład, serwer