Maciej Egermeier blog

Miałem ostatnio zadanie w postaci połączenia Reporting Services działających na jednym serwerze, z bazą danych MS SQL Server działającą na drugim serwerze. Okazuje się, że problemy pojawiają się, gdy przenosimy wszystko z konfiguracji testowej do produkcyjnej. Zwykle w konfiguracji testowej Reporting Services i SQL Server działają na jednym komputerze, zatem mają do siebie “pełne prawa”, ze względu na działanie z uprawnieniami użytkownika Network Service. Na oddzielnych serwerach już nie jesteśmy w tak komfortowej sytuacji. Postanowiłem stworzyć tego posta “dla potomności” żeby ktoś w podobnej sytuacji mógł to sobie wygoolować

Kilka informacji podstawowych -> Raporty na serwerze raportów zwykle mają zdefiniowany plik Data source zawierający informacje o połączeniu do bazy danych. Tak dla ułatwienia, żeby nie trzeba było dla każdego raportu wpisywać tych informacji. W Data Source definiuje się także sposób połączenia do bazy. Najprościej jest wykorzystać autentykację windows, czyli na podstawie uprawnień użytkownika domenowego. Niestety to nie jest takie proste. O tym dalej.

Załóżmy, że użytkownik domenowy, który wyświetla raport (*może to być użytkownik na prawach którego działa aplikacja ASP, która korzysta z kontrolki do wyświetlania raportu) ma prawa do tego raportu jak i do bazy danych, z której ten raport bierze dane. Skoro raport działa z uprawnieniami użytkownika (autentykacja Windows, czyli domenowa) no to wszystko gra. Ma prawa do tego, co trzeba. No nie do końca. Pojawia się błąd:
“An error has occurred during report processing. (rsProcessingAborted)
Cannot impersonate user for data source ‘DS1′. (rsErrorImpersonatingUser)
Logon failed. (rsLogonFailed)
For more information about this error navigate to the report server on the local server machine, or enable remote errors ”

Można sobie włączyć Remote errors (http://technet.microsoft.com/en-us/library/aa337165.aspx) ale niewiele to daje. Dodatkowa informacja to:

“Logon failure: the user has not been granted the requested logon type at this computer. (Exception from HRESULT: 0×80070569)”

Pierwsza przeszkoda

Aby możliwe było użycie Data Source na prawach użytkownika domenowego, ten użytkownik musi mieć prawo “Allow log on locally” (Zezwalaj na logowanie lokalne) na komputerze na którym działa Reporting Services. To prawo musi mieć użytkownik, który “wyzwala” Data source. Można także w konfiguracji Reporting Services (Start -> programy -> Microsoft SQL Server 2005 -> configuration tools -> Reporting Services Configuration) ustawić “Execution account” i tam wpisać użytkownika, który takie prawo będzie posiadał . W ten sposób Reporting Services będzie mogło wywoływać wszystkie data source. Jest do dokładniej opisane tutaj: http://msdn2.microsoft.com/en-us/library/bb326317.aspx

Druga przeszkoda

Chcieliśmy ustawić aby Reporting Services działały na zasadzie autentykacji windows. Daje to tyle ze aplikacja webowa IIS (w tym przypadku Reporting Services) może działać z uprawnieniami użytkownika domenowego, który z niej korzysta. Wszystko jest w porządku dopóki serwer IIS na podstawie tych danych uwierzytelniania spróbuje się dobrać do innych zasobów sieci (np. serwera MS SQL). Nie jest dopuszczalne takie zachowanie. Aplikacja nie możę korzystać z uprawnień tego użytkownika w innych usługach. Uznano, że to zbyt duże uprawnienie nadane aplikacji. Użytkownik musi wiedzieć do czego będą użyte jego uprawnienia. Ten problem nazwano “double hop”. Pierwszy hop to połączenie między użytkownikiem a IIS, a drugi hop to połączenie pomiędzy IIS a SQL serverem. Tego nie można zrobić. Jest to opisane tutaj: http://blogs.msdn.com/nunos/archive/2004/03/12/88468.aspx Tak naprawdę użytkownik daje prawo aplikacji do działania z jego uprawnieniami tylko na poziomie serwera IIS.

* Kilka użytecznych definicji i wyjaśnień można znaleźć tutaj: http://msdn2.microsoft.com/en-us/library/aa480547.aspx

Można to obejść w różny sposób.

1. W data source w Reporting Services wpisać nazwę użytkownika i hasło do połączenia z bazą danych (Stored Credentials). Hasło będzie zaszyfrowane w bazie danych Reporting Services (dla jasności: Reporting Services ma własną bazę danych do przechowywania raportów i innych rzeczy) .
Raczej nie ma możliwości zapisania nazwy użytkownika i hasła Data Source w rejestrze tak jak to można zrobić z aplikacją ASP. Jedynie można impersonifikować całą usługę Reporting Services, tak jak zostało to opisane tutaj: http://msdn2.microsoft.com/en-us/library/bb326419.aspx
2. Można zezwolić serwerowi IIS na “drugi hop” zgodnie z :

http://support.microsoft.com/default.aspx?scid=kb;en-us;810572

Czyli trzeba by było zmienić ustawienia active directory, aby ufać serwerowi IIS jeśli chodzi o delegowanie uprawnień (drugi hop):
http://msdn2.microsoft.com/en-us/library/ms916706.aspx

Minus jest taki, że trzeba by było zmienić ustawienia komputerów klienckich zgodnie z pierwszym podanym przeze mnie linkiem. Poza tym może to w jakimś stopniu obniżyć bezpieczeństwo, bo skoro serwer IIS będzie miał pozwolenie na delegowanie uprawnień, no to wszystkie aplikacje (nie tylko Reporting Services) będą mogły z tej opcji korzystać. Niby klient (Internet Explorer) musi pozwolić na delegowanie jego uprawnień, ale i tak może to być problem.

Mam nadzieję, że ten post zaoszczędzi komuś czas Dzięki temu problemowi zdecydowanie poprawiłem sobie znajomość zagadnień związanych z ASP i uprawnieniami domenowymi, choć nie ukrywam, że wolałbym spędzić nad tym mniej czasu

Podziel się!

Kiedyś w jednej z firm, w których pracowałem, musiałem jakoś ucywilizować tworzenie kopii zapasowych na komputerach. Przeszukując internetowe morze natrafiłem na bardzo fajny program o nazwie Cobian Backup. Okazał się być skutecznym narzędziem, dlatego chciałbym go tutaj polecić. Nie jest to może idealny i zapewne nie może się mierzyć z profesjonalnymi systemami, ale i tak ten program na licencji open source jest wart uwagi.

W skrócie: Program umożliwia utworzenie kopii zapasowej na serwerze FTP, dysku lub dysku sieciowym (pewnie dałoby się też w katalogu webowym WebDAV, jeśli wcześniej został dodany w systemie) według zadanego harmonogramu. Przed zapisem pliki mogą zostać skompresowane i zaszyfrowane przy użyciu silnych algorytmów kryptograficznych. Możliwe jest zapisanie tylko zmienionych plików.

Scenariusze tworzenia kopii zapasowych i bezpieczeństwo.

Podczas instalacji Cobiana wybieramy, czy ma zostać zainstalowany jako usługa systemu windows (uruchamiana jako dany użytkownik), czy jako normalny program. Działanie jako usługa jest świetnym pomysłem. W ten sposób użytkownik nie może tego programu wyłączyć, a więc nie może pominąć tworzenia np. codzinnej kopii. W konfiguracji zadania tworzenia kopii zapasowej można ustawić, aby zadanie zostało uruchomione jako inny użytkownik. Daje to możliwość stworzenia katalogu na dysku sieciowym, w którym zapisywane są kopie zapasowe, a do którego użytkownik nie ma dostępu. Ta opcja w połączeniu z możliwością zabezpieczenia dostępu do konfiguracji programu hasłem daje trochę pewności co do odporności na zamierzone lub nie szkodliwe działanie użytkowników (niestety hasło da się bardzo łatwo usunąć poprzez usunięcie jednego z plików konfiguracyjnych). Oczywiście zapisywanie w programie hasła użytkownika domenowego, na którego prawach by był dokonywany zapis kopii ma swoje wady. Teoretycznie możliwe jest wyciągniecie tego hasła z programu (jest zahaszowane), a więc i dostęp do wszystkich kopii zapasowych. Trudno sobie wyobrazić tworzenie dla każdego pracownika oddzielnego użytkownika dla backupu, więc taki użytkownik domenowy będzie miał dostęp do wszystkich plików pracowników. Można oczywiście szyfrować kopie zapasowe, ale to dodatkowo komplikuje całe rozwiązanie (gromadzenie gdzieś kluczy).
Można przemyśleć zastosowanie serwera FTP z jednym użytkownikiem i hasłem dla wszystkich komputerów – prawa tylko do zapisu. Niestety jeśli ktoś pozna hasło będzie mógł nadpisać istniejące na serwerze pliki, chyba że serwer zostanie inaczej skonfigurowany.
Co jeśli nie mamy serwera? Możemy kopiować pliki z jednego komputera na drugi z zastosowaniem szyfrowania plików. Można także rozważyć zakup urządzenia NAS (Network Attached Storage) np. D-Link DNS-323 i gromadzenie kopii zapasowych na jego dyskach twardych.

Logi i kontrolowanie całego procesu.

Niestety bez rewelacji. Program zapisuje logi lokalnie w postaci pliku tekstowego. Można ustawić powiadamianie na email, co jest tak naprawdę przesłaniem pliku logu. Dość przydatna może być opcja wysłania emaila powiadamiającego tylko w razie wystąpienia błędów. Niestety program nie zapisuje informacji w logu systemowym, nie potrafi zapisywać do sysloga ani nic takiego. Zatem nie ma co marzyć o takiej opcji, żeby w danym momencie wiedzieć na którym komputerze był uruchomiony backup, a na którym nie. Jedynym wyjściem by było ustawienie wszystkim pracownikom logowania na email i potem jakiegoś automatycznego parsowania plików logów. Ehh Niestety znów jest problem taki, że w programie musi być na sztywno wpisane hasło użytkownika serwera pocztowego, ale na szczęście jest zahaszowane.

Kopie zapasowe z laptopów

Jeśli np. ustawimy codzienny backup np. o 10 rano i wtedy laptop nie pojawi się w sieci i nie wykona zadania, można skorzystać z opcji “Run missed backups”. Na to że użytkownik sam uruchomi zadanie chyba raczej nie ma co liczyć.

Podsumowanie

Cobian Backup na pewno nie jest konkurencją dla komercyjnych systemów do automatyzacji tworzenia kopii zapasowych, ale na pewno jest lepszy niż zapisywanie raz na jakiś czas plików ręcznie. W przypadku wielu komputerów zarządzanie całą konfiguracją może być sporym wyzwaniem, ale w przypadku małej firmy z kilkoma komputerami może być skutecznym rozwiązaniem. Możliwość uruchamiania programu jako inny użytkownik daje nowe możliwości i zwiększa “głupotoodporność”.

Podziel się!

Znalezienie bezpłatnych narzędzi dla firmy świadczącej usługi informatyczne nie jest prostą sprawą. Mało kogo stać na zaawansowane systemy zgodne z ITIL np. produkcji HP. Zatem spróbujmy znaleźć coś zastępczego. Dokładnie chodzi w tym momencie (w nomenklaturze ITIL) o Service Support. Tutaj można zobaczyć diagram, który powinien pomóc w przypomnieniu sobie/poznaniu tych części składowych ITILa.

Zacznijmy od Incident Management i Problem Management.

W tym wypadku chyba jedynym słusznym rozwiązaniem jest Flyspray. Umożliwia wprowadzanie firm/projektów i do nich są tworzone taski (nazwijmy taska po naszemu zgłoszeniem) . System jest zrobiony na prawdę sensownie. Z moich doświadczeń jednak wynika, że brakuje mu dość istotnej funkcjonalności. Pracownicy mogą oczywiście wprowadzać komentarze pod wybranym zgłoszeniem, jednak nie wiadomo kto ile czasu nad tym pracował. Jest to bardzo istotne przy rozliczaniu czasu pracy. Do rozliczeń z klientem wystarczy suma, jednak do rozliczeń wewnętrznych jest potrzebne rozdzielenie na minizadania. Można tę funkcjonalność doprogramować i nie jest to bardzo trudne, gdyż ten PHPowy system jest dobrze zaprojektowany. Jest całkiem niezłe raportowanie, co może się przydać do fakturowania, ale niestety jest problem na przełomie miesięcy. Jeśli jest zgłoszenie, które się ciągnie na przestrzeni dwóch miesięcy to jest problem z fakturowaniem. Bo mamy sumaryczny czas, tylko nie wiadomo z jakiego miesiąca. Z pomocą przychodzą te minizadania. Jeśli zliczymy czas z minizadań to mamy już właściwy obraz godzin z miesiąca. Zatem trochę jest grzebania w kodzie PHP, aby było jak należy, ale i tak w kategorii open source nie widzę konkurencji dla Flyspray.

Change Management i Configuration Management.

Z Change Management można sobie poradzić używając do tego zgłoszeń w Flyspray. Zgłoszenia te muszą być potem zatwierdzone przez odpowiednie osoby. Może to być zrobione poprzez zmianę statusu zgłoszenia, lub poprzez wpisanie komentarza przy zgłoszeniu. Także w komentarzu można wpisać jakie są możliwe probemy.
Oczywiście nie ma co marzyć o pełnowartościowym CMDB (Configuration Management DataBase). Niby jest projekt open source o nazwie OneCMDB, ale chyba dotyczy to tylko serwerów. Niby jest jakaś funkcja automatycznego wykrywania tychże serwerów, ale nie widzę tam żadnego klienta, co właściwie to wszystko dyskwalifikuje. Zwykle serwerów jest kilka i chyba nie ma sensu dla tych kilku serwerów uruchamiać takiej usługi. Marzy mi się jakaś baza danych, która by była aktualizowana na podstawie oprogramowania klienckiego na każdym komputerze… ale czegoś takiego w Open Source nie ma.

Jeśli chodzi o takie bieda-zarządzanie konfiguracją to proponuję jakiś system Wiki. Lepiej chyba użyć TikiWiki niż MediaWiki ,bo w Tiki nie dość, że jest lepsze zarządzanie uprawnieniami do stron, to jeszcze można z niego zrobić pełnowartościowy portal Intranetowy, bo jest to pełnowartościowy CMS. Jednocześnie Wiki może służyć jako firmowa baza wiedzy.

Do zarządzania konfiguracją, ale w jednym tylko obszarze jest programik Firewall Builder, który służy do konfiguracji firewalli różnych typów (iptables, ipfilter, pf i cisco ale za $$) na zasadzie reguł, tak jak to bywa w popularnych firwallach sprzętowych. FWBuilder się na pewno sprawdzi jeśli trzeba obsłużyć kilka firewalli linuksowych [Może doczekamy się wsparcia dla sprzętowych firewalli, które dostajemy w routerach. Zobaczymy.]. Wszystko jest w jednym miejscu. Program generuje skrypty, które potem trzeba umieścić w na serwerze firewall. Można użyć CVSa do trzymania wszelkich zmian w plikach konfiguracyjnych tego firwalla, lub po prostu przechowywać poszczególne pliki z datami. Generalnie CVS może być dobrym rozwiązaniem do śledzenia zmian we wszelkich plikach konfiguracyjnych, a więc de facto do archiwizowania konfiguracji.

Jeszcze o Availability Management należącego do działu Service Delivery ITIL.

Do śledzenia dostępności serwerów, a także do monitoringu i informowania o awariach można użyć systemów:

1. Nagios
2. Cacti

przy czym Cacti oprócz funkcji podanych wcześniej, jest nastawiony na analizę ruchu sieciowego i generowanie jego wykresów. Może to być przydatne w Capacity Management. Może być także przydatnym narzędziem do raportowania dla klienta jeśli jesteśmy także dostawcą internetu.

Nagios

Cacti

Dla obu systemów można ściągnąć gotowe maszyny wirtualne VMware, co może służyć testom, lub po prostu ich użytkowaniu:

1. maszyna wirtualna z Nagiosem
2. maszyna wirtualna z Cacti

Podsumowanie
Oczywiście marzeniem jest połączenie tych wszystkich systemów w jakiś sposób, bo właśnie połączenie wszystkich elementów ITILa jest jego siłą. Marzeniem by było połączenie Flyspraya z CMDB, tak aby zgłoszenia były od razu wiązane z elementem w bazie danych sprzętu. Może doczekamy się czegoś takiego.
Mam świadomość tego, że systemy były opisane pobierznie, jednak od czego są strony poszczególnych projektów. No i oczywiście systemy to nie wszystko. Muszą być powiązane z dobrymi rozwiązaniami organizacyjnymi.

Podziel się!