• Als Spam markieren
• Beitrag melden

• 
  Diese Gruppe Alles

• Archiv
• RSS-Feeds

• Kontakt
• Hilfe
• Impressum
• Datenschutz

Re: [Webserver] Consigli su implementazione e uso di Thread con setgid/setuid

Il Wed, 06 Feb 2008 03:28:58 -0800, daniele_dll ha scritto:

> Salve a tutti,
>
> è il mio primo post qui:)
>
> Sto sviluppando un piccolo webserver da usare in sostituzione di Apache
> sul mio server, questo perché ho la necessità di avere i
vari virtual
> host agganciati a specifiche limitazioni (principalmente eseguiti con
> uno specifico user/group)
>
> Attualmente uso l'mpm itk di apache che funziona abbastanza bene ma è
> tremendamente pesante!
>
> Ho già iniziato lo sviluppo del webserver, ho buttato le basi, ovvero
> parsing del parametri, switching dell'utente sul processo principale,
> sganciamento dalla sessione e caricamento file di configurazione (ancora
> il parsing del file xml non l'ho implementato).
>


Dai una occhiata ad nginx.
Il codice è abbastanza complesso, ma è scritto bene.

nginx è asincrono comunque, non so se ti vada bene (dipende da cosa devi
servire).



> Ho letto sul documento della redhat riguardante l'implementazione dei
> thread che uno dei problemi che la NPTL doveva "risolvere" era lo switch
> utente sull'intero processo quando si usava setuid e setgid e questa
> cosa per me sarebbe una mezza tragedia ... potrei aggirare la cosa ma è
> gran casino!!!
>
> Volevo chiedervi quindi se effettivamente setuid e setgid cambiano
> queste informazioni solo per il thread cui vengono eseguiti o
> retroattivamente li cambiano per tutti i thread di quel processo (non di
> altri fork comunque, no?)
>

http://www.opengroup.org/onlinepubs/000095399/functions/setuid.html

If the process has appropriate privileges, setuid() shall set the real
user ID, effective user ID, and the saved set-user-ID of the calling
process to uid.


> Questo per me è necessario perché il server
funzionerà cosi (almeno
> nella mia testa):
> * Parte il server
> * Analizza la configurazione (Legge i paramertri di default, legge le
> tipologie di connessione con relativa configurazione, legge le socket da
> bindare legate al tipo di connessione da gestire [http, pop3, imap e
> cosi via {per adesso l'unico gestore sarà http}], legge la
> configurazione dei moduli legati al tipo di connessione, legge la
> configurazione degli esecutori delle richieste [ergo utenti/gruppi,
> limitazioni di banda/traffico, limitazioni su numero di richieste e
> altri parametri ancora, moduli da abilitare])


Ma questi esecutori devono eseguire codice "custom" o semplicemente
servono dei file statici?



> * Avvia N thread in base
> al numero di esecutori delle richieste (sono questi i thread che leggono
> dal disco)
> * Avvia M thread per i gestori del tipo della connessione (2
> smtp, un pop3, un imap e un http per esempio) a cui passa l'elenco delle
> pipe inizializzate dai thread per comunicare in base ad i legami
> definiti nella configurazione che poi switchano sull'utente/gruppo usato
> dal server
> * Avvia L thread in base al numero di socket da bindare (la 25, la 26
> per l'smpt, la 110 per l'imap, la 143 per l'imap e cosi via) e passa, in
> base ad i legami definiti nella configurazione, l'elenco delle pipe
> avviate dai gestori per la comunicazione e poi i thread switchano
> sull'utente/gruppo usato dal server
> * Switcha l'utente del fork principale per gestire i segnali
>

Non vedo la necessità di tutti questi thread, a parte per IO su disco
(almeno fino a quando non sarà disponibile una implementazione decente di
POSIX AIO).


> Alternativamente invece che avviare N thread dovrei avviare N fork ...
> ovviamente per gestire l'esecuzione asincrona finale andrei comunque ad
> usare dei thread: appena mi arriva una richiesta alla socket questa
> avvia un thread, accetta la connessione e si mette in comunicazione con
> il gestore facendo da ponte [nel caso di connessioni crittografate prima
> decritta] ... il gestore riceve la richiesta di una nuova connessione
> quindi apre un thread, gli passa la pipe e fa analizzare al thread gli
> header della connessione che a sua volta decide a quale esecutore deve
> passare il tutto e si mette in comunicazione su una pipe per far
> startare l'esecutore ad hoc al thread/fork specializzato.
>
> Lo so, è un processo un po incasinato, però credo sia
l'unico modo
> flessibile per gestire la cosa ... o è una cosa assurda?
>

I thread non vengono gratis, rischi di far esplodere il server in caso di
un alto numero di richieste concorrenti.

> (se notate ORRORI di italiano avvisatemi che riposto il testo ... sto di
> fretta :))




Saluti   Manlio Perillo

Antworten