Could you please use Oxford spelling here to include the rest of the world?

Why this was removed?

I would say that it would be better to use different name. Because it is not related to containers. It is related to privileges. By default, root has the NET_BIND_SERVICE capability and therefore it is possible to bind socket to privileged ports (< 1024).

So it depends how container was created and whether 389ds runs as root or as unprivileged user. But I can see that capability by default in my docker based container.

Maybe better name would be unprivileged.

Could you please use Oxford spelling here to include the rest of the world?

Line 31 also uses "containerised", so that should be changed too.

While I truly do see @lslebodn point, I feel the tool should be consistent with other existing usage in dscreate, and to continue to use "containerized" as we do in other sections. Having different option names that essentially do that same thing is confusing to me. Especially since we are being pushed hard towards container support, we should be catering to the container community. I think in real-world/production envs this would mostly be used in containers anyway. People installing DS as an unprivileged user, outside of a container, would most likely just be doing some testing/dev, and that seems like a corner case to me compared to the number of people using(or wanting to use) containers in production.

Perhaps the help text could be expanded to explain how it could be used in a non-container env? Just a thought - I'm not completely shutting down @lslebodn's point, but my point is that we should be consistent throughout the usage of dscreate (no matter what name we use).

I was not aware of using "containerized" on other places.
But it is really confusing.

You can run things in container as a root and the you are able to bind to the privileged port.

[root@host ~]# docker run -ti --rm docker.io/fedora:29 bash -c "id; capsh --print | grep cap_net_bind_service"
uid=0(root) gid=0(root) groups=0(root)
Current: = cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap+eip
Bounding set =cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap

Why this was removed?

Because when you think about it, if we make the config file gpl then any changes must be published as open source .... So really we should not have this. The copyright exists in the code, and the config just 'is'. It's not necessary.

I would say that it would be better to use different name. Because it is not related to containers. It is related to privileges. By default, root has the NET_BIND_SERVICE capability and therefore it is possible to bind socket to privileged ports (< 1024).
So it depends how container was created and whether 389ds runs as root or as unprivileged user. But I can see that capability by default in my docker based container.
Maybe better name would be unprivileged.

In a container we can't guarantee this privilege. As well, there is sysctls that can be tuned to alter these ports too. I think that you are right that we should say it's "lack of the priv OR ...". So I'll make the error message better.

Could you please use Oxford spelling here to include the rest of the world?

Just to nitpick, I think you mean "American", because the large parts of the rest of the world use British English ... I will change it (but I don't like it, because this is not native to me :( )

Could you please use Oxford spelling here to include the rest of the world?

Just to nitpick, I think you mean "American", because the large parts of the rest of the world use British English ... I will change it (but I don't like it, because this is not native to me :( )

Actually, Oxford spelling (and American, too) is using -ize. Common British usage, although, is to use -ise. But I feel the pain of nonhabitual things. :)

Could you please use Oxford spelling here to include the rest of the world?
Just to nitpick, I think you mean "American", because the large parts of the rest of the world use British English ... I will change it (but I don't like it, because this is not native to me :( )

I meant exactly Oxford spelling: https://en.wikipedia.org/wiki/Oxford_spelling
It is used in academic publications and international organizations like ISO and ITU.

I actually like the suggestion to use 'unprivileged' because it means exactly that: using non-privileged user and binding to ports >1024. It can be used even in non-containerized environments, while 'containerized' implies usage in container only.

It actually does more than just port changes though for containers. It completely disables all selinux parts and a few other things. It's only intended for setting up an instance inside of docker ...

EDIT: Basically, I think the name "containerized" is correct, because there is an intent behind this feature for container specific integration.

@vashirov Hey, these updates are in, so it would be great to have this reviewed :)

Are there any further issues with this change? This is important for container installs to function correctly.

@vashirov @mreynolds Ping, can this please be reviewed? It's one of the last things blocking me from making a proper dockerfile/container image for the project we can use.

Yup, LGTM. There was still a discussion about changing the name altogether, but for now I'm okay with this.

The name change can't happen, because this flag really really really is for enabling container only features. It sets high ports, disables selinux checks, and shortly, it's going to drop a marker that disables systemctl. It also prevents a server restart in the setup, and it provides no backends so that containers can work. The name change must not happen because this really really is a container specific set of work.

Thanks for the ack :)

And in container You can really really really have standard ports. And In container you can really really really have systemd. https://github.com/freeipa/freeipa-container

Sorry William I could not resist :-) :-) :-)

I agree it is just a name. confusing but just a name.

You can't always have systemd. I have been experiencing issues with suse + system in docker. And you can't always have high ports because we can't guarantee capabilities etc. :(

But as well, it really is doing more than just this. It omits a backend setup so that you can do a "stateless" install, and then just attach data-volumes which have an instance ready to go. It skips the selinux port checks. Soon it needs to drop in a marker file to the instance so that "testing" ds in a container from shell causes dsctl to work properly.

I appreciate your technical insight (and can imagine your funny humourous way of saying it too :) ), but the name is intentional. It's pretty clear - this changes your install for containers.

Could you then mark it as "non-systemd" container? My problem with this approach is that it could bring more confusion than needed for cars where we are running in a container with systemd. It is still a container but by the logic of this commit it would not be so. As result, if somebody would like to use the --containerized option with, day, FreeIPA container, it will break the setup.

Systemd doesn't really have the concept of containers that I am aware of, and so I think this is a not-needed distinction.
'for cars'? What does this mean?

FreeIPA users shouldn't be touching this option anyway, they should be going through ipa-create I would think?

I think that enough time has been spent on this matter, and it's not a productive use of my time :(

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 pull request has been cloned to Github as issue and is available here:
- https://github.com/389ds/389-ds-base/issues/3200

If you want to continue to work on the PR, please navigate to the github issue,
download the patch from the attachments and file a new pull request.

Thank you for understanding. We apologize for all inconvenience.