kickstart bootstrapping

[Natxo Asenjo]

hi,

I am learning cf3 finally -cf2 has just been working too well :-).

I am bootstrapping centos hosts like this in the %post section of our kickstart.cfg procedure:

wget -O /etc/yum.repos.d/cfengine-community.repo  http://192.168.5.1/mrepo/local/cfengine-community.repo
wget -O /etc/pki/rpm-gpg/cfengine.key http://192.168.5.1/mrepo/local/cfengine.key
yum update -y

# install cfengine agents
yum install -y cfengine-community
# bootstrap it
/var/cfengine/bin/cf-agent --bootstrap 192.168.5.1 > /root/bootstrapped.txt 2>&1
echo "192.168.5.1" > /var/cfengine/policy_server.dat

If I do not create the /var/cfengine/policy_server.dat file, after rebooting the centos hosts do not know where to get its policy from.

Is this the correct way of doing it? It works for me, but maybe it is not the right way. I could not find any info about it.

Thanks in advance.

--
Groeten,
natxo

[Neil Watson]

On Wed, Apr 01, 2015 at 10:03:37PM +0200, Natxo Asenjo wrote:
>
>
> # install cfengine agents
> yum install -y cfengine-community
> # bootstrap it
> /var/cfengine/bin/cf-agent --bootstrap 192.168.5.1 >
> /root/bootstrapped.txt 2>&1

This should populate policy_server.dat. It not, then the bootstrap must
have failed.


--
Neil H Watson
Sr. Partner, Architecture and Infrastructure
CFEngine reporting: https://github.com/evolvethinking/delta_reporting
CFEngine policy: https://github.com/evolvethinking/evolve_cfengine_freelib
CFEngine and vim: https://github.com/neilhwatson/vim_cf3
CFEngine support: http://evolvethinking.com

[Natxo Asenjo]

--
You received this message because you are subscribed to the Google Groups "help-cfengine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to help-cfengine+unsubscribe@googlegroups.com.
To post to this group, send email to help-c...@googlegroups.com.
Visit this group at http://groups.google.com/group/help-cfengine.
For more options, visit https://groups.google.com/d/optout.

--

--
Groeten,
natxo

[Natxo Asenjo]

On Wed, Apr 1, 2015 at 10:19 PM, Natxo Asenjo <natxo....@gmail.com> wrote:

sorry, pressed send too fast.
 

On Wed, Apr 1, 2015 at 10:18 PM, Neil Watson <cfen...@watson-wilson.ca> wrote:

On Wed, Apr 01, 2015 at 10:03:37PM +0200, Natxo Asenjo wrote:

  # install cfengine agents
  yum install -y cfengine-community
  # bootstrap it
  /var/cfengine/bin/cf-agent --bootstrap 192.168.5.1 >
  /root/bootstrapped.txt 2>&1

This should populate policy_server.dat. It not, then the bootstrap must
have failed

yes, agreed. But it fails every time, that's why I resorted to creating the file like that.

 

--

--
Groeten,
natxo

[Natxo Asenjo]

On Wed, Apr 1, 2015 at 10:21 PM, Natxo Asenjo <natxo....@gmail.com> wrote:

On Wed, Apr 1, 2015 at 10:18 PM, Neil Watson <cfen...@watson-wilson.ca> wrote:

On Wed, Apr 01, 2015 at 10:03:37PM +0200, Natxo Asenjo wrote:

  # install cfengine agents
  yum install -y cfengine-community
  # bootstrap it
  /var/cfengine/bin/cf-agent --bootstrap 192.168.5.1 >
  /root/bootstrapped.txt 2>&1

This should populate policy_server.dat. It not, then the bootstrap must
have failed

yes, agreed. But it fails every time, that's why I resorted to creating the file like that.

this is the 'log' of the error:

# cat bootstrapped.txt
2015-04-01T22:24:05+0200   notice: /default/cfe_internal_update/commands/'/usr/bin/systemctl restart cfengine3'[0]: Q: ".../systemctl rest": Running in chroot, ignoring request.

R: This autonomous node assumes the role of voluntary client
R: Updated local policy from policy server
R: Started the scheduler
2015-04-01T22:24:06+0200   notice: /default/cfe_internal_call_update/commands/'"/var/cfengine/bin/cf-agent" -f update.cf'[0]: Q: ".../cf-agent" -f u": Running in chroot, ignoring request.
Q: ".../cf-agent" -f u": Running in chroot, ignoring request.

2015-04-01T22:24:07+0200    error: Bootstrapping failed, cf-execd is not running

So that's why it's failing.

--

Groeten,
natxo

[Bryan Burke]

Interesting; this appears to be exactly the way we install/bootstrap cfengine, and we don't have any issues:

rpmkeys --import http://cfengine.com/pub/gpg.key

cat <<EOF >/etc/yum.repos.d/cfengine-community.repo

[cfengine-repository]

name=CFEngine

baseurl=http://cfengine.com/pub/yum/\$basearch/

enabled=0

gpgcheck=1

EOF

restorecon -R /etc/yum.repos.d

yum -y install cfengine-community

/var/cfengine/bin/cf-agent --bootstrap <policy-server>

I assume they are both going through the cfe_internal_update, but I'm not positive.

-- 

Bryan

--

You received this message because you are subscribed to the Google Groups "help-cfengine" group.

To unsubscribe from this group and stop receiving emails from it, send an email to help-cfengin...@googlegroups.com.

[Natxo Asenjo]

Hi Bryan,

On Tue, Apr 14, 2015 at 7:54 AM, Bryan Burke <bbur...@gmail.com> wrote:

Interesting; this appears to be exactly the way we install/bootstrap cfengine, and we don't have any issues:

rpmkeys --import http://cfengine.com/pub/gpg.key

cat <<EOF >/etc/yum.repos.d/cfengine-community.repo

[cfengine-repository]

name=CFEngine

baseurl=http://cfengine.com/pub/yum/\$basearch/

enabled=0

gpgcheck=1

EOF

restorecon -R /etc/yum.repos.d

yum -y install cfengine-community

/var/cfengine/bin/cf-agent --bootstrap <policy-server>

I assume they are both going through the cfe_internal_update, but I'm not positive.

is this for centos/rhel 7? I have  not yet tried running restorecon, but I do no think it matters because the rpm gets installed ok.

Bootstrapping centos 6 works fine, by the way.

it's not a major problem, just slightly annoying  until I found out what the problem was.

--

regards,

Natxo

[Bryan Burke]

Yep, this is on rhel7. I haven't gotten to test it with rhel7.1 yet, though.

--

[Bryan Burke]

So, this is old, but I tracked down the issue.

This was working for us just fine for a long time, then I updated the masterfiles to their latest (3.7.x tag) in preparation for testing and rolling out 3.7. You note in the log above that systemctl is complaining about being in a chroot environment. As best as I can tell, the installation of the RPM causes a "systemctl (re)start cfengine3" (the first chroot error we see), and then the bootstrap process calls cf-agent -f update.cf, which in turn calls systemctl restart cfengine3 (because it's still not running).

This is all fine, because we're in a installation/pre-first-boot environment and don't need cfengine running. However, it appears to me that the "cf-agent -f update.cf" fails due to that command failing. As a consequence, the bootstrap appears to fail, because the update run failed, even though all files are copied, etc. Thus, we also found that creating the policy_server.dat file fixed our problems.

Having said that, is there any good path to fix this? I imagine this is a common enough scenario to warrant some kind of upstream handling? I tried to run "cf-agent -N systemd --bootstrap ...", but that of course would not unset a hard class. The simplest (conceptually) solution would be to have a class one could set when running in such an environment that would get cf-agent to not attempt to restart the systemd service. Or perhaps reduce the bootstrap process to NOT run cf-agent -f update.cf. As long as it gets enabled, it's ok, right?

If an upstream fix isn't deemed appropriate, however, I guess we could continue to manually create our policy_server.dat files, or use the %post section to create a "first boot" type script that does all of this in a non-chroot environment.

Any thoughts?

[Nick Anderson]

On 11/17/2015 06:46 PM, Bryan Burke wrote:
> Or perhaps reduce the bootstrap process to NOT run cf-agent -f
> update.cf. As long as it gets enabled, it's ok, right?

We have had a couple of internal discussions about that execution of
update.cf from bootstrap. I opened a ticket proposing its removal from
the bootstrap policy here: https://dev.cfengine.com/issues/7660

I added you as a watcher, I hope you can add some opinions on the ticket.

[Natxo Asenjo]

hi Bryan,

On Wed, Nov 18, 2015 at 1:46 AM, Bryan Burke <bbur...@gmail.com> wrote:

So, this is old, but I tracked down the issue.

This was working for us just fine for a long time, then I updated the masterfiles to their latest (3.7.x tag) in preparation for testing and rolling out 3.7. You note in the log above that systemctl is complaining about being in a chroot environment. As best as I can tell, the installation of the RPM causes a "systemctl (re)start cfengine3" (the first chroot error we see), and then the bootstrap process calls cf-agent -f update.cf, which in turn calls systemctl restart cfengine3 (because it's still not running).

This is all fine, because we're in a installation/pre-first-boot environment and don't need cfengine running. However, it appears to me that the "cf-agent -f update.cf" fails due to that command failing. As a consequence, the bootstrap appears to fail, because the update run failed, even though all files are copied, etc. Thus, we also found that creating the policy_server.dat file fixed our problems.

 awesome work. Thanks for taking the time for looking into it.
 

Having said that, is there any good path to fix this? I imagine this is a common enough scenario to warrant some kind of upstream handling? I tried to run "cf-agent -N systemd --bootstrap ...", but that of course would not unset a hard class. The simplest (conceptually) solution would be to have a class one could set when running in such an environment that would get cf-agent to not attempt to restart the systemd service. Or perhaps reduce the bootstrap process to NOT run cf-agent -f update.cf. As long as it gets enabled, it's ok, right?

 

If an upstream fix isn't deemed appropriate, however, I guess we could continue to manually create our policy_server.dat files, or use the %post section to create a "first boot" type script that does all of this in a non-chroot environment.

I guess that as soon as more RHEL/centos organizations move to 7 then the 'pressure' to 'fix' this will be higher.

As long as it's documented that the fix is to create the policy_server.dat then I do not think this is a problem at this point, but for new cfengine environments it can be quite a wtf moment until you find this mail thread ;-)

--
Groeten,
natxo