Status of /etc/rc.conf.d/servicename feature in rc.subr

[Stefan Midjich]

Actually I have something to add about /etc/rc.conf.d and it's not
about the shell code.

My purpose to all this was to find a way to configure network
interfaces that doesn't require parsing rc.conf. We deploy hundreds of
machines using data center management tools so writing functions in
these tools for network configuration becomes much easier if you
separate the network configuration into their own files.

So using /etc/rc.conf.d/network will work, but I would like to go
further and suggest the OpenBSD model of using interface.ifname or
something similar. One file for each interface that is.

2011/6/20 Stefan Midjich <swehack at gmail.com>:
> Shortly after I posted my e-mail I was talking about this with a
> co-worker and realized that I'm using the wrong servicename in
> rc.conf.d. Checking the name variable in /etc/rc.d/netif made it all
> much more clear.
>
> And yes I would support the further development of this feature
> because I plan on using it in deployment of FreeBSD nodes.
>
> 2011/6/20 Mark Blackman <mark at exonetric.com>:
>> On 20 Jun 2011, at 09:20, Stefan Midjich wrote:
>>
>>> I noticed in /etc/rc.subr that the function load_rc_config sources
>>> /etc/rc.conf.d/${_name}. This is however undocumented, NetBSD mentions
>>> this feature in rc.conf(5) but FreeBSD does not.
>>>
>>> I have two questions, is this a new undocumented feature, or an old
>>> one being phased out? I'm hoping it's a new because I really want this
>>> feature.
>>>
>>> Second question, how do I use it? I've tried to track the ${_name}
>>> variable but I can't find anyone calling the parent function
>>> load_rc_config_var() where the name variable is set from its first
>>> argument.
>>
>> I've added a file called 'jail' there  and /etc/rc.d/jail will then
>> pick up configuration data from /etc/rc.conf.d/jail.
>>
>> I think it's quite a useful feature and would support it's
>> continued existence. However I wonder who else might be interested
>> in a better referencing method more like a perl hash or YAML files
>> for the configuration data.
>>
>> There's a clear nesting behaviour there built from shell variable
>> names that I find a little bit overextended.
>>
>> - Mark
>>
>
>
>
> --
>
>
> Med vänliga hälsningar / With kind regards
>
> Stefan Midjich
> http://swehack.se
>



-- 


Med vänliga hälsningar / With kind regards

Stefan Midjich
http://swehack.se