Hi, Topic#1:
On Windows, long-lived services, ala daemons on unix, are typically implemented as OS services. Not everybody does it this way, but I think a syslog exporter is likely to be handled this way. Topic#2: Since SNMPv3 has already been brought into the discussion, let me say that SNMPv3 applications can work with a daemon/os-service approach where multiple applications utilize a shared daemon so there is only one "engine" on a host, or it can work with each application being uniquely identified (see SNMPv3 engineID). It could also work with multiple uniquely identified daemons if that is desired. Those are implementation/deployment decisions. SNMPv3 uses shared key authentication, so if multiple applications run as unique entities, their key databases need to be updated independently of other applications; if a daemon is used, it is possible to have one key database that works for all the applications, making key distribution a bit easier. Of course, if multiple apps need to share a daemon, then there is the increased complexity of app synchronization of data, developing an API to the daemon, and API versioning must be handled, and so on. Topic#3: I think that to ensure replay protection, an SNMPv3 command line application should consider each restart as a reboot, and for those with daemon-style implementations, each restart of the daemon should probably be considered a reboot. I would recommend discussing this further with implementors of command line applications, such as those who work on the Net-SNMP distribution, or those who work on the SNMP Research products. Dbh David Harrington [EMAIL PROTECTED] co-chair, IETF SNMPv3 WG > -----Original Message----- > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 27, 2003 6:40 AM > To: Albert Mietus > Cc: [EMAIL PROTECTED]; Andrew Ross > Subject: RE: Reboot counter > > > First things first: I am convinced now that there is no > problem with the > reboot session id. I probably should have sone some quick math in the > first place. > > But still some comments... > > > > think about a tool like logger. As of my understanding, each > > > command-line invocation would create a new "reboot session". > > > > > > Rainer, I think your example isn't typical. > > I agree. But it is a real one ;) > > > > > On most system, there is one "global" sender (syslogd on > unix), which > > run's very long. Usually as long the system is up. It has > the counter. > > This sender get's it data from several sourcer (Applications using > > "syslog() call in libC; again a unix example). So "booting" an > > application, --read: you command line tool-- has no effect on the > > reboot counter. > > Agreed - but we do not life in an *nix only world. I am not sure if > homogenious systems would be better accepted if the only OS would be > *nix, but as of now we do have some others out. Look, we > (mainly, I can > say nowadays;)) implement on Windows. There is no such central sender. > We need to "boot" each application... > > > > > See below, for details of your example... > > But first, on "the central syslogd"; the RFC doesn't demand it, but > > assumes the is only 1 sender on each system. E.g. the > "private key" is > > shared by all signatures, so by all "sources". Hard to do when all > > applications are senders itself. > > If that is the case, we indeed have an issue here. Not a big > issue if a > single vendor's products run on the non-*nix box. But what if e.g. > Adiscon's EventReporter runs on the same system Kiwi's > syslogd runs... I > think there are ways to work this out, but I also think -sign can be > implemented to work around this. I think we do not absolutely > have only > one private key for the system. > > I am NOT arguing to change anything in -sign (at least yet). I am just > picking up the thought... > > > > > Back to your example. > > Even when quickly "rebooting" (read: increasing the reboot session > > counter fast), this should not be a problem. nine 9's is very big! > > My code uses the current-time, during initialisation, in > seconds after > > 2002 (syslog-sign didn't existed before) and divide by 2. > > > > This will result in a reboot-session, that will wrap in the year > > 2600 (or about). And which can be started each 2 seconds. > > > > You can find my code on SF.net, or see below for a C-code fragment: > > > > -------- > > GLOBAL int rebootSessionID = 0; > > > > int reboot_session_id(void) > > { > > if (rebootSessionID != 0) { > > if (gettimeofday(&now) != 0) > > rebootSessionID = 1 // it has to have a value > > else > > rebootSessionID= (now.tv_sec- ( (2002-1700) * 365 * > 3600) ) / 2 > > } > > return rebootSessionID; > > } > > ------ > > ... this is where I should have done some "advanced math" ;) OK, I am > guilty... > > > For a standalone commandline tool, you probably need more a bit more > > resolution. E.g. skip the "divide by 2". Most important is > that value > > is unique for that session, for that invocation of that commandline > > tool. If that means it will wrap in "only a few years", let it > > be. It's not typical to have short rebootsessions. It means > verifying > > the log, is hard to do anyhow !! Then is easy for delete > all log of a > > reboot session (for a hacker). That can't be verified. > > That is in fact an excellent point. So for my (unusual) command line > tool, I may be better of to use the day as reboot session id > and keep it > the same during all of the day. Of course, I could miss an > actual system > reboot, but I think that mapping would work fine for this bizzare > example. So I finally got my issue better solved than I asked for :) > > Thanks, > Rainer > > >
