D1. Ho creato sendmail.init e syslogd.init. Li ho messi in /usr/local/bin e ho cercato di eseguirli, ma ottengo degli errori.
R1. Questi file sono chiamati `init script'. Sono eseguiti dal programma init nella fase di inizializzazione del sistema. Non c'entrano con i file binari di /usr/local. Consulta la `Linux System Administrators Guide' o la `Linux Getting Started Guide' [anche in italiano su Guide LDP tradotte N.d.T.] per informazioni sull'uso degli `init script'.
D2. Ho messo queste linee in /etc/sendmail.cf
divert(0) VERSIONID(`tcpproto.mc') OSTYPE(linux) FEATURE(redirect) FEATURE(always_add_domain) FEATURE(use_cw_file) FEATURE(local_procmail) MAILER(local) MAILER(smtp)
E ho ricevuto degli strani messaggi di output. Perché?
R2. Non devi mettere queste linee direttamente in /etc/sendmail.cf. Il file sendmail.cf è stato ideato per essere di facile comprensione per sendmail e di difficile lettura per gli umani. Dunque per facilitare la configurazione noi umani usiamo un programma chiamato m4 e le sue capacità di gestione tramite macro per creare il file sendmail.cf. Le linee che iniziano con FEATURE sono in effetti delle macro che devono essere espanse in istruzioni di configurazione di sendmail. Esamina la documentazione su sendmail per capire come configurare sendmail con questo metodo. Nota inoltre che così creerai un file di configurazione principale /etc/sendmail.cf, file che lo script virtfs poi copierà in /virtual/domain1.com/etc/sendmail.cf. Quindi devi modificare il sendmail.cf della directory /virtual affinché sendmail risponda in modo appropriato.
D3. Dove trovo virtuald, che cos'è e come lo devo usare?
R3. Virtuald è un programma da me scritto per eseguire un
servizio virtuale. L'ho incluso come codice sorgente in linguaggio C in
questo HOWTO. Lo puoi compilare come un normale programma in C con
make virtuald. Il file binario risultante viene installato in
/usr/local/bin. Aggiungendo delle apposite linee in /etc/inetd.conf potrai
usarlo come `wrapper' per un normale programma server di rete.
D4. E se non ho dialog installato sul mio sistema?
R4. Dialog è un programma che permette di utilizzare finestre di dialogo a scomparsa (`dialog pop-up window') negli script di shell. È richiesto per il funzionamento degli script di shell di esempio che si trovano in questo HOWTO. Puoi ottenere una copia di dialog presso sunsite. È di facile compilazione e installazione.
D5. Come posso sapere se il syslogd virtuale funziona?
R5. Quando virtuald parte dovrebbe inviare i seguenti messaggi a syslogd (/var/log/messages):
Nov 19 17:21:07 virtual virtuald[10223]: Virtuald Starting: $Revision: 1.49 $ Nov 19 17:21:07 virtual virtuald[10223]: Incoming ip: 204.249.11.136 Nov 19 17:21:07 virtual virtuald[10223]: Chroot dir: /virtual/domain1.com
Il messaggio circa la directory su cui viene fatto chroot è
inviato da virtuald dopo l'esecuzione della chiamata di funzione
chroot. Se appare questo messaggio, il syslogd virtuale funziona.
Se si possono vedere i messaggi che il servizio che si sta rendendo virtuale
passa a syslogd, anche questo è un segno che il syslogd virtuale
è configurato correttamente.
Nota che se non è stata attivata l'opzione di compilazione VERBOSELOG virtuald non passerà nessun messaggio a syslogd. In questo caso si può dire che il syslogd virtuale funziona correttamente se il programma demone che si sta rendendo virtuale riesce di suo a passare qualche messaggio a syslogd.
D6. Come posso configurare le quote disco tenendo conto dei vari filesystem virtuali?
R6. Puoi configurare le quote disco come faresti normalmente. Puoi consultare il Quota mini-HOWTO. Comunque devi essere sicuro che non ci siano conflitti di uid tra i vari domini. Se ci sono conflitti avrai più utenti che condividranno una stessa quota. Tieni da parte un intervallo di uid riservati agli utenti che avranno la quota disco abilitata e fa in modo che i tuoi domini non abbiano altri utenti in tale intervallo tranne quelli registrati per avere una quota disco.
D7. Che cosa sono i '\' nelle voci di inetd.conf?
R7. È solo un metodo per spezzare su più righe una singola linea di configurazione. L'ho usato in modo da suddividere a piacere la riga. Puoi ignorare il '\' e riunire nuovamente le due righe insieme.
D8. Quando lancio passwd o altri programmi di login ricevo un
permission denied. Quando lancio FTP o `su' ricevo un
no modules loaded for service XXX. Perché?
R8. Sono messaggi di errore di PAM. Ho ideato questi script prima che uscisse PAM. Il mio script virtfs non copia /etc/pam.d, /usr/lib/cracklib_dict.*, /lib/security e nessun altro dei file richiesti per il corretto funzionamento di PAM. Modificando lo script virtfs in modo da copiare anche questi file il problema si risolverà.
D9. Virtuald può lavorare assieme ai file di tcpd: hosts.allow e hosts.deny?
R9. Sì, con opportune modifiche lo può fare.
Per prima cosa il sorgente dev'essere modificato in due punti.
Dev'essere inserito quanto segue nel punto in cui gli argomenti vengono controllati.
if (!argv[3])
{
syslog(LOG_ERR,"invalid arguments: no program to run");
exit(0);
}
La linea `exec' dev'essere cambiata da:
if (execvp(argv[2],argv+2)<0)
in:
if (execvp(argv[2],argv+3)<0)
Come secondo passo le linee di inetd.conf devono essere modificate da:
ftp stream tcp nowait root /usr/local/bin/virtuald \
virtuald /virtual/conf.ftp wu.ftpd -l -a
in:
ftp stream tcp nowait root /usr/local/bin/virtuald \
virtuald /virtual/conf.ftp tcpd wu.ftpd -l -a
Come terzo passo modifica in modo appropriato i file /virtual/domain1.com/etc/hosts.allow e /virtual/domain1.com/etc/hosts.deny.
D10. I miei host virtuali possono eseguire script CGI?
R10. Sì, lo possono fare, ma ti raccomando di mettere i
/cgi-bin in un posto non accessibile dopo il chroot, al quale
abbia accesso solo tu. Ad esempio /var/www/cgi-bin/domain1.com. Permettere
ai client l'accesso a /cgi-bin significa dare loro la possibilità di
eseguire programmi sul tuo server. Ciò costituirebbe un grosso
problema di sicurezza. Fa' attenzione. Personalmente non lascio eseguire
nessun cgi sui miei sistemi se non dopo aver controllato di persona
l'assenza di bug.
D11. I miei file di configurazione sono diversi dagli esempi riportati. Che devo fare?
R11. Ci sono due stili fondamentali di configurazione: SystemV e BSD. Gli esempi riportati in questo HOWTO sono basati sui file di configurazione nello stile SystemV. I servizi virtuali funzionano ugualmente bene in entrambi i sistemi. Per informazioni sui file di configurazione stile BSD consulta le fonti della tua distribuzione o il più vicino sito LDP.
D12. Ti ho scritto una e-mail e non ho ricevuto alcuna risposta o c'è voluto molto tempo per averla. Perché?
R12. Probabilmente perché non hai messo VIRTSERVICES HOWTO nel soggetto del messaggio. Ti prego di tenere a mente che sono un amministratore di reti e che, tra le altre cose che faccio nelle mie giornate sempre troppo brevi [``in my 20 hour days'' nell'originale N.d.T.], mi prendo cura dei box virtuali miei e dei miei clienti. I messaggi correttamente indirizzati trovano sempre risposta in due o tre giorni. I messaggi che invece non contengono il soggetto di cui sopra non vengono depositati nella mia casella VIRTSERVICES e possono non ricevere alcuna attenzione per giorni o anche settimane.
D13. Virtuald funziona su connessioni sotto i 100Mbit?
R13 La velocità della scheda di rete non è correlata al funzionamento di virtuald. Prova ad assicurarti che il tuo server lavori sotto i 10 Mbit e che la tua scheda di rete a 100 Mbit funzioni normalmente in assenza di un server virtuale.
D14. Dovrei usare la tabella virthost di sendmail?
R14. No. Quella è una funzionalità di sendmail che
gli permette di ricevere informazioni per la gestione di domini multipli.
Virtuald fornisce ad ogni sendmail il suo proprio ambiente, separato dagli
altri tramite chroot. Installa virtuald e poi configura sendmail
come faresti normalmente per ogni singolo dominio.
D15. Posso configurare un telnet virtuale sulla mia macchina? Che ne pensi della creazione di un account di root virtuale che permetta ai clienti di amministrare i propri domini?
R15. Questo genere di domande mi vengono fatte piuttosto spesso e, per essere onesti, mi stanno un po' stufando. La risposta, come espresso già parecchie volte nella documentazione, è che qualsiasi servizio eseguito attraverso inetd può essere reso virtuale usando lo script virtuald, quindi non c'è nulla che impedisca di farlo. Nulla eccetto il buon senso. Qualunque beneficio possa derivare dal permettere il telnet è ampiamente superato dai costi in termini di sicurezza per il box virtuale e di conseguenza per i siti, che si suppone debbano essere gestiti in modo responsabile. Di seguito cito solo alcuni dei punti in discussione:
chroot, può spegnere il sistema, e può
uccidere altri processi in esecuzione.L'idea di fondo è che permettere il login su un box virtuale è una pessima cosa. Ove lo si permettesse, ogni sito ospitato sulla macchina sarebbe a rischio. Se si desidera permettere al titolare di un sito di amministrare da sè i propri utenti allora raccomando di scrivere il codice (non si tratta di script) necessario a lanciare i processi virtuali che permetteranno di aggiungere, eliminare o modificare gli account degli utenti su un collegamento in ssh. Dovrebbe essere completamente guidato da menu, non dovrebbe permettere l'accesso ad una console e non dovrebbe girare con i permessi di root. Per ottenere ciò si dovà cambiare il proprietario dei file opportuni da root a qualche altro utente. Se fatto in questo modo, sarà forse abbastanza sicuro da poter essere usato su una macchina virtuale. Non è mai il caso di permettere il collegamento sulla macchina come root, sia in telnet che in ssh. Permetterlo vuol dire semplicemente che si stanno cercando dei guai. Se c'è una ragione schiacciante per dover far girare telnet, allora il sito dovrebbe essere ospitato su una macchina a parte, così da limitare il rischio a quella macchina. Nessun amministratore responsabile dovrebbe fare altrimenti, quindi non spenderò altro tempo sull'argomento.
D16. C'è da qualche parte un file rpm o tar, un sito web, una lista di discussione ecc. che si occupi di virtuald e del Virtual-Services HOWTO?
R16. Attualmente non è disponibile nulla del genere. Questo HOWTO è la sola fonte di informazione per quanto riguarda questo progetto. Trovo che questo HOWTO sia abbastanza autonomo da rendere superflue altre fonti di informazioni più frammentarie.
D17. Quando lancio virtexec come utente normale ricevo il
messaggio chroot: operation not permitted. Perché?
R17. Chroot è una chiamata di sistema ristretta
ai privilegi di root. Solo il superutente può eseguirla. Lo script
virtexec lancia il programma chroot, per cui è necessario
essere root per eseguirlo con successo.
D18. Ho configurato pop e sendmail ma il prelievo della posta a mezzo pop non sembra funzionare. Che succede?
R18. Alcuni programmi che gestiscono il servizio pop usano /usr/spool/mail come directory per i file di posta. So ad esempio che qpop dev'essere modificato a livello sorgente per risolvere il problema. Quindi ricompila il sorgente opportunamente modificato o collega con un link simbolico /virtual/domain1.com/usr/spool a /virtual/domain1.com/var/spool.
D19. Non ho usato il programma citato nel tuo HOWTO. Ho usato il programma XXX. Non funziona. Perché?
R19. Nei miei esempi ho cercato di fare in modo di usare i più generici e diffusi tra i vari server a disposizione. Ad ogni modo mi rendo conto che ognuno ha il suo programma preferito. Cerca di inviarmi quante più informazioni utili è possibile. Proverò ad immaginare una soluzione al tuo problema e la riporterò in questa FAQ. L'informazione più importante da inviarmi è dove trovare la versione del software che stai usando (nella forma ftp://ftp.domain1.com/subdir/subdir/file.tgz).
D20. Quando lancio virtexec mi dice: Il link simbolico non è a
una funzione virt. Cosa significa e come posso risolvere il problema?
R20. Virtexec è un programma che prende l'argomento zero
[il nome con cui viene invocato da riga di comando N.d.T.], elimina i suoi
primi quattro caratteri, ed esegue il programma dal nome rimanente
nell'ambiente virtuale. Ad esempio, virtpasswd fa eseguire passwd. Se i
primi quattro caratteri che deve eliminare non sono virt allora
emette quel messaggio di errore. Virtexec è uno script di shell e
dovrebbe risultare di facile comprensione. Ricorri alle pagine man di bash,
o di qualunque altra shell tu stia usando, per questioni concernenti la
programmazione in linguaggio di shell.
D21. Ho una domanda su Qmail, SAMBA, Apache, ecc. che non è correlata con la configurazione di virtuald o con l'uso del pacchetto in rapporto a virtuald.
R21. Tutti i pacchetti citati hanno una documentazione completa. Alcuni hanno anche siti web del tipo www.packagename.org a loro dedicati. Puoi consultarli per questioni riguardanti i pacchetti che non abbiano legami con il loro funzionamento in un ambiente virtuale.
D22. Ho parecchi alias di dominio per domain1.com ma la posta continua a rimbalzare dagli alias. Che succede?
R22. Virtmaildelivery utilizza unicamente le variabili di ambiente che gli vengono passate per determinare a quale directory /virtual/domain1.com consegnare i messaggi. Non effettua infatti alcun lookup DNS per determinare l'indirizzo del messaggio. Comunque, se l'indirizzo è submail.mail.domain1.com, virtmaildelivery proverà prima con quell'indirizzo, poi con mail.domain1.com, quindi con domain1.com e poi com in quest'ordine fino a che si abbia un riscontro positivo o non vi sia più un nome di dominio con cui provare.
Nondimeno se si hanno alias di dominio che non sono sottodomini uno dell'altro è necessario creare link simbolici come ad esempio:
cd /virtual ln -s domain1.com domain1alias.com
In questo modo virtmaildelivery sarà portato a credere che esistano entrambe le directory, anche se una è solo un link simbolico, e la posta potrà essere consegnata a user@domain1.com o user@domain1alias.com. Si noti che virtexec, ove eseguito, mostrerà entrambi i domini nella casella di dialogo. Si può scegliere uno qualunque dei due, dato che si tratta in realtà dello stesso filesystem virtuale.