Project

General

Profile

Actions

Feature #501

closed

Lavoisier WebService imrovments (Jan Kundrat)

Added by Lequeux Olivier about 14 years ago. Updated over 12 years ago.

Status:
Rejected
Priority:
Low
Assigned To:
-
Category:
Others
Target version:
Start date:
03/25/2010
Due date:
% Done:

0%

Estimated time:
15.00 h
Model:
Est. resolution:
Story points-Velocity based estimate-

Description

Dear colleagues,
I'm trying to deploy the operations portal in preparations of the EGI
migration in the Czech republic. I'm following the guide listed at [1].
The target box is running fully updated 64bit Scientific Linux 5.4.

I've had the following issues with the installation. Some of them are
rather cosmetic and are probably to be expected at this phase of
development. All issues are related to Lavoisier, as I wasn't able to
get it working at all.

- The tarball installs everything with 0777 permissions
- Using `pidof java` when checking for lavoisier is probably
unfortunate, as it's a rather generic process name
- `pidof` is located in /sbin/, and therefore not in default $PATH for
non-root users
- The support for "daemonization" (or running as a service) leaves much
to be desired, basically it seems to me that it expects to be left
running under screen or something similar (I'm just guessing that based
on the fact that I keep getting exceptions & backtraces in my shell)
- The documentation suggests that one can pick a different installation
path than /opt/lavoisier by means of $LAVOISIER_HOME, yet this variable
is not respected by scripts in bin/ at all (I did use the
/opt/lavoisier, I'm just reporting that I'd be facing even more troubles
if I did not pick the standard installation path)

All of the above does not, strictly speaking, affect the usability of
the software. However, the problem I'm facing is that I do not see
anything usable in the web interfaces [2] (the link points to our
instance which is having troubles), and the log4j is full of exceptions.
I'm not familiar with Lavoisier's code, so I'd be grateful for any hints
or pointers about what to do and how to debug the problem.

Actions #1

Updated by L'Orphelin Cyril over 13 years ago

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

Actions #2

Updated by L'Orphelin Cyril about 13 years ago

  • Target version set to SAND BOX
  • Estimated time set to 15.00 h

related to Lavoisier 2.0 migration

Actions #3

Updated by Veyre Pierre over 12 years ago

  • Status changed from New to Rejected
Actions

Also available in: Atom PDF