Skip to content

SLT ( Săptămâna de lucru la TFM ) Partea 2

  • by

sigla tfm
Saptamina care tocmai a trecut se poate numi saptamina re-impachetarilor. Foarte multe pachete au trecut prin procesul de reimpachetare. De ce ?

TFM2 avea in installer notiunea de template. Si am pus noi in tfm citeva profile care se mulau destul de bine la momentul respectiv pe nevoi. Numai ca nimeni nu a mai updatat acele profile de atunci. Intre timp pachetele au alte denumiri , majoritatea instalarilor s-au facut full si nu s-a tinut seama ca mai exista profile si mai mult ca profilele nu mai merg. Pina saptamina asta cind am incercat sa fac un sistem minimal pentru un mail exchanger care sa ruleze via uml.

Saptatul la UML a fost o a doua directie de sapaturi saptamina asta. Dar despre uml vorbim in SLT de saptamina viitoare

Prin metoda while ( fail ) do { fail = try() } am string intr-un director pachetele care mi se parea mie ca sint necesare pentru qmail si am incercat sa le instalez intr-o imagine montata in loop.

Metoda de instalare cu un fisier montat in loop este mult mai rapida decit sa instalatul intr-un director normal. De ce ? Pentru ca la o a doua instalare va trebui sa stergeti continutul directorului si umount / mkfs.ext3 / mount merge infinit mai repede decit rm -rf

Dupa ce am reusit sa string pachetele care depind unele de altele ( operatiunea micul chinez pe plantatie ) studiind rezultatul am constat ca o gramada de spatiu se pierdea cu documentatii, manuale si altele. Am hotarit sa refac rpm-urile care contineau documentatii si sa le mut in subpackete de sine statatoare. singurul “drawback” al actiunii ar fi ca sint mai multe pachete in tfm. Multe dar mai mici.

Si de aici toata distractia cu reimpachetatul. perl , cpio , udev , module-init-tools , pam sint doar citeva din ele. Operatiunea de reimpachetare va mai dura o perioada de vreme urmind a fi finalizata in tfm 3.1 probabil. In alte pachete executabilele aveau informatiile de debug asa ca au necesitat strip.

Si pentru ca mi-am adus aminte ca nu am avut timp sa povestesc aventurile cu kernelul si pptp o sa o fac in continuare.

A trebuit testat integrarea pptp in ADS. Moment in care au aparut problemele.
Serverul se manifesta ciudat. Este prima data cind vad erori de genul asta in linux. Pentru ceva timp am avut senzatia ca in loc de server linux e un windows instalat prost. Iara cum se manifesta:

  • Anumiti utilizatori se puteau conecta in vreme ce altii nu. userii si parolele fiind corecte
  • Orice conexiune murea in conditiile in care se facea trafic ceva mai mare. In principiu dupa circa 10 secunde la conectare nu se mai trafica nimic . Nici o eroare , absolut nimic.Dupa sapaturi care mi-au taiat orice fel de chef am descoperit erorile:
  • Braindeads punks care intretin ppp-ul au considerat ca e mai interesant sa refaca ei base64_encode si la orice utilizator de 4 caractere functia intorcea valori aiurea. Prin urmare utilizatorii de 4 litere nu se puteau loga.
  • In kernelul 2.6.15 au schimbat codul care gestioneaza terminalele (n_tty.c). Explicatia tehnica data de Paul Mackerras:
    What happens is that when pptp reads from the pty, we call
    read_chan() in drivers/char/n_tty.c on the master side of
    the pty. That copies all the characters out of its buffer
    to userspace and then calls check_unthrottle(), which
    calls the pty unthrottle routine, which calls tty_wakeup
    on the slave side, which calls ppp_asynctty_wakeup,
    which calls tasklet_schedule. So far so good. Since we are
    in process context, the tasklet runs immediately and calls
    ppp_async_process(), which calls ppp_async_push, which calls
    the tty->driver->write function to send some more output.
    
    However, tty->driver->write() returns zero, because the master
    tty->receive_room is still zero. We haven't returned from
    check_unthrottle() yet, and read_chan() only updates
    tty->receive_room_after_ calling check_unthrottle. That means
    that the driver->writecall in ppp_async_process() returns 0.
    That would be fine if we were going to get a subsequent
    wakeup call, but we aren't (we just had it, and the buffer
    is now empty).

    Bugurile au fost gasite simultam si au fost suprapuse ca si aparitie… Va puteti imagina cit stress a fost pina s-au rezolvat. Partea de kernel / ppp / pptp trebuia sa fie intr-un SLT separat dar nu am avut timp sa scriu postul.