Jeff-seattle
Visitor.
453 views

Can someone clarify the two types of non-root installs

Hi. So my memory was jogged in an IDM post earlier. My understand of eDirectory installs has been two ways. A root install, and any user simply doing a tarball extract. I keep running into mention of a root-install but non-root instance. This sounds quite nice actually, as we have always wanted to give the actual users and admins of the system full control, and have attempted some tarball instances in the past, but invariable they mess something up, ie remove a file or whatever. Addionally we run IDM, and IDM is extremely painful to patch as a non-root install.

So is this third install, simply a root-install with lots of sudo? I really am confused, and I cannot find any TID on this third option. Thanks,,,
Labels (1)
0 Likes
6 Replies
Knowledge Partner
Knowledge Partner

Re: Can someone clarify the two types of non-root installs

On 07/27/2018 06:34 AM, mtsjej wrote:
>
> Hi. So my memory was jogged in an IDM post earlier. My understand of
> eDirectory installs has been two ways. A root install, and any user
> simply doing a tarball extract. I keep running into mention of a
> root-install but non-root instance. This sounds quite nice actually, as


Yes, it is the best scenario from a security standpoint, and probably for
administration in general because it does not require 'root' access for
most day-to-day tasks.

> we have always wanted to give the actual users and admins of the system
> full control, and have attempted some tarball instances in the past, but
> invariable they mess something up, ie remove a file or whatever.


Yes, that is what happens when you move away from package-based installs.

> Addionally we run IDM, and IDM is extremely painful to patch as a
> non-root install.


Yes; it was nice they added support, but the better option was already
working, though not documented well.

> So is this third install, simply a root-install with lots of sudo? I
> really am confused, and I cannot find any TID on this third option.
> Thanks,,,


There are two types of installs, and two types of instances, and for the
most part they are mutually exclusive, and you are already understanding
most of it.

First, a root install just means an RPM-based install. Because modifying
the system's RPM repository requires 'root', this install requires 'root',
whether as root directly, or via su, or sudo, whatever. The package-based
install is the root install.

Second, a non-root intsall which is little more than a tarball. There are
still packages to install, though, e.g. NICI's package must still be
installed as 'root', but that's documented.

Now for instances there are similarly two types, and they can work with
either type of install (though a root instance with a non-root install
would be pretty weird). A root instance is what we're used to, where the
instance runs as 'root', and is basically how things are always done,
particularly when using Open Enterprise Server (OES). With ndsd running
as 'root', though, if it is ever compromised then it could compromise the
entire system (without other protections involved), including modifying
its own binaries to become resident across restarts of the ndsd process;
this is all bad. The upside is that it is easy to use any low (less than
1024) ports with a root instance because low ports are only allowed for a
privileged user by default.

A non-root instance can also work with either type of install, and the
commands are basically all the same. A non-root instance in a root
install is in my opinion, the perfect configuration, and is basically how
most other things in Linux work; Apache httpd is package-based, but then
runs as non-root. The upside is that if a compromise ever happens the
whole system is not damaged, but only the running instance. Since even
the file's own binaries are root-owned, a compromise cannot allow an
attacker to modify the binary to work across service restarts, and that's
a good thing too. The downside is that non-root instances cannot bind low
ports by default, so either higher ports are used (1524 instead of 524,
1636 instead of 636, etc.) or else the host's firewall can be used to make
the system appear to use low ports even though the service itself is only
listening on high ports (because NetFilter/iptables is awesome).

Keep in mind that while many customers use non-root instances in root
installs, it is not well-documented, and you may get pushback from support
or engineering at the current time if you hit a bug they cannot duplicate
in a more traditional setup. Hopefully that will change soon, but it is
something about which you should be aware if deploying in production.
Hopefully in the future this kind of setup will become the default, but a
lot of people who do not fully understand the benefits, or are just
uncomfortable with seemingly big changes, will need to get on the bandwagon.

Some of that transition time may be in figuring out how to change from
root to non-root; I created a CoolSolution a couple years ago to do that,
which may be worth reviewing to better understand the differences:

https://www.netiq.com/communities/cool-solutions/cool_tools/edirectory-conversion-root-non-root-instances/

Hopefully all of this helps explain some things a bit more; please feel
free to post back any follow-up questions or comments.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
0 Likes
Knowledge Partner
Knowledge Partner

Re: Can someone clarify the two types of non-root installs

ab wrote:

> Hopefully all of this helps explain some things a bit more; please
> feel free to post back any follow-up questions or comments.


That's a great explanation, Aaron and you have provided similar
explanations in other posts.

There seems to be a lot of interest in this topic. Why don't you create
a CoolSolution which is likely to have a much wider audience?

--
Kevin Boyle - Knowledge Partner
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below this post.
Thank you.
_____
Kevin Boyle - Knowledge Partner - Calgary, Alberta, Canada
Who are the Knowledge Partners?
If you appreciate my comments, please click the Like button.
If I have resolved your issue, please click the Accept as Solution button.
0 Likes
Knowledge Partner
Knowledge Partner

Re: Can someone clarify the two types of non-root installs

Kevin Boyle wrote:

> There seems to be a lot of interest in this topic. Why don't you create
> a CoolSolution which is likely to have a much wider audience?


He already did and even posted the link above... 😉
0 Likes
Knowledge Partner
Knowledge Partner

Re: Can someone clarify the two types of non-root installs

Lothar Haeger wrote:

> Kevin Boyle wrote:
>
> > There seems to be a lot of interest in this topic. Why don't you
> > create a CoolSolution which is likely to have a much wider audience?

>
> He already did and even posted the link above... 😉


I must be blind! <egg-on-face>

--
Kevin Boyle - Knowledge Partner
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below this post.
Thank you.
_____
Kevin Boyle - Knowledge Partner - Calgary, Alberta, Canada
Who are the Knowledge Partners?
If you appreciate my comments, please click the Like button.
If I have resolved your issue, please click the Accept as Solution button.
0 Likes
Knowledge Partner
Knowledge Partner

Re: Can someone clarify the two types of non-root installs

For what it is worth, I took Kevin's request as one generally on the
topic, where the CoolSolution I shared is just to help move from root to
non-root instance, so I assumed they were different topics. Still,
looking at the CoolSolution now, it has a lot of the background
information there.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
0 Likes
Jeff-seattle
Visitor.

Re: Can someone clarify the two types of non-root installs

ab;2484820 wrote:
On 07/27/2018 06:34 AM, mtsjej wrote:
>
> Hi. So my memory was jogged in an IDM post earlier. My understand of
> eDirectory installs has been two ways. A root install, and any user
> simply doing a tarball extract. I keep running into mention of a
> root-install but non-root instance. This sounds quite nice actually, as


Yes, it is the best scenario from a security standpoint, and probably for
administration in general because it does not require 'root' access for
most day-to-day tasks.

> we have always wanted to give the actual users and admins of the system
> full control, and have attempted some tarball instances in the past, but
> invariable they mess something up, ie remove a file or whatever.


Yes, that is what happens when you move away from package-based installs.

> Addionally we run IDM, and IDM is extremely painful to patch as a
> non-root install.


Yes; it was nice they added support, but the better option was already
working, though not documented well.

> So is this third install, simply a root-install with lots of sudo? I
> really am confused, and I cannot find any TID on this third option.
> Thanks,,,


There are two types of installs, and two types of instances, and for the
most part they are mutually exclusive, and you are already understanding
most of it.

First, a root install just means an RPM-based install. Because modifying
the system's RPM repository requires 'root', this install requires 'root',
whether as root directly, or via su, or sudo, whatever. The package-based
install is the root install.

Second, a non-root intsall which is little more than a tarball. There are
still packages to install, though, e.g. NICI's package must still be
installed as 'root', but that's documented.

Now for instances there are similarly two types, and they can work with
either type of install (though a root instance with a non-root install
would be pretty weird). A root instance is what we're used to, where the
instance runs as 'root', and is basically how things are always done,
particularly when using Open Enterprise Server (OES). With ndsd running
as 'root', though, if it is ever compromised then it could compromise the
entire system (without other protections involved), including modifying
its own binaries to become resident across restarts of the ndsd process;
this is all bad. The upside is that it is easy to use any low (less than
1024) ports with a root instance because low ports are only allowed for a
privileged user by default.

A non-root instance can also work with either type of install, and the
commands are basically all the same. A non-root instance in a root
install is in my opinion, the perfect configuration, and is basically how
most other things in Linux work; Apache httpd is package-based, but then
runs as non-root. The upside is that if a compromise ever happens the
whole system is not damaged, but only the running instance. Since even
the file's own binaries are root-owned, a compromise cannot allow an
attacker to modify the binary to work across service restarts, and that's
a good thing too. The downside is that non-root instances cannot bind low
ports by default, so either higher ports are used (1524 instead of 524,
1636 instead of 636, etc.) or else the host's firewall can be used to make
the system appear to use low ports even though the service itself is only
listening on high ports (because NetFilter/iptables is awesome).

Keep in mind that while many customers use non-root instances in root
installs, it is not well-documented, and you may get pushback from support
or engineering at the current time if you hit a bug they cannot duplicate
in a more traditional setup. Hopefully that will change soon, but it is
something about which you should be aware if deploying in production.
Hopefully in the future this kind of setup will become the default, but a
lot of people who do not fully understand the benefits, or are just
uncomfortable with seemingly big changes, will need to get on the bandwagon.

Some of that transition time may be in figuring out how to change from
root to non-root; I created a CoolSolution a couple years ago to do that,
which may be worth reviewing to better understand the differences:

https://www.netiq.com/communities/cool-solutions/cool_tools/edirectory-conversion-root-non-root-instances/

Hopefully all of this helps explain some things a bit more; please feel
free to post back any follow-up questions or comments.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.


Hi. That is a very good explanation, and the link you sent is very good as well. I am going to test this for sure. It should all our issues and I look forward to testing this. Thanks,,,
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.