my personal page

Jakiś czas temu zadzwoniłem radośnie do Microsoftu, żeby uzupełnić braki wiedzy. Konsultanci byli (jak zwykle) bardzo mili i uprzejmi i nawet udało im się rozwiać moje wątpliwości dotyczące zagadnień licencyjnych, jakie wówczas posiadałem. Nawet się trochę zdziwiłem, że nikt później nie zadzwonił i nie badał mnie na okoliczność moich problemów i ich potencjalnego rozwiązania.

Minęło kilka tygodni i znowu moja wiedza okazała się niewystarczająca do rozwiązania problemu z (innym już) produktem Firmy. Tym razem spróbowałem swoich sił i zacząłem przeglądać strony WWW. Po raz kolejny okazało się, że rozwiązanie problemu jest trywialne, tylko ja taki niedouczony. Ale tym razem zaproponowano mi udział w ankiecie, która pytała jak bardzo mi się podobało szukanie znajdowanie informacji. Niby nic wielkiego, ale urzekło mnie jedno pytanie, na które nie znalem (i nie znam do tej pory) odpowiedzi:

Dziś rano spotkała mnie niezbyt miła niespodzianka. Okazało się, że od wczoraj ClamAV w wersji 0.94 nie jest już wspierane. Niby nic, ale w nocy automatycznie uruchomił się freshclam i sam skaner odmówił współpracy. Po aktualizacji do najnowszej (0.96) wersji okazało się, że mój system pocztowy nie jest w stanie skorzystać z aż tak nowego anytwirusa. Stanęło w końcu na wersji 0.95.2-4.el5.rf (pobrałem sobie gotowe paczki do CentOSa z repozytoriów DAG).

Oficjalną informację o końcu wsparcia można przeczytać tutaj.

…okazuje się, że nie jest to wcale takie proste :-(

Opiekuję się siecią, która składa się z kontrolera domeny (Microsoft Windows 2003 server) oraz kilkunastu stacji roboczych z Windows XP. Jakiś czas temu dołożyłem do niej kilka komputerów z Vistą, podłączyłem do domeny i wszystko wydaje się działać w miarę dobrze (na tyle dobrze, na ile pozwala Vista, oczywiście). Jednak właśnie spotkałem się z problemem globalnego wyłączenia UAC. Teoretycznie do takich rzeczy służy GPO i właśnie tego mechanizmu chciałem użyć. Niestety, Microsoft zmienił format plików, które odpowiadają za składowanie szablonów administracyjnych, więc nie mogę sobie tak po prostu dodać nowych do istniejącej domeny :-(

Jedyną metodą, którą do tej pory znalazłem jest podniesienie schematu domeny do wersji 2008 i używanie stacji z Vistą do zarządzania GPO. Nie bardzo mi się taki pomysł podoba… chyba będzie trzeba napisać własne szablony…

Chciałem pozmieniać trochę rzeczy w pliku hosts. Jest to plik odpowiedzialny za (wstępne) rozwiązywanie nazw – ot taki wyjątkowo prymitywny DNS. W Linuksie robi się to dość prosto… vim /etc/hosts. zmienia co trzeba, zapisuje i tyle. W Windowsie teoretycznie też. Plik jest wprawdzie odrobinę zakamuflowany, bo powinniśmy go szukać w c:\%WinDir%\system32\drivers\etc, ale nadal nie wydaje się to specjalnym wyzwaniem. Ponieważ miałem przed sobą Windows w wersji 2003, to uruchomiłem Total Commandera i próbowałem przejść w odpowiednie miejsce. Lekko się zdziwiłem, jak okazało się, że katalog c:\windows\system32\drivers jest… prawie pusty. Dokładniej: znajduje się w nim tylko jeden plik, w dodatku o zerowej długości:

Zacząłem podejrzewać, ze z tym systemem jest coś bardzo nie tak. Ale działa już dość długo i nigdy nie skarżył się na brak, ważnego bądź bo bądź, katalogu. Pomęczyłem trochę google’a i znalazłem winnego. Okazało się, że w 64-bitowych Windowsach jest coś, co nazywa się Windows-on-Windows. Działa to z grubsza tak, że jeżeli 32-bitowa aplikacja chce się dostać do katalogu %WinDir%\System32, to zostaje „przekierowana” w inne miejsce (dokładniej: %WinDir%\SysWOW64). Sam mechanizm robi oczywiście dużo więcej, ale mnie interesowało konkretnie to zachowanie. Jeżeli ktoś potrzebuje się dostać do omawianego katalogu z poziomu 32-bitowch programów, to Microsoft opublikował specjalną łatkę, która to umożliwia. Ponieważ jedyną rzeczą, która mnie interesuje w „zablokowanym” katalogu jest okazjonalna zmiana zawartości pliku hosts, to dałem sobie spokój i uruchomiłem notatnik :-) Ale warto wiedzieć, że takie cuda są i znać metodę ich obejścia.

Microsoft w swoim NTFS 3.0 (czyli systemie plików, który jest domyślny dla Windows od wersji 2000) wbudował mechanizm „junction point„. Wygląda na to, że działa to trochę jak Linuksowe dowiązania symboliczne, ale na odrobinę niższym poziomie. Sam Windows XP dał się oszukać i działa z „podlinkowanym” w ten sposób katalogiem „Program Files” (co jest z resztą jednym z rozwiązań umożliwiających jakąkolwiek normalną pracę z ASUSem EEE PC 901, z którym mam właśnie nieprzyjemność obcować).

Z drugiej strony, ustrojstwo działa wyjątkowo magicznie i zachowuje się w niektórych przypadkach bardzo specyficznie. Przykładowo: możemy takie dowiązanie wyrzucić do kosza za pomocą explorera i wszystko działa dobrze. Ale jak opróżnimy kosz, to znika też zawartość katalogu docelowego. Krótką listę niespodzianek można znaleźć tutaj.

W XPku istnieją co najmniej dwa narzędzia, umożliwiające zabawę z takimi dowiązaniami. Jednym jest programik Linkd.exe, który znajduje się w pakiecie Windows Server 2003 Resource Kit Tools. Drugim – Junction produkcji Sysinternals. Oba pozwalają tworzyć i usuwać tytułowe linki, więc przy prostych zastosowaniach nie widzę specjalnej różnicy. Przewagą drugiego jest to, że nie musimy instalować całego pakietu, jako że jest on dostępny samodzielnie.

Co ciekawe – Windows Explorer wyświetla takie „wskaźniki” z ikonką regularnego katalogu, natomiast Total Commander rozpoznaje, że to niezupełnie pełnowartościowy katalog i ustawia specjalną ikonę.

Spora część sprzedawanych obecnie Pen Drive’ów szczyci się wsparciem dla U3. Pomyślałem, że fajnie by było mieć coś podobnego. Problem w tym, że nie wszystkie moje Peny wspierają tą technologię, oraz że tworzy ona dodatkowy dysk (a mi na służbowej maszynie trochę brakuje literek na dyski :-)). Z U3 dałem sobie więc spokój i zainteresowałem czymś odrobinę innym: PortableApps. Z porównań pomiędzy U3 a PortableApps wynika, iż pierwsze rozwiązanie skupia się na programach komercyjnych, drugie zaś – na świecie Open Source. Dla mnie nawet lepiej.

Całość składa się z PortableApps.com Platform™, które tworzy nam całkiem przyjemne menu (w dodatku potrafiące zrobić kopię zapasową całości) oraz aplikacji. Ze strony można pobrać albo 'platformę’ i wszystkie aplikacje osobno, albo jedną z dwóch wersji PortableApps.com Suite. Ja wybrałem bramkę numer jeden i dociągnąłem sobie zestaw pasujących mi aplikacji. A jest z czego wybierać. Jest nawet dodatek, który umożliwia zintegrowanie mojego ulubionego Total Commandera.

Skonfigurowane i gotowe do działania wygląda mniej więcej tak:

Od długiego już czasu zajmuję się siecią komputerową w pewnej szkole. Trochę mniej dawno szkoła owa dostała pracownię komputerową wyposażoną w sprzęt Apple. Komputery są całkiem miłe, ale (zgodnie z dyrektywami MENu) wszystkie zostały wyposażone w system filtrujący treści niepożądane o nazwie Hektor. Niestety, ustrojstwo niezupełnie działa zgodnie z oczekiwaniami, radośnie wycinając część zdecydowanie potrzebnych stron. W dodatku trochę „psuje” sam system i jest (dla kogoś zupełnie nie znającego MAC OS X) trudno usuwalne. Teoretycznie wystarczy wyłączyć w ustawieniach systemowych i Firefoxie korzystanie z serwera proxy i po sprawie. Teoretycznie, bo Hektor w nieznany mi zupełnie sposób potrafi sobie te ustawienia z powrotem poustawiać, a Firefox przy próbie jakiejkolwiek zmiany ustawień sieciowych zwyczajnie się wywala.

Znalazłem w Sieci instrukcję, jak zmienić tryb pracy Hektora, ale nie o to mi chodziło. I tak styku sieci szkolnej ze światową pajęczyną dzielnie strzeże squid, więc dodatkowy serwer proxy jest mi najzupełniej zbędny. Jak to draństwo usunąć? Właściwie nie wiem :-) Ale nauczyłem się toto wyłączać. Okazało się, że (pomimo zupełnie innej filozofii, niż w Linuksie) MAC OS X ma dość dobrze określone miejsca, w których konfiguruje się co ma być uruchamiane przy starcie systemu a co nie. Aby „pozbyć się natręta” (czyli nie uruchamiać Hektora przy starcie) wystarczy usunąć katalog /Library/StartupItems/Hektor (wraz z całą zawartością) i zrestartować komputer. Po takim zabiegu wszystko zaczyna jakoś lepiej działać. Firefox pozwala zmienić swoje ustawienia i się przy tym nie wykłada, a ustawienia systemowe sam z siebie nie konfigurują proxy. Ponieważ pozostała część infrastruktury i tak odpowiednio wyfiltruje cały ruch, taka konfiguracja jest w dalszym ciągu bezpieczna (nawet z punktu widzenia MENu), a wszystkie reguły określające co jest dobre a co złe „siedzą” w jednym miejscu.

Do mojego nowego openSUSE doinstalowałem sobie Wiresharka. Niestety, po uruchomieniu programu okazało się, że nie jestem w stanie zrobić nic sensownego, ponieważ lista interfejsów sieciowych jest… pusta. No tak, nie jestem root’em, więc takie ograniczenie jest dość oczywiste. Tylko co zrobić, żeby program zadziałał na moim istniejącym profilu?

Pierwszym pomysłem było sudo (które jest przeze mnie intensywnie wykorzystywane w pracy konsolowej). Niestety, samo sudo nie wystarczy:

kbechler@nx9005:~> sudo wireshark
root's password:

(wireshark:27537): Gtk-WARNING **: cannot open display:
kbechler@nx9005:~> 

Problemem jest tu zmienna DISPLAY, która znika podczas zmiany użytkownika. Rozwiązaniem, które udało mi się na szybko zlepić jest trywialny, jednolinijkowy skrypcik:

kbechler@nx9005:~> cat ./wrapper.sh
#!/bin/bash
xterm -e sudo sh -c "export DISPLAY=${DISPLAY}; $1 $2 $3 $4"
kbechler@nx9005:~> 

Trzeba tylko odpowiednio przerobić skrót do programu:
I powinno działać. Po kliknięciu najpierw pojawi się brzydkie okno xterma z pytaniem o hasło root’a (jeżeli nie dopisaliśmy naszego użytkownika do /etc/sudoers z flagą NOPASSWD), a potem system uruchomi Wireshark’a z prawami root’a.

Uzupełnienie: Co ciekawe, w CentOSie sam Wireshark znajduje się w katalogu /usr/sbin, natomiast /usr/bin/wireshark jest dowiązaniem symbolicznym do (odpowiedni skonfigurowanego) consolehelpera. Całkiem miłe :-)

Na co dzień Linuksa używam właściwie tylko na serwerach i dawno nie sprawdzałem, jak wygląda sprawa instalacji pingwina na stacji roboczej. Wygrzebałem więc z szafy jakiegoś laptopa i przystąpiłem do działania. Laptop okazał się sprzętem „nieco” już przechodzonym. Jest to HP/Compaq nx9005 kontrolowany przez procesor Athlon XP2400+ z 512 MB RAMu i 60GB dyskiem. Żaden demon szybkości, ale zainstalować jakąś nową dystrybucję powinno się dać :-)

Zrobiłem małe rozeznanie wśród obecnych dystrybucji i wybrałem sobie openSUSE. Raz, że jest dość popularna, a dwa, że firmowana przez Novella, więc powinna być w miarę dopracowana. Muszę przyznać, że pierwsze wrażenie zrobiła całkiem niezłe – zainstalowałem to sobie testowo na – zrobionej na szybko – maszynie wirtualnej, i nawet zadziałało.

Pierwsza przeszkoda, na jakąś się nadziałem to uszkodzony napę DVD. Instalator dał się załadować, ale nie był w stanie odczytać niektórych plików z płytki. Niestety, innego napędu nie udało mi się szybko znaleźć, więc spróbowałem instalacji przez Internet. (Przy okazji: Podczas konfiguracji sieci w instalatorze mamy wybór pomiędzy DHCPem, a ustawieniami ręcznymi, które został przetłumaczone jako „podręcznik” :-)). Instalacja przebiegła bez problemów, a sam proces można sprowadzić do klikania „Dalej…”. GNOME w openSUSE wygląda zupełnie inaczej, niż ten z CentOSa – jak na mój gust jest bardziej „Windowsowy”. Na razie system udało mi się bez problemów zainstalować. Zobaczymy, czy da się tego używać… :-)

Protokół FTP powstał w roku 1971 jako mechanizm umożliwiający wymianę plików. Pierwotnie stosowany był w sieci ARPANET. Ponieważ miały do niej dostęp tylko wybrane jednostki – nikt nie wysilał się nad zabezpieczeniem przekazywanych danych. W chwili obecnej protokoły które przesyłają hasła w postaci jawnej (czyli nie zaszyfrowanej w żaden sposób) są – przynajmniej dla mnie – wyjątkowo mało użyteczne. Niestety, poza FTP nie znalazłem żadnej wystarczająco mało skomplikowanej metody na przesyłanie plików do zdalnych sieci. Jest coś takiego, jak SFTP, ale połączenie go z chrootem nie jest takie zupełnie trywialne(*). Poza tym każdy użytkownik, korzystający z SFTP musi mieć konto systemowe na serwerze, co nie zawsze jest pożądane/wygodne/możliwe.

Szczęśliwie istnieje „bezpieczna” odmiana FTPa: FTPS, która dodaje wsparcie dla TLS/SSL. W dodatku skonfigurowanie czegoś takiego nie jest zbytnio skomplikowane. W najprostszym przypadku (vsftpd działający na CentOSie) wystarczy wygenerować certyfikat typu self-signed:
[kbechler@flame ~]$ openssl req -new -x509 -nodes -out vsftpd.pem -keyout vsftpd.pem
Generating a 2048 bit RSA private key
.................................................................................................+++
....................................+++
unable to write 'random state'
writing new private key to 'vsftpd.pem'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [PL]:
Locality Name (eg, city) []:
Organization Name (eg, company) []:
Organizational Unit Name (eg, section) []:
Given name []:
Surname []:
Common Name (eg, your name or your server's hostname) []:
Email Address []:
[kbechler@flame ~]$ sudo mv ./vsftpd.pem /etc/vsftpd


Dopisać poniższe trzy linijki do pliku konfiguracyjnego serwera (/etc/vsftpd/vsftpd.conf):
ssl_enable=YES
rsa_cert_file=/etc/vsftpd/vsftpd.pem
force_local_data_ssl=NO

i zrestartować usługę:
[kbechler@flame ~]$ sudo /etc/init.d/vsftpd restart
Shutting down vsftpd: [ OK ]
Starting vsftpd for vsftpd: [ OK ]


Potrzebujemy jeszcze klienta, który wspiera FTPS. Na szczęście ładnie poproszony Total Commander coś takiego potrafi :-)

Różnicę widać od razu:

Niestety, taka konfiguracja nieco nas ogranicza. Serwer vsftpd nie pozwala na logowanie użytkowników bez użycia SSLa, co powoduje, że nie da się do naszego serwera podłączyć używając np. klienta FTP wbudowanego w Windows. Można to zmienić dodając parametr „force_local_logins_ssl=NO” do konfiguracji serwera, ale… ponieważ ludzie są z natury leniwi, to nie będzie im się chciało niczego zmieniać w i dalszym ciągu będą korzystać z połączenia nieszyfrowanego… niestety, na ten problem lekarstwa nie znam :-(

(*) Od wersji 4.8 (ChangeLog) istnieje w OpenSSH parametr ChrootDirectory, który w prosty sposób coś takiego umożliwia.