Ottenere info sulle interfacce TUN/TAP attivate
Guido De Rosa
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
antani
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).
Guido De Rosa
> 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).
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":
Il codice che sto scrivendo, che è in Ruby e fa parte di un progetto
più ampio, è qui:
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.
antani
>> 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).
>
> Putroppo così non si può distinguere chi sta usando tun0, da chi sta
> usando tun1, tun2 etc. etc.
L'interfaccia, come ogni altra interfaccia nel sistema, puo' potenzialmente
essere usata da n processi contemporaneamente.
Sarebbe come chiedere: chi sta usando eth0?
Quello che ti servirebbe e' proprio "chi ha tirato su l'interfaccia", ma
come dicevo potrebbe non esserci traccia di cio' (potrebbe essere stata
creata dagli initscript al boot ad esempio).
Potresti provare a parsare i log di OpenVPN, che comunque potrebbero non
esserci, e il formato dei messaggi potrebbe differire leggermente tra le
varie versioni.
> 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.
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.
Guido De Rosa
-snip-
> Potresti provare a parsare i log di OpenVPN, che comunque potrebbero non
> esserci, e il formato dei messaggi potrebbe differire leggermente tra le
> varie versioni.
Per complicare ulteriormente le cose ci sono 12 diversi livelli di
verbosità...
> 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),
Infatti c'è un bel TODO... :-)
> e in secondo luogo uno potrebbe avere specificato --
> config ../../foo/bar/../.././abcd.conf (esempio volutamente estremo) che
> diventa un po' difficile da gestire,
Nell'ultimo commit, cerco di gestire la cosa:
> soprattutto se OpenVPN cambia la
> 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.
antani
> 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 :-)
/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.).
Guido De Rosa
> /proc/$pid/environ *e'* l'environment attuale.
Mmm, sembrerebbe di no (sempre che per "environment attuale"
intendiamo la stessa cosa)
Basta scrivere questo semplice programmino:
#include <stdlib.h>
#include <stdio.h>
int main()
{
printf("MYVAR=%s \n", getenv("MYVAR"));
setenv("MYVAR", "new_value", 1);
printf("I've just set MYVAR=%s \n", getenv("MYVAR"));
while(1) {
sleep(1);
}
}
Compilarlo ed eseguirlo, preimpostando la variabile MYVAR
gcc -o test_environ test_environ.c
MYVAR=old_value ./test_environ
Si ottiene questo output:
MYVAR=old_value
I've just set MYVAR=new_value
(qui il programma va in loop e non uscirà finché non sarà killato).
A questo punto possiamo aprire un altro terminale e (assumendo che non
vi siano altre istanze di test_environ in esecuzione) diamo:
cat /proc/`pidof test_environ`/environ | tr '\000' '\n' | grep MYVAR
e otteniamo
MYVAR=old_value
anziché "new_value"
quindi /proc/$pid/environ contiene l'ambiente al momento dell'avvio
del processo, e non sembra dare conto di eventuali cambiamenti a
runtime.
> 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.).
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.
antani
> > /proc/$pid/environ *e'* l'environment attuale.
>
> Mmm, sembrerebbe di no (sempre che per "environment attuale"
> intendiamo la stessa cosa)
Si' hai ragione, avevo scritto soprappensiero. Quel file contiene
l'environment ricevuto all'avvio del processo.
>> 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.).
>
> 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.
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).