The fix for this has nothing to do with the provided functionality, it only makes the whole package better maintainable and also provides the possibility to distribute luci as a native Python package (it was originally aimed to be distributable only as RPM so it combined both Python [setuptools] and non-Python worlds [make, sed, install, ...]).
This should be partially fixed in http://git.fedorahosted.org/git/?p=luci.git;a=commit;h=5b78325596c716055c9c1e64bc4387d4d8fa3ba7 Note that this is only a first step in merging with pkg-update branch which contains more changes related to luci packaging, external files etc. so the rest of these changes will be filed as separated consequent bugs and commited of separated consequent patches.
I forgot to mention in the message for that commit another changes that have been made: - everything sounding like "lucipam" changed respectively to identifiers sounding like "sasl2auth" as the original term was a bit misleading (rationale: PAM mechanism presumably lies at the very backend of what this module uses -- it uses SASL2 library to connecte to saslauthd service and if this service is configured in expected way [which is the default on Fedora and RHEL 6], the PAM authentication will be used indirectly via this chain) - implicit patch added and included in the spec file, that ez_setup.py module is not used if setuptools Python package not present (rationale: while ez_setup can be convenient for people using native Python package directly [that's why this is kept in raw sources], it is not desired to have anything incl. setuptools ad-hoc downloaded and installed while preparing system package [setuptools is in BuildRequires anyway])
Another change not mentioned in the commit message: - self-managed certificate no longer stored as two separated files (public certificate itself [cacert.pem] and private key [privkey.pem]) + concatenation of them in the "combined" PEM file (host.pem) -- now only this "combined" file is stored and used which remains fully compatible with what luci uses wrt certificates - ssl.wrap_socket: supports this "combined" file at least since Python 2.6 for which this ability was documented first (but may work also for previous versions and this just hadn't been documented for them) - server (paste) seems to support only this "combined" file (as PEM) - to bring more light to the matter, this illustration was used in irc discussion: content(privkey.pem)=A, content(cacert.pem)=B, content(host.pem)=AB; using "wrap_socket(certfile=cacert.pem, keyfile=privkey.pem, ...)" is semantically equivalent to "wrap_socket(certfile=host.pem, ...)"
Another change not mentioned before: - COPYING licence file renewed with fresh version of GPLv2 as obtained using 'wget http://www.gnu.org/licenses/gpl-2.0.txt' (original version contained strange unprintable characters, a bit different address [presumably no longer actual], ...)
Commit http://git.fedorahosted.org/git/?p=luci.git;a=commit;h=1026ec43fed3f95bf8a2e902d696016e42c08b14 contains any remaining change from pkg-update and hence is finishing the whole sequence of bugs (see "blocks" field) and respective commits in order to move whole bunch of changes that were made first separately on pkg-update branch of upstream git repo. (This separation was used to isolate often rapid changes forth and back to stable master branch).
To test this, there are far too many little things that can be groupped into these classes: - ability to prepare correct RPM package - this has already been proved to work, but any problem with this (such as non-existing file declared in %files section in spec or a file completely missing in built RPM so the luci installed from it won't run) may still occur, but most of this would be reported by the build tools so no active testing necessary (beside the test whether installed luci will run) - files that are created during the first start of luci should be checked (in the phase luci is running) for their attributes and ownership, especially these: - /var/lib/luci/etc/luci.ini: rw-r----- luci luci - /var/lib/luci/data/luci.db: rw-r----- luci luci - /var/lib/luci/certs/host.pem: rw------- luci luci - /var/log/luci/luci.log: rw-r----- luci luci - /var/run/luci/cache: rwxr-x--- luci luci - /var/run/luci/sessions: rwxr-x--- luci luci On the whole, after installation from such a new RPM based on changes connected with this bug, luci is expected to have no issue with its start (especially this phase could fail for many reasons as this part was partially reworked) and stop (and also with its run, indeed).
Only a note if this bug is ever manipulated again (e.g. copying for RHEL), there was a small edit in setup.py with commit http://git.fedorahosted.org/git/?p=luci.git;a=commit;h=e432ade2757c0fab9ac4b9e2822c6e63f9897fd9 that should be considered as indivisible part of already stated fixes.