Newsgroup: it.comp.os.linux.sys
Titolo: Ottenere info sulle interfacce TUN/TAP attivate

Salve,
ho cercato un bel po' in rete, senza successo.
Dato un Process ID, voglio sapere se e quali interfacce TUN/TAP ha
tirato su.
Vale anche il contrario: se voglio sapere quale processo ha creato,
poniamo, 'tun0', come faccio?
Ho provato a "farmi un giro" nei filesystem /proc/$PID e /sys/class/
net, ma non sono riuscito a venire a capo di nulla.
Grazie a chi vorrà aiutarmi.
Guido

Guido De Rosa wrote:

Non credo sia possibile. Tieni conto che se l'interfaccia e' persistente, il 
processo che l'ha creata e' quasi sicuramente terminato. Al massimo puoi 
vedere quali processi stanno *usando* l'interfaccia, cercando (ad esempio 
con lsof) i processi che hanno /dev/net/tun aperto (che significa che stanno 
leggendo/scrivendo dati dall'interfaccia).

 leggendo/scrivendo dati dall'interfaccia).
Putroppo così non si può distinguere chi sta usando tun0, da chi sta
usando tun1, tun2 etc. etc.
Sto scrivendo un frontend per openvpn e vorrei essere in grado di
gestire il "worst case scenario", in cui ci sono diversi processi
openvpn e NON è attivata l'opzione "management":
http://www.openvpn.net/index.php/open-source/documentation/miscellaneous/79-management-interface.html
Il codice che sto scrivendo, che è in Ruby e fa parte di un progetto
più ampio, è qui:
http://snurl.com/slru1
Finora ero riuscito ad ottenere tutte le informazioni sullo stato del
sistema a colpi di espressioni regolari e letture in /proc e /sys
senza dover fare troppe assunzioni su questa o quella configurazione.
L'idea è un tool che possa monitorare anche demoni che non sono stati
avviati dal tool stesso...
G.

 senza dover fare troppe assunzioni su questa o quella configurazione.
Vedo che leggi il file di configurazione. Ottenere il nome e la posizione 
del file dalla riga di comando non e' semplice, primo perche' potrebbe non 
esserci (si possono anche specificare le opzioni tutte sulla riga di comando 
senza usare --config), e in secondo luogo uno potrebbe avere specificato --
config ../../foo/bar/../.././abcd.conf (esempio volutamente estremo) che 
diventa un po' difficile da gestire, soprattutto se OpenVPN cambia la 
working directory dopo essere stato avviato.

 working directory dopo essere stato avviato.
Se diventa demone - come accade tipicamente - la sua cwd viene
cambiata in '/',
e lo stesso si ottiene se si va a leggere /proc/$pid/cwd. Per fortuna,
però, se si
legge /proc/$pid/environ e si estrae la variabile PWD, si ottiene la
directory da cui
*è stato lanciato* e non quella attuale, il che in questo caso è di
grande aiuto ;-)
Questa caratteristica di /proc/$pid/environ è però anche un difetto:
se fossi in grado
di leggere l'environment *attuale*, potrei estrarre la variabile 'dev'
che risolverebbe il mio problema :-)
G.

 che risolverebbe il mio problema :-)
/proc/$pid/environ *e'* l'environment attuale. La variabile che citi fa 
parte delle variabili che OpenVPN rende disponibili nell'environment degli 
script "figli" che vengono eseguiti (ad esempio per --up etc.).

 script "figli" che vengono eseguiti (ad esempio per --up etc.).
Certo, ma mi aspettavo che accadesse qualcosa di simile a quando, in
uno sript di shell, si imposta una variabile e poi si da "export": la
variabile è resa disponibile alle shell figlie, ma è subito
disponibile anche per la shell madre.

 disponibile anche per la shell madre.
Sono due cose diverse.
Un processo puo' decidere se e quale environment passare ai figli, tramite 
execve() o equivalente. Nella shell c'e' una convenzione per cui quando si 
fa "export" si sta in realta' "chiedendo" alla shell di inserire quella 
variabile nell'environment che passera' ai processi figli. Ma e' solo una 
convenzione in uso nella shell. Altri programmi sono liberi di fare come 
credono. 
Inoltre quelle variabili di cui parlavamo, tra cui "dev", nessuno le mette 
nell'environment di OpenVPN quando viene avviato (e anche in quel caso, come 
faresti a vederle? dovresti attaccarti al processo con gdb e chiamare 
getenv() :)
Quindi io mi aspetto che quando OpenVPN avvia un processo figlio, in quel 
momento metta la varibile o le variabili nell'environment del figlio in sede 
di chiamata ad execve(), quindi finche' non viene invocato un processo 
figlio quelle variabili non sono visibili (anche se, ovviamente, OpenVPN le 
avra' in memoria da qualche parte, altrimenti non funzionerebbe).