On Sep 28, 5:02 pm, rvlinden <rene.vanderlinde...@gmail.com> wrote:
> Hi,
>
> I'm using puppet 2.7.3 on RHEL/CentOS and I have an issue which is now
> a big blocking issue within my environment. What I'm trying to
> accomplish wit puppet is a create a mountpoint, mount a filesystem on
> it and install an application on that filesystems are set proper user/
> group and permissions on it, but it fails big time.
>
> The issues I currently run into are about 3 things
>
> 1. The file type does not allow multiple directories to be created at
> once ('mkdir -p')Surely that's a convenience issue, not a blocker. In any event, I am confident that if all the parent directories are intended to have the same properties then it should be possible to use a recursive defined type to ensure all are present. > 2. exec & file type create autorequire dependensies which creates > dependency cycles See below. > 3. Puppet does not allow duplicate resouces Indeed not. How would that make sense? It does provide virtual resources, which can address some of the scenarios where people otherwise would want to duplicate resource declarations. You declare the resource once, virtually, for all nodes that could possibly need it, then you realize that resource every place where otherwise you would declare it. After reading the rest of your post, however, I suspect the problem is not really duplicate resources. My guess is that your complaint is really that Puppet cannot manage both a mount point and the root of the filesystem mounted on it. These are distinct resources, but the underlying operating system design makes it difficult to distinguish them, and Puppet cannot do so. Indeed, the mount point's properties are invisible -- and thus unmanageable -- when a file system is mounted on it, so I attribute this issue to the OS, not to Puppet. [...] > These are the relations I created myself within puppet > > 1. exec mkdir /a/b/c => mount /a/b/c => file /a/b/c > 2. exec logical volume => mount /a/b/c > > This setup does not result in a cycle, but when puppet adds an > autorequire between exec mkdir /a/b/c and file a/b/c, it causes the > whole thing to cycle. > > Quote from the manual > > Autorequires: If Puppet is managing an exec’s cwd or the executable > file used in an exec’s command, the exec resource will autorequire > those files. If Puppet is managing the user that an exec should run > as, the exec resource will autorequire that user. Right, but how does that explain the behavior you see? Surely /a/b/c is not the working directory or executable of your Exec. I would guess that it is instead Mount autorequiring its mount point that is causing the cycle. That's not documented (which constitutes a documentation bug if Puppet does this), but it seems sort of logical. Also, there is a feature request asking for this (http:// projects.puppetlabs.com/issues/5015), though it is marked "Code Insufficient". If you can verify that behavior, however, then I would file a bug ticket on it, as at minimum there is a documentation bug. Alternatively, if you can confirm that the Exec is the source of the autorequire then I would definitely file a ticket for that, as it would unquestionably be buggy. > I don't mind if I have to rewrite my code or start from scratch, but I > need help to create my mountpoint location with root:root/755 and > after mounting allow the same location to have a different owner:group/ > permissions. If autorequirements are indeed the root of the problem then the easiest thing to do might be to declare explicit relationships in the correct direction. Autorequirements should always be overridden by explicitly declared ones. If you find that to not be the case then I urge you to file a bug ticket about it. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
