Hi Folks
I have been looking diligently through my DPM logfiles in anticipation for the
LCG security challenges.
I have a few notes, to which other people might want to add.
DPM Logging
-----------
The log files for, say, an srmcp transaction are spread over dpns, dpm, srmv1
and gridftp logs. In addition, gridftp transactions on pool nodes are logged
on that host, not on the admin node. It's then far from easy to work out
where one should look. DNs get recorded in multiple places by multiple
daemons - usually information appears more than once (confusing but 2 is much
better than 0 in this case).
However, my first pass answer to the question "who put file X on your system
is":
a) Look at the srmv1 logs. If the file was transferred using srm then the DN
and client host will be recorded. This might be all you need but...
b) If you need more information, or the file was griftped, then grep for file
X in the dpns logfile. This should show the name server transaction, and will
also show the grid certificate used. Importantly it will also show the TURL
(look for the "Cns_srv_addreplica:" line) and the pool onto which the file
was placed.
c) If required, go to the pool host and look in /var/log/messages - you should
find the gridftp transfer which placed the file onto the system. Again, the
certificate DN is recorded. The dpm-gridftp.log file does not record the DN
information - it just logs some parameters of the transfer, e.g size,
streams. However, _very_importantly_, it records the host which transferred
the file (under DEST=[IP.ADDRESS]). (There is host information also stored in
the dpns logs, however this is normally the DPM admin host for file copies,
which is doing the lookups for the user, not the user's client machine.)
However, there are some caveats and other notes:
1. If the client did a globus-url-copy directly into DPM name space, then the
receiving gridftp server is on the admin node, not the pool node (the server
then rfios the file to the pool). Look at the admin node's gridftp logs.
Naturally, there's nothing in the srm logs in this case.
2. The gridftp server on a pool is also normal gridftp server, i.e., it can
transfer files into the normal file space of your system (try
"globus-url-copy file:/some/file gsiftp://pool.node/tmp/someFile"). If this
happens then there's nothing logged in the nameserver. The only logs will
be /var/log/messages and /var/log/dpm-gsiftp.log _on_the_pool_node_.
This should satisfy security logging requirements. We can find: time stamps,
certificate used, source host, destination filename.
!!!!!BUT!!!!!
By default on an SL box /var/log/messages, which potentially contains the only
record of the DN used in a gridftp transaction, is only kept for 4 weeks. LCG
security requires 90 days, so I strongly suggest that all sites check their
logrotate.conf, and amend to:
---
weekly
keep 15
compress
delaycompress
---
Next question: "Who deleted file X?":
Depends how they did it:
SRM:
Much the same as above, look in the srmv1 logs. There should be a
"advisoryDelete:" log, with DN and client host. Further, in the dpns logs,
there should be a Cns_srv_listreplica for the file, then a Cns_delreplica
against the TURL.
gridftp:
The dpns logs are useless here (except for time) - all record as root on the
admin host which is doing the lookups on behalf of the client. One needs to
look in /var/log/messages for an ftp DELE command as part of the gridftp
transaction log - the DN is recorded a few lines above. Look in
dpm-gsiftp.log for the client host IP as above.
Once again the it's possible for important information to only be present
in /var/log/messages. ENSURE YOUR SITE KEEPS THIS FOR AT LEAST 90 DAYS.
Comments? I'll wikify if people think this is useful.
dCache anyone?
Graeme
--
--------------------------------------------------------------------
Dr Graeme Stewart http://www.physics.gla.ac.uk/~graeme/
GridPP DM Wiki http://wiki.gridpp.ac.uk/wiki/Data_Management
|