Dans le message <news:45d20968$0$458$, *Guytou* tapota sur f.c.o.unix :
Comment surveiller efficacement un fichier présent dans un répertoire.
1/ Pour être informé dés sa suppression
3/ Pour savoir quand il a été supprimé
2/ Pour connaitre quel user l'a supprimé en utilisant quelle commande UNIX ou script
Voyez éventuellement du côté de Snoopy Logger qui permet de tracer tous les appels à execv et à execve. Ça ne permet pas de tout tracer non plus (par exemple les commandes internes des shells) et ça pourrait être contourné avec un LD_PRELOAD qui va bien.
-- Sébastien Monbrun aka TiChou
Dans le message <news:45d20968$0$458$426a74cc@news.free.fr>,
*Guytou* tapota sur f.c.o.unix :
Comment surveiller efficacement un fichier présent dans un répertoire.
1/ Pour être informé dés sa suppression
3/ Pour savoir quand il a été supprimé
2/ Pour connaitre quel user l'a supprimé en utilisant quelle commande
UNIX ou script
Voyez éventuellement du côté de Snoopy Logger qui permet de tracer tous les
appels à execv et à execve. Ça ne permet pas de tout tracer non plus (par
exemple les commandes internes des shells) et ça pourrait être contourné
avec un LD_PRELOAD qui va bien.
Dans le message <news:45d20968$0$458$, *Guytou* tapota sur f.c.o.unix :
Comment surveiller efficacement un fichier présent dans un répertoire.
1/ Pour être informé dés sa suppression
3/ Pour savoir quand il a été supprimé
2/ Pour connaitre quel user l'a supprimé en utilisant quelle commande UNIX ou script
Voyez éventuellement du côté de Snoopy Logger qui permet de tracer tous les appels à execv et à execve. Ça ne permet pas de tout tracer non plus (par exemple les commandes internes des shells) et ça pourrait être contourné avec un LD_PRELOAD qui va bien.
-- Sébastien Monbrun aka TiChou
Sébastien Monbrun aka TiChou
Dans le message <news:, *Sébastien Monbrun aka TiChou* tapota sur f.c.o.unix :
Voyez éventuellement du côté de Snoopy Logger qui permet de tracer tous les appels à execv et à execve. Ça ne permet pas de tout tracer non plus (par exemple les commandes internes des shells) et ça pourrait être contourné avec un LD_PRELOAD qui va bien.
En parlant de shell, il existe aussi des patches qui permettent de logger, via syslog, toutes les commandes lancées par un shell.
(le lien d'origine de l'auteur du patche est mort)
-- Sébastien Monbrun aka TiChou
Dans le message <news:bzium.20070214145035@florizarre.tichou.org>,
*Sébastien Monbrun aka TiChou* tapota sur f.c.o.unix :
Voyez éventuellement du côté de Snoopy Logger qui permet de tracer tous
les appels à execv et à execve. Ça ne permet pas de tout tracer non plus
(par exemple les commandes internes des shells) et ça pourrait être
contourné avec un LD_PRELOAD qui va bien.
En parlant de shell, il existe aussi des patches qui permettent de logger,
via syslog, toutes les commandes lancées par un shell.
Dans le message <news:, *Sébastien Monbrun aka TiChou* tapota sur f.c.o.unix :
Voyez éventuellement du côté de Snoopy Logger qui permet de tracer tous les appels à execv et à execve. Ça ne permet pas de tout tracer non plus (par exemple les commandes internes des shells) et ça pourrait être contourné avec un LD_PRELOAD qui va bien.
En parlant de shell, il existe aussi des patches qui permettent de logger, via syslog, toutes les commandes lancées par un shell.
(le lien d'origine de l'auteur du patche est mort)
-- Sébastien Monbrun aka TiChou
Guytou
Bonsoir Alain,
Comment surveiller efficacement un fichier présent dans un répertoire.
1/ Pour être informé dés sa suppression 3/ Pour savoir quand il a été supprimé
Si c'est sous Linux, il y a inotify(7).
Je ne connaissais pas la commande inotify(7).
ps -edf >> supprime.txt :-) J'espère que tu ne comptes pas trop là-dessus. Sinon, tu peux
regarder du coté de utmp et wtmp.
Je ne connaissais pas non plus ces deux commandes Unix (utmp et wtmp).
Grâce à google j'ai rensemblé une forte documentation sur ces 3 commandes et aussi sur la sécurité informatique. Dès demain matin auboulot, je vais améliorer mon script de surveillance d'un fichier.
Merci de votre aide
GUYTOU
"Alain Ketterlin" a écrit dans le message de news:
"Guytou" writes:
Comment surveiller efficacement un fichier présent dans un répertoire.
1/ Pour être informé dés sa suppression 3/ Pour savoir quand il a été supprimé
Si c'est sous Linux, il y a inotify(7).
2/ Pour connaitre quel user l'a supprimé en utilisant quelle commande UNIX ou script
Ca, ça me semble sans espoir...
# Je crée la liste des process et user présent sur le serveur au moment de la suppression de mon fichier ps -edf >> supprime.txt
:-) J'espère que tu ne comptes pas trop là-dessus. Sinon, tu peux regarder du coté de utmp et wtmp.
-- Alain.
Bonsoir Alain,
Comment surveiller efficacement un fichier présent dans un répertoire.
1/ Pour être informé dés sa suppression
3/ Pour savoir quand il a été supprimé
Si c'est sous Linux, il y a inotify(7).
Je ne connaissais pas la commande inotify(7).
ps -edf >> supprime.txt
:-) J'espère que tu ne comptes pas trop là-dessus. Sinon, tu peux
regarder du coté de utmp et wtmp.
Je ne connaissais pas non plus ces deux commandes Unix (utmp et wtmp).
Grâce à google j'ai rensemblé une forte documentation sur ces 3 commandes
et aussi sur la sécurité informatique.
Dès demain matin auboulot, je vais améliorer mon script de surveillance d'un
fichier.
Merci de votre aide
GUYTOU
"Alain Ketterlin" <alain@dpt-info.u-strasbg.fr> a écrit dans le message de
news: 87vei5rzjm.fsf@dpt-info.u-strasbg.fr...
"Guytou" <mapasa@free.fr> writes:
Comment surveiller efficacement un fichier présent dans un répertoire.
1/ Pour être informé dés sa suppression
3/ Pour savoir quand il a été supprimé
Si c'est sous Linux, il y a inotify(7).
2/ Pour connaitre quel user l'a supprimé en utilisant quelle
commande UNIX ou script
Ca, ça me semble sans espoir...
# Je crée la liste des process et user présent sur le serveur au
moment de la suppression de mon fichier
ps -edf >> supprime.txt
:-) J'espère que tu ne comptes pas trop là-dessus. Sinon, tu peux
regarder du coté de utmp et wtmp.
Comment surveiller efficacement un fichier présent dans un répertoire.
1/ Pour être informé dés sa suppression 3/ Pour savoir quand il a été supprimé
Si c'est sous Linux, il y a inotify(7).
Je ne connaissais pas la commande inotify(7).
ps -edf >> supprime.txt :-) J'espère que tu ne comptes pas trop là-dessus. Sinon, tu peux
regarder du coté de utmp et wtmp.
Je ne connaissais pas non plus ces deux commandes Unix (utmp et wtmp).
Grâce à google j'ai rensemblé une forte documentation sur ces 3 commandes et aussi sur la sécurité informatique. Dès demain matin auboulot, je vais améliorer mon script de surveillance d'un fichier.
Merci de votre aide
GUYTOU
"Alain Ketterlin" a écrit dans le message de news:
"Guytou" writes:
Comment surveiller efficacement un fichier présent dans un répertoire.
1/ Pour être informé dés sa suppression 3/ Pour savoir quand il a été supprimé
Si c'est sous Linux, il y a inotify(7).
2/ Pour connaitre quel user l'a supprimé en utilisant quelle commande UNIX ou script
Ca, ça me semble sans espoir...
# Je crée la liste des process et user présent sur le serveur au moment de la suppression de mon fichier ps -edf >> supprime.txt
:-) J'espère que tu ne comptes pas trop là-dessus. Sinon, tu peux regarder du coté de utmp et wtmp.
-- Alain.
Alain Ketterlin
"Guytou" writes:
Comment surveiller efficacement un fichier présent dans un répertoire. 1/ Pour être informé dés sa suppression 3/ Pour savoir quand il a été supprimé
Si c'est sous Linux, il y a inotify(7).
Je ne connaissais pas la commande inotify(7).
En fait, ce n'est pas une commande, c'est un ensemble d'appels système. Ca va donc être à toi d'écrire le programme... Je ne sais pas si il existe des commandes toute prêtes. Voici un lien sur une page qui donne des indications :
Ce n'est pas très récent, donc je ne sais pas si c'est à jour.
Je ne connaissais pas non plus ces deux commandes Unix (utmp et wtmp).
Là non plus, ce ne sont pas des commandes, simplement le format des logs. Voir les autres messages pour divers moyens de scruter qui a fait quoi.
-- Alain.
"Guytou" <mapasa@free.fr> writes:
Comment surveiller efficacement un fichier présent dans un répertoire.
1/ Pour être informé dés sa suppression
3/ Pour savoir quand il a été supprimé
Si c'est sous Linux, il y a inotify(7).
Je ne connaissais pas la commande inotify(7).
En fait, ce n'est pas une commande, c'est un ensemble d'appels
système. Ca va donc être à toi d'écrire le programme... Je ne sais pas
si il existe des commandes toute prêtes. Voici un lien sur une page
qui donne des indications :
Comment surveiller efficacement un fichier présent dans un répertoire. 1/ Pour être informé dés sa suppression 3/ Pour savoir quand il a été supprimé
Si c'est sous Linux, il y a inotify(7).
Je ne connaissais pas la commande inotify(7).
En fait, ce n'est pas une commande, c'est un ensemble d'appels système. Ca va donc être à toi d'écrire le programme... Je ne sais pas si il existe des commandes toute prêtes. Voici un lien sur une page qui donne des indications :
Ce n'est pas très récent, donc je ne sais pas si c'est à jour.
Je ne connaissais pas non plus ces deux commandes Unix (utmp et wtmp).
Là non plus, ce ne sont pas des commandes, simplement le format des logs. Voir les autres messages pour divers moyens de scruter qui a fait quoi.
-- Alain.
Vincent Lefevre
Dans l'article , Alain Ketterlin écrit:
En fait, ce n'est pas une commande, c'est un ensemble d'appels système. Ca va donc être à toi d'écrire le programme... Je ne sais pas si il existe des commandes toute prêtes. Voici un lien sur une page qui donne des indications :
Ce n'est pas très récent, donc je ne sais pas si c'est à jour.
Pour inotify, cf
http://en.wikipedia.org/wiki/Inotify
qui donne notamment un lien sur inotify-tools.
Alternativement, si besoin est (kernel plus ancien que 2.6.13, etc.), sous Debian, il existe les paquets fam:
Description: File Alteration Monitor FAM monitors files and directories, notifying interested applications of changes. . This package provides a server that can monitor a given list of files and notify applications through a socket. If the kernel supports dnotify (kernels >= 2.4.x) FAM is notified directly by the kernel. Otherwise it has to poll the files' status. FAM can also provide an RPC service for monitoring remote files (such as on a mounted NFS filesystem).
et fwatch:
Description: Kernel level file activity monitoring Allows you to seamlessly follow the file activity (open, close, stat) by hooking directly into the Linux kernel and reporting every operation to /dev/fwatch. Can help debugging and tuning. Fwatch is distributed as a Linux kernel module.
Ceci dit, je suppose qu'il faut aussi écrire le programme.
Dans l'article <87fy973n1a.fsf@dpt-info.u-strasbg.fr>,
Alain Ketterlin <alain@dpt-info.u-strasbg.fr> écrit:
En fait, ce n'est pas une commande, c'est un ensemble d'appels
système. Ca va donc être à toi d'écrire le programme... Je ne sais pas
si il existe des commandes toute prêtes. Voici un lien sur une page
qui donne des indications :
Ce n'est pas très récent, donc je ne sais pas si c'est à jour.
Pour inotify, cf
http://en.wikipedia.org/wiki/Inotify
qui donne notamment un lien sur inotify-tools.
Alternativement, si besoin est (kernel plus ancien que 2.6.13, etc.),
sous Debian, il existe les paquets fam:
Description: File Alteration Monitor
FAM monitors files and directories, notifying interested applications
of changes.
.
This package provides a server that can monitor a given list of files
and notify applications through a socket. If the kernel supports
dnotify (kernels >= 2.4.x) FAM is notified directly by the kernel.
Otherwise it has to poll the files' status. FAM can also provide an
RPC service for monitoring remote files (such as on a mounted NFS
filesystem).
et fwatch:
Description: Kernel level file activity monitoring
Allows you to seamlessly follow the file activity (open, close, stat)
by hooking directly into the Linux kernel and reporting every
operation to /dev/fwatch. Can help debugging and tuning. Fwatch is
distributed as a Linux kernel module.
Ceci dit, je suppose qu'il faut aussi écrire le programme.
En fait, ce n'est pas une commande, c'est un ensemble d'appels système. Ca va donc être à toi d'écrire le programme... Je ne sais pas si il existe des commandes toute prêtes. Voici un lien sur une page qui donne des indications :
Ce n'est pas très récent, donc je ne sais pas si c'est à jour.
Pour inotify, cf
http://en.wikipedia.org/wiki/Inotify
qui donne notamment un lien sur inotify-tools.
Alternativement, si besoin est (kernel plus ancien que 2.6.13, etc.), sous Debian, il existe les paquets fam:
Description: File Alteration Monitor FAM monitors files and directories, notifying interested applications of changes. . This package provides a server that can monitor a given list of files and notify applications through a socket. If the kernel supports dnotify (kernels >= 2.4.x) FAM is notified directly by the kernel. Otherwise it has to poll the files' status. FAM can also provide an RPC service for monitoring remote files (such as on a mounted NFS filesystem).
et fwatch:
Description: Kernel level file activity monitoring Allows you to seamlessly follow the file activity (open, close, stat) by hooking directly into the Linux kernel and reporting every operation to /dev/fwatch. Can help debugging and tuning. Fwatch is distributed as a Linux kernel module.
Ceci dit, je suppose qu'il faut aussi écrire le programme.
On Thu, 15 Feb 2007 10:40:47 +0000 (UTC) Vincent Lefevre <vincent+ wrote:
Alternativement, si besoin est (kernel plus ancien que 2.6.13, etc.), sous Debian, il existe les paquets fam
Gamin fournit les même services aussi (on le trouve plus souvent que fam maintenant.)
Mais là encore il faut coder ...
(par contre, avec l'interface fournit pour python j'ai écrit un petit truc qui monitor les changements d'un .dvi en quelques minutes sans jamais avoir coder en python de ma vie avant ... )
-- Ferengi Rule of Acquisition #125: You can't make a deal if you're dead. -- ST:DS9, "The Siege of AR-558"
On Thu, 15 Feb 2007 10:40:47 +0000 (UTC)
Vincent Lefevre <vincent+news@vinc17.org> wrote:
Alternativement, si besoin est (kernel plus ancien que 2.6.13, etc.),
sous Debian, il existe les paquets fam
Gamin fournit les même services aussi (on le trouve plus souvent que
fam maintenant.)
Mais là encore il faut coder ...
(par contre, avec l'interface fournit pour python j'ai écrit un petit
truc qui monitor les changements d'un .dvi en quelques minutes sans
jamais avoir coder en python de ma vie avant ... )
--
Ferengi Rule of Acquisition #125:
You can't make a deal if you're dead.
-- ST:DS9, "The Siege of AR-558"
On Thu, 15 Feb 2007 10:40:47 +0000 (UTC) Vincent Lefevre <vincent+ wrote:
Alternativement, si besoin est (kernel plus ancien que 2.6.13, etc.), sous Debian, il existe les paquets fam
Gamin fournit les même services aussi (on le trouve plus souvent que fam maintenant.)
Mais là encore il faut coder ...
(par contre, avec l'interface fournit pour python j'ai écrit un petit truc qui monitor les changements d'un .dvi en quelques minutes sans jamais avoir coder en python de ma vie avant ... )
-- Ferengi Rule of Acquisition #125: You can't make a deal if you're dead. -- ST:DS9, "The Siege of AR-558"
rixed
Juste par complétude, puisqu'il n'a été question que de Linux jusqu'ici :
- Sous FreeBSD il y a désormais (version 6.2) un module d'audit qui permet en autres de monitorer la suppression (ou la tentative de suppression) d'un fichier, avec utilisateur et tutti quanti ; - Ça utilise un format de log standard, nommé BSM, donc c'est bien ; - Puisqu'il y a un format standard, FreeBSD doit suivre d'autres Unix - la doc site Solaris et MacOS-X ;
Juste par complétude, puisqu'il n'a été question que de Linux jusqu'ici :
- Sous FreeBSD il y a désormais (version 6.2) un module d'audit qui
permet en autres de monitorer la suppression (ou la tentative de
suppression) d'un fichier, avec utilisateur et tutti quanti ;
- Ça utilise un format de log standard, nommé BSM, donc c'est bien ;
- Puisqu'il y a un format standard, FreeBSD doit suivre d'autres Unix -
la doc site Solaris et MacOS-X ;
Juste par complétude, puisqu'il n'a été question que de Linux jusqu'ici :
- Sous FreeBSD il y a désormais (version 6.2) un module d'audit qui permet en autres de monitorer la suppression (ou la tentative de suppression) d'un fichier, avec utilisateur et tutti quanti ; - Ça utilise un format de log standard, nommé BSM, donc c'est bien ; - Puisqu'il y a un format standard, FreeBSD doit suivre d'autres Unix - la doc site Solaris et MacOS-X ;
- Sous FreeBSD il y a désormais (version 6.2) un module d'audit qui permet en autres de monitorer la suppression (ou la tentative de suppression) d'un fichier, avec utilisateur et tutti quanti ;
Merci à "rixed" pour sa contribution
GUYTOU
"rixed" a écrit dans le message de news:
Juste par complétude, puisqu'il n'a été question que de Linux jusqu'ici :
- Sous FreeBSD il y a désormais (version 6.2) un module d'audit qui permet en autres de monitorer la suppression (ou la tentative de suppression) d'un fichier, avec utilisateur et tutti quanti ; - Ça utilise un format de log standard, nommé BSM, donc c'est bien ; - Puisqu'il y a un format standard, FreeBSD doit suivre d'autres Unix - la doc site Solaris et MacOS-X ;
- Sous FreeBSD il y a désormais (version 6.2) un module d'audit qui
permet en autres de monitorer la suppression (ou la tentative de
suppression) d'un fichier, avec utilisateur et tutti quanti ;
Merci à "rixed" pour sa contribution
GUYTOU
"rixed" <rixed@msx.happyleptic.org> a écrit dans le message de news:
slrnetl8qv.p3j.rixed@localhost.localdomain...
Juste par complétude, puisqu'il n'a été question que de Linux jusqu'ici :
- Sous FreeBSD il y a désormais (version 6.2) un module d'audit qui
permet en autres de monitorer la suppression (ou la tentative de
suppression) d'un fichier, avec utilisateur et tutti quanti ;
- Ça utilise un format de log standard, nommé BSM, donc c'est bien ;
- Puisqu'il y a un format standard, FreeBSD doit suivre d'autres Unix -
la doc site Solaris et MacOS-X ;
- Sous FreeBSD il y a désormais (version 6.2) un module d'audit qui permet en autres de monitorer la suppression (ou la tentative de suppression) d'un fichier, avec utilisateur et tutti quanti ;
Merci à "rixed" pour sa contribution
GUYTOU
"rixed" a écrit dans le message de news:
Juste par complétude, puisqu'il n'a été question que de Linux jusqu'ici :
- Sous FreeBSD il y a désormais (version 6.2) un module d'audit qui permet en autres de monitorer la suppression (ou la tentative de suppression) d'un fichier, avec utilisateur et tutti quanti ; - Ça utilise un format de log standard, nommé BSM, donc c'est bien ; - Puisqu'il y a un format standard, FreeBSD doit suivre d'autres Unix - la doc site Solaris et MacOS-X ;
