my personal page

…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.

A skoro przy biurze jesteśmy… nie każdy wie, że istnieją narzędzia umożliwiające dobranie się do dokumentów Worda, Excela i im podobnych bez potrzeby kupowania jakiejkolwiek licencji (no, poza samymi okienkami). Istnieje coś takiego, jak Word/Excel/PowerPoint Viewer. Niewielkie (jak na standardy Microsoftu, oczywiście) narzędzia, które potrafią wyświetlić i wydrukować dokumenty stworzone przy użyciu ich „pełnowymiarowych” braci. Pod tym adresem znajduje się zestawienie programów ułatwiających życie ludziom, którzy nie dorobili się Office’a.

Na skróty (wersje polskie):
Word Viewer
Excel Viewer
PowerPoint Viewer

Wraz z wprowadzeniem na rynek pakietu Office 2007, Microsoft zmienił sposób zapisywania dokumentów. Teraz używają formatu opartego na Open XMLu, który z założenia powinien być „lżejszy”, bardziej otwarty i w ogóle super-extra-hiper-cudowny. Technicznie aspekty tych formatów niezbyt mnie interesują, a marketingowo jest to dość ostra konkurencja dla powstałego trochę wcześniej OpenDocument (którym natywnie posługuje się np. Open Office).

No dobra, ale co mamy zrobić, jeżeli jesteśmy posiadaczami pakietu Office w wersji wcześniejszej (na przykład 2003 lub XP) i dostaniemy dokument zapisany w nowym formacie? Microsoft to przewidział. Myślał, myślał, i wymyślił. Narzędzie nazywa się „Pakiet zgodności formatu plików pakietu Microsoft Office dla programów Word, Excel i PowerPoint 2007″. Waży kilkadziesiąt mega, ale działa poprawnie. I to nie jest byle programik. Integruje się bowiem z zainstalowanym Office’m i umożliwia odczytywanie i edycję dokumentów w „nowym” formacie za pomocą „starych” narzędzi. Bez dodatkowych kroków typu ręczne konwertowanie plików, albo otwieranie ich za pomocą dodatkowej opcji ukrytej gdzieś w menu. Wszystko przebiega automagicznie. Fakt, pliki otwierają się trochę wolniej, ale przecież zawsze możemy sobie kupić mocniejszy komputer :-)

Nie mam zamiaru rozpisywać się jaki to Microsoft jest cudowny i wspaniały, ale to narzędzie naprawdę ułatwia pracę z klientami i doceniam, że coś takiego zostało wydane.