Default policies don't work out of the box.

[bahamat]

The following cases should work:

• cfengine3 bootstrap to itself
• cfengine3 bootstrap to cfengine3
• cfengine3 bootstrap to cfengine-community on Debian
• cfengine3 bootstrap to cfengine-community on RHEL/CentOS
• cfengine-community on Debian bootstrap to cfengine3
• cfengine-community on RHEL/CentOS bootstrap to cfengine3

[tzz]

The necessary fixes are in https://github.com/cfengine/masterfiles but not core.git (since core.git/masterfiles will be removed in 3.6). So fixing policy issues will require one of these solutions:

• make one-time fixes in core.git/masterfiles that will be obsolete with 3.6 (ouch)
• start using https://github.com/cfengine/masterfiles which will make the Debian package diverge from the CFEngine-released package significantly
• move to 3.6 (ugh)

My personal preference is to use https://github.com/cfengine/masterfiles but I can see the risk in that approach, so let me know what you think.

[basvandervlies]

I just did some tests and cf-agent --bootstrap <server> does not work on debian systems. Due to the face that sys,workdir/inputs is a symbolic link to /etc/cfengine3. The `failsafe.cf`` is properly created in /etc/cfengine3. Then it fails with:

root# cf-agent --bootstrap r7n15
2013-10-28T13:47:46+0100   notice: R: This autonomous node assumes the role of voluntary client
2013-10-28T13:47:46+0100   notice: R: Failed to copy policy from policy server at 145.101.32.29:/var/cfengine/masterfiles
       Please check
       * cf-serverd is running on 145.101.32.29
       * network connectivity to 145.101.32.29 on port 5308
       * masterfiles 'body server control' - in particular allowconnects, trustkeysfrom and skipverify
       * masterfiles 'bundle server' -> access: -> masterfiles -> admit/deny
       It is often useful to restart cf-serverd in verbose mode (cf-serverd -v) on 145.101.32.29 to diagnose connection issues.
       When updating masterfiles, wait (usually 5 minutes) for files to propagate to inputs on 145.101.32.29 before retrying.
2013-10-28T13:47:46+0100   notice: R: Did not start the scheduler
2013-10-28T13:47:46+0100    error: Bootstrapping failed, no input file at '/var/lib/cfengine3/inputs/promises.cf' after bootstrap

I deleted the symlink and make inputs a real directory and everything work as expected.

[tzz]

Could we use a hard link instead of a symlink?

[basvandervlies]

no unix handbook -) Hardlinks does not work for different filesystems

On 28 okt. 2013, at 14:09, Ted Zlatanov notifications@github.com wrote:

Could we use a hard link instead of a symlink?

—
Reply to this email directly or view it on GitHub.

---

SURFsara has a new telephone number: +31 20 800 1300.

Bas van der Vlies
| Operations, Support & Development | SURFsara | Science Park 140 | 1098 XG Amsterdam
| T +31 (0) 20 800 1300 | bas.vandervlies@surfsara.nl | www.surfsara.nl |

[basvandervlies]

@tzz it is cfengine that prevents this info: Path '/var/lib/cfengine3/inputs' is a symlink. Unable to move it aside without move_obstructions is set. I think cfengine can not handle this copy to symlinked directory. failsafe.cf is properly created in /etc/cfengine3.

[tzz]

OK, my earlier comment about general direction is still standing. How are we going to patch these cases in general?

For this one specifically, I think move_obstructions should be set in masterfiles appropriately to handle symlinks. Would that fix the problem?

[basvandervlies]

move_obstructions is not the solution that will replace the link with a directory. So /etc/cfengine3 will be obsoleted after bootstrap is run. CFengine prevent to copy to a symbolic that points to a directory. Someone has implemented this and i do not the reason behind it.

We have to ask the debian maintainers if we van use this approach. Link /etc/cfengine to sys.workdir/inputs. There are several debian packages that do the reverse approach:

14:58 r7n15.lisa.surfsara.nl:/etc 
root# find /etc -type l  | xargs ls -l | grep var
lrwxrwxrwx 1 root root  27 Sep  7  2012 /etc/joe/editorrc -> ../../var/lib/misc/editorrc
lrwxrwxrwx 1 root root  31 Apr 18  2013 /etc/sgml/catalog -> /var/lib/sgml-base/supercatalog
lrwxrwxrwx 1 root root 39 Feb 22  2012 /etc/fonts/conf.d/30-defoma.conf -> /var/lib/defoma/fontconfig.d/fonts.conf
lrwxrwxrwx 1 root root 13 Dec  8  2009 /etc/motd -> /var/run/motd
lrwxrwxrwx 1 root root 38 Dec  8  2009 /etc/pango/pangox.aliases -> /var/lib/defoma/pango.d/pangox.aliases

else we have to modify the generated failsafe.code to see if sys.workdir/inputs is a symbolic link or real directory.

[basvandervlies]

@tzz maybe this is the solution. the copy_from has an attribute type_check. The scenario is that if we set type_check : false and the symlink is pointing to directory we just copy else we display the default errorr message. This require to patch the cfengine source

[tzz]

Can you suggest what files need to be patched and how? I'm not sure I understand the right solution.

[basvandervlies]

This email was not archived:

Some the failsafe.cf that is generated by cf-agent —bootstrap, places the file in /etc/cfengine3 and does not display the message that sys.workdir/inputs is a symbolic link. It is not consistent behavior.  Is just the difference between stat() or lstat()  function call.

[bahamat]

I think that the issue of $(sys.workdir)/inputs being a symlink to /etc/cfengine3 is something that needs to be revisted.

It's done that way to help comply with Debian policy, but it clearly doesn't work. So we need something different.

My proposal would be to leave $(sys.workdir)/inputs as an actual directory and make /etc/cfengine3 a symlink to $(sys.workdir)/masterfiles)` (the contents of inputs is not meant to be user editable anyway). We should get Antonio's feedback on this.

[basvandervlies]

sys.workdir/inputs can now be a symlink to a directory in the cfengine core. See:

• cf-agent --bootstrap fails on Debian systems. cfengine/core#1050

I will merge pull request: #42
This is just the back port of the same patch.

[bahamat]

Will this work for masterfiles as well?

[basvandervlies]

It works for all symlinked directories

On 29 okt. 2013, at 08:59, Brian Bennett notifications@github.com wrote:

Will this work for masterfiles as well?

—
Reply to this email directly or view it on GitHub.

---

SURFsara has a new telephone number: +31 20 800 1300.

Bas van der Vlies
| Operations, Support & Development | SURFsara | Science Park 140 | 1098 XG Amsterdam
| T +31 (0) 20 800 1300 | bas.vandervlies@surfsara.nl | www.surfsara.nl |

[tzz]

Is this fixed, then?

[bahamat]

I don't know if all of the usage cases have been tested. I'd like to keep this open until each one is checked off.

[tzz]

@basvandervlies @bahamat @vohi does cfengine/core#1050 need to be backported to 3.5.x? If so I can open the PR+ticket.

[basvandervlies]

@tzz That would be nice +1.

[basvandervlies]

@bahamat, @tzz and others. Due this project i am testing the bootstrap procedure. Correct me if i am wrong but this will only work if the client and policy_server uses the same sys.workdir. So our debian package can never use the bootstrap procedure if the policy server uses other sys.workdir. This is due the generated '''failsafe.cf'''.

[basvandervlies]

@bahamat @tzz the patch is reverted due to security issues: cfengine/core#1050. So we have also to delete the patch and make '''/etc/cfengine'' to '''sys.workdir/inputs'''. Then everything works as expected.

[basvandervlies]

To prevent the symlink attack i just submitted a pull request: #50

I am still in favor of reverting the symlink:

• /etc/cfengine ---> sys,workdir/inputs

I do not know if this acceptable according the Debian package policies.

[basvandervlies]

Mark Simons just had hangout with Mark Burgess and he is in favor of /etc/cfengine3 ---> sys,workdir/inputs. So one of the debian package developers have to ask if this acceptable. If this acceptable then we have a working bootstrap.

[tzz]

@basvandervlies can you please explain exactly what is the proposed solution? I think you're proposing a symlink but it's hard to tell.

[basvandervlies]

@tzz Your right it is a symlink ;-) from /etc/cfengine3 to sys.workdir/inputs. Debian sys.workdir=/var/lib/cfengine3.
If the symlink is from sys.workdir/inputs to /etc/ecfengine3 we need pull request cfengine/core#1050

[tzz]

I understand. So Debian will have to find the symlink acceptable and we'll wait for their decision, probably from Antonio?

[basvandervlies]

@tzz yes we have to wait for Antonio's answer and provide a mechanism for the transition from old to new situation. remove the the sysmlink sys,workdir/inputs, copy /etc/cfengine3 to sys.workdir/inputs and make the symlink.

[basvandervlies]

There is a pull request cfengine/core#1260 that add two configure options:

• --with-masterdir= (default: $(sys,workdir)/masterfiles, variable = $(sys.masterdir)
• --with-inputdir= (default: $(sys.workdir)/inputs, variable = $(sys.inputdir)

This is will solve the /etc/cfengine3 symbolic issue with bootstrap on the client

[tzz]

cfengine/core#1260 is merged :)

[basvandervlies]

@tzz Thanks for the support!!! We have to wait fot 3.6 ;-)

[basvandervlies]

The masterdir/inputdir is now merge cfengine/core/#1293. So one hurdle to go

[bahamat]

This can be reconciled with a shortcut promise.

[bahamat]

This also applies to the masterfiles package, so removing blocker tag.

[bahamat]

• Debian cfengine3 -> cfengine3 works as expected.
• Cross platform (i.e., cfengine3 <-> cfengine-community) is currently untested.