On Mon, Sep 24, 2012 at 2:53 PM, Chiradeep Vittal <chiradeep.vit...@citrix.com> wrote: > > > On 9/21/12 8:37 PM, "Chip Childers" <chip.child...@sungard.com> wrote: > >>On Sep 21, 2012, at 8:59 PM, Chiradeep Vittal >><chiradeep.vit...@citrix.com> wrote: >> >>> >>> I am unable to resolve >>> https://issues.apache.org/jira/browse/CLOUDSTACK-147. >>> Perhaps we need a cleanroom implementation or an exception. >>> CLOUDSTACK-147 is the only one in "Unresolved" state >>> >>> Cheers >>> -- >>> Chiradeep >>> >>> >>> >> >>Wow, this is fantastic news! >> >>Yes, thee RAT stuff probably needs to be adjusted a bit (which I'll >>happily own). We also need to do the licensing stuff for the files >>originally included from other projects (again, I'm more than willing >>to get that done early next week). >> >>For that unresolved issue, perhaps we can try what Joe did for >>CLOUDSTACK-146? Does someone want to try and track down the orig >>developer? If not, this is a specific item that we can ask for an >>exception on from the legal folks. >> >>-chip > > There is no "original developer", it is a delta from the stock Debian > config.
By "original developer", I meant that we could go to the source project for the file itself and ask what claims they believe they have on the file (and / or willingness to change). Does it make sense to try that? > > I can reduce rsyslog.conf to the following 10-line delta from the stock > Debian rsyslog.conf > 16,17c16,17 > > < #$ModLoad imudp > < #$UDPServerRun 514 > --- >> $ModLoad imudp >> $UDPServerRun 3914 > 57,58c57,58 > < *.*;auth,authpriv.none -/var/log/syslog > < #cron.* /var/log/cron.log > --- >> #*.*;auth,authpriv.none -/var/log/syslog >> cron.* /var/log/cron.log > 79a80,81 >> >> local0.* -/var/log/haproxy.log > 83,85c85,87 > < *.=debug;\ > < auth,authpriv.none;\ > < news.none;mail.none -/var/log/debug > --- >> #*.=debug;\ >> # auth,authpriv.none;\ >> # news.none;mail.none -/var/log/debug > 89c91,92 > < mail,news.none -/var/log/messages > --- >> local0.none;\ >> mail.none,news.none -/var/log/messages > > > I can replace the rsyslog.conf in the source repo with this patch. > But we need a way to recreate the needed rsyslog.conf from whatever is in > the system vm at runtime. > > Perhaps that is a different bug, one that is a non-blocker for 4.0. > But a fix would be needed for the next maintenance release or > whenever a release changes the config files. > > Let's say hypothetically that VPN software has a rare bug that > causes its logging to spin out of control. > As a stopgap, we release a fix to rsyslog.conf to stop it from logging to > disk. > Depending on whether it is a fresh virtual router or an already-patched > virtual router, the > patch needed for rsyslog.conf will be different. > > -- > Chiradeep > >
