Hai Rainer,
> > > command-line invocation would create a new "reboot session".
> > Rainer, I think your example isn't typical.
> > On most system, there is one "global" sender (syslogd on unix), which
> I agree. But it is a real one ;)
> Agreed - but we do not life in an *nix only world.
I just named Unix as an example. I'm sorry I a suggested Unix only:-)
The same aplies to other systems, like embedded systems.
> *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.
It can even be done on Windows! It's a design/architectural isuee!
Why not implement such a "sender" (a service, in Win32), and let applications
send "messages" to that service. This is possible!
About A year ago, I have seen such a tool. It was simple and easy.
It even "greped" the MS-eventque and converted them so syslog.
Then it is easy to upgrade to -sign!
> 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.
This, although even more off-topic, is not a Win only issue. Also on
Unix systems, there is a problem when you try to run several "syslogd
services".
Either you have 1, with a "open interface" that all applications
use. Or you have several --more-or-less central ones, each doing a
part of the job. The RFC doesn't forbit it. It just becomes more
complicated to operate (manage) those systems.
Seams to be time that Adiscon, KIWI and You should decide. Develop on
you own, and let the customers decide (read: get the trouble:-). Or
define an kind of Win-RFC on that internal interface. All
"application", than can use taht interface. And the customer can
select "the best central service". Or doesn't the Windows word work
that way:-)
> > 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 :)
Hope it helps
BTW, running a commandline tool is a Unix'm. It's not typical on
Windows! So find it hard to believe "it is real" :-)
--
ALbert Mietus
Send prive mail to: [EMAIL PROTECTED]
Send business mail to: [EMAIL PROTECTED]
Don't send spam mail!
