Using the cli tools today ...
by William Brown
Hi all,
I've been re-deploying my home ldap server with the cli today and ... wow. DS 1.4.x compared to 1.3.x to administer is like a new product. It's unbelievable how easy it is to do ... everything. New backends, exports, imports, plugins ... you name it. It's really looking like "the ldap server I always wish I had" when I was an admin. Great work to everyone on this, I know it's been ages to get here, but it's just wonderful to see it in action.
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs
4 years, 9 months
LDAPCon 2019 CFP
by William Brown
Hi all,
The LDAP Con 2019 CFP is now open - this would be a great chance for our developers to speak about what we have done for accessibility and other improvements in the last two years. For those in the EU this should be pretty easy to get to. I'm currently asking a member of the program committee if they'll accept recorded submissions from developers who are long distance and unable to travel (AUS/US). I also would love if the conference recorded talks so that the world can see what is on offer in our community (I'll ask them about that separately).
I think we have a lot we could present here especially around:
* lib389 and the ds* tools
* cockpit
* docker and containerisation
Good luck in your submissions!
https://cfp.ldapcon.org/ldapcon2019/cfp
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs
4 years, 9 months
Discussion - 389ds docker images
by William Brown
Hi all,
I'd like us to start offering 389ds images on docker hub - and ideally, I'd like to automate this process as much as possible.
As I've historically been the person who has been pushing this the most, I'm happy to maintain and coordinate that these are updated and released when the project updates it's branches.
Due to the way docker works, we only need to make sure that what we have in the volume /data is readable and operational, so I think there is no issue with what base image we choose for the container image, because we can always change it later without affecting the user as /data is always the way we'll access and present the container state.
For me, I'd probably setup an automated build from git master on a :devel tag or similar in docker hub, and :latest would be the latest major series release (1.4), probably shortened to :4, with the point releases in there too, IE :4.1, :4.2. patch releases would just be updates to those streams. If possible I'd like to automate those from our git branches. The best way would probably be to make a git mirror to github/gitlab which can then have triggers to call docker hub to do necessary updates.
A major question is how we actually do the build - do we build from the source tree, or do we build from a rolling repo like the network:ldap repo in opensuse (which is always following upstream releases). I think building from source is the most flexible, as it gives us the closest relationship to git and our upstream release process.
Thoughts?
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs
4 years, 9 months
