policy_server.dat IP to DNS

[Markus Rexhepi-Lindberg]

Hello,

We have a lot of servers that was bootstrapped quite some time ago and they have the IP address instead of the DNS address of the policy server in their /var/cfengine/policy_server.dat file. Is there a recommended way to migrate these to use the DNS address instead? I was thinking that perhaps a simple bundle to update the file would suffice but I wanted to check with the community first to find out if there is a better way.

BR/
Markus

[Marco Marongiu]

Hello Markus

I think the file by design contains the IP address, and not the hostname, to avoid that a failure in name resolution could affect ability of the client to connect to the server and fetch policy updates. The documentation itself indicates that the file contains the IP of the policy server, not the name. See https://docs.cfengine.com/docs/3.24/overview-directory-structure.html#policy_server-dat

Ciao,
-- bronto

[craig.c...@northern.tech]

Hi Markus,
The policy_server.dat file will include what is given to cf-agent --bootstrap. As of CFEngine 3.11 and newer it is possible to use a hostname.

This commit added this ability: https://github.com/cfengine/core/commit/1a45d2043615c3627069b893759e9b7d275b9938

Using a hostname has benefits and drawbacks.
The benefit is that the DNS entry could change and you could avoid having to rebootstrap to a different IP address. The caveat here is that long-running processes like cf-serverd may need a restart in order to do the name to IP translation.
Drawbacks of using a hostname are if DNS doesn't work out, which certainly is not uncommon.

I do think that using an IP address is a bit more reliable.
Instead of manipulating that file you could instead re-bootstrap with a command like cf-agent --no-lock --inform --bootstrap <newip>.

Let us know what you think and how you proceed.

-Craig

[Nick Anderson]

I do think that using an IP address is a bit more reliable. Instead of manipulating that file you could instead re-bootstrap with a command like cf-agent –no-lock –inform –bootstrap <newip>.

I typically advise against a re-bootstrap. It's a bit heavy handed, and if it fails it can leave you in worse position.

When you --bootstrap , the content in $(sys.input_dir) is wiped and completely re-seeded. If your bootstrap fails you will not have a full policy in inputs, where as if you re-write policy_server.dat your existing policy will remain in place and the next time the agent starts it will resolve the new value for policy server.

[Marco Marongiu]

On 20/10/2025 17:06, craig.comstock via help-cfengine wrote:
> The policy_server.dat file will include what is given to cf-agent --
> bootstrap. As of CFEngine 3.11 and newer it is possible to use a
> hostname.

Then, I guess, an update of the documentation is in order ☺️

Ciao!
-- bronto

[Markus Rexhepi-Lindberg]

When you --bootstrap , the content in $(sys.input_dir) is wiped and completely re-seeded. If your bootstrap fails you will not have a full policy in inputs, where as if you re-write policy_server.dat your existing policy will remain in place and the next time the agent starts it will resolve the new value for policy server.

Does this mean next time cf-agent executes or when the cf daemons (re)starts? 

[Nick Anderson]

When you –bootstrap , the content in $(sys.input_dir) is wiped and completely re-seeded. If your bootstrap fails you will not have a full policy in inputs, where as if you re-write policy_server.dat your existing policy will remain in place and the next time the agent starts it will resolve the new value for policy server.

Does this mean next time cf-agent executes or when the cf daemons (re)starts?

Yes the next time cf-agent is executed from it's perspective it will have the new policy server address.

The daemons each have their own perspective. When they re-evaluate the policy they should also re-load the policy_server.dat. The daemon might realize the need to re-evaluate it's policy on it's own, or it might not and it might need to be re-started, it depends on specifically what changed (actual policy .cf files or external data), I don't think that the daemons key need for policy re-load in relation to a policy_server.dat change.

The value derived from policy_server.dat is used in default MPF access rules so for example cf-serverd having a stale value would impact the new policy servers ability to access the host (if you have a case where the hub is collecting things from the client, e.g. enterprise or some policy to copy files from the client).

[Nick Anderson]

Yep.

https://github.com/cfengine/documentation/pull/3533


--
Nick Anderson | Doer of Things | (+1) 785-550-1767 | https://northern.tech

[Markus Rexhepi-Lindberg]

Changing the IP address to a DNS address in the policy_server.dat for all the clients worked nicely in my environment.

I did it using the following bundle:

bundle agent migrate_policy_server_dat
{
  files:
    "$(sys.workdir)/policy_server.dat"
      create => "false",
      edit_line => replace_policy_server_strings();
}

bundle edit_line replace_policy_server_strings
{
  replace_patterns:
    "192.0.2.10"
      replace_with => string("cfhub01.example.com");
}

Thanks for all the help!