Deszcze nispokojne potargały sad, a my na tej wojnie ładnych parę lat. PLD robimy, nigdy nie skończymy….
PLD Traffic #9
No niestety. Załoga LinuxNews mocno zajęta i traffica nie mieli kiedy umieścić. Może w przyszłości. Ja nadal xslt nie lubię, a ponieważ zajęty jestem mocno to w tym numerze odnośników nie ma nadal. Tyle spraw technicznych. A co w tym tygodniu? Masakra.
Cotygodniowe statystyki:
77 Tomasz Kłoczko <kloczek@rudy.mif.pg.gda.pl>
37 Jakub Bogusz <qboosh@pld.org.pl>
27 Michal Moskal <malekith@pld.org.pl>
24 Marcin Bohosiewicz <marcus@kernel.pl>
23 Arkadiusz Miskiewicz <misiek@pld.ORG.PL>
22 Michał Margula <alchemyx@uznam.net.pl>
21 Tomasz Pala <gotar@poczta.onet.pl>
20 Paweł Gołaszewski <blues@ds6.pg.gda.pl>
18 Mariusz Mazur <mariusz@isn.pl>
16 wrobell <wrobell@ite.pl>
1. Problemy z instalacją
W wiadomości "Dzisiejsze ISO znowu zjebane" Michał Kochanowicz napisał:
"Chyba mnie coś trafi.
Dzisiejszy ISO się nie bootuje.
Po zbootowaniu go za pomocą dyskietki utworzonej z bootdisk_ide.img z tegoż ISO instalacja kończy się tak:
Ładuję poldek-pkg
cp: /src//.poldekrc: No such file or directory
Something went bad.
To już trzeci ISO ściągnięty w ciągu 24h. Ściągnięcie każdego trwa ~4h. Żeby go wypalić muszę komuś wleźć w dupę. Bez wazeliny. Czy naprawdę nie istnieje możliwość sprawdzenia tego CD przed wrzuceniem na FTP? Wykonanie instalacji BASE to góra pięć minut."
W trakcie dyskusji jaka nastąpiła ustalono, że przed wystawieniem obrazów na ftp należy je u kogoś przestestować. Kilka dni później Michał napisał kolejny list ("Kolejny *zjebany* ISO"):
"To już kurwa nie jest zabawne.
(…)
!!! INSTALACJA PAKIETÓW NIE POWIODŁA SIĘ
To już kurwa 4 ściągnięty ISO który nie działa. A jeszcze, kurwa, przez to że na niego czekałem spóźnię się w parę miejsc. A jeszcze będę musiał świecić oczami przed kolegą, którego namówiłem na instalację PLD i od tygodnia nie jestem w stanie dostarczyć mu działającej instalacji.
Jeśli dobrze rozumiem właścielem maszyny ftp.pld.org.pl jest Marcin. Więc niniejszym, zgodnie z panującą ostatnio modą, zwracam się do ciebie z prośbą o zabranie dostępu do tej maszyny osobie, która udostępniła bez sprawdzenia kolejne już *niedziałające* ISO."
Marcin Bohosiewicz odpowiedział:
"Osoba ta zostala pouczona, zeby nowe ISO wystawiac w "test" i przenosic na wlasciwe miejsce dopiero po sprawdzeniu przez kilka osob ze ISO sa dobre. Z tego co wiem przyczyna tego, ze obecne ISO byly uszkodzone byl blad Arka, ktory nie sprawdzil ze sed mu w jednym skrypcie zamienil o jeden string za duzo… i blad poszedl dalej.
Przypominam, ze metodologia publikowania ISO zostala wypracowana, gdy nie milismy 36GB dysku na ftpa i PLD cierpialo na chroniczny brak miejsca. Teraz, gdy miejsca jest pod dostatkiem, nalezy wprowadzic rowniez w images podkatalog test i testowanie ISO przed skasowaniem poprzedniego.
Do Tomka: zrob to, czy ja mam katalogi test pozakladac?
Do malekitha: sprobuj zrobic cos takiego, zeby tego typu bledy nie mogly sie powtorzyc.
M.
PS. ja tez swiece oczami przed klientem ktory chcial sobie w domu Linuxa zainstalowac i mu polecilem PLD. Skonczy sie na wycieczce przez pol Polski, zebym mu tradycyjnym cp -av wreszcie to PLD zainstalowal."
Michał Moskal (malekith) odpowiedział, że "jak będzie mrożonka i nic się nie będzie tam ruszać to się nie będą [błędy] zdarzać".
2. Poldek i jego bajery
W wiadomości "svgalib i kernel(-smp)" Radosław Kintzi zapytał "Dlaczego svgalib wymaga kernel-smp". Jace Konieczny odpowiedział mu:
"Odpal poldka (oczywiście odpowiednio nowego) z opcją –ask, to da ci wybór. Teraz wybrał za ciebie które drivery svgalib zainstalować :-)"
3. Czasy ftp
W wiadomości "ftp.pld.org.pl i GMT" Adam Gorzkiewicz zapytał:
"Czy ftp.pld.org.pl pokazuje zasoby z czasem GMT czy czsem lokalnym? Potrzebne mi to do prawidłowej konfiguracji mirrora."
Marcin Bohosiewicz odpowiedział mu:
"FTP zawsze pokazuje GMT. A przynajmniej powinno i ftp.pld.org.pl tak robi. Dlaczego? Bo protokol FTP nie przewiduje przekazania w naglowkach informacji z jakiej strefy czasowej klient sie laczy, wiec dla zachowania jednoznacznosci wybrano czas uniwersalny."
4. Problemy z egrepem
W wiadomości "Memleak w grepie?" Michał Margula napisał:
"Mam taki oto skrytp, sklecony na poczekaniu. Pewnie można to zrobić lepiej np przepuszczając całość przez perla czy cokolwiek, ale chwilowo zastanawia mnie jedna ważna rzecz. egrep po kilkunastu godzinach puchnie do olbrzymich rozmiarów (rekord 600 mega). Czy to normalne? Czy to jakiś wyciek?
Skrypt wygląda tak:
#/bin/sh
TCPDUMP_OPT="-i any -n dst net 192.168.0.0/16 or dst net 217.97.213.0/24 or dst net 213.25.9.0/24" tcpdump $TCPDUMP_OPT | awk '{ print $4 }’ | tr -d ":" | egrep "[0-9]+.[0-9]+.[0-9]+.[0-9]+.6[0-9]{4}" | cut -d "." -f 1-4"
Arkadiusz Patyk odpowiedział:
"Potwierdzam.
Z naszym grepem jest cos nie tak – juz kiedys – pare miesiecy temu wspominalem o tym. Praktycznie nie da sie grepowac b. duzych plikow – wpierdziala cala pamiec i kapota."
Michał spytał się "jak się szuka memleaków" na co Paweł Kołodziej odpowiedział, że "ccmalloc jest do tego bardzo fajne".
5. Quota i z nią problemy
W wiadomości "dziwny problem z quotą" Andrzej Dopierała napisał:
"Hej. piszę tutaj a nie na users ponieważ problem musi leżeć gdzieś w pld i niemal wykluczam aby występował on z mojej winy.
Zauważyłem go na dwóch systemach:
i586 – postawiony jakiś czas temu na jajku 2.4.7, regularnie upgradowany
i686 – świeża instalacja na jajku 2.2.20
oba systemy mają dysku scsi. Problem polega na tym że edquota user nie zmienia żadnych ustawień – zapisuje je, ale po ponownym wczytaniu ustawienia nie są zmienione. Wykluczam tutaj błąd z mojej strony ponieważ na i586 quota od początku była ustawiona i nie było z nią żadnych problemów. Teraz jednak edquota nie "zapisuje" zmian nawet wśród tych użytkowników gdzie quota była kiedys ustawiona. Nic od czasu instalacji w konfiuracji quoty ani filesystemów nie było także zmieniane. strace(o ile dobrze je interpretuję) pokazuje że ustawienia są poprawnie przesyłane do quoty przez quotactl, natomiast kolejny odczyt jest juz niepraidłowy.
Znalazłem jednak dziwaczne obejście całego problemu. Otóż:
EDITOR=nano edquota user
działa. To znaczy zapisana w nano(pico…) konfiguracja jest zachowywana na dysku. EDITOR=vi/vim zmian tych nie zapisuje. Jeżeli ktoś byłby w stanie mi pomóc i wyjaśnić cały problem chętnie udostępnię logi strace/ltrace."
Jakub Bogusz odpowiedział:
"Pewnie to samo co z crontabem… sprawdź po:
:set nobackup nowritebackup
vim przy zapisywaniu kopii zapasowej robi rename i write, a nie kopiuje i zapisuje do pierwotnego pliku (swoją drogą, jeżeli plik jest w /tmp lub podobnym katalogu, może być to niebezpieczne). edquota widocznie także nie zamyka pliku przed uruchomieniem edytora."
Później nastąpiła krótka dyskusja o tym, które pakiety należy poprawić i jak.
6. Nowy bóg
W wiadomości "administrativia: bekap PLD cvs admin" Tomasz Kłoczko napisał:
"Zapomniałem powiadomić.
W razie gdybym nie był jakoś osiągalny wszelkie operacje administracyjne w CVS od przedwczoraj jest w stanie wykonać Artur Frysiak (wiget)."
Nie było odpowiedzi.
7. Wielka burda (a właściwie wielki burdel)
Dla utrzymania kondycji należy co kilka tygodni rozpętać wojenkę. To wie każdy developer PLD. Ponieważ obecna wojenka była dosyć duża i brzemienna w skutkach (jej echa przedostały się nawet na 7thguard) dlatego zależy niżej podpisanemu na jak największej obiektywności. Zmuszony przez okoliczności, w trosce o niewinnych, blah blah blah.
W skrócie. Za dwa lub trzy dni należy się spodziewać specjalnej edycji traffica poświęconej tylko i wyłącznie obecnej sytuacji. So stay tuned.
Archiwalny news dodany przez użytkownika: mmazur.
Kliknij tutaj by zobaczyć archiwalne komentarze.