Rudder

Jonathan CLARKE wrote:

It seems to me that our only option here is to use a different port number for rsyslog on Ubuntu (and possibly other OSes if they start using the same approach...), and configure Rudder to read the port number from a variable and update node's configurations accordingly. This is possible, since the configs are read via CFEngine, so will still be updated even if no reports are ever received.

Do you think this would be an appropriate solution? Any opinions on this from the dev team?

This would definitely work, yes.

In the meantime I've disabled $PrivDropToUser syslog and $PrivDropToGroup syslog lines from /etc/rsyslog.conf to keep rsyslog running as root and it worked too. This is probably less secure though, so whichever you think is more appropriate.

Thanks for looking into this!

Jonathan CLARKE wrote:

Michael,

Thank you very much for this bug report and the analysis you have done. This is an unfortunate bug...

It seems to me that our only option here is to use a different port number for rsyslog on Ubuntu (and possibly other OSes if they start using the same approach...), and configure Rudder to read the port number from a variable and update node's configurations accordingly. This is possible, since the configs are read via CFEngine, so will still be updated even if no reports are ever received.

Do you think this would be an appropriate solution? Any opinions on this from the dev team?

Jon, I'm not sure about the implementation.
Should we use a variable in rudder-web.properties which define a port number of syslog ? This imply that the port could be modified easily and not automatically.

After a discussion with Nicolas P., it seems that the work to do is more at CF-Clerk and Rudder Scala level than in init promises:

- 1/ we have to define a new system variable, "rsyslog port";
- 2/ we have to read its value from somewhere
- 3/ finally, we have to modify promises so that they use that system variable (that the only point related to cfengine).

For 2/, we believe that the simplest and more futur-proof solution is to simply have a property in Rudder configuration.properties file for that port, defaulted to default Rsyslog port, and with a comment specifying to value to set to be compliant with Ubuntu default choice.
In that case, an other task will be to add to migration scripts that new parameter.

Jon, what do you think about that ?

A first attempt could be this:

• Create a new property : rudder.syslog.port=514 (which could be modified manually of automatically by packaging [Thank Vincent for the idea])
• Usage of a system variable (like SYSLOGPORT) from Rudder which value is set from the property above
  • Add the new system variable in the metadata.xml of common and distributePolicy
  • Change every occurrence of syslog port by this system variable in the Techniques
• Pray for the sake of Rudder

François ARMAND wrote:

A new system variable is available, with name "SYSLOGPORT".
It takes its value from the configuration.properties file, from the "rudder.syslog.port" parameter.

Nico, I reassign that task to you to finish the techniques and packaging stuff.

Thanks !
Could you document the way you use to add a new variable, please ? Somewhere like dev part in foskwiki ?

• The CHECK_DIST can be done more easily using the "-s" option to lsb_release
• If you use lsb_release, you should depend on it
• The regexps for reading the existing value in rudder-web.properties and updating it were not flexible enough: you could have spaces around the "=" sign, they have to be included in the regexps
• The filename for rudder-web.properties was wrong (/tmp/rudder-web.properties)
• The check doesn't have to be "==5514", just "! <1024"
• The description text for the variable added to rudder-web.properties was not up to date

• There were some missing ";" in the CFEngine code!
• The regexp to read from the rudder-web.properties file was again too precise, not flexible enough
• Some comments would have helped
• Our convention is to always have promise types in the same order as normal ordering

Commiting a fix now.

Jonathan CLARKE wrote:

I've reviewed the packaging side of this, and commited a few changes:

• The CHECK_DIST can be done more easily using the "-s" option to lsb_release
• If you use lsb_release, you should depend on it

On the same subject, we shouldn't just check for Ubuntu 12.04, but for Ubuntu >= 12.04. Fixing.