Project

General

Profile

Actions

User story #4456

closed

Remove Rudder DIT internal information from rudder-web.properties

Added by François ARMAND about 10 years ago. Updated almost 4 years ago.

Status:
Resolved
Priority:
N/A
Assignee:
-
Category:
Web - Maintenance
UX impact:
Suggestion strength:
User visibility:
Effort required:
Name check:
Fix check:
Regression:

Description

Rudder web application configuration file ( /opt/rudder/etc/rudder-web.properties ) contains information about about Rudder internal LDAP DIT (i.e tree) organization, which is an internal only, developer related information.

There is no way that a Rudder user could change that and everything still work as exected - or at least, it may happen (well in fact, with quick&dirty test, it seems to work for mains things, kudo to dev), but we have ZERO value to expose that to user, beside making them wonder what the hell we are asking to configure, and freezing some internal choice forever.

Moreover, the properties are already marked as "should not be modified" and "internal value, do not touch".

The corresponding configuration properties are:

#
  1. LDAP DIT configuration #
  2. You should not have to modify the following properties, used to
  3. configure the inernal structure of the LDAP Directory. #
    ldap.node.base=cn=rudder-configuration
    ldap.rudder.base=ou=Rudder, cn=rudder-configuration
    ldap.inventories.software.basedn=ou=Inventories, cn=rudder-configuration
    ldap.inventories.accepted.basedn=ou=Accepted Inventories, ou=Inventories, cn=rudder-configuration
    ldap.inventories.pending.basedn=ou=Pending Inventories, ou=Inventories, cn=rudder-configuration
    ldap.inventories.removed.basedn=ou=Removed Inventories, ou=Inventories, cn=rudder-configuration

So, for 2.10, I propose to:

- remove that from rudder-web.properties,
- make the DIT structure what it is by convention, at the code level (i.e: in dev/services configuration, not in user related configuration)
- as migration path, make a script that checks that these properties have the default value, and remove them. In the hightly impropable case where a user changed these parameters, stop the migration and display a message asking to contact rudder development team to find the best way to help him (because we can't simply move the data around, if somebody did change these values, it may have had really really good and high motivation).

What do you think ? Jon, attributing to you for the discussion/validation, of course the implementation part would go other people.

Actions #1

Updated by Jonathan CLARKE about 10 years ago

  • Status changed from Discussion to Rejected

I understand that these are properties we would not change often, or even easily. But I see no reason to hide them.

We never know what the future is made of, and maybe it will make sense to someone one day to change all these properties.

The first use case that comes to mind is in an enterprise that is only allowed one directory technology, that's not OpenLDAP, so they need to put Rudder's LDAP directory in another directory server, and they need to change the base DN (and therefore all the DNs listed above).

I could come up with other use cases, but in general, what I am trying to say here is: don't hide configurable items. It is good to expose as many as possible. Hiding config properties in code would make us seem like some nasty big "one size fits all" solution. Not a nice idea.

However, I would also add that your underlying point is that the rudder-web.properties file is confusing. And I agree. But this is being solved differently: all important, user-configurable properties, are being exposed in the web interface, so that the average user never has to edit this file. And that makes it an expert's file. And then the LDAP properties are in the right place :)

So, rejecting this for now - of course feel free to re-open and discuss if you disagree strongly.

Actions #2

Updated by François ARMAND about 10 years ago

  • Status changed from Rejected to Discussion

OK for the main argument about exposing properties, I'm not against that. And OK for the "expert" vision of that file, that seems to be the way we want to go.

But I would like to have the correct granularity about exposed properties, and I don't thing we have it here.

The risk with bad exposed properties is to freeze and architecture that was not chosen to be froze at that level, or at some different time (and is not relevant anymore). And so, in fact, we give the user the feeling of modularity when there is none, i.e we are doing false modularity.
And so, we forbid future evolution (because, as you said, we don't know what the future is made of) for no good reason.

So, it seems that the modularity that make sense for Rudder and may actually matter for user is the following:

- a DN for inventories OU, because I can easily think about use case where for performance or integration with other tools, these data live outside of Rudder,
- a DN for Rudder things (policy related, Rudder configuration, etc), because they are not exposed today and I don't see a more granular split that make sense in isolation

So basically, I would like to merge ldap.node.base / ldap.inventories.software.basedn / ldap.inventories.accepted.basedn / ldap.inventories.pending.basedn / ldap.inventories.removed.based into one property, "ldap.inventories.basedn".

One reason for that is to allow us to change the inventory structure to allow adapt to scalling when we will need to scale to thousand of nodes - not that I already now what we will have to change, if anything, but if we have to, we won't want to deal with case where the user changed these properties.

I won't argues more for that, so feel free to close it again - we can wait to have user & scalling feedback to take a more data-evidence based choice about the inventory structure.

Actions #3

Updated by Jonathan CLARKE about 10 years ago

  • Status changed from Discussion to 8
  • Assignee deleted (Jonathan CLARKE)
  • Target version changed from 2.10.0~beta1 to Ideas (not version specific)

OK, I see what you mean. I have nothing against removing some of the "outer leaves" from this configuration, so long as we keep at least the following properties fully configurable:

ldap.node.base=cn=rudder-configuration
ldap.rudder.base=ou=Rudder, cn=rudder-configuration
ldap.inventories.basedn=ou=Inventories, cn=rudder-configuration

(note that the last one in the list doesn't currently exist, I thought it did, but it was called ldap.inventories.*software*.basedn, which seems clearly wrong)

However, if we don't know where we're going with this, and since this is not hurting anyone at this point in time, and we have many other higher priorities (bugs to fix! new features to implement!) I would like to set this aside for now, and avoid spending precious time on it until we have a good reason to.

In that spirit, leaving the ticket open, but unassigned, and targeted for "sometime in the future". Is that OK for you?

Actions #4

Updated by François ARMAND about 10 years ago

OK for the ticket status.

Actions #5

Updated by Benoît PECCATTE almost 9 years ago

  • Status changed from 8 to New
Actions #6

Updated by François ARMAND almost 4 years ago

  • Status changed from New to Resolved

They were removed in rudder 5.0

Actions

Also available in: Atom PDF