Zadanie jest następujące: dostać się za pomocą protokołu RDP (port tcp/3389) do maszyny o adresie 192.168.0.2. Host, do którego będziemy ustanawiać sesję SSH musi oczywiście wiedzieć, co to jest 192.168.0.2 i mieć dostęp do odpowiedniego portu.

1. Uruchamiamy PUTTY i wpisujemy nazwę domenową (lub adres IP) hosta, który rozumie SSH:

2. Przechodzimy do zakładki „Connection -> SSH – > Tunnels” i wypełniamy odpowiednie pola:
„Source port” to port TCP po stronie naszego lokalnego komputera, który „zmapujemy” na zdalną maszynę
„Destination” to adres i numer portu TCP zdalnego systemu

Potem wciskamy guzik „Add”. Możemy oczywiście dodać więcej portów (niekoniecznie do tego samego hosta).

Na koniec wciskamy „Open”, uwierzytelniamy się po SSH i możemy łączyć się ze zdalnymi zasobami używając adresu loopback (127.0.0.1) i odpowiednich portów.

Okazuje się, że zmiana domyślnych wartości parametrów jest wyjątkowo trywialna. Oto, co należy zrobić:
1. Otworzyć nowe okno putty,
2. Wybrać „Default Settings” z okna zapisanych sesji i wcisnąć „Load”,
3. Poustawiać sobie opcje według uznania (np. zmienić domyślne kodowanie na UTF-8 i „podrasować” kolorki),
4. Wrócić do „głównego” okna programu, czyli zakładki „Session”,
5. Pilnując, aby „Default Settings” było ciągle aktywną opcją, wcisnąć „Save”.

I tyle. Dzięki temu, w rejestrze Windows w gałęzi HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\Sessions zostanie utworzona nowa struktura opisująca domyślne parametry, które putty będzie od tej pory wczytywało od razy po uruchomieniu. Niby proste, ale na tyle nieuntuicyjne (przynajmniej dla mnie), że postanowiłem to opisać.

Mam router łączący sieć lokalną w pewnym budynku ze światem. Prosty routing, kilka ACLek, NAT, niby nic ciekawego. Ale zachciało mi się podłączyć to urządzenie do Cacti celem stałego monitorowania działalności użytkowników. O ile wykresy dotyczące obciążenia procesora oraz ilości przepływających przez interfejsy danych udało mi się wyklikać w ciągu minuty, to na badaniu ilości bieżących translacji poległem. Wymęczyłem dość porządnie wujka Google i udało mi się dowiedzieć jedynie tyle, że inni także mają taki problem. Niby znalazłem template do kaktusa, który robi dokładnie to, czego mi potrzeba, jednak mój router (Cisco 1811) uparcie wyrzuca na użytym w szablonie (nie wiem, jak przetłumaczyć template) OIDzie (.1.3.6.1.4.1.9.10.77.1.2.3.0) same zera. I wygląda na to, że w prosty sposób nie da się tego zrobić. Jedyne, co mi – na razie – przychodzi do głowy, to napisanie jakiegoś wrappera do CLI, ale eleganckie to to nie będzie…

let g:C_Libs = '-lm -lpthread'

Wprawdzie działa to w odniesieniu do wszystkich „projektów”, które otwieram z VIMie, ale jest jednak bardziej eleganckie od ręcznego grzebania w samym c.vim’ie.

1. Musimy posiadać odpowiedni certyfikat do podpisywania maili. Ponieważ podpisywanie odbywa się za pomocą klucza prywatnego, a potwierdzenia autentyczności można dokonać przy użyciu (ogólnie dostępnego) certyfikatu – musimy takową w jakiś sposób zdobyć.
Można ją kupić w dowolnym centrum, jak np. VeriSign – wtedy będziemy wyglądać bardzo profesjonalnie, a nasz certyfikat będzie automatycznie rozpoznawany przez większość używanych obecnie programów. Jest to jedyna rozsądna opcja, jeżeli chcemy taką funkcjonalność oferować klientom. Jednak do testów wygenerowałem sobie certyfikat podpisany przez moje (światowo niezaufane :-)) centrum. Opisów, jak „zrobić” sobie taką infrastrukturę jest w Sieci całkiem sporo i nie będę tego teraz opisywał.

2. Musimy zebrać certyfikaty użytkowników, do których będziemy wysyłać maile. Szyfrowanie danych odbywa się za pomocą certyfikatu (dostępnego publicznie) i bez niego raczej ciężko nam będzie cokolwiek zrobić. Certyfikaty klientów nie muszą by wygenerowane przez zaufane centrum, a nam zależy wyłącznie na tym, aby klucze prywatne, które są z nimi powiązane, były odpowiednio bezpieczne.

3. Ktoś powinien nam dostarczyć odpowiednie dane, które będziemy wysyłać – w moim przypadku będą to pliki PDF, które wygeneruje SAP lub jakiś inny potwór, którego działania nie rozumiem.

4. Trzeba tego PDFa jakoś zaszyfrować, podpisać i wysłać.

I tu zaczynają się schody… o ile zaszyfrowanie i podpisanie maila jest operacją dość prostą:

cat ./plik.txt | openssl smime -encrypt cert_kogos.pem | openssl smime -sign -signer cert.pem -inkey privkey.pem

to wysłanie tego mailem w taki sposób, żeby było poprawnie wyświetlone w czytniku poczty, nie jest już takie oczywiste.

Próbowałem na różne sposoby, jednak za pomocą „czystej” konsoli nie udało mi się osiągnąć tego, co sobie wymyśliłem. Rozwiązaniem okazało się napisanie prostego skryptu w PERLu, który to wszystko po kolei zrobi:

#!/usr/bin/perl
use MIME::Lite;
use Crypt::SMIME;
 
$wiadomosc = MIME::Lite->new(
        From            => 'moj_adres@gmail.com',
        To              => 'odbiorca@wp.pl',
        Subject         => 'temat',
        Type            => 'TEXT',
        Data            => "Dzien dobry\n\nTRESC\n\n-- \nPozdrawiam,\nKonrad"
);
 
$wiadomosc->attach(
        Type            => 'application/pdf',
        Path            => 'tajne_dane.pdf',
        Filename        => 'tajne_dane.pdf'
);
 
{
    local $/=undef;
    open(MY_PKEY, "certs/moj_klucz.pem") || die "open failed: $!"; $privkey = ;
    open(MY_CERT, "certs/moj_cert.pem") || die "open failed: $!"; $cert = ;
    open(TO_CERT, "certs/cert_odbiorcy.pem") || die "open failed: $!"; $to_cert = ;
}
 
$smime = Crypt::SMIME->new();
$smime->setPrivateKey($privkey, $cert);
$smime->setPublicKey($to_cert);
$tmp = $smime->sign($wiadomosc->as_string);
open(MAIL, "|/usr/sbin/sendmail -t");
print MAIL $smime->encrypt($tmp);
close(MAIL);

No dobra, biblioteka MIME::Lite została tutaj użyta dość osobliwie, bo wcale nie do wysyłania maili, ale jest to najprostszy sposób sformatowania maila przed jego zaszyfrowaniem, na który wpadłem. Poza tym, PERLa właściwie nie znam, a ten kod powyżej to „składanka” z przykładów, które znalazłem gdzieś w Sieci.

Teraz muszę się jeszcze zająć tematem podpisywania samych PDFów. No bo skoro ma być tak super profesjonalnie, to dlaczego nie? :-)

W jednym z oddziałów jest sobie serwerek, robiący bardzo ważne rzeczy. Do maszyny udało się kiedyś „wepchnąć” siedem dysków SCSI oraz kontroler Adaptec 2130. Dyski podzielone zostały na dwie macierze: RAID-1 (mirror, 2 dyski) na system, oraz RAID-5 na pięciu pozostałych dyskach na dane. Działało to przez ostatnich kilka lat bez żadnych problemów, dokładnie tak samo, jak podobne maszyny w innych miejscach. Niestety, w pewnym momencie urządzenie stwierdziło, że ma dość i postanowiło się zepsuć, dość dziwnie z resztą. Do tej pory widziałem już różne awarie sprzętowe – łącznie z wybuchem backplane’a, który osmalił kilka najbliżej zamontowanych dysków i zaczął niemiłosiernie śmierdzieć. Ale sytuacja, w której kontroler zgubił jednocześnie dwa dyski – a przynajmniej tak twierdził – była dla mnie czymś zupełnie nowym.
Pierwsze, co zrobiliśmy, to otworzenie obudowy i sprawdzenie, czy wszystkie kabelki są na swoich miejscach, czy dyski się kręcą i czy nie ma śladów pożaru. Po dokładnych oględzinach okazało się, że wszystko powinno działać poprawnie. Jednak nie działało.
BIOS kontrolera poprosił o zaakceptowanie „nowej” konfiguracji i bez tego nie chciał współpracować. Dalej było jeszcze gorzej – macierz zniknęła! Poza tym okazało się, że kontroler owszem, widzi wszystkie dyski, ale dwa z nich mają wyjątkowo dziwne wielkości (na poziomie 100MB każdy). Co ciekawe, modele dysków wyświetlane były poprawnie. Wszelkie próby nakłonienia sprzętu do zmiany błędnych wartości (poprzez wybieranie „rescan” we wszelkich możliwych miejscach) nie dały nic. Dopiero „initialize disks” pomogło i dyski zaczęły identyfikować się poprawnie. Ale co z tego, jak macierzy w dalszym ciągu nie było i zapowiadało się żmudne odtwarzanie systemu z kopii zapasowej, która znajdowała się w innej lokalizacji (backup off-site)?
I w tym momencie z pomocą przyszła strona producenta kontrolera. Okazało się, że w przypadku utworzenia nowej macierzy z tego samego zestawu dysków i z tymi samym parametrami, jest szansa na dostęp do znajdujących się tam danych. Szczegóły opisane są na tej stronie. Szczęśliwie poprzednio tworzyliśmy tą macierz w sposób wyjątkowo standardowy, więc nie miałem problemów z „odtworzeniem” parametrów.
Po restarcie okazało się, że faktycznie zawartość macierzy ocalała i mogłem się dostać do danych. Oczywiście pierwsze, co zrobiłem, to skopiowanie tego wszystkiego w inne miejsce, ale cała procedura zaoszczędziła kilkunastu/kilkudziesięciu godzin, które zajęłoby odtwarzanie tego wszystkiego z zewnątrz.

Mamy mało krytyczny serwer, świadczący pewne usługi dla użytkowników. Dopóki działa i robi swoje, nikt się do niego nie dotyka. Ale ostatnio zachciało mi się przejrzeć listę systemów i porobić trochę aktualizacji. Byłem dość mocno zdziwiony, jak po zalogowaniu i wpisaniu „yum clean all”, program zawisł. Dosłownie – nie reagował na nic, poza „kill -9″. Zacząłem przeglądać logi, porównałem konfigurację, wyłączyłem wszystkie pluginy – nadal nic. Następnym krokiem byłoby przeinstalowanie pakietu, ale w tym wypadku było to mało realne (no bo przecież do instalacji potrzebny jest właśnie YUM, który nie działa).
Poszedłem więc odrobinę inną drogą i ściągnąłem sobie ręcznie nową wersję bezpośrednio z repozytorium CentOSa (wget jest jednym z bardziej przydatnych narzędzi w ratowaniu systemu). „rpm -U yum…” i…. wisi!
Okazało się, że uszkodzeniu uległa baza pakietów (a dokładniej, pliki blokad) RPMa. Wystarczyło je usunąć:
rm -f /var/lib/rpm/__db*żeby wszystko wróciło do normy. Warto zapamiętać ;-)

Systemem wykonującym kopie bezpieczeństwa dla wspomnianych przeze mnie systemów jest Linux (konkretnie CentOS w wersji 5). Po przejrzeniu informacji dostępnych w Internecie okazało się, że metod szyfrowania systemów plików nie ma wcale tak dużo. Pierwszym kandydatem był TrueCrypt, którego z powodzeniem używam w wielu innych miejscach (zarówno zawodowo, jak i prywatnie), jednak – z niewiadomych mi przyczyn – był mało stabilny i potrafił wywalić całą maszynę. Znalazłem nawet informację, że problem faktycznie występuje i że zostanie to kiedyś poprawione. Ale potrzebowałem czegoś „na już”, więc zacząłem szukać dalej. Ostatecznie padło na LUKSa. Nie będę się specjalnie rozpisywał, co można za pomocą tego oprogramowania zrobić, bo jest to ładnie opisane na stronie domowej. Ograniczę się jedynie do krótkiej ściągawki, jak wykonać podstawowe czynności.

Załóżmy, że dysk, który chcemy „zaLUKSować” to /dev/sdd1. Podstawowym narzędziem, jakiego będziemy używać to „cryptsetup”.

Sprawdzanie, czy dane urządzenie nie jest już przypadkiem zaszyfrowane:
cryptsetup isLuks /dev/sdd1 2>>/dev/null && echo TAK || echo NIE
Jeżeli poprzednie polecenie dało wynik negatywny (czyli nie jest jeszcze zaszyfrowane), to możemy je „sformatować”:
cryptsetup luksFormat /dev/sdd1
Teraz warto sprawdzić, czy operacja się faktycznie udała i podejrzeć nagłówek LUKSa:
cryptsetup luksDump /dev/sdd1
Nastepnym krokiem jest „otworzenie” zaszyfrowanego urządzenia:
cryptsetup luksOpen /dev/sdd1 bkpPo tej operacji powinno nam się w systemie pojawić nowe urządzenie blokowe, do którego możemy uzyskać dostęp poprzez /dev/mapper/bkp.

Po zamontowaniu możemy sobie obejrzeć jego „stan”:
dmsetup info bkp
Jeżeli wszystko się zgadza (a przynajmniej nie ma żadnych rażących błędów), przystępujemy do tworzenia systemu plików:
mke2fs -j /dev/mapper/bkp

Na koniec wystarczy zamontować system plików w systemie:
mount /dev/mapper/bkp /mnt/usb…i cieszyć możliwością ukrywania naszych ściśle tajnych danych przed światem.

Po zakończeniu zabawy należy oczywiście odpowiednio wszystko pozamykać:
sync
umount /mnt/usb
cryptsetup luksClose bkp

Kilka lat temu napisałem w VBscripcie prosty skrypt, który kasuje pliki starsze, niż zadana ilość dni. Niby nic wielkiego – tych kilku linijek kodu używam z powodzeniem do dnia dzisiejszego i zawsze działa to tak samo dobrze. Niedawno jeden z moich współpracowników potrzebował zautomatyzować pewien proces i musiał zrobić dokładnie to samo, co mój skrypt. Poszedł jednak zupełnie inną drogą i mój misterny kod został bez litości „zredukowany” do jednej linijki. Jest to doskonały przykład na to, że nie zawsze to, czego używamy od wielu lat jest na pewno najlepsze i najbardziej optymalne.
Na swoje usprawiedliwienie mogę napisać jedynie to, że mój skrypt powstał jako część większej całości i nie zastanawiałem się wtedy, czy istnieje jakieś specjalne polecenie, którym mógłbym wykonać zadaną czynność. Dopisałem po prostu kolejną część w języku, którego akurat używałem.

Mój skrypt, który wygląda tak:Option Explicit
'
' Skrypt kasuje wszystkie pliki z katalogu "path", które są starsze, niż "max_age" dni
'
Dim FSO : Set FSO = CreateObject("Scripting.FileSystemObject")
Dim path : path = "c:\what\ever"
Dim folder : Set folder = FSO.GetFolder(path)
Dim max_age : max_age = 3
Dim file, age
'
For Each file In folder.Files
age = CStr(DateDiff("s", file.DateLastModified, Now))
age = age\(3600*24)
If age > max_age Then
WScript.Echo Now & " - kasuje plik: " & path & "\" & file.Name
FSO.DeleteFile(path & "\" & file.Name)
End If
Next
'
WScript.Quit


został zastąpiony taką oto linijką:forfiles -p "C:\what\ever" -s -m *.* -d -3 -c "cmd /c del @path"

A co w przypadku Linuksa? Tutaj – szczęśliwie – zawsze używałem konstrukcji, którą chyba dość trudno będzie uprościć:

find /sciezka/do/plikow/* -mtime +10 |xargs rm -rf

Wiem, że można użyć parametru „exec” finda i zapisać powyższe jakoś tak:
find /sciezka/do/plikow/* -mtime +10 -exec rm -rf {} \;
jednak połączenie z xargs wydawało mi się zawsze bardziej „poukładane” :-)

1. Musimy włączyć możliwość logowania się na supervisora za pomocą SSH – robi się to z konsoli systemowej w taki sposób.

2. Logujemy się jako root na naszego hosta (oczywiście za pomocą odblokowanego wcześniej SSH).

3. Tworzymy plik, który będzie opisywał „usługę” odpowiedzialną na serwer NTP na lokalnym hoście i otwierał dla nas port udp/123:cat < /etc/vmware/firewall/ntp.xml
<ConfigRoot>
<service>
<id>NTP server</id>
<rule id='0000'>
<direction>inbound</direction>
<protocol>udp</protocol>
<porttype>dst</porttype>
<port>123</port>
</rule>
</service>
</ConfigRoot>
EOF


4. Musimy teraz przeładować konfigurację zapory:esxcli network firewall refresh

5. W konsoli administracyjnej ESXa powinna nam się pojawić nowa usługa, którą możemy teraz włączyć:

6. Warto jeszcze – tak na wszelki wypadek – sprawdzić, czy serwer NTP jest faktycznie włączony i czy będzie sam startował przy uruchamianiu systemu:~ # /etc/init.d/ntpd status
ntpd is running
~ # chkconfig --list ntpd
ntpd on
~ #


I to wszystko. Jeżeli wszystko się uda, to możemy cieszyć się serwerem czasu na hoście ESXi :-)

Oczywiście sam tego wszystkiego nie wymyśliłem. Skarbnicą wiedzy o hypervisorach ESXi jest ten blog. Opisana tu procedura oparta została o ten wpis.