new type: nfs-exports, your thoughts.
Udo Waechter
I started writing a type and provider for /etc/exports i.e. nfs-exports.
type: http://pastie.org/518506
provider: http://pastie.org/518507
Now, I have some questions:
1. Where would I add the functionality of reloading mountd?
I have read a post where luke (i think it was him) suggested, that
reloading of services and such should not
belong to the type/provider that changes its config file. I for
myself would like to have this functionality
embedded in the type or provider. But which of those two and how?
1.1 What has to be done to reload mountd? Here are those that I know of:
Linux: "exportfs -ra"
FreeBSD, Darwin: "kill -HUP /var/run/mountd.pid"
1.2 How does this work on other OSes?
1.2.1 Where is /etc/exports
1.2.2 how does one refresh mountd (or whatever it is called)
2. Would you rather prefer to have:
2.1 one options parameter, where all export options are defined:
-- as string?
-- as array?
2.2 split up possible options into parameters (I like that somehow):
2.2.1 the type would have options like:
- rw (true => "rw", false => "ro")
- root_squash (true => "root_squash", false => "no_root_squash")
- anonuid/anongid (number)
- async (true => "async", false => "sync")
- and so on (see: http://linux.die.net/man/5/exports)
This would make things easy to validate.
2.2.2 The problem here is: FreeBSD (all BSDs?) has a different syntax:
- http://www.freebsd.org/cgi/man.cgi?query=exports&sektion=5
- now which one should I choose.
- I would prefer the linux-type (since I am really familiar with it)
As I see it, I will write different providers for BSD-style exports
and linux-style exports.
I would like to hear your thoughts on this.
Bye.
udo.
--
:: udo waechter - ro...@zoide.net :: N 52º16'30.5" E 8º3'10.1"
:: genuine input for your ears: http://auriculabovinari.de
:: your eyes: http://ezag.zoide.net
:: your brain: http://zoide.net
Christian Hofstädtler
> Hello all,
> I started writing a type and provider for /etc/exports i.e. nfs-exports.
> type: http://pastie.org/518506
> provider: http://pastie.org/518507
>
> Now, I have some questions:
> 1.1 What has to be done to reload mountd? Here are those that I know of:
> Linux: "exportfs -ra"
> FreeBSD, Darwin: "kill -HUP /var/run/mountd.pid"
On Linux there are also at least two user-space NFS server
implementation, and both do not provide exportfs. The v2-only version
needs an /etc/init.d/nfs-user-server reload, can't speak for unfs3.
> [..]
Christian
Kjetil Torgrim Homme
> I started writing a type and provider for /etc/exports i.e. nfs-exports.
> type: http://pastie.org/518506
> provider: http://pastie.org/518507
>
> Now, I have some questions:
> 1. Where would I add the functionality of reloading mountd?
> I have read a post where luke (i think it was him) suggested,
> that reloading of services and such should not belong to the
> type/provider that changes its config file. I for myself would
> like to have this functionality embedded in the type or
> provider. But which of those two and how?
I think this should work like services, where you have "ensure =>
running" for starting the service, and "enable => true" to make the
change persistent. in other words, "ensure => exported" would run
exportfs(8) on Linux, without changing /etc/exports, "enable => true"
would edit exports, but not enable it. the combination would be
needed.
> 1.1 What has to be done to reload mountd? Here are those that I know
> of:
> Linux: "exportfs -ra"
> FreeBSD, Darwin: "kill -HUP /var/run/mountd.pid"
in Solaris (and HP-UX and AIX IIRC), you run shareall.
(nice touch that FreeBSD kill supports a pid file, haven't seen that
before. will break in a bash script, though.)
> 1.2 How does this work on other OSes?
> 1.2.1 Where is /etc/exports
in Solaris, this is in /etc/dfs/dfstab for "legacy" mounts, for ZFS it
is stored as a filesystem attribute.
> 2. Would you rather prefer to have:
> 2.1 one options parameter, where all export options are defined:
> -- as string?
> -- as array?
I prefer a simple string.
> 2.2 split up possible options into parameters (I like that somehow):
> 2.2.1 the type would have options like:
> - rw (true => "rw", false => "ro")
> - root_squash (true => "root_squash", false => "no_root_squash")
> - anonuid/anongid (number)
> - async (true => "async", false => "sync")
> - and so on (see: http://linux.die.net/man/5/exports)
> This would make things easy to validate.
not sure if its worthwhile to require a Puppet upgrade to take
advantage of a new NFS feature. (BTW, if you must, make the parameter
"sync". double negatives are needlessly confusing.)
> 2.2.2 The problem here is: FreeBSD (all BSDs?) has a different syntax:
> - http://www.freebsd.org/cgi/man.cgi?query=exports&sektion=5
> - now which one should I choose.
> - I would prefer the linux-type (since I am really familiar with it)
>
> As I see it, I will write different providers for BSD-style exports
> and linux-style exports.
and obviously the Solaris provider will be quite different from the
Linux provider.
> I would like to hear your thoughts on this.
stick to the portable stuff in the basic interface. that's just about
everything except the export options.
--
Kjetil T. Homme
Redpill Linpro AS - Changing the game
Udo Waechter
On 06/22/2009 12:07 PM, Kjetil Torgrim Homme wrote:
> Udo Waechter<udo.wa...@uni-osnabrueck.de> writes:
>
>> I started writing a type and provider for /etc/exports i.e. nfs-exports.
>> type: http://pastie.org/518506
>> provider: http://pastie.org/518507
>>
>> Now, I have some questions:
>> 1. Where would I add the functionality of reloading mountd?
>> I have read a post where luke (i think it was him) suggested,
>> that reloading of services and such should not belong to the
>> type/provider that changes its config file. I for myself would
>> like to have this functionality embedded in the type or
>> provider. But which of those two and how?
>
> I think this should work like services, where you have "ensure =>
> running" for starting the service, and "enable => true" to make the
> change persistent. in other words, "ensure => exported" would run
> exportfs(8) on Linux, without changing /etc/exports, "enable => true"
> would edit exports, but not enable it. the combination would be
> needed.
hmmm, I am not sure if I really like this. currently I have:
ensure => true|false
This simply adds the export or removes it from /etc/exports This is
enough for me.
>
>> 1.1 What has to be done to reload mountd? Here are those that I know
>> of:
>> Linux: "exportfs -ra"
>> FreeBSD, Darwin: "kill -HUP /var/run/mountd.pid"
>
> in Solaris (and HP-UX and AIX IIRC), you run shareall.
>
> (nice touch that FreeBSD kill supports a pid file, haven't seen that
> before. will break in a bash script, though.)
>
The kill line above is worng, of course it should be:
kill -HUP `cat /var/run/mountd.pid`
To be precise, freebsd has "/etc/rc.d/mountd reload", but darwin has
not, thus I chose the kill trick. This is good for both bsds
>> 1.2 How does this work on other OSes?
>> 1.2.1 Where is /etc/exports
>
> in Solaris, this is in /etc/dfs/dfstab for "legacy" mounts, for ZFS it
> is stored as a filesystem attribute.
Yes, so does zfs-on freebsd. We chose not to use that feature on our
fileservers (which run freebsd). We still use /etc/exports this makes
things more protable.
>
>> 2. Would you rather prefer to have:
>> 2.1 one options parameter, where all export options are defined:
>> -- as string?
>> -- as array?
>
> I prefer a simple string.
Yep, it is a string now. One can use the Linux options, and those that
are applicable on freebsd will be converted to that notation.
>
>> 2.2.2 The problem here is: FreeBSD (all BSDs?) has a different syntax:
>> - http://www.freebsd.org/cgi/man.cgi?query=exports&sektion=5
>> - now which one should I choose.
>> - I would prefer the linux-type (since I am really familiar with it)
>>
>> As I see it, I will write different providers for BSD-style exports
>> and linux-style exports.
yes, the should not be the problem. The problem comes on type-level:
in linux we have a lot of export-options, on freebsd there is
essentially only the -map* and -ro
rw/ro are the only ones that actually have the same name ;)
Why do all have to brew their one soup? Please, do not answer this
question...
bye,
udo.
Luke Kanies
I'd prefer to stick to the standard present|absent.
>>> 1.1 What has to be done to reload mountd? Here are those that I know
>>> of:
>>> Linux: "exportfs -ra"
>>> FreeBSD, Darwin: "kill -HUP /var/run/mountd.pid"
>>
>> in Solaris (and HP-UX and AIX IIRC), you run shareall.
>>
>> (nice touch that FreeBSD kill supports a pid file, haven't seen that
>> before. will break in a bash script, though.)
>>
> The kill line above is worng, of course it should be:
> kill -HUP `cat /var/run/mountd.pid`
>
> To be precise, freebsd has "/etc/rc.d/mountd reload", but darwin has
> not, thus I chose the kill trick. This is good for both bsds
I think I mentioned this on this thread already, but I'd much prefer
if the type had an automatic 'notify' relationship with the service,
rather than directly killing it or whatever. That way it's a bit more
portable, and it allows users a lot more flexibility.
>
>>> 1.2 How does this work on other OSes?
>>> 1.2.1 Where is /etc/exports
>>
>> in Solaris, this is in /etc/dfs/dfstab for "legacy" mounts, for ZFS
>> it
>> is stored as a filesystem attribute.
> Yes, so does zfs-on freebsd. We chose not to use that feature on our
> fileservers (which run freebsd). We still use /etc/exports this
> makes things more protable.
>
>>
>>> 2. Would you rather prefer to have:
>>> 2.1 one options parameter, where all export options are defined:
>>> -- as string?
>>> -- as array?
>>
>> I prefer a simple string.
> Yep, it is a string now. One can use the Linux options, and those
> that are applicable on freebsd will be converted to that notation.
I really prefer an array - again, it hides a bit of the platform
specifics.
>>> 2.2.2 The problem here is: FreeBSD (all BSDs?) has a different
>>> syntax:
>>> - http://www.freebsd.org/cgi/man.cgi?query=exports&sektion=5
>>> - now which one should I choose.
>>> - I would prefer the linux-type (since I am really familiar with
>>> it)
>>>
>>> As I see it, I will write different providers for BSD-style exports
>>> and linux-style exports.
> yes, the should not be the problem. The problem comes on type-level:
>
> in linux we have a lot of export-options, on freebsd there is
> essentially only the -map* and -ro
>
> rw/ro are the only ones that actually have the same name ;)
> Why do all have to brew their one soup? Please, do not answer this
> question...
>
> bye,
> udo.
>
--
Nature and nature's laws lay hid in night,
God said, "Let Newton be," and all was light.
It did not last; the devil howling "Ho!
Let Einstein be!" restored the status quo.
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com