Re: Centralized logging
> The main issue with remote logging is that your log messages could be > lost when destination is unreachable. I'll have a look into it. Using only base would be pleasant, but it's definitely not mandatory. As my project hasn't reached implementation I'll begin my evaluation on the drawing board to classify my data in aspects of authenticity and reliability. > You can also find syslog-ng in ports which have more bells and > whistles, such as SQL support and whatnot. Though syslog-ng would be interesting from a technological point of view, there is currently no sense in going "full extend" for a few machines. To both of you (@Chris & @Ben), thanks for you input. Very welcome. Best wishes, Fabian
Re: Centralized logging
he...@ezaquarii.com writes: > On 2021-04-24 22:50, li...@mailbox.org wrote: > > Do you have any best / bad practices at hand regarding OpenBSD and > > optionally the syslogd / tools it ships with? > > The main issue with remote logging is that your log messages could be > lost > when destination is unreachable. Neither syslog(3) nor the standard it implements makes any attempt to provide a facility in which log messages are guaranteed to be delivered and recorded reliably. There is no way for logging code to respond to errors which occurred in the logging system while submitting the log message as is the case with any other I/O. If that's a concern then logging may not be the appropriate solution. "The syslog() function shall send a message to an implementation-defined logging facility, which *MAY* log it in an implementation-defined system log ... (or a bunch of other optional things)" (emphasis added) > ... That said, there are some systems (as mentioned) which attempt to do so anyway which I've found to work pretty well on the whole. Matthew
Re: Centralized logging
On 2021-04-24 22:50, li...@mailbox.org wrote: Do you have any best / bad practices at hand regarding OpenBSD and optionally the syslogd / tools it ships with? The main issue with remote logging is that your log messages could be lost when destination is unreachable. Default syslogd(8) shipped with OpenBSD supports remote log destinations with mutual TLS authentication, but man page is somewhat silent about reliability. You can pipe all log entries to an external application tho, and leveraging whatever log dispatch mechanism you find suitable for your case. You can also find syslog-ng in ports which have more bells and whistles, such as SQL support and whatnot. The important part would be to enable disk buffering for outgoing log entries in case destination server is unreachable. Syslog-ng has such option: https://www.syslog-ng.com/technical-documents/doc/syslog-ng-open-source-edition/3.16/administration-guide/disk-buffer Cheers, Chris
Centralized logging
Good evening folks and sorry if I may am unintentionally generating noise on this list. This is my first attempt, so I hope everything is going well and according to plan. After setting up my first OpenBSD server the question arose as to what could be a good setup for a centralized log management. My point of origin is 3-4 servers, which should send (encrypted) log data to another more restricted place to rest. Do you have any best / bad practices at hand regarding OpenBSD and optionally the syslogd / tools it ships with? Best wishes & a great Sunday Fabian
Re: Centralized logging
>Do you have any best / bad practices at hand regarding OpenBSD and optionally >the syslogd / tools it ships with? Take a look at /etc/syslog.conf and syslog.conf(5). You said you have to deal with logs on several machines? The syslog utility can direct log messages to other machines; /etc/syslog.conf has some examples in the comments. Ben Raskin
