K-NET s.c.

Roaming Profile – kopia zapasowa c.d.

Dwa miesiące temu pisałem o tym jak zrobić kopie zapasową profilu typu Roaming Profile w sieci Active Directory. W trakcie korzystania przez cały ten czas z opisywanego narzędzia psexec będącego częścią pakietu SysInternals PSTools okazało się, że potrafi ono odmówić posłuszeństwa. Każda próba uruchomienia środowiska za jego pomocą kończy się komunikatem:

Error communicating with PsExec service

Próba zwyczajnego przeinstalowania pakietu nie pomaga. Okazuje się, że antidotum w tej sytuacji jest wykonanie poniższej procedury i nie pytajcie mnie dlaczego to działa akurat w taki sposób:

1. Na komputerze z zainstalowaną usługą psexec należy ją po prostu zatrzymać. Można to zrobić za pomocą GUI lub za pomocą polecenia pskill.
2. Na drugim komputerze trzeba zdalnie usunąć psexec poleceniem sc \\nazwa_naprawianego_komputera delete psexesvc.
3. Dopiero teraz można ponownie zainstalować pakiet PSTools ponownie.

Hmm…, dziwne.

MG

Roaming Profile – kopia zapasowa

Domena MS Active Directory umozliwia przechowywanie profilu użytkownika w postaci tzw. Roaming Profile. Oznacza to, że przede wszystkim dane użytkowników mogą byc składowane na serwerze i umieszczone w odpowiednim współdzielonym katalogu. Główną zaletą takiego rozwiązania (pominę tym razem wady) jest umożliwienie pracy z każdej końcówki w domenie ponieważ po zalogowaniu profil użytkownika jest przesyłany na stację roboczą. Zaś podczas pracy system dba o synchronizację jego zawartości z serwerem. Brzmi całkiem nieźle i powiedzmy, że generalnie się sprawdza.

W skład profilu użytkownika wchodzą przede wszystkim jego pliki i poczta ale również ustawienia związane z całym spersonalizowanym środowiskiem pracy – czyli profil użytkownika w całości. Są to dane bardzo wrażliwe na zmiany. Powszechnie wiadomo czym może zakończyć się ręczne modyfikowanie profilu Windows. Stąd Roaming Profile przechowywany na serwerze ma odpowiedni poziom zabezpieczeń. Dostęp do swoich plików ma praktycznie tylko ich użytkownik. Nie ma go nawet administrator. Co jednak można zrobić w sytuacji gdy powinniśmy (jako administrator) wykonywać kopie zapasową profilu użytkownika?

Rozwiązaniem tego problemu jest zmodyfikowanie uprawnień dla poszczególnych katalogów wewnątrz profilu użytkownika. Aby chronić środowisko pracy najlepiej jest ograniczyć się np. tylko do katalogów: Pulpit i Moje dokumenty (większość cennych danych znajduje się właśnie tutaj).

Zaczynamy od pobrania narzędzia PSTools ze strony SysInternals. Po rozpakowaniu pliku PSTools.zip, z katalogu PSTools uruchamiamy okienko systemowe poleceniem:

psexec -i -s cmd.exe

Potem korzystając z otworzonego okna systemowego (wywołanego z najwyższymi uprawnieniamy – SYSTEM, należy korzystać bardzo ostrożnie) wydajemy polecenie zmieniające uprawnienia dla wybranego katalogu:

icacls "D:\Profiles\*" /grant "domain admins":(OI)(CI)F /T

Naturalnie przykładowa ścieżkę D:\Profiles\* zmieniamy na docelową dla swoich zastosowań (np. wspomniany Pulpit lub Moje dokumenty).

MG

update.rc-d vs rc.local vs @reboot

Tym razem chciałem przedstawić krótki i treściwy wpis na temat uruchamiana aplikacji w trakcie startu serwerowego systemu operacyjnego. Sprawa dotyczy mojego ulubionego Debiana. Właściwie najabardziej elegancką i zgodną z regułami metodą jest umieszczenie skryptu startowego w katalogu /etc/init.d/, nadanie mu praw wykonywalnych i wywołanie polecenia:

update-rc.d nasz_skrypt defaults 99

Niemniej z różnych przyczyn nie zawsze się to udaje. Trzeba podejść do tematu inaczej. Od razu zaznaczam, że poniższe metody, jakkolwiek spełniające swój cel, są po prostu bardzo nieeleganckie i nie świadczą najlepiej o umiejętnościach administratora. Czasami jednak trzeba się ugiąć – chociażby pod presją czasu.

Druga metoda polega na dopisaniu skryptu do pliku /etc/rc.local. Generalnie tym sposobem można rozwiązać dużo problemów ale osobiście stosuje go tylko doraźnie. Polecam to jako rozwiązanie tymczasowe.

Trzecia metoda, kiedy zawiodą dwie poprzednie, to umieszczenie skryptu startowego w cronie systemowym dla konta root. Wywołujemy go poleceniem:

crontab -e

a następnie na końcu pliku dopisujemy linijkę:

@reboot /ścieżka_dostępu/nasz_skrypt

Od tego momentu, za każdym razem podczas uruchamiania się systemu, automatycznie będzie wykonywał się skrypt. Mało elegancko ale skutecznie.

MG

Konfigurowanie użytkowników systemowych na serwerze Samba w środowisku Active Directory

Praktyka związana z budowaniem sieci komputerowych w małych i średnich firmach pokazuje, że często jesteśmy zmuszeni tworzyć środowiska heterogeniczne, gdzie np. domena Active Directory AD współpracuje z linuksowym sewerem plików Samba SMB. Aby ten dość często spotykany tandem był w pełni funkcjonalny dobrze jest zintegrować bazę użytkowników AD z kontami dla serwera SMB. Nie chcę tutaj poruszać problemów związanych z samą konfiguracją po stronie Linuksa – jest to wielokrotnie omawione w sieci (jeden z najlepszych poradników howto można znaleźć pod tym adresem). Tym razem chciałbym pokazać jak rozdzielić na serwerze Debian użytkowników AD od systemowych.

W przypadku integrowania serwera plików z domeną mamy dwie możliwości:

• albo wszystkie konta będą przechowywane w katalogu Active Directory
• albo na serwerze linuksowym pozostawimy część natywnych kont systemowych

Osobiście zawsze wybieram tą drugą opcję, chociażby dlatego aby uniezależnić niektóre usługi systemowe od domeny. Takie podejście bywa często krytykowane, szczególnie przez zwolenników centralnego zarządzania. Niemniej jest spotykane i stosowane. Problem z opisywaną konfiguracją polega na tym, że łącząc nasz serwer z domeną musimy włączyć protokół uwierzytelniania Kerberos. Przy standardowej konfiguracji oznacza to, że wszyscy użytkownicy o identyfikatorze UID większym równym 1000, będą autoryzowani na poziomie domeny (oznacza to, że np. nie zadziałają prawidłowo polecenia passwd i useradd).

Jak zwykle w takich przypadkach istnieje wiele rozwiązań, o czym można przekonać się poszukując materiałów w sieci. Niemniej najprostszym i prawdopodobnie najszybszym będzie wyedytowanie pliku/etc/pam.d/common-password. Następnie należy zmienić wartość paramteru minimum_uid (która domyślnie wynosi 1000):

password requisite pam_krb5.so minimum_uid=2000

Powyższy wpis oznacza, że odtąd użytkownicy LDAP (którzy w tym przypadku są użytkownikami AD) mają identyfikatory UID zaczynające się od 2000, zaś lokalny administrator linuksowy może spokojnie operować na kontach systemowych.

MG

Administracja usługami za pomocą rcconf i sysv-rc-conf

Jeśli chcemy precyzyjnie zarządzać demonami systemowymi uruchamianymi w trakcie startu sytemu to pakiety rcconf i sysv-rc-conf mogą okazać niezastąpionym narzędziem. Wyobraźmy sobie, że administrujemy sewerem Debian bez powłoki graficznej. Aby dodać lub usunąć usługę systemową do listy procesów startowych możemy skorzystać z dobrze znanego skryptu update-rc.d. Niestety, zdarza się, że podczas jego użycia napotkamy błędy związane ze skryptami startowymi. Co można zrobić w takiej sytuacji? Jeżeli zależy nam na czasie, proponuje zainstalować z repozytorium odpowiednie narzędzia:

apt-get install rcconf
apt-get install sysv-rc-conf

Następnie wystarczy wydać odpowiednią komende z linii poleceń i rozpocząć konfiguracje systemu. rcconf jest nakładką (front-end) dla skryptów update-rc.d, zaś sysv-rc-conf to rozbudowane narzędzie, które umożliwia np. szczegółowe dodawanie i suwanie usług w zależności od poziomu startowego (runlevel). Tak czy inaczej obydwa są bardzo przejrzyste i intuicyjne. Myśle, że poradzi sobie z nimi każdy, nawet początkujący administrator.

MG

Dovecot, Postfix, IMAP – Operation not permitted

Dzisiaj krótki, wakacyjny wpis dotyczący błędu związanegoz konfiguracją obsługi IMAP za pomocą Dovecot. W tandemie ze standardowo skonfigurowanym Postfixem, gdy zdecydowaliśmy się przechowywać pocztę w formacie mbox w katalogu /var/mail/ przy próbie pobrania poczty za pomocą dowolnego programu pocztowego (np. Thunderbird) w pliku /var/log/mail.log mogą pojawić się następujace błędy:

dovecot: imap(...):
Error: chown(...) failed: Operation not permitted
Error: mkdir(...) failed: Operation not permitted
Error: fchown(...) failed: Operation not permitted
Error: file_dotlock_create(...) failed: Permission denied

Jest to związane z niewystarczającymi uprawnieniami w katalogu użytkownika. Zgodnie z dokumentacją powinniśmy zajrzeć na stronę z opisem roziwązania http://wiki2.dovecot.org/Errors/ChgrpNoPerm. Ponieważ dla mnie obydwa omawiane tam rozwiązania wyglądają niedobrze, proponuję zastosować w pliku /etc/dovecot/conf.d/10-mail.conf zastosować następującą łatkę, w miejsce linijki:

mail_location = mbox:~/mail:INBOX=/var/mail/%u

podstawić:

mail_location = mbox:~/mail/mailboxes:INBOX=/var/mail/%u:→
DIRNAME=mBoX-MeSsAgEs:INDEX=~/mail/index:CONTROL=~/mail/control

Sprawdziłem… pomaga. Tak jak obiecałem – krótko i na temat136.

MG

Plik wsadowy ze skryptem PowerShell dla serwera MS Exchange

PowerShell to rozbudowane, konsolowe narzędzie do administracji systemem operacyjnym Windows Server. Długie polecenia, ilość opcji a także niezrozumiałe, na pierwszy rzut oka, przełączniki powodują, że rozwiązanie to może zniechęcić. Tym bardziej, jeśli ktoś jest amatorem tzw. 'wyklikiwania’ poleceń. Niemniej jest to najlepsza, o ile nie jedyna, droga do pisania skryptów systemowych, które można dodać do schedulera systemowego i tym samym załatwić sobie dużo wolnego czasu.

Standardowo PowerShell wykorzystywany jest do czynności ogólno-systemowych. Jednak instalując nowe usługi na swoim serwerze np. Microsoft Exchange Server, otrzymujemy dostęp do zmodyfikowanego pod kątem Exchange środowiska PowerShell, która umożliwia zarządzanie. Czy można zatem przygotować skrypt, który będzie wykonywany w tle i będzie korzystał z komend właściwych dla wspomnianego środowiska? Można i należy to robić, szczególnie w przypadku takich zadań jak chociażby raportowanie zdarzeń itp.

Zamieszczony poniżej przykład pokazuje jak powinien wyglądać plik wsadowy (może być to popularny batch), który wywoła środowisko PowerShell dla MS Exchange a następnie przygotuje raport w pliku, zawierający listę przekierowanych kont pocztowych. W praktyce, część polecenia, oznaczona kolorem szarym jest uniwersalna, w oznaczonej na zielono skorzystałem z komendy (cmdletu) Get-Mailbox-Server. Może zostać ona zamieniona na każdy inny cmdlet wg pomysłu użytkownika.

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -version 2.0→
-NonInteractive -WindowStyle Hidden -command ". 'C:\Program Files\→
Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1';→ 
Connect-ExchangeServer -auto; Get-Mailbox -Server→ 
{nazwa serwera MS Exchange} -Filter 'ForwardingAddress -ne $null' |→ 
out-file -filepath {nazwa pliku ze ścieżką}"

MG

Heartbleed, Shorewall i czarne listy

Dzisiaj, krótki świąteczny wpis dla adminstratorów codzienie zmagających się ze skryptami skanującymi porty naszych serwerów. Rozgłos jaki zyskał Heartbleed, w rzeczy samej jedna z najpoważniejszych luk w bibliotece OpenSSL, zaowocował zwiększoną aktywnością tzw. script-kiddies, którzy natychmiast ruszyli do 'ataku’. W logach systemowych zaczęły pojawiać się w dużej ilości ostrzeżenia dotyczące błedów sesji TLS. Niezależnie o typu usługi tj. SMTPS, POP3S, HTTPS, każda może zostać zaatakowana. Jak zauważyłem większość tego typu starań ma swoje źródła w państwach powszechnie znanych z sieciowych parktyk siłowych, mam na myśli metodę brute-force. Znudzony nieustannym zalewaniem informacją o nieudanych połączeniach postanowiłem pójść na całość i dosłownie wyciąć ruch pochodzący z najbardziej aktywnych sieci IP. W jaki sposób? Z pomocą przychodzi jak zwykle niezawodny Shorewall, który znacznie upraszcza zarządzanie iptables. W tym przypadku w pliku blacklist podajemy adres sieci w notacji CIDR bez żadnych opcji, np. po prostu:

10.10.10.0/24

W ten sposób blokujemy cały ruch. Trzeba jednak pamiętać, żeby przypadkiem nie odciąć swoich użytkowników. Zatem ostrożnie!

MG

Jak naprawić URL po przeniesieniu witryny WordPress pod nowy adres

WordPress jest jednym z najbardziej popularnych systemów zarządzania treścią tzw. CMS. Sam używam wyłącznie WordPressa i wysoko go sobie cenie. Nie chciałbym rozpisywać się o zaletach tego oprogramowania, jak również tworzyć kolejnego poradnika instalacji czy konfiguracji. Materiałów w sieci jest wystarczająco dużo. Tym razem chciałbym pokazać jak rozwiązać bardzo konkretny problem, związany z przenoszeniem, tworzeniem kopii testowych itp. witryn utworzonych za pomocą opisywanego CMSa.

Generalnie, wykonywanie kopii witryn WordPressa to przede wszystkim:

• kopiowanie i przenoszenie bazy danych oraz
• kopiowanie i przenoszenie całej struktury katalogów i plików

Niemniej, nawet jeżeli całkiem nieźle radzimy sobie z powyższymi zadaniami to trzeba pamiętać, że nasza strona WordPress jest widoczna jako adres URL w sieci np. 'www.strona-wp.pl’. Tworząc jej kopie albo przenosząc pod nowy adres trzeba pamiętać o uaktualnieniu bazy danych. WordPress zapisuje bowiem wyświetlane elementy typu grafiki, dokumenty itp. za pomocą ich adresu URL. Często, przeniesiona strona, właśnie z tego powodu nie chce wyswietlać żadnych grafik bądź innych obiektów. Co możemy zrobić? Wykonać trzy polecenia UPDATE w środowisku bazy danych:

1. UPDATE wp_options SET option_value = replace(option_value, →
   'http://www.stary-adres.pl', 'http://www.nowy-adres.pl') →
   WHERE option_name = 'home' OR option_name = 'siteurl';

2. UPDATE wp_posts SET guid = replace(guid, →
   'http://www.stary-adres.pl','http://www.nowy-adres.pl');

3. UPDATE wp_posts SET post_content = replace(post_content, →
   'http://www.stary-adres.pl', 'http://www.nowy-adres.pl');

Reszte poprawek musimy wykonać ręcznie, edytując konfiguracje witryny. Niemniej przytoczone polecenia pozwolą na pewno zaoszczędzić mnóstwo czasu.

MG

Serwer NTP w systemie Windows Server 2008 R2

Problem synchronizacji czasu w sieci lokalnej bywa często pomijany. W sieciach z jednorodnym środowiskiem np. Linux czy Windows nie stanowi dużego wyzwania. Jednak co zrobić gdy mamy ekosystem (popularny ostatnio termin) mieszany. Stacje robocze Windows są od razu wyposażone w klienta synchronizacji czasu. Nie chce on jednak współpracować z bardzo dobrym oprogramowaniem, serwerem NTP, na Linuxie. Chyba jeszcze nikomu nie udało się zmusić do poprawnej współpracy wspomnianych systemów. Nie pozostaje zatem nic innego jak przygotwać serwer NTP w środowisku Windows. Nasz bohater, Windows Serwer 2008 R2 posiada taką usługę, jednak myli się ten, kto myśli, że jego konfiguracja polega wyłącznie na tzw. 'wyklikaniu’.

Z drugiej strony wystarczy, że spełnimy 3 warunki:

1. Utworzymy regułę zapory systemowej dla ruchu przychodzącego, dla portu 123 i protokołu UDP
2. Upewnimy się, że usługa 'Czas systemu Windows’ jest skonfigurowana jako uruchomienie automatyczne
3. Znamy pewne 'magiczne’ polecenie…

W zasadzie wszystko sprowadza się do punktu 3 a komenda wygląda tak:

w32tm /config /syncfromflags:manual →
/manualpeerlist:europe.pool.ntp.org → 
/reliable:yes /update

Cały proces kończymy poleceniem:

w32tm /resync

Od tego momentu możemy konfigurować stacje robocze wskazując powyższy serwer jako źródło czasu.

Na koniec wypada dodać, że w Internecie można znaleźć dużo materiałów, oficjalnych bądź nie, na ten temat. Jednak przytoczona tutaj metoda jest sprawdzona i skuteczna.

MG