K-NET s.c.

Instalacja GRUB na drugim dysku macierzy RAID1

Począwszy do Debiana Squeuze, wśród jego użytkowników, administratorów systemu itd. rozgorzała dyskusja na temat błędów pojawiających się podczas instalacji. Rzecz dotyczy składania macierzy RAID1. Jak się okazuje, nawet prawidłowo przeprowadzony proces instalacji systemu od zera nie gwarantuje, że nasz serwer będzie bezpieczny. W czym rzecz? W przypadku awarii pierwszego dysku macierzy, nie ma szans aby system wystartował z drugiego, lustrzanego dysku. Najprościej ujmując, pakiet GRUB, który stanowi tzw. boot-loader, zostanie zainstalowany w MBR (Master Boot Record – Główny Rekord Startowy) tylko pierwszego dysku. Rozwiązanie wydaje się bardzo proste. Trzeba ręcznie zainstalować GRUB w MBR drugiego dysku. Jednak z niewiadomych przyczyn większość poradników przytacza błędną komendę (sic!). Wg moich doświadczeń, a walczyłem z powyższym problemem dzień cały, jedyną i sprawdzoną postacią komendy 'grub-install’ jest:

grub-install --no-floppy --boot-directory=/dev/md0 /dev/sdb

Kilka słów komentarza. Istotne jest poprawne wskazanie zarówno partycji typu RAID (/dev/md0) jak i fizycznego dysku (/dev/sdb – zakładam, że w przytoczonym przykładzie drugi dysk to /dev/sdb). Po wykonaniu powyższej operacji, można przejść do sprawdzenia czy system startuje z drugiego dysku np. odpinając na czas testów, dysk pierwszy od kontrolera.

MG

Odnowienie certyfikatu SSL w serwerze MS Exchange 2010

Każdy kto instalował i konfigurował serwer MS Exchange wie, że jednym z jego komponentów jest dostęp do skrzynek pocztowych przez przeglądarkę (tzw. OWA – Outlook Web Access). Jak każda tego typu komunikacja OWA powinno być zabezpieczone, najczęściej za pomocą protokołu HTTPS. Żeby zrealizować takie rozwiązanie trzeba zainstalować certyfikat SSL. Standardowa procedura zakłada wygenerowanie żądania, przesłanie go do wystawcy certyfikatu, w efekcie zaś otrzymanie samego pliku z certyfikatem. Co jednak zrobić jeśli tylko odnawiamy certyfikat? Czy standardowa procedura jest konieczna?

W przypadku odnowienia certyfikatu, który podpisany został przez tego samego, zaufanego wydawcę, możemy spokojnie pominąć typową, szeroko opisywaną w Internecie, procedurę. Ponieważ podczas instalacji OWA wymagany jest serwer IIS (Internet Information Server), tak naprawdę wystarczy dokonać zmian w konfiguracji tego ostatniego.

Na początek uruchamiamy menadżera IIS (’IIS Manager’). W lewym okienku aplikacji wybieramy definicje swojego serwera (poniżej opcji 'Start Page’) i w środkowej sekcji wybieramy certyfikaty serwera (’Server Certificates’). Po prawej stronie, z dostępnych opcji wybieramy Complete Certificate Request…. Po uruchomieniu okna Wizard, wskazujemy plik z certyfikatem (uwaga – domyślne rozszerzenie nie jest wymagane). Wybieramy również przyjazną nazwę, inaczej alias. Po zakończeniu czynności, program wyświetli monit Complete Certificate Request. W tym momencie potwierdzamy (OK) komunikat i przechodzimy dalej.

Tym razem rozwijamy drzewko po lewej stronie i wśród dostępnych serwerów wybieramy właściwy, podświetlając jego nazwe. Najczęściej będzie to Default Web Site. W tym momencie konieczne jest zatrzymanie usługi IIS (serwera). Po prawej stronie w sekcji Edit Site wybieramy opcje Bindings…. W okienku konfiguracyjnym, które pojawi się na środku ekranu, wybieramy https, następnie zaś, w kolejnym okienku, z rozwijanej listy wybieramy nowy certyfikat (zainstalowany w poprzednim kroku). Uruchamiamy usługę IIS. W tym momencie zakończyliśmy instalację certyfikatu SSL dla naszego OWA.

MG

Jak ograniczyć liczbe równoczesnych połączeń z serwerem SSH

Obecnie sieci VPN są zagadnieniem powszechnie znanym, szeroko komentowanym i zalecanym we wdrożeniach biznesowych. Istnieje cała masa gotowych rozwiązań sprzętowych, na poziomie aplikacji itp. Praktycznie każdy administrator może sam, według uznania, wybrać wygodne narzędzie. Różnią się one algorytmami, wymaganiami oraz niestety ceną. Czy można zbudować skalowalny dostęp VPN do firmy, który nie będzie wymagał dużych środków finansowych? Jednym z szeroko ostatnio polecanych rozwiązań jest VPN z wykorzystaniem serwera SSH. Elementami tej techniki są m. in.: (a) serwer dostępowy, zrealizowany np. jako sewer Linux z demonem SSHD oraz (b) aplikacja kliencka, która potrafi zestawić szyfrowany tunel np. Bitwise Tunellier.

Jeden z problemów, związanych z opisywanym tunelem SSL polega na tym, że klient może kreować równocześnie wiele połączeń, korzystających w tym samym czasie, z tego samego konta dostępowego. Być może nie jest to rzecz dyskwalifikująca całość, jednak w codziennej praktyce administratorskiej może utrudniać życie. W końcu chcemy aby logi systemowe były jasne i przejrzyste – słowem czytelne. Najlepiej aby jedno połączenie, czyli wspomniany tunel SSL, było przypisane tylko i wyłączenie do jednego konta.

Przykładowe rozwiązanie dla systemu Linux, z serwerem dostępowym bazującym na dystrybucji Debian Squeeze, polega na odpowiedniej modyfikacji pliku ’/etc/security/limits.conf’. Zawiera on m. in. defincje dotycząca liczby równoczesnych sesji SSH dla jednego konta dostępowego. W opisywanym rozwiązaniu należy dodać następującą linie przed znacznikiem ’# End of file’:

@sshlimited     -       maxlogins       1

I to wszystko, jak zwykle w przypadku Linuxa, krótko i na temat 🙂

MG

Jak podejrzeć kto zajął zasób we współdzielonym kalendarzu MS Exchange

Powszechnie wiadomo, że serwer MS Exchange, oprócz standardowych skrzynek pocztowych, obsługuje skrzynki związane z zasobami. Dotyczy to zarówno lokalizacji (np. sala konferenycyjna) jak i sprzętu (np. projektor). Ta, dość wygodna funkcjonalność, umożliwia rezerwowanie zasobów w ramach organizacji. Informacje o ich zajętości można uzyskać przeglądając współdzielony kalendarz.

Niestety, standardowa konfiguracja sewera umożliwia odczytanie informacji tylko o zajętości. Nie dowiemy się natomiast kto zdążył już zarezerwować zasób. W codziennej pracy włączenie informacji o osobie rezerwującej okazuje się bardzo przydatne i pożądane.

Jak to zrobić w najprostszy sposób? Korzystając z Power Shell dostarczonego w pakiecie MS Exchange (nie mylić z Command Prompt czy Power Shell systemowym!). Po uruchomieniu Power Shell z menu systemowego, przywita nas niebieskie okienko ze znakiem zachęty. Wydajemy polecenie:

[PS] C:>Get-MailboxFolderPermission NazwaZasobu:Calendar

RunspaceId : 8706cde4-2cb5-4519-9a46-a46fcc0c450c
FolderName : Calendar
User : Default
AccessRights : {AvailabilityOnly}
Identity : Default
IsValid : True

Zwróćmy uwagę na wiersz AccessRights, w którym odczytujemy informacje o uprawnieniach: AvailabilityOnly.

Następnie wydajemy polecenie:

Set-MailboxFolderPermission NazwaZasobu:Calendar -User Default →
→ -AccessRights Reviewer

które zmieni uprawnienia dotyczące obiektu NazwaZasobu. To wszystko. Odtąd możemy zawsze sprawdzić kto zarezerwował zasób. Jeszcze tylko mały test:

[PS] C:>Get-MailboxFolderPermission NazwaZasobu:Calendar

RunspaceId : 8706cde4-2cb5-4519-9a46-a46fcc0c450c
FolderName : Calendar
User : Default
AccessRights : {Reviewer}
Identity : Default
IsValid : True

RunspaceId : 8706cde4-2cb5-4519-9a46-a46fcc0c450c
FolderName : Calendar
User : Anonymous
AccessRights : {None}
Identity : Anonymous
IsValid : True

Mam nadzieje, że wszyscy zauważyli zmianę uprawnień 🙂

MG

Problemy z logami w MS Exchange 2010

Zarządzając MS Exchange 2010 czasami możemy napotkać nieprzyjemne niespodzianki. Do jednej z nich należy blokada logów. Exchange, oprócz skrzynek pocztowych (mailbox), przechowuje logi, które zawierają m.in. całą korespondencję przechodzącą przez serwer. Z tego powodu log potrafi przybrać gigantyczne rozmiary blokując wolumin/dysk/partycję (brak wolnego miejsca na dysku). Dane te są niestety potrzebne w przypadku awaryjnego odtwarzania bazy skrzynek pocztowych, nie można ich zatem tak po prostu usunąć ręcznie. Jednak czy aby na pewno?

Zazwyczaj gdy dojdzie do blokady dysku z powodu braku miejsca sewer przestaje przetwarzać korespondencję. W takiej sytuacji trudno jest stosować skomplikowane operacje, bowiem liczy się każda chwila. Może również być tak, że nawet nie mamy gdzie przesunąć logów. Słowem impas. Musimy przede wszystkim pamiętać o dwóch podstawowych regułach:

1. Nigdy nie usuwamy logów. Możemy je co najwyżej przesunąć na inny dysk (również zewnętrzny) tak aby były dostępne na żądanie.
2. Z katalogu z logami usuwamy tylko te, które są starsze niż tzw. punkt kontroli (checkpoint).

I właśnie drugi warunek pozwali nam zadziałać ręcznie.

Procedura jest dość prosta:

• Należy odnaleźć w katalogu zawierającym logi plik z rozszerzeniem '*.chk’ (w większości przypadków będzie miał jedną z nazw: 'E00.chk’, 'E01.chk’, 'E03.chk’ itd. )
• Korzystamy z wbudowanego narzędzia linii poleceń ’eseutil.exe’ i w oknie dialogowym (np. po wywołaniu command line prompt poleceniem ’cmd.exe’) wpisujemy np.:

"C:\Program Files\exchsrvr\bin\eseutil.exe" /MK →
→ "C:\Program Files\exchsrvr\mdbdata\E02.chk"

•  Komenda odpowie wyświetlając w okienku raport, którego najważniejsza, z naszego punktu widzenia, linijka będzie wyglądać jak:

Checkpoint (0x21EE,11B0,9A)

• Interesuja nas pierwsza wartość z nawiasu, bezpośrednio po prefiksie '0x’, czyli w tym przypadku ’21EE’
• Wyświetlamy zawartość katalogu z logami w Exploratorze systemowym i sortujemy ją wg daty
• Dobra wiadomość jest taka, że możemy 'odchudzić’ katalog przenosząć wszystkie pliki '*.log’ starsze niż ’E02021EE.log’!

To tyle w kwestii ratowania życia administratorom 🙂 IMHO warto jest jednak unikać w przyszłości takich sytuacji i wykonywać regularnie kopie zapasowe logów (za pomocą wbudowanej w system usługi). W trakcie tego procesu logi zostaną 'przycięte’, nie zagrozi nam zatem brak miejsca na dysku. Jednak o tym jak to zrobić napiszę innym razem…

MG

Jak skompilować ClamAV dla Debiana – aktualizacja

Jakiś czas temu opublikowałem krótki artykuł na temat kompilacji ClamAV dla systemu Debian. Trochę czasu upłynęło (tak naprawdę ponad 3 lata – jak ten czas leci…), pora zatem na aktualizację poradnika. Dystrybucje Debiana nie często pociągają za sobą konieczność rewolucyjnych zmian, jednak jeśli chcemy powtórzyć cały proces dla Debiana Squeeze (aktualnej wersji stable) to powinniśmy liczyć się z paroma drobiazgami:

•  Przede wszystkim nie musimy już dodawać repozytorium Debian Volatile, które zostało zastąpione przez squeeze-updates (vide: http://www.debian.org/News/2011/20110215). Zatem, o ile jeszcze tego nie zrobiliśmy, powinniśmy w pliku /etc/apt/sources.list umieścić linikę:

deb-src http://security.debian.org/  squeeze/updates →
→ main contrib non-free

• Jeśli zaś, a jestem niemal pewien, że tak właśnie jest,  mamy również dodane repozytorium:

deb     http://security.debian.org/  squeeze/updates →
→ main contrib non-free

•  to kompilowanie ClamAV powinniśmy wykonywać tylko w przypadku problemów z pakietem instalowanym z gotowej paczki.

Jak widać na podstawie powyższego przykładu, od Debiana Squeeze, zadania związane z obsługą ClamAV, znacznie się upraszczają. Czy to dobrze, czy źle? Odpowiedź pozostawiam administratorom na co dzień utrzymującym swoje serwery.

MG

Niezastąpiony tandem: terminal-ide + hackerskeyboard

Banałem jest stwierdzenie, że rok 2012 upłynął pod znakiem Androida. System, który święci triumfy zdobywając przebojem rynek urządzeń mobilnych, na dobre zagościł w naszych domach. Ulegając trendom, ale również w poczuciu obowiązków wobec klientów, którzy coraz częściej zwracają się o pomoc w obsłudze urządzeń z Androidem, postanowiłem kupić tablet. Wybór padł na Google Nexus 7. Oprócz wielu rzeczy, które przeciętny użytkownik zwykł robić za pomocą tabletu, wpadłem na pomysł, że chciałbym mieć podręczny teminal do zarządzania serwerami przez SSH. Z początku sprawy nie wyglądały dobrze. Aplikacji dostępnych w sklepie Google Play, które można z ręką na sercu polecić, było jak na lekarstwo. Dopiero niedawno, sam nie pamiętam z którego źródła, dowiedziałem się o dwóch aplikacjach, które mogę polecić każdemu administratorowi.

Pierwszą jest terminal-ide. Tak naprawdę to emulator terminala dla Androida mający spore możliwości. Dla mnie najważniejszą był wbudowany pakiet SSH oraz uruchamianie wielu terminali jednocześnie. Do ciekawostek można zaliczyć również midnight-commander, który otrzymujemy wraz z aplikacją. Korzyści jest dużo więcej, wystarczy odwiedzić stronę autora, pobrać aplikację i zainstalować ją (uwaga – plik APK do małych nie należy).

Żaden terminal nie spełni naszych oczekiwań jeżeli nie dysponujemy dobrą klawiaturą. Wśród dostępnych rozwiązań wyróżnia się zdecydowanie hackerskeyboard. Jak dotąd nie spotkałem podobnej aplikacji, który udostępnia np. strzałki czy klawisze kontrolne na panelu dotykowym w tak wygodny sposób. Zdecydowanie polecam odwiedziny na stronie autora i przetestowanie jego oferty.

MG

Preparing to configure Windows. Do not turn off your computer.

Moment aktualizowania systemu Windows jest dla mnie zawsze dość stresujący. Niestety, raz na jakiś czas, im częściej tym lepiej, należy aktualizować serwery. Przyznam, że po wielu latach, nadal mam mieszane uczucia i zdarza mi się odwlekać tę chwilę. Niedawno w trakcie aktualizacji jednego z serwerów produkcyjnych musiałem zmierzyć się ze 'zwisem’ w trakcie wspomnianego procesu. Kiedy od godziny obserwuje się napis ’Preparing to configure Windows. Do not turn off your computer.’ różne myśli zaczynają chodzić po głowie. Przede wszystkim nie można ulec panice i restartować ręcznie serwera bo może się to skonczyć źle… Czy jest jakaś alternatywa?

Poniżej zamieszczam procedurę dla sytuacji, w której instalacja trwa od dłuższego czasu, RDP nie działa, jednak nadal można wykonać ping do serwera.

1. Na komputerze z systemem Windows, należy założyć konto o takiej samej nazwie użytkownika i haśle, jak konto administratora w przypadku problematycznego serwera.
2. Następuje logujemy się do świeżo utworzonego konta i uruchamiamy polecenie 'services.msc’ oraz łączymy z serwerem.
3. Na liście aktywnych usług odnajdujemu ’Windows modules installer’, prawie na pewno usługa znajduje się w trybie ’Stopping’, nie można też ani jej zatrzymać ani zmienić konfiguracji. Właśnie ta usługa jest najczęściej odpowiedzialna za zwis podczas aktualizacji.
4. Programem/procesem, która uruchamia wspomnianą usługę jest ’C:\windows\servicing\trustedinstaller.exe’, musimy zatem zabić ten proces.
5. Pobieramy z Internetu narzędzie do zdalnego zarządzania procesami np. ’http://lizardsystems.com/remote-process-explorer/’.
6. Po zainstalowaniu narzędzia, podłączeniu do serwera i zabiciu procesu, serwer od razu przejdzie do ponownego uruchomienia systemu.

Mam nadzieję, że powyższy wpis okaże się pomocny i pozowoli szybko, w sposób cywilzowany, rozwiązać problem z aktualizacją.

MG

Obsługa UPS Smart-UPS SC1000 w Debian Squeeze

Dawno już minęły czasy, kiedy praktycznie każdy UPS firmy APC, obecnie APC Schneider, można było obsłużyć za pomocą linuksowego daemona apcupsd. Na stronie jego autorów można znaleźć ostrzeżenie przed kupowaniem modeli SmartUPS SMX/SMT 750, 1000, 1500, czy SmartUPS RT 3000XL, 5000XL. Niestety padłem ofiarą takiego zakupu i duże było moje zdziwienie, że nic nie działa jak powinno. Ponieważ miałem możliwość wymiany urządzenia, to zamówiłem nowy, inny model. Tym razem zażyczyłem sobie żeby był obsługiwany przez apcupsd. Po paru dniach dotarł UPS Smart-UPS SC1000. Zabrałem się szybko za instalacje i okazało się, że znowu jest problem. Serwer nie miał portu szeregowego, zaś UPS zamiast kabla USB został wyposażony w adapter Profilic USB-to-serial. Mając na pokładzie Debiana Squeeze zacząłem zmagać się z adapterem. Moduł obsługi został dołączony do standardowego jądra, jednak UPS nadal pozostawał ślepy i głuchy. Po kilku godzinach szukania rozwiązania, trafiłem na strony Ubuntu Forum, gdzie udało mi się znaleźć pozyteczne informacje i przygotować działające, choć może niezbyt eleganckie rozwiązanie.

Po pierwsze – modyfikujemy skrypt startowy ’/etc/init.d/apcupsd’, dodając między wierszem:

case "$1" in
  start)
    echo -n "Starting $DESC: "

a wierszem:

rm -f /etc/apcupsd/powerfail

następujący kod:

if [ ! -d /dev/usb-tty ]
then
mkdir -p /dev/usb-tty
fi

mknod /dev/usb-tty/ttyUSB0 c 188 0
mknod /dev/usb-tty/ttyUSB1 c 188 1
mknod /dev/usb-tty/ttyUSB2 c 188 2
mknod /dev/usb-tty/ttyUSB3 c 188 3
mknod /dev/usb-tty/ttyUSB4 c 188 4
mknod /dev/usb-tty/ttyUSB5 c 188 5
mknod /dev/usb-tty/ttyUSB6 c 188 6
mknod /dev/usb-tty/ttyUSB7 c 188 7
mknod /dev/usb-tty/ttyUSB8 c 188 8
mknod /dev/usb-tty/ttyUSB9 c 188 9
mknod /dev/usb-tty/ttyUSB10 c 188 10
mknod /dev/usb-tty/ttyUSB11 c 188 11
mknod /dev/usb-tty/ttyUSB12 c 188 12
mknod /dev/usb-tty/ttyUSB13 c 188 13
mknod /dev/usb-tty/ttyUSB14 c 188 14
mknod /dev/usb-tty/ttyUSB15 c 188 15

Po drugie – edytujemy plik ’/etc/apcupsd/apcupsd.conf’ i definiujemu następujące parametry:

UPSCABLE smart
UPSTYPE apcsmart
DEVICE /dev/usb-tty/ttyUSB0

Ostania linijkę powinniśmy zmodyfikować w zależności od portu, do którego podłączyliśmy UPS. Po restarcie daemona apcupsd:

/etc/init.d/apcupsd stop
/etc/init.d/apcupsd start

nasz UPS, po wpisaniu polecenia:

/etc/init.d/apcupsd status

powinien odezwać się dobrze znanym komunikatem.

MG

Instalacja winapcupsd na systemie serwerowym

Czy wszystkie serwery Windows powinny być zabezpieczone za pomocą zasilaczy awaryjnych? Odpowiedź jest oczywista. Jednak nie zawsze łatwa w realizacji. Co zrobić jeżeli nie mamy akurat pod ręką np. APC Smart-UPS, dedykowanego dla serwerów a pozostały nam niewykorzystane APC Back-UPS dla stacji roboczych? Zazwyczaj ten drugi pozwoli na prawidłowe zamknięcie systemu  w ciągu kilku minut, nadaje się zatem na tymczasowy zasilacz. Problem polega jednak na oprogarmowaniu dostarczanym ze sprzętem:

• APC Smart-UPS jest sprzedawany z aplikacją PowerChute Business Edition, dedykowaną dla serwerów, i nie obsługuje innych modeli zasilaczy APC,
• z kolei APC Back-UPS jest sprzedawany z aplikacją PowerChute Personal Edition, której nie możemy zainstalować na serwerowyn systemie.

Można pomysleć, że to sytuacja bez wyjścia. Tymczasem, ku mojemu zaskoczeniu, można skorzystać z oprogramowania na licencji GPL, którym jest Apcupsd. Na pewno dla każdego, kto instalował zasilacze APC pod Linuxem, ta nazwa nie brzmi obco. Na stronie projektu znajduje się odnośnik do portu dla Windows. Okazuje się, że aplikacja działa bardzo sprawnie a konfiguracja nie różni się niczym od tej z Linuxa. Jedynym, drobnym problemem, jest instalacja sterownika dostarczanego z aplikacją (należy uważnie przeczytać dokumentację i postępować zgodnie z instrukcją krok po kroku). Poza tym winapcupsd pozwala cieszyć się na serwerze pełnymi możliwościami zasilacza awaryjnego dla stacji roboczej.

MG