Ok, so I''m obviously doing something wrong here. This is running
puppet 0.22.2 on a centos 4 update 4 box.
When I try running this test -
mount { bigdisk:
ensure => mounted,
device => ''bigserver:/bigdisk'',
fstype => nfs,
name => ''/bigdisk'',
dump => "0",
pass => "0",
options => ''rw,rsize=32768,wsize=32768,defaults'',
}
Yet, when I run it:
bash-3.00$ sudo puppet --noop --verbose ./work.pp
notice: //Mount[pdprojects]/ensure: is absent, should be mounted (noop)
err: Got an uncaught exception of type ArgumentError: Field
''dump'' is required
I assume this is a usage error, but I can''t find out why.
Any takers?
Thanks,
--mac
Sorry, I tried to find/replace $employer specifics. The output should be: bash-3.00$ sudo puppet --noop --verbose ./work.pp notice: //Mount[bigdisk]/ensure: is absent, should be mounted (noop) err: Got an uncaught exception of type ArgumentError: Field ''dump'' is required Thanks, --mac
On Apr 3, 2007, at 1:36 PM, Chris McEniry wrote:> Ok, so I''m obviously doing something wrong here. This is running > puppet 0.22.2 on a centos 4 update 4 box. > > When I try running this test - > > mount { bigdisk: > ensure => mounted, > device => ''bigserver:/bigdisk'', > fstype => nfs, > name => ''/bigdisk'', > dump => "0", > pass => "0", > options => ''rw,rsize=32768,wsize=32768,defaults'', > } > > Yet, when I run it: > > bash-3.00$ sudo puppet --noop --verbose ./work.pp > notice: //Mount[pdprojects]/ensure: is absent, should be mounted > (noop) > err: Got an uncaught exception of type ArgumentError: Field ''dump'' > is required > > I assume this is a usage error, but I can''t find out why.Strange. I tested just about exactly this, because you told me you were encountering this problem, and I couldn''t reproduce it. What platform is it? I can try it again just to make sure; I''ll let you know. -- I don''t want any yes-men around me. I want everybody to tell me the truth even if it costs them their jobs. -- Samuel Goldwyn --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
I found what''s triggering it. The existing fstab entries did not have the dump or pass fields. Since this is an nfs field, some people would argue that those are not necessary. I don''t know the standard well enough to argue either way as to what is "correct", but I know that many OSes support entries with no dump/pass values. Once I dropped in "0 0" at the end of each fstab entry, it''s not complaining anymore. With regards to the error, it wasn''t clear that it was the fstab entries, so that could be clearer. Thoughts? --mac
On Apr 3, 2007, at 1:58 PM, Chris McEniry wrote:> I found what''s triggering it. The existing fstab entries did not have > the dump or pass fields. Since this is an nfs field, some people > would argue that those are not necessary. I don''t know the standard > well enough to argue either way as to what is "correct", but I know > that many OSes support entries with no dump/pass values. > > Once I dropped in "0 0" at the end of each fstab entry, it''s not > complaining anymore. > > With regards to the error, it wasn''t clear that it was the fstab > entries, so that could be clearer.Huh, I hadn''t thought of that -- they get parsed in with no values, but Puppet refuses to write them back out. That''s definitely a bug. I always assumed that all fields were required, and I''ve been hesitant to have default values for these fields (even though they seem pretty obsolete). I''m definitely willing to add whatever default behaviour people think is appropriate, but at the last, records that parse should be able to be written out just fine. -- "They called me mad, and I called them mad, and damn them, they outvoted me." -- Nathaniel Lee, on being consigned to a mental institution, circa 17th c. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On Tue, Apr 03, 2007 at 02:10:14PM -0500, Luke Kanies wrote:> On Apr 3, 2007, at 1:58 PM, Chris McEniry wrote: > > > I found what''s triggering it. The existing fstab entries did not have > > the dump or pass fields. Since this is an nfs field, some people > > would argue that those are not necessary. I don''t know the standard > > well enough to argue either way as to what is "correct", but I know > > that many OSes support entries with no dump/pass values. > > > > Once I dropped in "0 0" at the end of each fstab entry, it''s not > > complaining anymore. > > > > With regards to the error, it wasn''t clear that it was the fstab > > entries, so that could be clearer. > > Huh, I hadn''t thought of that -- they get parsed in with no values, > but Puppet refuses to write them back out. That''s definitely a bug. > > I always assumed that all fields were required, and I''ve been > hesitant to have default values for these fields (even though they > seem pretty obsolete).from fstab(5): If the fifth field is not present, a value of zero is returned and dump will assume that the filesystem does not need to be dumped. If the sixth field is not present or zero, a value of zero is returned and fsck will assume that the filesystem does not need to be checked. You should be safe with a default of zero if it''s missing it seems.
On Apr 3, 2007, at 3:20 PM, Kostas Georgiou wrote:> > from fstab(5): > If the fifth field is not present, a value of zero is returned > and dump will assume that the filesystem does not need to be > dumped. > > If the sixth field is not present or zero, a value of zero is > returned and fsck will assume that the filesystem does not > need to be checked. > > You should be safe with a default of zero if it''s missing it seems.Heh, which man page is that from? Considering that there are about six semi-officially supported platforms... Either way, sounds like 0 is a sufficient default for both, since I expect this behaviour will work for everyone. :) -- Measure with a micrometer. Mark with chalk. Cut with an axe. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com