Bądź na bieżąco - RSS

Aktualizacja hosta ESXi

Sierpień 18th, 2018 | Brak Komentarzy | Kategoria: Linux, Porady, Windows

VMware ESXiWirtualizacja jest obecnie praktycznie standardem. Jest powszechnie dostępna i łatwo można samemu przygotować własny host maszyn wirtualnych. Od jakiegoś czasu testuje aktualnie kilka instalacji VMware ESXi i muszę przyznać, że jestem zaskoczony wygodą obsługi oraz jak dotąd (odpukać) bezawaryjną pracą. Instalacja jest dosyć łatwa pod warunkiem, że przygotujemy się pod kątem sprzętu. Nie każdy zostanie wykryty przez instalator, ale metodą prób i błedów a także przy wsparciu forów technicznych można rozwiązać większość problemów. Potem jest już z górki. Do czasu. Jak zwykle po jakimś czasie powinniśmy pomyśleć o kwestiach bezpieczeństwa, a co się z tym wiąże aktualizacji naszego hosta.

Jeżeli podobnie jak ja używasz wersji ewaluacyjnej ESXi to znaczy, że najprawdopodobniej korzystasz z trybu standalone server, czyli posiadasz tylko jeden host maszyn wirtulanych. Instalacja tego typu wyróżnia się brakiem wygodnej czytaj graficznej obsługi aktualizacji. Pełna instalacja zarezerwowana jest dla dużych farm hostów, a tak naprawdę trzeba zapłacić za oprogramowanie zarządzające hostami, co na jedno wychodzi. W tym przypadku trzeba sobie radzić za pomocą konsoli tekstowej.  Ale po kolei…

Najpierw należy zalogować się na nasz host używając po prostu przeglądarki internetowej. Z poziomu graficznej konsoli zarządzania trzeba uruchomić usługę SSH. Nie jest ona domyślnie włączona – dla bezpieczeństwa. Wybieramy zatem opcję Manage z okienka Navigator po lewej stronie i w okienku po prawej stronie przechodzimy do zakładki Services. Uruchamiamy usługę TSM-SSH (po zakończeniu aktualizacji warto ją wyłączyć ponownie). Od tej pory możemy połączyć się za pomocą SSH do naszego hosta.

Zaczynamy od sprawdzenia wersji poleceniem:

~ # esxcli system version get
Product: VMware ESXi
Version: 6.7.0
Build: Releasebuild-469512
Update: 0
Patch: 0

Następnie udajemy się na stronę z aktualizacjami dla VMware ESXi i pobieramy właściwą dla naszego systemu. Warto zauważyć, że aktualizacje kumulują się, więc nie ma potrzeby wgrywania wszystkich – wystarczy ostatnia. Dodam, że na pewno trzeba wgrać oznaczone etykietką Critical, reszta według uznania.

Przełączamy host ESXi w tryb Maintenance (za pomocą przeglądarki i strony zarządzającej) i możemy przystąpić do działania. Rozpoczynamy od wyświetlenia listy profili dostępnych w naszym patchu:

~ # esxcli software sources profile list --depot=/vmfs/volumes/ \
datastore1/patch/update-from-esxi6.7-5.0_update03.zip
Name Vendor Acceptance Level
-------------------------------- ------------ ----------------
ESXi-6.7.0-20171002001-standard VMware, Inc. PartnerSupported
ESXi-6.7.0-20171001001s-standard VMware, Inc. PartnerSupported
ESXi-6.7.0-20171001001s-no-tools VMware, Inc. PartnerSupported
ESXi-6.7.0-20171002001-no-tools VMware, Inc. PartnerSupported

Najbezpieczniej jest skorzystać z profilu standardowego, a więc ESXi-6.7.0-20171002001-standard. Jest to zazwyczaj pierwszy dostępny profil z listy. Nim w następnym kroku przystąpimy do aktualizacji serwera, powinniśmy najpierw sprawdzić jaki będzie wynik tej operacji. Z pomocą przychodzi opcja –dry-run. Wpisujemy plecenie:

~ # esxcli software profile update --depot=/vmfs/volumes/ \
datastore1/patch/update-from-esxi6.7-5.0_update03.zip \
--dry-run --profile=ESXi-6.7.0-20131002001-standard
Update Result
Message: Dryrun only, host not changed. The following \
installers will be applied: [BootBankInstaller]
Reboot Required: true
VIBs Installed: 
VMware_bootbank_ehci-ehci-hcd_1.0-3vmw.500.1.11.623860, \
VMware_bootbank_esx-base_5.0.0-3.41.1311175, \
VMware_bootbank_esx-tboot_5.0.0-2.26.914586, \
VMware_bootbank_ipmi-ipmi-si-drv_39.1-4vmw.500.2.26.914586, \
VMware_bootbank_misc-drivers_5.0.0-3.41.1311175, \
VMware_bootbank_net-be2net_4.0.88.0-1vmw.500.0.7.515841, \ 
VIBs Removed: 
VMware_bootbank_ehci-ehci-hcd_1.0-3vmw.500.0.0.469512, \ 
VMware_bootbank_esx-base_5.0.0-0.0.469512, \
VMware_bootbank_esx-tboot_5.0.0-0.0.469512, \
VMware_bootbank_ipmi-ipmi-si-drv_39.1-4vmw.500.0.0.469512, \
VMware_bootbank_misc-drivers_5.0.0-0.0.469512, \
VMware_bootbank_net-be2net_4.0.88.0-1vmw.500.0.0.469512,

Jeśli nie otrzymaliśmy żadnych komunikatów o błedach możemy śmiało przystąpić do właściwej aktualizacji. Tym razem korzystamy z komendy:

~ # esxcli software profile update --depot=/vmfs/volumes/ \
datastore1/patch/update-from-esxi6.7-5.0_update03.zip \
--profile=ESXi-6.7.0-20131002001-standard 
Update Result
Message: The update completed successfully, but the 
system needs to be rebooted for the changes to be effective. \
Reboot Required: true

Na sam koniec nie pozostaje nic innego jak uruchomić ponownie serwer VMware ESXi (skoro sam tego zażądał):

~ # reboot

Po starcie systemu wyłączamy tryb Maintenance i voilá! Prawda, że proste 😉

MG

Tagi: , , , , ,

Kopie zapasowe w sieci Windows – część 2

Lipiec 21st, 2018 | Brak Komentarzy | Kategoria: Porady, Windows

Kopie zapasoweWe wpisie z przed dwóch miesięcy – tak, tak, mnie również dopadło wakacyjne lenistwo, opisywałem jak stworzyć listę komputerów z systemem Windows, które są aktualnie aktywne w naszej domenie lub grupie roboczej. Omówione rozwiązanie działa niezależnie od wszelkich mechanizmów wbudowanych w Active Directory czy też innych. Wspomnianą listę można zapisać np. w pliku tekstowym, po to aby w następnej kolejności zbudować skrypt wsadowy, który wykona kopie zapasowe z komputerów z listy. Ale po kolei.

Po pierwsze, trzeba zapewnić sobie dostęp do zasobów lokalnych komputerów. Jeżeli na każdym z nich mamy swoje konto administracyjne i dodatkowo wszędzie używamy tego samego konta to bardzo łatwo jest odczytać zawartość dysków twardych np. partycji systemowej C:. Nie jest tajemnicą, że w Windows tworzone są standardowe udziały sieciowe np. C$, które odpowiadają całym partycjom. Ja jednak z wielu powodów namawiałbym do utworzenia specjalnego udziału np. o nazwie Archiwum, z uprawnieniami tylko-do-odczytu dla zdalnego adminstratora. Jeśli umówimy się z użytkownikami aby tam właśnie umieszczali ważne zbiory (może to być np. folder D:/Archiwum) to wtedy pozostanie jedynie zadbać o skopiowanie całej zawartości aby zabezpieczyć się przed ewentualną utratą danych.

Jako zagorzały zwolennik Linuksa zawsze uważałem, że nie ma nic lepszego od narzędzia rsync. Jednak jego instalacja w systemie Windows wiąże się z koniecznością zainstalowania całego środowiska Cygwin, lub co najmniej jego bibliotek dll wraz ze wspomnianym narzędziem. Może jednak istnieje coś podobnego dla Windows? Tak odkryłem narzędzie robocopy. Trzeba przyznać, że ma duże możliwości i co ważne potrafi robić lustro katalogów (mirror) a jest to przecież coś o co nam chodzi przy zabezpieczaniu danych.

Ponieważ wspomniana na początku wpisu lista komputerów zawiera ich nazwy netbios (a nie adresy IP) stąd napisanie prostego batcha nie powinno być żadnym problemem. Na pewno powinien zawierać komendę jak w poniższym przykładzie:

ROBOCOPY \\nazwa_netbios\Archiwum \Archiwum_nazwa_netbios /MIR /FFT →
→ /R:3 /W:10 /Z /NP /NDL

Wywołanie robocopy z podanymi parametrami spowoduje wykonanie dokładnego lustra z udziału Archiwum na komputerze nazwa_netbios do katalogu Archiwum_nazwa_netbios na naszym serwerze z kopiami zapasowymi – czyli po prostu lokalnie. Co ważniejsze ponowne jej wywołanie spowoduje wykonanie kopii różnicowej, a więc zapewni dużo szybsze działanie.

Pozostałe opcje pozostawiam dla zainteresowanych odsyłając do dokumentacji polecenia robocopy. Na koniec nadmienię tylko, że sam cały skrypt wsadowy przygotowuje na Linkuksie przy okazji generowania listy komputerów. Jest mi łatwiej to zrobić ze względu na stare przyzwyczajenia i dostepność takich narzędzi jak chociażby awk. Myślę jednak, że równie dobrze można to zrobić w środowisku Windows. Miłej zabawy.

MG

 

Tagi: , , ,

Kopie zapasowe w sieci Windows – część 1

Maj 19th, 2018 | Brak Komentarzy | Kategoria: Porady, Windows

Kopie zapasoweMożna powiedzieć, że wykonujemy kopie zapasowe, bo jest to obowiązek każdego administratora. Oczywiście zdarza się, że o naszych obowiązkach dowiadujemy się kiedy mamy duży problem bo zagineły np. pliki użytkowników. Nie mam w tym miejscu na myśli systemów serwerowych ale archiwa pracowników. Rzadko zdarza się, żeby ktoś zmusił się sam do robienia kopii skoro ma w firmie dział IT.

Niezależnie od tego czy dysponujemy domeną Active Directory, czy prostą grupą roboczą, zawsze warto się zabepieczać. W dzisiejszym wpisie chciałem pokazać jak zbudować prosty system kopii zapasowych, wykonywanych bez żadnych dodatkowych i płatnych narzędzi. W zasadzie wystarczą nam dwie rzeczy:

  • komputer z Linuxem i zainstalowanym pakietem nmap
  • komputer z Windows 7 w górę, który standardowo ma wbudowane polecenie robocopy

Pierwsze narzędzie posłuży nam do odkrywania komputerów, które są aktualnie dostępne w naszej sieci Windows. Zakładam, że na każdym z nich znajduje się udostępniony sieciowo katalog np. o nazwie Archiwum, którego zawartość powinniśmy skopiować do siebie. Wspomniany udział można oczywiście ukryć dodając znak na końcu jego nazwy, czyli powinno być Archiwum$. Pamiętajmy również aby archiwum udostępnić dla użytkownika, z którego konta uruchamiamy skrypty na naszym komputerze. Czyli jeśli pracujemy jako Admin z hasłem password, to udostępniamy zasoby dla takiego samego użytkownika. Jeśli nie mamy domeny, to po prostu dodajmy lokalnie na każdym komputerze takie konto.

Po co wykrywanie aktywnych końcówek w sieci? Otóż zanim zdobędziemy kopie danych musimy być pewni, że dany komputer jest włączony. Z moich doświadczeń wynika niestety, że bazowanie na DHCP, DNS czy skryptach wykozrystujących polecenia ping, arp nie jest skuteczne. Dużo lepiej jest to zrobić używając niezawodnego skanera sieciowego nmap. Oczywiście najlepiej jest uruchamiać go na maszynie z Linuksem. Można używać portów dla Windows, ale osobiście nie próbowałem i ciężko jest mi powiedzieć jaki będzie efekt.

Aby stworzyć naprawdę niezawodny system będziemy jeszcze potrzebować skryptu nbstat.nse. Dzięki niemu będziemy niezawodnie wykrywać aktywne hosty Windows. Przykładowe polecenie ma postać:

nmap -p 137 -sU --script nbstat.nse 192.168.1.1-254

co spowoduje przeskanowanie całej podsieci 192.168.1.1-254 i otrzymamy poniższy rezultat:

Starting Nmap 7.40 ( https://nmap.org ) at 2018-05-19 18:10 CEST
 Nmap scan report for PC1.local (192.168.1.1)
 Host is up (0.0031s latency).
 PORT STATE SERVICE
 137/udp open netbios-ns

Host script results:
 |_nbstat: NetBIOS name: PC1, NetBIOS user: <unknown>, NetBIOS MAC: 
   a4:4c:c8:cd:2f:0f (unknown)

...

Nmap done: 254 IP addresses (6 hosts up) scanned in 55.61 seconds

Z punktu widzenia dalszej obróbki skryptu powinniśmy wyczyścić powyższy raport i można to zrobić w bardzo prosty sposób:

nmap -p 137 -sU --script nbstat.nse 192.168.1.1-254 | →
→ awk '/local/ {print $5}'

Zwracam uwagę, że tym sposobem filtrujemy linie zawierające frazę local, może być to inna fraza, według naszego uznanania i konfiguracji sieci. Tak czy inaczej tym razem otrzymamy już tylko listę adresów IP. Będzie to lista aktywnych w danym momencie końcówek, dla których powinniśmy wykonać kopię plików. Możemy zatem skorzystać z polecenia robocopy, ale o tym następnym razem.

MG

Tagi: , , ,

Logcheck, systemd – zaśmiecone logi

Kwiecień 21st, 2018 | Brak Komentarzy | Kategoria: Linux, Porady

logcheck, systemdWśród administratorów Linuksa, od wielu lat prym wiedzie mały ale bardzo poręczny pakiet logcheck. Narzędzie to wykonuje niezwykle żmudną, ale bardzo potrzebną pracę, polegającą na przeszukiwaniu logów systemowych pod kątem wszelkich anomalii. Skonfigurowane według standardowych zaleceń potrafi być bardzo krzykliwe zasypując nas stosem maili informujących w wykrytych, podejrzanych odstępstwach od prawidłowej pracy systemu operacyjnego. Co prawda zwalnia nas ono z konieczności codziennego przeglądania raportów o systemie, jednak nawet najbardziej usłużne narzędzie będzie bezlitosne jeśli nie zajmiemy się filtrowaniem generowanych komunikatów.

W przypadku logcheck cała sztuka polega na odpowiednim definiowaniu filtrów w katalogach:

/etc/logcheck/ignore.d.{paranoid;server;workstation}

Zazwyczaj wystarczy korzystać ze ścieżki /etc/logcheck/ignore.d.server, wpisując w plikach testowych wyrażenia regularne. logcheck porównuje wyrażenie z wyszukanym rezultatem i w przypadku zgodności zapobiega generowaniu monitu. Budowanie wyrażeń regularnych samo w sobie jest małą sztuką. Czasami niektórzy wpisują po prostu wzorce na sztywno np.

Reloading web server: apache2.

co zapobiegnie periodycznym informacjom o restartowaniu naszego serwera www. Inni zaś potrafią zbudować naprawde wyrafinowane wyrażenia.

W wydaniu 8 Debiana o nazwie Jessie pojawił się jednak pewien błąd, który bardzo utrudnia życie. Dotyczy właśnie filtrowania za pomocą logcheck i demona systemowego systemd. Dotąd nie było żadnych problemów, jednak właśnie Jessie zaczął zasypywać nas komunikatami, które wydają się nie mieć końca. Co ważniejsze żadne filtry wpisane na sztywno nie pomagają, bowiem reguły systemd są bardzo obszerne i groźne byłoby wycięcie informacji, które mogą okazać się istotne z punktu widzienia administrowania naszym serwerem.

W tym przypadku z pomocą przychodzi strona Debian Wiki i gotowy zestaw wyrażeń przygotowanych przez jej użytkowników. Wystarczy skopiować je do pliku tekstowego we wspomnianym wcześniej katalogu i gotowe. Wszytskie aktualne reguły można pobrać, a w zasadzie skopiować pod adresem:

https://wiki.debian.org/systemd/logcheck

Zapraszam 🙂

MG

Tagi: , ,

Czy działa połączenie UDP?

Lipiec 15th, 2017 | Brak Komentarzy | Kategoria: Linux, Porady

UDP

 

 

Jedną z powszechnych czynności administracyjnych jest sprawdzanie stanu połączeń TCP lub UDP z serwerem. Zazwyczaj najpierw sprawdzamy czy serwer odpowiada – służy do tego polecenie ping:

ping 192.168.1.1

Jeśli administrator serwera zablokował protokół ICMP, co wcale nie zdarza się tak rzadko, to możemy posłużyć się poleceniem arping:

arping 192.168.1.1

Trzeba jednak pamiętać, że powyższa komenda zadziała tylko w sieci lokalnej. Kiedy będziemy już pewni, że wszystko z serwerem w porządku to możemy przejść do sprawdzania połączeń z usługami. Najprostszą czynnością będzie wykonanie polecenia telnet ze wskazaniem numeru portu usługi:

telnet 192.168.1.1 80

Powyższa komenda sprawdza połączenie z serwerem WWW na porcie 80. Jeśli wszystko działa powinniśmy otrzymać informację o ustanowieniu połączenia:

Trying 192.168.1.1...
Connected to 192.168.1.1.
Escape character is '^]'.

Jednak omawiane właśnie rozwiązanie dotyczy wyłącznie usług połączeniowych takich tak TCP. Co zrobić w przypadku protokołu UDP, z którego np. korzysta usługa DNS? Tutaj musimy posłużyć się aplikacją netcat, wskazując podobnie jak w poprzednim przypadku numer portu:

nc -vz -u 192.168.1.1 53

Opcja vz zwiększa poziom komunikatów oraz zmusza netcat wyłącznie do sprawdzenia usługi bez wysyłania danych. Z kolei u wymusza korzystanie z pakietów UDP w miejsc TCP. Przy prawidłowym przebiegu operacji otrzymamy informację, na której zależało nam od samego początku:

Connection to 192.168.1.1 53 port [udp/domain] succeeded!

MG

Tagi: , ,

Cron – zabawy z usługą harmonogramu zadań systemowych

Kwiecień 15th, 2017 | Brak Komentarzy | Kategoria: Linux, Porady

Cron - linuksowy budzik systemowyWszyscy użytkownicy Linuxa, zarówno korzystający tylko do celów domowych, jaki i administratorzy systemów serwerowych, na pewno nie raz zetknęli się z tak zwanym harmonogramem zadań systemowych czyli po prostu usługą cron. Pomysłowość ludzka bywa zadziwiająca i osobiście widziałem już najdziwniejsze zastosowania harmonogramu. Można go używać do wykonywania codziennych kopii zapasowych za pomocą ulubionego narzędzia rsync, można co 5 minut synchronizować dane pomiędzy dwoma systemami, można wreszcie wymusić okresowe ponowne uruchamianie usługi systemowej daemona, która nie zachowuje się tak jak byśmy tego oczekiwali. W tym ostatnim przypadku należałoby rzecz jasna zastanowić się raczej czemu usługa nie działa prawidłowo i poprawić jej błędy ale kto może zabronić leniwemu administratorowi pójść na skróty. Tak czy inaczej zastosowań może być mnóstwo.

Generalnie obsługa usługi cron sprowadza się do wywołania prostej komendy z odpowiednimi parametrami. Jeśli chcemy wyświetlić listę aktywnych zadań użyjemy wywołania:

crontab -l

W przypadku dodawania nowego zadania będzie to składnia:

crontab -e

I właśnie dopisanie nowej linijki z poleceniem uruchamiania programu czy skryptu o zadanym czasie, pomimo, że wydaje się stosunkowo proste, bardzo często budzi wątpliwości. Szczególnie początkujący użytkownicy mogą gubić się w gąszczu zasad dotyczących definiowania pory uruchamiania, definiowania okresu powtarzania, stosowania wyjątków itd. Często kończy się to szperaniem za pomocą Google, nikt przecież nie uczy się na pamięć wszyskich reguł. Właśnie w takiej sytuacji może przyjść z pomocą serwis crontab.guru.

Jak już wielokrotnie wspominałem w innych artykułach nie staram się opisywać szczegółowo wad i zalet każdego przytaczanego narzędzia ale jednocześnie gorąco zachęcam do zapoznania się z nim i wypróbowania w codziennej pracy. W końcu wszystko co może uczynić codzienne zadania łatwiejszymi i bardziej przyjemnymi jest warte poświęcenia uwagi. Zatem otwieramy kolejne okienko przeglądarki i wpisujemy adres crontab.guru. Życzę miłej pracy.

MG

Tagi: , ,

Redirect – automatyczne przekierowanie strony www

Marzec 18th, 2017 | Brak Komentarzy | Kategoria: Linux, Porady, Windows

URL RedirectBardzo często zdarza się, że chcemy przenieść serwis www, swoją stronę domową czy nawet pojedyncze statyczne dokumenty HTML pod zupełnie nowy adres. Aby poinformować swoich użytkowników o zmianach można umieścić odpowiedni komunikat na stronie – tzw. URL Redirect Information. Jest to zdecydowanie najprostsza metoda ale czasami warto zastanowić się nad innymi sposobami. Jeśli akurat jesteśmy administratorami serwera to można oczywiście tak skonfigurować serwer wirtualny Apache aby robił to automatycznie:

<VirtualHost *:80>
  ServerName poprzedni_adres.pl
  Redirect permanent / http://nowy_adres.pl
</VirtualHost>

Jednak nie mając tak szerokich możliwości również możemy skonfigurować zaawansowane przekierowanie. Najprościej będzie zrobić to w HTML:

<!DOCTYPE html>
<html>
<head>
<meta http-equiv="refresh" content="0; url=http://nowy_adres">
</head>
<body>
</body>
</html>

Zdarza się jednak, że przeglądarki nie dopuszczają do tego typu przekierowań. Dlatego możemy skorzystać z pliku .htaccess:

Redirect 301 / http://nowy_adres

Jeśli nie mamy powyższych możliwości, nadal możemy próbować, używając JavaScript:

<!DOCTYPE html>
<html>
<body>
<script type="text/javascript">
    window.location.replace("http://nowy_adres");
</script>
</body>
</html>

lub języka PHP:

<?php
header("Location: http://nowy_adres", true, 301);
exit();
?>

Tak czy inaczej, mamy do wyboru całkiem sporo różnych metod.

MG

Tagi: , , ,

Macierz RAID1 i problemy z GRUB2

Luty 18th, 2017 | Brak Komentarzy | Kategoria: Linux, Porady

RAID1Powszechnie wiadomo, że nie jest szczególnie trudno zbudować macierz programową RAID1 używając systemu operacyjnego Debian. Przy instalacji jest to jedna z najczęściej wybieranych opcji, w celu zabezpieczenia się przed niespodziewaną utratą danych. Większość tak zwanych software’owych raidów, oferowanych przez producentów płyt głównych, opiera się właśnie o pakiet mdadm, czyli w zasadzie jest to dokładnie takie samo rozwiązanie jak w przypadku zwyczajnej instalacji. Przyznam się, że często wyłączam raid na płycie głównej, bo wolę panować do końca nad systemem, i po prostu instaluję oprogramowanie ręcznie. I wszystko było by dobrze gdyby nie jeden, nie zrozumiały przeze mnie fakt. Otóż do tej pory, przy składaniu raidu, instalator modyfikuje konfigurację bootloadera grub tylko dla pierwszego dysku (np. /dev/sda). Co oznacza, że w przypadku uszkodzenia drugiego dysku (np. /dev/sdb) twardego komputer przeżyje awarię, jednak jeżeli zostanie uszkodzony pierwszy dysk można mieć sporo kłopotów z jego uruchomieniem. Internet jest pełen takich historii, jak również mnóstwo jest porad jak zapobiegać lub usunąć ten błąd. Ja gorąco będę namawiał do przygotowania się zawczasu i skonfigurowania prawidłowo systemu na samym początku. W tym celu zaraz po instalacji systemy wystarczy skorzystać z trzech prostych poleceń (wydawanych z konta root)):

mv /boot/grub/device.map /boot/grub/device.map.old
grub-mkdevicemap
update-grub2 && grub-install /dev/sda && grub-install /dev/sd

Czasami naprawdę niewiele wystarczy, żeby zabezpieczyć się na przyszłość.

MG

Tagi: , , , ,

Debian Jessie – sshd i obsługa PAM

Styczeń 21st, 2017 | Brak Komentarzy | Kategoria: Linux, Porady

Debian PAMW najnowszej wersji Debiana (Jessie), nie wiedzieć skąd pojawił się błąd związany z obsługą sesji SSH. Do tej pory, wykonując typowe prace administracyjne takie jak aktualizacje, w szczególności wymianę jądra systemu na nowszą wersję, nie było żadnego problemu kiedy trzeba było wydać polecenie reboot. Serwer prawidłowo kończył sesję SSH i po krótkiej chwili można było znowu się połączyć. O ile oczywiście dał radę podnieść się po naszych zabiegach. Tym razem jest inaczej. Krótko mówiąć sesja SSH zawiesza się i bez siłowego zamknięcia terminala nie ma mowy o kontynuowaniu pracy. Związane jest to z obsługą biblioteki PAM. Żeby pozbyć się opisanej niedogodności konieczna jest instalacja dodatkowych bibliotek, które nie są dostarczane w standarowej wersji:

apt-get install libpam-systemd dbus

Na tym nie koniec. Musimy upewnić się, że nasz daemon sshd ma włączoną obsługę PAM. Tak inaczej wystarczy wydać polecenie:

 grep -i UsePAM /etc/ssh/sshd_config

i ewentualnie odkomentować w pliku /etc/ssh/sshd_config wspomnianą linię. Na koniec restartujemy sshd:

/etc/init.d/ssh restart

MG

Tagi: , , ,

Time has been changed – co oznacza ten komunikat

Grudzień 17th, 2016 | Brak Komentarzy | Kategoria: Linux, Porady

Time has been changedJednym z problemów w administracji serwerami (nie tylko inuxowymi) jest synchronizacja czasu. Praktycznie każda usługa systemowa może odmówić posłuszeństwa jeżeli nie zadbamy o prawidłową podstawę czasu. Z pozoru zadanie to jest dość proste. Wystarczy zainstalować pakiet ntp:

 

 

apt-get install ntp

i od razu wszystko powinno działać. Osobiście polecam takie rozwiązanie na każdym sewerze z Linuxem aby właśnie zadbać o zsynchronizowanie naszej skali czasu z serwerami źródłowymi dostępnymi w Internecie. Musimy jednak pamiętać, że oprócz zegara systemowego, każdy komputer wyposażony jest w zegar sprzętowy. Funkcjonowanie tego ostatniego, a raczej jego zła praca, na pewno będzie miała wpływ na stabilność zegara systemowego. Są to bardzo rzadkie przypadki ale zdarzają się. Np. w Debianie Jessie aby zrealizować synchornizację wykorzystywane są kolejno usługi i funkcje systemd, swdate i w konsekwencji Slow Clock Adjuster. Co w moim przypadku, przy korzystaniu z maszyny VirtualBox, i zapewne błędnej obsłudze czasu przez środowisko wirtualne, zaowocowało komunikatami systemowymi (rsyslogd):

host systemd[1]: Time has been changed

Jak wspomniałem, jest to błąd oprogramowania i aby pozbyć się powyższych komunikatów trzeba je po prostu odfiltorwać na poziomie logu systemowego. W tym celu logujemy do konsoli roota i zakładmy plik time_msgs.conf:

touch /etc/rsyslog.d/time_msgs.conf

Następnie edytujemy plik:

vi /etc/rsyslog.d/time_msgs.conf

i dodajemu linijkę:

:msg, contains, "Time has been changed" stop

Po wszystkim musimy ponownie uruchomić usługę:

/etc/init.d/rsyslog stop
/etc/init.d/rsyslog start

Tym samym pozbyliśmy się niepotrzebnych komunikatów z logów systemowych.

MG

Tagi: , , , , ,