1. ABSTRACT
This document proposes a method for implementing logging in svnserve.
It presents the implementation in two phases.
2. PURPOSE
Svnserve currently has no log to record network access and operations.
This is a significant feature that limits many people from using
svnserve, and instead forcing them to use Apache/WebDAV to obtain
connection and operation logging.
I've seen this topic has been brought up several times before. Several
people have requested this feature including myself but as far as I
can tell no one has tackled it yet.
3. INITIAL PLANS (Phase I)
The inital logging features I am proposing are quite simple. I'd like
to keep the initial implementation very simple and expand from there.
I would like to point out that Phase I only attempts to address
network connection logging. In a much broader scope logging could be
used to log debug information, program traces, or just simply be more
verbose. This is something I think should be addressed in Phase II.
3.1 Log files
All log information will be written to a file. The log's
filename and path should be specifiable through svnserve.conf
with a line like the following:
logfile = /var/log/svnserve.log
The default path should be the repository path that's being accessed.
Relative paths can be accessed from this path as shown in this
example:
logfile = ../logs/svnserve.log
The log file can be disabled by either specifying nothing for the
logfile, as shown below, or ommitting the line altogether.
logfile =
This of course means if by default logfile is not specified in
svnserve.conf, then, also by default, a log will not be written.
Note here that each repository has its own svnserve.conf file and thus
a single instance of svnserve could be writing to different logfiles,
one for each repository.
3.2 Log Entries
Initially, there will be only one type of log entry which is written
before any operation is performed. If authentication fails and the
operation is aborted, a log entry will still be written.
* log entries consist of:
- the time
- the remote connection's ip address
- the user:
if no authentication is required, write anonymous
if user is authenticated write the user name
if authentication failed, write "AUTHFAIL" or similar.
- the opreration type
[YYYY:mm:dd@HH:MM:SS] [IP Address] [User] [Operation Type]
4. FUTURE PLANS (Phase II)
All items in phase II are currently just ideas and suggestions. The
items here need some in-depth discussion to flesh them out. I'll try
not to say too much on them so as not to steer them in any direction
just yet.
4.1 Customizable Log Format
It would be nice to add the option of customizing log formats. This
might be more complicated than it's worth but I'll leave that open for
debate.
* Listed here are some additional items that could be in a log entry,
not including the items mentioned above in Phase I. This list is by no
means exhaustive.
- Revision: a number, a range, a date, or HEAD
- Repository Realm string
- Path of repository
- Logging the method authenticated with (provider description)
- Log the directory accessed
I don't suggest to give a format for this. I'm woefully unaware of
any common custom log format specifications. I leave this one open to
suggestions.
4.2 Support more verbose output and debug tracing.
I don't think this requires much explanation. Developers and users
alike could get a lot of help from tracing and verbose logging. It's
been requested several times on the mailing list. I'm sure if the
functions were there today many people would start using them.
4.3 Support for syslogd
This was mentioned in the following email:
http://subversion.tigris.org/servlets/ReadMsg?listName=dev&msgNo=93651
The problems I see with syslog stem from its use on platforms other
than Linux/Unix. The Windows world uses the Windows Event Log but
might have a compatible version of syslogd. Still, there is BeOS,
OS/2, and OS/400 to take care of. Any implementation will need to be
cross-platform.
The following email also directly relates to this:
http://subversion.tigris.org/servlets/ReadMsg?listName=dev&msgNo=93420
Additionaly, some people may not want to run syslogd for security
reasons or otherwise. We should never force someone to use syslogd.
4.4 Add logging functionality via APR-util or log4c
As far as I know, APR-util doesn't have logging functions, but it
could be added.
Using APR for logging functions was mentioned in one of the emails
noted above. This could be a good solution to supporting files,
network access, syslogd, Windows Event Logs, etc in a generic manner.
Having a robust cross-platform logger with functionality like log4j
and log4c (e.g. logging via TCP) would be a great help to developers.
4.5 XML Logging format
This could be useful to many people. One nice thing about XML is that
it is easy to transform into HTML using XSLT. I don't think there is
much demand for this though.
5. RELATED MATERIAL
5.1 Patch from Karl Fogel
This is a patch and proposal from Karl Fogel that notes similar stuff
to what I'm proposing (though much better!). According to his notes,
the patch is for ra_dav and does not change svnserve.
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=101176
6. CONCLUSION
This should help to get the ball rolling. I should have a patch I can
submit showing a sample implementation of Phase I soon.
I hope this proposal meets what other people are looking for in
logging for svnserve. If not, please chime in with your two cents.
Any comments, suggestions, concerns are welcome.
- Brian Holmes
IRC: holmesbj
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 13 02:34:56 2005