So it seems that 389ds project managed to get itself colonized by the freeipa/cockpit team within Red Hat and if things progress in this direction 389 ds becomes formerly known as directory server...

I'm not sure what this comment is meant to mean, and it does seem like it's meant to be a criticism? We chose cockpit because we didn't want to maintain an Admin framework ourselves due to lack of people-power in the team. There are certainly "Red Hat" specific issues in the project, and I have been working to highlight these to people so that we can progress past that point, but this is not one of them. Perhaps this is a better topic for the 389-devel list.

Anyway if you actually have some justifiable reason why /etc/sysconfig should be used other than "duh it's always been this way" or even know why and how historically /etc/sysconfig came to be this way in the first place I would love to hear it

I can think of three reasons, but that does not mean we should not change.

First, systemd uses the contents as it's environment, and this has been deployed for sometime.
Second, lib389 uses these files as the "instance present" marker, but arguably due to defaults.inf and the design of lib389 this could change.
The final and real issue is upgrades. It's really hard to do an upgrade where we can trust the results will "stick". We can't guarantee that rpm post scripts are run. We don't know if we were an os restored from a backup. We don't know if the admin has changed these contents.

So for Red Hat, I would say at this point, it could be impossible to change.

However, for any other distro, during ./configure, we could set the sysconfdir to /etc/dirsrv.d, and then lib389/389-ds would "just work".

So the content of this bug may simply be "allow changing initconfigdir in configure.ac".

PS: initconfigdir already checks for sysconfig, default, or "package name" if the first two aren't found. So I think it may already work.

The "cockpit" project colonized the server WG mailinglist in Fedora and is (mis)using for their own project's gain ( advertising their projects release announcement there, I dont know if Stephen put them up to it or not or they start doing so and from that's projects perspective thing such behaviour is acceptable ) so the project might have done so here as well. ( which is where this colonized reference comes from )

Anyway back to topic.

"First, systemd uses the contents as it's environment"

The entire systemd implementation needs to be reworked, it's Environment and or EnvironmentFile reference removed and the actual values put in the type unit files themselves ( or associated snippets like 20-limits or so for soft hard limits dropping directory etc ) and any reference to .include files removed and this needs to be done before RHEL 8 get's released if it's not too late already, otherwise those having to maintain 389ds in RHEL are in for a good surprise from a demanding paying customers.

"and this has been deployed for sometime."

This is no excuse as in you would be forced to never be able to change your project in an ever changing world and simply does not work in practice or in real life for that matter,which is why changes like this happen on a major updates either in components and in new distribution releases ( like RHEL ) .

"Second, lib389 uses these files as the "instance present" marker, but arguably due to defaults.inf and the design of lib389 this could change."

s/could/should/ change

"The final and real issue is upgrades. It's really hard to do an upgrade where we can trust the results will "stick". We can't guarantee that rpm post scripts are run. We don't know if we were an os restored from a backup. We don't know if the admin has changed these contents. "

Yup nothing is certain in this world except death and taxes which is why you need to have faith in
%postun
if [ "$1" = "1" ]; then
foo > /dev/null; true
fi

And have faith in administrators to deal with this ( that's what they are getting paid for ) and restrict those changes to RHEL 8 ( major upgrade ) or for this project, put it immediately in the 389ds release that will not be in RHEL 8 to ensure wide enough exposure to iron out any bugs for RHEL 9 ( one of Fedora's original purpose ).

"So for Red Hat, I would say at this point, it could be impossible to change."

Red Hat might have managed to shot projects entirely in the head with it's modularity as in projects might never be able to make "invasive changes" due to that, an attitude that does not work in an ever changing world ( and markets ) but the management must have consulted projects ( internally anyway ) and thought this through before start offering this as an solution to it's customer base.

"However, for any other distro, during ./configure, we could set the sysconfdir to /etc/dirsrv.d, and then lib389/389-ds would "just work"."

Probably should be a directory within the existing /etc/dirsrv directory otherwise it ends up confusing for users since these would be two similar directories as in

/etc/dirsrv
/etc/dirsrv.d

@johannbg, thanks for opening that ticket it is indeed important to get 389-ds opened to most of the distro/needs.

Your technical/strategy concerns about various projects/tech (cockpit, module, systemd...) gave me hard time to follow the core of the ticket that is to make 389-ds available on non systemd system.

@firstyear proposed a change in ./configure to set initconfig_dir accordingly to your need. Also ./configure contains switches (like for solaris/linux host) where initdir was set to systV initscripts. Would you check this file and see if options or which changes can help ?

@tbordaz

"Your technical/strategy concerns about various projects/tech (cockpit, module, systemd...) gave me hard time to follow the core of the ticket that is to make 389-ds available on non systemd system."

The core of this ticket is to make 389ds in Fedora/Red Hat stop using /etc/sysconfig directory altogether so the configuration option alone is not enough to make the required change but is a part of it.

The benefits of this change is that it will makes things more compatible and easier to maintain for systemd based distribution like arch,deban,fedora, opensuse. ( the more unification we can get done on the core/baseOS level the better it is for everyone )

In the linux ecosystem you limit your upstream project "support" on the number of uniq package mangers + the parent linux distribution shipping them ( which is why I mention just for example debian and not debian and ubuntu etc ) otherwise your project might end up having to support all of them ( All those ca 500 active ones )

What I gather ( please correct me if I'm wrong ) what's necessary scope for that change is the following.

The unit files need to be rewritten. ( which they need to be done anyway )
The lib389 needs to be looked at
The dscreate needs to be looked at
The configuration/build option for rpm package need to be changed
And the spec file needs to adjusted accordingly.

What me and @firstyear where discussing what was required to remove the dependency on /etc/sysconfig from a Red Hat maintenance perspective. ( with the biggest concern being the upgrade path in RHEL )

Back in the day this was not so much of a problem
Upstream made changes.
Those changes landed in Fedora ( Upstream first )
Those changes landed in $NEXT_RHEL_RELEASE ( so this change would land in RHEL 8 if possibly if not RHEL 9 )
Everyone happy.

Today things have become more complicated due to growing product portfolio from Red Hat resulting in upstream changes being prevented from entering Fedora as an result of that ( The whole chain is broken due to internal management problem within Red Hat, one of many btw ) which is my guess why @firstyear year is so hesitant to do this. ( He sounds more like a RHEL maintainer than an RH upstream developer, which makes him stuck between rock and a hard place.. )

@johannbg , thanks for those explanations.

The ticket https://pagure.io/389-ds-base/issue/49875 is under investigation. Does it address your request about the 'unit files to be rewritten' ?

The "cockpit" project colonized the server WG mailinglist in Fedora and is (mis)using for their own project's gain ( advertising their projects release announcement there, I dont know if Stephen put them up to it or not or they start doing so and from that's projects perspective thing such behaviour is acceptable ) so the project might have done so here as well. ( which is where this colonized reference comes from )

This statement is not appropriate.

The entire systemd implementation needs to be reworked, it's Environment and or EnvironmentFile reference removed and the actual values put in the type unit files themselves ( or associated snippets like 20-limits or so for soft hard limits dropping directory etc ) and any reference to .include files removed and this needs to be done before RHEL 8 get's released if it's not too late already, otherwise those having to maintain 389ds in RHEL are in for a good surprise from a demanding paying customers.

"Why"?

Yup nothing is certain in this world except death and taxes which is why you need to have faith in
%postun
if [ "$1" = "1" ]; then
foo > /dev/null; true
fi
And have faith in administrators to deal with this ( that's what they are getting paid for )

No. It's not possible to have faith in post scripts. It is also not possible to assume administrators will read your release notes in detail let alone follow them. I have been working on this project for some time now, and if I have learnt anything, it's that LDAP is horribly complex and overwhelming to people, and we can not expect people who are already over-worked and over-burden to do our busy work. If we are to do this, it will be with a migration script or tool that we can guarantee will absolutely be run.

Today things have become more complicated due to growing product portfolio from Red Hat resulting in upstream changes being prevented from entering Fedora as an result of that ( The whole chain is broken due to internal management problem within Red Hat, one of many btw ) which is my guess why @firstyear year is so hesitant to do this. ( He sounds more like a RHEL maintainer than an RH upstream developer, which makes him stuck between rock and a hard place.. )

I am not a Red Hat developer, nor am I associated with Red Hat in any capacity. I am an upstream developer of the 389 Project employed by SUSE Labs. However, I am applying a strong and liberal dose of empathy and experience as a former sys admin to the project in my responses.

Now, as @tbordaz has pointed out, these concerns are addressed in 49875 so I am closing this ticket.

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/3262

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.