User story #1971
closed
Impossible to manage rudder server via web interface
Added by Jean Remond over 12 years ago. Updated about 9 years ago.
Description
The rudder root server is not listed in the nodes list.
It makes impossible to test rudder with only one machine.
Updated by Jonathan CLARKE over 12 years ago
- Status changed from New to 2
- Priority changed from N/A to 3
- Target version set to 18
Jean Remond wrote:
The rudder root server is not listed in the nodes list.
It makes impossible to test rudder with only one machine.
This is a very good use case to enable managing the root server. Thanks for suggesting it!
We originally disabled this feature, to avoid "breaking" Rudder. Some of the discussion related to it is in #1201 (mostly in French, sorry!).
I agree with you that we should enable this feature - there are no major technical limitations that I can see, only "safety" limitations (it makes it easier to shoot yourself in the foot!), so with appropriate warnings it would be a nice feature to have.
Updated by François ARMAND over 12 years ago
- Target version changed from 18 to 24
Updated by Jean Remond over 12 years ago
If you change rudder-cfengine-community by rudder-agent as a dependency for rudder-server-root, will that work ?
Updated by Jonathan CLARKE over 12 years ago
Hi Jean,
Jean Remond wrote:
If you change rudder-cfengine-community by rudder-agent as a dependency for rudder-server-root, will that work ?
No, it's not that simple, unfortunately :-)
The Rudder server is aware that it is itself a node to be managed, but we made a choice a while back to deliberatly hide this "special" node in the web interface. It does actually have policies applied, including a special one called "distribute policy", which makes it a "CFEngine server".
I agree that we should unhide this, and make it possible to manage the Rudder server via Rudder. This would also allow to configure some parts of Rudder via the web interface (like the allowed networks, some paths, ports used, etc...)
Updated by Jonathan CLARKE over 12 years ago
- Tracker changed from Question to User story
Updated by Jonathan CLARKE about 12 years ago
- Category set to Web - Config management
Updated by Jonathan CLARKE almost 12 years ago
- Assignee set to François ARMAND
So this is another ticket on the same subject as #1201. François and Nicolas will be interested to read it I guess.
This points out one major point that needs adressing: we'll need to modify packaging to no longer use rudder-cfengine-community but rudder-agent instead. This will give us an inventory of the node and will prime it using node initial promises.
Updated by François ARMAND almost 12 years ago
- Target version changed from 24 to 46
Updated by François ARMAND almost 12 years ago
- Status changed from 2 to In progress
- Priority changed from 3 to 1
A first pair-programming sceance reveals that the developper of Rudder are great: just adding an inventory for the policy server seems to make all of it works, and even allows to simplify some more code.
More precisely:
- the init script is not changed, the user still have to answer host, it, etc for the server
- but these data will be put in the ou=Accepted Inventory branch as for a regular node
- and now, the server node entry in ou=Nodes, etc is the same as a regular node, only its objectclass change
- when a new inventory will come from the Policy Server, it will automatically be accepted, as the policy server has data in ou=Accepted Inventory
- the target of the Inventory rule is changed from "all_exceptedPolicyServers" to "all"
- all other Rudder behaviour were already sufficiently generic to work as is.
What must be done now:
- modify "init promises" on policy server to add inventory
- use standard "rudder agent" on policy server
- some (a lot ?) of ergonomic upgrades like:
- do not display "remove" button for policy servers (at least the master one :)
- add some icon or other highlighting for a policy server node details
- add the possibility to have a "not a policy server" filter (or node type) for group creation
- check if the fact that the hostname is now comming from the policy server inventory is not a problem
- add the node type in inventory (policy server, relay server, simple node).
Updated by Jonathan CLARKE almost 12 years ago
- Target version changed from 46 to 47
Updated by François ARMAND almost 12 years ago
- Status changed from In progress to Discussion
- Assignee deleted (
François ARMAND)
I believe that that bug won't go much farther, and other, more atomic bug should be created for the remaining tasks.
Updated by Matthieu CERDA almost 12 years ago
Here is what I was suggesting in order to have a complying packaging:
- Adjust the rudder-server-root dependencies from rudder-cfengine-community to rudder-agent
- Change rudder-agent postinst to ask the user wether this is a node or a server machine and copy the right init promises accordingly
- Check if the init promises are not set to use a hardcoded path for the inputs folder, if so they should use $(sys.workdir) instead.
Updated by Jonathan CLARKE almost 12 years ago
Matthieu CERDA wrote:
Here is what I was suggesting in order to have a complying packaging:
- Adjust the rudder-server-root dependencies from rudder-cfengine-community to rudder-agent
Sounds good.
We'll also need to manage the upgrade side of this: how to tell apt-get/aptitude to remove rudder-cfengine-community and install rudder-agent instead. Maybe using "Conflicts:"?
- Change rudder-agent postinst to ask the user wether this is a node or a server machine and copy the right init promises accordingly
I'm not sure we need to ask the user. It may be possible to tell another way - or even use the same initial promises in both cases, that just detect if the UUID is "root"?
- Check if the init promises are not set to use a hardcoded path for the inputs folder, if so they should use $(sys.workdir) instead.
Hmmm, why would this be necessary? rudder-agent and rudder-cfengine-community have the same workdir - /var/rudder/cfengine-community. Only CFEngine Nova (for Windows support) differs and uses /var/cfengine.
Updated by Matthieu CERDA almost 12 years ago
Jonathan CLARKE wrote:
Matthieu CERDA wrote:
Here is what I was suggesting in order to have a complying packaging:
- Adjust the rudder-server-root dependencies from rudder-cfengine-community to rudder-agent
Sounds good.
We'll also need to manage the upgrade side of this: how to tell apt-get/aptitude to remove rudder-cfengine-community and install rudder-agent instead. Maybe using "Conflicts:"?
Well, we already had to manage this case when we migrated from rudder-policy-templates to rudder-techniques. We used a mix of conflicts and requires, we should look at the commit.
- Change rudder-agent postinst to ask the user wether this is a node or a server machine and copy the right init promises accordingly
I'm not sure we need to ask the user. It may be possible to tell another way - or even use the same initial promises in both cases, that just detect if the UUID is "root"?
Well, as long as the file has been generated it is possible, but we have to carefully look at the installation order. Is the file generated before or after rudder-agent installation ?
- Check if the init promises are not set to use a hardcoded path for the inputs folder, if so they should use $(sys.workdir) instead.
Hmmm, why would this be necessary? rudder-agent and rudder-cfengine-community have the same workdir - /var/rudder/cfengine-community. Only CFEngine Nova (for Windows support) differs and uses /var/cfengine.
Oh, you're right ! This makes things much more simple.
Updated by Nicolas CHARLES almost 12 years ago
- % Done changed from 0 to 50
The webapp lets choose for each group if we want to include the policy servers in it or not.
By default, it is false (to prevent surprise when migrating from a 2.4)
There is still some polishing to do in the display part though
Updated by Jonathan CLARKE almost 12 years ago
- Target version changed from 47 to 50
Updated by Jonathan CLARKE almost 12 years ago
- Target version changed from 50 to 2.4.0~beta3
Updated by Nicolas PERRON almost 12 years ago
Matthieu CERDA wrote:
Jonathan CLARKE wrote:
Matthieu CERDA wrote:
Here is what I was suggesting in order to have a complying packaging:
- Adjust the rudder-server-root dependencies from rudder-cfengine-community to rudder-agent
Sounds good.
We'll also need to manage the upgrade side of this: how to tell apt-get/aptitude to remove rudder-cfengine-community and install rudder-agent instead. Maybe using "Conflicts:"?
Well, we already had to manage this case when we migrated from rudder-policy-templates to rudder-techniques. We used a mix of conflicts and requires, we should look at the commit.
You're right. In the 2.3 branch, rudder-policy-templates is the good example. This package has replaced rudder-webapp which was later of 2.2.0~beta1 version.
Replaces: rudder-webapp (>= 2.2.0~beta1)
Another example is rudder-techniques on branch 2.4. This package replaced rudder-policy-templates without worrying about version(like http://www.debian.org/doc/debian-policy/ch-relationships.html#s7.6.2):
Provides: rudder-policy-templates Replaces: rudder-policy-templates Conflicts: rudder-policy-templates
We could specify the version like the first example:
Provides: rudder-cfengine-community (>= 2.4.0~beta3) Conflicts: rudder-cfengine-community (>= 2.4.0~beta1) Replaces: rudder-cfengine-community (>= 2.4.0~beta1)
- Change rudder-agent postinst to ask the user wether this is a node or a server machine and copy the right init promises accordingly
I'm not sure we need to ask the user. It may be possible to tell another way - or even use the same initial promises in both cases, that just detect if the UUID is "root"?
Well, as long as the file has been generated it is possible, but we have to carefully look at the installation order. Is the file generated before or after rudder-agent installation ?
How could the files be installed before the installation ? rudder-agebt/rudder-cfengine-community is the first package to be installed and provides theses files.
We shouldn't have to ask the user whether the machien is a node or a server, we must try to automate this.
- Check if the init promises are not set to use a hardcoded path for the inputs folder, if so they should use $(sys.workdir) instead.
Hmmm, why would this be necessary? rudder-agent and rudder-cfengine-community have the same workdir - /var/rudder/cfengine-community. Only CFEngine Nova (for Windows support) differs and uses /var/cfengine.
Oh, you're right ! This makes things much more simple.
I agree with you
Updated by Nicolas PERRON almost 12 years ago
I first analyze show me that:
- init daemon and default are differents: not the same name (cfengine-community and rudder-agent), a little difference in the default file.
- the BerkeleyDB's library version used are not the same.
- build options are not the same.
Updated by Nicolas PERRON almost 12 years ago
Nicolas PERRON wrote:
Matthieu CERDA wrote:
Jonathan CLARKE wrote:
Matthieu CERDA wrote:
Here is what I was suggesting in order to have a complying packaging:
- Adjust the rudder-server-root dependencies from rudder-cfengine-community to rudder-agent
Sounds good.
We'll also need to manage the upgrade side of this: how to tell apt-get/aptitude to remove rudder-cfengine-community and install rudder-agent instead. Maybe using "Conflicts:"?
Well, we already had to manage this case when we migrated from rudder-policy-templates to rudder-techniques. We used a mix of conflicts and requires, we should look at the commit.
You're right. In the 2.3 branch, rudder-policy-templates is the good example. This package has replaced rudder-webapp which was later of 2.2.0~beta1 version.
[...]Another example is rudder-techniques on branch 2.4. This package replaced rudder-policy-templates without worrying about version(like http://www.debian.org/doc/debian-policy/ch-relationships.html#s7.6.2):
[...]We could specify the version like the first example:
[...]
That's the logic for debian but we have to check of to implement this with RPM.
Updated by Jonathan CLARKE almost 12 years ago
That's the logic for debian but we have to check of to implement this with RPM.
Actually, we implemented it for rudder-techniques already (that package changed name, used to be rudder-policy-templates), but it's roughly the same idea:
https://github.com/Normation/rudder-packages/blob/branches/rudder/2.4/rudder-techniques/SPECS/rudder-techniques.spec#L55
Updated by Jonathan CLARKE almost 12 years ago
Nicolas PERRON wrote:
Besides, using rudder-agent instead of rudder-cfengine imply to check differencies between the both of them.
I first analyze show me that:
- init daemon and default are differents: not the same name (cfengine-community and rudder-agent), a little difference in the default file.
We should keep the rudder-agent name and adapt the rudder-server-root script, and possibly common or distributePolicy Techniques.
- the BerkeleyDB's library version used are not the same.
That should not be the case!
- build options are not the same.
They look the same to me, aside from an extra variable "BERKELEY_DB_LIB=-ldb".
Also, the main difference is that rudder-agent adds initial promises management, which rudder-cfengine-community does not. And of course, on the node, initial promises are different than on the root server. Although we could merge them and use the "policy_server::" or "root_server::" classes to control actions, or the bundlesequence.
Updated by Jonathan CLARKE almost 12 years ago
- Category changed from Web - Config management to 11
- Assignee set to Nicolas PERRON
- Target version changed from 2.4.0~beta3 to 2.3.9
Nicolas PERRON wrote:
Besides, using rudder-agent instead of rudder-cfengine imply to check differencies between the both of them.
I first analyze show me that:
- init daemon and default are differents: not the same name (cfengine-community and rudder-agent), a little difference in the default file.
- the BerkeleyDB's library version used are not the same.
- build options are not the same.
By the way, these are all very good examples of why being DRY is important... otherwise you end with some changes that are not spread everywhere, and it becomes impossible to track!
Updated by Nicolas PERRON almost 12 years ago
Jonathan CLARKE wrote:
It's a little more complicated than I expected. We should discuss in two others issues:Nicolas PERRON wrote:
Besides, using rudder-agent instead of rudder-cfengine imply to check differencies between the both of them.
I first analyze show me that:
- init daemon and default are differents: not the same name (cfengine-community and rudder-agent), a little difference in the default file.
We should keep the rudder-agent name and adapt the rudder-server-root script, and possibly common or distributePolicy Techniques.
- the BerkeleyDB's library version used are not the same.
That should not be the case!
- build options are not the same.
They look the same to me, aside from an extra variable "BERKELEY_DB_LIB=-ldb".
Also, the main difference is that rudder-agent adds initial promises management, which rudder-cfengine-community does not. And of course, on the node, initial promises are different than on the root server. Although we could merge them and use the "policy_server::" or "root_server::" classes to control actions, or the bundlesequence.
Updated by Nicolas PERRON almost 12 years ago
It's a little more complicated than I expected. We should discuss in two others issues:
All necessary work about merging initial promises in order to replace rudder-cfengine-community has been made. It remains nova initial promises but it can be done later.
Updated by Nicolas PERRON over 11 years ago
- % Done changed from 50 to 90
- The root inventory wasn't send to the webapp
- After a migration, some entries wasn't present and prevent to search for the server in the Node management section.
- Some CFEngine reports were missing
Now, most of the work has been done.
Updated by Nicolas PERRON over 11 years ago
I suppose this ticket could be considered as done now, isn't it ?
Updated by Jonathan CLARKE over 11 years ago
Nicolas PERRON wrote:
I suppose this ticket could be considered as done now, isn't it ?
It seems to me unlikely this was fixed in version 2.3.9, since it's only on the 2.4 branch. Can you amend please? (I think this should be 2.4.0~beta3)
There are a couple of commits attached to it, so they need a Technical Review. Can you ask François to do this once the version is fixed?
Updated by Nicolas PERRON over 11 years ago
- Target version changed from 2.3.9 to 2.4.0~beta4
Jonathan CLARKE wrote:
Nicolas PERRON wrote:
I suppose this ticket could be considered as done now, isn't it ?
It seems to me unlikely this was fixed in version 2.3.9, since it's only on the 2.4 branch. Can you amend please? (I think this should be 2.4.0~beta3)
There are a couple of commits attached to it, so they need a Technical Review. Can you ask François to do this once the version is fixed?
Of course, this was a 2.4 bug, I don't know why it has been changed.
Updated by Nicolas PERRON over 11 years ago
- Status changed from Discussion to Pending technical review
- % Done changed from 90 to 100
Updated by Nicolas CHARLES over 11 years ago
The part I've done with Francois (it was pair-programming) looks great, but I'd like an external look at it
Updated by Vincent MEMBRÉ over 11 years ago
I did the technical review of first commit as it was a pair programming commit of François and Nicolas.
I found a misstake in NodeConfigurationServiceImpl, when updating root node configuration its "isPolicyServer" attribute was defined to false, but root server is definetely a policy server.
I should be set to true
I commited the fix.
Except that typo, everything looks valid to me, thank you Nicolas and François!
Updated by Vincent MEMBRÉ over 11 years ago
Second commit seems valid too, Thank you again Nicolas and François!
Updated by Jonathan CLARKE over 11 years ago
- Status changed from Pending technical review to 10
Updated by Jonathan CLARKE over 11 years ago
- Status changed from 10 to Released
Updated by Nicolas PERRON about 11 years ago
- Project changed from Rudder to 34
- Category deleted (
11)
Updated by Benoît PECCATTE about 9 years ago
- Project changed from 34 to Rudder
- Category set to Packaging