K-NET s.c.

IPv6 w służbie udziałom sieciowym

Życie lubi często płatać figle. Nierzadko stawia administratorów przed bardzo dziwnymi zadaniami, uwzględniającymi bardzo wydumane ezoteryczne scenariusze działania. Gdybym sam się z tym nie stykał na co dzień, to muszę przyznać, że byłoby mi ciężko uwierzyć. A jednak shit happens jak mawiają.

Dzisiejszy wpis dotyczy sytuacji, w której ktoś postanowił wymienić sprzęt sieciowy, w tym serwery plików NAS (tj. QNAP, Synology) i zastąpić je po prostu udziałami na serwerze plików Windows. Ponieważ nowa polityka bezpiczeństwa nie zakładała wykorzystywania rozwiązań innych niż z systemem Windows, nagle wspomniane wcześniej urządzenia zostały wyłączone. Można powiedzieć – cóż… koszty wdrożenia… ale w ten sposób pozbyto się niemałej przestrzeni dyskowej (chodziło to o kilka, kilkanaście TB), która może być zawsze wykorzystana np. do kopii zapasowych. Nietrudno się domyśleć, że powstał problem jak podłączyć z powrotem urządzenia tak aby nie naruszały zasad bezpieczeństwa. Najlepiej oczywiście lokalnie np. przez port USB, ale po pierwsze nie każde ma taką możliwość, po drugie tracimy w ten sposób masę funkcji, które są wbudowane w gotowce typu NAS. Czyli pozostaje przełożyć dyski do serwerów Windows… otóż nie do końca.

Pierwszą myślą było utworzenie osobnej podsieci lokalnej dla naszego NASa i przygotowanie na wybranym komputerze sieciowego interfejsu wirtualnego tak aby stacja mogła korzystać równocześnie z głównej podsieci i w połączeniu punkt-punkt z dysków NAS (dzięki udziałom SMB). Łatwo powiedzieć i łatwo zrobić jeśli ktoś nie rzuca kłód pod nogi. A tym razem kolejną przeszkodą był fakt, że główny interfejs sieciowy został skonfigurowany do pobierania parametrów IP przez DHCP. Niestety ani Windows 7 ani Windows 10 nie umożliwiają skonfigurowania wirtualnej karty sieciowej jeśli podstawowa korzysta z DHCP. Oczywiście w sieci można znaleźć trochę propozycji rozwiązań, jednak nie działają one wogóle, albo wymagają instalowania dodatkowego oprogramowania. Dodatkowo często po restarcie komputera cała misternie przygotowana konfiguracja idzie w cyfrową niepamięć. I właśnie w tym przypadku przydaje się IPv6.

Wystarczy otworzyć okno właściwości karty sieciowej, żeby zauważyć, że przecież oporócz IPv4 możemy skonfigurować IPv6. Na razie mało kto z tego korzysta, a bywa, że ze względów bezpieczeństwa IPv6 jest wyłączane. Tym razem możemy skonfigurować lokalną sieć IPv6 do połączenia naszego komputera z NASem. Zatem po kolei. Na komputerze Windows dodajemy IPv6 z adresem lokalnym:

fe80::208:9bff:fef9:44f

Lokalny adres IPv6 wygenerujemy przy pomocy strony https://www.ultratools.com/tools/rangeGenerator. Pamiętajmy jednak aby wybrać adres z prefiksem 64. Jest to dosyć często spotykana opcja w gotowcach typu NAS.

Na naszym urządzeniu NAS konfigurujemy IPv6 z tej samej podsieci ale np. z numerem o 1 większym. Czyli uruchamiamy kalkulator z możliwością obliczeń w zapisie szesnastkowym i do wartości 44f dodajemy 1. Powiniśmy otrzymać adres postaci:

fe80::208:9bff:fef9:450

Po restarcie obu urządzeń mamy gotową podsieć lokalną składającą się z komputera Windows i serwera NAS. Musimy tylko wiedzieć jak dostać się do dysków np. z poziomu Eksploratora Plików Windows. Otwieramy zatem eksplorator i w polu adresu wpisujemy:

\\fe80--208-9bff-fef9-450.ipv6-literal.net

Wpisywanie każdorazowo powyższego adresu jest kłopotliwe, można zatem przygotować skrót na Pulpicie albo (jeszcze lepiej) zamontować nasz udział jako lokalny katalog (C:\NAS):

mklink /D C:\NAS \\fe80--208-9bff-fef9-450.ipv6-literal.net\

Pamiętajmy jednak, że montować możemy udział sieciowy (np. \\fe80–208-9bff-fef9-450.ipv6-literal.net\kopie), więc podany przeze mnie przykład nie zadziała 😉 .

MG

Docker, Portainer i kłopoty z OpenProject

Techniki wirtualizacji są obecnie bardzo popularne. Począwszy od tych dostępnych na wyciągnięcie ręki dla każdego użytkownika, mam na myśli VirtualBox, a skończywszy na bardziej rozbudowanych typu VMware ESXi, czy QEMU. Te ostatnie wymagają już środowiska w pełni serwerowego i trochę zaawansowanej technicznie wiedzy (ale bez przesady). Z drugiej strony prężnie rozwija się technologia kontenerów wirtualizacyjnych typu Docker. Stają się one popularne głównie w środowisku programistów (koderów i developerów) bo pozwalają w łatwy sposób instalować całe środowiska z przygotowanych obrazów. Skraca to bardzo czas rozwoju oprogramowania, bo daje do ręki skonfigurowany gotowiec jak np. LAMP czyli Linux, Apache, MySQL, PHP/Python/Perl.

W tym wpisie chciałem się właśnie skupić się na apliakcji Docker. Wynika to głównie stąd, że jakiś czas temu realizowałem projekt polegający na zainstalowaniu całego środowiska developerskiego. Składały się na nie serwer z Debianem oraz 3 kontenery: GitLab, Nextcloud i OpenProject. Można powiedzieć solidne środowisko do pracy dla programistów. Całość została uruchomiona w sieci lokalnej, a każdy z wymienionych kontenerów był dostępny pod swoim własnym adresem IP oraz wewnętrzną nazwą domenową. Przy tej okazji chciałem podzielić się dwoma spostrzeżeniami, dotyczącymi problemów, których zrozumienie i dla których przygotowanie rozwiązania bardzo ułatwiło mi opracowanie rozwiązań. Jeden będzie dosyć ogólny, drugi zaś to przykład debugowania rozwiązania i zaaplikowania specyficznej łaty. Ale po kolei.

Środowiskiem kontenerów Dockera można zarządzać oczywiście za pomocą linii komend. Jednak jako alternatywe polecam gorąco projekt o nazwie Portainer. Instalowany jako jeden z pierwszych kontenerów naszego Dockera pozwoli w dosyć prosty i elegancki sposób zarządzać całością. Zwolenników aplikacji webowych ucieszy na pewno fakt, że jest to po prostu serwer, który udostępnia interfejs przeglądarkowy. Możemy zarządzać praktycznie wszystkimi potrzebnymi modułami w tym: kontenerami, obrazami, wolumenami i sieciami. Możliwości jest dużo więcej i najlepiej jest zainstalować to oprogramowanie samemu, żeby o tym się przekonać. Tym bardziej, że jest to łatwe jak instalacja każdego kontenera w Dockerze 🙂

Drugim problemem, bardziej złożonym, okazała się isntalacja OpenProject. Chciałbym o tym wspomnieć ponieważ jest to bardzo dobry przykład na to, z jakimi problememi można się spotkać używając Dockera. Sama instalacja z oficjalnego, przygotowanego przez autorów obrazu nie nastręcza większych żadnych trudności. Zaraz po uruchomieniu wszysko działa dobrze. Jednak z czasem, gdy będziemy musieli zrestartować cały serwer, a co za tym idzie swoje kontenery również, może się okazać, że OpenProject odmawia posłuszeństwa. Zamiast głównej strony serwisu natkniemy się na informacje o niedostępności. Po przeprowadzeniu wspomnianego na początku debugowania oraz sprawdzeniu stanu samego kontenera (który zachowuje się jak najbardziej poprawnie, czyli uruchamia się i nie zgłasza żadnych błędów) okazało się, że przyczyną jest zatrzymanie się serwera Apache. Niestety ręczne uruchamianie daemona również nie pomaga. Problem jest nieco głębszy i polega na tym, że w trakcie restartu kontenera zdarza się, że nie jest usuwany plik apache2.pid, co z punktu widzenia systemu oznacza, że Apache jak najbardziej działa cały czas (co nie jest prawdą). Rozwiązanie jest dosyć proste. Plik ten należy usunąć ręcznie, czyli:

• z poziomu Portainera (omówionego akapit wcześniej) połączyć się z konsolą,
• usunąć ręcznie plik PID: rm -f /var/run/apache2/apache2.pid,
• uruchomić Apache: /etc/init.d/apache2 start.

Powyższa sztuczka pokazuje, że pomimo iż oficjalne kontenery Dockera zazwyczaj działają bez zarzutu to czasami wymagana jest głębsza wiedza i grzebanie w czeluściach obrazu.

MG

Aktualizacja hosta ESXi

Wirtualizacja 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

Kopie zapasowe w sieci Windows – część 2

We 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

Kopie zapasowe w sieci Windows – część 1

Moż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

Logcheck, systemd – zaśmiecone logi

Wś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

Telnet – instalacja na Windows Server 2016

Środowisko systemów serwerowych Microsoft zmienia się bardzo dynamicznie. Nie ma co ukrywać, że konkurencja rozwija się bardzo szybko i pomimo, że mogłoby wydawać się, iż nic nie zagrozi dominacji serwerów Windows w segmencie małych i średnich firm wykorzystujących rozwiązania oparte o MS SQL, to sam Microsoft wprowadza modyfikacje podążające za najnowszymi trendami. Nie ukrywam, że na przykład bardzo mnie cieszy współpraca z Canonical i migracja części narzędzi terminalowych wprost z Linuxa. Bo właśnie o terminal tutaj chodzi, a będąc bardziej precyzyjnym o wygodę z jego korzystania (czyli np. poleceń telnet, ftp itd.). Narzędzia interfejsu graficznego mają swoje zalety, w szczególności dla początkującego użytkownika, jednak jeśli ktoś przebrnie przez początkowe trudności to zazwyczaj docenia mocno wygodę korzystania z trybu tekstowego.

W dzisiejszym wpisie chciałem pokazać jak zainstalować narzędzia Windows 2016 Server za pomocą 3 metod. Jak można się domyślić z poprzedniego akapitu skupię się raczej na terminalu niż na okienkach konfiguracyjnych. Za przykład posłuży nam program telnet.

Po pierwsze warto sprawdzić czy przypadkiem telnet nie został już zainstalowany w systemie. Można sprawdzić to w bardzo prosty sposób. Otwieramy terminal tekstowy i wpisujemy polecenie:

C:\>telnet google.com 80
 'telnet' is not recognized as an internal or external command, →
 → operable program or batch file.
C:\>

Powyższy komunikat świadczy, że należy włączyć narzędzie na poziomie serwera, czyli po prostu zainstalować aplikację.

Tereaz możemy przejść do instalacji w zwykłym terminalu tekstowym (uruchamianym poleceniem cmd – command prompt):

dism /online /Enable-Feature /FeatureName:TelnetClient

Po krótkim oczekiwaniu aplikacja zostanie zainstalowana.

Na tym nie konczą się nasze możliwości ponieważ można zrobić to samo w słynnym PowerShellu. Tym razem trzeba użyć polecenia:

Install-WindowsFeature -name Telnet-Client

W szczególności to rozwiązanie wydaje się być bardzo ciekawe, a użycie polecenia Install-WindowsFeature daje nam naprawdę duże możliwości. Polecam potestować – więcej informacji można znaleźć w dokumentacji na stronach Microsoftu.

Trzeciej opcji, którą jest instalacja w trybie okienkowym, nie będę opisywał. Z premedytacją – jako zwolennik terminali tekstowych.

MG

sudppipe – tunel UDP dla Windows

Systemy serwerowe rodziny Windows stają się praktycznie niezastąpione w środowisku, gdzie jesteśmy zmuszeni korzystać z firmowych systemów bazodanowych. Oferta tych ostatnich zakłada w zasadzie wykorzystanie tylko jedynego słusznego środowiska pracy. Czasami nastręcza to nietypowych trudności, w szczególności gdy chodzi o sterowanie przepływem komunikacji. Oprogramowanie zapory sieciowej wbudowane w serwer w zasadzie nie pozwala na łatwe przekierowywanie komunikacji TCP nie wspominając już o UDP. Jeśli trafimy na środowisko homogeniczne, to skonfigurowanie wyżej wymienionych przekierowań może być trudne. Podstawowym narzędziem jest tutaj komenda linii poleceń netsh opisana w innym artykule.

Jeśli posiadamy urządzenia takie jak np. drukarki sieciowe, to przydatne staje się zarządzanie nimi za pomocą protokołu SNMP. W tym momencie może się okazać, że powinniśmy przygotować przekierowanie portów UDP na serwerze Windows. Zakładam tutaj, że drukarki sieciowe są skonfigurowane w oddzielnym VLANie, ale również w oddzielnej podsieci IP. Jeśli zatem chcielibyśmy dostać się do urządzenia SNMP z puli klienckiej (posiadającej własny VLAN) musimy włączyć tzw. port forwarding, z tym że dla UDP.

Zmagając się z opisanym problemem trafiłem na bardzo przydatne narzędzie dostępne na stronie Luigiego Auriemmy. Wśród dostępnych aplikacji znajduje się mały program o nazwie sudppipe. Wywołany z linii poleceń pozwala skonfigurować tunel UDP na serwerze Windows. Całość wygląda w działaniu zachęcająco:

Usage: sudppipe.exe [options] <server*> <server_port> <local_port>

Sprawdziłem i działa bez zarzutu. Zachęcam do szczegółowego zapoznania się z jego możliwościami.

MG

burndisk – nagrywanie płyt CD/DVD z linii poleceń

Czasami tak się zdarza, że jesteśmy zmuszeni zrezygnować z naszego ulubionego środowiska pracy na rzecz rozwiązań narzuconych z góry. W moim przypadku musiałem się pogodzić z pożegnaniem z Debianem i przenieść ulubione skrypty systemowe na system Windows. Chodziło rzecz jasna o zachowanie tych samych funkcjonalności, a jedną z nich było automatyczne wykonywanie kopii serwera baz danych i zapisanie ich na płycie DVD Blue Ray.

Nie chcę tutaj szczegółowo rozpisywać się na temat pisania skryptów wsadowych, czy systemowych jak kto woli, bo informacji na ten temat jest aż za dużo i nie jest to żadna specjalistyczna wiedza. Każdy średnio zaawansowany użytkownik Windows wie jak napisać prosty skrypt typu bat lub cmd. Co jednak zrobić kiedy w grę – z przyczyn oczywistych – wchodzi wykorzystanie narzędzia linii poleceń, które pozwoliłoby „wypalić” płytę.  Do tego płytę Blue Ray.

Z początku chciałem użyć jednego z portów narzędzi linuksowych takich na przykład, które są oparte na bibliotece cygwin. Rozwiązanie jednak okazało się niemożliwe bo po prostu nie mogłem zainstalować żadnej nowej aplikacji w systemie. Ot takie wytyczne dotyczące polityki bezpieczeństwa.

Potem, zrezygnowany zacząłem przeszukiwać sieć, żeby poczytać trochę o komercyjnych (czytaj płatnych) rozwiązaniach. Tutaj programiści mają wiele kombajnów do zaoferowania, ale jak należy się spodziewać za odpowiednią cenę. Oczywiście nie chciałem tracić czasu na negocjacje z właścicielem serwerów. Tym bardziej, że po zakupie drogiej technologii opartej o serwery firmy Dell i oprogramowanie Windows Server, środki na rozbudowę inwestycji stopniały praktycznie do zera.

Na szczęście, jak już się wielokrotnie przekonałem, wytrwałe szukanie przynosi w końcu efekty. Znalazłem prostą i efektywną aplikację, narzędzie o nazwie burndisk, a ściślej mówiąc pojedynczy plik wykonywalny burndisk.exe. Nie ma potrzeby instalacji, a użycie w skrypcie jest bajecznie proste. Całość sprowadza się do wywołania programu z odpowiednimi przełącznikami co w moim przypadku sprowadziło się do komendy:

burndisk.exe /write {pliki_do_skopiowania} {symbol_napędu_DVD} ⇒
⇒ /vol {etykieta_woluminu}

Dodam, że program doskonale nagrywa wszystkie rodzaje płyt CD/DVD, korzystając z systemowego API. Po więcej informacji zapraszam na stronę producenta.

MG

FTP z linii poleceń w systemie Windows

O tym, że linia poleceń w przypadku systemów takich jak Linux daje szerokie możliwości nie trzeba się specjalnie rozpisywać. Czasami jednak jesteśmy zmuszeni napisać skrypt systemowy dla serwera Windows i wtedy nie jest już tak prosto. Mam na myśli całkiem konkretny przypadek z własnego podwórka. W dużym skrócie zadanie polegało na okresowym wysyłaniu pliku baz danych MSSQL na zewnętrzny serwer FTP. Z jednej strony sprawa dosyć prosta, bo od razu przychodzi na myśl wykorzystanie harmonogramu zadań systemowych i użycie odpowiedniego skryptu wsadowego, z drugiej strony okazało się jednak, że narzędzie linii poleceń Windows takie jak komenda ftp niespecjalnie radzi sobie z trybem pasywnym transmisji. Zgodnie z dokumentacją wszystko powinno działać bez problemu, można nawet użyć spreparowanej wcześniej listy poleceń ftp, aby zautomatyzować zadanie jednak bardzo często w trakcie wykonania program zawiesza się. W sieci można znaleźć mnóstwo porad co zrobić w takiej sytuacji. Postanowiłem się tym razem podzielić innym rozwiązaniem.

W miejsce polecenia ftp można użyć dobrze znanego programu WinSCP. W skład tego pakietu wchodzi program o nazwie winscp.com, który pozwala na użycie w trybie wsadowym:

winscp.com /command "open ftp://uzytkownik:haslo@serwer.ftp/" →
→ "put plik.sql /home/user/" "exit"

Warto zwrócić tutaj uwagę na niezwykłą prostotę składni polecenia. Po przełączniku command następuje po prostu lista poleceń do wykonania. Ponieważ całość mieści się w jednej linii można w zasadzie całą komendę wpisać wprost do harmonogramu zadań systemowych. Dodatkowym plusem będzie możliwość obsługi protokołu szyfrowanego np. SFTP, czego nie potrafi zrobić narzędzie wbudowane w Windows.

MG