[Webserver] Consigli su implementazione e uso di Thread con setgid/setuid
Von: daniele dll (d.albano@gmail.com) [Profil]
Datum: 06.02.2008 12:28
Message-ID: <44ef198e-cfc6-4251-b809-d44e55cd3dd6@n20g2000hsh.googlegroups.com>
Newsgroup: it.comp.os.linux.development
Datum: 06.02.2008 12:28
Message-ID: <44ef198e-cfc6-4251-b809-d44e55cd3dd6@n20g2000hsh.googlegroups.com>
Newsgroup: it.comp.os.linux.development
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).
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?)
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])
* 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
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?
(se notate ORRORI di italiano avvisatemi che riposto il testo ... sto
di fretta :))
[ Auf dieses Posting antworten ]Antworten
- Manlio Perillo (06.02.2008 14:08)
- daniele_dll (06.02.2008 14:56)
- Manlio Perillo (06.02.2008 15:26)
- Poster (06.02.2008 14:31)
