<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<TITLE>Virtual Services Howto: FAQ</TITLE>
<LINK HREF="Virtual-Services-HOWTO-12.html" REL=previous>
<LINK HREF="Virtual-Services-HOWTO.html#toc13" REL=contents>
</HEAD>
<BODY>
Avanti
<A HREF="Virtual-Services-HOWTO-12.html">Indietro</A>
<A HREF="Virtual-Services-HOWTO.html#toc13">Indice</A>
<HR>
<H2><A NAME="s13">13. FAQ</A></H2>
<P><B>D1</B>. Ho creato sendmail.init e syslogd.init. Li ho messi in
/usr/local/bin e ho cercato di eseguirli, ma ottengo degli errori.
<P>
<P><B>R1</B>. 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
<A HREF="http://www.pluto.linux.it/ildp/guide">Guide LDP tradotte</A> N.d.T.]
per informazioni sull'uso degli `init script'.
<P>
<P><B>D2</B>. Ho messo queste linee in /etc/sendmail.cf
<P>
<PRE>
divert(0)
VERSIONID(`tcpproto.mc')
OSTYPE(linux)
FEATURE(redirect)
FEATURE(always_add_domain)
FEATURE(use_cw_file)
FEATURE(local_procmail)
MAILER(local)
MAILER(smtp)
</PRE>
<P>E ho ricevuto degli strani messaggi di output. Perché?
<P>
<P><B>R2</B>. 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.
<P>
<P><B>D3</B>. Dove trovo virtuald, che cos'è e come lo devo usare?
<P>
<P><B>R3</B>. 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
<CODE>make virtuald</CODE>. 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.
<P>
<P><B>D4</B>. E se non ho dialog installato sul mio sistema?
<P>
<P><B>R4</B>. 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
<A HREF="ftp://metalab.unc.edu/pub/Linux/utils/shell/cdialog-0.9a.tar.gz">sunsite</A>. È di facile compilazione e installazione.
<P>
<P><B>D5</B>. Come posso sapere se il syslogd virtuale funziona?
<P>
<P><B>R5</B>. Quando virtuald parte dovrebbe inviare i seguenti messaggi
a syslogd (/var/log/messages):
<P>
<PRE>
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
</PRE>
<P>Il messaggio circa la directory su cui viene fatto <CODE>chroot</CODE> è
inviato da virtuald dopo l'esecuzione della chiamata di funzione
<CODE>chroot</CODE>. 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.
<P>
<P>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.
<P>
<P><B>D6</B>. Come posso configurare le quote disco tenendo conto dei vari
filesystem virtuali?
<P>
<P><B>R6</B>. Puoi configurare le quote disco come faresti normalmente. Puoi
consultare il
<A HREF="http://sunsite.unc.edu/LDP/HOWTO/mini/Quota.html">Quota mini-HOWTO</A>. 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.
<P>
<P><B>D7</B>. Che cosa sono i '\' nelle voci di inetd.conf?
<P>
<P><B>R7</B>. È 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.
<P>
<P><B>D8</B>. Quando lancio passwd o altri programmi di login ricevo un
<CODE>permission denied</CODE>. Quando lancio FTP o `su' ricevo un
<CODE>no modules loaded for service XXX</CODE>. Perché?
<P>
<P><B>R8</B>. 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à.
<P>
<P><B>D9</B>. Virtuald può lavorare assieme ai file di tcpd:
hosts.allow e hosts.deny?
<P>
<P><B>R9</B>. Sì, con opportune modifiche lo può fare.
<P>
<P>Per prima cosa il sorgente dev'essere modificato in due punti.
<P>
<P>Dev'essere inserito quanto segue nel punto in cui gli argomenti vengono
controllati.
<P>
<PRE>
if (!argv[3])
{
syslog(LOG_ERR,"invalid arguments: no program to run");
exit(0);
}
</PRE>
<P>La linea `exec' dev'essere cambiata da:
<P>
<PRE>
if (execvp(argv[2],argv+2)<0)
</PRE>
<P>in:
<P>
<PRE>
if (execvp(argv[2],argv+3)<0)
</PRE>
<P>Come secondo passo le linee di inetd.conf devono essere modificate da:
<P>
<PRE>
ftp stream tcp nowait root /usr/local/bin/virtuald \
virtuald /virtual/conf.ftp wu.ftpd -l -a
</PRE>
<P>in:
<P>
<PRE>
ftp stream tcp nowait root /usr/local/bin/virtuald \
virtuald /virtual/conf.ftp tcpd wu.ftpd -l -a
</PRE>
<P>Come terzo passo modifica in modo appropriato i file
/virtual/domain1.com/etc/hosts.allow e /virtual/domain1.com/etc/hosts.deny.
<P>
<P><B>D10</B>. I miei host virtuali possono eseguire script CGI?
<P>
<P><B>R10</B>. Sì, lo possono fare, ma ti raccomando di mettere i
/cgi-bin in un posto non accessibile dopo il <CODE>chroot</CODE>, 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.
<P>
<P><B>D11</B>. I miei file di configurazione sono diversi dagli esempi
riportati. Che devo fare?
<P>
<P><B>R11</B>. 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.
<P>
<P><B>D12</B>. Ti ho scritto una e-mail e non ho ricevuto alcuna risposta o
c'è voluto molto tempo per averla. Perché?
<P>
<P><B>R12</B>. 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.
<P>
<P><B>D13</B>. Virtuald funziona su connessioni sotto i 100Mbit?
<P>
<P><B>R13</B> 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.
<P>
<P><B>D14</B>. Dovrei usare la tabella virthost di sendmail?
<P>
<P><B>R14</B>. 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 <CODE>chroot</CODE>. Installa virtuald e poi configura sendmail
come faresti normalmente per ogni singolo dominio.
<P>
<P><B>D15</B>. 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?
<P>
<P><B>R15</B>. 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:
<P>
<UL>
<LI> Allo scopo di ingannare compiutamente una sessione telnet in entrata
si dovrebbe fare qualche modifica al kernel, aggiustare l'indirizzo IP
sorgente per le connessioni in uscita, ingannare gethostname per fargli
usare l'hostname virtuale e non quello del sistema reale, eccetera. Se si
hanno conoscenze avanzate, ci si diverta pure a smanettare sul kernel, ma
non lo consiglio certo a principianti o simili.</LI>
<LI> Permettere agli utenti di accedere alla propria macchina via telnet
significa consentire loro di lanciare programmi a piacere. Usando trucchi
ben noti essi potrebbero acquistare i privilegi di root e procurare danni
al sistema.</LI>
<LI> Dare un account telnet con privilegi di root su un box virtuale
è malsano. Come root nell'ambiente virtuale un utente può
leggere comunque i file di device a basso livello, annullando in
pratica il <CODE>chroot</CODE>, può spegnere il sistema, e può
uccidere altri processi in esecuzione.</LI>
<LI> I programmi che vengono eseguiti in queste sessioni telnet occupano
un certo tempo di CPU, prezioso per i servizi di rete.</LI>
<LI> Telnet è un servizio insicuro. Lungo la rete le password
vengono trasmesse in chiaro. Se un utente malintenzionato riuscisse ad
ottenerle, potrebbe utilizzare i trucchi sopramenzionati per mettere in
pericolo il sistema.</LI>
<LI> Gli ambienti virtuali avranno bisogno di uno spazio maggiore. Serve
lo spazio per un numero maggiore di librerie condivise, file di
configurazione e file binari. Anche su un disco da sei gigabyte lo spazio
disponibile può esaurirsi molto rapidamente.</LI>
</UL>
<P>
<P>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.
<P>
<P><B>D16</B>. 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?
<P>
<P><B>R16</B>. 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.
<P>
<P><B>D17</B>. Quando lancio virtexec come utente normale ricevo il
messaggio <CODE>chroot: operation not permitted</CODE>. Perché?
<P>
<P><B>R17</B>. <CODE>Chroot</CODE> è una chiamata di sistema ristretta
ai privilegi di root. Solo il superutente può eseguirla. Lo script
virtexec lancia il programma <CODE>chroot</CODE>, per cui è necessario
essere root per eseguirlo con successo.
<P>
<P><B>D18</B>. Ho configurato pop e sendmail ma il prelievo della posta a
mezzo pop non sembra funzionare. Che succede?
<P>
<P><B>R18</B>. 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.
<P>
<P><B>D19</B>. Non ho usato il programma citato nel tuo HOWTO. Ho usato il
programma XXX. Non funziona. Perché?
<P>
<P><B>R19</B>. 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).
<P>
<P><B>D20</B>. Quando lancio virtexec mi dice: <CODE>Il link simbolico non è a
una funzione virt</CODE>. Cosa significa e come posso risolvere il problema?
<P>
<P><B>R20</B>. 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 <CODE>virt</CODE> 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.
<P>
<P><B>D21</B>. 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.
<P>
<P><B>R21</B>. 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.
<P>
<P><B>D22</B>. Ho parecchi alias di dominio per domain1.com ma la posta
continua a rimbalzare dagli alias. Che succede?
<P>
<P><B>R22</B>. 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.
<P>
<P>Nondimeno se si hanno alias di dominio che non sono sottodomini uno
dell'altro è necessario creare link simbolici come ad esempio:
<P>
<PRE>
cd /virtual
ln -s domain1.com domain1alias.com
</PRE>
<P>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.
<P>
<P>
<HR>
Avanti
<A HREF="Virtual-Services-HOWTO-12.html">Indietro</A>
<A HREF="Virtual-Services-HOWTO.html#toc13">Indice</A>
</BODY>
</HTML>
