Closed 389-ds-bot closed 4 years ago
389-ds-bot
commented
4 years ago Comment from mreynolds (@mreynolds389) at 2019-02-06 15:37:54
I'm not sure how to respond to the angry and disrespectful tickets you just opened.
If you just want an option to not start the server after the install just say so. Btw, this is exactly how the old perl installer worked (so why are you only upset about this now?).
389-ds-bot
commented
4 years ago Comment from mreynolds (@mreynolds389) at 2019-02-06 15:37:54
Metadata Update from @mreynolds389:
389-ds-bot
commented
4 years ago Comment from johannbg at 2019-02-06 16:53:29
I'm not angry nor upset, this is just how I communicate, being subtle is not in my nature and I got a poor taste in humour.
How sensitive or not people are to that is well their problem.
Anyway looking into this, is it not correct understanding that you always need to run dscreate before starting an instance for the first time?
If that's the case an massively clean up on the type unit files ( and the associated EnvironmentFiles ) and get rid of that /etc/sysconfig dependency in dirsrv?
Btw why was it rewritten in python?
389-ds-bot
commented
4 years ago Comment from johannbg at 2019-02-06 17:17:04
Give that I'm an over thinker and usually years ahead of normal people thought process I probably and have a poor way of communicating I should clarify what the deal is with /etc/sysconfig
The thing is that packagers often misunderstand that unit files are subject to admin configuration and should be treated as such, and that spliting out configuration of unit files into separate EnvironmentFiles= is a really non-sensical game of unnecessary indirection and just invites packagers to reintroduce the /etc/default/ and /etc/sysconfig/ madness that is being tried to be removed on the core/baseOS level.
So what I meant by "Anyway looking into this, is it not correct understanding that you always need to run dscreate before starting an instance for the first time?"
Is that if dscreate is required before each instance run everytime it could ( potentially ) if it made sense to generate the type service file for the instance then and there.
I'm just trying to remember why things ended like they are when I took that ca ~900 lines of scripted mess and converted it to what is the bases for what you ship today in the unit files. Were there was some gotcha that Rich pointed out?
Is Rich Meggins no longer with the project?
389-ds-bot
commented
4 years ago Comment from mreynolds (@mreynolds389) at 2019-02-06 17:50:27
I'm not angry nor upset, this is just how I communicate, being subtle is not in my nature and I got a poor taste in humour.
Since we didn't know you we were not familiar with your sense of humour.
How sensitive or not people are to that is well their problem.
Fair enough, but so is the response that you get from us ;-)
Anyway looking into this, is it not correct understanding that you always need to run dscreate before starting an instance for the first time?
Perhaps you are used to openldap (which works very differently than 389 DS)? In 389 Directory Server you must first create an instance before you can do anything with it. You do not get an "instance" by just installing the rpm. This is how it's always been in 389 ds ( and going back to Netscape DS, Sun DS, ODSEE, etc).
If that's the case an massively clean up on the type unit files ( and the associated EnvironmentFiles ) and get rid of that /etc/sysconfig dependency in dirsrv?
Well I did not design or implement the systemd side of things so I really can not comment on this except that no one has had a problem with it for the last 7 years. And yes we are changing to drop in files very soon but we haven't gotten there yet (only so many engineers and hours in the day). However, we do accept code contributions and pull-requests ;-)
Btw why was it rewritten in python?
Because perl sucks :-) I think there was an issue related to RHEL and shipping perl which is what started our move away from perl years ago, but I don't recall those details any more. Either way we are completely moving away from perl. In Fedora 30 all the perl tools, and the old java console are deprecated, and in Fedora 31 we will no longer offer the legacy tools package or the standalone java console. And as you also noticed we are currently developing (it's not done yet) a new web based UI using the Fedora/RHEL web console (aka cockpit).
Seriously I am sorry you do not like the direction we are taking with the product, but the overall response to these changes has been well received by the open source community and our customers.
Anyway, getting back to the ticket... we will look into adding these options to the installer (I see no reason not to implement them).
389-ds-bot
commented
4 years ago Comment from johannbg at 2019-02-06 18:14:07
Clean ups are necessary perl is no exception and anything java related is just gods gift of going away.
I have already started to look at the type unit files amongst other things to clean up here and given what I learned when handling the legacy sys v to systemd migration in the distribution ( Fedora ) and spent years doing so I'm very familiar with the attitude if want something done you have to do it yourself.
As long as cockpit/freeipa is not a requisite for running 389ds as an directory server I dont mind but if the project has become depended on cockpit and or freeipa for operating as such then it's time that you simple decide to integrated/merge it into the freeipa/cockpit product.
If this is not dependent ( or heading that way ) on freeipa/cockpit product, presumably that I submit structure to support mkosi in the git root as well as prep the site web side for readthedoc instance which will contain document structure without any reference to Red Hat's own document which at a whim of some manager might get closed whenever right or is that a touchy subject?
389-ds-bot
commented
4 years ago Comment from firstyear (@Firstyear) at 2019-02-07 00:25:55
@johannbg I would like to start by drawing your attention to the fact that in this project we follow the Fedora Code of Conduct. We believe in respectful discussion and debate, without insults of any persons.
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
How sensitive or not people are to that is well their problem. Give that I'm an over thinker and usually years ahead of normal people thought process I probably and have a poor way of communicating I should clarify what the deal is with /etc/sysconfig
I will state clearly - this is not a reason or excuse for bad behavior, and it will not be tolerated in the future.
I am also probably the primary author of the "python junk" as you call it, so I find this reference rather insulting given that this has been literally years of my time, effort and work, and plenty of time from the rest of the team, to make this work as reliably as it does today. If you have a legitimate issue with it's behavior we would like to know, in a professional and clear manner.
I also did most of the systemd integration work, and there are good reasons for how it was done. If you want to know, ask on the mailing list rather than opening tickets please.
So I will make a few project things here clear.
Next, let's talk about project direction. Others in the team know this already, but I have been pushing for a "just works" attitude. We autotune, have secure defaults, and even dynamically generate certs on install. So this idea of "there are other tasks" is kind of being replaced by us trying to get as much right on your behalf as possible. We have been trying to pay attention to proper user experience and psychological design and interaction principles. We can not remain stagnant in a market of change. 389 to me, will become the easiest to use, feature rich, and most secure LDAP product on the market.
With that out of the way ....
Now, you specifically seem to be angry about the issues of how the lib389 start up works. This looks like an issue with your ./configure, where you have stated "--with-systemd", and lib389 attempts to use the systemctl command even though it is apparently not present.
This is absolutely a bug, and one that I plan to resolve in my container work (which also doesn't have systemd present). Today, this is already fixed in "container" mode, but you should not use this unless you are actually making a docker image. This will be resolved as part of #3256 which you have already commented on.
Finally, you have not disclosed your distro version, arch or further, which would help in analysing this issue.
Thanks,
// edit: add link to coc
389-ds-bot
commented
4 years ago Comment from johannbg at 2019-02-07 11:05:54
"I also did most of the systemd integration work, and there are good reasons for how it was done. "
Fyi I'm the one that did the heavy lifting of the systemd integration work for 389ds as for majority of all legacy sysv init components shipped in Fedora, after all I was the one that ran the sysv to systemd migration in the project and it take my work very seriously unlike majority of other feature owners in the fedora project who left things half implement, half integrated yet claimed to be 100% feature complete.
In my free time literally spent days going through those ca 800 - 900 lines of scripted mess legacy sysv init script for 389ds was and converted that into the unit files, an work that I worked together with Rich Megginson ( # 695736 ).
Now you might at some point taken that converted work and added few lines to those what 10 - or 12 lines the unit files on average are and or adapted and or integrated into further into the project but plz spare me the hypocritical emotional drama, acting like you are taking offence and residing CoC and what when you cant even give credit where credit is due...
"Finally, you have not disclosed your distro version, arch or further, which would help in analysing this issue."
If you would not have let your emotion get the best of you and read the report you would have noticed
dscreate from-file /tmp/389ds-test.inf
Is the command that triggers this
And
Package Version and Platform 389-ds-base-1.4.0.21-1.fc29.x86_64
Which clearly show release version, archictecture and platform
And just one example the projects vision you describe "dynamically generate certs" which presumably is self signed certs which are being generated "on behalf of the administrator" is working against the industry, which in turn is making things worse not better....
389-ds-bot
commented
4 years ago Comment from firstyear (@Firstyear) at 2019-02-08 00:44:50
In my free time literally spent days going through those ca 800 - 900 lines of scripted mess legacy sysv init script for 389ds was and converted that into the unit files, an work that I worked together with Rich Megginson ( # 695736 ). Now you might at some point taken that converted work and added few lines to those what 10 - or 12 lines the unit files on average are and or adapted and or integrated into further into the project but plz spare me the hypocritical emotional drama, acting like you are taking offence and residing CoC and what when you cant even give credit where credit is due...
I am not here to compare "lines of code" or "who did more". You can examine the git log if you wish.
Your actions are not displaying a level of individual respect or professionalism expected by this project or the Code of Conduct. This is not "hypocritical emotional drama" or "acting". I have been contacted by multiple people privately about your conduct on this and other issues. These people are uncomfortable and upset with your use of insults, demeaning comments, hostile criticism (instead of constructive criticism) and disrespect of the team - the team of the project whom I consider to be friends.
I am closing this issue, as it will soon be resolved in another ticket, and because I will not accept this style of behavior in this project. I will ask you to reconsider how you are speaking and acting in these matters before you comment on this project again in the future.
389-ds-bot
commented
4 years ago Comment from firstyear (@Firstyear) at 2019-02-08 00:44:50
Metadata Update from @Firstyear:
389-ds-bot
commented
4 years ago Comment from johannbg at 2019-02-08 06:18:58
Interesting response which can be acted upon in anycase which other ticket is this issue being resolved in? ( this is unrelated to 49875 )
389-ds-bot
commented
4 years ago Comment from firstyear (@Firstyear) at 2019-02-08 06:26:05
389-ds-bot
commented
4 years ago Comment from firstyear (@Firstyear) at 2019-02-08 06:27:01
389-ds-bot
commented
4 years ago Comment from johannbg at 2019-02-08 06:49:53
I'll have a look, Thanks for working on this.
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/50204
Issue Description
This is spectacular nonsense that the command starts and enables the 389ds after run o_O does dscreate perhaps punch holes in the firewall for the administrator as well ( probably using the firewall bloat that Tim wrote instead of creating nftable snippet ) and wipe the devops cloud administrators ass on the outhouse since those kids are incapable of doing that themselves these days ;)
Becoming an lazy administrator in our field is something to strive for and takes years of fuckups, re-implementing infrastructures and requires administrators to actually know their applications and applications stacks before they can sit on the pub all day and play golf day.
That new-found python junk ( what happened to the good old perl stuff? ) should be rewritten to be default off and --start --enabled be added for administrators having to use should they choose to immediately want to start enable this. ( there are other activities that need to be done before starting enabling this like, creating certificates adding ldif, perhaps tune the directory server etc. )
Starting installation... /usr/lib/systemd/system/dirsrv@.service:16: .include directives are deprecated, and support for them will be removed in a future version of systemd. Please use drop-in files instead. <--- yeah how about that... Created symlink /etc/systemd/system/multi-user.target.wants/dirsrv@localhost.service → /usr/lib/systemd/system/dirsrv@.service. System has not been booted with systemd as init system (PID 1). Can't operate. Failed to connect to bus: Host is down System has not been booted with systemd as init system (PID 1). Can't operate. Failed to connect to bus: Host is down Error: Command '['systemctl', 'start', 'dirsrv@localhost']' returned non-zero exit status 1.
Package Version and Platform
389-ds-base-1.4.0.21-1.fc29.x86_64
Steps to reproduce
Actual results
It tries to start enable the directory server as opposed to simply configure it...
Expected results
Sane command that does not start/enable the service when run atleast if not asked too..