I have a machine with two swap partitions (sda2 and sda8). Both will have none as mount point. When I try to use puppet (using mount type) for managing fstab I get problems because "name" in both instances (i.e. mount path) will be "none". How should I fix this within puppet? Regards Halvard Moe
On Apr 25, 2007, at 5:27 AM, Halvard Moe wrote:> > I have a machine with two swap partitions (sda2 and sda8). Both will > have none as mount point. When I try to use puppet (using mount type) > for managing fstab I get problems because "name" in both instances > (i.e. mount path) will be "none". How should I fix this within puppet?Hmm, kinda forgot that this problem could show up. At this point, the problem is unresolvable, but maybe I should switch mounts to use the device as the name, rather than the mount point. I know this would fix problems on OS X, because it already uses the device as the key, rather than the mount point. Can anyone think of a reason not to do this? Another option is to allow specifying multiple devices in a single mount resource, which would then manage mount entries for both, but I don''t think that''s really the "right" option. -- To get back my youth I would do anything in the world, except take exercise, get up early, or be respectable. -- Oscar Wilde --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
> Hmm, kinda forgot that this problem could show up. At this point, > the problem is unresolvable, but maybe I should switch mounts to use > the device as the name, rather than the mount point. I know this > would fix problems on OS X, because it already uses the device as the > key, rather than the mount point. > > Can anyone think of a reason not to do this? > > Another option is to allow specifying multiple devices in a single > mount resource, which would then manage mount entries for both, but I > don''t think that''s really the "right" option. > >another thing that could be handy on this type would be the possibility to ADD options to partitions only if they exist like: mount { ''/tmp'': options => +nosuid,+nodev, onlyifexist => true } would add the options to the existing one without creating the mount if it does not exist. -- Cordialement, Ghislain _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On Apr 25, 2007, at 9:48 AM, ADNET Ghislain wrote:> another thing that could be handy on this type would be the > possibility to ADD options to partitions only if they exist like: > > mount { ''/tmp'': > options => +nosuid,+nodev, > onlyifexist => true > } > > would add the options to the existing one without creating the > mount if it does not exist.This should really be a general feature, not just restricted to mount points, but it would require some significant rethinking of how we think about ''ensure''. I''m working on that, but I don''t know when it will be done. If you file it as an enhancement request, I can get it into the development queue, but I''m clearly not making any promises on timelines. -- We cannot really love anybody with whom we never laugh. --Agnes Repplier --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
I can think of one good reason not to do this... A standard RH installation uses ''none'' as the device mount point for proc, tmpfs, devpts, and sysfs. The only way I know of to make it truly unique just using the information in the file is to combine the mount point and the device into a single string...perhaps "none_proc", "none_tmpfs", etc... Or...you could just apply arbitrary autonumeric names to the various mounts. Just my 2p. Trevor On 4/25/07, Luke Kanies <luke@madstop.com> wrote:> > On Apr 25, 2007, at 5:27 AM, Halvard Moe wrote: > > > > > I have a machine with two swap partitions (sda2 and sda8). Both will > > have none as mount point. When I try to use puppet (using mount type) > > for managing fstab I get problems because "name" in both instances > > (i.e. mount path) will be "none". How should I fix this within puppet? > > Hmm, kinda forgot that this problem could show up. At this point, > the problem is unresolvable, but maybe I should switch mounts to use > the device as the name, rather than the mount point. I know this > would fix problems on OS X, because it already uses the device as the > key, rather than the mount point. > > Can anyone think of a reason not to do this? > > Another option is to allow specifying multiple devices in a single > mount resource, which would then manage mount entries for both, but I > don''t think that''s really the "right" option. > > -- > To get back my youth I would do anything in the world, except take > exercise, get up early, or be respectable. -- Oscar Wilde > --------------------------------------------------------------------- > Luke Kanies | http://reductivelabs.com | http://madstop.com > > > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-users >_______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On Apr 25, 2007, at 11:55 AM, Trevor Vaughan wrote:> I can think of one good reason not to do this... > > A standard RH installation uses ''none'' as the device mount point > for proc, tmpfs, devpts, and sysfs.So the device itself is ''none''? I don''t have any recent RH installations, but my old fc4 image has the following: /dev/shm /dev/shm tmpfs defaults 0 0 /dev/proc /proc proc defaults 0 0 /dev/sys /sys sysfs defaults 0 0 It no longer looks like that? You''re saying the first field is now ''none'' for those?> The only way I know of to make it truly unique just using the > information in the file is to combine the mount point and the > device into a single string...perhaps "none_proc", "none_tmpfs", > etc... > > Or...you could just apply arbitrary autonumeric names to the > various mounts.These would both be pretty bad and hopefully avoidable. -- Kai''s Example Dilemma: A good analogy is like a diagonal frog. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
Luke Kanies wrote:> On Apr 25, 2007, at 11:55 AM, Trevor Vaughan wrote: > >> I can think of one good reason not to do this... >> >> A standard RH installation uses ''none'' as the device mount point >> for proc, tmpfs, devpts, and sysfs. > > So the device itself is ''none''? I don''t have any recent RH > installations, but my old fc4 image has the following: > > /dev/shm /dev/shm tmpfs > defaults 0 0 > /dev/proc /proc proc > defaults 0 0 > /dev/sys /sys sysfs > defaults 0 0 > > It no longer looks like that? You''re saying the first field is now > ''none'' for those?Like this surely: UUID=747dcd0e-b570-48a3-b07c-17d2be01d585 none swap sw 0 0 Dave
On Wed, 2007-04-25 at 12:17 -0500, Luke Kanies wrote:> > A standard RH installation uses ''none'' as the device mount point > > for proc, tmpfs, devpts, and sysfs.For RHEL4, fstab looks like /dev/hda3 / ext3 defaults 1 1 none /dev/pts devpts gid=5,mode=620 0 0 none /proc proc defaults 0 0 none /dev/shm tmpfs defaults 0 0 /dev/hda1 /boot ext3 defaults 1 2 For FC6, rawhide (what will be FC7), and RHEL5, it is /dev/vg00/lv00 / ext3 defaults 1 1 LABEL=/boot /boot ext3 defaults 1 2 devpts /dev/pts devpts gid=5,mode=620 0 0 tmpfs /dev/shm tmpfs defaults 0 0 /dev/vg00/home /home ext3 defaults 1 2 proc /proc proc defaults 0 0 sysfs /sys sysfs defaults 0 0 Note that apart from the ''none'' business, there''s also mount-by-label, i.e. mounts that aren''t based off a device, but a fs label. If we allow funky device names like ''LABEL=xxx'', the only issue are the ''none'' entries; I haven''t tried yet, but I wonder if none is really special here, or if any identifier that''s not a device could be used. The man page says that for proc ''procfs'' should be used ... David
There is also the corner case where you want to mount the same device in multiple places within the filesystem, for access under chroots or similar, eg: /dev/vg00/lv_chroot_bin /chroot/blah1/bin ext3 ro 0 0 /dev/vg00/lv_chroot_bin /chroot/blah2/bin ext3 ro 0 0 /dev/vg00/lv_chroot_bin /chroot/blah3/bin ext3 ro 0 0 I realise this is a rare occurrence, but it''s a possibility. mike David Lutterkort wrote:> On Wed, 2007-04-25 at 12:17 -0500, Luke Kanies wrote: > >>> A standard RH installation uses ''none'' as the device mount point >>> for proc, tmpfs, devpts, and sysfs. >>> > > For RHEL4, fstab looks like > > /dev/hda3 / ext3 defaults 1 1 > none /dev/pts devpts gid=5,mode=620 0 0 > none /proc proc defaults 0 0 > none /dev/shm tmpfs defaults 0 0 > /dev/hda1 /boot ext3 defaults 1 2 > > For FC6, rawhide (what will be FC7), and RHEL5, it is > > /dev/vg00/lv00 / ext3 defaults 1 1 > LABEL=/boot /boot ext3 defaults 1 2 > devpts /dev/pts devpts gid=5,mode=620 0 0 > tmpfs /dev/shm tmpfs defaults 0 0 > /dev/vg00/home /home ext3 defaults 1 2 > proc /proc proc defaults 0 0 > sysfs /sys sysfs defaults 0 0 > > Note that apart from the ''none'' business, there''s also mount-by-label, > i.e. mounts that aren''t based off a device, but a fs label. > > If we allow funky device names like ''LABEL=xxx'', the only issue are the > ''none'' entries; I haven''t tried yet, but I wonder if none is really > special here, or if any identifier that''s not a device could be used. > The man page says that for proc ''procfs'' should be used ... > > David > > > > > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-users >-- Mike Pountney, Information Systems Manager, Semantico, Floor 1, 21-23 Dyke Road, Brighton BN1 3FE <http://www.semantico.com/> <mailto:Mike.Pountney@semantico.com> <tel:+44-1273-722222;ext=209> <fax:+44-1273-723232>
On Apr 26, 2007, at 3:53 AM, Mike Pountney wrote:> There is also the corner case where you want to mount the same > device in > multiple places within the filesystem, for access under chroots or > similar, eg: > > /dev/vg00/lv_chroot_bin /chroot/blah1/bin ext3 ro 0 0 > /dev/vg00/lv_chroot_bin /chroot/blah2/bin ext3 ro 0 0 > /dev/vg00/lv_chroot_bin /chroot/blah3/bin ext3 ro 0 0 > > I realise this is a rare occurrence, but it''s a possibility.Puppet will not be able to support this until/unless it supports multiple primary keys, I expect. -- Morgan''s Second Law: To a first approximation all appointments are canceled. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On Apr 25, 2007, at 1:36 PM, David Lutterkort wrote:> On Wed, 2007-04-25 at 12:17 -0500, Luke Kanies wrote: >>> A standard RH installation uses ''none'' as the device mount point >>> for proc, tmpfs, devpts, and sysfs. > > For RHEL4, fstab looks like > > /dev/hda3 / ext3 defaults 1 1 > none /dev/pts devpts gid=5,mode=620 0 0 > none /proc proc defaults 0 0 > none /dev/shm tmpfs defaults 0 0 > /dev/hda1 /boot ext3 defaults 1 2 > > For FC6, rawhide (what will be FC7), and RHEL5, it is > > /dev/vg00/lv00 / ext3 > defaults 1 1 > LABEL=/boot /boot ext3 > defaults 1 2 > devpts /dev/pts devpts > gid=5,mode=620 0 0 > tmpfs /dev/shm tmpfs > defaults 0 0 > /dev/vg00/home /home ext3 > defaults 1 2 > proc /proc proc > defaults 0 0 > sysfs /sys sysfs > defaults 0 0 > > Note that apart from the ''none'' business, there''s also mount-by-label, > i.e. mounts that aren''t based off a device, but a fs label. > > If we allow funky device names like ''LABEL=xxx'', the only issue are > the > ''none'' entries; I haven''t tried yet, but I wonder if none is really > special here, or if any identifier that''s not a device could be used. > The man page says that for proc ''procfs'' should be used ...Even if they all start with ''none'', that''s a significant problem. I don''t really know what to do here. Any recommendations? Or should I suddenly refocus on getting multiple primary keys to work? There''s a heckuva lot of refactoring to do to get there, but we keep running into problems that require it. -- A complex system that works is invariably found to have evolved from a simple system that works. -- John Gaule --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On Thu, Apr 26, 2007 at 10:57:13AM -0500, Luke Kanies wrote:> Or should I suddenly refocus on getting multiple primary keys to > work? There''s a heckuva lot of refactoring to do to get there, but > we keep running into problems that require it.As much as it''s going to be an absolute butt-load of work, I think it might be time to start pondering composite "primary keys" for Puppet objects. As you say, there''s several things that look like they need it. - Matt -- You have a 16-bit quantity, but 5 bits of it are here and 2 bits of it are there... and 2 bits of it are back here and 3 bits of it are up there. The C code to extract useful data had so many >> and << operators in it that it looked like the C++ version of "hello world". -- Matt Roberds, ASR
On Thu, Apr 26, 2007 at 10:57:13AM -0500, Luke Kanies wrote:> Even if they all start with ''none'', that''s a significant problem. > > I don''t really know what to do here. Any recommendations? > > Or should I suddenly refocus on getting multiple primary keys to > work? There''s a heckuva lot of refactoring to do to get there, but > we keep running into problems that require it.Apart from getting primary keys to work the only other solution (that I can think) is to use something like ''mountpoint#device'' as the primary key. I don''t like it as a solution though :( Kostas
On Thu, 2007-04-26 at 09:53 +0100, Mike Pountney wrote:> There is also the corner case where you want to mount the same device in > multiple places within the filesystem, for access under chroots or > similar, eg: > > /dev/vg00/lv_chroot_bin /chroot/blah1/bin ext3 ro 0 0 > /dev/vg00/lv_chroot_bin /chroot/blah2/bin ext3 ro 0 0 > /dev/vg00/lv_chroot_bin /chroot/blah3/bin ext3 ro 0 0 > > I realise this is a rare occurrence, but it''s a possibility.When I first looked at that I thought "Long winded way to corrupt file systems", and then noticed the ro option ;) More to the point, a setup like this, or simple bind mounts can lead to non-unique device names. The more we talk about this, the clearer it seems that the only unique key for mounts is the pair (device, mountpoint) ... short of that, you''ll always have non-uniqueness. David
On Fri, 2007-04-27 at 01:53 +0100, Kostas Georgiou wrote:> Apart from getting primary keys to work the only other solution (that > I can think) is to use something like ''mountpoint#device'' as the primary > key. I don''t like it as a solution though :(I think this would be fine if it were completely hidden from the user; or maybe it should just be hacked in the mount type for the one common case where multiple mounts have the same mountpoint: swap. Maybe there should just be a separate swap type ;) David
On Apr 26, 2007, at 3:21 PM, Matthew Palmer wrote:> > As much as it''s going to be an absolute butt-load of work, I think > it might > be time to start pondering composite "primary keys" for Puppet > objects. As > you say, there''s several things that look like they need it.I agree, although it shouldn''t be so much work, and it will definitely allow us the opportunity to refactor some things that should have been done differently to begin with. There are just so many other things in the stack right now... -- The Number 1 Sign You Have Nothing to Do at Work... The 4th Division of Paperclips has overrun the Pushpin Infantry and General White-Out has called for a new skirmish. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On Apr 26, 2007, at 8:10 PM, David Lutterkort wrote:> On Fri, 2007-04-27 at 01:53 +0100, Kostas Georgiou wrote: >> Apart from getting primary keys to work the only other solution (that >> I can think) is to use something like ''mountpoint#device'' as the >> primary >> key. I don''t like it as a solution though :( > > I think this would be fine if it were completely hidden from the user; > or maybe it should just be hacked in the mount type for the one common > case where multiple mounts have the same mountpoint: swap. Maybe there > should just be a separate swap type ;)Right -- we could do this if we generated the name, but that would require disallowing the user to specify a name, which isn''t really going to work. -- There is no expedient to which a man will not go to avoid the labor of thinking. --Thomas A. Edison --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
David Schmitt
2007-Apr-30 21:44 UTC
[OT] multiple mounts (was: Re: Multiple swap partitions)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 27 April 2007, David Lutterkort wrote:> On Thu, 2007-04-26 at 09:53 +0100, Mike Pountney wrote: > > There is also the corner case where you want to mount the same device in > > multiple places within the filesystem, for access under chroots or > > similar, eg: > > > > /dev/vg00/lv_chroot_bin /chroot/blah1/bin ext3 ro 0 0 > > /dev/vg00/lv_chroot_bin /chroot/blah2/bin ext3 ro 0 0 > > /dev/vg00/lv_chroot_bin /chroot/blah3/bin ext3 ro 0 0 > > > > I realise this is a rare occurrence, but it''s a possibility. > > When I first looked at that I thought "Long winded way to corrupt file > systems", and then noticed the ro option ;) More to the point, a setup > like this, or simple bind mounts can lead to non-unique device names.Just a little side note: AFAIK multiple mounting equals bind mounting under current kernels. 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) iD8DBQFGNmMo/Pp1N6Uzh0URAhkNAJ0aGLqdCg/WW0wut9WHYlG2I8q1HQCdGBAP tJ9F564lxhmzmdabYAfy7YY=bAAI -----END PGP SIGNATURE-----