[utah-devel] rsyslog and utah

[Daniel Manrique]

On 13-02-19 11:17 PM, Andy Doan wrote:
> As you know, I've been playing with the rsylog branch[1] by adding some
> live logging of the installation. However, I may have hit a bump in the
> road when testing server images. The server install runs from a busybox
> shell which includes a simplified "logger" implementation that doesn't
> seem to work with rsyslog.

I may be wrong here, since server installations *may* have changed, but when
implementing this for checkbox-satellite, we found that d-i's handling of remote
syslogging was pretty good, it supports the log_host and log_port kernel
commandline parameters out of the box; rather, we had to do work to add support
for that to casper for desktop installations (ask Max, I discussed this with him).

> 
> I don't know all the permutations of installers we have to support, but
> I'm starting to wonder if assuming an installer will have a properly
> functioning rsylog'er is feasible?

This may not be the case for QA, but the two main versions of the installer we
had to consider were d-i (for server and alternate images) and casper/ubiquity
(for desktop). For casper-based installers (I *think* the *ubuntu flavors use
this but I may be mistaken) the remote implementation used on checkbox-satellite
should work out of the box.

> 
> This issue coupled with the fact I haven't been that excited about
> dealing with rsyslogd (it seems like it can finicky at times). Has me
> wondering: Do we need something different.
> 
> Since I'm new, you might be able to stop me here with a "don't worry".
> If I'm not crazy, then its time to talk solutions. I'll pitch an idea
> and see what you think:
> 
> We make 3 assumptions:
>  1) target has network
>  2) target supports "tail -f"
>  3) target includes netcat "nc".
> 
> With those assumptions you could basically spawn something like:
> 
>  tail -f /var/log/syslog | nc <host> <port>
> 
> somewhere early in the install (I think there's some type of preseed
> support for this).
> 
> Then you create some minmial twisted lineReceiver service when UTAH is
> run that listens on an ephemeral port and processes these messages from
> the target.

On the server-side this sounds a lot like what we did with checkbox-satellite,
we have a monitor_syslog script that uses nc to listen on a udp port (which the
client is configured to log to), and exits with useful codes when it sees stuff
happen (like messages indicating the install was finished) or *not* happen (i.e.
if it doesn't see the finished install in 15 minutes or so). It also logs all
this to a local file for later perusal.

But really, client-side, the existing implementations were robust enough that we
just implemented this and we haven't had to fix this in well over a year.

> 
> thoughts?
> 
> 1: https://code.launchpad.net/~nuclearbob/utah/rsyslog
>