Rudder

I just installed a fresh version of Rudder 2.8.0 on CentOS 6. The installation reported completing succesfully, but I could not access the webapp, and after some investigating, I found that httpd was not running.

Here is an extract from the install logs:

  Installing : 1398866025:rudder-webapp-2.8.0.release-1.EL.6.noarch                                                                                               66/72 
INFO: Setting Apache HTTPd as a boot service... Done
INFO: Restrating syslog... Done
INFO: Stopping Apache HTTPd... Done
INFO: No usable SSL certificate detected for Rudder HTTP/S support, generating one automatically... Done
INFO: Starting Apache HTTPd...INFO: Launching script to check if a migration is needed

(on a side note: the "echo " Done" line is missing after the apache start)

Running "/sbin/service httpd start" manually, I see this:

[vagrant@server ~]$ sudo /sbin/service httpd start
Starting httpd: Syntax error on line 30 of /etc/httpd/conf.d/rudder-vhost-ssl.conf:
SSLCertificateFile: file '/opt/rudder/etc/ssl/rudder-webapp.crt' does not exist or is empty
                                                           [FAILED]

This is true:

[vagrant@server ~]$ ls /opt/rudder/etc/ssl/
rudder-webapp.key

When I remove everything under /opt/rudder/etc/ssl, and try to run the key and crt generation command manually, I get this:

[vagrant@server ~]$ sudo openssl req -new -x509 -newkey rsa:2048 -subj "/CN=$(hostname --fqdn)/" -keyout /opt/rudder/etc/ssl/rudder-webapp.key -out /opt/rudder/etc/ssl/rudder-webapp.crt -days 1460 -nodes -sha256
Generating a 2048 bit RSA private key
......................................................................+++
.........+++
writing new private key to '/opt/rudder/etc/ssl/rudder-webapp.key'
-----
problems making Certificate Request
140679770867528:error:0D07A097:asn1 encoding routines:ASN1_mbstring_ncopy:string too long:a_mbstr.c:154:maxsize=64
[vagrant@server ~]$ echo $?
1

I figured out that this comes from my hostname being too long, which is used as the certificate's CN:

[vagrant@server ~]$ hostname --fqdn
server.rudder.local.rudder.local.rudder.local.rudder.local.rudder.local.rudder.local

(on a side note, this is a bug in the rudder-vagrant provisioning scripts, that appends "rudder.local" onto the hostname even if it's already there)

Nothing warned me about this during the install process, even though the openssl command returned a non-zero code.

From https://fedoraproject.org/wiki/Packaging:ScriptletSnippets, I see:

rpm in its default configuration does not at the moment execute shell scriptlets with the -e argument to the shell

So, all of our post/pre inst/uninst scripts have been written in the assumption that, like Debian packaging, if anything goes wrong (ie returns non-zero), the package manager will complain and alert the user. This is not the case, and our RPM packages end up being installed, errors happen, but the user gets told "Success". This is bad.

I'm not sure how to proceed, I see several options:

1. We add "set -e" to all our post/pre in/unin scripts in the .spec files. This will cause the package installation to fail and the user will be alerted. It seems like a quick and easy solution to implement, although if we decide to go with it, I think we should only make this change in 2.8.x, not in older versions, because this may break something (we may have some commands failing, but that don't matter). However, I wonder if this approach doesn't go against "the RPM way". I know that in the Debian world, it is common to tell apt-get/aptitude to "try again with configuring that package", but I've never heard of this in the RPM world...
2. We add detection to anything important, as in "do_stuff || "Failed to do_stuff, OMG, you should totally check the docs now and fix this yourself!". I don't like this solution as much, because it would be complicated and error-prone to implement, and doesn't really fix the problem. But it may be more the "RPM way".
3. Can't think of any other approaches for now.

Thoughts?