Project

General

Profile

Actions
Copy link

Bug #15188

closed

Allow disabling the agent without stopping cf-serverd

Added by Nigel Mundy almost 5 years ago. Updated over 4 years ago.

Status:
Released
Priority:
N/A
Assignee:
Alexis Mousset
Category:
Agent
Target version:
6.0.0
Pull Request:
https://github.com/Normation/rudder-p...
Severity:
Major - prevents use of part of Rudder | no simple workaround
UX impact:
User visibility:
Operational - other Techniques | Rudder settings | Plugins
Effort required:
Small
Priority:
63
Name check:
To do
Fix check:
To do
Regression:

Description

we have found that if you disable the agent on the root server, this prevents cf-serverd from starting, which I would guess would be intended if there was only an agent on the machine.

However, being the root server, with cf-serverd not running this then means that no agents can connect to it for policy updates, when the intended action was to only stop the root server's agent from getting a policy update.

Some form of logic needs to be devised which means that cf-serverd is not stopped if it is the rudder root server.

the disabled cf-serverd persists across a reboot if the agent is still disabled. (ie /opt/rudder/etc/agent-disabled exists)

The only current workaround is to ensure the agent is never disabled on the root server (which we usually do as a matter of course for things like distro upgrades, to prevent a policy run reverting repository lists part way)

OS: Debian 9 (Stretch), so processes being started (or disabled) by systemd units.

Subtasks 2 (0 open — 2 closed)

User story #16168: Remove cf-serverd kill switch on agent disabledReleasedAlexis MoussetActions
User story #16169: Add an option to not stop cf-serverd on agent stopReleasedAlexis MoussetActions

Related issues 1 (1 open — 0 closed)

Related to Rudder - Architecture #15191: Separate remote-run server from policy serverNewActions
Actions
Copy link
 #1

Updated by Vincent MEMBRÉ almost 5 years ago

  • Target version set to 5.0.13

I think you're right and maybe only the agent should be disabled on root server ? (and also relay ??)

@Team, Would it be possible ?? what do you think of it ?

Actions
Copy link
 #2

Updated by Alexis Mousset almost 5 years ago

  • Subject changed from cf-serverd not starting on root server to Allow disabling the agent without stopping cf-serverd
  • Category changed from Server components to Agent
  • Target version changed from 5.0.13 to 6.0.0~beta1
  • User visibility set to Operational - other Techniques | Rudder settings | Plugins
  • Priority changed from 0 to 26

Thank you for reporting this, there is indeed a problem with current agent and cf-serverd's service behaviour.

Current situation

  • The rudder-agent service starts two daemons:
    • cf-serverd wich:
      • allows trigerring a remote-run on all nodes
      • serves policy files from relays and root servers (which is definitely a server feature)
    • cf-execd which regularly triggers an agent run
  • disabling the agent also prevents both agent services (cf-execd and cf-serverd) from starting
  • there is an option is disable command to also stop the agent service

Problems:

  • Keeping a service running but preventing it from restarting makes not sense.
  • It is unexpected that acting on the agent would break policy server, and worse that it is not possible to keep it working with a disabled agent.
  • There is a clash between cf-serverd usages between simple nodes and servers. It is part of agent (package, service, etc). but also acts as a server component.

Short term changes

  • Make cf-serverd (and cf-execd for consistency) ignore agent state:
    • change policies to ignore disable flag
    • change systemd unit to ignore disable flag
  • rudder agent stop or rudder agent disable -s will still stop cf-execd and cf-serverd

Long term changes

This would requires wider changes to Rudder.

We could run two separate cf-serverd daemons, one for remote-run and one as policy-server, probably on different ports. This would allow better service organization and avoid unexpected behaviour.

What do you think about this solution?

Actions
Copy link
 #3

Updated by Alexis Mousset almost 5 years ago

Actions
Copy link
 #4

Updated by Alexis Mousset over 4 years ago

  • Target version changed from 6.0.0~beta1 to 6.1.0~beta1
  • Priority changed from 26 to 25
Actions
Copy link
 #5

Updated by François ARMAND over 4 years ago

  • Target version changed from 6.1.0~beta1 to 6.0.0
  • Priority changed from 25 to 50
Actions
Copy link
 #6

Updated by Benoît PECCATTE over 4 years ago

  • Effort required set to Small
  • Priority changed from 50 to 64

The short term version is small

Actions
Copy link
 #7

Updated by Benoît PECCATTE over 4 years ago

  • Status changed from New to In progress
  • Assignee set to Benoît PECCATTE
Actions
Copy link
 #8

Updated by Benoît PECCATTE over 4 years ago

  • Status changed from In progress to Pending technical review
  • Assignee changed from Benoît PECCATTE to Alexis Mousset
  • Pull Request set to https://github.com/Normation/rudder-packages/pull/2146
Actions
Copy link
 #9

Updated by Benoît PECCATTE over 4 years ago

  • Status changed from Pending technical review to Pending release
Actions
Copy link
 #10

Updated by Alexis Mousset over 4 years ago

  • Status changed from Pending release to Released
  • Priority changed from 64 to 63

This bug has been fixed in Rudder 6.0.0 which was released today.

Actions
Copy link

Also available in: Atom PDF