devil-linux-develop Mailing List for Devil-Linux (Page 17)

Having given further thought to my earlier posting from work, and
hopefully to ease confusion between the differing network scripts, I
have given a version of "1.44a" to the original mactab-modified
script, and "1.44b" to the same file as further patched by Stefan.

Both files have been uploaded to mantis.

If Stefan can confirm I have correctly added his modifications to
1.44b, then I propose this is the file to use.

I'd expect Heiko to strip the temporary branding 1.44a and 1.44b, by the way.

Regards - Steve

"Stephen H F Ralph" <shf...@gm...>

>>> Heiko: Could one of you just send me the already patched network script
I have just taken a detailed look at Stefan's patch, and it seems his network script has his improved regexp, and also he has coded a call to a new "create_mactab()" function.

Perhaps Stefan could submit his final network script to become the definitive copy?

Regards - Steve.

Stephen H F Ralph
Principal Computer Officer | Integration Team | ICT Services | Transform Sandwell | Sandwell MBC | Freeth Street | Oldbury | West Midlands | B69 3DE
Tel: 0121 569 3132 | Fax: 0121 569 3493
Email: ste...@sa...



-----Original Message-----
From: Heiko Zuerker [mailto:he...@zu...]
Sent: 24 May 2010 16:13
To: dev...@li...
Subject: Re: [Devil-linux-develop] Enable "nameif" to associate MAC address with correct interface name

I'm having trouble applying the patches.
Could one of you just send me the already patched network script?

Thanks
Heiko

Quoting Heiko Zuerker <he...@zu...>:

> I finally have some time to look at this...
> The new patch should be applied after the first one?
>
> Heiko
>
>> -----Original Message-----
>> From: Stefan Engel [mailto:ma...@en...]
>> Sent: Monday, May 10, 2010 6:01 PM
>> To: dev...@li...
>> Subject: Re: [Devil-linux-develop] Enable "nameif" to associate MAC
>> address with correct interface name
>>
>> Hi,
>>
>> thanks to Steve and Roy for helping getting this setup started.
>> Until
>> now I didn't know there is this nice little tool called nameif.
>>
>> I just polished the patch a little bit and modified the code which
>> creates /etc/mactab from /etc/mactable.conf. I uploaded it as
>> network_mactable.patch to bug #73.
>>
>> After patching the /etc/init.d/network script now works as follows:
>> # if /etc/mactable.conf doesn't exist, just proceed as normal
>> # if /etc/mactable.conf exists, then
>> ## get MAC addresses of all interfaces (via ip link show)
>> ## skip any empty lines or comment lines beginning with '#' in
>> /etc/mactable.conf
>> ## check if interface definitions are found in /etc/mactable.conf
>> ### if so, then write interface definitions into /etc/mactab.tmp
>> ### if not, then issue a warning about the not defined interface(s)
>> ## if all interfaces are found, rename /etc/mactab.tmp into
>> /etc/mactab
>> ## if an interface definition is missing, then remove
>> /etc/mactab.tmp
>> and don't touch an already existing /etc/mactab
>>
>> After that, the patch works as suggested: if /etc/mactab exists,
>> then
>> use it. If not, skip this stuff and proceed as normal.
>>
>> With my setup here everything works as expected (after defining the
>> MAC
>> addresses of course). So in case of trouble, I don't have to think
>> about
>> the correct MAC setup to get things running again, but I can now
>> switch
>> the usb-stick with the firewall config from one machine to another
>> and
>> that's it.
>>
>> Regards,
>> Stefan
>>
>> roy barnard wrote:
>> > Stefan,
>> >
>> > I helped Steve Ralph write the patch.
>> > Your understanding of regexp is way better than mine.
>> > I like this as it removes the need for the "cut" command which
>> should speed the code up.
>> >
>> > I had to read it twice to get it but today I learnt a little more
>> regexp.
>> >
>> > Thank you.
>> >
>> > Roy Barnard
>> >
>> >
>> > --- On Wed, 5/5/10, Stefan Engel <ma...@en...> wrote:
>> >
>> >> From: Stefan Engel <ma...@en...>
>> >> Subject: Re: [Devil-linux-develop] Enable "nameif" to associate
>> MAC address with correct interface name
>> >> To: dev...@li...
>> >> Date: Wednesday, 5 May, 2010, 23:18
>> >> I did some testing with the patch and
>> >> it looks good so far. Only thing I
>> >> would change is the regexp. From:
>> >>
>> >> MacList=`/sbin/ip addr show | /bin/grep  "link/ether"
>> >> | /bin/sed
>> >> "s#.*link\/ether \| brd #\|#ig" | /usr/bin/cut -f2 -d'|'`
>> >>
>> >> to:
>> >> MacList=`/sbin/ip link show | /bin/grep  "ether" |
>> >> /bin/sed "s#.*ether
>> >> \([0-9a-f:]*\) .*#\1#ig"`
>> >>
>> >> Regards,
>> >> Stefan
>> >>
>> >> Stefan Engel wrote:
>> >>> Hi,
>> >>>
>> >>> his patch looks just like what I have been looking
>> >> for. I will add it to
>> >>> my VM test environment for testing. As far as I can
>> >> see, nothing of the
>> >>> current network handling gets broken if /etc/mactab
>> >> and
>> >>> /etc/mactable.conf are missing, so I would vote to add
>> >> this patch to DL.
>> >>> Regards,
>> >>> Stefan
>> >>>
>> >>> Steve Ralph wrote:
>> >>>> Hi,
>> >>>>
>> >>>> I have just submitted a mantis-patch for
>> >> "/etc/init.d/network" that
>> >>>> calls nameif to name network interfaces based on
>> >> MAC addresses. The call
>> >>>> is only made if the required "/etc/mactab" file
>> >> exists and is readable.
>> >>>> Nameif is called on a per-interface basis after
>> >> the module has been
>> >>>> modprob'ed into place.
>> >>>>
>> >>>> Please note that the version of
>> >> "/etc/init.d/network" that was used as a
>> >>>> starting point was "# $Revision: 1.44 $" which is
>> >> has been patched for
>> >>>> interface aliases and has a higher revision number
>> >> than version 1.43
>> >>>> that ships with DL-1.4-RC3.
>> >>>>
>> >>>> There are two distinct but linked patches
>> >> contained in the one file.
>> >>>> They could be separated quite easily, if
>> >> required.
>> >>>>
>> >>>> The first patch that calls nameif/mactab is:
>> >>>> @@ -162,8 +163,18 @@
>> >>>>
>> >>         if [ "$MODULE" != "UNKNOWN" ]
>> >> && [ "$MODULE" !=
>> >>>> "autoselect" ] ; then
>> >>>>
>> >>
>> >>     modprobe $MODULE $MODULE_OPTS > /dev/null
>> >>>>
>> >>         fi
>> >>>>
>> >>     fi
>> >>>> +
>> >>    # Using /etc/mactab (may have been created
>> >> from
>> >>>> /etc/mactable.conf
>> >>>> +
>> >>    #       Process
>> >> IF for active Media Access Control
>> >>>> (Ethernet MAC) Address.
>> >>>> +
>> >>    # Only process interfaces which DON'T have
>> >> a :-_.
>> >>>> (Colon/dash/underscore/dot) in them.
>> >>>> +
>> >>    #
>> >>>> +
>> >>    if [ -r /etc/mactab ]; then
>> >>>> +
>> >>          if [ `expr index
>> >> "$IF" ":-_."` == 0 ];   then
>> >>>> +
>> >>
>> >>    UseIFMac=`/bin/grep --ignore-case "^$IF"
>> >>>> /etc/mactab`
>> >>>> +
>> >>
>> >>    /sbin/nameif -s $UseIFMac
>> >>>> +
>> >>          fi
>> >>>> +
>> >>    fi
>> >>>>
>> >>>>
>> >>>>
>> >>     if [ "$WIRELESS" = "yes" ]; then
>> >>>>
>> >>             setup_wireless
>> >> $DEVICE
>> >>>>
>> >>>> The format for the optional configuration file
>> >> "/etc/mactab" may be
>> >>>> taken from my proposed "/etc/mactab.sample":
>> >>>>
>> >>>>         #---
>> >> /etc/mactab.sample
>> >>>>         #
>> >>>>         #
>> >>      Example format for /etc/mactab.
>> >>>>         #
>> >>      Used by nameif to name network
>> >> interfaces based on MAC
>> >>>> addresses
>> >>>>         #
>> >>>>         eth0
>> >>   00:40:f4:b8:db:2f
>> >>>>         eth1
>> >>   00:40:f4:b8:db:2e
>> >>>>         eth2
>> >>   00:40:f4:b8:db:2d
>> >>>>         #
>> >>>>         #--- End
>> >>>>
>> >>>> I believe this implements standard functionality
>> >> to control network
>> >>>> interfaces names based on MAC addresses.
>> >>>>
>> >>>> If implemented, this would prevent udev shuffling
>> >> interface names across
>> >>>> a system reboot.
>> >>>>
>> >>>> The second part of the patch introduces new
>> >> functionality with the
>> >>>> specific aim to allow a single DL-etc-mods.tar.bz2
>> >> config to be moved
>> >>>> onto a cold-standby unit, and automatically
>> >> receive the correct
>> >>>> (preconfigured) interface assignments.
>> >>>>
>> >>>> The patch is a follows:
>> >>>>
>> >>>> @@ -376,8 +387,16 @@
>> >>>>
>> >>     # if vlan tools are installed set vlan naming
>> >> shema
>> >>>>
>> >>     #
>> >>>>
>> >>     test -x $VLAN && $VLAN set_name_type
>> >>>> VLAN_PLUS_VID_NO_PAD &> /dev/null
>> >>>>
>> >>>> +
>> >>    # if /etc/mactable.conf is readable then
>> >>>> +
>> >>    #       extract
>> >> lines for each available MAC Address we
>> >>>> have
>> >>>> +
>> >>    #       and
>> >> create/overwrite /etc/mactab
>> >>>> +
>> >>    if [ -r /etc/mactable.conf ]; then
>> >>>> +
>> >>          MacList=`/sbin/ip
>> >> addr show | /bin/grep
>> >>>> "link/ether" | /bin/sed "s#.*link\/ether \| brd
>> >> #\|#ig" | /usr/bin/cut
>> >>>> -f2 -d'|'`
>> >>>> +
>> >>          /bin/grep -F
>> >> "$MacList" /etc/mactable.conf |
>> >>>> /usr/bin/cut -f-2 -d'|' | /bin/sed "s#|# #"
>> >>> /etc/mactab
>> >>>> +
>> >>    fi
>> >>>> +
>> >>>>
>> >>     #
>> >>>>
>> >>     # physical interfaces are brought up first
>> >>>>
>> >>     #
>> >>>>
>> >>     for interface in $(cd ${CONFIG_DIR}; ls -1
>> >>>> ${CONFIG_FILE}* 2>/dev/null | sed \
>> >>>>
>> >>>> The key here is the use of a new
>> >> "/etc/mactable.conf " config file which
>> >>>> is preconfigured with interface and MAC details
>> >> for both the production
>> >>>> and the standby hardware.
>> >>>>
>> >>>> Again, the format for the optional configuration
>> >> file
>> >>>> "/etc/mactable.conf" may be taken from my
>> >> proposed
>> >>>> "/etc/mactable.conf.sample":
>> >>>>
>> >>>>         #---
>> >> /etc/mactable.conf.sample
>> >>>>         #
>> >>>>         # Interface
>> >> name | MAC Address | Comment
>> >>>>         #
>> >>>>
>> >>    eth0|00:40:f4:b8:db:2f| Gannet01
>> >> (Production fw) lan1
>> >>>>
>> >>    eth1|00:40:f4:b8:db:2e| Gannet01
>> >> (Production fw) lan2
>> >>>>
>> >>    eth2|00:40:f4:b8:db:2d| Gannet01
>> >> (Production fw) lan3
>> >>>>         #
>> >>>>
>> >>    eth0|00:30:18:49:5f:08| Gannet02 (Cold
>> >> Standby fw) lan1
>> >>>>
>> >>    eth1|00:30:18:49:5f:07| Gannet02 (Cold
>> >> Standby fw) lan2
>> >>>>
>> >>    eth2|00:30:18:49:5f:06| Gannet02 (Cold
>> >> Standby fw) lan3
>> >>>>         #
>> >>>>
>> >>    eth0|00:11:85:10:be:f9| Hippopotamus
>> >> (Development/testbed) eth0
>> >>>>
>> >>    eth1|00:10:5a:28:51:36| Hippopotamus
>> >> (Development/testbed) eth1
>> >>>>
>> >>    eth2|00:50:04:3a:aa:5b| Hippopotamus
>> >> (Development/testbed) eth2
>> >>>>         #
>> >>>>         #--- End
>> >>>>
>> >>>> Here three systems have their interface and mac
>> >> details catalogued. When
>> >>>> the patched "/etc/init.d/network" file is run, it
>> >> extracts mac-addresses
>> >>>> from "/etc/mactable.conf " that match the
>> >> physically identified
>> >>>> interfaces, and repopulates "/etc/mactab" ready
>> >> for nameif to use, but
>> >>>> containing only details appropriate for (in the
>> >> sample) "Gannet01",
>> >>>> "Gannet02", or "Hippopotamus".
>> >>>>
>> >>>> If the first "/etc/mactab" patch is rejected, then
>> >> the second
>> >>>> "/etc/mactable.conf" automatically falls, as it
>> >> depends on nameif being
>> >>>> run against the newly created " /etc/mactab"
>> >> file.
>> >>>>
>> >>>> This will, I believe, give Stefan [ma...@en...]
>> >> the ability to
>> >>>> have a replacement firewall on cold-standby.
>> >>>>
>> >>>> Much of the above code must be credited to my
>> >> colleague Roy Barnard.
>> >>>>
>> >>>> Regards - Steve.
>> >>>>
>> >>>> Stephen H F Ralph
>> >>>> Principal Computer Officer | Integration Team |
>> >> ICT Services | Transform
>> >>>> Sandwell
>> >>>> Sandwell MBC | Freeth Street | Oldbury | West
>> >> Midlands | B69 3DE
>> >>>> Tel: 0121 569 3132 | Fax: 0121 569 3493
>> >>>> Email: ste...@sa...
>> >> <mailto:ste...@sa...>
>>
>>
>> -------------------------------------------------------------------
>> -----------
>>
>> _______________________________________________
>> Devil-linux-develop mailing list
>> Dev...@li...
>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>



--

Regards
   Heiko Zuerker
   http://www.devil-linux.org


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



------------------------------------------------------------------------------

_______________________________________________
Devil-linux-develop mailing list
Dev...@li...
https://lists.sourceforge.net/lists/listinfo/devil-linux-develop

I'm having trouble applying the patches.
Could one of you just send me the already patched network script?

Thanks
Heiko

Quoting Heiko Zuerker <he...@zu...>:

> I finally have some time to look at this...
> The new patch should be applied after the first one?
>
> Heiko
>
>> -----Original Message-----
>> From: Stefan Engel [mailto:ma...@en...]
>> Sent: Monday, May 10, 2010 6:01 PM
>> To: dev...@li...
>> Subject: Re: [Devil-linux-develop] Enable "nameif" to associate MAC
>> address with correct interface name
>>
>> Hi,
>>
>> thanks to Steve and Roy for helping getting this setup started.
>> Until
>> now I didn't know there is this nice little tool called nameif.
>>
>> I just polished the patch a little bit and modified the code which
>> creates /etc/mactab from /etc/mactable.conf. I uploaded it as
>> network_mactable.patch to bug #73.
>>
>> After patching the /etc/init.d/network script now works as follows:
>> # if /etc/mactable.conf doesn't exist, just proceed as normal
>> # if /etc/mactable.conf exists, then
>> ## get MAC addresses of all interfaces (via ip link show)
>> ## skip any empty lines or comment lines beginning with '#' in
>> /etc/mactable.conf
>> ## check if interface definitions are found in /etc/mactable.conf
>> ### if so, then write interface definitions into /etc/mactab.tmp
>> ### if not, then issue a warning about the not defined interface(s)
>> ## if all interfaces are found, rename /etc/mactab.tmp into
>> /etc/mactab
>> ## if an interface definition is missing, then remove
>> /etc/mactab.tmp
>> and don't touch an already existing /etc/mactab
>>
>> After that, the patch works as suggested: if /etc/mactab exists,
>> then
>> use it. If not, skip this stuff and proceed as normal.
>>
>> With my setup here everything works as expected (after defining the
>> MAC
>> addresses of course). So in case of trouble, I don't have to think
>> about
>> the correct MAC setup to get things running again, but I can now
>> switch
>> the usb-stick with the firewall config from one machine to another
>> and
>> that's it.
>>
>> Regards,
>> Stefan
>>
>> roy barnard wrote:
>> > Stefan,
>> >
>> > I helped Steve Ralph write the patch.
>> > Your understanding of regexp is way better than mine.
>> > I like this as it removes the need for the "cut" command which
>> should speed the code up.
>> >
>> > I had to read it twice to get it but today I learnt a little more
>> regexp.
>> >
>> > Thank you.
>> >
>> > Roy Barnard
>> >
>> >
>> > --- On Wed, 5/5/10, Stefan Engel <ma...@en...> wrote:
>> >
>> >> From: Stefan Engel <ma...@en...>
>> >> Subject: Re: [Devil-linux-develop] Enable "nameif" to associate
>> MAC address with correct interface name
>> >> To: dev...@li...
>> >> Date: Wednesday, 5 May, 2010, 23:18
>> >> I did some testing with the patch and
>> >> it looks good so far. Only thing I
>> >> would change is the regexp. From:
>> >>
>> >> MacList=`/sbin/ip addr show | /bin/grep  "link/ether"
>> >> | /bin/sed
>> >> "s#.*link\/ether \| brd #\|#ig" | /usr/bin/cut -f2 -d'|'`
>> >>
>> >> to:
>> >> MacList=`/sbin/ip link show | /bin/grep  "ether" |
>> >> /bin/sed "s#.*ether
>> >> \([0-9a-f:]*\) .*#\1#ig"`
>> >>
>> >> Regards,
>> >> Stefan
>> >>
>> >> Stefan Engel wrote:
>> >>> Hi,
>> >>>
>> >>> his patch looks just like what I have been looking
>> >> for. I will add it to
>> >>> my VM test environment for testing. As far as I can
>> >> see, nothing of the
>> >>> current network handling gets broken if /etc/mactab
>> >> and
>> >>> /etc/mactable.conf are missing, so I would vote to add
>> >> this patch to DL.
>> >>> Regards,
>> >>> Stefan
>> >>>
>> >>> Steve Ralph wrote:
>> >>>> Hi,
>> >>>>
>> >>>> I have just submitted a mantis-patch for
>> >> "/etc/init.d/network" that
>> >>>> calls nameif to name network interfaces based on
>> >> MAC addresses. The call
>> >>>> is only made if the required "/etc/mactab" file
>> >> exists and is readable.
>> >>>> Nameif is called on a per-interface basis after
>> >> the module has been
>> >>>> modprob'ed into place.
>> >>>>
>> >>>> Please note that the version of
>> >> "/etc/init.d/network" that was used as a
>> >>>> starting point was "# $Revision: 1.44 $" which is
>> >> has been patched for
>> >>>> interface aliases and has a higher revision number
>> >> than version 1.43
>> >>>> that ships with DL-1.4-RC3.
>> >>>>
>> >>>> There are two distinct but linked patches
>> >> contained in the one file.
>> >>>> They could be separated quite easily, if
>> >> required.
>> >>>>
>> >>>> The first patch that calls nameif/mactab is:
>> >>>> @@ -162,8 +163,18 @@
>> >>>>
>> >>         if [ "$MODULE" != "UNKNOWN" ]
>> >> && [ "$MODULE" !=
>> >>>> "autoselect" ] ; then
>> >>>>
>> >>
>> >>     modprobe $MODULE $MODULE_OPTS > /dev/null
>> >>>>
>> >>         fi
>> >>>>
>> >>     fi
>> >>>> +
>> >>    # Using /etc/mactab (may have been created
>> >> from
>> >>>> /etc/mactable.conf
>> >>>> +
>> >>    #       Process
>> >> IF for active Media Access Control
>> >>>> (Ethernet MAC) Address.
>> >>>> +
>> >>    # Only process interfaces which DON'T have
>> >> a :-_.
>> >>>> (Colon/dash/underscore/dot) in them.
>> >>>> +
>> >>    #
>> >>>> +
>> >>    if [ -r /etc/mactab ]; then
>> >>>> +
>> >>          if [ `expr index
>> >> "$IF" ":-_."` == 0 ];   then
>> >>>> +
>> >>
>> >>    UseIFMac=`/bin/grep --ignore-case "^$IF"
>> >>>> /etc/mactab`
>> >>>> +
>> >>
>> >>    /sbin/nameif -s $UseIFMac
>> >>>> +
>> >>          fi
>> >>>> +
>> >>    fi
>> >>>>
>> >>>>
>> >>>>
>> >>     if [ "$WIRELESS" = "yes" ]; then
>> >>>>
>> >>             setup_wireless
>> >> $DEVICE
>> >>>>
>> >>>> The format for the optional configuration file
>> >> "/etc/mactab" may be
>> >>>> taken from my proposed "/etc/mactab.sample":
>> >>>>
>> >>>>         #---
>> >> /etc/mactab.sample
>> >>>>         #
>> >>>>         #
>> >>      Example format for /etc/mactab.
>> >>>>         #
>> >>      Used by nameif to name network
>> >> interfaces based on MAC
>> >>>> addresses
>> >>>>         #
>> >>>>         eth0
>> >>   00:40:f4:b8:db:2f
>> >>>>         eth1
>> >>   00:40:f4:b8:db:2e
>> >>>>         eth2
>> >>   00:40:f4:b8:db:2d
>> >>>>         #
>> >>>>         #--- End
>> >>>>
>> >>>> I believe this implements standard functionality
>> >> to control network
>> >>>> interfaces names based on MAC addresses.
>> >>>>
>> >>>> If implemented, this would prevent udev shuffling
>> >> interface names across
>> >>>> a system reboot.
>> >>>>
>> >>>> The second part of the patch introduces new
>> >> functionality with the
>> >>>> specific aim to allow a single DL-etc-mods.tar.bz2
>> >> config to be moved
>> >>>> onto a cold-standby unit, and automatically
>> >> receive the correct
>> >>>> (preconfigured) interface assignments.
>> >>>>
>> >>>> The patch is a follows:
>> >>>>
>> >>>> @@ -376,8 +387,16 @@
>> >>>>
>> >>     # if vlan tools are installed set vlan naming
>> >> shema
>> >>>>
>> >>     #
>> >>>>
>> >>     test -x $VLAN && $VLAN set_name_type
>> >>>> VLAN_PLUS_VID_NO_PAD &> /dev/null
>> >>>>
>> >>>> +
>> >>    # if /etc/mactable.conf is readable then
>> >>>> +
>> >>    #       extract
>> >> lines for each available MAC Address we
>> >>>> have
>> >>>> +
>> >>    #       and
>> >> create/overwrite /etc/mactab
>> >>>> +
>> >>    if [ -r /etc/mactable.conf ]; then
>> >>>> +
>> >>          MacList=`/sbin/ip
>> >> addr show | /bin/grep
>> >>>> "link/ether" | /bin/sed "s#.*link\/ether \| brd
>> >> #\|#ig" | /usr/bin/cut
>> >>>> -f2 -d'|'`
>> >>>> +
>> >>          /bin/grep -F
>> >> "$MacList" /etc/mactable.conf |
>> >>>> /usr/bin/cut -f-2 -d'|' | /bin/sed "s#|# #"
>> >>> /etc/mactab
>> >>>> +
>> >>    fi
>> >>>> +
>> >>>>
>> >>     #
>> >>>>
>> >>     # physical interfaces are brought up first
>> >>>>
>> >>     #
>> >>>>
>> >>     for interface in $(cd ${CONFIG_DIR}; ls -1
>> >>>> ${CONFIG_FILE}* 2>/dev/null | sed \
>> >>>>
>> >>>> The key here is the use of a new
>> >> "/etc/mactable.conf " config file which
>> >>>> is preconfigured with interface and MAC details
>> >> for both the production
>> >>>> and the standby hardware.
>> >>>>
>> >>>> Again, the format for the optional configuration
>> >> file
>> >>>> "/etc/mactable.conf" may be taken from my
>> >> proposed
>> >>>> "/etc/mactable.conf.sample":
>> >>>>
>> >>>>         #---
>> >> /etc/mactable.conf.sample
>> >>>>         #
>> >>>>         # Interface
>> >> name | MAC Address | Comment
>> >>>>         #
>> >>>>
>> >>    eth0|00:40:f4:b8:db:2f| Gannet01
>> >> (Production fw) lan1
>> >>>>
>> >>    eth1|00:40:f4:b8:db:2e| Gannet01
>> >> (Production fw) lan2
>> >>>>
>> >>    eth2|00:40:f4:b8:db:2d| Gannet01
>> >> (Production fw) lan3
>> >>>>         #
>> >>>>
>> >>    eth0|00:30:18:49:5f:08| Gannet02 (Cold
>> >> Standby fw) lan1
>> >>>>
>> >>    eth1|00:30:18:49:5f:07| Gannet02 (Cold
>> >> Standby fw) lan2
>> >>>>
>> >>    eth2|00:30:18:49:5f:06| Gannet02 (Cold
>> >> Standby fw) lan3
>> >>>>         #
>> >>>>
>> >>    eth0|00:11:85:10:be:f9| Hippopotamus
>> >> (Development/testbed) eth0
>> >>>>
>> >>    eth1|00:10:5a:28:51:36| Hippopotamus
>> >> (Development/testbed) eth1
>> >>>>
>> >>    eth2|00:50:04:3a:aa:5b| Hippopotamus
>> >> (Development/testbed) eth2
>> >>>>         #
>> >>>>         #--- End
>> >>>>
>> >>>> Here three systems have their interface and mac
>> >> details catalogued. When
>> >>>> the patched "/etc/init.d/network" file is run, it
>> >> extracts mac-addresses
>> >>>> from "/etc/mactable.conf " that match the
>> >> physically identified
>> >>>> interfaces, and repopulates "/etc/mactab" ready
>> >> for nameif to use, but
>> >>>> containing only details appropriate for (in the
>> >> sample) "Gannet01",
>> >>>> "Gannet02", or "Hippopotamus".
>> >>>>
>> >>>> If the first "/etc/mactab" patch is rejected, then
>> >> the second
>> >>>> "/etc/mactable.conf" automatically falls, as it
>> >> depends on nameif being
>> >>>> run against the newly created " /etc/mactab"
>> >> file.
>> >>>>
>> >>>> This will, I believe, give Stefan [ma...@en...]
>> >> the ability to
>> >>>> have a replacement firewall on cold-standby.
>> >>>>
>> >>>> Much of the above code must be credited to my
>> >> colleague Roy Barnard.
>> >>>>
>> >>>> Regards - Steve.
>> >>>>
>> >>>> Stephen H F Ralph
>> >>>> Principal Computer Officer | Integration Team |
>> >> ICT Services | Transform
>> >>>> Sandwell
>> >>>> Sandwell MBC | Freeth Street | Oldbury | West
>> >> Midlands | B69 3DE
>> >>>> Tel: 0121 569 3132 | Fax: 0121 569 3493
>> >>>> Email: ste...@sa...
>> >> <mailto:ste...@sa...>
>>
>>
>> -------------------------------------------------------------------
>> -----------
>>
>> _______________________________________________
>> Devil-linux-develop mailing list
>> Dev...@li...
>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>



-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

I finally have some time to look at this...
The new patch should be applied after the first one?

Heiko

> -----Original Message-----
> From: Stefan Engel [mailto:ma...@en...]
> Sent: Monday, May 10, 2010 6:01 PM
> To: dev...@li...
> Subject: Re: [Devil-linux-develop] Enable "nameif" to associate MAC
> address with correct interface name
> 
> Hi,
> 
> thanks to Steve and Roy for helping getting this setup started.
> Until
> now I didn't know there is this nice little tool called nameif.
> 
> I just polished the patch a little bit and modified the code which
> creates /etc/mactab from /etc/mactable.conf. I uploaded it as
> network_mactable.patch to bug #73.
> 
> After patching the /etc/init.d/network script now works as follows:
> # if /etc/mactable.conf doesn't exist, just proceed as normal
> # if /etc/mactable.conf exists, then
> ## get MAC addresses of all interfaces (via ip link show)
> ## skip any empty lines or comment lines beginning with '#' in
> /etc/mactable.conf
> ## check if interface definitions are found in /etc/mactable.conf
> ### if so, then write interface definitions into /etc/mactab.tmp
> ### if not, then issue a warning about the not defined interface(s)
> ## if all interfaces are found, rename /etc/mactab.tmp into
> /etc/mactab
> ## if an interface definition is missing, then remove
> /etc/mactab.tmp
> and don't touch an already existing /etc/mactab
> 
> After that, the patch works as suggested: if /etc/mactab exists,
> then
> use it. If not, skip this stuff and proceed as normal.
> 
> With my setup here everything works as expected (after defining the
> MAC
> addresses of course). So in case of trouble, I don't have to think
> about
> the correct MAC setup to get things running again, but I can now
> switch
> the usb-stick with the firewall config from one machine to another
> and
> that's it.
> 
> Regards,
> Stefan
> 
> roy barnard wrote:
> > Stefan,
> >
> > I helped Steve Ralph write the patch.
> > Your understanding of regexp is way better than mine.
> > I like this as it removes the need for the "cut" command which
> should speed the code up.
> >
> > I had to read it twice to get it but today I learnt a little more
> regexp.
> >
> > Thank you.
> >
> > Roy Barnard
> >
> >
> > --- On Wed, 5/5/10, Stefan Engel <ma...@en...> wrote:
> >
> >> From: Stefan Engel <ma...@en...>
> >> Subject: Re: [Devil-linux-develop] Enable "nameif" to associate
> MAC address with correct interface name
> >> To: dev...@li...
> >> Date: Wednesday, 5 May, 2010, 23:18
> >> I did some testing with the patch and
> >> it looks good so far. Only thing I
> >> would change is the regexp. From:
> >>
> >> MacList=`/sbin/ip addr show | /bin/grep  "link/ether"
> >> | /bin/sed
> >> "s#.*link\/ether \| brd #\|#ig" | /usr/bin/cut -f2 -d'|'`
> >>
> >> to:
> >> MacList=`/sbin/ip link show | /bin/grep  "ether" |
> >> /bin/sed "s#.*ether
> >> \([0-9a-f:]*\) .*#\1#ig"`
> >>
> >> Regards,
> >> Stefan
> >>
> >> Stefan Engel wrote:
> >>> Hi,
> >>>
> >>> his patch looks just like what I have been looking
> >> for. I will add it to
> >>> my VM test environment for testing. As far as I can
> >> see, nothing of the
> >>> current network handling gets broken if /etc/mactab
> >> and
> >>> /etc/mactable.conf are missing, so I would vote to add
> >> this patch to DL.
> >>> Regards,
> >>> Stefan
> >>>
> >>> Steve Ralph wrote:
> >>>> Hi,
> >>>>
> >>>> I have just submitted a mantis-patch for
> >> "/etc/init.d/network" that
> >>>> calls nameif to name network interfaces based on
> >> MAC addresses. The call
> >>>> is only made if the required "/etc/mactab" file
> >> exists and is readable.
> >>>> Nameif is called on a per-interface basis after
> >> the module has been
> >>>> modprob'ed into place.
> >>>>
> >>>> Please note that the version of
> >> "/etc/init.d/network" that was used as a
> >>>> starting point was "# $Revision: 1.44 $" which is
> >> has been patched for
> >>>> interface aliases and has a higher revision number
> >> than version 1.43
> >>>> that ships with DL-1.4-RC3.
> >>>>
> >>>> There are two distinct but linked patches
> >> contained in the one file.
> >>>> They could be separated quite easily, if
> >> required.
> >>>>
> >>>> The first patch that calls nameif/mactab is:
> >>>> @@ -162,8 +163,18 @@
> >>>>
> >>         if [ "$MODULE" != "UNKNOWN" ]
> >> && [ "$MODULE" !=
> >>>> "autoselect" ] ; then
> >>>>
> >>
> >>     modprobe $MODULE $MODULE_OPTS > /dev/null
> >>>>
> >>         fi
> >>>>
> >>     fi
> >>>> +
> >>    # Using /etc/mactab (may have been created
> >> from
> >>>> /etc/mactable.conf
> >>>> +
> >>    #       Process
> >> IF for active Media Access Control
> >>>> (Ethernet MAC) Address.
> >>>> +
> >>    # Only process interfaces which DON'T have
> >> a :-_.
> >>>> (Colon/dash/underscore/dot) in them.
> >>>> +
> >>    #
> >>>> +
> >>    if [ -r /etc/mactab ]; then
> >>>> +
> >>          if [ `expr index
> >> "$IF" ":-_."` == 0 ];   then
> >>>> +
> >>
> >>    UseIFMac=`/bin/grep --ignore-case "^$IF"
> >>>> /etc/mactab`
> >>>> +
> >>
> >>    /sbin/nameif -s $UseIFMac
> >>>> +
> >>          fi
> >>>> +
> >>    fi
> >>>>
> >>>>
> >>>>
> >>     if [ "$WIRELESS" = "yes" ]; then
> >>>>
> >>             setup_wireless
> >> $DEVICE
> >>>>
> >>>> The format for the optional configuration file
> >> "/etc/mactab" may be
> >>>> taken from my proposed "/etc/mactab.sample":
> >>>>
> >>>>         #---
> >> /etc/mactab.sample
> >>>>         #
> >>>>         #
> >>      Example format for /etc/mactab.
> >>>>         #
> >>      Used by nameif to name network
> >> interfaces based on MAC
> >>>> addresses
> >>>>         #
> >>>>         eth0
> >>   00:40:f4:b8:db:2f
> >>>>         eth1
> >>   00:40:f4:b8:db:2e
> >>>>         eth2
> >>   00:40:f4:b8:db:2d
> >>>>         #
> >>>>         #--- End
> >>>>
> >>>> I believe this implements standard functionality
> >> to control network
> >>>> interfaces names based on MAC addresses.
> >>>>
> >>>> If implemented, this would prevent udev shuffling
> >> interface names across
> >>>> a system reboot.
> >>>>
> >>>> The second part of the patch introduces new
> >> functionality with the
> >>>> specific aim to allow a single DL-etc-mods.tar.bz2
> >> config to be moved
> >>>> onto a cold-standby unit, and automatically
> >> receive the correct
> >>>> (preconfigured) interface assignments.
> >>>>
> >>>> The patch is a follows:
> >>>>
> >>>> @@ -376,8 +387,16 @@
> >>>>
> >>     # if vlan tools are installed set vlan naming
> >> shema
> >>>>
> >>     #
> >>>>
> >>     test -x $VLAN && $VLAN set_name_type
> >>>> VLAN_PLUS_VID_NO_PAD &> /dev/null
> >>>>
> >>>> +
> >>    # if /etc/mactable.conf is readable then
> >>>> +
> >>    #       extract
> >> lines for each available MAC Address we
> >>>> have
> >>>> +
> >>    #       and
> >> create/overwrite /etc/mactab
> >>>> +
> >>    if [ -r /etc/mactable.conf ]; then
> >>>> +
> >>          MacList=`/sbin/ip
> >> addr show | /bin/grep
> >>>> "link/ether" | /bin/sed "s#.*link\/ether \| brd
> >> #\|#ig" | /usr/bin/cut
> >>>> -f2 -d'|'`
> >>>> +
> >>          /bin/grep -F
> >> "$MacList" /etc/mactable.conf |
> >>>> /usr/bin/cut -f-2 -d'|' | /bin/sed "s#|# #"
> >>> /etc/mactab
> >>>> +
> >>    fi
> >>>> +
> >>>>
> >>     #
> >>>>
> >>     # physical interfaces are brought up first
> >>>>
> >>     #
> >>>>
> >>     for interface in $(cd ${CONFIG_DIR}; ls -1
> >>>> ${CONFIG_FILE}* 2>/dev/null | sed \
> >>>>
> >>>> The key here is the use of a new
> >> "/etc/mactable.conf " config file which
> >>>> is preconfigured with interface and MAC details
> >> for both the production
> >>>> and the standby hardware.
> >>>>
> >>>> Again, the format for the optional configuration
> >> file
> >>>> "/etc/mactable.conf" may be taken from my
> >> proposed
> >>>> "/etc/mactable.conf.sample":
> >>>>
> >>>>         #---
> >> /etc/mactable.conf.sample
> >>>>         #
> >>>>         # Interface
> >> name | MAC Address | Comment
> >>>>         #
> >>>>
> >>    eth0|00:40:f4:b8:db:2f| Gannet01
> >> (Production fw) lan1
> >>>>
> >>    eth1|00:40:f4:b8:db:2e| Gannet01
> >> (Production fw) lan2
> >>>>
> >>    eth2|00:40:f4:b8:db:2d| Gannet01
> >> (Production fw) lan3
> >>>>         #
> >>>>
> >>    eth0|00:30:18:49:5f:08| Gannet02 (Cold
> >> Standby fw) lan1
> >>>>
> >>    eth1|00:30:18:49:5f:07| Gannet02 (Cold
> >> Standby fw) lan2
> >>>>
> >>    eth2|00:30:18:49:5f:06| Gannet02 (Cold
> >> Standby fw) lan3
> >>>>         #
> >>>>
> >>    eth0|00:11:85:10:be:f9| Hippopotamus
> >> (Development/testbed) eth0
> >>>>
> >>    eth1|00:10:5a:28:51:36| Hippopotamus
> >> (Development/testbed) eth1
> >>>>
> >>    eth2|00:50:04:3a:aa:5b| Hippopotamus
> >> (Development/testbed) eth2
> >>>>         #
> >>>>         #--- End
> >>>>
> >>>> Here three systems have their interface and mac
> >> details catalogued. When
> >>>> the patched "/etc/init.d/network" file is run, it
> >> extracts mac-addresses
> >>>> from "/etc/mactable.conf " that match the
> >> physically identified
> >>>> interfaces, and repopulates "/etc/mactab" ready
> >> for nameif to use, but
> >>>> containing only details appropriate for (in the
> >> sample) "Gannet01",
> >>>> "Gannet02", or "Hippopotamus".
> >>>>
> >>>> If the first "/etc/mactab" patch is rejected, then
> >> the second
> >>>> "/etc/mactable.conf" automatically falls, as it
> >> depends on nameif being
> >>>> run against the newly created " /etc/mactab"
> >> file.
> >>>>
> >>>> This will, I believe, give Stefan [ma...@en...]
> >> the ability to
> >>>> have a replacement firewall on cold-standby.
> >>>>
> >>>> Much of the above code must be credited to my
> >> colleague Roy Barnard.
> >>>>
> >>>> Regards - Steve.
> >>>>
> >>>> Stephen H F Ralph
> >>>> Principal Computer Officer | Integration Team |
> >> ICT Services | Transform
> >>>> Sandwell
> >>>> Sandwell MBC | Freeth Street | Oldbury | West
> >> Midlands | B69 3DE
> >>>> Tel: 0121 569 3132 | Fax: 0121 569 3493
> >>>> Email: ste...@sa...
> >> <mailto:ste...@sa...>
> 
> 
> -------------------------------------------------------------------
> -----------
> 
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop

All,

Thanks for taking time to discuss this idea.
Following up on replies in no specific order.

>>Heiko:
>>Although I like the idea, I'm still not convinced that we should do it.
>>It may be something we should add to Mantis for 1.5
>>(I created that project already in Mantis).
>>I'd rather get a final 1.4 out, so we can start working on new features but still have a stable tree.

Please don't delay 1.4 for this.
When we have a general agreement I will back port to my 1.4 Version knowing that the functionality will be in later versions.


>>Heiko:
>>would it help to have multiple boot.xxx scripts?
>>E.g. boot.mountfs, boot.network, boot.last ?
>>We would consider those user-scripts, just like the boot.local one.

I don't know.  Depends when the scripts are run and what is ready/not ready in the ram drive.


>>Serge:
>>In general, I like the idea, because it shows the unified way for init script extensions.
>>And, the most attractive part, it's disabled by default :)

I always try to ensure my idea's don't change the underlying functionality.
I break less this way.


>>Heiko:
>>*If* we would implement something like the proposal below,
>>I'd rather call 1 script and just give it a parameter like 'prestart' or 'poststop'.
>>This way there would be a lot less scripts.

I don't like the one script idea as it immediately cut down the functionality, unless the same script is called at lots of different places but that just makes things more complicated.

New Idea:
I have given this more thought and I have a modified version of my suggestion, that might be a better compromise but still giving the functionality that I would like to see.

In Centos the starting and stopping of services is handled by a script called "service".  Eg: service squid stop

If this script was created which handled my pre-start/pre-stop/post-start/post-stop system as described before, then the only change to DL would be to patch the /etc/init.d/rc script to use the new "service" script only if required.

Reasons:
uses Dick's suggested a wrapper script idea.
no changes to the existing init.d scripts.
Give me the required functionality.
Disabled by default as Serge likes.
Only requires modifying one existing script (/etc/init.d/rc)
/etc/init.d/squid stop works as expected.
easily ports backwards/forwards.

But......

/etc/init.d/service squid stop
would run any required pre-stop scripts call "/etc/init.d/squid stop" and then run and post-stop scripts.

I would make "service" to the /etc/init.d/ script even if there are no additional scripts.

I will mock this up over the next few days an report back.
Please feel free to comment on this new idea.

Many Thanks,
Roy Barnard



      

On 05/14/10 18:25, Heiko Zuerker wrote:
> Hey,
>
> would it help to have multiple boot.xxx scripts?
> E.g. boot.mountfs, boot.network, boot.last ?
> We would consider those user-scripts, just like the boot.local one.

If I understand the OP's problem correctly (which I might not) his 
problem arises because his spool directory is in ram and so its 
structure does not persist over reboots.

This may be a common difficulty for apps in diskless systems.  I think 
the problem might be resolved by having another script which is run 
after all disks, logical volumes etc are present but before any apps are 
started.  I think this can be done from a script in /etc/init.d/boot.d 
similar to boot.local but which is run last.  It could be called 
lateboot.local.

One issue that might arise is that the network is not running at this 
point and hostname has been set to a default value. Setting the hostname 
to a configured value in localnet may be a way around that.

Since such changes reside entirely in /etc a solution like this can be 
implemented by users on an ad-hoc basis and thus not impact the release 
of 1.4.

Dick

I did understand it the same way you did, but I was looking for a
compromise which would make everyone happy.
*If* we would implement something like the proposal below, I'd rather
call 1 script and just give it a parameter like 'prestart' or
'poststop'. This way there would be a lot less scripts.

Although I like the idea, I'm still not convinced that we should do it.
It may be something we should add to Mantis for 1.5 (I created that
project already in Mantis).
I'd rather get a final 1.4 out, so we can start working on new features
but still have a stable tree.

Heiko

> -----Original Message-----
> From: Serge Leschinsky [mailto:fi...@in...]
> Sent: Friday, May 14, 2010 4:00 PM
> To: dev...@li...
> Subject: Re: [Devil-linux-develop] Setting up directories in /var
> during boot.
> 
> Heiko,
> 
> I'd understood it a bit different way.
> 
> Each init script has 4 external calls (pre/post start, per/post
> stop) and those
> scripts are in the following filesystem hierarchy
> 
> 	xxxx/start/pre/<service-name>
> 	xxxx/start/post/<service-name>
> 	xxxx/stop/pre/<service-name>
> 	xxxx/stop/post/<service-name>
> 
> Those calls might be commented out by default to decrease
> unnecessary activity.
> 
> In general, I like the idea, because it shows the unified way for
> init script
> extensions. And, the most attractive part, it's disabled by default
> :)
> 
> 
> Serge
> 
> On 05/14/2010 10:25 AM, Heiko Zuerker wrote:
> > Hey,
> >
> > would it help to have multiple boot.xxx scripts?
> > E.g. boot.mountfs, boot.network, boot.last ?
> > We would consider those user-scripts, just like the boot.local
> one.
> >
> > Heiko
> >
> > Quoting roy barnard <roy...@ya...>:
> >
> >> Dick,
> >>
> >>> Although a bit of a bodge I think it would be more appropriate
> for one
> >>> to patch the few init files that are affected after each
> reinstall
> >>> (a relatively rare event) than impose all this dynamic on every
> service
> >>
> >> I don't disagree.  On my main firewall I run the same version of
> DL
> >> for a year or two then upgrade.
> >> When a new major version comes out I normally follow the Release
> >> Candidates, so this would incease my testing.
> >>
> >> I agree that the idea of only patching init.d scripts as
> required is
> >> "a bit of a bodge" and in my opinion makes things more difficult
> for
> >> others using the mechanic,as they would first have to check if
> the
> >> required init.d has been patched for Pre-Start scripts and then
> >> created the directory as per previous email.  I think this make
> the
> >> idea more complicated, I don't now if that is an issue as I
> would
> >> expect DL to be used by Linux Savvy SysAdmins.
> >>
> >> I did consider using an eviroment variable to enable/disable the
> >> functionality but as the directory existance checks are on the
> ram
> >> drive I could see no gain.
> >>
> >> I am interested in your other comment:
> >>> Or better still put the service in a wrapper script so that all
> >>> startup matters are part of the application concerned.
> >>
> >> Can you please expand your wrapper script idea, as this may be a
> >> better solution.
> >>
> >> Many Thanks,
> >> Roy Barnard
> >>
> >>
> >> --- On Tue, 11/5/10, Dick Middleton <di...@fo...> wrote:
> >>
> >>> From: Dick Middleton <di...@fo...>
> >>> Subject: Re: [Devil-linux-develop] Setting up directories in
> /var
> >>> during boot.
> >>> To: dev...@li...
> >>> Date: Tuesday, 11 May, 2010, 16:20
> >>> On 05/11/10 15:27, roy barnard
> >>> wrote:
> >>>
> >>>> If I just add the commands I need to the specific
> >>> init.d scripts, then it will solve my issues but it also
> >>> means I will need to edit and maintain these scripts each
> >>> time I upgrade to the next version of DL. If I need to apply
> >>> patches to any of my modified init.d scripts (from mantis
> >>> for example), I will need to remove my changes, patch and
> >>> then reapply my changes.
> >>>>
> >>>> I was trying to think about more of a global solution.
> >>> If this is an issue for me then I always try to consider if
> >>> it might be an issue for others.
> >>> ...
> >>>  > Does anyone else need this type of configuration
> >>> flexibility?
> >>>
> >>> It seems like a lot of overhead to run maybe one
> >>> script.   It does
> >>> depend how much this capability is likely to be used.
> >>>
> >>> Although a bit of a bodge I think it would be more
> >>> appropriate for one
> >>> to patch the few init files that are affected after each
> >>> reinstall (a
> >>> relatively rare event) than impose all this dynamic on
> >>> every service
> >>> just in case.  Or better still put the service in a
> >>> wrapper script so
> >>> that all startup matters are part of the application
> >>> concerned.
> >>>
> >>> Dick
> >>>
> >>>
> >>>
> >>> ---------------------------------------------------------------
> ---------------
> >>>
> >>> _______________________________________________
> >>> Devil-linux-develop mailing list
> >>> Dev...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/devil-linux-
> develop
> >>>
> >>
> >>
> >>
> >>
> >>
> >> ----------------------------------------------------------------
> --------------
> >>
> >> _______________________________________________
> >> Devil-linux-develop mailing list
> >> Dev...@li...
> >> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
> >>
> >
> >
> >
> 
> 
> -------------------------------------------------------------------
> -----------
> 
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop

Heiko,

I'd understood it a bit different way.

Each init script has 4 external calls (pre/post start, per/post stop) and those
scripts are in the following filesystem hierarchy

	xxxx/start/pre/<service-name>
	xxxx/start/post/<service-name>
	xxxx/stop/pre/<service-name>
	xxxx/stop/post/<service-name>

Those calls might be commented out by default to decrease unnecessary activity.

In general, I like the idea, because it shows the unified way for init script
extensions. And, the most attractive part, it's disabled by default :)


Serge

On 05/14/2010 10:25 AM, Heiko Zuerker wrote:
> Hey,
> 
> would it help to have multiple boot.xxx scripts?
> E.g. boot.mountfs, boot.network, boot.last ?
> We would consider those user-scripts, just like the boot.local one.
> 
> Heiko
> 
> Quoting roy barnard <roy...@ya...>:
> 
>> Dick,
>>
>>> Although a bit of a bodge I think it would be more appropriate for one
>>> to patch the few init files that are affected after each reinstall
>>> (a relatively rare event) than impose all this dynamic on every service
>>
>> I don't disagree.  On my main firewall I run the same version of DL  
>> for a year or two then upgrade.
>> When a new major version comes out I normally follow the Release  
>> Candidates, so this would incease my testing.
>>
>> I agree that the idea of only patching init.d scripts as required is  
>> "a bit of a bodge" and in my opinion makes things more difficult for  
>> others using the mechanic,as they would first have to check if the  
>> required init.d has been patched for Pre-Start scripts and then  
>> created the directory as per previous email.  I think this make the  
>> idea more complicated, I don't now if that is an issue as I would  
>> expect DL to be used by Linux Savvy SysAdmins.
>>
>> I did consider using an eviroment variable to enable/disable the  
>> functionality but as the directory existance checks are on the ram  
>> drive I could see no gain.
>>
>> I am interested in your other comment:
>>> Or better still put the service in a wrapper script so that all
>>> startup matters are part of the application concerned.
>>
>> Can you please expand your wrapper script idea, as this may be a  
>> better solution.
>>
>> Many Thanks,
>> Roy Barnard
>>
>>
>> --- On Tue, 11/5/10, Dick Middleton <di...@fo...> wrote:
>>
>>> From: Dick Middleton <di...@fo...>
>>> Subject: Re: [Devil-linux-develop] Setting up directories in /var  
>>> during boot.
>>> To: dev...@li...
>>> Date: Tuesday, 11 May, 2010, 16:20
>>> On 05/11/10 15:27, roy barnard
>>> wrote:
>>>
>>>> If I just add the commands I need to the specific
>>> init.d scripts, then it will solve my issues but it also
>>> means I will need to edit and maintain these scripts each
>>> time I upgrade to the next version of DL. If I need to apply
>>> patches to any of my modified init.d scripts (from mantis
>>> for example), I will need to remove my changes, patch and
>>> then reapply my changes.
>>>>
>>>> I was trying to think about more of a global solution.
>>> If this is an issue for me then I always try to consider if
>>> it might be an issue for others.
>>> ...
>>>  > Does anyone else need this type of configuration
>>> flexibility?
>>>
>>> It seems like a lot of overhead to run maybe one
>>> script.   It does
>>> depend how much this capability is likely to be used.
>>>
>>> Although a bit of a bodge I think it would be more
>>> appropriate for one
>>> to patch the few init files that are affected after each
>>> reinstall (a
>>> relatively rare event) than impose all this dynamic on
>>> every service
>>> just in case.  Or better still put the service in a
>>> wrapper script so
>>> that all startup matters are part of the application
>>> concerned.
>>>
>>> Dick
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Devil-linux-develop mailing list
>>> Dev...@li...
>>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>>
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Devil-linux-develop mailing list
>> Dev...@li...
>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>
> 
> 
> 

Hey,

would it help to have multiple boot.xxx scripts?
E.g. boot.mountfs, boot.network, boot.last ?
We would consider those user-scripts, just like the boot.local one.

Heiko

Quoting roy barnard <roy...@ya...>:

> Dick,
>
>> Although a bit of a bodge I think it would be more appropriate for one
>> to patch the few init files that are affected after each reinstall
>> (a relatively rare event) than impose all this dynamic on every service
>
> I don't disagree.  On my main firewall I run the same version of DL  
> for a year or two then upgrade.
> When a new major version comes out I normally follow the Release  
> Candidates, so this would incease my testing.
>
> I agree that the idea of only patching init.d scripts as required is  
> "a bit of a bodge" and in my opinion makes things more difficult for  
> others using the mechanic,as they would first have to check if the  
> required init.d has been patched for Pre-Start scripts and then  
> created the directory as per previous email.  I think this make the  
> idea more complicated, I don't now if that is an issue as I would  
> expect DL to be used by Linux Savvy SysAdmins.
>
> I did consider using an eviroment variable to enable/disable the  
> functionality but as the directory existance checks are on the ram  
> drive I could see no gain.
>
> I am interested in your other comment:
>> Or better still put the service in a wrapper script so that all
>> startup matters are part of the application concerned.
>
> Can you please expand your wrapper script idea, as this may be a  
> better solution.
>
> Many Thanks,
> Roy Barnard
>
>
> --- On Tue, 11/5/10, Dick Middleton <di...@fo...> wrote:
>
>> From: Dick Middleton <di...@fo...>
>> Subject: Re: [Devil-linux-develop] Setting up directories in /var  
>> during boot.
>> To: dev...@li...
>> Date: Tuesday, 11 May, 2010, 16:20
>> On 05/11/10 15:27, roy barnard
>> wrote:
>>
>> > If I just add the commands I need to the specific
>> init.d scripts, then it will solve my issues but it also
>> means I will need to edit and maintain these scripts each
>> time I upgrade to the next version of DL. If I need to apply
>> patches to any of my modified init.d scripts (from mantis
>> for example), I will need to remove my changes, patch and
>> then reapply my changes.
>> >
>> > I was trying to think about more of a global solution.
>> If this is an issue for me then I always try to consider if
>> it might be an issue for others.
>> ...
>>  > Does anyone else need this type of configuration
>> flexibility?
>>
>> It seems like a lot of overhead to run maybe one
>> script.   It does
>> depend how much this capability is likely to be used.
>>
>> Although a bit of a bodge I think it would be more
>> appropriate for one
>> to patch the few init files that are affected after each
>> reinstall (a
>> relatively rare event) than impose all this dynamic on
>> every service
>> just in case.  Or better still put the service in a
>> wrapper script so
>> that all startup matters are part of the application
>> concerned.
>>
>> Dick
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Devil-linux-develop mailing list
>> Dev...@li...
>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>
>
>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>



-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Dick,

> Although a bit of a bodge I think it would be more appropriate for one 
> to patch the few init files that are affected after each reinstall
> (a relatively rare event) than impose all this dynamic on every service 

I don't disagree.  On my main firewall I run the same version of DL for a year or two then upgrade.
When a new major version comes out I normally follow the Release Candidates, so this would incease my testing.

I agree that the idea of only patching init.d scripts as required is "a bit of a bodge" and in my opinion makes things more difficult for others using the mechanic,as they would first have to check if the required init.d has been patched for Pre-Start scripts and then created the directory as per previous email.  I think this make the idea more complicated, I don't now if that is an issue as I would expect DL to be used by Linux Savvy SysAdmins.

I did consider using an eviroment variable to enable/disable the functionality but as the directory existance checks are on the ram drive I could see no gain.

I am interested in your other comment:
> Or better still put the service in a wrapper script so that all
> startup matters are part of the application concerned.

Can you please expand your wrapper script idea, as this may be a better solution.

Many Thanks,
Roy Barnard


--- On Tue, 11/5/10, Dick Middleton <di...@fo...> wrote:

> From: Dick Middleton <di...@fo...>
> Subject: Re: [Devil-linux-develop] Setting up directories in /var during boot.
> To: dev...@li...
> Date: Tuesday, 11 May, 2010, 16:20
> On 05/11/10 15:27, roy barnard
> wrote:
> 
> > If I just add the commands I need to the specific
> init.d scripts, then it will solve my issues but it also
> means I will need to edit and maintain these scripts each
> time I upgrade to the next version of DL. If I need to apply
> patches to any of my modified init.d scripts (from mantis
> for example), I will need to remove my changes, patch and
> then reapply my changes.
> >
> > I was trying to think about more of a global solution.
> If this is an issue for me then I always try to consider if
> it might be an issue for others.
> ...
>  > Does anyone else need this type of configuration
> flexibility?
> 
> It seems like a lot of overhead to run maybe one
> script.   It does 
> depend how much this capability is likely to be used.
> 
> Although a bit of a bodge I think it would be more
> appropriate for one 
> to patch the few init files that are affected after each
> reinstall (a 
> relatively rare event) than impose all this dynamic on
> every service 
> just in case.  Or better still put the service in a
> wrapper script so 
> that all startup matters are part of the application
> concerned.
> 
> Dick
> 
> 
> 
> ------------------------------------------------------------------------------
> 
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>


      

On 05/11/10 15:27, roy barnard wrote:

> If I just add the commands I need to the specific init.d scripts, then it will solve my issues but it also means I will need to edit and maintain these scripts each time I upgrade to the next version of DL. If I need to apply patches to any of my modified init.d scripts (from mantis for example), I will need to remove my changes, patch and then reapply my changes.
>
> I was trying to think about more of a global solution. If this is an issue for me then I always try to consider if it might be an issue for others.
...
 > Does anyone else need this type of configuration flexibility?

It seems like a lot of overhead to run maybe one script.   It does 
depend how much this capability is likely to be used.

Although a bit of a bodge I think it would be more appropriate for one 
to patch the few init files that are affected after each reinstall (a 
relatively rare event) than impose all this dynamic on every service 
just in case.  Or better still put the service in a wrapper script so 
that all startup matters are part of the application concerned.

Dick

Serge,

If I just add the commands I need to the specific init.d scripts, then it will solve my issues but it also means I will need to edit and maintain these scripts each time I upgrade to the next version of DL. If I need to apply patches to any of my modified init.d scripts (from mantis for example), I will need to remove my changes, patch and then reapply my changes.

I was trying to think about more of a global solution. If this is an issue for me then I always try to consider if it might be an issue for others.

Devil-Linux is different from, say, RHEL / Centos / Fedora, because the machine is partially stateless.

The etc-mods.tar.bz2 config file only handles etc (and root) but not the other parts of the system - this design is really good for firewalls and other security devices.

I have given some thought concerning a more global implementation for my suggestions, so here goes:

1) New subdirs are created eg:
        /etc/init.d/local-scripts/start/pre
        /etc/init.d/local-scripts/start/post
        /etc/init.d/local-scripts/stop/pre
        /etc/init.d/local-scripts/stop/post

2) Each init.d script is modified along these lines (I based this on /etc/init.d/skeleton):

start)
        [ -d /etc/init.d/local-scripts/start/pre/$0 ] && /usr/bin/run-parts /etc/init.d/local-scripts/start/pre/$0
                 # Existing Start code
         [ -d /etc/init.d/local-scripts/start/post/$0 ] && /usr/bin/run-parts /etc/init.d/local-scripts/start/post/$0
         ;;
stop)
        [ -d /etc/init.d/local-scripts/stop/pre/$0 ] && /usr/bin/run-parts /etc/init.d/local-scripts/stop/pre/$0
                # Existing Stop code
        [ -d /etc/init.d/local-scripts/stop/post/$0 ] && /usr/bin/run-parts /etc/init.d/local-scripts/stop/post/$0
        ;;

These proposals do *NOT* modify the existing behaviour of the current boot process in any way.

The directory check is done on the ramdisk so there should be minimal performance impact.

For my specific "lpd" problem, I would create a subdir "/etc/init.d/local-scripts/start/pre/lpd" and place any scripts here, naming them to set the run-parts ordering.

To migrate my changes between DL Versions I would copy the entire contents of "/etc/init.d/local-scripts/", in the same way that I would copy any other specific configuration.

I agree that some services may never need this, like beep, but I think this type of solution would work for me on lpd, squid, firewall and networking.

Does anyone else need this type of configuration flexibility?


Many Thanks,

Roy Barnard

--- On Mon, 10/5/10, Serge Leschinsky <fi...@in...> wrote:

> From: Serge Leschinsky <fi...@in...>
> Subject: Re: [Devil-linux-develop] Setting up directories in /var during boot.
> To: dev...@li...
> Cc: "roy barnard" <roy...@ya...>
> Date: Monday, 10 May, 2010, 0:09
> On 05/08/2010 03:16 PM, roy barnard
> wrote:
> > Heiko,
> > 
> > I have looked at that and it's still not perfect.
> > I you need to stop and start a service like squid you
> might also need to remember to stop and start the new
> services created from skeleton.
> > 
> > The default numbering of the rc3.d services makes it
> tricky to insert the new services in the best places.
> > 
> > It's better than my fudge (boot.local) but I still
> wonder if there is any better option.
> > 
> > If the run-parts idea is accepted I am happy to do the
> work building all the patches.
> > 
> 
> Roy, as far as I understand, you are resolving the issue
> globally by adding a
> new entity. It's OK if we have at least 2-3-4 services with
> such prerequisites.
>  In your case the simplest way, I guess, is direct
> modification of the init
> script - start/stop sections. You can add any commands
> there or invoke external
> scripts. It's your idea but not global and applied to only
> one service.
> 
> Sincerely,
> Serge
> 
> > Roy
> > 
> > --- On Fri, 7/5/10, Heiko Zuerker <he...@zu...>
> wrote:
> > 
> >> From: Heiko Zuerker <he...@zu...>
> >> Subject: Re: [Devil-linux-develop] Setting up
> directories in /var during boot.
> >> To: dev...@li...
> >> Date: Friday, 7 May, 2010, 19:49
> >> I think the simplest way would be to
> >> just copy the /etc/init.d/skeleton
> >> script and insert it into the runlevel wherever it
> fits
> >> best.
> >>
> >> Heiko
> >>
> >>> -----Original Message-----
> >>> From: roy barnard [mailto:roy...@ya...]
> >>> Sent: Thursday, May 06, 2010 3:52 PM
> >>> To: devil linux-develop
> >>> Subject: [Devil-linux-develop] Setting up
> directories
> >> in /var
> >>> during boot.
> >>>
> >>> Hi,
> >>>
> >>> Can anyone help me with setting up directories
> in /var
> >> during boot?
> >>>
> >>> I have configured DL-1.4RC3 as a Print Server
> using
> >> LPRNG.
> >>> To load the parallel port kernel driver I
> added
> >> "modprobe lp" to
> >>> the boot.local file, which works fine.
> >>>
> >>> I then configured the printcap file, again
> fine.
> >>> I needed to create the directory
> /var/spool/lpd/lp,
> >> which I tried
> >>> to do be putting "checkpc -f" in the
> boot.local file
> >> and let it
> >>> automatically do this for me.
> >>>
> >>> This failed because the boot.local is executed
> prior
> >> to the
> >>> hostname being set which "checkpc" needs.
> >>> (my work around to put mkdir,chown and chmods
> into
> >> boot.local)
> >>>
> >>> Will the same issues happen when running
> other
> >> programs which
> >>> expect new directories in /var ?
> >>>
> >>> Is there a rc.local file later in to boot
> sequence I
> >> have missed?
> >>>
> >>> I wonder if a better way forward would be to
> have each
> >> /etc/init.d
> >>> scripts call PRE/POST start-up scripts using
> >> run-parts.  The same
> >>> idea could be used for shutdown allowing
> cleaning up
> >> when a service
> >>> shuts down.
> >>>
> >>> An other example for this would be if you need
> to
> >> download a proxy
> >>> whitelist prior to squid starting but after
> networking
> >> is up.
> >>>
> >>> Many thanks,
> >>> Roy Barnard
>










      

Hi,

thanks to Steve and Roy for helping getting this setup started. Until
now I didn't know there is this nice little tool called nameif.

I just polished the patch a little bit and modified the code which
creates /etc/mactab from /etc/mactable.conf. I uploaded it as
network_mactable.patch to bug #73.

After patching the /etc/init.d/network script now works as follows:
# if /etc/mactable.conf doesn't exist, just proceed as normal
# if /etc/mactable.conf exists, then
## get MAC addresses of all interfaces (via ip link show)
## skip any empty lines or comment lines beginning with '#' in
/etc/mactable.conf
## check if interface definitions are found in /etc/mactable.conf
### if so, then write interface definitions into /etc/mactab.tmp
### if not, then issue a warning about the not defined interface(s)
## if all interfaces are found, rename /etc/mactab.tmp into /etc/mactab
## if an interface definition is missing, then remove /etc/mactab.tmp
and don't touch an already existing /etc/mactab

After that, the patch works as suggested: if /etc/mactab exists, then
use it. If not, skip this stuff and proceed as normal.

With my setup here everything works as expected (after defining the MAC
addresses of course). So in case of trouble, I don't have to think about
the correct MAC setup to get things running again, but I can now switch
the usb-stick with the firewall config from one machine to another and
that's it.

Regards,
Stefan

roy barnard wrote:
> Stefan,
> 
> I helped Steve Ralph write the patch.
> Your understanding of regexp is way better than mine.
> I like this as it removes the need for the "cut" command which should speed the code up.
> 
> I had to read it twice to get it but today I learnt a little more regexp.
> 
> Thank you.
> 
> Roy Barnard
> 
> 
> --- On Wed, 5/5/10, Stefan Engel <ma...@en...> wrote:
> 
>> From: Stefan Engel <ma...@en...>
>> Subject: Re: [Devil-linux-develop] Enable "nameif" to associate MAC address with correct interface name
>> To: dev...@li...
>> Date: Wednesday, 5 May, 2010, 23:18
>> I did some testing with the patch and
>> it looks good so far. Only thing I
>> would change is the regexp. From:
>>
>> MacList=`/sbin/ip addr show | /bin/grep  "link/ether"
>> | /bin/sed
>> "s#.*link\/ether \| brd #\|#ig" | /usr/bin/cut -f2 -d'|'`
>>
>> to:
>> MacList=`/sbin/ip link show | /bin/grep  "ether" |
>> /bin/sed "s#.*ether
>> \([0-9a-f:]*\) .*#\1#ig"`
>>
>> Regards,
>> Stefan
>>
>> Stefan Engel wrote:
>>> Hi,
>>>
>>> his patch looks just like what I have been looking
>> for. I will add it to
>>> my VM test environment for testing. As far as I can
>> see, nothing of the
>>> current network handling gets broken if /etc/mactab
>> and
>>> /etc/mactable.conf are missing, so I would vote to add
>> this patch to DL.
>>> Regards,
>>> Stefan
>>>
>>> Steve Ralph wrote:
>>>> Hi,
>>>>  
>>>> I have just submitted a mantis-patch for
>> "/etc/init.d/network" that
>>>> calls nameif to name network interfaces based on
>> MAC addresses. The call
>>>> is only made if the required "/etc/mactab" file
>> exists and is readable.
>>>> Nameif is called on a per-interface basis after
>> the module has been
>>>> modprob'ed into place.
>>>>  
>>>> Please note that the version of
>> "/etc/init.d/network" that was used as a
>>>> starting point was "# $Revision: 1.44 $" which is
>> has been patched for
>>>> interface aliases and has a higher revision number
>> than version 1.43
>>>> that ships with DL-1.4-RC3.
>>>>  
>>>> There are two distinct but linked patches
>> contained in the one file.
>>>> They could be separated quite easily, if
>> required.
>>>>  
>>>> The first patch that calls nameif/mactab is:
>>>> @@ -162,8 +163,18 @@
>>>>             
>>         if [ "$MODULE" != "UNKNOWN" ]
>> && [ "$MODULE" !=
>>>> "autoselect" ] ; then
>>>>             
>>                
>>     modprobe $MODULE $MODULE_OPTS > /dev/null
>>>>             
>>         fi
>>>>             
>>     fi
>>>> +           
>>    # Using /etc/mactab (may have been created
>> from
>>>> /etc/mactable.conf
>>>> +           
>>    #       Process
>> IF for active Media Access Control
>>>> (Ethernet MAC) Address.
>>>> +           
>>    # Only process interfaces which DON'T have
>> a :-_.
>>>> (Colon/dash/underscore/dot) in them.
>>>> +           
>>    #
>>>> +           
>>    if [ -r /etc/mactab ]; then
>>>> +             
>>          if [ `expr index
>> "$IF" ":-_."` == 0 ];   then
>>>> +             
>>              
>>    UseIFMac=`/bin/grep --ignore-case "^$IF"
>>>> /etc/mactab`
>>>> +             
>>              
>>    /sbin/nameif -s $UseIFMac
>>>> +             
>>          fi
>>>> +           
>>    fi
>>>>  
>>>>  
>>>>             
>>     if [ "$WIRELESS" = "yes" ]; then
>>>>             
>>             setup_wireless
>> $DEVICE
>>>>  
>>>> The format for the optional configuration file
>> "/etc/mactab" may be
>>>> taken from my proposed "/etc/mactab.sample":
>>>>  
>>>>         #---
>> /etc/mactab.sample
>>>>         #
>>>>         # 
>>      Example format for /etc/mactab.
>>>>         # 
>>      Used by nameif to name network
>> interfaces based on MAC
>>>> addresses
>>>>         #
>>>>         eth0 
>>   00:40:f4:b8:db:2f
>>>>         eth1 
>>   00:40:f4:b8:db:2e
>>>>         eth2 
>>   00:40:f4:b8:db:2d
>>>>         #
>>>>         #--- End
>>>>  
>>>> I believe this implements standard functionality
>> to control network
>>>> interfaces names based on MAC addresses.
>>>>  
>>>> If implemented, this would prevent udev shuffling
>> interface names across
>>>> a system reboot.
>>>>  
>>>> The second part of the patch introduces new
>> functionality with the
>>>> specific aim to allow a single DL-etc-mods.tar.bz2
>> config to be moved
>>>> onto a cold-standby unit, and automatically
>> receive the correct
>>>> (preconfigured) interface assignments.
>>>>  
>>>> The patch is a follows:
>>>>  
>>>> @@ -376,8 +387,16 @@
>>>>             
>>     # if vlan tools are installed set vlan naming
>> shema
>>>>             
>>     #
>>>>             
>>     test -x $VLAN && $VLAN set_name_type
>>>> VLAN_PLUS_VID_NO_PAD &> /dev/null
>>>>  
>>>> +           
>>    # if /etc/mactable.conf is readable then
>>>> +           
>>    #       extract
>> lines for each available MAC Address we
>>>> have
>>>> +           
>>    #       and
>> create/overwrite /etc/mactab
>>>> +           
>>    if [ -r /etc/mactable.conf ]; then
>>>> +             
>>          MacList=`/sbin/ip
>> addr show | /bin/grep
>>>> "link/ether" | /bin/sed "s#.*link\/ether \| brd
>> #\|#ig" | /usr/bin/cut
>>>> -f2 -d'|'`
>>>> +             
>>          /bin/grep -F
>> "$MacList" /etc/mactable.conf |
>>>> /usr/bin/cut -f-2 -d'|' | /bin/sed "s#|# #"
>>> /etc/mactab
>>>> +           
>>    fi
>>>> +
>>>>             
>>     #
>>>>             
>>     # physical interfaces are brought up first
>>>>             
>>     #
>>>>             
>>     for interface in $(cd ${CONFIG_DIR}; ls -1
>>>> ${CONFIG_FILE}* 2>/dev/null | sed \
>>>>  
>>>> The key here is the use of a new
>> "/etc/mactable.conf " config file which
>>>> is preconfigured with interface and MAC details
>> for both the production
>>>> and the standby hardware.
>>>>  
>>>> Again, the format for the optional configuration
>> file
>>>> "/etc/mactable.conf" may be taken from my
>> proposed
>>>> "/etc/mactable.conf.sample":
>>>>  
>>>>         #---
>> /etc/mactable.conf.sample
>>>>         #
>>>>         # Interface
>> name | MAC Address | Comment
>>>>         #
>>>>     
>>    eth0|00:40:f4:b8:db:2f| Gannet01
>> (Production fw) lan1
>>>>     
>>    eth1|00:40:f4:b8:db:2e| Gannet01
>> (Production fw) lan2
>>>>     
>>    eth2|00:40:f4:b8:db:2d| Gannet01
>> (Production fw) lan3
>>>>         #
>>>>     
>>    eth0|00:30:18:49:5f:08| Gannet02 (Cold
>> Standby fw) lan1
>>>>     
>>    eth1|00:30:18:49:5f:07| Gannet02 (Cold
>> Standby fw) lan2
>>>>     
>>    eth2|00:30:18:49:5f:06| Gannet02 (Cold
>> Standby fw) lan3
>>>>         #
>>>>     
>>    eth0|00:11:85:10:be:f9| Hippopotamus
>> (Development/testbed) eth0
>>>>     
>>    eth1|00:10:5a:28:51:36| Hippopotamus
>> (Development/testbed) eth1
>>>>     
>>    eth2|00:50:04:3a:aa:5b| Hippopotamus
>> (Development/testbed) eth2
>>>>         #
>>>>         #--- End
>>>>  
>>>> Here three systems have their interface and mac
>> details catalogued. When
>>>> the patched "/etc/init.d/network" file is run, it
>> extracts mac-addresses
>>>> from "/etc/mactable.conf " that match the
>> physically identified
>>>> interfaces, and repopulates "/etc/mactab" ready
>> for nameif to use, but
>>>> containing only details appropriate for (in the
>> sample) "Gannet01",
>>>> "Gannet02", or "Hippopotamus".
>>>>  
>>>> If the first "/etc/mactab" patch is rejected, then
>> the second
>>>> "/etc/mactable.conf" automatically falls, as it
>> depends on nameif being
>>>> run against the newly created " /etc/mactab"
>> file.
>>>>  
>>>> This will, I believe, give Stefan [ma...@en...]
>> the ability to
>>>> have a replacement firewall on cold-standby.
>>>>  
>>>> Much of the above code must be credited to my
>> colleague Roy Barnard.
>>>>  
>>>> Regards - Steve.
>>>>  
>>>> Stephen H F Ralph
>>>> Principal Computer Officer | Integration Team |
>> ICT Services | Transform
>>>> Sandwell
>>>> Sandwell MBC | Freeth Street | Oldbury | West
>> Midlands | B69 3DE
>>>> Tel: 0121 569 3132 | Fax: 0121 569 3493
>>>> Email: ste...@sa...
>> <mailto:ste...@sa...>

On 05/08/2010 03:16 PM, roy barnard wrote:
> Heiko,
> 
> I have looked at that and it's still not perfect.
> I you need to stop and start a service like squid you might also need to remember to stop and start the new services created from skeleton.
> 
> The default numbering of the rc3.d services makes it tricky to insert the new services in the best places.
> 
> It's better than my fudge (boot.local) but I still wonder if there is any better option.
> 
> If the run-parts idea is accepted I am happy to do the work building all the patches.
> 

Roy, as far as I understand, you are resolving the issue globally by adding a
new entity. It's OK if we have at least 2-3-4 services with such prerequisites.
 In your case the simplest way, I guess, is direct modification of the init
script - start/stop sections. You can add any commands there or invoke external
scripts. It's your idea but not global and applied to only one service.

Sincerely,
Serge

> Roy
> 
> --- On Fri, 7/5/10, Heiko Zuerker <he...@zu...> wrote:
> 
>> From: Heiko Zuerker <he...@zu...>
>> Subject: Re: [Devil-linux-develop] Setting up directories in /var during boot.
>> To: dev...@li...
>> Date: Friday, 7 May, 2010, 19:49
>> I think the simplest way would be to
>> just copy the /etc/init.d/skeleton
>> script and insert it into the runlevel wherever it fits
>> best.
>>
>> Heiko
>>
>>> -----Original Message-----
>>> From: roy barnard [mailto:roy...@ya...]
>>> Sent: Thursday, May 06, 2010 3:52 PM
>>> To: devil linux-develop
>>> Subject: [Devil-linux-develop] Setting up directories
>> in /var
>>> during boot.
>>>
>>> Hi,
>>>
>>> Can anyone help me with setting up directories in /var
>> during boot?
>>>
>>> I have configured DL-1.4RC3 as a Print Server using
>> LPRNG.
>>> To load the parallel port kernel driver I added
>> "modprobe lp" to
>>> the boot.local file, which works fine.
>>>
>>> I then configured the printcap file, again fine.
>>> I needed to create the directory /var/spool/lpd/lp,
>> which I tried
>>> to do be putting "checkpc -f" in the boot.local file
>> and let it
>>> automatically do this for me.
>>>
>>> This failed because the boot.local is executed prior
>> to the
>>> hostname being set which "checkpc" needs.
>>> (my work around to put mkdir,chown and chmods into
>> boot.local)
>>>
>>> Will the same issues happen when running other
>> programs which
>>> expect new directories in /var ?
>>>
>>> Is there a rc.local file later in to boot sequence I
>> have missed?
>>>
>>> I wonder if a better way forward would be to have each
>> /etc/init.d
>>> scripts call PRE/POST start-up scripts using
>> run-parts.  The same
>>> idea could be used for shutdown allowing cleaning up
>> when a service
>>> shuts down.
>>>
>>> An other example for this would be if you need to
>> download a proxy
>>> whitelist prior to squid starting but after networking
>> is up.
>>>
>>> Many thanks,
>>> Roy Barnard

Does anybody else have an opinion on this?
I'm hungover and it's a bit challenging today to make decisions... ;-)

Heiko

Quoting roy barnard <roy...@ya...>:

> Heiko,
>
> I have looked at that and it's still not perfect.
> I you need to stop and start a service like squid you might also  
> need to remember to stop and start the new services created from  
> skeleton.
>
> The default numbering of the rc3.d services makes it tricky to  
> insert the new services in the best places.
>
> It's better than my fudge (boot.local) but I still wonder if there  
> is any better option.
>
> If the run-parts idea is accepted I am happy to do the work building  
> all the patches.
>
> Roy
>
> --- On Fri, 7/5/10, Heiko Zuerker <he...@zu...> wrote:
>
>> From: Heiko Zuerker <he...@zu...>
>> Subject: Re: [Devil-linux-develop] Setting up directories in /var  
>> during boot.
>> To: dev...@li...
>> Date: Friday, 7 May, 2010, 19:49
>> I think the simplest way would be to
>> just copy the /etc/init.d/skeleton
>> script and insert it into the runlevel wherever it fits
>> best.
>>
>> Heiko
>>
>> > -----Original Message-----
>> > From: roy barnard [mailto:roy...@ya...]
>> > Sent: Thursday, May 06, 2010 3:52 PM
>> > To: devil linux-develop
>> > Subject: [Devil-linux-develop] Setting up directories
>> in /var
>> > during boot.
>> >
>> > Hi,
>> >
>> > Can anyone help me with setting up directories in /var
>> during boot?
>> >
>> > I have configured DL-1.4RC3 as a Print Server using
>> LPRNG.
>> > To load the parallel port kernel driver I added
>> "modprobe lp" to
>> > the boot.local file, which works fine.
>> >
>> > I then configured the printcap file, again fine.
>> > I needed to create the directory /var/spool/lpd/lp,
>> which I tried
>> > to do be putting "checkpc -f" in the boot.local file
>> and let it
>> > automatically do this for me.
>> >
>> > This failed because the boot.local is executed prior
>> to the
>> > hostname being set which "checkpc" needs.
>> > (my work around to put mkdir,chown and chmods into
>> boot.local)
>> >
>> > Will the same issues happen when running other
>> programs which
>> > expect new directories in /var ?
>> >
>> > Is there a rc.local file later in to boot sequence I
>> have missed?
>> >
>> > I wonder if a better way forward would be to have each
>> /etc/init.d
>> > scripts call PRE/POST start-up scripts using
>> run-parts.  The same
>> > idea could be used for shutdown allowing cleaning up
>> when a service
>> > shuts down.
>> >
>> > An other example for this would be if you need to
>> download a proxy
>> > whitelist prior to squid starting but after networking
>> is up.
>> >
>> > Many thanks,
>> > Roy Barnard
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> -------------------------------------------------------------------
>> > -----------
>> >
>> > _______________________________________________
>> > Devil-linux-develop mailing list
>> > Dev...@li...
>> > https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Devil-linux-develop mailing list
>> Dev...@li...
>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>
>
>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>



-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Heiko,

I have looked at that and it's still not perfect.
I you need to stop and start a service like squid you might also need to remember to stop and start the new services created from skeleton.

The default numbering of the rc3.d services makes it tricky to insert the new services in the best places.

It's better than my fudge (boot.local) but I still wonder if there is any better option.

If the run-parts idea is accepted I am happy to do the work building all the patches.

Roy

--- On Fri, 7/5/10, Heiko Zuerker <he...@zu...> wrote:

> From: Heiko Zuerker <he...@zu...>
> Subject: Re: [Devil-linux-develop] Setting up directories in /var during boot.
> To: dev...@li...
> Date: Friday, 7 May, 2010, 19:49
> I think the simplest way would be to
> just copy the /etc/init.d/skeleton
> script and insert it into the runlevel wherever it fits
> best.
> 
> Heiko
> 
> > -----Original Message-----
> > From: roy barnard [mailto:roy...@ya...]
> > Sent: Thursday, May 06, 2010 3:52 PM
> > To: devil linux-develop
> > Subject: [Devil-linux-develop] Setting up directories
> in /var
> > during boot.
> > 
> > Hi,
> > 
> > Can anyone help me with setting up directories in /var
> during boot?
> > 
> > I have configured DL-1.4RC3 as a Print Server using
> LPRNG.
> > To load the parallel port kernel driver I added
> "modprobe lp" to
> > the boot.local file, which works fine.
> > 
> > I then configured the printcap file, again fine.
> > I needed to create the directory /var/spool/lpd/lp,
> which I tried
> > to do be putting "checkpc -f" in the boot.local file
> and let it
> > automatically do this for me.
> > 
> > This failed because the boot.local is executed prior
> to the
> > hostname being set which "checkpc" needs.
> > (my work around to put mkdir,chown and chmods into
> boot.local)
> > 
> > Will the same issues happen when running other
> programs which
> > expect new directories in /var ?
> > 
> > Is there a rc.local file later in to boot sequence I
> have missed?
> > 
> > I wonder if a better way forward would be to have each
> /etc/init.d
> > scripts call PRE/POST start-up scripts using
> run-parts.  The same
> > idea could be used for shutdown allowing cleaning up
> when a service
> > shuts down.
> > 
> > An other example for this would be if you need to
> download a proxy
> > whitelist prior to squid starting but after networking
> is up.
> > 
> > Many thanks,
> > Roy Barnard
> > 
> > 
> > 
> > 
> > 
> > 
> >
> -------------------------------------------------------------------
> > -----------
> > 
> > _______________________________________________
> > Devil-linux-develop mailing list
> > Dev...@li...
> > https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
> 
> 
> ------------------------------------------------------------------------------
> 
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
> 


      

I think the simplest way would be to just copy the /etc/init.d/skeleton
script and insert it into the runlevel wherever it fits best.

Heiko

> -----Original Message-----
> From: roy barnard [mailto:roy...@ya...]
> Sent: Thursday, May 06, 2010 3:52 PM
> To: devil linux-develop
> Subject: [Devil-linux-develop] Setting up directories in /var
> during boot.
> 
> Hi,
> 
> Can anyone help me with setting up directories in /var during boot?
> 
> I have configured DL-1.4RC3 as a Print Server using LPRNG.
> To load the parallel port kernel driver I added "modprobe lp" to
> the boot.local file, which works fine.
> 
> I then configured the printcap file, again fine.
> I needed to create the directory /var/spool/lpd/lp, which I tried
> to do be putting "checkpc -f" in the boot.local file and let it
> automatically do this for me.
> 
> This failed because the boot.local is executed prior to the
> hostname being set which "checkpc" needs.
> (my work around to put mkdir,chown and chmods into boot.local)
> 
> Will the same issues happen when running other programs which
> expect new directories in /var ?
> 
> Is there a rc.local file later in to boot sequence I have missed?
> 
> I wonder if a better way forward would be to have each /etc/init.d
> scripts call PRE/POST start-up scripts using run-parts.  The same
> idea could be used for shutdown allowing cleaning up when a service
> shuts down.
> 
> An other example for this would be if you need to download a proxy
> whitelist prior to squid starting but after networking is up.
> 
> Many thanks,
> Roy Barnard
> 
> 
> 
> 
> 
> 
> -------------------------------------------------------------------
> -----------
> 
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop

Hi,

his patch looks just like what I have been looking for. I will add it to
my VM test environment for testing. As far as I can see, nothing of the
current network handling gets broken if /etc/mactab and
/etc/mactable.conf are missing, so I would vote to add this patch to DL.

Regards,
Stefan

Steve Ralph wrote:
> 
> Hi,
>  
> I have just submitted a mantis-patch for "/etc/init.d/network" that
> calls nameif to name network interfaces based on MAC addresses. The call
> is only made if the required "/etc/mactab" file exists and is readable.
> Nameif is called on a per-interface basis after the module has been
> modprob'ed into place.
>  
> Please note that the version of "/etc/init.d/network" that was used as a
> starting point was "# $Revision: 1.44 $" which is has been patched for
> interface aliases and has a higher revision number than version 1.43
> that ships with DL-1.4-RC3.
>  
> There are two distinct but linked patches contained in the one file.
> They could be separated quite easily, if required.
>  
> The first patch that calls nameif/mactab is:
> @@ -162,8 +163,18 @@
>                      if [ "$MODULE" != "UNKNOWN" ] && [ "$MODULE" !=
> "autoselect" ] ; then
>                                  modprobe $MODULE $MODULE_OPTS > /dev/null
>                      fi
>                  fi
> +               # Using /etc/mactab (may have been created from
> /etc/mactable.conf
> +               #       Process IF for active Media Access Control
> (Ethernet MAC) Address.
> +               # Only process interfaces which DON'T have a :-_.
> (Colon/dash/underscore/dot) in them.
> +               #
> +               if [ -r /etc/mactab ]; then
> +                       if [ `expr index "$IF" ":-_."` == 0 ];   then
> +                               UseIFMac=`/bin/grep --ignore-case "^$IF"
> /etc/mactab`
> +                               /sbin/nameif -s $UseIFMac
> +                       fi
> +               fi
>  
>  
>                  if [ "$WIRELESS" = "yes" ]; then
>                          setup_wireless $DEVICE
>  
> The format for the optional configuration file "/etc/mactab" may be
> taken from my proposed "/etc/mactab.sample":
>  
>         #--- /etc/mactab.sample
>         #
>         #       Example format for /etc/mactab.
>         #       Used by nameif to name network interfaces based on MAC
> addresses
>         #
>         eth0    00:40:f4:b8:db:2f
>         eth1    00:40:f4:b8:db:2e
>         eth2    00:40:f4:b8:db:2d
>         #
>         #--- End
>  
> I believe this implements standard functionality to control network
> interfaces names based on MAC addresses.
>  
> If implemented, this would prevent udev shuffling interface names across
> a system reboot.
>  
> The second part of the patch introduces new functionality with the
> specific aim to allow a single DL-etc-mods.tar.bz2 config to be moved
> onto a cold-standby unit, and automatically receive the correct
> (preconfigured) interface assignments.
>  
> The patch is a follows:
>  
> @@ -376,8 +387,16 @@
>                  # if vlan tools are installed set vlan naming shema
>                  #
>                  test -x $VLAN && $VLAN set_name_type
> VLAN_PLUS_VID_NO_PAD &> /dev/null
>  
> +               # if /etc/mactable.conf is readable then
> +               #       extract lines for each available MAC Address we
> have
> +               #       and create/overwrite /etc/mactab
> +               if [ -r /etc/mactable.conf ]; then
> +                       MacList=`/sbin/ip addr show | /bin/grep
> "link/ether" | /bin/sed "s#.*link\/ether \| brd #\|#ig" | /usr/bin/cut
> -f2 -d'|'`
> +                       /bin/grep -F "$MacList" /etc/mactable.conf |
> /usr/bin/cut -f-2 -d'|' | /bin/sed "s#|# #" >/etc/mactab
> +               fi
> +
>                  #
>                  # physical interfaces are brought up first
>                  #
>                  for interface in $(cd ${CONFIG_DIR}; ls -1
> ${CONFIG_FILE}* 2>/dev/null | sed \
>  
> The key here is the use of a new "/etc/mactable.conf " config file which
> is preconfigured with interface and MAC details for both the production
> and the standby hardware.
>  
> Again, the format for the optional configuration file
> "/etc/mactable.conf" may be taken from my proposed
> "/etc/mactable.conf.sample":
>  
>         #--- /etc/mactable.conf.sample
>         #
>         # Interface name | MAC Address | Comment
>         #
>         eth0|00:40:f4:b8:db:2f| Gannet01 (Production fw) lan1
>         eth1|00:40:f4:b8:db:2e| Gannet01 (Production fw) lan2
>         eth2|00:40:f4:b8:db:2d| Gannet01 (Production fw) lan3
>         #
>         eth0|00:30:18:49:5f:08| Gannet02 (Cold Standby fw) lan1
>         eth1|00:30:18:49:5f:07| Gannet02 (Cold Standby fw) lan2
>         eth2|00:30:18:49:5f:06| Gannet02 (Cold Standby fw) lan3
>         #
>         eth0|00:11:85:10:be:f9| Hippopotamus (Development/testbed) eth0
>         eth1|00:10:5a:28:51:36| Hippopotamus (Development/testbed) eth1
>         eth2|00:50:04:3a:aa:5b| Hippopotamus (Development/testbed) eth2
>         #
>         #--- End
>  
> Here three systems have their interface and mac details catalogued. When
> the patched "/etc/init.d/network" file is run, it extracts mac-addresses
> from "/etc/mactable.conf " that match the physically identified
> interfaces, and repopulates "/etc/mactab" ready for nameif to use, but
> containing only details appropriate for (in the sample) "Gannet01",
> "Gannet02", or "Hippopotamus".
>  
> If the first "/etc/mactab" patch is rejected, then the second
> "/etc/mactable.conf" automatically falls, as it depends on nameif being
> run against the newly created " /etc/mactab" file.
>  
> This will, I believe, give Stefan [ma...@en...] the ability to
> have a replacement firewall on cold-standby.
>  
> Much of the above code must be credited to my colleague Roy Barnard.
>  
> Regards - Steve.
>  
> Stephen H F Ralph
> Principal Computer Officer | Integration Team | ICT Services | Transform
> Sandwell
> Sandwell MBC | Freeth Street | Oldbury | West Midlands | B69 3DE
> Tel: 0121 569 3132 | Fax: 0121 569 3493
> Email: ste...@sa... <mailto:ste...@sa...>
>  
>  
>  
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop

Any opinions on this?

 

Heiko

 

From: Steve Ralph [mailto:Ste...@sa...] 
Sent: Tuesday, May 04, 2010 1:04 PM
To: dev...@li...
Subject: Re: [Devil-linux-develop] Enable "nameif" to associate MAC
address with correct interface name

 

Hi,

 

I have just submitted a mantis-patch for "/etc/init.d/network" that
calls nameif to name network interfaces based on MAC addresses. The call
is only made if the required "/etc/mactab" file exists and is readable.
Nameif is called on a per-interface basis after the module has been
modprob'ed into place.

 

Please note that the version of "/etc/init.d/network" that was used as a
starting point was "# $Revision: 1.44 $" which is has been patched for
interface aliases and has a higher revision number than version 1.43
that ships with DL-1.4-RC3.

 

There are two distinct but linked patches contained in the one file.
They could be separated quite easily, if required. 

 

The first patch that calls nameif/mactab is:

@@ -162,8 +163,18 @@

                     if [ "$MODULE" != "UNKNOWN" ] && [ "$MODULE" !=
"autoselect" ] ; then

                                 modprobe $MODULE $MODULE_OPTS >
/dev/null

                     fi

                 fi

+               # Using /etc/mactab (may have been created from
/etc/mactable.conf

+               #       Process IF for active Media Access Control
(Ethernet MAC) Address.

+               # Only process interfaces which DON'T have a :-_.
(Colon/dash/underscore/dot) in them.

+               #

+               if [ -r /etc/mactab ]; then

+                       if [ `expr index "$IF" ":-_."` == 0 ];   then

+                               UseIFMac=`/bin/grep --ignore-case "^$IF"
/etc/mactab`

+                               /sbin/nameif -s $UseIFMac

+                       fi

+               fi

 

 

                 if [ "$WIRELESS" = "yes" ]; then

                         setup_wireless $DEVICE

 

The format for the optional configuration file "/etc/mactab" may be
taken from my proposed "/etc/mactab.sample":

 

        #--- /etc/mactab.sample

        #

        #       Example format for /etc/mactab. 

        #       Used by nameif to name network interfaces based on MAC
addresses

        #

        eth0    00:40:f4:b8:db:2f

        eth1    00:40:f4:b8:db:2e

        eth2    00:40:f4:b8:db:2d

        #

        #--- End

 

I believe this implements standard functionality to control network
interfaces names based on MAC addresses. 

 

If implemented, this would prevent udev shuffling interface names across
a system reboot.

 

The second part of the patch introduces new functionality with the
specific aim to allow a single DL-etc-mods.tar.bz2 config to be moved
onto a cold-standby unit, and automatically receive the correct
(preconfigured) interface assignments.

 

The patch is a follows:

 

@@ -376,8 +387,16 @@

                 # if vlan tools are installed set vlan naming shema

                 #

                 test -x $VLAN && $VLAN set_name_type
VLAN_PLUS_VID_NO_PAD &> /dev/null

 

+               # if /etc/mactable.conf is readable then

+               #       extract lines for each available MAC Address we
have

+               #       and create/overwrite /etc/mactab

+               if [ -r /etc/mactable.conf ]; then

+                       MacList=`/sbin/ip addr show | /bin/grep
"link/ether" | /bin/sed "s#.*link\/ether \| brd #\|#ig" | /usr/bin/cut
-f2 -d'|'`

+                       /bin/grep -F "$MacList" /etc/mactable.conf |
/usr/bin/cut -f-2 -d'|' | /bin/sed "s#|# #" >/etc/mactab

+               fi

+

                 #

                 # physical interfaces are brought up first

                 #

                 for interface in $(cd ${CONFIG_DIR}; ls -1
${CONFIG_FILE}* 2>/dev/null | sed \

 

The key here is the use of a new "/etc/mactable.conf " config file which
is preconfigured with interface and MAC details for both the production
and the standby hardware.

 

Again, the format for the optional configuration file
"/etc/mactable.conf" may be taken from my proposed
"/etc/mactable.conf.sample":

 

        #--- /etc/mactable.conf.sample

        #

        # Interface name | MAC Address | Comment

        #

        eth0|00:40:f4:b8:db:2f| Gannet01 (Production fw) lan1

        eth1|00:40:f4:b8:db:2e| Gannet01 (Production fw) lan2

        eth2|00:40:f4:b8:db:2d| Gannet01 (Production fw) lan3

        #

        eth0|00:30:18:49:5f:08| Gannet02 (Cold Standby fw) lan1

        eth1|00:30:18:49:5f:07| Gannet02 (Cold Standby fw) lan2

        eth2|00:30:18:49:5f:06| Gannet02 (Cold Standby fw) lan3

        #

        eth0|00:11:85:10:be:f9| Hippopotamus (Development/testbed) eth0

        eth1|00:10:5a:28:51:36| Hippopotamus (Development/testbed) eth1

        eth2|00:50:04:3a:aa:5b| Hippopotamus (Development/testbed) eth2

        #

        #--- End

 

Here three systems have their interface and mac details catalogued. When
the patched "/etc/init.d/network" file is run, it extracts mac-addresses
from "/etc/mactable.conf " that match the physically identified
interfaces, and repopulates "/etc/mactab" ready for nameif to use, but
containing only details appropriate for (in the sample) "Gannet01",
"Gannet02", or "Hippopotamus".

 

If the first "/etc/mactab" patch is rejected, then the second
"/etc/mactable.conf" automatically falls, as it depends on nameif being
run against the newly created " /etc/mactab" file.

 

This will, I believe, give Stefan [ma...@en...] the ability to
have a replacement firewall on cold-standby.

 

Much of the above code must be credited to my colleague Roy Barnard.

 

Regards - Steve.

 

Stephen H F Ralph

Principal Computer Officer | Integration Team | ICT Services | Transform
Sandwell 

Sandwell MBC | Freeth Street | Oldbury | West Midlands | B69 3DE

Tel: 0121 569 3132 | Fax: 0121 569 3493

Email: ste...@sa...

 

 

 

Hi,

I have just submitted a mantis-patch for "/etc/init.d/network" that calls nameif to name network interfaces based on MAC addresses. The call is only made if the required "/etc/mactab" file exists and is readable. Nameif is called on a per-interface basis after the module has been modprob'ed into place.

Please note that the version of "/etc/init.d/network" that was used as a starting point was "# $Revision: 1.44 $" which is has been patched for interface aliases and has a higher revision number than version 1.43 that ships with DL-1.4-RC3.

There are two distinct but linked patches contained in the one file. They could be separated quite easily, if required.

The first patch that calls nameif/mactab is:
@@ -162,8 +163,18 @@
                    if [ "$MODULE" != "UNKNOWN" ] && [ "$MODULE" != "autoselect" ] ; then
                                modprobe $MODULE $MODULE_OPTS > /dev/null
                    fi
                fi
+               # Using /etc/mactab (may have been created from /etc/mactable.conf
+               #       Process IF for active Media Access Control (Ethernet MAC) Address.
+               # Only process interfaces which DON'T have a :-_. (Colon/dash/underscore/dot) in them.
+               #
+               if [ -r /etc/mactab ]; then
+                       if [ `expr index "$IF" ":-_."` == 0 ];  then
+                               UseIFMac=`/bin/grep --ignore-case "^$IF" /etc/mactab`
+                               /sbin/nameif -s $UseIFMac
+                       fi
+               fi


                if [ "$WIRELESS" = "yes" ]; then
                        setup_wireless $DEVICE

The format for the optional configuration file "/etc/mactab" may be taken from my proposed "/etc/mactab.sample":

        #--- /etc/mactab.sample
        #
        #       Example format for /etc/mactab.
        #       Used by nameif to name network interfaces based on MAC addresses
        #
        eth0    00:40:f4:b8:db:2f
        eth1    00:40:f4:b8:db:2e
        eth2    00:40:f4:b8:db:2d
        #
        #--- End

I believe this implements standard functionality to control network interfaces names based on MAC addresses.

If implemented, this would prevent udev shuffling interface names across a system reboot.

The second part of the patch introduces new functionality with the specific aim to allow a single DL-etc-mods.tar.bz2 config to be moved onto a cold-standby unit, and automatically receive the correct (preconfigured) interface assignments.

The patch is a follows:

@@ -376,8 +387,16 @@
                # if vlan tools are installed set vlan naming shema
                #
                test -x $VLAN && $VLAN set_name_type VLAN_PLUS_VID_NO_PAD &> /dev/null

+               # if /etc/mactable.conf is readable then
+               #       extract lines for each available MAC Address we have
+               #       and create/overwrite /etc/mactab
+               if [ -r /etc/mactable.conf ]; then
+                       MacList=`/sbin/ip addr show | /bin/grep "link/ether" | /bin/sed "s#.*link\/ether \| brd #\|#ig" | /usr/bin/cut -f2 -d'|'`
+                       /bin/grep -F "$MacList" /etc/mactable.conf | /usr/bin/cut -f-2 -d'|' | /bin/sed "s#|# #" >/etc/mactab
+               fi
+
                #
                # physical interfaces are brought up first
                #
                for interface in $(cd ${CONFIG_DIR}; ls -1 ${CONFIG_FILE}* 2>/dev/null | sed \

The key here is the use of a new "/etc/mactable.conf " config file which is preconfigured with interface and MAC details for both the production and the standby hardware.

Again, the format for the optional configuration file "/etc/mactable.conf" may be taken from my proposed "/etc/mactable.conf.sample":

        #--- /etc/mactable.conf.sample
        #
        # Interface name | MAC Address | Comment
        #
        eth0|00:40:f4:b8:db:2f| Gannet01 (Production fw) lan1
        eth1|00:40:f4:b8:db:2e| Gannet01 (Production fw) lan2
        eth2|00:40:f4:b8:db:2d| Gannet01 (Production fw) lan3
        #
        eth0|00:30:18:49:5f:08| Gannet02 (Cold Standby fw) lan1
        eth1|00:30:18:49:5f:07| Gannet02 (Cold Standby fw) lan2
        eth2|00:30:18:49:5f:06| Gannet02 (Cold Standby fw) lan3
        #
        eth0|00:11:85:10:be:f9| Hippopotamus (Development/testbed) eth0
        eth1|00:10:5a:28:51:36| Hippopotamus (Development/testbed) eth1
        eth2|00:50:04:3a:aa:5b| Hippopotamus (Development/testbed) eth2
        #
        #--- End

Here three systems have their interface and mac details catalogued. When the patched "/etc/init.d/network" file is run, it extracts mac-addresses from "/etc/mactable.conf " that match the physically identified interfaces, and repopulates "/etc/mactab" ready for nameif to use, but containing only details appropriate for (in the sample) "Gannet01", "Gannet02", or "Hippopotamus".

If the first "/etc/mactab" patch is rejected, then the second "/etc/mactable.conf" automatically falls, as it depends on nameif being run against the newly created " /etc/mactab" file.

This will, I believe, give Stefan [ma...@en...] the ability to have a replacement firewall on cold-standby.

Much of the above code must be credited to my colleague Roy Barnard.

Regards - Steve.

Stephen H F Ralph
Principal Computer Officer | Integration Team | ICT Services | Transform Sandwell
Sandwell MBC | Freeth Street | Oldbury | West Midlands | B69 3DE
Tel: 0121 569 3132 | Fax: 0121 569 3493
Email: ste...@sa...<mailto:ste...@sa...>

I did that, after making some improvements. Now it provides more 
warnings and info about the devices it is removing / recreating, backs 
up the old rules file, and optionally resets ifcfg-eth[n] file(s) (for 
discovered eth[n] devices) to module="autoselect". It has 2 modes of 
operation, one of which deletes the rules file (allowing complete 
redetection of hardware and perhaps successful restart of the network) 
and the other doesn't, which should allow restart of the network after 
manual configuration of the rules file. And there is help information.

I've done some testing of it but without moving network hardware around 
/ changing network hardware. When I've done that I will post it as an 
additional comment to the feature request in Mantis.

Dominic

On 26/04/2010 19:48, Heiko Zuerker wrote:
> I think a warning should also be displayed, that the order of the
> interfaces may have changed and the admin needs to verify.
>
> Can you send the patch as an attachment please?
> Or even better, create a feature request in mantis and attach it
> there. That way we won't loose track of it.
>
> Heiko

Hi,

>>> On 25/04/2010 13:40, Heiko Zuerker wrote:
>>> I took a quick look at our network init script.
>>> I'm not sure about a good place to put the nameif line, since we may required the module to be loaded first.

We (Roy and I) are currently half-way through patching init.d/network script to call nameif on a per-interface basis; once we have it sorted I'll post both here and log a patch on mantis. Then we'll have two methods of sorting this issue, nameif and udev, and can discuss which is the best to use.

Regards - Steve.

Stephen H F Ralph
Principal Computer Officer | Integration Team | ICT Services | Transform Sandwell
Sandwell MBC | Freeth Street | Oldbury | West Midlands | B69 3DE
Email: ste...@sa...

-----Original Message-----
From: Heiko Zuerker [mailto:he...@zu...]
Sent: 26 April 2010 19:48
To: dev...@li...
Subject: Re: [Devil-linux-develop] Feature request - Enable "nameif" to associate MAC address with correct interface name.

I think a warning should also be displayed, that the order of the
interfaces may have changed and the admin needs to verify.

Can you send the patch as an attachment please?
Or even better, create a feature request in mantis and attach it
there. That way we won't loose track of it.

Heiko

Quoting Dominic Raferd <dl...@ed...>:

> On 26/04/2010 16:13, Heiko Zuerker wrote:
>> Hey,
>>
>> Quoting Dominic Raferd<dl...@ed...>:
>>
>>
>>> Regarding udev, I found info at
>>> http://www.reactivated.net/writing_udev_rules.html#why about how it
>>> works which mentions some udev tools - udevinfo, udevtest, udevtrigger,
>>> udevcontrol - which are missing in DL, and might be worth adding.
>>>
>> Those are the old tools, they have been replaced by 'udevadm'.
>> Excecute 'udevadm help' for details.
>>
> cool, thanks
>>> udevtrigger seems to be the way to reprocess udev rules without
>>> rebooting. Altering (or deleting) 70-persistent-net.rules + udevtrigger
>>> + /etc/init.d/network restart should be a way to fix a broken network
>>> connection after a hardware change. At the moment I think you have to
>>> save-config and reboot instead of udevtrigger.
>>>
>> We use the the trigger and settle commands in /etc/init.d/boot.
>>
> So I see, and I learn something!
>>
>>> If this worked, then a new option could be added for the network script,
>>> say '-redetect' which would stop the network, delete
>>> 70-persistent-net.rules, then run udevtrigger before starting the
>>> network again. It should also post an advisory message that the change
>>> will not persist under DL unless configuration is saved.
>>>
>>
> To fix a simple broken network connection after a hardware change
> (especially if using the autoselect option in Setup/Network i.e. letting
> udev choose the network card module), here is a patch for the network
> script (DL 1.4RC3):
>
> --- /etc/init.d/network 1980-01-01 01:01:01.000000000 +0000
> +++ /home/z-shares/scripts/network      2010-04-26 19:21:47.000000000 +0100
> @@ -517,0 +518,15 @@
> +
> +       redetect)
> +               $0 stop $ONLY_INTERFACE
> +               sleep 1
> +               echo -n "Removed persistent record(s) for "
> +               egrep -o "NAME=\"[^\"]*"
> /etc/udev/rules.d/70-persistent-net.rules|awk -F \" '{print $2}'
> +               rm /etc/udev/rules.d/70-persistent-net.rules
> +               udevadm trigger --subsystem-match=net
> +               udevadm settle
> +               echo -n "Redetected and recreated persistent record(s) for "
> +               egrep -o "NAME=\"[^\"]*"
> /etc/udev/rules.d/70-persistent-net.rules|awk -F \" '{print $2}'
> +               $0 start $ONLY_INTERFACE
> +               echo "Network devices redetected. Run save-config to
> make changes permanent."
> +               ;;
> +
> @@ -519 +534 @@
> -               echo "Usage: $0 {start|stop|restart} [interface]"
> +               echo "Usage: $0 {start|stop|restart|redetect} [interface]"
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>



--

Regards
   Heiko Zuerker
   http://www.devil-linux.org


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



------------------------------------------------------------------------------
_______________________________________________
Devil-linux-develop mailing list
Dev...@li...
https://lists.sourceforge.net/lists/listinfo/devil-linux-develop

I think a warning should also be displayed, that the order of the  
interfaces may have changed and the admin needs to verify.

Can you send the patch as an attachment please?
Or even better, create a feature request in mantis and attach it  
there. That way we won't loose track of it.

Heiko

Quoting Dominic Raferd <dl...@ed...>:

> On 26/04/2010 16:13, Heiko Zuerker wrote:
>> Hey,
>>
>> Quoting Dominic Raferd<dl...@ed...>:
>>
>>
>>> Regarding udev, I found info at
>>> http://www.reactivated.net/writing_udev_rules.html#why about how it
>>> works which mentions some udev tools - udevinfo, udevtest, udevtrigger,
>>> udevcontrol - which are missing in DL, and might be worth adding.
>>>
>> Those are the old tools, they have been replaced by 'udevadm'.
>> Excecute 'udevadm help' for details.
>>
> cool, thanks
>>> udevtrigger seems to be the way to reprocess udev rules without
>>> rebooting. Altering (or deleting) 70-persistent-net.rules + udevtrigger
>>> + /etc/init.d/network restart should be a way to fix a broken network
>>> connection after a hardware change. At the moment I think you have to
>>> save-config and reboot instead of udevtrigger.
>>>
>> We use the the trigger and settle commands in /etc/init.d/boot.
>>
> So I see, and I learn something!
>>
>>> If this worked, then a new option could be added for the network script,
>>> say '-redetect' which would stop the network, delete
>>> 70-persistent-net.rules, then run udevtrigger before starting the
>>> network again. It should also post an advisory message that the change
>>> will not persist under DL unless configuration is saved.
>>>
>>
> To fix a simple broken network connection after a hardware change
> (especially if using the autoselect option in Setup/Network i.e. letting
> udev choose the network card module), here is a patch for the network
> script (DL 1.4RC3):
>
> --- /etc/init.d/network 1980-01-01 01:01:01.000000000 +0000
> +++ /home/z-shares/scripts/network      2010-04-26 19:21:47.000000000 +0100
> @@ -517,0 +518,15 @@
> +
> +       redetect)
> +               $0 stop $ONLY_INTERFACE
> +               sleep 1
> +               echo -n "Removed persistent record(s) for "
> +               egrep -o "NAME=\"[^\"]*"
> /etc/udev/rules.d/70-persistent-net.rules|awk -F \" '{print $2}'
> +               rm /etc/udev/rules.d/70-persistent-net.rules
> +               udevadm trigger --subsystem-match=net
> +               udevadm settle
> +               echo -n "Redetected and recreated persistent record(s) for "
> +               egrep -o "NAME=\"[^\"]*"
> /etc/udev/rules.d/70-persistent-net.rules|awk -F \" '{print $2}'
> +               $0 start $ONLY_INTERFACE
> +               echo "Network devices redetected. Run save-config to
> make changes permanent."
> +               ;;
> +
> @@ -519 +534 @@
> -               echo "Usage: $0 {start|stop|restart} [interface]"
> +               echo "Usage: $0 {start|stop|restart|redetect} [interface]"
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>



-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

On 26/04/2010 16:13, Heiko Zuerker wrote:
> Hey,
>
> Quoting Dominic Raferd<dl...@ed...>:
>
>    
>> Regarding udev, I found info at
>> http://www.reactivated.net/writing_udev_rules.html#why about how it
>> works which mentions some udev tools - udevinfo, udevtest, udevtrigger,
>> udevcontrol - which are missing in DL, and might be worth adding.
>>      
> Those are the old tools, they have been replaced by 'udevadm'.
> Excecute 'udevadm help' for details.
>    
cool, thanks
>> udevtrigger seems to be the way to reprocess udev rules without
>> rebooting. Altering (or deleting) 70-persistent-net.rules + udevtrigger
>> + /etc/init.d/network restart should be a way to fix a broken network
>> connection after a hardware change. At the moment I think you have to
>> save-config and reboot instead of udevtrigger.
>>      
> We use the the trigger and settle commands in /etc/init.d/boot.
>    
So I see, and I learn something!
>    
>> If this worked, then a new option could be added for the network script,
>> say '-redetect' which would stop the network, delete
>> 70-persistent-net.rules, then run udevtrigger before starting the
>> network again. It should also post an advisory message that the change
>> will not persist under DL unless configuration is saved.
>>      
>    
To fix a simple broken network connection after a hardware change 
(especially if using the autoselect option in Setup/Network i.e. letting 
udev choose the network card module), here is a patch for the network 
script (DL 1.4RC3):

--- /etc/init.d/network 1980-01-01 01:01:01.000000000 +0000
+++ /home/z-shares/scripts/network      2010-04-26 19:21:47.000000000 +0100
@@ -517,0 +518,15 @@
+
+       redetect)
+               $0 stop $ONLY_INTERFACE
+               sleep 1
+               echo -n "Removed persistent record(s) for "
+               egrep -o "NAME=\"[^\"]*" 
/etc/udev/rules.d/70-persistent-net.rules|awk -F \" '{print $2}'
+               rm /etc/udev/rules.d/70-persistent-net.rules
+               udevadm trigger --subsystem-match=net
+               udevadm settle
+               echo -n "Redetected and recreated persistent record(s) for "
+               egrep -o "NAME=\"[^\"]*" 
/etc/udev/rules.d/70-persistent-net.rules|awk -F \" '{print $2}'
+               $0 start $ONLY_INTERFACE
+               echo "Network devices redetected. Run save-config to 
make changes permanent."
+               ;;
+
@@ -519 +534 @@
-               echo "Usage: $0 {start|stop|restart} [interface]"
+               echo "Usage: $0 {start|stop|restart|redetect} [interface]"

Hey,

Quoting Dominic Raferd <dl...@ed...>:

> Regarding udev, I found info at
> http://www.reactivated.net/writing_udev_rules.html#why about how it
> works which mentions some udev tools - udevinfo, udevtest, udevtrigger,
> udevcontrol - which are missing in DL, and might be worth adding.

Those are the old tools, they have been replaced by 'udevadm'.  
Excecute 'udevadm help' for details.

> udevtrigger seems to be the way to reprocess udev rules without
> rebooting. Altering (or deleting) 70-persistent-net.rules + udevtrigger
> + /etc/init.d/network restart should be a way to fix a broken network
> connection after a hardware change. At the moment I think you have to
> save-config and reboot instead of udevtrigger.

We use the the trigger and settle commands in /etc/init.d/boot.

> If this worked, then a new option could be added for the network script,
> say '-redetect' which would stop the network, delete
> 70-persistent-net.rules, then run udevtrigger before starting the
> network again. It should also post an advisory message that the change
> will not persist under DL unless configuration is saved.

-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.