On 31.03.2011 23:32, Trevor Vaughan wrote:
Fair enough.
nss:<foo> or nss_foo?
According to nsswitch.conf(5) this would include:
aliases
ethers
group -> Covered by 'group' type
hosts -> Covered by 'host' type
netgroup
networks
passwd -> Covered by 'user' type
protocols
publickey
rpc
services -> The one we want to cover
shadow -> Covered by 'user' type
So, if this logic holds, would we need to rename/alias the 'host' type
to nss_host?
It's not a horrible idea so long as it's a full version deprecation.
It would add consistency and tell you more concretely what you're
actually configuring. For instance, if some crazy person decides to
create a full BIND type then you would have another 'host' scope in
there.
"Well, actually"[1] nss can talk to ldap, nis, files, berkley dbs, and a
bunch of other nasty stuff, and complex combinations of them. So
"nss_user" would have have a very local meaning, depending on the
contents of nsswitch and the user you're looking at. I'm all for having
support for any and all of those mechanisms, I'm just not sure that they
should all be managed via nss_user providers...
Best Regards, David
[1]http://tirania.org/blog/archive/2011/Feb-17.html
Trevor
On Thu, Mar 31, 2011 at 3:38 PM, Oliver<[email protected]> wrote:
On 31 March 2011 21:17, Trevor Vaughan<[email protected]> wrote:
I'm not sure if it's that easy.
In Fedora, at least, network materials are grouped into the
'initscripts' package and items such as /etc/hosts and /etc/services
are in the 'setup' package.
You almost would need a LSB category to give these a really broad
header (where applicable).
I'm not sure if that's a good idea though.
Perhaps: etc_services, etc_hosts , etc_networks etc...?
It's based on where they live but that seems to be more consistent
than anything else.
I can't speak for Fedora's packaging, but my impression is that these
files are all ultimately serving the name service, configured via
/etc/nsswitch.conf and thus part of GNU libc. The absence of any of
these files due to packaging differences should be irrelevant, since
they (AFAIK) are all default choices of the name service switch
config, and hence have the same basic format.
Trevor
On Thu, Mar 31, 2011 at 2:30 PM, Oliver Hookins<[email protected]> wrote:
On Mar 31, 4:45 pm, Jacob Helwig<[email protected]> wrote:
On Thu, 31 Mar 2011 08:16:31 -0400, Trevor Vaughan wrote:
I don't like 'port', but I'm having a hard time coming up with a good alternate.
sys_service?
The man page says "The Internet network services list" so perhaps
net_svc or net_service?
network_service, or net_service are currently the leading candidates in
my mind, for what it's worth.
I don't mean to muddy the water (especially as I'm only joining the
thread very late in the game), but shouldn't this be grouped under the
more general heading of name service? That is to say, the files-style
databases that are in the same format between protocols, services,
ethers and rpc.
By extension, shouldn't such a generic type/provider support all of
these databases and be able to store values in any of them?
To be completely accurate in this abstraction, technically /etc/hosts
would also be covered (and /etc/networks). Is this all a fair call or
is this a debate best saved for another day?
--
Jacob Helwig
signature.asc
< 1KViewDownload
--
You received this message because you are subscribed to the Google Groups "Puppet
Developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
[email protected]
-- This account not approved for unencrypted proprietary information --
--
dasz.at OG Tel: +43 (0)664 2602670 Web: http://dasz.at
Wien UID: ATU64260999
FB-Nr.: FN 309285 g FB-Gericht: Wien
--
You received this message because you are subscribed to the Google Groups "Puppet
Developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
