symlinks and the copy: directive

[Brian C. Hill]

I posted this last week; no one responded. Is there a better
way to achieve this?

I want to copy a tree of symbolic links, some of which will not
actually point to anything on some systems. Is there a way to get
cfengine to copy the symbolic link without worrying about whether the
link is 'dangling' or not?

Brian

[Paul Krizak]

According to the documentation:

nofile=kill/force
This decides what happens to links which point to non-existent
files. The default action is to remove such links, or refuse to create
them. By setting the force option you can force cfengine to make
symbolic links to files which do not exist. This is useful for setting
up links to filesystems which are not permanently mounted.

So you can presumably do something like

links:

someclass::

/some/file -> /some/other/file nofile=force

Paul Krizak 5900 E. Ben White Blvd. MS 625
Advanced Micro Devices Austin, TX 78741
Linux/Unix Systems Engineering Phone: (512) 602-8775
Microprocessor Solutions Sector

> _______________________________________________
> Help-cfengine mailing list
> Help-c...@gnu.org
> http://lists.gnu.org/mailman/listinfo/help-cfengine

[Brian C. Hill]

Hi Paul, et al,

That option works for the links directive only, and the links
directive doesn't seem to be able to do what I need done.

I am trying to copy an already-populated directory of symbolic
links from one system to another with the copy directive. Some of the
links point to files that won't exist on all systems, including the
remote server itself, and I cannot get cfengine to copy links to a
system when they files they point to don't exist on the remote server.
Is there some way to tell cfenging to copy the links and not mind what
they point to?

Brian
======================================================================

--
_____________________________________________________________________
/ Brian C. Hill bch...@bch.net http://brian.bch.net \
| UNIX Specialist BCH Technical Services http://www.bch.net |

[Paul Krizak]

Ah...I need to read more closely. I didn't see that you were working in
the "copy" area and not the "links" area.

Yeah...no ideas about how to do this with "copy"...

[Mark Burgess]

Yes - always begin with the manual.

nofile=kill/force
This decides what happens to links which point to non-existent files.
The default action is to remove such links, or refuse to create them. By
setting the force option you can force cfengine to make symbolic links
to files which do not exist. This is useful for setting up links to
filesystems which are not permanently mounted.

[Mark Burgess]

Actually, on closer examination, this is the default behaviour for copy,
when copying links, as far as I can see. I just tested it and it works.

M

[Brian C. Hill]

Hi Mark / everyone,

I get this when running cfagent -v on the client. It won't
copy the links because the server is complaing that they don't
point to anything. That's true on the server, but it won't be
in the particular case of this client.

WHen you say that it is the default behavior, I assume
you mean that the copy: directive doesn't care whether the
links resolve or not. Did you mean something else? Is that
what worked for you?

Brian

------------------ ------------------ ------------------ ------------------

cfengine:: Server returned error: unable to stat file
/usr/local/bin/openssl
cfengine:: (Can't stat /usr/local/bin/openssl)
cfengine:: Server returned error: unable to stat file
/usr/local/bin/c_rehash
cfengine:: (Can't stat /usr/local/bin/c_rehash)
cfengine:: Server returned error: unable to stat file /usr/local/bin/go
cfengine:: (Can't stat /usr/local/bin/go)

======================================================================

--

[Mark Burgess]

On Wed, 2005-12-21 at 16:24 -0800, Brian C. Hill wrote:
> Hi Mark / everyone,
>
> I get this when running cfagent -v on the client. It won't
> copy the links because the server is complaing that they don't
> point to anything. That's true on the server, but it won't be
> in the particular case of this client.
>
> WHen you say that it is the default behavior, I assume
> you mean that the copy: directive doesn't care whether the
> links resolve or not. Did you mean something else? Is that
> what worked for you?

Ah - I haven't tried that way around. Cfagent will create a link that
does not point to an existing file if asked to do so. But if there is a
link that doesn't point to anywhere on the server, that might cause the
access control to balk. I can look into this in a few days. But why not
simply use links on client side rather than try to copy an image -- it
doesn't make much sense to have links pointing no where on a server,
just for distribution.

M

[Mark Burgess]

ok - I confirm that this is a bug/typo in cfservd. A patch has been
applied to the source.

M

On Wed, 2005-12-21 at 16:24 -0800, Brian C. Hill wrote:

> Hi Mark / everyone,
>
> I get this when running cfagent -v on the client. It won't
> copy the links because the server is complaing that they don't
> point to anything. That's true on the server, but it won't be
> in the particular case of this client.
>
> WHen you say that it is the default behavior, I assume
> you mean that the copy: directive doesn't care whether the
> links resolve or not. Did you mean something else? Is that
> what worked for you?
>

> Brian

[Brian C. Hill]

Thanks Mark!

Brian
======================================================================

--

[Brian C. Hill]

I tested 2.18 and the problem still exists. Is the fix
not in 2.18?

[Brian C. Hill]

Never mind. It works (user error).

Thanks again.

Brian
======================================================================

[Brian C. Hill]

Hi Mark, et al,

There turns out to be one wrinkle still not addressed.

The change you made fixes the case where an entire directory
tree is pushed out that contains symlinks. The case where only a
symblic link it specifically being copied still fails.

cpoy:
/dir server=master.domain.tld dest=/dir

(works)

/dirs/symlink server=master.domain.tld dest=/dirs/symlink

(fails)

Can this be fixed, too?

[Mark Burgess]

As far as my testing indicates. this works fine. (??)

Mark