Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added OpenLDAP 2.4.41 image #6

Merged
merged 1 commit into from
Aug 12, 2015

Conversation

stevekuznetsov
Copy link
Contributor

Also added a testenv image that adds test data for use in Origin integration testing.

Future TODO:

@stevekuznetsov
Copy link
Contributor Author

@liggitt PTAL

@liggitt liggitt self-assigned this Aug 3, 2015
This was referenced Aug 4, 2015
@stevekuznetsov
Copy link
Contributor Author

@bparees PTAL as well! This image will only be used for our testing (for now). I am of the opinion that as long as we label it as such we can get away with keeping the future TODO list as future TODOs.

VOLUME ["/var/lib/ldap", "/etc/openldap"]

# Expose default ports for ldap and ldaps
EXPOSE 389 636
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you're going to be running as non-root, presumably...can you listen on these ports?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seemed to work perfectly fine in testing

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was able to chmod the slapd binary in such a way that it does indeed have the permissions to listen on these ports. I think this is preferable to mapping them to something with a router.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you chmod'd it to setuid root? no that is bad.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@smarterclayton selinux is going to prevent this sort of thing at some point, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bparees @smarterclayton would it be valid to setcap 'cap_net_bind_service=+ep' the slapd binary?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that sounds like a better approach..

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You know what they say, why use a brush when you have a bulldozer?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@deads2k is the only person i know who likely has bulldozer driving experience.

@stevekuznetsov
Copy link
Contributor Author

@bparees Updated, everything works fine with UID == 0 and UID != 0

@stevekuznetsov stevekuznetsov force-pushed the skuznets/openldap branch 5 times, most recently from 77b5a23 to b6b35e6 Compare August 7, 2015 19:37
@stevekuznetsov
Copy link
Contributor Author

@bparees updated Dockerfile to grant low-port bind access to binary instead of creating large security hole

mkdir -p /etc/openldap && \
chmod a+rwx -R /etc/openldap && \
mkdir -p /var/run/openldap && \
chmod a+rwx -R /var/run/openldap
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

combine these RUNs

@stevekuznetsov
Copy link
Contributor Author

@bparees Unfortunately I have not been able to find a way in the last two weeks to get this to run as non-root other than to bulldoze my way through the config and data directories, overwriting it all from a default-configured setup. I would also prefer not to put the binaries in the repository, but that is the only way this works at all.

@bparees
Copy link
Contributor

bparees commented Aug 7, 2015

i'm going to need a better understanding of why that is........ it's going to be a pain to maintain that as binary files, nevermind the general horribleness of having binary content in git in terms of what it does to repo size.

@stevekuznetsov stevekuznetsov force-pushed the skuznets/openldap branch 4 times, most recently from 518df58 to 21ad5d6 Compare August 11, 2015 14:17
@stevekuznetsov
Copy link
Contributor Author

@bparees PTAL - added HACKING.md to address your concerns. Will merge if it LGTY.

@stevekuznetsov stevekuznetsov force-pushed the skuznets/openldap branch 2 times, most recently from d28fd28 to 9d0c888 Compare August 11, 2015 17:30
@stevekuznetsov
Copy link
Contributor Author

@bparees Moved test data out of this repo

The default out-of-the-box installation of OpenLDAP contains a `olcRootDN` manager for the `cn=config` database but does not list a password, which is problematic as it does not allow you to use the full authentication (`-x -D <managerCN> -w <password>`) and therefore does not allow for the user to use this set-up to add or remove records unless they are `UID 0`.

### OpenLDAP Configuration Dump
OpenLDAP exposes administrative tools like [`slapadd`](http://www.openldap.org/software/man.cgi?query=slapadd&apropos=0&sektion=0&manpath=OpenLDAP+2.4-Release&format=html) and [`slpacat`](http://www.openldap.org/software/man.cgi?query=slapcat&apropos=0&sektion=0&manpath=OpenLDAP+2.4-Release&format=html) which operate on OpenLDAP installations with the daemon not running. These tools are a promising work-around to the authentication nightmare above. The gist of this approach is as such: first, install OpenLDAP on a machine or container where you have `root` privileges (`UID 0` and `GID 0` are required due to how OpenLDAP generates authentication identities), create an OpenLDAP installation to your liking, stop the daemon (`slapd`), dump all of the OpenLDAP installation to `ldif` using `slapcat -n0`, then import all of the data using `slapadd -n0` on another installation. This approach does not seem to work as if there are no vestiges of the new `cn=config` configuration schema in the `etc/openldap` directory, the `slapadd` command looks for the old `slapd.conf` configuration schema and fails because it is deprecated. `slapadd` also cannot be used while the daemon is off to insert the records we want to `olcDatabase{0}config` as it is only capable of adding object, not editing or amending current objects. Editing the files by hand will trigger checksum errors and cause a corrupt installation. Therefore, this option was abandoned.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

work on the tone a little... "nightmare" is probably not how we want to describe this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Little to much heart in that one?

@bparees
Copy link
Contributor

bparees commented Aug 11, 2015

one final comment and lgtm.

@bparees
Copy link
Contributor

bparees commented Aug 11, 2015

@stevekuznetsov failed testing: https://ci.openshift.redhat.com/jenkins/view/Image%20Verification/job/openldap/3/console

looks like it might just be this rmdir that failed, though i'm not clear why that would be...maybe the dir couldn't be rm'd because your container didn't stop so the cidfile wasn't removed?

rmdir /tmp/tmp.jjean7DZk1openldap_test_cidfiles
make: *** [test] Error 1

  • echo 'ERROR: openldap-rhel7 failed testing.'
  • exit 1

@stevekuznetsov
Copy link
Contributor Author

I can't reproduce this with TARGET=rhel7 make test locally. The logs look like they show the container stopping with a 0 exit code, as well:

+ CONTAINER=7bd0c9fdebadeff2fcbe657e67d8c76bb7f4e9fffaa929f1e3d0c76cf431ea90
+ echo 'Stopping and removing container 7bd0c9fdebadeff2fcbe657e67d8c76bb7f4e9fffaa929f1e3d0c76cf431ea90...'
+ docker stop 7bd0c9fdebadeff2fcbe657e67d8c76bb7f4e9fffaa929f1e3d0c76cf431ea90
++ docker inspect -f '{{.State.ExitCode}}' 7bd0c9fdebadeff2fcbe657e67d8c76bb7f4e9fffaa929f1e3d0c76cf431ea90
+ exit_status=0
+ '[' 0 '!=' 0 ']'
+ docker rm 7bd0c9fdebadeff2fcbe657e67d8c76bb7f4e9fffaa929f1e3d0c76cf431ea90
+ rm /tmp/tmp.jjean7DZk1openldap_test_cidfiles/test_container_root
+ echo Done.

@stevekuznetsov
Copy link
Contributor Author

@bparees I use ldapsearch in order to test the image, and the Jenkins server doesn't have this installed. Thoughts?

@bparees
Copy link
Contributor

bparees commented Aug 12, 2015

can you curl/wget ldapsearch as part of the test script?

@stevekuznetsov
Copy link
Contributor Author

I'll look into it. I think it should be possible.

@stevekuznetsov
Copy link
Contributor Author

@bparees Great Success

@bparees
Copy link
Contributor

bparees commented Aug 12, 2015

@stevekuznetsov i actually just meant use curl to download ldapsearch and then use it..but i guess that works too.

bparees added a commit that referenced this pull request Aug 12, 2015
@bparees bparees merged commit b72261e into openshift:master Aug 12, 2015
stevekuznetsov pushed a commit to stevekuznetsov/openldap that referenced this pull request Oct 6, 2015
stevekuznetsov pushed a commit to stevekuznetsov/openldap that referenced this pull request Oct 6, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants