operations-portal-users

a list of issues and comments about the operations portal that I'd like
to talk about while in Lyon follows.

- The recommended installation procedure leaves Lavoisier running under
the root account. It's a standard security practice not to run various
services, especially ones that are network-accessible, under a dedicated
user account.

- Startup scripts rely on /sbin and /usr/sbin being in $PATH, which
usually isn't the case for non-root users.

- A check for Lavoisier's status should not be done with `pidof java`.
Such check matches any running JVM instance and not only those specific
to Lavoisier. A standard Unix way of doing such checks is to create a
PID file and check for the existence of a process with the matching PID.

- For security and maintenance reasons, it's much easier not to bundle
various JARs with the application, but to rely on a standard packages
from the Linux distribution.

- Furthermore, some of the bundled JARs contain binaries which refer to
shared libraries which are not part of the base RHEL5 installation
(graphviz) without specifying proper dependency. Binaries for Windows
are also provided, which is not needed on Linux.

- The `graphviz` binary is unpacked to a well-known location inside
/tmp, a behavior known as "insecure temporary file creation". Its
possible impact is being amplified by the Lavoisier's default
configuration to run as root.

- Exceptions from Lavoisier go to script's stderr instead of using a
standard syslog facility. This prevents using sites' centralized syslog
for monitoring of Lavoisier's health.

- There is no support for "daemonization", ie. no provided startup
scripts and traditional Unix-like service management. This means that
the service can't be easily started on machine bootup.

- It is unclear why certain issues were experienced during the
deployment in Prague. A common solution was to manually comment
out/modify parts of XSLT files, but it is not clear whether these issues
would be encountered again upon upgrade to future releases.

Additionally, I could use an explanation about which Nagios' output is
the portal currently processing -- the configuration explicitly points
to the central one, but according to your mail from September 8th, it
seems that it should be listening to the results from the regional one.

When would you prefer to have this conversation?

Looking forward to talking with you,
Jan