On 03/02/17 01:14, Emmanuel Lécharny wrote:
Le 02/02/2017 à 10:04, Brian Burch a écrit :
I have a stable 1.5.4 production directory and felt it was time to
upgrade to 2.0.0. All of my 1.5.4 customisation is done with shell
scripts and ldif files, which I track through source management.
I was dismayed when the server upgrade from ubuntu 14.04 LTS (which
does not have an apacheds package at all) to 16.04 LTS installed
apacheds 2.0.0-M15 and trashed my 1.5.4 installation. Luckily, I have
a lot of backups and could restore the environment quickly!
2.0.0-M15 is not even recent. It's 3 years old.
Oh yes, I was well aware of that fact soon after I discovered the
unwelcome "upgrade" to my system. I have no idea why the 16.04 upgrade
process decided to install apacheds in the first place, because my 1.5.4
system was built from source and implemented locally without a deb. I
had assumed it would only upgrade packages that were already installed,
but something more sneaky must have been involved!
I know this is a controversial topic with many open source projects.
Project developers have their preferred installation directory structure
and (for sensible problem determination reasons) want users to install
their versions. However, the various linux distributions have their own
preferred installation directory standards and (for equally sensible
reasons) prefer users to install their own versions of the packages.
I don't know why apacheds found its way into the ubuntu repositories for
16.04 and later (via debian), when it wasn't available in prior
releases. Someone put the work into repackaging M15 for debian/ubuntu
(and systemd), probably on a pre-release repository that subsequently
became production, probably because no-one complained that it didn't work...
I've seen this happen with other projects, too. I open bugs with a
bypass of "remove the ubuntu package and install the XXX version from
the project download page", which seems to keep most people happy.
Unfortunately, the bug usually stays open because the maintainer of the
distribution package doesn't find time to bring it up to date.
Having said all this, I REALLY NEED to integrate M23 (or subsequent)
with systemd because I have several critical services which use LDAP for
authentication and authorisation. The default systemd behaviour for
"bare" systemv scripts does not even honour the rather primitive systemv
intended startup ordering. I need a systemd service file that a) starts
the server, and b) defines the services that MUST NOT be started until
apacheds is running. (Lets not get sidetracked by the work I did with
1.5.4 to achieve this under upstart on ubuntu 14.04!)
Once I have successfully upgraded my production directory to M23, I'll
take a serious look at integrating it with systemd.
Lastly, I should say I am sympathetic and very grateful for those
volunteers who try to bridge the divide between project developers and
distribution management!
Best wishes,
Brian
