I''m trying to manage a directory full of symlinks for our
users'' home
directories and running into problems.
Our home directories are spread out across multiple NFS partitions.
For flexibility and ease of use, we have a /u directory that contains
symlinks to each user''s specific home directory, e.g. /u/bob ->
/home/k/bob, /u/eric -> /home/b/eric, etc.
The "master" /u/ directory is on the same machine that houses our
authentication system. When a new user is created, a symlink is made
for them in /u/. We periodically push /u/ out with rsync and would
prefer to manage it with puppet. The type reference clearly states
that "you cannot currently copy links using this mechanism [the
''file''
type]", but just in case I tried every variant I could think of. I
exported /u/ from our master server so that it could be mounted with
NFS, thinking that perhaps the fileserver just couldn''t describe
symlinks but that a local copy would succeed.
file { "/u":
ensure => directory,
source => "puppet://puppet/u/", # and "/mnt/u/" for the
NFS
# experiment I mentioned
recurse => true,
links => manage
}
It''s not practical for us to manage users entirely with puppet, and
I''d prefer not having to maintain a second list of home directory
symlinks in a puppet manifest alongside the existing list of symlinks
in our master /u/ directory. I was hoping someone would have
alternative suggestions, or at least a definitive answer that I''m just
going to have to wait until symlink copying is supported.
--
eric
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 05 April 2007 21:50, Eric Peden wrote:> I''m trying to manage a directory full of symlinks for our users'' home > directories and running into problems. > > Our home directories are spread out across multiple NFS partitions. > For flexibility and ease of use, we have a /u directory that contains > symlinks to each user''s specific home directory, e.g. /u/bob -> > /home/k/bob, /u/eric -> /home/b/eric, etc. > > The "master" /u/ directory is on the same machine that houses our > authentication system. When a new user is created, a symlink is made > for them in /u/. We periodically push /u/ out with rsync and would > prefer to manage it with puppet. The type reference clearly states > that "you cannot currently copy links using this mechanism [the ''file'' > type]", but just in case I tried every variant I could think of. I > exported /u/ from our master server so that it could be mounted with > NFS, thinking that perhaps the fileserver just couldn''t describe > symlinks but that a local copy would succeed. > > file { "/u": > ensure => directory, > source => "puppet://puppet/u/", # and "/mnt/u/" for the NFS > # experiment I mentioned > recurse => true, > links => manage > } > > It''s not practical for us to manage users entirely with puppet, and > I''d prefer not having to maintain a second list of home directory > symlinks in a puppet manifest alongside the existing list of symlinks > in our master /u/ directory. I was hoping someone would have > alternative suggestions, or at least a definitive answer that I''m just > going to have to wait until symlink copying is supported.As I see it, there are at least two ways out of your dilemma: 1) Create ALL symlinks with puppet: Only one list in the puppet manifest. 2) Create the manifest from the /u/ directory. This is a little straightforward shell script. Personally I would prefer the first option, but I don''t know your environmental constraints. Regards, David - -- - - hallo... wie gehts heute? - - *hust* gut *rotz* *keuch* - - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGFhnO/Pp1N6Uzh0URAqF+AJ43QmWM1HwSIwvMvSwsgw2mCG23egCeNrL9 KS17zBgF1DSD8E1MWHRAna0=UP0h -----END PGP SIGNATURE-----
On Apr 5, 2007, at 2:50 PM, Eric Peden wrote:> [...] > It''s not practical for us to manage users entirely with puppet, and > I''d prefer not having to maintain a second list of home directory > symlinks in a puppet manifest alongside the existing list of symlinks > in our master /u/ directory. I was hoping someone would have > alternative suggestions, or at least a definitive answer that I''m just > going to have to wait until symlink copying is supported.It''s actually not that complicated to add the ability to copy symlinks in the fileserver, but it also hasn''t seemed that urgent -- I think you''re the first person to ask for it. Is there a reason you can''t use an automounter here? That''s really the right choice, and it would allow you to pretty much skip any of the hassle associated with either Puppet or these symlinks. You have a clean map from user names to nfs file sources -- put that into a ''/u'' map, enable the automounter, done. Now just modify the mount map when you add new users, and you''re done. Is there a reason you can''t do that at your site? -- To my embarrassment I was born in bed with a lady. --Wilson Mizner --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On 4/6/07, Luke Kanies <luke@madstop.com> wrote:> Is there a reason you can''t use an automounter here? That''s really > the right choice, and it would allow you to pretty much skip any of > the hassle associated with either Puppet or these symlinks. > > You have a clean map from user names to nfs file sources -- put that > into a ''/u'' map, enable the automounter, done. Now just modify the > mount map when you add new users, and you''re done. > > Is there a reason you can''t do that at your site?I appreciate the question. When I passed it along to our senior sysadmin, it sparked quite a discussion. ;) As a result of that discussion, I think I''m going to make a simple little script to build a puppet manifest from our /u/ master directory, as David suggested. Our refusal to use an automount stems from a desire for certain machines to have different subsets of the user home directories available; this cries out for management via puppet, so I think the manifest building approach will make a suitable bridge between the two paradigms. For now. Thank you both for the suggestions. -- eric
On Apr 6, 2007, at 2:31 PM, Eric Peden wrote:> > I appreciate the question. When I passed it along to our senior > sysadmin, it sparked quite a discussion. ;) As a result of that > discussion, I think I''m going to make a simple little script to build > a puppet manifest from our /u/ master directory, as David suggested. > Our refusal to use an automount stems from a desire for certain > machines to have different subsets of the user home directories > available; this cries out for management via puppet, so I think the > manifest building approach will make a suitable bridge between the two > paradigms. For now.Hmm. I''ve always considered it a bug if you have to generate Puppet code. Isn''t the real concern whether users have accounts on a given machine, not whether the user''s home directory is automounted? Remember that automounting only mounts directories that are used, so it''s essentially zero cost to have a bunch of directories capable of being mounted but not actually mounted. If a user is present and ever logs in (or if someone else accesses the user''s home dir), then the dir will be automounted, else it will be ignored. Also, note that if you''re going to generate a configuration file, you might as well just generate local automount maps. I''d keep a yaml file of the different user => dir maps, and then configure each client to generate the correct automount configuration based on those maps. If you want to keep this in Puppet, you could do something like: # automount.pp class automount_setup { # Create the dir, and remove any no-longer-needed files file { "/etc/automount.d": ensure => directory, recurse => true, purge => true } # Rebuild the file when requested or when the automount dir changes exec { rebuild_automount: command => "/bin/cat /etc/automount.d/* > /etc/auto.home", refreshonly => true, subscribe => File["/etc/automount.d"] } # You''ll probably need to restart automount if the auto.home file changes } define automount($source = false, $options = "") { $realsource = $dir ? { false => "nfs.domain.com:/base/$name", default => $source } file { "/etc/automount.d/$name": content => "$name $options $realsource\n" } } With this, you can just create whatever automount maps you want: automount { [me, you, "bobby mcgee": } # use defaults automount { stranger: source => "myserver.domain.com:/home/weirdness" } This will correctly generate the files on the client, you get to be as picky as you want about what configurations are where, and you don''t need to worry about generating configurations or making symlinks. That''s just how I would do it, though, and I tend to be pretty attached to things like automount. -- I do not feel obliged to believe that the same God who has endowed us with sense, reason, and intellect has intended us to forgo their use. -- Galileo Galilei --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com