Zarządzanie stacjami Windows za pomocą Cygwina, cz. I - Instalacja Cygwina i przygotowanie paczki do cichej instalacji

Cytat dnia:
The two basic principles of Windows system administration:

* For minor problems, reboot
* For major problems, reinstall

Ta idea przyświeca zapewne większości administratorów Windows (są oczywiście nieliczne wyjątki ale ja w swojej karierze takich nie spotkałem).
To będzie prawdopodobnie pierwszy z cyklu artykułów na temat zdalnego zarządzania stacjami Windows.
Od dłuższego czasu próbuję znaleźć rozsądny sposób na zarządzanie stacjami będącymi w domenie ale zarządzanymi przez serwer Linuksowy z działającą Sambą. Co to jest Samba? O tym opowiem z pewnością w przyszłości...
A teraz zajmijmy się zarządzaniem stacjami Windows.
Po dłuższym rozeznaniu tematu znalazłem pewien zestaw aplikacji open source wspomagających zarządzanie stacjami roboczymi. Pozwolę sobie je tu wymienić:
- projekt unattended-gui - umożliwia zarządzanie infrastrukturą, na pierwszy rzut oka niby wiele można (zarządzanie oprogramowaniem na stacjach windows, linux, konfiguracją sieci, switch'y, etc.) jednak nie znalazłem zbyt wielu informacji jak to się dokładnie robi. Możliwe jednak, że się mylę - na swoje usprawiedliwienie dodam, że przeglądałem to jedynie przez parę minut - projekt mnie nie przekonał, na tyle, żeby z niego skorzystać. Jednak na pewno będę miał go na oku.

- projekt kontrolpack - dostęp do zdalnej konsoli systemów Windows, Linux, Mac OS X. Działa w architekturze klient-serwer. Dosyć ciekawe rozwiązanie, jednak chyba jeszcze nie w pełni dopracowane. W trakcie testów doświadczyłem pewnych problemów ze zwieszaniem się klienta windowsowego przy odpalaniu skryptów Ruby. Wydaje się, że przy dużej liczbie stacji udostępnienie konsoli może być niewystarczającym rozwiązaniem. Nie znalazłem żadnych informacji na temat tworzenia grup hostów. Klient łączy się z serwerem na dziwnym porcie - wygląda na to, że korzysta z własnego protokołu transmisji - co mnie nie przekonuje - tym bardziej, że nigdzie w dokumentacji nie znalazłem informacji na temat sposobu wymianych danych między klientem a serwerem, a cóż tu dopiero mówić o jej bezpieczeństwie. Projekt rozwija się dynamicznie i miejmy nadzieję, że w krótkim czasie funkcjonalność i dokumentacja znacznie się poprawią.

- winexe - znalazłem gdzieś na forum, program umożliwiający zdalne podłączenie do stacji i uruchomienie dowolnego procesu. Pozwolę sobie w dalszym cyklu artykułów napisać o nim więcej.

- cygwin - nazwijmy go emulatorem środowiska Linux na windowsie. Dokładny opis można znaleźć w wikipedii

Poza programi open source warto wspomnieć o dwóch opcjach komercyjnych:
- program psexec - zdalne wykonywanie poleceń - podobnie jak winexe
- windows services for unix - odpowiednik cygwina stworzony przez Microsoft - ciężka kobyła (300MB) a nie ma nawet w pakiecie usługi ssh. Według Microsoftu ma przekonać administratorów *nix do środowiska windows i ułatwić ich migrację na nową platformę. Jednak w środowisku administratorów *nix program nazywany jest przewrotnie unix services for windows - krótko mówiąc brakująca proteza umożliwiająca w miarę rozsądną pracę w środowisku windows.
SFU po zainstalowaniu umożliwia połączenie ze stacją za pomocą protokołu telnet (przypominają się dawne czasy). Co prawda chłopaki coś wspominają o tym, że jest problem z przesyłaniem haseł plain tekstem przez sieć, ale przecież instalujemy to w zaufanej infrastrukturze - więc w czym rzecz? No jeśli już potrzebujecie to instalujcie openSSH - ale jak? To poszukajcie w sieci - mi się odechciało.

Po dłuższej analizie i licznych próbach (współ)pracy z powyższymi narzędziami dokonałem wyboru - tandem:
Cygwin, winexe i Ruby (jako język skryptowy) powinien zaspokoić moje potrzeby/wydumane wymagania.

Teraz po krótce pozwolę sobie opisać na początek kolejne kroki instalacji i przygotowywania pakietu Cygwin do używania w zarządzaniu stacjami Windows.

Pojawia się tu kilka niuansów nad którymi spędziłem trochę czasu, szczególnie wredny jest etap przygotowywania cichej instalacji i sama cicha instalacja.

Ze strony głównej projektu Cygwin ściągamy instalkę setup.exe.

Lista dostępnych opcji instalatora:
-D --download Download from internet
-L --local-install Install from local directory
-s --site Download site
-R --root Root installation directory
-q --quiet-mode Unattended setup mode
-h --help print help
-l --local-package-dir Local package directory
-r --no-replaceonreboot Disable replacing in-use files on next
reboot.
-n --no-shortcuts Disable creation of desktop and start
menu shortcuts
-N --no-startmenu Disable creation of start menu shortcut
-d --no-desktop Disable creation of desktop shortcut
-A --disable-buggy-antivirus Disable known or suspected buggy anti
virus software packages during
execution.

*Przygotowanie paczki cygwin do cichej instalacji na wielu stacjach roboczych
- Uruchamiamy setup.exe
- wybieramy katalog docelowy (c:\cygwin)
- wybieramy lokalny katalog repozytorium pakietów (c:\cygwin-root\root-dir) - należy go stworzyć przed instalacją
- wybieramy instalację z sieci
- wybieramy mirror (w sumie dowolny)
- wybieramy dodatkowe paczki do zainstalowania (z bardziej przydatnych: openssh, wget, procps, linux-utils, netcat)
- przechodzimy przez kolejne kroki instalatora

Po zainstalowaniu cygwina w katalogu z repozytoriami (c:\cygwin-root\root-dir) pojawi się folder, którego nazwa będzie adresem serwera źródeł instalacji (mirror) wybranego w trakcie uruchomienia instalatora cygwin.
Sam cygwin zainstaluje się w c:\cygwin.
Musimy teraz odtworzyć strukturę z konfiguracją zainstalowanego cygwina w katalogu c:\cygwin-root:
- tworzymy katalog c:\cygwin-root\cygwin\etc\setup
- przegrywamy z c:\cygwin\etc\setup do katalogu c:\cygwin-root\cygwin\etc\setup wszystkie pliki, których nazwa zaczyna się od last- (last-*)
- kopiujemy z c:\cygwin\etc\setup do c:\cygwin-root\cygwin\etc\setup plik setup.ini

Mamy już gotową konfigurację, którą możemy posłużyć się przy kolejnych instalacjach cygwina na stacjach roboczych.

*Cicha instalacja paczki cygwin na stacji roboczej
- tworzymy katalog c:\cygwin
- kopiujemy katalog c:\cygwin-root\cygwin\etc do c:\cygwin
- uruchamiamy instalator w trybie cichej instalacji:

setup.exe -q -R c:\cygwin -L -l c:\cygwin-root\root-dir

Jeżeli chcemy mieć Cygwin'a zainstalowanego na dysky systemowym zamiast identyfikatora napędu (c:) warto użyć zmiennej systemowej %systemdrive%

*Uruchomienie usługi SSH na stacji
Rejestracja SVC
- uruchamiamy konsolę cygwina
- uruchamiamy polecenie ssh-host-config
- odpowiadamy na zadawane pytania:
"privilege separation" => yes
"create local user sshd" => yes
"install sshd as a service" => yes
"CYGWIN=" => ntsec tty
- jeżeli pojawią się błędy - należy poprawić ustawienia systemu zgodnie z zaleceniami, które wyświetli ssh-host-config
- uruchamiamy utworzony serwis sshd za pomocą jednej z dwóch komend

net start sshd
cygrunsrv --start sshd

Teraz trzeba jeszcze odblokować usługę na firewall'u:

cmd /c if exist c:\windows\system32\netsh.exe netsh firewall set allowedprogram c:\cygwin\usr\sbin\sshd.exe SSHD enable

Muszę przyznać, że zarządzanie firewallem Windowsowym jest bardzo podobne do tworzenia reguł za pomocą iptables (o ile nie robimy tego w GUI ;)), a więc bardzo wygodne - ale o tym to już innym razem.

WAŻNE!
*Żeby użytkownicy Windows mogli się logować należy synchronizować bazy danych użytkowników w Windowsie ze środowiskiem Cygwin. Robimy to za pomocą:

mkpasswd -cl > /etc/passwd
mkgroup --local > /etc/group

*Zawsze upewnij się, że każdy użytkownik w systemie ma ustawione hasło do logowania.

Przydatne linki:
Projekt Cygwin
Cygwin FAQ
Z jakiegoś forum na temat instalacji Cygwina

Zdalny pipe

Dziś kolega 'junior admin' podniecił się strasznie możliwością przekierowywania standardowego wyjścia programu na standardowe wejście kolejnego między lokalnym i zdalnym systemem, czyli tzw. pipem. Zacznijmy od dwóch przykładów, które mi podesłał:

tar cf - whatever | ssh remotehost " ( cd /some/path ; tar xf - ) "
ssh remotehost "( cd /somewhere ; tar cf - something ) " | tar xf -

W pierwszej linijce pakujemy (bez kompresji) zadaną jako drugi parametr listę plików, pierwszym parametrem jest w tym wypadku znak '-' często używany jeśli chcemy uzyskać coś na STDOUT zamiast zapisać gdzieś w pliku, gdy program to umożliwia. Tak więc znak '-' informuje polecenie tar, że zamiast zapisywać tworzone archiwum do pliku ma wyrzucić wynik na standardowe wyjście (czyli w linuksie plik o deskryptorze 1).
Następnie mamy | czyli przekierowanie/przekazanie standardowego wyjścia poprzednio wykonywanej komendy (opisanej już jedyneczki) na standardowe wejście kolejnej komendy (STDIN - czyli deskryptor pliku o identyfikatorze 0 [zero])
Kolejnym poleceniem jest wywołanie ssh - nawiąż połączenie z hostem remotehost i wykonaj polecenia podane jako kolejny parametr. Podajemy je w cudzysłowiu, żeby bash w trakcie przetwarzania nie potraktował spacji jako separatora kolejnych argumentów (pewnie poleciałyby błedy - można spróbować - na pewno coś 'chorego' się stanie. O interpretacji linii poleceń przez shell to może innym razem - jak ktoś z czytelników będzie bardzo tego chciał).
Pozostaje więc ostatnia część:

cd /some/path ; tar xf -

To już dosyć proste - zmieniamy ścieżkę i rozpakowujemy archiwum poleceniem tar (x - extract). Pojawia się znowu magiczny minus. W wypadku rozpakowywania (jak co poniektórzy pewnie się domyślają) minus mówi o tym, że źródłem z którego należy czytać nie jest plik a standardowe wejście (przytaczane wcześniej zero).

Drugi przypadek pozostawiam do samodzielnej analizy. W razie problemów i pytań służę pomocą

Do samodzielnej lektury polecam wikipedię

• wersja angielska
  
• polska - też jest ale jest dużo mniej informacji

Co mi tu jeszcze ciekawego przyszło do głowy. Każdy program po wykonaniu zwraca status wykonania w postaci liczbowej. Znajdziemy go w zmiennej shella $?:

echo $?

Jeżeli program wykonał się poprawnie - nie pojawiły się błędy - to status powinien być równy 0 [zero]. W przypadku problemów będzie to cyfra różna od zero - to co będzie oznaczać zależy już od programu. Warto sprawdzać tą zmienną pisząc skrypty - przez co możemy przerwać je w odpowiednim momencie, gdy coś pójdzie nie tak a nie zostawić wszystko dalszemu biegowi wypadków.
A co w wypadku gdy łączymy kilka poleceń w pipe? Jak wykryć, że któreś (nieostatnie) polecenie wykonało się niepoprawnie?

Odpowiedź w przyszłym blogu...
Może warto poszukać samemu?

Czekam na komentarze...

kopiowanie plików na zdalne serwery

Możliwości jest wiele. Od prostego scp, przez rsync'a wywoływanego na wiele sposobów, poprzez netcat'a, montowanie zdalnego zasobu przez sshfs lub temu podobne drivery do sftp, żeby nie wspomnieć tu o standardowym ftp lub uniksowych nfs-ach. Znalazło by się jeszcze wiele innych, o których albo nie pamiętam albo w momencie pisania nie przyszły mi do głowy. Open source - open mind.

• SCP

Znajduje się w pakiecie z projektu openBSD - openSSH. Najczęscie (w debianie będzie to prawdopodobnie pakiet openssh-client, w gentoo po prostu openssh)

Najprościej można tak:
scp plik_lokalny [user@]host_zdalny:/sciezka/w/filesystemie [-p 22]

-p 22 to port na który łączymy się ze zdalnym hostem.
Popatrz tez w man. Warto z tego polecenia często korzystać - szczególnie na początku, gdy system kryje w sobie mnóstwo tajemnic.
i pojedynczy plik jest skopiowany o ile użytkownik może pisać w określonej zdalnej lokalizacji.
Skopiowaliśmy pojedynczy plik. A co jeśli chcemy skopiować część struktury katalogów. Powiedzmy podkatalog '/home/foo'. Użyjmy przełącznika -r (recursive). Musimy uważać jedynie na symlinki (o tym innym razem) ponieważ scp podąży za tymi linkami i zamiast skopiować informację o linku - przeniesie nam całą zawartość, na którą wskazuje symlink - a to może kosztować sporo miejsca i powielić nam struktury w filesystemie. Zamiast -r często warto najpierw skompresować zawartość, którą zamierzamy przenieść i nie przejmować się problemami związanymi z użyciem przełącznika -r.

Przypomniało mi się jeszcze o dd. Można też w pipe puścić wejście dd i z drugie strony tunelu ssh zapisać do pliku wynikowego. Ale o tym może innym razem.

Jest jeszcze conajmnie jeden problem, który jest związany z użyciem scp. Mianowicie gdy coś nam przerwie transmisję, to możemy śmiało zaczynać kopiowanie od zera - nic się nie da zrobić (przynajmniej tak mi się wydaje).

Warto wtedy pomyśleć o użyciu

• rsync
  

Jak można wnioskować z nazwy - remote sync, czyli synchronizacja z systemem zdalnym. Narządko ma ciekawą właściwość, o której wspomnę kolejnym razem. Teraz powiem tylko tyle, że pozwala na szybkie i bezpieczne synchronizowanie zasobów, przy niewielkim zużyciu łącza w wypadkach gdy dane są w znacznym stopniu synchronizowane. Pozwala to ponowić przerwany transport od miejsca jego zakończenia. Polecam artykuł na wikipedii o rsync.

Jako przykład, z którego korzystałem przed chwilką podam:
rsync galeria.tar.bz2 -ave ssh ssh.linuxway.eu:/home/galeria.tar.bz2

Zgłębienie składni pozostawiam czytelnikowi.