Jog Jajcusia

Zaginiona entropia i stary Python musi odejść

02 czerwca 2004 18:02:04 | kategorie: linux, praca, python, pyxmpp,

Wczoraj w firmie przeżyliśmy chwilę grozy. Zaczęło się niewinnie. Nie mogłem commitnąć zmian w systemie zarządzania użytkownikami. svn commit zawisał, strace pokazywało, że na dostępie do /dev/random. Nie było to pilne, więc bardzo się tym nie przejąłem. Potem dzwonił gościu, że poczty nie może odebrać. Chwila śledztwa wykazała, że zacina się na autoryzacji DIGEST-MD5. Od razu skojarzyłem to z problemami z /dev/random. Potem było już tylko gorzej — przy niedziałającym /dev/random posłuszeństwa odmówił też PostgreSQL. A ja ciągle nie wiedziałem co się dzieje. /proc/sys/kernel/random/entropy_avail pokazywało 0 i nie chciało nawet drgnąć. Nie pomogło też wybicie procesów korzystających z /dev/random i /dev/urandom. Wyglądało na to, że coś się zacieło. Ten serwer już długo działał, a jeszcze nie było takich problemów.

Pomyślałem o sprzętowym generatorze liczb losowych — podobno niektóre płyty takie coś mają. find /lib/modules -name "*rng*" pokazało dwa moduły. Jeden (amd768_rng) miał nazwę podobną do chipsetu płyty. Załadowałem i nawet działa — cat /dev/misc/amd768_rng pokazywało krzaczki. Jednak aplikacje odwoływały się do /dev/random, a tam dalej bez zmian. Spróbowałem ln -s /dev/misc/amd768_rng /dev/random — Permission denied, mv /dev/random /dev/random.orig — to samo. Cholerny devfs - próbuje być mądrzejszy ode mnie! Zawsze lubiłem ideę devfs — w /dev/ jest tylko to co mam w komputerze, a dysk o konkretnym SCSI-id podłączony do konkretnego kontrolera ma zawsze tę samą nazwę, a nie zależną od tego co jeszcze jest podłączone. Jednak implementacja jest fatalne, a ten przypadek przeważył — devfs wyleciał z tego serwera. I tak robiliśmy reboot, bo innych pomysłów nie było.

Po reboocie okazało się, że /dev/amd768_rng nie jest całkiem zgodny z /dev/random — po podlinkowaniu niektóre aplikacje (w szczególności SVN) zawisały przy próbie korzystania z tegoż. Jednak /proc/sys/kernel/random/entropy_avail było już większe od zera, więc problem chwilowo zniknął. Jednak nie na długo — entropy_avail zaczęło się zmniejszać i znowu doszło do zera blokując wiele usług. Zamiany /dev/random na /dev/urandom nie brałem pod uwagę - po to używam SSL, SASL itp. żeby było bezpiecznie, a /dev/urandom bez entropii generuje liczby bardzo pseudolosowe, a więc do kryptografii niespecjalnie się nadające. Na szczęście kumpel znalazł winowajcę — iptables -m random. Jedna taka regułka była w naszym firewallu i po podłączeniu któregoś klienta najwyraźniej zabrakło na nią entropii. Po zamianie tego na coś innego entropy_avail urosło do sensownej wartości i wszystko zaczęło znowu działać. Ufff...

W PyXMPP i CJC obsługa MUC zaczyna działać. Można już wejść na takiego czata i pogadać. Ale pierwszym felerem, który się rzuca w oczy, są niewłaściwe czasy przy wiadomościach z historii pokoju. Jest tam czas aktualny, zamiast tego podanego w <x xmlns="jabber:x:delay"/>. JEP-91 jest banalnie prosty, więc postanowiłem go od razu zaimplementować. Oczywiste było, że przydałby się typ opisujący czas, którego w Pythonie zawsze brakowało. Zwykle używałem mx.Datetime, ale nie chciałem dla takiej dupereli do PyXMPP dodawać kolejnej zależności. Więc użyłem modułu time, ale on jest do bani. Można pobrać aktualny czas, przedstawić ją w postaci UTC, czy czasu lokalnego, czy skonwertować tekst o znanym formacie na czas — ale tylko w czasie lokalnym. Na zamianę czasu UTC w postaci tekstowej na czas lokalny nie znalazłem sposobu. Poczytałem dokumentację — z niej wynikało że %Z w formacie dla time.strptime czasem może działać — u mnie nie działa. Pogooglałem i okazało się że moje wiadomości na temat braku typu dla czasu są nieaktualne. W Pythonie 2.3 jest moduł datetime, który daje wszystko co potrzebuję wraz z sensownym interfejsem. Dotychczas jednak PyXMPP działało także na pythonie 2.2.x. Chyba przestanie — już dawno zastanawiałem się nad porzuceniem wsparcia dla Pythona 2.2 — chociażby dlatego, że nie ma w nim obsługi stringprep, czy IDN (oba standardy wymagane przez XMPP). Teraz PyXMPP zawiera moją własną implementację stringprep dla Pythona 2.2 (wraz z wymaganą przez nią normalizacją Unicode — to było sporo roboty), a IDN po prostu nie są obsługiwane gdy używany jest Python 2.2 (użycie znaku nie-ASCII w domenie JID powoduje bład). Ciekawe dla ilu użytkowników takie podniesienie wymagań będzie dużym kłopotem. A może w ogóle się tym nie przejmować? W końcu już teraz użytkownicy Debiana muszą kombinować, żeby z PyXMPP skorzystać, bo standardowo mają historyczne wersje Pythona i libxml2. Chyba jednak wywalę obsługę pythona 2.2 — kodowi wyjdzie to tylko na dobre.