Admin logging SoC project requirements
Gerald (Jerry) Carter
jerry at samba.org
Tue May 30 03:07:27 GMT 2006
-----BEGIN PGP SIGNED MESSAGE-----
Michael Krax wrote:
> I have a little bit trouble locating the spots where
> to place calls to admin_log().
> Canidates in the second case are (ordered from lowest
> to highest level, as far as I understand it):
> * add_smbfilepwd_entry() in pdb_smbpasswd.c (and
> equivalents in the other backends)
> * smbpasswd_add_sam_account() in pdb_smbpasswd.c
> and all the other backends
> * pdb_add_sam_account() in pdb_interface.c (what about
> * in the admin block in _samr_create_user() in srv_samr_nt.c
> *and* in local_password_change() in passdb.c
The trick is to catch events at the lowest common
denominator so there is only one code path to maintain.
For user's this would probably be in pdb_add_sam_account().
The RAP and RPC code paths think down to here.
> So we keep this in mind, I do start with the
> "user-added"- and the "machine-account-invalid" type
> of events; if there is time I'd like looking into
> auditing, too.
That's fine. But for the success of the SoC based
project, I think only the plumbing and logging a minimum
number of admin events (to verify functionality)
> Apparently the eventlog framework Marcin Porwit worked upon
> is now in Samba3. Integration with it would be (for now) by
> way of syslog, ie.:
Yes. See the HOWTO at http://wiki.samba.org/index.php/Event_Logging.
Centeris sets this up for you via their Likewise console.
You can download betas from www.centeris.com if you want to
avoid the initial hassle of setting Eventlogging up for yourself.
> admin_log() -> writes to syslog (or whatever configured) -> syslog (or
> other backend storage) is parsed and "eventlogadm" is called
> (as in http://www.samba.org/~jerry/Samba-EventLog-HOWTO.txt)
> # tail -f /var/log/messages |\
> my_program_to_parse_into_eventlog_records |\
> eventlogadm SyslogLinux
> Later on, there should be direct support for eventlog in adminlog.
This is a bit of a philosophical issue. If the admin log
interface writes directly to the eventlog tdbs then those
eventlogs are not long strictly caches of logs stored elsewhere.
I prefer personally to log via syslogd and have some script
import the data from there into the tdbs.
> Reading your example about the missing DC credentials
> I noticed that you were also providing some hints to
> the admin how to solve the problem. I'm not quite sure
> if the admin log should provide such information. But:
> A solution could be to provide an external collection
> with (more or less) detailed information on a certain
> error. In that case, we need a unique id for every
> logging event (my example does not do this yet).
That was my next suggestion. Unique event IDs are a must
in either case I think.
> So there are two different prototypes for the admin_log function (please
> ignore the different parameters in the sample patch, it was a first try):
> void admin_log(int eventType, /* determines the syslog facility */
> int priority, /* as in syslog(...) */
> const char *format_str, ...);
> eventType corresponds to something like ADMIN_LOG_TYPE_AUTH,
> ADMIN_LOG_TYPE_PRINT... We could pass all *AUTH messages to syslog
> facility AUTHPRIV, all others to SYSLOG (that's what I mean with
> void admin_log(int uniqueEventId, const char *format_str, ...);
> /* uniqueEventId references an array containing all the other
> information (eventType, priority etc.) necessary */
> A compromise between the two options would be to join the argument list
> so that we do not need a uniqueEventId but can provide one.
These look pretty good. I think it is a good idea to
combine the two prototypes though. Couple of questions.
* Should we all an admin to turn off a class of eventTypes
(log auth but not printing)? I'm inclined to always log.
* I think we need both event type and ID (perhaps as bit
masks on how NTSTATUS codes are done in win32).
* I don't really think that we need to use multiple syslog
facilities. I could be persuaded otherwise but I'm more
inclined to use LOCAL_7 or something. The reason is there
is not always a one-to-one mapping between our event type
and a syslog facility.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the samba-technical