/etc/netstart diff

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

/etc/netstart diff

Holger Mikolon
The veriable $HN_DIR is set in /etc/netstart on line 166 but used only
once (line 78). The diff below makes use of $HN_DIR in the other cases
where netstart cares of ip address configuration.

With below change I can maintain different sets (think "profiles") of
hostname.if(5) files in separate directories and use them e.g. like this:
"env HN_DIR=/etc/myprofile sh /etc/netstart"

Even without such use case it's at least a consistency fix.

Regards
Holger
;-se


Index: etc/netstart
===================================================================
RCS file: /cvs/src/etc/netstart,v
retrieving revision 1.186
diff -u -p -u -r1.186 netstart
--- etc/netstart 25 Jul 2017 21:17:11 -0000 1.186
+++ etc/netstart 7 Nov 2017 15:36:25 -0000
@@ -129,8 +129,8 @@ ifmstart() {
  local _sifs=$1 _xifs=$2 _hn _if _sif _xif
 
  for _sif in ${_sifs:-ALL}; do
- for _hn in /etc/hostname.*; do
- _if=${_hn#/etc/hostname.}
+ for _hn in $HN_DIR/hostname.*; do
+ _if=${_hn#$HN_DIR/hostname.}
  [[ $_if == '*' ]] && continue
 
  # Skip unwanted ifs.
@@ -147,12 +147,12 @@ ifmstart() {
 # Parse /etc/mygate and add default routes for IPv4 and IPv6
 # Usage: defaultroute
 defaultroute() {
- ! $V4_DHCPCONF && stripcom /etc/mygate |
+ ! $V4_DHCPCONF && stripcom $HN_DIR/mygate |
  while read gw; do
  [[ $gw == @(*:*) ]] && continue
  route -qn add -host default $gw && break
  done
- ! $V6_AUTOCONF && stripcom /etc/mygate |
+ ! $V6_AUTOCONF && stripcom $HN_DIR/mygate |
  while read gw; do
  [[ $gw == !(*:*) ]] && continue
  route -qn add -host -inet6 default $gw && break

Reply | Threaded
Open this post in threaded view
|

Re: /etc/netstart diff

Robert Peichaer
On Wed, Nov 08, 2017 at 10:47:43PM +0100, Holger Mikolon wrote:

> The veriable $HN_DIR is set in /etc/netstart on line 166 but used only
> once (line 78). The diff below makes use of $HN_DIR in the other cases
> where netstart cares of ip address configuration.
>
> With below change I can maintain different sets (think "profiles") of
> hostname.if(5) files in separate directories and use them e.g. like this:
> "env HN_DIR=/etc/myprofile sh /etc/netstart"
>
> Even without such use case it's at least a consistency fix.
>
> Regards
> Holger
> ;-se

Hallo Holger

This "feature" was introduced for a specific purpose some time ago to
assist the transition to the new hostname.if(5) parser code in the
netstart script. People were able to run netstart with the -n option
and this HN_DIR environment variable to verify that the new parser
works with their possibly non-trivial hostname.if(5) configurations.
We considered this to be a rather delicate transition because we did
not want to break peoples setups.

Now that the parser code proved to not break anything, I rather want
to remove this funcionality, than to extend it.

--
-=[rpe]=-

Reply | Threaded
Open this post in threaded view
|

Re: /etc/netstart diff

Alexander Hall


On November 9, 2017 7:02:54 PM GMT+01:00, Robert Peichaer <[hidden email]> wrote:

>On Wed, Nov 08, 2017 at 10:47:43PM +0100, Holger Mikolon wrote:
>> The veriable $HN_DIR is set in /etc/netstart on line 166 but used
>only
>> once (line 78). The diff below makes use of $HN_DIR in the other
>cases
>> where netstart cares of ip address configuration.
>>
>> With below change I can maintain different sets (think "profiles") of
>> hostname.if(5) files in separate directories and use them e.g. like
>this:
>> "env HN_DIR=/etc/myprofile sh /etc/netstart"
>>
>> Even without such use case it's at least a consistency fix.
>>
>> Regards
>> Holger
>> ;-se
>
>Hallo Holger
>
>This "feature" was introduced for a specific purpose some time ago to
>assist the transition to the new hostname.if(5) parser code in the
>netstart script. People were able to run netstart with the -n option
>and this HN_DIR environment variable to verify that the new parser
>works with their possibly non-trivial hostname.if(5) configurations.
>We considered this to be a rather delicate transition because we did
>not want to break peoples setups.
>
>Now that the parser code proved to not break anything, I rather want
>to remove this funcionality, than to extend it.

I totally agree.