vermin.eu.org

Powstał następujący problem - chciałem sobie włączyć film pod linuxem. Rzadko to robię, bo jednak jak jestem pod linuxem to pracuję, a relax mam pod Windowsem. Okazało się jednak, że totem, który jest domyślnie zainstalowany jako odtwarzacz filmów wywraca się przy starcie pisząc coś o katalogu mcop (can’t create mcop directory).
To było proste - wystarczyło stworzyć katalog o nazwie maszyny, a dokładniej wydać polecenie:

Niby pomogło, ale totem nadal wywracał się po starcie, sugerując zbyt mało pamięci (BadAlloc (insufficient resources for operation) BadRequest (invalid request code or no such operation)). Okazało się, że ładuje grafikę PNG (splashscreen), która po dekompresji coś mu się nie zgadzała i powodowała wyjątek. Super program swoją drogą, że niemożność załadowania splashscreena to krytyczny wyjątek…
Znowuż trzeba było odwołać się do operacji na plikach - tym razem wystarczyło zmienić rozmiar pliku totem_logo.png w /usr/share/totem na 800×600… lub go skasować. To nie powoduje problemów.

Haha! Teoretycznie już wszystko powinno działać! Niestety, tu na przeszkodzie stanęły dla odmiany sterowniki do chipsetu. Z niewiadomych przyczyn po starcie aplikacji film odtwarza się w miarę ok. Niemniej już drugie włączenie powoduje ostre zniekształcenia kontrastu i jasności - jakby jakieś wartości ustawiały się od razu w położeniach maksymalnych. Tego problemu na razie nie udało mi się zwalczyć

Jeśli używamy SBSa, to łącząc się z jego witryną możemy pod Windows załadować automagiczny programik, który nam sam skonfiguruje połączenie z siecią SBS. Oczywiście to żadna magia, chociaż w widoku połączeń sieciowych pod XP widać, coś co się nazywa magaer połączeń sieciowych. To samo można uzyskać dodając nowe połączenie i zestawiając normalne połączenie VPN.

Skoro można zestawić VPN, to czemu nie zrobić tego spod linuxa? To do roboty.
Po pierwsze instalujemy pakiecik pptp-linux, a następnie przystępujemy do jego banalnej konfiguracji.

1. W /etc/ppp/options.pptp dodajemy linię
   lock noauth nobsdcomp nodeflate

   ,

2. W /etc/ppp/chap-secrets dodajemy domenową nazwę logowania oraz hasło w następującej formie
   domena\\login PPTP hasło *
3. Tworzymy plik /etc/ppp/peers/nazwa_tunelu, w którym wpisujemy:
   pty “pptp serwer –nolaunchpppd”
   name domena\\login
   remotename PPTP
   require-mppe-128
   file /etc/ppp/options.pptp
   ipparam nazwa_tunelu
4. Teraz wystarczy wystartować tunel komendą pon nazwa_tunelu lub też, w celu zwiększenia diagnostyki pon nazwa_tunelu debug dump logfd 2 nodetach

Tunel zamykamy komendą poff. Niestety sam pon konfiguruje tunel, niemniej nie ustawia routingów, nie ustawia serwerów DNS - trzeba się tym zająć na własną rękę. Ponieważ dla mnie skonfigurowany tunel ma się automatycznie podnosić się przy starcie maszyny - wystarczyło do /etc/network/interfaces dodać następujące linijki rozwiązujące problemy trasowania.

Do /etc/if-up.d trzeba dodać mały skrypcik (jak napiszę to zamieszczę) który sprawdza czy interfejs ppp jest podniesiony i jeśli tak, to dodaje do /etc/resolv.conf linijkę zawierającą namiary tegoż nameserwera. Oczywiście w if-down.d trzeba zamieścić regułkę odwrotną, wyjmującą tegoż NSa z listy.

Źródło: PPTP

Mam na dysku laptopa kilka systemów - ze 3 XPki (każdy z innej domeny), Vistę i oczywiśce (last but not least) - Debiana. Miałem tych systemów o dwa więcej - wszystko było ładnie, wszystko było poustawiane. Wstawał boot loader visty z którego wybierałem starszego windowsa , a potem opcja linux i odpalał mi się grub. (Tak - mam 3 boot loadery.) Problem jednak z tym, że ten boot manager po porządkach na dysku zaczął mieć grobowe problemy.

Otóż po wyrzuceniu jednego ze zbędnych systemów na dysku zostało mi nieprzydzielone do niczego miejsce (reserved for future use). Niby żaden problem, ale dla GRUBa jednak jest. Otóż partycje linuxa znajdują się ZA tym wolnym miejscem. Oznacza to, że linux widzi patycję /boot jako /dev/sda9. Problem jest w tym, że dla GRUBa ta sama partycja oznaczana jest jako (hd0,8). No i teraz nie mogę tak ściągnąć boot sectora, żeby automatycznie mi się załadowało boot menu. Jeśli ściągnę tak jak powinienem, z /dev/sda9, to on po załadowaniu się się widzi… 10, czyli /. Jeśli ściągnę z /dev/sda8 - to nic się nie stanie, bo tam jest swap.

Nie mogę w żaden sposób, nie zmieniając kolejności partycji powiedzieć mu jak ma się ładować, nie pisząc ręcznie komend. Oczywiście, wystarczyłoby to wolne miejsce oznaczyć jako partycję i grubowi zacznie się wszystko zgadzać, niemniej to nie jest rozwiązanie na miarę geek’a, nieprawdaż? Any hints?

Dziennik Internautów podał intrygującego newsa, że HP będzie wspierać Debiana na swoich serwerach. Dla mnie to piękna wiadomość, w końcu będzie można pomendzić na infolinii jak coś nie zadziała poprawnie… Szkoda tylko, że FSC nie zdecydowało się na ten krok, wspierając jednak RH i Suse… Ile to czasu zabiera zanim zepsuje inną dystrybucję podobnie do tej, która naprawdę jest produkcyjna, żeby móc uzyskać support

Czasem może zdarzyć się, że ISP blokuje bezpośredni dostęp do portów 25 w sieciach znajdującej się poza jego domeną. Tak akurat dzieje się w lokalizacji gdzie aktualnie się znajduję, co oznacza, że trzeba własny serwer pocztowy przestawić na inny port. Oczywiście nie można go przestawić całkowicie, ponieważ inne serwery pocztowe nie porozumieją się z nami nie mogąc znaleźć punktu wejścia serwera.

Okazuje się jednak, że konfiguracja postfixa jest przygotowana na taką ewentualność. Jeśli mamy w posfixie uruchomiony mechanizm TLS to spokojnie możemy uruchomić postfixa na porcie 465 (smtps). Wystarczy w pliku /etc/postfix/master.cf odhaszować linijkę:

oraz oczywiście dodać regułkę do firewall’a przepuszczającą ruch na wzmiankowanym porcie
Warto zauważyć, że demon czuwający na porcie 465 nie przedstawia się tak ładnie jak ten porcie 25 - od razu wymaga rozpoczęcia negocjacji TLS.

Osięgniemy w ten sposób dwa cele - pierwszy z nich to możliwość wysyłania poczty, drugi - to pewność bezpiecznego skonfigurowania klientów pocztowych, którym oczywiście nakazujemy łączyć się z portem 465 zamiast 25. Pozostaje jeszcze problem dobrego dopasowania certyfikatów, ale to temat na inny art.

Typowy scenariusz - mamy serwerek FTP, oczywiście chrootujemy użytkowników do katalogów domowych. Nagle okazuje się, że jeden z nich musi mieć dostęp do dodatkowych danych, np. utrzymać stronę WWW, którą do tej pory zajmował się inny użytkownik. Symlinki oczywiscie nie wchodzą w grę, ale jest kilka opcji:

• można dać mu kolejny login i hasło, (które zgubi, zapomni), co jest proste dla admina, ale niewygodne dla usera
• można przekopiować dane do jego katalogu, zmienić uprawnienia, zmienić konfigurację apache, co jest trudne, długie, wymaga restartu usługi, no i jak ten user odejdzie, to trzeba operację powtórzyć
• można też zastosować rzecz wygodną i dla admina i dla usera - czyli mount

W zasadzie wydanie komendy

załatwia nam sprawę (jak to jest na czas powyżej średniego uptime maszyny to warto to dodać do /etc/fstab). Proste, czyste, przyjemne

Źródło: MDLog:/sysadmin

Sobota, godziny popołudniowe, szybki look w logi i co widzę? Gdzieś w środku nocy, jakiś dzieciak zza oceanu wybrał sobie jeden z moich serwerków w celu przetestowania swoich narzędzi. Bardzo to niefajne, bo szybkie łącze pozwoliło mu na dosłownie zalanie serwera requestami o autoryzację - do DOSa nie doszło - niemniej jest to trochę wkurzające…

O ile SSH się w miarę łatwo zabezpiecza przed zbyt duża ilością wpisów, to już serwery FTP zabezpieczyć trudniej. Z pomocą przychodzą dwa narzędzia - pierwsze z nich to znane z pakietu *sentry Logsentry, zaś drugie, nad którym się skupię - fail2ban. Obydwa działają tak samo - monitorują logi i na tej zasadzie podejmują odpowiednie działania. Obydwa mają zbliżone zalety i tą samą wadę - regexpy¹. Obydwa używają /etc/deny.hosts lub iptables. Obydwu nie ma w stable

Fail2ban niestety nie znajduje się w stable - jest za to w testing i unstable, więc można go ściągnąć stamtąd lub bezpośrednio ze stron projektu Debian. Z wymogów instalacyjnych trzeba wspomnieć o pythonie i lsb-base, które na szczęście są w stable i to w odpowiednich wersjach. Po instalacji fail2ban od razu rozpoczyna działanie - niemniej dobrego admina to nie zadawala i od razu rusza do /etc/fail2ban.conf, żeby poprawić konfigurację.

Co warto zmienić? Na pewno warto dodać listę adresów, które nie będą blokowane (bo w końcu każdy może wysłać stworzone przez siebie pakiety wskazujące na dowolne IP) - opcja ignoreip. Kolejną opcją, którą warto zmienić, to czas blokady (bantime) - domyślne 10 minut to za mało - warto dać więcej, a mając fizyczny dostęp do maszyny nawet -1 (for ever). Jeśli ktoś lubi, to warto włączyć opcję powiadamiania emailem o zablokowaniu konkretnego IP (jeśli dostajemy wiadomości w stylu in-your-face, to trudniej zapomnieć, że taki niskopoziomowy mechanizm gdzieś tam sobie działa i można szybciej zdiagnozować problem). Pozostaje włączenie odpowiednich demonów, czyli zmiana enabled na true w odpowiednich sekcjach pliku konfiguracyjnego.
Domyślnie skrypt ma wpisane kilka typowych demonów - SSH (włączone domyślnie), SASL, Apache, ApacheAttacks, VSFTPD, PROFTPD, ale bazując na wyrażeniach regularnych¹ można dodać dowolne inne, co jest duuużym plusem. Kolejnym plusem jest przyjemna konfiguracja iptables, którą wykonuje program - tworzy własne łańcuchy opisujące przez jaką regułę dany IP został zablokowany, co pozwala łatwiej przejrzeć logi w razie narzekań userów czy innych adminów.

¹regexpy to mieszane błogosławieństwo - pozwalają na wspaniałe dostosowanie programu pod de facto dowolnego demona, niemniej pozwalają także na przemycenie, przez użycie zbyt szerokiego zakresu wyrażenia, błędów, pozwalających w tym wypadku na DOS maszyny…

Warto poczytać dodatkowo: Debian Administration

Smyrak postanowił odpowiedzieć na mój artykulik. Pozostaje mi dalej rozwodzić się nad tym co jednak Debian ma, a czego może wprost nie widać.

FreeBSD ma jedną fajną dla mnie rzecz - robisz make world, idziesz na dłuższy spacer i masz system zrobiony od zera, ładnie skompilowany na Twoją maszynę. To cudo kopiują pod linuksem developerzy Gentoo - niemniej Debian, choć nie pozwala na aż tak cudowne stwierdzenie ma kilka rzeczy, które może nie tak łatwo zauważyć.

Debian, chociaż jest zasadniczo dystrybucją binarną ma opcje, które pozwalają na własną kompilację pakietów. Ten feature jest nie tylko dostępny, ale wręcz w wypadku pakietów, których licencja nie pozwala na rozprowadzanie ich w formie zmienionej (np. Pine) lub z innych dziwnych powodów. Co jest miłe - rozprowadzanie ich w formie źródłowej pozwala wciąż nie tylko zachować wszelkie zależności, ale także śledzić wszelkie aktualizacje (np. bezpieczeństwa), które są z danym pakietem związane.

Jak do tego dojść? W /etc/apt/apt.conf oprócz linijek zaczynających się od deb są także linijki zaczynające się od src, dzięki którym możemy ściągnąć z repozytorium pakiet źródłowy. Możemy nawet ciut więcej - możemy ściągnąć pakiet źródłowy bez poprawek wprowadzonych przez zespół Debiana, jeśli tylko mamy na to ochotę. Dzięki temu, (wkładając w to oczywiście mnóstwo pracy - pakietów nawet w base jest tona), możemy otrzymać czysty debianowy system kompilowany na swojej maszynie. Możemy także (znów niestety wymaga to trochę pracy) stworzyć dzięki temu własne pakiety!

No i na koniec, żeby post trzymał się tytułu - pliki deb, to podobnie jak w fBSD, archiwa. Nie są to jednak wprost tar.gz, ale archiwa programu ar w których znajdują się pliki: control.tar.gz (zawierający metadane oraz pliki post- i pre- instalacyjne) oraz data.tar.gz (zawierający właściwe pliki programu). Ponadto na stronach projektu można spokojnie ściągnąć wersje źródłowe, pliki różnicowe ze zmianami developerów do wersji vanilla no i same binarki.

Smyru, miłośnik fBSD i użytkownik Linuxa (w wersji Debian derivatives - innych nie toleruje) pytał o możliwość znalezienia listy plików w niezainstalowanym archiwum. Zgodnie z Twoją prośbą (Aziz Light!) - podaję Ci świecę.

Są dwie opcje - pierwsza z nich to wspaniała wyszukiwarka pakietów, która umożliwia wyszukiwanie pakietów, plików i innych takich (prawie jak porty fBSD), druga, to narzędzia apt - jedno z nich wbudowane w pakiet apt, czyli apt-cache, dające możliwosć wszukiwania opisów pakietów, druga, to pakiet też będący w base, nie instalowany domyślnie apt-file, który po zaktualizowaniu (apt-file update) daje możliwość pokazania zawartości archiwum (apt-file list apt-file). Enough light?

Debian project ogłosił dziś, że nowa dystrybucja Debiana - etch (4.0) pojawi się w grudniu. Co w niej będzie ostatecznie zobaczymy w październiku, kiedy będzie ostatni review i najprawdopodbniej zamrożenie stanu testing.

Co pojawi się w nowej wersji Debiana? Jest kilka blokad - oraz celów. Co ciekawe - cele nie muszą być spełnione żeby pojawiła się nowa wersja - blokady muszą (chyba czepiam się aktualnie nazewnictwa…).
Wśród blokad pojawia się przede wszystkim przejście na xorg (w końcu), przejście na gcc 4.x, wsparcie dla architektury amd64, selekcjonowanie dokumentów zgodnie z polityką Debiana, wyrzucenie z jądra firmware’u oraz secure apt (ciekawe czy z zaimplementowanymi plikami delta, pozwalającymi na zmniejszenie ilości danych, które są pobierane z serwerów debiana podczas apt-get update).
Do celów nowej wersji zaliczają się m.in. uwzględnienie standardu Linux Standard Base w wersji 3.1, wsparcie dla SELinuxa, ipv6 oraz NFS v4 - w sumie z tego wszystkiego interesuje mnie ipv6 oraz SELinux, którego trzeba powoli poznawać (dobrze to można zrobić na przykładzie np. Fedory, która ma go zintegrowanego z distro od dawna).

Chociaż to się nasuwa wprost jako dość oczywiste, to jednak nie piszę tu o występach naszej reprezentacji, której śpieszy się do domu tak ewidentnie, że nawet wchodząc na murawę była wciąż w kontakcie z bliskimi by cell phone a potem grała tak, żeby wrócić jak najszybciej w domowe pielesze. Nie chodzi mi tu nawet o naszego Pinokio drużynowego, czyli Rasiaka-Drewniaka. Nie, naprawdę nie piszę tu wcale o tym jak jestem rozczarowany występem naszej reprezentacji i o tym jak ze smutkiem chowałem wczoraj biało-czerwoną…

Otóż kończy się security-support dla najpopularniejszej wersji debiana, z którą wielu żyło przez ostatnie 4 lata - Debian 3.0 Woody. Szkoda oczywiście, że team security ogłasza to raptem z miesięcznym opóźnieniem, chociaż jeśli ktoś na serwerze do tej pory nie przemigrował na Sarge, to pewnie nie ma maszyny na frontendzie a raczej coś schowanego w głebi infrastruktury z aplikacją non-critical, której lepiej nie tykać bo nie ma teamu, który ją tworzył… Tak czy siak, jeśli ktoś nie jest w takiej sytuacji to najwyższy czas zmigrować na nowszą wersję! Najlepiej już na Etch z testingu, jeśli to nie jest system mission-critical

Pomimo tego, że etch pojawić się ma już niedługo, może okazać się, że chcemy zainstalować pakiety w wersji nowszej, niż ta, która znajduje się w aktualnej wersji stabilnej. Żeby zainstalować nowsze pakiety, wystarczy oczywiście dodać nowe źródla pakietów… tyle, że niestety dodanie do źródeł apt całego drzewa pakietów (echo deb http://www.backports.org/debian/ sarge-backports main >> /etc/apt/sources.list), powoduje po apt-get update && apt-get ugrade nagłą próbę wymiany większości pakietów systemowych.

Rozwiązania takiego problemu są trzy. Pierwsze z nich, to dodanie tylko ścieżki, do tego pakietu, który chce się zastosować - co niestety po ostatnim rebuildzie backports spowoduje problem z niespełnieniem zależności gdy pakiet wymaga większej ilości dodatków. Drugie, to dodanie do /etc/apt/preferences linii

a następnie dla każdego pakietu bloków

Trzecim rozwiązaniem, najbardziej uniwersalnym jest ustalenie w preferencjach apt, która z odmian (flavors) jest tą domyślną (echo APT::Default-Release “stable”; >> /etc/apt/apt.conf). Oczywiście najbardziej domyślną jest stable, ale jeśli dodamy do /etc/apt/sources.list linijki zawierające dystrybucję unstable (deb http://{mirror-debiana}/ unstable main) lub testing (deb http://{mirror-debiana}/ testing main) bez tego wpisu, to będące tam nowsze wersje pakietów nadinstalują natychmiast wersje zainstalowane w systemie, co automatyczną aktualizację systemu w zakresie li-tylko poprawek bezpieczeństwa uczyni praktycznie niemożliwą.

Dla pewnoście możemy dodać dodatkowo dla każdej z odmian odpowiedni wpis do /etc/apt/preferences

Po wykonaniu tych czynności uruchomienie apt-get update i aktualizacja repozytoriów pozwoli nam na korzystanie z poszerzonej gamy pakietów. Żeby zainstalować te nowe wersje należy rozszerzyć wywołanie apt o parametr -t odmiana_debiana, np. sarge-backports.
Oczywiście zawsze możemy instalować konkretną wersję pakietu wpisując przy instalacji parametr w postaci nazwa_pakietu=numer_wersji, ale przez to musielibyśmy każdą z zależności instalować osobno.

Dwie uwagi, o których warto pamiętać rozszerzając swoją listę pakietów: pierwsza z nich to rozszerzenie domyślnej wielkości cache /etc/apt/apt.config ‘APT::Cache-Limits [duuża liczba];’, druga, to fakt, że wpisanie repozytoriów wersji testing czy też unstable spowoduje częstą konieczność ściągania wcale nie małych plików zawierających opis repozytoriów, co może być problemem przy wolnym łączu, (no i ponadto po co to robić, jak zazwyczaj z tego nie będziemy więcej korzystać po jednym użyciu? Nie zasyfiajmy zbędnie łączy mirrorów!)

Andreas Barth podał potencjalny termin pojawienia się nowej wersji projektu Debian - Etch. Jeśli wszystko pójdzie zgodnie z zapowiadziami, nowa wersja pojawi się już po 18 miesiącach od wydania poprzedniej wersji 3.1 (obecnie w release 2). Termin w sumie akurat - nie za szybko, żeby wciąż aktualizować systemy, ale i nie za długo, (poprzednio na update z 3.0 na 3.1 czekaliśmy tylko trzy lata, co powodowało konieczność wspierania się backportsami), także technologia się mocno nie zdąży zestarzeć. Co da nam nowa stabilna wersja? Przejście na XFree na xorg, gcc z 3.1 na 4.0, wsparcie dla architektury amd64 no i przejście na obecny od poczatku roku secure-apt.
Cóż - pozostaje nam czekać na nowe, stabilne wydanie, tymczasem testując je na nieprodukcyjnych maszynach

Secunia.com ostrzega przed dziurą w clamav, mogącą doprowadzić do zDOSowania maszyny. Oczywiście debian wydał już poprawkę. Update pakietu mocno zalecany!

System Debian GNU/Linux, (i derywatywy), zaczyna być coraz szerzej dostrzegany i rysować się jako pewien standard systemu linux. Już ostatnie reklamy Microsoft wprost odnoszą się do Debiana, używając reklamy porównawczej, (swoją drogą, czy można ich za to pozwać?). Teraz debian został bardzo poważnie dostrzeżony przez firmę Oracle - na serwerze oss.oracle.com umieściła ona repozytoria dla swojej bazy - oracle express edition. Na razie dla wersji niestabilnej (sid), niemniej to już pozwala na testowanie oracle przez developerów, którzy raczej także korzystają z wersji rozwojowych. Aby skorzystać z rozwiązania wystarczy dodać

do /etc/apt/sources.list i odświeżyć listę pakietów.

Pomimo publikacji rozwiązania w sekcji non-free, ważne jest coraz szersze dostrzeganie przez firmy komercyjne potencjału zawartego w Open Source, a z mojej perspektywy w Debian GNU/Linux. Pozwala to na uzyskanie supportu dla wdrażanych rozwiązań, (a przynajmniej szerszego grona współużytkowników na forum)… oraz poznawanie platform, które na otwartym systemie nie miały jeszcze przyjemności gościć… za free.

Źródło wiadomości: Debian Weekly News @ 7thGuard.net