Re: [utah-devel] rsyslog and utah
On 02/20/2013 09:06 AM, Andy Doan wrote:
On 02/20/2013 02:51 AM, Jean-Baptiste Lallement wrote:
On 02/20/2013 05:17 AM, 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'm curious to know what doesn't work exactly with remote syslog and
debian-installer based installation (server images)? I haven't found a
single bug in Debian and Ubuntu about remote logging not working during
installation.
Sounds like its probably user error on my part. I've got to look more
into some desktop stuff today, but will try and dig into this soon.
Thanks for calling me out! It came down to a subtle typo in code:
if 'log_port' not in self.cmdline:
option = 'log_post={}'.format(self.rsyslog.port)
self.logger.info('Adding {} option for rsyslog'
.format(option))
self.cmdline += ' ' + option
note the "log_post" in the code that sets the cmdline argument :)
--
Ubuntu-utah-devel mailing list
Ubuntu-utah-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-utah-devel
Re: [utah-devel] rsyslog and utah
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 > > 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 > -- Ubuntu-utah-devel mailing list Ubuntu-utah-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-utah-devel
Re: [utah-devel] rsyslog and utah
On 02/20/2013 02:51 AM, Jean-Baptiste Lallement wrote: On 02/20/2013 05:17 AM, 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'm curious to know what doesn't work exactly with remote syslog and debian-installer based installation (server images)? I haven't found a single bug in Debian and Ubuntu about remote logging not working during installation. Sounds like its probably user error on my part. I've got to look more into some desktop stuff today, but will try and dig into this soon. -- Ubuntu-utah-devel mailing list Ubuntu-utah-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-utah-devel
Re: [utah-devel] rsyslog and utah
Hey Andy, On 02/20/2013 05:17 AM, 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'm curious to know what doesn't work exactly with remote syslog and debian-installer based installation (server images)? I haven't found a single bug in Debian and Ubuntu about remote logging not working during installation. 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 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 That won't work on ubiquity based installations because of LP #882147 ( overlayfs does not implement inotify interfaces correctly) You'll have to use busybox tail instead which uses polling instead of inotify. 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. thoughts? I think you should first figure why a standard remote logging facility like rsyslog doesn't work before adding more complexity (and as a consequence more development time, more maintenance and less reliability) to UTAH. 1: https://code.launchpad.net/~nuclearbob/utah/rsyslog -- Jean-Baptiste IRC: jibel -- Ubuntu-utah-devel mailing list Ubuntu-utah-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-utah-devel
