You are here
First of all, I want to say thank you to Alon and Liraz for the great work on these appliances and especially the new tkldev environment. I've been keeping tabs on TurnKey Linux since hearing about it a couple of years ago and finally decided to take the plunge and convert my CentOS 5 based servers in the hopes that it will be more maintainable with respect to the configuration changes that I have to make. The tkldev appliance has been great to work with to creat new builds that are setup the way I need.
As I've been working through the openLDAP appliance I came across a few items that I think should be improved from the default appliance configuration, and I wanted to get some feedback from you all as far as how best to proceed. My primary question is what types of changes should be pushed upstream to the appliance and which should be handled as patches that users can download and apply if they need that functionality? I'm envisioning a possible environment where there is a base appliance with a good default configuration and then various patches that configure it for more specific capabilities. Some examples using the openLDAP appliance are below.
Configure phpLDAPadmin (web gui to LDAP server) to access the cn=config database with the server configurations. I think this, if the devs agree, would become part of the base appliance. I've created a branch to add that functionality and submitted a pull-request via github if anyone wants to check it out.
Configure recommended default indices for openLDAP to improve performance. I think this should also become part of the base appliance, and also created a branch with the needed functionality.
A set of phpLDAPadmin templates and configuration to make managing the LDAP server friendlier. This I could see going either way, part of appliance or tklpatch, mostly because it would tend to impose a particular directory structure/workflow. Although if done well it would encourage people to implement a good structure to their database. For this one I currently have a tklpatch but if there was interest I could easily make it a branch so that it could be included in the base appliance.
Add the SAMBA schema and phpLDAPadmin templates to manage SAMBA (Windows compatible file server) users via LDAP. This one I'm leaning a little more toward just providing a patch that users could apply if they wanted, simply because not everyone who is setting up an LDAP server is going to use the SAMBA schema. That said, it shouldn't hurt to have the schema loaded even if not using it, however it may have a performance impact for large databases. I also noticed the phpLDAPadmin includes several SAMBA related templates by default, so have some customized SAMBA related templates also shouldn't be a big deal. This was actually what started it all since I had originally developed a couple of custom templates and thought it would be nice to have an automated way to apply them to a new server.
Finally, there are some changes that would be need to tklcore and the fileserver appliances to authenticate against the LDAP server. I think it would be great to just install an appliance and in the inithooks specify the domain and LDAP server etc, and have it all setup and working. For these I would think that creating a separate appliance would be the best approach since you don't necessarily want the same configuration between the original appliance and the LDAP enabled one. However, maybe something where the inithooks ask if you want LDAP authentication or not. I'm not sure which would be more difficult to maintain, separate appliances that are almost identical, or an inithook script that configures the appliance for different capabilities.
Anyway, I'd appreciate feedback on my thoughts above. I see this being applicable to more appliances than the ones I'm using especially when considering TurnKey Linux as a network infrastructure.
Thanks for the feedback
TBH I know very little about LDAP and don't feel like I am in any position to comment on most of your post sorry. But I would like to thank you for making the effort to post this extensive feedback/feature request/suggestion(s).
I have posted it as a feature request on the TKL Issue tracker. As I mentioned in the 'issue' on GitHub I think ideally your individual points should be pulled out each with their own 'issue'. But for now a placeholder issue will have to do... I'll try to get back to this and convert it into individual feature requests (unless you or someone else beats me to it) but not sure when that'll be...
You're Welcome
Jeremy, Thank you for taking the time to read it. I guess my over-all question got lost in the details of the LDAP server. Even though you don't have much experience with the LDAP piece of it, I would like your thoughts on how to handle different flavors of appliance.
For instance one of the changes I mentioned above is necessary to allow the file-server (SAMBA) to use LDAP instead of it's normal user database, which is useful for providing a single-signon experience to users of a network. This is a change to the one appliance (OpenLDAP) to support another appliance (Fileserver). However, most of the changes required to the LDAP appliance are general to this setup, so they apply to anyone who want to use the file server with the LDAP server*. So, as an end user setting up a network, would you want to have a separate OpenLDAP appliance that had the SAMBA pieces added, a tklpatch that you can apply to the stock OpenLDAP appliance, or the ability to choose how the appliance gets configured when it is first setup?
On the flip side, as an appliance developer, does it make more sense to keep something like this as a tklpatch, create a new appliance for it, or use the inithook scripts to tailor the configuration on install? There, the question is mostly one of which is more straightforward to maintain for the appliance devs. I can see the inithook option being easier to maintain, but it would definitely require significant development effort up-front.
So, as you can see, these possibilities are more general than the OpenLDAP specific changes that I outlined above, and it would be great if we came up with a preferred way to provide general configurations of appliances like this.
*There would also be corresponding changes required to the file server appliance to support this setup.
Sorry I never replied to this thread....
Overall my inclination would be to add the functionality to OpenLDAP (to communicate with Samba). From where I sit; it wouldn't be too much extra even if the OpenLDAP user didn't want it. And a bonus if they did. Although as you know I don't know much about LDAP...
On the Samba side, using a patch (perhaps installable with a helper script) and perhaps also documenting what needs to be done would be the way to go IMO...
Add new comment