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

I'd say check it in, this way we get more testers right away.
It'll probably be a few days before I get a chance to look at it.

Heiko

Quoting Serge Leschinsky <ser...@gm...>:

> Done.
> The patches for setup (with "no additional space for DG") and for
> upgrade-config are enclosed.
>
> Serge
>
> On 09/06/2010 12:47 PM, Heiko Zuerker wrote:
>> It worked on my test machine, but it adds an additional space after the
>> default gateways IP (right before the closing " )
>>
>> Of course the next step is to correct the code in the "setup" program
>> (which by the way doesn't like the new ifcfg files).
>
>



-- 

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


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

Done.
The patches for setup (with "no additional space for DG") and for
upgrade-config are enclosed.

Serge

On 09/06/2010 12:47 PM, Heiko Zuerker wrote:
> It worked on my test machine, but it adds an additional space after the
> default gateways IP (right before the closing " )
> 
> Of course the next step is to correct the code in the "setup" program
> (which by the way doesn't like the new ifcfg files).

It worked on my test machine, but it adds an additional space after the
default gateways IP (right before the closing " )

Of course the next step is to correct the code in the "setup" program
(which by the way doesn't like the new ifcfg files).

Heiko

> -----Original Message-----
> From: Serge Leschinsky [mailto:ser...@gm...]
> Sent: Monday, September 06, 2010 2:17 PM
> To: dev...@li...
> Subject: Re: [Devil-linux-develop] network configuration script - add
> routes
> 
> Sorry, I forgot to add that the code is a complete program.
> As formatting may be broken, I include the code as an attachment.
> 
> Serge
> 
> 
> On 09/06/2010 11:13 AM, Serge Leschinsky wrote:
> > Heiko,
> >
> > actually, I have tested the code before posting, but it will be
great
> > to get feedback before I merge this fragment (which converts network
> > interface files
> > only) into upgrade-config. I'm asking because the price of my
mistake
> > in this case is quite big - after upgrade the network might be
> inaccessible.
> > Any volunteers are welcome :)
> >
> > Serge
> >
> > On 09/06/2010 07:04 AM, Heiko Zuerker wrote:
> >> Hey,
> >>
> >> I blame this question on my hangover...
> >> How do you want to me to test, this seems like just a code
fragment.
> >>
> >> Heiko
> >>
> >>> -----Original Message-----
> >>> From: Serge Leschinsky [mailto:ser...@gm...]
> >>> Sent: Sunday, September 05, 2010 5:37 PM
> >>> To: dev...@li...
> >>> Subject: Re: [Devil-linux-develop] network configuration script -
> >>> add routes
> >>>
> >>> Please test this code:
> >>>
> >>> # cat upgrade
> >>>
> >>> convert_routes ()
> >>> {
> >>>   local file=$1
> >>>   grep "^ROUTE=" $file | while read line;
> >>>   do
> >>>         unset ROUTE net gw
> >>>         eval $line
> >>>
> >>>         if  echo $ROUTE | grep "via\|dev" > /dev/null 2>&1; then
> >>> 	  echo $line; continue ;
> >>> 	fi
> >>>
> >>>         if echo $ROUTE | grep ":" > /dev/null 2>&1; then
> >>>                net=$(echo $ROUTE | cut -d':' -f1)
> >>>                gw=$(echo $ROUTE | cut -d':' -f2)
> >>>         else
> >>>                net=$(echo $ROUTE) # to remove spaces
> >>>         fi
> >>>
> >>>         #echo $net $gw $dev
> >>>
> >>>         # fixes
> >>>         if echo $net | grep default > /dev/null 2>&1; then
> >>>                 net="default";
> >>>         fi
> >>>
> >>>         if [ x"$gw" == "x" ]; then
> >>>                 dev="dev \$DEVICE";
> >>>         else
> >>>                 gw="via $gw";
> >>>         fi
> >>>
> >>>         echo "ROUTE=\"$net $gw $dev\""
> >>>   done
> >>>
> >>> }
> >>>
> >>> # convert network interface configuration to new format for iface
in
> >>> /etc/sysconfig/nic/*; do
> >>>
> >>>   version=$(awk -F "@version:" ' /^#@version:/ { print $2}'
$iface)
> >>>
> >>>   if [ -n "$version" ]; then
> >>>         # conversion from version "x"
> >>>         # Versions other then '1' was not released yet"
> >>>         continue
> >>>   else
> >>>         cp $iface $iface.conversion
> >>>         echo "#@version: 1" > $iface
> >>>         sed -e 's/^ROUTE/#ROUTE/g' $iface.conversion >> $iface
> >>>         convert_routes $iface.conversion >> $iface
> >>>         rm -f $iface.conversion
> >>>   fi
> >>>
> >>> done
> >>>
> >>>
> >>>
> >>> On 09/05/2010 12:08 PM, Heiko Zuerker wrote:
> >>>> Yes that would make sense.
> >>>>
> >>>> H.
> >>>>
> >>>
> >>>
> >>
---------------------------------------------------------------------
> >> ---
> >> ------
> >>> This SF.net Dev2Dev email is sponsored by:
> >>>
> >>> Show off your parallel programming skills.
> >>> Enter the Intel(R) Threading Challenge 2010.
> >>> http://p.sf.net/sfu/intel-thread-sfd
> >>> _______________________________________________
> >>> Devil-linux-develop mailing list
> >>> Dev...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
> >>
> >>
> >>
---------------------------------------------------------------------
> >> --------- This SF.net Dev2Dev email is sponsored by:
> >>
> >> Show off your parallel programming skills.
> >> Enter the Intel(R) Threading Challenge 2010.
> >> http://p.sf.net/sfu/intel-thread-sfd
> >> _______________________________________________
> >> Devil-linux-develop mailing list
> >> Dev...@li...
> >> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
> >>
> >

Sorry, I forgot to add that the code is a complete program.
As formatting may be broken, I include the code as an attachment.

Serge


On 09/06/2010 11:13 AM, Serge Leschinsky wrote:
> Heiko,
> 
> actually, I have tested the code before posting, but it will be great to get
> feedback before I merge this fragment (which converts network interface files
> only) into upgrade-config. I'm asking because the price of my mistake in this
> case is quite big - after upgrade the network might be inaccessible.
> Any volunteers are welcome :)
> 
> Serge
> 
> On 09/06/2010 07:04 AM, Heiko Zuerker wrote:
>> Hey,
>>
>> I blame this question on my hangover... 
>> How do you want to me to test, this seems like just a code fragment.
>>
>> Heiko
>>
>>> -----Original Message-----
>>> From: Serge Leschinsky [mailto:ser...@gm...]
>>> Sent: Sunday, September 05, 2010 5:37 PM
>>> To: dev...@li...
>>> Subject: Re: [Devil-linux-develop] network configuration script - add
>>> routes
>>>
>>> Please test this code:
>>>
>>> # cat upgrade
>>>
>>> convert_routes ()
>>> {
>>>   local file=$1
>>>   grep "^ROUTE=" $file | while read line;
>>>   do
>>>         unset ROUTE net gw
>>>         eval $line
>>>
>>>         if  echo $ROUTE | grep "via\|dev" > /dev/null 2>&1; then
>>> 	  echo $line; continue ;
>>> 	fi
>>>
>>>         if echo $ROUTE | grep ":" > /dev/null 2>&1; then
>>>                net=$(echo $ROUTE | cut -d':' -f1)
>>>                gw=$(echo $ROUTE | cut -d':' -f2)
>>>         else
>>>                net=$(echo $ROUTE) # to remove spaces
>>>         fi
>>>
>>>         #echo $net $gw $dev
>>>
>>>         # fixes
>>>         if echo $net | grep default > /dev/null 2>&1; then
>>>                 net="default";
>>>         fi
>>>
>>>         if [ x"$gw" == "x" ]; then
>>>                 dev="dev \$DEVICE";
>>>         else
>>>                 gw="via $gw";
>>>         fi
>>>
>>>         echo "ROUTE=\"$net $gw $dev\""
>>>   done
>>>
>>> }
>>>
>>> # convert network interface configuration to new format for iface in
>>> /etc/sysconfig/nic/*; do
>>>
>>>   version=$(awk -F "@version:" ' /^#@version:/ { print $2}' $iface)
>>>
>>>   if [ -n "$version" ]; then
>>>         # conversion from version "x"
>>>         # Versions other then '1' was not released yet"
>>>         continue
>>>   else
>>>         cp $iface $iface.conversion
>>>         echo "#@version: 1" > $iface
>>>         sed -e 's/^ROUTE/#ROUTE/g' $iface.conversion >> $iface
>>>         convert_routes $iface.conversion >> $iface
>>>         rm -f $iface.conversion
>>>   fi
>>>
>>> done
>>>
>>>
>>>
>>> On 09/05/2010 12:08 PM, Heiko Zuerker wrote:
>>>> Yes that would make sense.
>>>>
>>>> H.
>>>>
>>>
>>>
>> ------------------------------------------------------------------------
>> ------
>>> This SF.net Dev2Dev email is sponsored by:
>>>
>>> Show off your parallel programming skills.
>>> Enter the Intel(R) Threading Challenge 2010.
>>> http://p.sf.net/sfu/intel-thread-sfd
>>> _______________________________________________
>>> Devil-linux-develop mailing list
>>> Dev...@li...
>>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net Dev2Dev email is sponsored by:
>>
>> Show off your parallel programming skills.
>> Enter the Intel(R) Threading Challenge 2010.
>> http://p.sf.net/sfu/intel-thread-sfd
>> _______________________________________________
>> Devil-linux-develop mailing list
>> Dev...@li...
>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>
> 

Heiko,

actually, I have tested the code before posting, but it will be great to get
feedback before I merge this fragment (which converts network interface files
only) into upgrade-config. I'm asking because the price of my mistake in this
case is quite big - after upgrade the network might be inaccessible.
Any volunteers are welcome :)

Serge

On 09/06/2010 07:04 AM, Heiko Zuerker wrote:
> Hey,
> 
> I blame this question on my hangover... 
> How do you want to me to test, this seems like just a code fragment.
> 
> Heiko
> 
>> -----Original Message-----
>> From: Serge Leschinsky [mailto:ser...@gm...]
>> Sent: Sunday, September 05, 2010 5:37 PM
>> To: dev...@li...
>> Subject: Re: [Devil-linux-develop] network configuration script - add
>> routes
>>
>> Please test this code:
>>
>> # cat upgrade
>>
>> convert_routes ()
>> {
>>   local file=$1
>>   grep "^ROUTE=" $file | while read line;
>>   do
>>         unset ROUTE net gw
>>         eval $line
>>
>>         if  echo $ROUTE | grep "via\|dev" > /dev/null 2>&1; then
>> 	  echo $line; continue ;
>> 	fi
>>
>>         if echo $ROUTE | grep ":" > /dev/null 2>&1; then
>>                net=$(echo $ROUTE | cut -d':' -f1)
>>                gw=$(echo $ROUTE | cut -d':' -f2)
>>         else
>>                net=$(echo $ROUTE) # to remove spaces
>>         fi
>>
>>         #echo $net $gw $dev
>>
>>         # fixes
>>         if echo $net | grep default > /dev/null 2>&1; then
>>                 net="default";
>>         fi
>>
>>         if [ x"$gw" == "x" ]; then
>>                 dev="dev \$DEVICE";
>>         else
>>                 gw="via $gw";
>>         fi
>>
>>         echo "ROUTE=\"$net $gw $dev\""
>>   done
>>
>> }
>>
>> # convert network interface configuration to new format for iface in
>> /etc/sysconfig/nic/*; do
>>
>>   version=$(awk -F "@version:" ' /^#@version:/ { print $2}' $iface)
>>
>>   if [ -n "$version" ]; then
>>         # conversion from version "x"
>>         # Versions other then '1' was not released yet"
>>         continue
>>   else
>>         cp $iface $iface.conversion
>>         echo "#@version: 1" > $iface
>>         sed -e 's/^ROUTE/#ROUTE/g' $iface.conversion >> $iface
>>         convert_routes $iface.conversion >> $iface
>>         rm -f $iface.conversion
>>   fi
>>
>> done
>>
>>
>>
>> On 09/05/2010 12:08 PM, Heiko Zuerker wrote:
>>> Yes that would make sense.
>>>
>>> H.
>>>
>>
>>
> ------------------------------------------------------------------------
> ------
>> This SF.net Dev2Dev email is sponsored by:
>>
>> Show off your parallel programming skills.
>> Enter the Intel(R) Threading Challenge 2010.
>> http://p.sf.net/sfu/intel-thread-sfd
>> _______________________________________________
>> Devil-linux-develop mailing list
>> Dev...@li...
>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
> 
> 
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
> 
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
> 

Hey,

I blame this question on my hangover... 
How do you want to me to test, this seems like just a code fragment.

Heiko

> -----Original Message-----
> From: Serge Leschinsky [mailto:ser...@gm...]
> Sent: Sunday, September 05, 2010 5:37 PM
> To: dev...@li...
> Subject: Re: [Devil-linux-develop] network configuration script - add
> routes
> 
> Please test this code:
> 
> # cat upgrade
> 
> convert_routes ()
> {
>   local file=$1
>   grep "^ROUTE=" $file | while read line;
>   do
>         unset ROUTE net gw
>         eval $line
> 
>         if  echo $ROUTE | grep "via\|dev" > /dev/null 2>&1; then
> 	  echo $line; continue ;
> 	fi
> 
>         if echo $ROUTE | grep ":" > /dev/null 2>&1; then
>                net=$(echo $ROUTE | cut -d':' -f1)
>                gw=$(echo $ROUTE | cut -d':' -f2)
>         else
>                net=$(echo $ROUTE) # to remove spaces
>         fi
> 
>         #echo $net $gw $dev
> 
>         # fixes
>         if echo $net | grep default > /dev/null 2>&1; then
>                 net="default";
>         fi
> 
>         if [ x"$gw" == "x" ]; then
>                 dev="dev \$DEVICE";
>         else
>                 gw="via $gw";
>         fi
> 
>         echo "ROUTE=\"$net $gw $dev\""
>   done
> 
> }
> 
> # convert network interface configuration to new format for iface in
> /etc/sysconfig/nic/*; do
> 
>   version=$(awk -F "@version:" ' /^#@version:/ { print $2}' $iface)
> 
>   if [ -n "$version" ]; then
>         # conversion from version "x"
>         # Versions other then '1' was not released yet"
>         continue
>   else
>         cp $iface $iface.conversion
>         echo "#@version: 1" > $iface
>         sed -e 's/^ROUTE/#ROUTE/g' $iface.conversion >> $iface
>         convert_routes $iface.conversion >> $iface
>         rm -f $iface.conversion
>   fi
> 
> done
> 
> 
> 
> On 09/05/2010 12:08 PM, Heiko Zuerker wrote:
> > Yes that would make sense.
> >
> > H.
> >
> 
>
------------------------------------------------------------------------
------
> This SF.net Dev2Dev email is sponsored by:
> 
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop

Please test this code:

# cat upgrade

convert_routes ()
{
  local file=$1
  grep "^ROUTE=" $file | while read line;
  do
        unset ROUTE net gw
        eval $line

        if  echo $ROUTE | grep "via\|dev" > /dev/null 2>&1; then
	  echo $line; continue ;
	fi

        if echo $ROUTE | grep ":" > /dev/null 2>&1; then
               net=$(echo $ROUTE | cut -d':' -f1)
               gw=$(echo $ROUTE | cut -d':' -f2)
        else
               net=$(echo $ROUTE) # to remove spaces
        fi

        #echo $net $gw $dev

        # fixes
        if echo $net | grep default > /dev/null 2>&1; then
                net="default";
        fi

        if [ x"$gw" == "x" ]; then
                dev="dev \$DEVICE";
        else
                gw="via $gw";
        fi

        echo "ROUTE=\"$net $gw $dev\""
  done

}

# convert network interface configuration to new format
for iface in /etc/sysconfig/nic/*; do

  version=$(awk -F "@version:" ' /^#@version:/ { print $2}' $iface)

  if [ -n "$version" ]; then
        # conversion from version "x"
        # Versions other then '1' was not released yet"
        continue
  else
        cp $iface $iface.conversion
        echo "#@version: 1" > $iface
        sed -e 's/^ROUTE/#ROUTE/g' $iface.conversion >> $iface
        convert_routes $iface.conversion >> $iface
        rm -f $iface.conversion
  fi

done



On 09/05/2010 12:08 PM, Heiko Zuerker wrote:
> Yes that would make sense.
> 
> H.
> 

Heiko,

how to identify that the network configuration has "new" format to avoid
unnecessary processing? What about version in the file? The similar to syslog-ng
config file. Something like that:

#@version 1

I'll try to do that.

Serge

On 09/05/2010 12:08 PM, Heiko Zuerker wrote:
> Yes that would make sense.
> 
> H.
> 

Yes that would make sense.

H.

> -----Original Message-----
> From: Serge Leschinsky [mailto:ser...@gm...]
> Sent: Sunday, September 05, 2010 1:29 PM
> To: dev...@li...
> Subject: Re: [Devil-linux-develop] network configuration script - add
> routes
> 
> Hi Heiko,
> 
> you are right. The code below converts "old style" routes to "new
style"
> and prints new ROUTE without modification. Can we use it as a template
> for upgrade script?
> 
> 
> # cat ./test
> ######### Possible route configuration ######### # OLD ROUTES
> 
> ROUTE="$ROUTE 192.168.254.0/255.255.255.0:10.90.1.252"
> ROUTE="$ROUTE 192.168.3.0:10.90.1.252"
> ROUTE="$ROUTE default/0:10.90.1.1"
> 
> ROUTE="$ROUTE 192.168.3.0/255.255.255.0"
> ROUTE="$ROUTE 192.168.5.7"
> 
> # NEW ROUTES
> 
> ROUTE="192.168.254.X/255.255.255.0 via 10.90.1.252 "
> ROUTE="192.168.3.X via 10.90.1.252 "
> ROUTE="default via 10.90.1.X "
> ROUTE="192.168.3.X/255.255.255.0 dev $DEVICE"
> ROUTE="192.168.5.X dev $DEVICE"
> 
> ###############################################
> grep "^ROUTE=" ./$0 | while read line;
> do
>         unset ROUTE net gw
>         eval $line
> 
>         if  echo $ROUTE | grep "via\|dev" > /dev/null 2>&1; then echo
$line;
> continue ; fi
> 
>         if echo $ROUTE | grep ":" > /dev/null 2>&1; then
>                net=$(echo $ROUTE | cut -d':' -f1)
>                gw=$(echo $ROUTE | cut -d':' -f2)
>         else
>                net=$(echo $ROUTE) # to remove spaces
>         fi
> 
>         #echo $net $gw $dev
> 
>         # fixes
>         if echo $net | grep default > /dev/null 2>&1; then
>                 net="default";
>         fi
> 
>         if [ x"$gw" == "x" ]; then
>                 dev="dev \$DEVICE";
>         else
>                 gw="via $gw";
>         fi
> 
>         echo "ROUTE=\"$net $gw $dev\""
> 
> done
> 
> 
> On 09/05/2010 08:59 AM, Heiko Zuerker wrote:
> > Hey,
> >
> > Seems like we need to update the upgrade script, to set the routes
> > correctly.
> > I just updated all my VMs and I had to fix the default route
> everywhere.
> >
> > Heiko
> >
> >> -----Original Message-----
> >> From: Serge Leschinsky [mailto:ser...@gm...]
> >> Sent: Monday, August 30, 2010 3:08 PM
> >> To: dev...@li...
> >> Subject: Re: [Devil-linux-develop] network configuration script -
add
> >> routes
> >>
> >> Done.
> >>
> >> Serge
> >>
> >> On 08/30/2010 08:32 AM, Heiko Zuerker wrote:
> >>> Seems good to me.
> >>> Let's get it in CVS so we can have more testers.
> >>> I'm still working on updating all the software packages Alby
> >>> mentioned, including a couple of fixes to the script he provided.
> >>>
> >>> Heiko
> >>>
> >>> Quoting Serge Leschinsky <ser...@gm...>:
> >>>
> >>>> the final final version:
> >>>>
> >>>> Summary:
> >>>>
> >>>> - added all types of route
> >>>> - added rules
> >>>> - added tunnel interface configuration
> >>>>
> >>>> Serge
> >>>>
> >>>>
> >>>>
> >
---------------------------------------------------------------------
> >>>> ----
> >>>> cat ifcfg-eth0.sample:
> >>>> #
> >>>> # example for a "normal" INTERFACE with no VLANs and no
> BRIDGING
> >> #
> >>>> DHCP=no #DHCP=yes #DHCP=server # options passed directly to
> >> dhcpcd on
> >>>> startup #DHCP_OPTIONS=""
> >>>> ONBOOT=yes
> >>>> DEVICE=eth0
> >>>> IP=10.90.1.200
> >>>> NETMASK=255.255.255.0
> >>>> #BROADCAST=10.90.1.255
> >>>> #MAC=
> >>>> MODULE=pcnet32
> >>>> #MODULE_OPTS=
> >>>> #
> >>>>
> >>>>
> >>
> #######################################################
> >> #
> >>>> # ROUTE=" ...... "
> >>>> # where ROUTE is a key word and the line with ROUTE # should not
> >> have
> >>>> spaces between the beginning of # the line and the keyword #
> Route
> >>>> statement is a any valid "ip route"# command, # without "ip route
> >>>> add" prefix - it will be added # automatically # #
IPV6ROUTE="...."
> >>>> # IPV6ROUTE keyword can be used for ipv6 routes.
> >>>> #
> >>>> # RULE=" ...... "
> >>>> # where RULE is a key word and the line with RULE # should not
> have
> >>>> spaces between the beginning of # the line and the keyword #
> Rule
> >>>> statement is a any valid "ip rule" command, # without "ip rule
add"
> >>>> prefix - it will be added # automatically # # $DEVICE can be used
> > to
> >>>> directly specify the interface # ###### samples for several
> > possible
> >>>> scenarios # # route to network 192.168.254.0/255.255.255.0 via
> >>>> gateway 10.90.1.252
> >>>> #ROUTE="192.168.254.0/255.255.255.0 via 10.90.1.252"
> >>>> # or
> >>>> #ROUTE="192.168.254.0/24 via 10.90.1.252"
> >>>> #
> >>>> #
> >>>> # route to host 192.168.3.1 via 10.90.1.252
> >>>> #ROUTE="192.168.3.0/32 via 10.90.1.252"
> >>>> #
> >>>> # route to network that is also reachable via this interface
> >>>> #ROUTE="192.168.3.0/24 dev $DEVICE"
> >>>> #
> >>>>
> >>>> # special routes
> >>>> #ROUTE="unreachable 10.0.0.0/8"
> >>>> #ROUTE="blackhole 192.168.1.0/24"
> >>>> #
> >>>> # add as many ROUTE="...." lines as you need routes # # the next
> > line
> >>>> shows how to set the default gateway #ROUTE="default via
> >> 10.90.1.1".
> >>>> #
> >>>> ###### advanced routing
> >>>> # make sure additional routing table is created # # echo "500
> >>>> bypass" >> /etc/iproute2/rt_tables # #ROUTE="default via
> >> 1.234.123.1
> >>>> table bypass"
> >>>> #RULE="from 10.0.0.0/24 table bypass prio 500"
> >>>> #RULE="from 10.0.1.0/24 table bypass prio 600"
> >>>> #RULE="from 10.0.2.123/32 to 10.8.0.0/16 table main prio 400"
> >>>> #
> >>>>
> >>>>
> >
---------------------------------------------------------------------
> >>>> ----
> >>>> cat ifcfg-tun0.sample:
> >>>> #
> >>>> # example for a tunnel INTERFACE
> >>>> #
> >>>> ONBOOT=yes
> >>>> TUNNEL=yes
> >>>>
> >>>> # bind the tunnel to the device DEVICE so that tunneled packets #
> >>>> will only be routed via this device and will not be able to
escape
> > #
> >>>> to another device when the route to endpoint changes.
> >>>> #DEVICE=eth4
> >>>>
> >>>> # set the fixed local address for tunneled packets.
> >>>> LOCAL=10.90.1.200
> >>>>
> >>>> # set the remote endpoint of the tunnel.
> >>>> REMOTE=1.2.3.204
> >>>>
> >>>> # Available modes depend on the encapsulating address family.
> >>>> # Modes for IPv4 encapsulation available: ipip, sit, isatap and
> > gre.
> >>>> # Modes for IPv6 encapsulation available: ip6ip6, ipip6 and any.
> >>>> MODE=ipip
> >>>>
> >>>> # addtional tunnel options if any
> >>>> TUN_OPTS=""
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >
----------------------------------------------------------------------
> > --
> > ------
> >> This SF.net Dev2Dev email is sponsored by:
> >>
> >> Show off your parallel programming skills.
> >> Enter the Intel(R) Threading Challenge 2010.
> >> http://p.sf.net/sfu/intel-thread-sfd
> >> _______________________________________________
> >> Devil-linux-develop mailing list
> >> Dev...@li...
> >> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
> >
> >
> >
----------------------------------------------------------------------
> > -------- This SF.net Dev2Dev email is sponsored by:
> >
> > Show off your parallel programming skills.
> > Enter the Intel(R) Threading Challenge 2010.
> > http://p.sf.net/sfu/intel-thread-sfd
> > _______________________________________________
> > Devil-linux-develop mailing list
> > Dev...@li...
> > https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
> >
> 
> 
>
------------------------------------------------------------------------
------
> This SF.net Dev2Dev email is sponsored by:
> 
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop

Hi Heiko,

you are right. The code below converts "old style" routes to "new style" and
prints new ROUTE without modification. Can we use it as a template for upgrade
script?


# cat ./test
######### Possible route configuration #########
# OLD ROUTES

ROUTE="$ROUTE 192.168.254.0/255.255.255.0:10.90.1.252"
ROUTE="$ROUTE 192.168.3.0:10.90.1.252"
ROUTE="$ROUTE default/0:10.90.1.1"

ROUTE="$ROUTE 192.168.3.0/255.255.255.0"
ROUTE="$ROUTE 192.168.5.7"

# NEW ROUTES

ROUTE="192.168.254.X/255.255.255.0 via 10.90.1.252 "
ROUTE="192.168.3.X via 10.90.1.252 "
ROUTE="default via 10.90.1.X "
ROUTE="192.168.3.X/255.255.255.0 dev $DEVICE"
ROUTE="192.168.5.X dev $DEVICE"

###############################################
grep "^ROUTE=" ./$0 | while read line;
do
        unset ROUTE net gw
        eval $line

        if  echo $ROUTE | grep "via\|dev" > /dev/null 2>&1; then echo $line;
continue ; fi

        if echo $ROUTE | grep ":" > /dev/null 2>&1; then
               net=$(echo $ROUTE | cut -d':' -f1)
               gw=$(echo $ROUTE | cut -d':' -f2)
        else
               net=$(echo $ROUTE) # to remove spaces
        fi

        #echo $net $gw $dev

        # fixes
        if echo $net | grep default > /dev/null 2>&1; then
                net="default";
        fi

        if [ x"$gw" == "x" ]; then
                dev="dev \$DEVICE";
        else
                gw="via $gw";
        fi

        echo "ROUTE=\"$net $gw $dev\""

done


On 09/05/2010 08:59 AM, Heiko Zuerker wrote:
> Hey,
> 
> Seems like we need to update the upgrade script, to set the routes
> correctly.
> I just updated all my VMs and I had to fix the default route everywhere.
> 
> Heiko
> 
>> -----Original Message-----
>> From: Serge Leschinsky [mailto:ser...@gm...]
>> Sent: Monday, August 30, 2010 3:08 PM
>> To: dev...@li...
>> Subject: Re: [Devil-linux-develop] network configuration script - add
>> routes
>>
>> Done.
>>
>> Serge
>>
>> On 08/30/2010 08:32 AM, Heiko Zuerker wrote:
>>> Seems good to me.
>>> Let's get it in CVS so we can have more testers.
>>> I'm still working on updating all the software packages Alby
>>> mentioned, including a couple of fixes to the script he provided.
>>>
>>> Heiko
>>>
>>> Quoting Serge Leschinsky <ser...@gm...>:
>>>
>>>> the final final version:
>>>>
>>>> Summary:
>>>>
>>>> - added all types of route
>>>> - added rules
>>>> - added tunnel interface configuration
>>>>
>>>> Serge
>>>>
>>>>
>>>>
> ---------------------------------------------------------------------
>>>> ----
>>>> cat ifcfg-eth0.sample:
>>>> #
>>>> # example for a "normal" INTERFACE with no VLANs and no BRIDGING
>> #
>>>> DHCP=no #DHCP=yes #DHCP=server # options passed directly to
>> dhcpcd on
>>>> startup #DHCP_OPTIONS=""
>>>> ONBOOT=yes
>>>> DEVICE=eth0
>>>> IP=10.90.1.200
>>>> NETMASK=255.255.255.0
>>>> #BROADCAST=10.90.1.255
>>>> #MAC=
>>>> MODULE=pcnet32
>>>> #MODULE_OPTS=
>>>> #
>>>>
>>>>
>> #######################################################
>> #
>>>> # ROUTE=" ...... "
>>>> # where ROUTE is a key word and the line with ROUTE # should not
>> have
>>>> spaces between the beginning of # the line and the keyword # Route
>>>> statement is a any valid "ip route"# command, # without "ip route
>>>> add" prefix - it will be added # automatically # # IPV6ROUTE="...."
>>>> # IPV6ROUTE keyword can be used for ipv6 routes.
>>>> #
>>>> # RULE=" ...... "
>>>> # where RULE is a key word and the line with RULE # should not have
>>>> spaces between the beginning of # the line and the keyword # Rule
>>>> statement is a any valid "ip rule" command, # without "ip rule add"
>>>> prefix - it will be added # automatically # # $DEVICE can be used
> to
>>>> directly specify the interface # ###### samples for several
> possible
>>>> scenarios # # route to network 192.168.254.0/255.255.255.0 via
>>>> gateway 10.90.1.252
>>>> #ROUTE="192.168.254.0/255.255.255.0 via 10.90.1.252"
>>>> # or
>>>> #ROUTE="192.168.254.0/24 via 10.90.1.252"
>>>> #
>>>> #
>>>> # route to host 192.168.3.1 via 10.90.1.252
>>>> #ROUTE="192.168.3.0/32 via 10.90.1.252"
>>>> #
>>>> # route to network that is also reachable via this interface
>>>> #ROUTE="192.168.3.0/24 dev $DEVICE"
>>>> #
>>>>
>>>> # special routes
>>>> #ROUTE="unreachable 10.0.0.0/8"
>>>> #ROUTE="blackhole 192.168.1.0/24"
>>>> #
>>>> # add as many ROUTE="...." lines as you need routes # # the next
> line
>>>> shows how to set the default gateway #ROUTE="default via
>> 10.90.1.1".
>>>> #
>>>> ###### advanced routing
>>>> # make sure additional routing table is created # # echo "500
>>>> bypass" >> /etc/iproute2/rt_tables # #ROUTE="default via
>> 1.234.123.1
>>>> table bypass"
>>>> #RULE="from 10.0.0.0/24 table bypass prio 500"
>>>> #RULE="from 10.0.1.0/24 table bypass prio 600"
>>>> #RULE="from 10.0.2.123/32 to 10.8.0.0/16 table main prio 400"
>>>> #
>>>>
>>>>
> ---------------------------------------------------------------------
>>>> ----
>>>> cat ifcfg-tun0.sample:
>>>> #
>>>> # example for a tunnel INTERFACE
>>>> #
>>>> ONBOOT=yes
>>>> TUNNEL=yes
>>>>
>>>> # bind the tunnel to the device DEVICE so that tunneled packets #
>>>> will only be routed via this device and will not be able to escape
> #
>>>> to another device when the route to endpoint changes.
>>>> #DEVICE=eth4
>>>>
>>>> # set the fixed local address for tunneled packets.
>>>> LOCAL=10.90.1.200
>>>>
>>>> # set the remote endpoint of the tunnel.
>>>> REMOTE=1.2.3.204
>>>>
>>>> # Available modes depend on the encapsulating address family.
>>>> # Modes for IPv4 encapsulation available: ipip, sit, isatap and
> gre.
>>>> # Modes for IPv6 encapsulation available: ip6ip6, ipip6 and any.
>>>> MODE=ipip
>>>>
>>>> # addtional tunnel options if any
>>>> TUN_OPTS=""
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
> ------------------------------------------------------------------------
> ------
>> This SF.net Dev2Dev email is sponsored by:
>>
>> Show off your parallel programming skills.
>> Enter the Intel(R) Threading Challenge 2010.
>> http://p.sf.net/sfu/intel-thread-sfd
>> _______________________________________________
>> Devil-linux-develop mailing list
>> Dev...@li...
>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
> 
> 
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
> 
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
> 

Hey,

Seems like we need to update the upgrade script, to set the routes
correctly.
I just updated all my VMs and I had to fix the default route everywhere.

Heiko

> -----Original Message-----
> From: Serge Leschinsky [mailto:ser...@gm...]
> Sent: Monday, August 30, 2010 3:08 PM
> To: dev...@li...
> Subject: Re: [Devil-linux-develop] network configuration script - add
> routes
> 
> Done.
> 
> Serge
> 
> On 08/30/2010 08:32 AM, Heiko Zuerker wrote:
> > Seems good to me.
> > Let's get it in CVS so we can have more testers.
> > I'm still working on updating all the software packages Alby
> > mentioned, including a couple of fixes to the script he provided.
> >
> > Heiko
> >
> > Quoting Serge Leschinsky <ser...@gm...>:
> >
> >> the final final version:
> >>
> >> Summary:
> >>
> >> - added all types of route
> >> - added rules
> >> - added tunnel interface configuration
> >>
> >> Serge
> >>
> >>
> >>
---------------------------------------------------------------------
> >> ----
> >> cat ifcfg-eth0.sample:
> >> #
> >> # example for a "normal" INTERFACE with no VLANs and no BRIDGING
> #
> >> DHCP=no #DHCP=yes #DHCP=server # options passed directly to
> dhcpcd on
> >> startup #DHCP_OPTIONS=""
> >> ONBOOT=yes
> >> DEVICE=eth0
> >> IP=10.90.1.200
> >> NETMASK=255.255.255.0
> >> #BROADCAST=10.90.1.255
> >> #MAC=
> >> MODULE=pcnet32
> >> #MODULE_OPTS=
> >> #
> >>
> >>
> #######################################################
> #
> >> # ROUTE=" ...... "
> >> # where ROUTE is a key word and the line with ROUTE # should not
> have
> >> spaces between the beginning of # the line and the keyword # Route
> >> statement is a any valid "ip route"# command, # without "ip route
> >> add" prefix - it will be added # automatically # # IPV6ROUTE="...."
> >> # IPV6ROUTE keyword can be used for ipv6 routes.
> >> #
> >> # RULE=" ...... "
> >> # where RULE is a key word and the line with RULE # should not have
> >> spaces between the beginning of # the line and the keyword # Rule
> >> statement is a any valid "ip rule" command, # without "ip rule add"
> >> prefix - it will be added # automatically # # $DEVICE can be used
to
> >> directly specify the interface # ###### samples for several
possible
> >> scenarios # # route to network 192.168.254.0/255.255.255.0 via
> >> gateway 10.90.1.252
> >> #ROUTE="192.168.254.0/255.255.255.0 via 10.90.1.252"
> >> # or
> >> #ROUTE="192.168.254.0/24 via 10.90.1.252"
> >> #
> >> #
> >> # route to host 192.168.3.1 via 10.90.1.252
> >> #ROUTE="192.168.3.0/32 via 10.90.1.252"
> >> #
> >> # route to network that is also reachable via this interface
> >> #ROUTE="192.168.3.0/24 dev $DEVICE"
> >> #
> >>
> >> # special routes
> >> #ROUTE="unreachable 10.0.0.0/8"
> >> #ROUTE="blackhole 192.168.1.0/24"
> >> #
> >> # add as many ROUTE="...." lines as you need routes # # the next
line
> >> shows how to set the default gateway #ROUTE="default via
> 10.90.1.1".
> >> #
> >> ###### advanced routing
> >> # make sure additional routing table is created # # echo "500
> >> bypass" >> /etc/iproute2/rt_tables # #ROUTE="default via
> 1.234.123.1
> >> table bypass"
> >> #RULE="from 10.0.0.0/24 table bypass prio 500"
> >> #RULE="from 10.0.1.0/24 table bypass prio 600"
> >> #RULE="from 10.0.2.123/32 to 10.8.0.0/16 table main prio 400"
> >> #
> >>
> >>
---------------------------------------------------------------------
> >> ----
> >> cat ifcfg-tun0.sample:
> >> #
> >> # example for a tunnel INTERFACE
> >> #
> >> ONBOOT=yes
> >> TUNNEL=yes
> >>
> >> # bind the tunnel to the device DEVICE so that tunneled packets #
> >> will only be routed via this device and will not be able to escape
#
> >> to another device when the route to endpoint changes.
> >> #DEVICE=eth4
> >>
> >> # set the fixed local address for tunneled packets.
> >> LOCAL=10.90.1.200
> >>
> >> # set the remote endpoint of the tunnel.
> >> REMOTE=1.2.3.204
> >>
> >> # Available modes depend on the encapsulating address family.
> >> # Modes for IPv4 encapsulation available: ipip, sit, isatap and
gre.
> >> # Modes for IPv6 encapsulation available: ip6ip6, ipip6 and any.
> >> MODE=ipip
> >>
> >> # addtional tunnel options if any
> >> TUN_OPTS=""
> >>
> >>
> >>
> >
> >
> >
> 
> 
>
------------------------------------------------------------------------
------
> This SF.net Dev2Dev email is sponsored by:
> 
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop

Fixed

Heiko

Quoting Stefan Engel <ma...@en...>:

> Hi Heiko,
>
> I have just updated and taken a look into Makefile.build. I don't know
> if this is correct:
>
> GROUP_16 := e2fsprogs gdchart openldap pam_mysql postgresql \
>          wvstreams iperf irqbalance util-linux
>
> ...
>
> util-linux:  | $(GROUP_16)
>
>
> AFAIK util-linux will then only be build if group 16 is completely
> build, and because util-linux is in group 16 we might have a problem
> here. Shouldn't it be more like
>
> util-linux:  | $(GROUP_15)
>
>
> Regards,
> Stefan
>
> On 08/31/2010 03:30 PM, Heiko Zuerker wrote:
>> Stefan,
>>
>> I moved util-linux into the place you suggested.
>>
>> Heiko
>>
>> Quoting Stefan Engel <ma...@en...>:
>>> Hi,
>>>
>>> the build of DL just finished from a clean lfssystem with default config
>>> for applications and kernel. Everything seems ok so far.
>>>
>>> According to chapter 6 of
>>> http://www.linuxfromscratch.org/lfs/view/stable LFS is building
>>> util-linux early in the process too.
>>>
>>> Stefan
>>>
>>> On 08/09/2010 02:13 PM, Heiko Zuerker wrote:
>>>> Hey,
>>>>
>>>> it's almost impossible to find all the package interdependencies
>>>> without trial'n'error. Did you compile DL with a clean lfssystem and
>>>> all options turned on? If that works, then we could move it.
>>>> As an alternative, we can also be look at moving apcupsd.
>>>>
>>>> Heiko
>>>>
>>>> Quoting Stefan Engel <ma...@en...>:
>>>>> Hi,
>>>>>
>>>>> for our firewall distribution I tried to upgrade apcupsd to the latest
>>>>> release (3.14.8) and stumbled over a problem cause by /usr/bin/col of
>>>>> the LFS system (lfssystem-SVN-20070314). This version seems to be a
>>>>> little bit too old and has problems dealing with some characters when
>>>>> generating the man pages of apcupsd.
>>>>>
>>>>> /usr/bin/col can be found in the package util-linux. util-linux already
>>>>> gets build and installed in the underlying LFS system, but this is late
>>>>> in the build order. To work around my problem I moved util-linux from
>>>>> GROUP_24 to GROUP_17 and adjusted the dependency of util-linux to
>>>>> GROUP_16 in Makefile.build.
>>>>>
>>>>> Is it possible to change this in Makefile.build or are there any
>>>>> problems when using a current version of util-linux during the early
>>>>> stages of the build process?
>>>>>
>>>>> Regards,
>>>>> Stefan
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> This SF.net email is sponsored by
>>>>>
>>>>> Make an app they can't live without
>>>>> Enter the BlackBerry Developer Challenge
>>>>> http://p.sf.net/sfu/RIM-dev2dev
>>>>> _______________________________________________
>>>>> Devil-linux-develop mailing list
>>>>> Dev...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> This SF.net email is sponsored by
>>>
>>> Make an app they can't live without
>>> Enter the BlackBerry Developer Challenge
>>> http://p.sf.net/sfu/RIM-dev2dev
>>> _______________________________________________
>>> Devil-linux-develop mailing list
>>> Dev...@li...
>>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>>
>>
>>
>>
>
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> 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.

Hi Heiko,

I have just updated and taken a look into Makefile.build. I don't know
if this is correct:

GROUP_16 := e2fsprogs gdchart openldap pam_mysql postgresql \
         wvstreams iperf irqbalance util-linux

...

util-linux:  | $(GROUP_16)


AFAIK util-linux will then only be build if group 16 is completely
build, and because util-linux is in group 16 we might have a problem
here. Shouldn't it be more like

util-linux:  | $(GROUP_15)


Regards,
Stefan

On 08/31/2010 03:30 PM, Heiko Zuerker wrote:
> Stefan,
> 
> I moved util-linux into the place you suggested.
> 
> Heiko
> 
> Quoting Stefan Engel <ma...@en...>:
>> Hi,
>>
>> the build of DL just finished from a clean lfssystem with default config
>> for applications and kernel. Everything seems ok so far.
>>
>> According to chapter 6 of
>> http://www.linuxfromscratch.org/lfs/view/stable LFS is building
>> util-linux early in the process too.
>>
>> Stefan
>>
>> On 08/09/2010 02:13 PM, Heiko Zuerker wrote:
>>> Hey,
>>>
>>> it's almost impossible to find all the package interdependencies
>>> without trial'n'error. Did you compile DL with a clean lfssystem and
>>> all options turned on? If that works, then we could move it.
>>> As an alternative, we can also be look at moving apcupsd.
>>>
>>> Heiko
>>>
>>> Quoting Stefan Engel <ma...@en...>:
>>>> Hi,
>>>>
>>>> for our firewall distribution I tried to upgrade apcupsd to the latest
>>>> release (3.14.8) and stumbled over a problem cause by /usr/bin/col of
>>>> the LFS system (lfssystem-SVN-20070314). This version seems to be a
>>>> little bit too old and has problems dealing with some characters when
>>>> generating the man pages of apcupsd.
>>>>
>>>> /usr/bin/col can be found in the package util-linux. util-linux already
>>>> gets build and installed in the underlying LFS system, but this is late
>>>> in the build order. To work around my problem I moved util-linux from
>>>> GROUP_24 to GROUP_17 and adjusted the dependency of util-linux to
>>>> GROUP_16 in Makefile.build.
>>>>
>>>> Is it possible to change this in Makefile.build or are there any
>>>> problems when using a current version of util-linux during the early
>>>> stages of the build process?
>>>>
>>>> Regards,
>>>> Stefan
>>>>
>>>> ------------------------------------------------------------------------------
>>>> This SF.net email is sponsored by
>>>>
>>>> Make an app they can't live without
>>>> Enter the BlackBerry Developer Challenge
>>>> http://p.sf.net/sfu/RIM-dev2dev
>>>> _______________________________________________
>>>> Devil-linux-develop mailing list
>>>> Dev...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>>>
>>>
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by
>>
>> Make an app they can't live without
>> Enter the BlackBerry Developer Challenge
>> http://p.sf.net/sfu/RIM-dev2dev
>> _______________________________________________
>> Devil-linux-develop mailing list
>> Dev...@li...
>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>
> 
> 
> 

Serge,

That's now done, with patch against 1.50 which is the latest I can find 
in cvs.

Dominic

On 01/09/2010 21:17, Serge Leschinsky wrote:
> Dominic,
>
> may I ask you to reopen the FR#70 and upload the patch against the latest
> version of network script?
>
> Serge
>
> On 08/31/2010 07:28 AM, Dominic Raferd wrote:
>>    Serge:
>>
>> Exactly so. I think this 'network redetect' works easily if there is one
>> network device (option 'r'). With more than one, and if the order
>> (eth0/eth1) matters, the user configures 70-persistent-net.rules
>> manually and then uses 'network redetect' with option 'k' to restart
>> networking; it makes life easier in this situation too. I haven't been
>> able to test it with wireless lan devices, though.
>>
>> BTW I see the existing network script has a never-executed call at the
>> end to a non-existent /etc/init.d/wlan.
>>
>> Dominic
>>
>> On 30/08/2010 21:50, Serge Leschinsky wrote:
>>> Heiko, Dominic,
>>>
>>>
>>> as far as I can see this feature is opposite to concatenation of
>>> 70-persistent-net.rules, and in essence it's a way to clean this file up from
>>> "outdated" records without reboot. For me it's "nice to have".
>>>
>>>
>>> Serge
>>>
>>>
>>>
>>> On 08/30/2010 08:33 AM, Heiko Zuerker wrote:
>>>> Does anybody have an opinion on this?
>>>>
>>>> Heiko
>>>>
>>>> Quoting Dominic Raferd<dl...@ed...>:
>>>>
>>>>> Back in April I submitted to Mantis some code for the
>>>>> /etc/init.d/network script which added a new 'redetect' options to allow
>>>>> redetection of changed network hardware
>>>>> https://sourceforge.net/apps/mantisbt/devil-linux/view.php?id=70. This
>>>>> was felt to be unnecessary because of the introduction of mactab, but it
>>>>> might be worth reconsidering if we are now removing mactab.
>>>>>
>>>>> Dominic
>>>>>
>>>>> Here's the help info for it:
>>>>>
>>>>> 'network redetect' will disrupt any existing network connection and may
>>>>> leave it broken. It is intended for use from a local terminal and in
>>>>> cases where network hardware has changed and needs to be reconfigured to
>>>>> work properly. Or (with 'k' option) where
>>>>> /etc/udev/rules.d/70-persistent-net.rules file has been changed
>>>>> manually, and the network needs to be restarted to reflect the changes.
>>>>> If pre-existing network hardware is working, but additional new network
>>>>> hardware is not, 'network redetect' is probably not the right tool -
>>>>> instead, configure the new hardware from the NET section of 'setup'.
>>>>>
>>>>> Usually you first run with option 'r', this stops the network, removes
>>>>> any prior information about network devices stored at
>>>>> /etc/udev/rules.d/70-persistent-net.rules, redetects network devices,
>>>>> recreates this file and then attempts to restart the network. To restart
>>>>> the network it needs a network module; if you choose the 'autoselect'
>>>>> option when and if requested, it will override any existing module set
>>>>> by 'setup' at /etc/sysconfig/nic/ifcfg-ethn and use the module suggested
>>>>> by udev.
>>>>>
>>>>> If this fails, reconfigure /etc/udev/rules.d/70-persistent-net.rules
>>>>> manually (for instance, switching the allocation of device NAMEs between
>>>>> eth0 and eth1) and then rerun 'network redetect' with the 'k' option.
>>>>>
>>>>> If you still have problems, check settings for the network device
>>>>> (including module) using 'setup'. When you have an operational network,
>>>>> save your changes with 'save-config -q'.
>>>>>
>>>>>> Heiko
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Heiko Zuerker [mailto:he...@zu...]
>>>>>>> Sent: Saturday, August 28, 2010 8:06 AM
>>>>>>> To: dev...@li...
>>>>>>> Subject: Re: [Devil-linux-develop] Enable "nameif" to associate MAC
>>>>>>> address with correct interface name
>>>>>>>
>>>>>>> Yes I agree, let's take it back out.
>>>>>>>
>>>>>>> Heiko
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Stefan Engel [mailto:ma...@en...]
>>>>>>>> Sent: Monday, August 23, 2010 4:12 AM
>>>>>>>> To: dev...@li...
>>>>>>>> Subject: Re: [Devil-linux-develop] Enable "nameif" to associate MAC
>>>>>>>> address with correct interface name
>>>>>>>>
>>>>>>>> Hi Serge,
>>>>>>>>
>>>>>>>> I just tested my config with
>>>>>> /etc/udev/rules.d/70-persistent-net.rules
>>>>>>>> with two VMs and it's working without problems. This solution looks
>>>>>>> like
>>>>>>>> the more elegant way to assign interface names to mac addresses.
>>>>>>>>
>>>>>>>> Seems that the changes we made for dealing with /etc/mactab and
>>>>>>>> /etc/mactable are more or less obsolete by now.
>>>>>>>>
>>>>>>>> udev already works in the correct way when assigning the interface
>>>>>>>> names, without the 'workaround' I made in the network script to get
>>>>>>> the
>>>>>>>> interface names right. So if nobody really needs the changes we made
>>>>>>>> for working with /etc/mactab, /etc/mactable, we could roolback these
>>>>>>>> changes.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Stefan
>>>>>>>>
>>>>>>>> On 08/22/2010 07:56 AM, Serge Leschinsky wrote:
>>>>>>>>> Hi guys,
>>>>>>>>>
>>>>>>>>> DL system has been retired recently and I found that the problem
>>>>>>> with
>>>>>>>>> MAC-interface name association was solved a bit differently.
>>>>>>> Probably
>>>>>>>>> I missed something  - in this case I'm sorry in advance.
>>>>>>>>>
>>>>>>>>> The solution is based on udev rule (70-persistent-net.rules). The
>>>>>>> file
>>>>>>>>> below is a simple concatenation of 70-persistent-net.rules from 3
>>>>>>>>> different DL systems, and I was able to copy configuration tarball
>>>>>>>>> between systems without problem with network interface renaming.
>>>>>>>> Is it the same what you wish to get?
>>>>>>>>>
>>>>>>>>> # cat /etc/udev/rules.d/70-persistent-net.rules
>>>>>>>>> # This file was automatically generated by the
>>>>>>>>> /lib/udev/write_net_rules # program, run by the persistent-net-
>>>>>>>> generator.rules rules file.
>>>>>>>>> #
>>>>>>>>> # You can modify it, as long as you keep each rule on a single #
>>>>>>> line,
>>>>>>>>> and change only the value of the NAME= key.
>>>>>>>>>
>>>>>>>>> # PCI device 0x10ec:0x8169 (r8169)
>>>>>>>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>>>>>>>>> ATTR{address}=="00:14:d1:16:ab:c5", ATTR{type}=="1",
>>>>>>>> KERNEL=="eth*", NAME="eth0"
>>>>>>>>> # PCI device 0x10ec:0x8139 (8139too) SUBSYSTEM=="net",
>>>>>>>>> ACTION=="add", DRIVERS=="?*",
>>>>>>> ATTR{address}=="00:0a:e6:88:8f:4d",
>>>>>>>>> ATTR{type}=="1",
>>>>>>>> KERNEL=="eth*", NAME="eth1"
>>>>>>>>> # PCI device 0x10ec:0x8169 (r8169)
>>>>>>>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>>>>>>>>> ATTR{address}=="00:14:d1:16:a8:cc", ATTR{type}=="1",
>>>>>>>> KERNEL=="eth*", NAME="eth1"
>>>>>>>>> # PCI device 0x10ec:0x8139 (8139too) SUBSYSTEM=="net",
>>>>>>>>> ACTION=="add", DRIVERS=="?*",
>>>>>>> ATTR{address}=="00:0d:87:26:33:9e",
>>>>>>>>> ATTR{type}=="1",
>>>>>>>> KERNEL=="eth*", NAME="eth0"
>>>>>>>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>>>>>>>>> ATTR{address}=="00:23:4d:0b:87:b2", ATTR{type}=="1",
>>>>>>>> KERNEL=="eth*", NAME="wlan0"
>>>>>>>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>>>>>>>>> ATTR{address}=="00:21:70:bc:07:76", ATTR{type}=="1",
>>>>>>>> KERNEL=="eth*", NAME="eth0"
>>>>>>>>> # PCI device 0x8086:0x10f5 (e1000e)
>>>>>>>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>>>>>>>>> ATTR{address}=="00:22:68:13:c2:3b", ATTR{type}=="1",
>>>>>>>> KERNEL=="eth*", NAME="eth1"
>>>>>>>>> # PCI device 0x8086:0x4237 (iwlagn)
>>>>>>>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>>>>>>>>> ATTR{address}=="00:1e:65:6b:22:64", ATTR{type}=="1",
>>>>>>>> KERNEL=="wlan*", NAME="wlan1"
>>>>>>>>>
>>>>>>>>> Serge
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 06/18/2010 09:13 AM, Stefan Engel wrote:
>>>>>>>>>> Sorry for the late reply, holiday and work kept me busy.
>>>>>>>>>>
>>>>>>>>>> I have seen the bug #73 is resolved and the network script is now
>>>>>>>>>> available in the latest CVS snapshot. I am about to build my own
>>>>>>>>>> devil distro sometime during the next days. So far the script
>>>>>> looks
>>>>>>>>>> ok and should work as intended.
>>>>>>>>>>
>>>>>>>>>> Thanks for all helping to get this task done.
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Stefan
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 05/25/2010 03:29 AM, Stephen H F Ralph wrote:
>>>>>>>>>>> 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...>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> --------------------------------------------------------------------
>>>>>>>>>>> ----------
>>>>>>>>>
>>>>>>> ----------------------------------------------------------------------
>>>>>>>>> --------
>>>>>>>>> This SF.net email is sponsored by
>>>>>>>>>
>>>>>>>>> Make an app they can't live without
>>>>>>>>> Enter the BlackBerry Developer Challenge
>>>>>>>>> http://p.sf.net/sfu/RIM-dev2dev
>>>>>>>>> _______________________________________________
>>>>>>>>> Devil-linux-develop mailing list
>>>>>>>>> Dev...@li...
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> ------------------------------------------------------------------------
>>>>>>> ------
>>>>>>>> This SF.net email is sponsored by
>>>>>>>>
>>>>>>>> Make an app they can't live without
>>>>>>>> Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-
>>>>>>>> dev2dev _______________________________________________
>>>>>>>> Devil-linux-develop mailing list
>>>>>>>> Dev...@li...
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>>>>>>
>>>>>>>
>>>>>> ------------------------------------------------------------------------
>>>>>> ------
>>>>>>> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
>>>>>>> Be part of this innovative community and reach millions of netbook
>>>>>> users
>>>>>>> worldwide. Take advantage of special opportunities to increase revenue
>>>>>>> and speed time-to-market. Join now, and jumpstart your future.
>>>>>>> http://p.sf.net/sfu/intel-atom-d2d
>>>>>>> _______________________________________________
>>>>>>> Devil-linux-develop mailing list
>>>>>>> Dev...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
>>>>>> Be part of this innovative community and reach millions of netbook users
>>>>>> worldwide. Take advantage of special opportunities to increase revenue and
>>>>>> speed time-to-market. Join now, and jumpstart your future.
>>>>>> http://p.sf.net/sfu/intel-atom-d2d
>>>>>> _______________________________________________
>>>>>> Devil-linux-develop mailing list
>>>>>> Dev...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>>>> ------------------------------------------------------------------------------
>>>>> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
>>>>> Be part of this innovative community and reach millions of netbook users
>>>>> worldwide. Take advantage of special opportunities to increase revenue and
>>>>> speed time-to-market. Join now, and jumpstart your future.
>>>>> http://p.sf.net/sfu/intel-atom-d2d
>>>>> _______________________________________________
>>>>> Devil-linux-develop mailing list
>>>>> Dev...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>>>>
>>>>
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> This SF.net Dev2Dev email is sponsored by:
>>>
>>> Show off your parallel programming skills.
>>> Enter the Intel(R) Threading Challenge 2010.
>>> http://p.sf.net/sfu/intel-thread-sfd
>>> _______________________________________________
>>> Devil-linux-develop mailing list
>>> Dev...@li...
>>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net Dev2Dev email is sponsored by:
>>
>> Show off your parallel programming skills.
>> Enter the Intel(R) Threading Challenge 2010.
>> http://p.sf.net/sfu/intel-thread-sfd
>> _______________________________________________
>> Devil-linux-develop mailing list
>> Dev...@li...
>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>
>
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop

Dominic,

may I ask you to reopen the FR#70 and upload the patch against the latest
version of network script?

Serge

On 08/31/2010 07:28 AM, Dominic Raferd wrote:
>   Serge:
> 
> Exactly so. I think this 'network redetect' works easily if there is one 
> network device (option 'r'). With more than one, and if the order 
> (eth0/eth1) matters, the user configures 70-persistent-net.rules 
> manually and then uses 'network redetect' with option 'k' to restart 
> networking; it makes life easier in this situation too. I haven't been 
> able to test it with wireless lan devices, though.
> 
> BTW I see the existing network script has a never-executed call at the 
> end to a non-existent /etc/init.d/wlan.
> 
> Dominic
> 
> On 30/08/2010 21:50, Serge Leschinsky wrote:
>> Heiko, Dominic,
>>
>>
>> as far as I can see this feature is opposite to concatenation of
>> 70-persistent-net.rules, and in essence it's a way to clean this file up from
>> "outdated" records without reboot. For me it's "nice to have".
>>
>>
>> Serge
>>
>>
>>
>> On 08/30/2010 08:33 AM, Heiko Zuerker wrote:
>>> Does anybody have an opinion on this?
>>>
>>> Heiko
>>>
>>> Quoting Dominic Raferd<dl...@ed...>:
>>>
>>>> Back in April I submitted to Mantis some code for the
>>>> /etc/init.d/network script which added a new 'redetect' options to allow
>>>> redetection of changed network hardware
>>>> https://sourceforge.net/apps/mantisbt/devil-linux/view.php?id=70. This
>>>> was felt to be unnecessary because of the introduction of mactab, but it
>>>> might be worth reconsidering if we are now removing mactab.
>>>>
>>>> Dominic
>>>>
>>>> Here's the help info for it:
>>>>
>>>> 'network redetect' will disrupt any existing network connection and may
>>>> leave it broken. It is intended for use from a local terminal and in
>>>> cases where network hardware has changed and needs to be reconfigured to
>>>> work properly. Or (with 'k' option) where
>>>> /etc/udev/rules.d/70-persistent-net.rules file has been changed
>>>> manually, and the network needs to be restarted to reflect the changes.
>>>> If pre-existing network hardware is working, but additional new network
>>>> hardware is not, 'network redetect' is probably not the right tool -
>>>> instead, configure the new hardware from the NET section of 'setup'.
>>>>
>>>> Usually you first run with option 'r', this stops the network, removes
>>>> any prior information about network devices stored at
>>>> /etc/udev/rules.d/70-persistent-net.rules, redetects network devices,
>>>> recreates this file and then attempts to restart the network. To restart
>>>> the network it needs a network module; if you choose the 'autoselect'
>>>> option when and if requested, it will override any existing module set
>>>> by 'setup' at /etc/sysconfig/nic/ifcfg-ethn and use the module suggested
>>>> by udev.
>>>>
>>>> If this fails, reconfigure /etc/udev/rules.d/70-persistent-net.rules
>>>> manually (for instance, switching the allocation of device NAMEs between
>>>> eth0 and eth1) and then rerun 'network redetect' with the 'k' option.
>>>>
>>>> If you still have problems, check settings for the network device
>>>> (including module) using 'setup'. When you have an operational network,
>>>> save your changes with 'save-config -q'.
>>>>
>>>>> Heiko
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Heiko Zuerker [mailto:he...@zu...]
>>>>>> Sent: Saturday, August 28, 2010 8:06 AM
>>>>>> To: dev...@li...
>>>>>> Subject: Re: [Devil-linux-develop] Enable "nameif" to associate MAC
>>>>>> address with correct interface name
>>>>>>
>>>>>> Yes I agree, let's take it back out.
>>>>>>
>>>>>> Heiko
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Stefan Engel [mailto:ma...@en...]
>>>>>>> Sent: Monday, August 23, 2010 4:12 AM
>>>>>>> To: dev...@li...
>>>>>>> Subject: Re: [Devil-linux-develop] Enable "nameif" to associate MAC
>>>>>>> address with correct interface name
>>>>>>>
>>>>>>> Hi Serge,
>>>>>>>
>>>>>>> I just tested my config with
>>>>> /etc/udev/rules.d/70-persistent-net.rules
>>>>>>> with two VMs and it's working without problems. This solution looks
>>>>>> like
>>>>>>> the more elegant way to assign interface names to mac addresses.
>>>>>>>
>>>>>>> Seems that the changes we made for dealing with /etc/mactab and
>>>>>>> /etc/mactable are more or less obsolete by now.
>>>>>>>
>>>>>>> udev already works in the correct way when assigning the interface
>>>>>>> names, without the 'workaround' I made in the network script to get
>>>>>> the
>>>>>>> interface names right. So if nobody really needs the changes we made
>>>>>>> for working with /etc/mactab, /etc/mactable, we could roolback these
>>>>>>> changes.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Stefan
>>>>>>>
>>>>>>> On 08/22/2010 07:56 AM, Serge Leschinsky wrote:
>>>>>>>> Hi guys,
>>>>>>>>
>>>>>>>> DL system has been retired recently and I found that the problem
>>>>>> with
>>>>>>>> MAC-interface name association was solved a bit differently.
>>>>>> Probably
>>>>>>>> I missed something  - in this case I'm sorry in advance.
>>>>>>>>
>>>>>>>> The solution is based on udev rule (70-persistent-net.rules). The
>>>>>> file
>>>>>>>> below is a simple concatenation of 70-persistent-net.rules from 3
>>>>>>>> different DL systems, and I was able to copy configuration tarball
>>>>>>>> between systems without problem with network interface renaming.
>>>>>>> Is it the same what you wish to get?
>>>>>>>>
>>>>>>>> # cat /etc/udev/rules.d/70-persistent-net.rules
>>>>>>>> # This file was automatically generated by the
>>>>>>>> /lib/udev/write_net_rules # program, run by the persistent-net-
>>>>>>> generator.rules rules file.
>>>>>>>> #
>>>>>>>> # You can modify it, as long as you keep each rule on a single #
>>>>>> line,
>>>>>>>> and change only the value of the NAME= key.
>>>>>>>>
>>>>>>>> # PCI device 0x10ec:0x8169 (r8169)
>>>>>>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>>>>>>>> ATTR{address}=="00:14:d1:16:ab:c5", ATTR{type}=="1",
>>>>>>> KERNEL=="eth*", NAME="eth0"
>>>>>>>> # PCI device 0x10ec:0x8139 (8139too) SUBSYSTEM=="net",
>>>>>>>> ACTION=="add", DRIVERS=="?*",
>>>>>> ATTR{address}=="00:0a:e6:88:8f:4d",
>>>>>>>> ATTR{type}=="1",
>>>>>>> KERNEL=="eth*", NAME="eth1"
>>>>>>>> # PCI device 0x10ec:0x8169 (r8169)
>>>>>>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>>>>>>>> ATTR{address}=="00:14:d1:16:a8:cc", ATTR{type}=="1",
>>>>>>> KERNEL=="eth*", NAME="eth1"
>>>>>>>> # PCI device 0x10ec:0x8139 (8139too) SUBSYSTEM=="net",
>>>>>>>> ACTION=="add", DRIVERS=="?*",
>>>>>> ATTR{address}=="00:0d:87:26:33:9e",
>>>>>>>> ATTR{type}=="1",
>>>>>>> KERNEL=="eth*", NAME="eth0"
>>>>>>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>>>>>>>> ATTR{address}=="00:23:4d:0b:87:b2", ATTR{type}=="1",
>>>>>>> KERNEL=="eth*", NAME="wlan0"
>>>>>>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>>>>>>>> ATTR{address}=="00:21:70:bc:07:76", ATTR{type}=="1",
>>>>>>> KERNEL=="eth*", NAME="eth0"
>>>>>>>> # PCI device 0x8086:0x10f5 (e1000e)
>>>>>>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>>>>>>>> ATTR{address}=="00:22:68:13:c2:3b", ATTR{type}=="1",
>>>>>>> KERNEL=="eth*", NAME="eth1"
>>>>>>>> # PCI device 0x8086:0x4237 (iwlagn)
>>>>>>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>>>>>>>> ATTR{address}=="00:1e:65:6b:22:64", ATTR{type}=="1",
>>>>>>> KERNEL=="wlan*", NAME="wlan1"
>>>>>>>>
>>>>>>>> Serge
>>>>>>>>
>>>>>>>>
>>>>>>>> On 06/18/2010 09:13 AM, Stefan Engel wrote:
>>>>>>>>> Sorry for the late reply, holiday and work kept me busy.
>>>>>>>>>
>>>>>>>>> I have seen the bug #73 is resolved and the network script is now
>>>>>>>>> available in the latest CVS snapshot. I am about to build my own
>>>>>>>>> devil distro sometime during the next days. So far the script
>>>>> looks
>>>>>>>>> ok and should work as intended.
>>>>>>>>>
>>>>>>>>> Thanks for all helping to get this task done.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Stefan
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 05/25/2010 03:29 AM, Stephen H F Ralph wrote:
>>>>>>>>>> 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...>
>>>>>>>>>>
>>>>>>>>>>
>>>>>> --------------------------------------------------------------------
>>>>>>>>>> ----------
>>>>>>>>
>>>>>> ----------------------------------------------------------------------
>>>>>>>> --------
>>>>>>>> This SF.net email is sponsored by
>>>>>>>>
>>>>>>>> Make an app they can't live without
>>>>>>>> Enter the BlackBerry Developer Challenge
>>>>>>>> http://p.sf.net/sfu/RIM-dev2dev
>>>>>>>> _______________________________________________
>>>>>>>> Devil-linux-develop mailing list
>>>>>>>> Dev...@li...
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>> ------
>>>>>>> This SF.net email is sponsored by
>>>>>>>
>>>>>>> Make an app they can't live without
>>>>>>> Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-
>>>>>>> dev2dev _______________________________________________
>>>>>>> Devil-linux-develop mailing list
>>>>>>> Dev...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>>>>>
>>>>>>
>>>>> ------------------------------------------------------------------------
>>>>> ------
>>>>>> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
>>>>>> Be part of this innovative community and reach millions of netbook
>>>>> users
>>>>>> worldwide. Take advantage of special opportunities to increase revenue
>>>>>> and speed time-to-market. Join now, and jumpstart your future.
>>>>>> http://p.sf.net/sfu/intel-atom-d2d
>>>>>> _______________________________________________
>>>>>> Devil-linux-develop mailing list
>>>>>> Dev...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
>>>>> Be part of this innovative community and reach millions of netbook users
>>>>> worldwide. Take advantage of special opportunities to increase revenue and
>>>>> speed time-to-market. Join now, and jumpstart your future.
>>>>> http://p.sf.net/sfu/intel-atom-d2d
>>>>> _______________________________________________
>>>>> Devil-linux-develop mailing list
>>>>> Dev...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>>> ------------------------------------------------------------------------------
>>>> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
>>>> Be part of this innovative community and reach millions of netbook users
>>>> worldwide. Take advantage of special opportunities to increase revenue and
>>>> speed time-to-market. Join now, and jumpstart your future.
>>>> http://p.sf.net/sfu/intel-atom-d2d
>>>> _______________________________________________
>>>> Devil-linux-develop mailing list
>>>> Dev...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>>>
>>>
>>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net Dev2Dev email is sponsored by:
>>
>> Show off your parallel programming skills.
>> Enter the Intel(R) Threading Challenge 2010.
>> http://p.sf.net/sfu/intel-thread-sfd
>> _______________________________________________
>> Devil-linux-develop mailing list
>> Dev...@li...
>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>
> 
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
> 
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
> 

Forget the last reply. It was meant for Heiko's mail regarding "Possible
to build util-linux earlier?".

Regards,
Stefan

On 09/01/2010 09:21 PM, Stefan Engel wrote:
> Thanks, then I can now remove one more patch from my setup.
> 
> Regards,
> Stefan
> 
> On 08/31/2010 04:28 PM, Dominic Raferd wrote:
>>   Serge:
>>
>> Exactly so. I think this 'network redetect' works easily if there is one 
>> network device (option 'r'). With more than one, and if the order 
>> (eth0/eth1) matters, the user configures 70-persistent-net.rules 
>> manually and then uses 'network redetect' with option 'k' to restart 
>> networking; it makes life easier in this situation too. I haven't been 
>> able to test it with wireless lan devices, though.
>>
>> BTW I see the existing network script has a never-executed call at the 
>> end to a non-existent /etc/init.d/wlan.
>>
>> Dominic
>>
>> On 30/08/2010 21:50, Serge Leschinsky wrote:
>>> Heiko, Dominic,
>>>
>>>
>>> as far as I can see this feature is opposite to concatenation of
>>> 70-persistent-net.rules, and in essence it's a way to clean this file up from
>>> "outdated" records without reboot. For me it's "nice to have".
>>>
>>>
>>> Serge
>>>
>>>
>>>
>>> On 08/30/2010 08:33 AM, Heiko Zuerker wrote:
>>>> Does anybody have an opinion on this?
>>>>
>>>> Heiko
>>>>
>>>> Quoting Dominic Raferd<dl...@ed...>:
>>>>
>>>>> Back in April I submitted to Mantis some code for the
>>>>> /etc/init.d/network script which added a new 'redetect' options to allow
>>>>> redetection of changed network hardware
>>>>> https://sourceforge.net/apps/mantisbt/devil-linux/view.php?id=70. This
>>>>> was felt to be unnecessary because of the introduction of mactab, but it
>>>>> might be worth reconsidering if we are now removing mactab.
>>>>>
>>>>> Dominic
>>>>>
>>>>> Here's the help info for it:
>>>>>
>>>>> 'network redetect' will disrupt any existing network connection and may
>>>>> leave it broken. It is intended for use from a local terminal and in
>>>>> cases where network hardware has changed and needs to be reconfigured to
>>>>> work properly. Or (with 'k' option) where
>>>>> /etc/udev/rules.d/70-persistent-net.rules file has been changed
>>>>> manually, and the network needs to be restarted to reflect the changes.
>>>>> If pre-existing network hardware is working, but additional new network
>>>>> hardware is not, 'network redetect' is probably not the right tool -
>>>>> instead, configure the new hardware from the NET section of 'setup'.
>>>>>
>>>>> Usually you first run with option 'r', this stops the network, removes
>>>>> any prior information about network devices stored at
>>>>> /etc/udev/rules.d/70-persistent-net.rules, redetects network devices,
>>>>> recreates this file and then attempts to restart the network. To restart
>>>>> the network it needs a network module; if you choose the 'autoselect'
>>>>> option when and if requested, it will override any existing module set
>>>>> by 'setup' at /etc/sysconfig/nic/ifcfg-ethn and use the module suggested
>>>>> by udev.
>>>>>
>>>>> If this fails, reconfigure /etc/udev/rules.d/70-persistent-net.rules
>>>>> manually (for instance, switching the allocation of device NAMEs between
>>>>> eth0 and eth1) and then rerun 'network redetect' with the 'k' option.
>>>>>
>>>>> If you still have problems, check settings for the network device
>>>>> (including module) using 'setup'. When you have an operational network,
>>>>> save your changes with 'save-config -q'.
>>>>>
>>>>>> Heiko
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Heiko Zuerker [mailto:he...@zu...]
>>>>>>> Sent: Saturday, August 28, 2010 8:06 AM
>>>>>>> To: dev...@li...
>>>>>>> Subject: Re: [Devil-linux-develop] Enable "nameif" to associate MAC
>>>>>>> address with correct interface name
>>>>>>>
>>>>>>> Yes I agree, let's take it back out.
>>>>>>>
>>>>>>> Heiko
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Stefan Engel [mailto:ma...@en...]
>>>>>>>> Sent: Monday, August 23, 2010 4:12 AM
>>>>>>>> To: dev...@li...
>>>>>>>> Subject: Re: [Devil-linux-develop] Enable "nameif" to associate MAC
>>>>>>>> address with correct interface name
>>>>>>>>
>>>>>>>> Hi Serge,
>>>>>>>>
>>>>>>>> I just tested my config with
>>>>>> /etc/udev/rules.d/70-persistent-net.rules
>>>>>>>> with two VMs and it's working without problems. This solution looks
>>>>>>> like
>>>>>>>> the more elegant way to assign interface names to mac addresses.
>>>>>>>>
>>>>>>>> Seems that the changes we made for dealing with /etc/mactab and
>>>>>>>> /etc/mactable are more or less obsolete by now.
>>>>>>>>
>>>>>>>> udev already works in the correct way when assigning the interface
>>>>>>>> names, without the 'workaround' I made in the network script to get
>>>>>>> the
>>>>>>>> interface names right. So if nobody really needs the changes we made
>>>>>>>> for working with /etc/mactab, /etc/mactable, we could roolback these
>>>>>>>> changes.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Stefan
>>>>>>>>
>>>>>>>> On 08/22/2010 07:56 AM, Serge Leschinsky wrote:
>>>>>>>>> Hi guys,
>>>>>>>>>
>>>>>>>>> DL system has been retired recently and I found that the problem
>>>>>>> with
>>>>>>>>> MAC-interface name association was solved a bit differently.
>>>>>>> Probably
>>>>>>>>> I missed something  - in this case I'm sorry in advance.
>>>>>>>>>
>>>>>>>>> The solution is based on udev rule (70-persistent-net.rules). The
>>>>>>> file
>>>>>>>>> below is a simple concatenation of 70-persistent-net.rules from 3
>>>>>>>>> different DL systems, and I was able to copy configuration tarball
>>>>>>>>> between systems without problem with network interface renaming.
>>>>>>>> Is it the same what you wish to get?
>>>>>>>>>
>>>>>>>>> # cat /etc/udev/rules.d/70-persistent-net.rules
>>>>>>>>> # This file was automatically generated by the
>>>>>>>>> /lib/udev/write_net_rules # program, run by the persistent-net-
>>>>>>>> generator.rules rules file.
>>>>>>>>> #
>>>>>>>>> # You can modify it, as long as you keep each rule on a single #
>>>>>>> line,
>>>>>>>>> and change only the value of the NAME= key.
>>>>>>>>>
>>>>>>>>> # PCI device 0x10ec:0x8169 (r8169)
>>>>>>>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>>>>>>>>> ATTR{address}=="00:14:d1:16:ab:c5", ATTR{type}=="1",
>>>>>>>> KERNEL=="eth*", NAME="eth0"
>>>>>>>>> # PCI device 0x10ec:0x8139 (8139too) SUBSYSTEM=="net",
>>>>>>>>> ACTION=="add", DRIVERS=="?*",
>>>>>>> ATTR{address}=="00:0a:e6:88:8f:4d",
>>>>>>>>> ATTR{type}=="1",
>>>>>>>> KERNEL=="eth*", NAME="eth1"
>>>>>>>>> # PCI device 0x10ec:0x8169 (r8169)
>>>>>>>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>>>>>>>>> ATTR{address}=="00:14:d1:16:a8:cc", ATTR{type}=="1",
>>>>>>>> KERNEL=="eth*", NAME="eth1"
>>>>>>>>> # PCI device 0x10ec:0x8139 (8139too) SUBSYSTEM=="net",
>>>>>>>>> ACTION=="add", DRIVERS=="?*",
>>>>>>> ATTR{address}=="00:0d:87:26:33:9e",
>>>>>>>>> ATTR{type}=="1",
>>>>>>>> KERNEL=="eth*", NAME="eth0"
>>>>>>>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>>>>>>>>> ATTR{address}=="00:23:4d:0b:87:b2", ATTR{type}=="1",
>>>>>>>> KERNEL=="eth*", NAME="wlan0"
>>>>>>>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>>>>>>>>> ATTR{address}=="00:21:70:bc:07:76", ATTR{type}=="1",
>>>>>>>> KERNEL=="eth*", NAME="eth0"
>>>>>>>>> # PCI device 0x8086:0x10f5 (e1000e)
>>>>>>>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>>>>>>>>> ATTR{address}=="00:22:68:13:c2:3b", ATTR{type}=="1",
>>>>>>>> KERNEL=="eth*", NAME="eth1"
>>>>>>>>> # PCI device 0x8086:0x4237 (iwlagn)
>>>>>>>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>>>>>>>>> ATTR{address}=="00:1e:65:6b:22:64", ATTR{type}=="1",
>>>>>>>> KERNEL=="wlan*", NAME="wlan1"
>>>>>>>>>
>>>>>>>>> Serge
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 06/18/2010 09:13 AM, Stefan Engel wrote:
>>>>>>>>>> Sorry for the late reply, holiday and work kept me busy.
>>>>>>>>>>
>>>>>>>>>> I have seen the bug #73 is resolved and the network script is now
>>>>>>>>>> available in the latest CVS snapshot. I am about to build my own
>>>>>>>>>> devil distro sometime during the next days. So far the script
>>>>>> looks
>>>>>>>>>> ok and should work as intended.
>>>>>>>>>>
>>>>>>>>>> Thanks for all helping to get this task done.
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Stefan
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 05/25/2010 03:29 AM, Stephen H F Ralph wrote:
>>>>>>>>>>> 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...>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> --------------------------------------------------------------------
>>>>>>>>>>> ----------
>>>>>>>>>
>>>>>>> ----------------------------------------------------------------------
>>>>>>>>> --------
>>>>>>>>> This SF.net email is sponsored by
>>>>>>>>>
>>>>>>>>> Make an app they can't live without
>>>>>>>>> Enter the BlackBerry Developer Challenge
>>>>>>>>> http://p.sf.net/sfu/RIM-dev2dev
>>>>>>>>> _______________________________________________
>>>>>>>>> Devil-linux-develop mailing list
>>>>>>>>> Dev...@li...
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> ------------------------------------------------------------------------
>>>>>>> ------
>>>>>>>> This SF.net email is sponsored by
>>>>>>>>
>>>>>>>> Make an app they can't live without
>>>>>>>> Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-
>>>>>>>> dev2dev _______________________________________________
>>>>>>>> Devil-linux-develop mailing list
>>>>>>>> Dev...@li...
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>>>>>>
>>>>>>>
>>>>>> ------------------------------------------------------------------------
>>>>>> ------
>>>>>>> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
>>>>>>> Be part of this innovative community and reach millions of netbook
>>>>>> users
>>>>>>> worldwide. Take advantage of special opportunities to increase revenue
>>>>>>> and speed time-to-market. Join now, and jumpstart your future.
>>>>>>> http://p.sf.net/sfu/intel-atom-d2d
>>>>>>> _______________________________________________
>>>>>>> Devil-linux-develop mailing list
>>>>>>> Dev...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
>>>>>> Be part of this innovative community and reach millions of netbook users
>>>>>> worldwide. Take advantage of special opportunities to increase revenue and
>>>>>> speed time-to-market. Join now, and jumpstart your future.
>>>>>> http://p.sf.net/sfu/intel-atom-d2d
>>>>>> _______________________________________________
>>>>>> Devil-linux-develop mailing list
>>>>>> Dev...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>>>> ------------------------------------------------------------------------------
>>>>> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
>>>>> Be part of this innovative community and reach millions of netbook users
>>>>> worldwide. Take advantage of special opportunities to increase revenue and
>>>>> speed time-to-market. Join now, and jumpstart your future.
>>>>> http://p.sf.net/sfu/intel-atom-d2d
>>>>> _______________________________________________
>>>>> Devil-linux-develop mailing list
>>>>> Dev...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>>>>
>>>>
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> This SF.net Dev2Dev email is sponsored by:
>>>
>>> Show off your parallel programming skills.
>>> Enter the Intel(R) Threading Challenge 2010.
>>> http://p.sf.net/sfu/intel-thread-sfd
>>> _______________________________________________
>>> Devil-linux-develop mailing list
>>> Dev...@li...
>>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net Dev2Dev email is sponsored by:
>>
>> Show off your parallel programming skills.
>> Enter the Intel(R) Threading Challenge 2010.
>> http://p.sf.net/sfu/intel-thread-sfd
>> _______________________________________________
>> Devil-linux-develop mailing list
>> Dev...@li...
>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>
>>
> 
> 
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
> 
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
> 
> 

Thanks, then I can now remove one more patch from my setup.

Regards,
Stefan

On 08/31/2010 04:28 PM, Dominic Raferd wrote:
>   Serge:
> 
> Exactly so. I think this 'network redetect' works easily if there is one 
> network device (option 'r'). With more than one, and if the order 
> (eth0/eth1) matters, the user configures 70-persistent-net.rules 
> manually and then uses 'network redetect' with option 'k' to restart 
> networking; it makes life easier in this situation too. I haven't been 
> able to test it with wireless lan devices, though.
> 
> BTW I see the existing network script has a never-executed call at the 
> end to a non-existent /etc/init.d/wlan.
> 
> Dominic
> 
> On 30/08/2010 21:50, Serge Leschinsky wrote:
>> Heiko, Dominic,
>>
>>
>> as far as I can see this feature is opposite to concatenation of
>> 70-persistent-net.rules, and in essence it's a way to clean this file up from
>> "outdated" records without reboot. For me it's "nice to have".
>>
>>
>> Serge
>>
>>
>>
>> On 08/30/2010 08:33 AM, Heiko Zuerker wrote:
>>> Does anybody have an opinion on this?
>>>
>>> Heiko
>>>
>>> Quoting Dominic Raferd<dl...@ed...>:
>>>
>>>> Back in April I submitted to Mantis some code for the
>>>> /etc/init.d/network script which added a new 'redetect' options to allow
>>>> redetection of changed network hardware
>>>> https://sourceforge.net/apps/mantisbt/devil-linux/view.php?id=70. This
>>>> was felt to be unnecessary because of the introduction of mactab, but it
>>>> might be worth reconsidering if we are now removing mactab.
>>>>
>>>> Dominic
>>>>
>>>> Here's the help info for it:
>>>>
>>>> 'network redetect' will disrupt any existing network connection and may
>>>> leave it broken. It is intended for use from a local terminal and in
>>>> cases where network hardware has changed and needs to be reconfigured to
>>>> work properly. Or (with 'k' option) where
>>>> /etc/udev/rules.d/70-persistent-net.rules file has been changed
>>>> manually, and the network needs to be restarted to reflect the changes.
>>>> If pre-existing network hardware is working, but additional new network
>>>> hardware is not, 'network redetect' is probably not the right tool -
>>>> instead, configure the new hardware from the NET section of 'setup'.
>>>>
>>>> Usually you first run with option 'r', this stops the network, removes
>>>> any prior information about network devices stored at
>>>> /etc/udev/rules.d/70-persistent-net.rules, redetects network devices,
>>>> recreates this file and then attempts to restart the network. To restart
>>>> the network it needs a network module; if you choose the 'autoselect'
>>>> option when and if requested, it will override any existing module set
>>>> by 'setup' at /etc/sysconfig/nic/ifcfg-ethn and use the module suggested
>>>> by udev.
>>>>
>>>> If this fails, reconfigure /etc/udev/rules.d/70-persistent-net.rules
>>>> manually (for instance, switching the allocation of device NAMEs between
>>>> eth0 and eth1) and then rerun 'network redetect' with the 'k' option.
>>>>
>>>> If you still have problems, check settings for the network device
>>>> (including module) using 'setup'. When you have an operational network,
>>>> save your changes with 'save-config -q'.
>>>>
>>>>> Heiko
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Heiko Zuerker [mailto:he...@zu...]
>>>>>> Sent: Saturday, August 28, 2010 8:06 AM
>>>>>> To: dev...@li...
>>>>>> Subject: Re: [Devil-linux-develop] Enable "nameif" to associate MAC
>>>>>> address with correct interface name
>>>>>>
>>>>>> Yes I agree, let's take it back out.
>>>>>>
>>>>>> Heiko
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Stefan Engel [mailto:ma...@en...]
>>>>>>> Sent: Monday, August 23, 2010 4:12 AM
>>>>>>> To: dev...@li...
>>>>>>> Subject: Re: [Devil-linux-develop] Enable "nameif" to associate MAC
>>>>>>> address with correct interface name
>>>>>>>
>>>>>>> Hi Serge,
>>>>>>>
>>>>>>> I just tested my config with
>>>>> /etc/udev/rules.d/70-persistent-net.rules
>>>>>>> with two VMs and it's working without problems. This solution looks
>>>>>> like
>>>>>>> the more elegant way to assign interface names to mac addresses.
>>>>>>>
>>>>>>> Seems that the changes we made for dealing with /etc/mactab and
>>>>>>> /etc/mactable are more or less obsolete by now.
>>>>>>>
>>>>>>> udev already works in the correct way when assigning the interface
>>>>>>> names, without the 'workaround' I made in the network script to get
>>>>>> the
>>>>>>> interface names right. So if nobody really needs the changes we made
>>>>>>> for working with /etc/mactab, /etc/mactable, we could roolback these
>>>>>>> changes.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Stefan
>>>>>>>
>>>>>>> On 08/22/2010 07:56 AM, Serge Leschinsky wrote:
>>>>>>>> Hi guys,
>>>>>>>>
>>>>>>>> DL system has been retired recently and I found that the problem
>>>>>> with
>>>>>>>> MAC-interface name association was solved a bit differently.
>>>>>> Probably
>>>>>>>> I missed something  - in this case I'm sorry in advance.
>>>>>>>>
>>>>>>>> The solution is based on udev rule (70-persistent-net.rules). The
>>>>>> file
>>>>>>>> below is a simple concatenation of 70-persistent-net.rules from 3
>>>>>>>> different DL systems, and I was able to copy configuration tarball
>>>>>>>> between systems without problem with network interface renaming.
>>>>>>> Is it the same what you wish to get?
>>>>>>>>
>>>>>>>> # cat /etc/udev/rules.d/70-persistent-net.rules
>>>>>>>> # This file was automatically generated by the
>>>>>>>> /lib/udev/write_net_rules # program, run by the persistent-net-
>>>>>>> generator.rules rules file.
>>>>>>>> #
>>>>>>>> # You can modify it, as long as you keep each rule on a single #
>>>>>> line,
>>>>>>>> and change only the value of the NAME= key.
>>>>>>>>
>>>>>>>> # PCI device 0x10ec:0x8169 (r8169)
>>>>>>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>>>>>>>> ATTR{address}=="00:14:d1:16:ab:c5", ATTR{type}=="1",
>>>>>>> KERNEL=="eth*", NAME="eth0"
>>>>>>>> # PCI device 0x10ec:0x8139 (8139too) SUBSYSTEM=="net",
>>>>>>>> ACTION=="add", DRIVERS=="?*",
>>>>>> ATTR{address}=="00:0a:e6:88:8f:4d",
>>>>>>>> ATTR{type}=="1",
>>>>>>> KERNEL=="eth*", NAME="eth1"
>>>>>>>> # PCI device 0x10ec:0x8169 (r8169)
>>>>>>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>>>>>>>> ATTR{address}=="00:14:d1:16:a8:cc", ATTR{type}=="1",
>>>>>>> KERNEL=="eth*", NAME="eth1"
>>>>>>>> # PCI device 0x10ec:0x8139 (8139too) SUBSYSTEM=="net",
>>>>>>>> ACTION=="add", DRIVERS=="?*",
>>>>>> ATTR{address}=="00:0d:87:26:33:9e",
>>>>>>>> ATTR{type}=="1",
>>>>>>> KERNEL=="eth*", NAME="eth0"
>>>>>>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>>>>>>>> ATTR{address}=="00:23:4d:0b:87:b2", ATTR{type}=="1",
>>>>>>> KERNEL=="eth*", NAME="wlan0"
>>>>>>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>>>>>>>> ATTR{address}=="00:21:70:bc:07:76", ATTR{type}=="1",
>>>>>>> KERNEL=="eth*", NAME="eth0"
>>>>>>>> # PCI device 0x8086:0x10f5 (e1000e)
>>>>>>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>>>>>>>> ATTR{address}=="00:22:68:13:c2:3b", ATTR{type}=="1",
>>>>>>> KERNEL=="eth*", NAME="eth1"
>>>>>>>> # PCI device 0x8086:0x4237 (iwlagn)
>>>>>>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>>>>>>>> ATTR{address}=="00:1e:65:6b:22:64", ATTR{type}=="1",
>>>>>>> KERNEL=="wlan*", NAME="wlan1"
>>>>>>>>
>>>>>>>> Serge
>>>>>>>>
>>>>>>>>
>>>>>>>> On 06/18/2010 09:13 AM, Stefan Engel wrote:
>>>>>>>>> Sorry for the late reply, holiday and work kept me busy.
>>>>>>>>>
>>>>>>>>> I have seen the bug #73 is resolved and the network script is now
>>>>>>>>> available in the latest CVS snapshot. I am about to build my own
>>>>>>>>> devil distro sometime during the next days. So far the script
>>>>> looks
>>>>>>>>> ok and should work as intended.
>>>>>>>>>
>>>>>>>>> Thanks for all helping to get this task done.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Stefan
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 05/25/2010 03:29 AM, Stephen H F Ralph wrote:
>>>>>>>>>> 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...>
>>>>>>>>>>
>>>>>>>>>>
>>>>>> --------------------------------------------------------------------
>>>>>>>>>> ----------
>>>>>>>>
>>>>>> ----------------------------------------------------------------------
>>>>>>>> --------
>>>>>>>> This SF.net email is sponsored by
>>>>>>>>
>>>>>>>> Make an app they can't live without
>>>>>>>> Enter the BlackBerry Developer Challenge
>>>>>>>> http://p.sf.net/sfu/RIM-dev2dev
>>>>>>>> _______________________________________________
>>>>>>>> Devil-linux-develop mailing list
>>>>>>>> Dev...@li...
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>> ------
>>>>>>> This SF.net email is sponsored by
>>>>>>>
>>>>>>> Make an app they can't live without
>>>>>>> Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-
>>>>>>> dev2dev _______________________________________________
>>>>>>> Devil-linux-develop mailing list
>>>>>>> Dev...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>>>>>
>>>>>>
>>>>> ------------------------------------------------------------------------
>>>>> ------
>>>>>> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
>>>>>> Be part of this innovative community and reach millions of netbook
>>>>> users
>>>>>> worldwide. Take advantage of special opportunities to increase revenue
>>>>>> and speed time-to-market. Join now, and jumpstart your future.
>>>>>> http://p.sf.net/sfu/intel-atom-d2d
>>>>>> _______________________________________________
>>>>>> Devil-linux-develop mailing list
>>>>>> Dev...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
>>>>> Be part of this innovative community and reach millions of netbook users
>>>>> worldwide. Take advantage of special opportunities to increase revenue and
>>>>> speed time-to-market. Join now, and jumpstart your future.
>>>>> http://p.sf.net/sfu/intel-atom-d2d
>>>>> _______________________________________________
>>>>> Devil-linux-develop mailing list
>>>>> Dev...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>>> ------------------------------------------------------------------------------
>>>> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
>>>> Be part of this innovative community and reach millions of netbook users
>>>> worldwide. Take advantage of special opportunities to increase revenue and
>>>> speed time-to-market. Join now, and jumpstart your future.
>>>> http://p.sf.net/sfu/intel-atom-d2d
>>>> _______________________________________________
>>>> Devil-linux-develop mailing list
>>>> Dev...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>>>
>>>
>>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net Dev2Dev email is sponsored by:
>>
>> Show off your parallel programming skills.
>> Enter the Intel(R) Threading Challenge 2010.
>> http://p.sf.net/sfu/intel-thread-sfd
>> _______________________________________________
>> Devil-linux-develop mailing list
>> Dev...@li...
>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>
> 
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
> 
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
> 
> 

  Serge:

Exactly so. I think this 'network redetect' works easily if there is one 
network device (option 'r'). With more than one, and if the order 
(eth0/eth1) matters, the user configures 70-persistent-net.rules 
manually and then uses 'network redetect' with option 'k' to restart 
networking; it makes life easier in this situation too. I haven't been 
able to test it with wireless lan devices, though.

BTW I see the existing network script has a never-executed call at the 
end to a non-existent /etc/init.d/wlan.

Dominic

On 30/08/2010 21:50, Serge Leschinsky wrote:
> Heiko, Dominic,
>
>
> as far as I can see this feature is opposite to concatenation of
> 70-persistent-net.rules, and in essence it's a way to clean this file up from
> "outdated" records without reboot. For me it's "nice to have".
>
>
> Serge
>
>
>
> On 08/30/2010 08:33 AM, Heiko Zuerker wrote:
>> Does anybody have an opinion on this?
>>
>> Heiko
>>
>> Quoting Dominic Raferd<dl...@ed...>:
>>
>>> Back in April I submitted to Mantis some code for the
>>> /etc/init.d/network script which added a new 'redetect' options to allow
>>> redetection of changed network hardware
>>> https://sourceforge.net/apps/mantisbt/devil-linux/view.php?id=70. This
>>> was felt to be unnecessary because of the introduction of mactab, but it
>>> might be worth reconsidering if we are now removing mactab.
>>>
>>> Dominic
>>>
>>> Here's the help info for it:
>>>
>>> 'network redetect' will disrupt any existing network connection and may
>>> leave it broken. It is intended for use from a local terminal and in
>>> cases where network hardware has changed and needs to be reconfigured to
>>> work properly. Or (with 'k' option) where
>>> /etc/udev/rules.d/70-persistent-net.rules file has been changed
>>> manually, and the network needs to be restarted to reflect the changes.
>>> If pre-existing network hardware is working, but additional new network
>>> hardware is not, 'network redetect' is probably not the right tool -
>>> instead, configure the new hardware from the NET section of 'setup'.
>>>
>>> Usually you first run with option 'r', this stops the network, removes
>>> any prior information about network devices stored at
>>> /etc/udev/rules.d/70-persistent-net.rules, redetects network devices,
>>> recreates this file and then attempts to restart the network. To restart
>>> the network it needs a network module; if you choose the 'autoselect'
>>> option when and if requested, it will override any existing module set
>>> by 'setup' at /etc/sysconfig/nic/ifcfg-ethn and use the module suggested
>>> by udev.
>>>
>>> If this fails, reconfigure /etc/udev/rules.d/70-persistent-net.rules
>>> manually (for instance, switching the allocation of device NAMEs between
>>> eth0 and eth1) and then rerun 'network redetect' with the 'k' option.
>>>
>>> If you still have problems, check settings for the network device
>>> (including module) using 'setup'. When you have an operational network,
>>> save your changes with 'save-config -q'.
>>>
>>>> Heiko
>>>>
>>>>> -----Original Message-----
>>>>> From: Heiko Zuerker [mailto:he...@zu...]
>>>>> Sent: Saturday, August 28, 2010 8:06 AM
>>>>> To: dev...@li...
>>>>> Subject: Re: [Devil-linux-develop] Enable "nameif" to associate MAC
>>>>> address with correct interface name
>>>>>
>>>>> Yes I agree, let's take it back out.
>>>>>
>>>>> Heiko
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Stefan Engel [mailto:ma...@en...]
>>>>>> Sent: Monday, August 23, 2010 4:12 AM
>>>>>> To: dev...@li...
>>>>>> Subject: Re: [Devil-linux-develop] Enable "nameif" to associate MAC
>>>>>> address with correct interface name
>>>>>>
>>>>>> Hi Serge,
>>>>>>
>>>>>> I just tested my config with
>>>> /etc/udev/rules.d/70-persistent-net.rules
>>>>>> with two VMs and it's working without problems. This solution looks
>>>>> like
>>>>>> the more elegant way to assign interface names to mac addresses.
>>>>>>
>>>>>> Seems that the changes we made for dealing with /etc/mactab and
>>>>>> /etc/mactable are more or less obsolete by now.
>>>>>>
>>>>>> udev already works in the correct way when assigning the interface
>>>>>> names, without the 'workaround' I made in the network script to get
>>>>> the
>>>>>> interface names right. So if nobody really needs the changes we made
>>>>>> for working with /etc/mactab, /etc/mactable, we could roolback these
>>>>>> changes.
>>>>>>
>>>>>> Regards,
>>>>>> Stefan
>>>>>>
>>>>>> On 08/22/2010 07:56 AM, Serge Leschinsky wrote:
>>>>>>> Hi guys,
>>>>>>>
>>>>>>> DL system has been retired recently and I found that the problem
>>>>> with
>>>>>>> MAC-interface name association was solved a bit differently.
>>>>> Probably
>>>>>>> I missed something  - in this case I'm sorry in advance.
>>>>>>>
>>>>>>> The solution is based on udev rule (70-persistent-net.rules). The
>>>>> file
>>>>>>> below is a simple concatenation of 70-persistent-net.rules from 3
>>>>>>> different DL systems, and I was able to copy configuration tarball
>>>>>>> between systems without problem with network interface renaming.
>>>>>> Is it the same what you wish to get?
>>>>>>>
>>>>>>> # cat /etc/udev/rules.d/70-persistent-net.rules
>>>>>>> # This file was automatically generated by the
>>>>>>> /lib/udev/write_net_rules # program, run by the persistent-net-
>>>>>> generator.rules rules file.
>>>>>>> #
>>>>>>> # You can modify it, as long as you keep each rule on a single #
>>>>> line,
>>>>>>> and change only the value of the NAME= key.
>>>>>>>
>>>>>>> # PCI device 0x10ec:0x8169 (r8169)
>>>>>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>>>>>>> ATTR{address}=="00:14:d1:16:ab:c5", ATTR{type}=="1",
>>>>>> KERNEL=="eth*", NAME="eth0"
>>>>>>> # PCI device 0x10ec:0x8139 (8139too) SUBSYSTEM=="net",
>>>>>>> ACTION=="add", DRIVERS=="?*",
>>>>> ATTR{address}=="00:0a:e6:88:8f:4d",
>>>>>>> ATTR{type}=="1",
>>>>>> KERNEL=="eth*", NAME="eth1"
>>>>>>> # PCI device 0x10ec:0x8169 (r8169)
>>>>>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>>>>>>> ATTR{address}=="00:14:d1:16:a8:cc", ATTR{type}=="1",
>>>>>> KERNEL=="eth*", NAME="eth1"
>>>>>>> # PCI device 0x10ec:0x8139 (8139too) SUBSYSTEM=="net",
>>>>>>> ACTION=="add", DRIVERS=="?*",
>>>>> ATTR{address}=="00:0d:87:26:33:9e",
>>>>>>> ATTR{type}=="1",
>>>>>> KERNEL=="eth*", NAME="eth0"
>>>>>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>>>>>>> ATTR{address}=="00:23:4d:0b:87:b2", ATTR{type}=="1",
>>>>>> KERNEL=="eth*", NAME="wlan0"
>>>>>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>>>>>>> ATTR{address}=="00:21:70:bc:07:76", ATTR{type}=="1",
>>>>>> KERNEL=="eth*", NAME="eth0"
>>>>>>> # PCI device 0x8086:0x10f5 (e1000e)
>>>>>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>>>>>>> ATTR{address}=="00:22:68:13:c2:3b", ATTR{type}=="1",
>>>>>> KERNEL=="eth*", NAME="eth1"
>>>>>>> # PCI device 0x8086:0x4237 (iwlagn)
>>>>>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>>>>>>> ATTR{address}=="00:1e:65:6b:22:64", ATTR{type}=="1",
>>>>>> KERNEL=="wlan*", NAME="wlan1"
>>>>>>>
>>>>>>> Serge
>>>>>>>
>>>>>>>
>>>>>>> On 06/18/2010 09:13 AM, Stefan Engel wrote:
>>>>>>>> Sorry for the late reply, holiday and work kept me busy.
>>>>>>>>
>>>>>>>> I have seen the bug #73 is resolved and the network script is now
>>>>>>>> available in the latest CVS snapshot. I am about to build my own
>>>>>>>> devil distro sometime during the next days. So far the script
>>>> looks
>>>>>>>> ok and should work as intended.
>>>>>>>>
>>>>>>>> Thanks for all helping to get this task done.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Stefan
>>>>>>>>
>>>>>>>>
>>>>>>>> On 05/25/2010 03:29 AM, Stephen H F Ralph wrote:
>>>>>>>>> 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...>
>>>>>>>>>
>>>>>>>>>
>>>>> --------------------------------------------------------------------
>>>>>>>>> ----------
>>>>>>>
>>>>> ----------------------------------------------------------------------
>>>>>>> --------
>>>>>>> This SF.net email is sponsored by
>>>>>>>
>>>>>>> Make an app they can't live without
>>>>>>> Enter the BlackBerry Developer Challenge
>>>>>>> http://p.sf.net/sfu/RIM-dev2dev
>>>>>>> _______________________________________________
>>>>>>> Devil-linux-develop mailing list
>>>>>>> Dev...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>> ------------------------------------------------------------------------
>>>>> ------
>>>>>> This SF.net email is sponsored by
>>>>>>
>>>>>> Make an app they can't live without
>>>>>> Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-
>>>>>> dev2dev _______________________________________________
>>>>>> Devil-linux-develop mailing list
>>>>>> Dev...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>>>>
>>>>>
>>>> ------------------------------------------------------------------------
>>>> ------
>>>>> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
>>>>> Be part of this innovative community and reach millions of netbook
>>>> users
>>>>> worldwide. Take advantage of special opportunities to increase revenue
>>>>> and speed time-to-market. Join now, and jumpstart your future.
>>>>> http://p.sf.net/sfu/intel-atom-d2d
>>>>> _______________________________________________
>>>>> Devil-linux-develop mailing list
>>>>> Dev...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
>>>> Be part of this innovative community and reach millions of netbook users
>>>> worldwide. Take advantage of special opportunities to increase revenue and
>>>> speed time-to-market. Join now, and jumpstart your future.
>>>> http://p.sf.net/sfu/intel-atom-d2d
>>>> _______________________________________________
>>>> Devil-linux-develop mailing list
>>>> Dev...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>> ------------------------------------------------------------------------------
>>> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
>>> Be part of this innovative community and reach millions of netbook users
>>> worldwide. Take advantage of special opportunities to increase revenue and
>>> speed time-to-market. Join now, and jumpstart your future.
>>> http://p.sf.net/sfu/intel-atom-d2d
>>> _______________________________________________
>>> Devil-linux-develop mailing list
>>> Dev...@li...
>>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>>
>>
>>
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>

Stefan,

I moved util-linux into the place you suggested.

Heiko

Quoting Stefan Engel <ma...@en...>:
> Hi,
>
> the build of DL just finished from a clean lfssystem with default config
> for applications and kernel. Everything seems ok so far.
>
> According to chapter 6 of
> http://www.linuxfromscratch.org/lfs/view/stable LFS is building
> util-linux early in the process too.
>
> Stefan
>
> On 08/09/2010 02:13 PM, Heiko Zuerker wrote:
>> Hey,
>>
>> it's almost impossible to find all the package interdependencies
>> without trial'n'error. Did you compile DL with a clean lfssystem and
>> all options turned on? If that works, then we could move it.
>> As an alternative, we can also be look at moving apcupsd.
>>
>> Heiko
>>
>> Quoting Stefan Engel <ma...@en...>:
>>> Hi,
>>>
>>> for our firewall distribution I tried to upgrade apcupsd to the latest
>>> release (3.14.8) and stumbled over a problem cause by /usr/bin/col of
>>> the LFS system (lfssystem-SVN-20070314). This version seems to be a
>>> little bit too old and has problems dealing with some characters when
>>> generating the man pages of apcupsd.
>>>
>>> /usr/bin/col can be found in the package util-linux. util-linux already
>>> gets build and installed in the underlying LFS system, but this is late
>>> in the build order. To work around my problem I moved util-linux from
>>> GROUP_24 to GROUP_17 and adjusted the dependency of util-linux to
>>> GROUP_16 in Makefile.build.
>>>
>>> Is it possible to change this in Makefile.build or are there any
>>> problems when using a current version of util-linux during the early
>>> stages of the build process?
>>>
>>> Regards,
>>> Stefan
>>>
>>> ------------------------------------------------------------------------------
>>> This SF.net email is sponsored by
>>>
>>> Make an app they can't live without
>>> Enter the BlackBerry Developer Challenge
>>> http://p.sf.net/sfu/RIM-dev2dev
>>> _______________________________________________
>>> Devil-linux-develop mailing list
>>> Dev...@li...
>>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>>
>>
>>
>>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> 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, Dominic,


as far as I can see this feature is opposite to concatenation of
70-persistent-net.rules, and in essence it's a way to clean this file up from
"outdated" records without reboot. For me it's "nice to have".


Serge



On 08/30/2010 08:33 AM, Heiko Zuerker wrote:
> Does anybody have an opinion on this?
> 
> Heiko
> 
> Quoting Dominic Raferd <dl...@ed...>:
> 
>> Back in April I submitted to Mantis some code for the
>> /etc/init.d/network script which added a new 'redetect' options to allow
>> redetection of changed network hardware
>> https://sourceforge.net/apps/mantisbt/devil-linux/view.php?id=70. This
>> was felt to be unnecessary because of the introduction of mactab, but it
>> might be worth reconsidering if we are now removing mactab.
>>
>> Dominic
>>
>> Here's the help info for it:
>>
>> 'network redetect' will disrupt any existing network connection and may
>> leave it broken. It is intended for use from a local terminal and in
>> cases where network hardware has changed and needs to be reconfigured to
>> work properly. Or (with 'k' option) where
>> /etc/udev/rules.d/70-persistent-net.rules file has been changed
>> manually, and the network needs to be restarted to reflect the changes.
>> If pre-existing network hardware is working, but additional new network
>> hardware is not, 'network redetect' is probably not the right tool -
>> instead, configure the new hardware from the NET section of 'setup'.
>>
>> Usually you first run with option 'r', this stops the network, removes
>> any prior information about network devices stored at
>> /etc/udev/rules.d/70-persistent-net.rules, redetects network devices,
>> recreates this file and then attempts to restart the network. To restart
>> the network it needs a network module; if you choose the 'autoselect'
>> option when and if requested, it will override any existing module set
>> by 'setup' at /etc/sysconfig/nic/ifcfg-ethn and use the module suggested
>> by udev.
>>
>> If this fails, reconfigure /etc/udev/rules.d/70-persistent-net.rules
>> manually (for instance, switching the allocation of device NAMEs between
>> eth0 and eth1) and then rerun 'network redetect' with the 'k' option.
>>
>> If you still have problems, check settings for the network device
>> (including module) using 'setup'. When you have an operational network,
>> save your changes with 'save-config -q'.
>>
>>>
>>> Heiko
>>>
>>>> -----Original Message-----
>>>> From: Heiko Zuerker [mailto:he...@zu...]
>>>> Sent: Saturday, August 28, 2010 8:06 AM
>>>> To: dev...@li...
>>>> Subject: Re: [Devil-linux-develop] Enable "nameif" to associate MAC
>>>> address with correct interface name
>>>>
>>>> Yes I agree, let's take it back out.
>>>>
>>>> Heiko
>>>>
>>>>> -----Original Message-----
>>>>> From: Stefan Engel [mailto:ma...@en...]
>>>>> Sent: Monday, August 23, 2010 4:12 AM
>>>>> To: dev...@li...
>>>>> Subject: Re: [Devil-linux-develop] Enable "nameif" to associate MAC
>>>>> address with correct interface name
>>>>>
>>>>> Hi Serge,
>>>>>
>>>>> I just tested my config with
>>> /etc/udev/rules.d/70-persistent-net.rules
>>>>> with two VMs and it's working without problems. This solution looks
>>>> like
>>>>> the more elegant way to assign interface names to mac addresses.
>>>>>
>>>>> Seems that the changes we made for dealing with /etc/mactab and
>>>>> /etc/mactable are more or less obsolete by now.
>>>>>
>>>>> udev already works in the correct way when assigning the interface
>>>>> names, without the 'workaround' I made in the network script to get
>>>> the
>>>>> interface names right. So if nobody really needs the changes we made
>>>>> for working with /etc/mactab, /etc/mactable, we could roolback these
>>>>> changes.
>>>>>
>>>>> Regards,
>>>>> Stefan
>>>>>
>>>>> On 08/22/2010 07:56 AM, Serge Leschinsky wrote:
>>>>>> Hi guys,
>>>>>>
>>>>>> DL system has been retired recently and I found that the problem
>>>> with
>>>>>> MAC-interface name association was solved a bit differently.
>>>> Probably
>>>>>> I missed something  - in this case I'm sorry in advance.
>>>>>>
>>>>>> The solution is based on udev rule (70-persistent-net.rules). The
>>>> file
>>>>>> below is a simple concatenation of 70-persistent-net.rules from 3
>>>>>> different DL systems, and I was able to copy configuration tarball
>>>>>> between systems without problem with network interface renaming.
>>>>> Is it the same what you wish to get?
>>>>>>
>>>>>>
>>>>>> # cat /etc/udev/rules.d/70-persistent-net.rules
>>>>>> # This file was automatically generated by the
>>>>>> /lib/udev/write_net_rules # program, run by the persistent-net-
>>>>> generator.rules rules file.
>>>>>> #
>>>>>> # You can modify it, as long as you keep each rule on a single #
>>>> line,
>>>>>> and change only the value of the NAME= key.
>>>>>>
>>>>>> # PCI device 0x10ec:0x8169 (r8169)
>>>>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>>>>>> ATTR{address}=="00:14:d1:16:ab:c5", ATTR{type}=="1",
>>>>> KERNEL=="eth*", NAME="eth0"
>>>>>>
>>>>>> # PCI device 0x10ec:0x8139 (8139too) SUBSYSTEM=="net",
>>>>>> ACTION=="add", DRIVERS=="?*",
>>>> ATTR{address}=="00:0a:e6:88:8f:4d",
>>>>>> ATTR{type}=="1",
>>>>> KERNEL=="eth*", NAME="eth1"
>>>>>>
>>>>>> # PCI device 0x10ec:0x8169 (r8169)
>>>>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>>>>>> ATTR{address}=="00:14:d1:16:a8:cc", ATTR{type}=="1",
>>>>> KERNEL=="eth*", NAME="eth1"
>>>>>>
>>>>>> # PCI device 0x10ec:0x8139 (8139too) SUBSYSTEM=="net",
>>>>>> ACTION=="add", DRIVERS=="?*",
>>>> ATTR{address}=="00:0d:87:26:33:9e",
>>>>>> ATTR{type}=="1",
>>>>> KERNEL=="eth*", NAME="eth0"
>>>>>>
>>>>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>>>>>> ATTR{address}=="00:23:4d:0b:87:b2", ATTR{type}=="1",
>>>>> KERNEL=="eth*", NAME="wlan0"
>>>>>>
>>>>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>>>>>> ATTR{address}=="00:21:70:bc:07:76", ATTR{type}=="1",
>>>>> KERNEL=="eth*", NAME="eth0"
>>>>>>
>>>>>> # PCI device 0x8086:0x10f5 (e1000e)
>>>>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>>>>>> ATTR{address}=="00:22:68:13:c2:3b", ATTR{type}=="1",
>>>>> KERNEL=="eth*", NAME="eth1"
>>>>>>
>>>>>> # PCI device 0x8086:0x4237 (iwlagn)
>>>>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>>>>>> ATTR{address}=="00:1e:65:6b:22:64", ATTR{type}=="1",
>>>>> KERNEL=="wlan*", NAME="wlan1"
>>>>>>
>>>>>>
>>>>>> Serge
>>>>>>
>>>>>>
>>>>>> On 06/18/2010 09:13 AM, Stefan Engel wrote:
>>>>>>> Sorry for the late reply, holiday and work kept me busy.
>>>>>>>
>>>>>>> I have seen the bug #73 is resolved and the network script is now
>>>>>>> available in the latest CVS snapshot. I am about to build my own
>>>>>>> devil distro sometime during the next days. So far the script
>>> looks
>>>>>>> ok and should work as intended.
>>>>>>>
>>>>>>> Thanks for all helping to get this task done.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Stefan
>>>>>>>
>>>>>>>
>>>>>>> On 05/25/2010 03:29 AM, Stephen H F Ralph wrote:
>>>>>>>> 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...>
>>>>>>>>
>>>>>>>>
>>>> --------------------------------------------------------------------
>>>>>>>> ----------
>>>>>>
>>>>>>
>>>> ----------------------------------------------------------------------
>>>>>> --------
>>>>>> This SF.net email is sponsored by
>>>>>>
>>>>>> Make an app they can't live without
>>>>>> Enter the BlackBerry Developer Challenge
>>>>>> http://p.sf.net/sfu/RIM-dev2dev
>>>>>> _______________________________________________
>>>>>> Devil-linux-develop mailing list
>>>>>> Dev...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>> ------------------------------------------------------------------------
>>>> ------
>>>>> This SF.net email is sponsored by
>>>>>
>>>>> Make an app they can't live without
>>>>> Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-
>>>>> dev2dev _______________________________________________
>>>>> Devil-linux-develop mailing list
>>>>> Dev...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>>>
>>>>
>>>>
>>> ------------------------------------------------------------------------
>>> ------
>>>> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
>>>> Be part of this innovative community and reach millions of netbook
>>> users
>>>> worldwide. Take advantage of special opportunities to increase revenue
>>>> and speed time-to-market. Join now, and jumpstart your future.
>>>> http://p.sf.net/sfu/intel-atom-d2d
>>>> _______________________________________________
>>>> Devil-linux-develop mailing list
>>>> Dev...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
>>> Be part of this innovative community and reach millions of netbook users
>>> worldwide. Take advantage of special opportunities to increase revenue and
>>> speed time-to-market. Join now, and jumpstart your future.
>>> http://p.sf.net/sfu/intel-atom-d2d
>>> _______________________________________________
>>> Devil-linux-develop mailing list
>>> Dev...@li...
>>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>
>> ------------------------------------------------------------------------------
>> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
>> Be part of this innovative community and reach millions of netbook users
>> worldwide. Take advantage of special opportunities to increase revenue and
>> speed time-to-market. Join now, and jumpstart your future.
>> http://p.sf.net/sfu/intel-atom-d2d
>> _______________________________________________
>> Devil-linux-develop mailing list
>> Dev...@li...
>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>
> 
> 
> 

Done.

Serge

On 08/30/2010 08:32 AM, Heiko Zuerker wrote:
> Seems good to me.
> Let's get it in CVS so we can have more testers.
> I'm still working on updating all the software packages Alby  
> mentioned, including a couple of fixes to the script he provided.
> 
> Heiko
> 
> Quoting Serge Leschinsky <ser...@gm...>:
> 
>> the final final version:
>>
>> Summary:
>>
>> - added all types of route
>> - added rules
>> - added tunnel interface configuration
>>
>> Serge
>>
>>
>> -------------------------------------------------------------------------
>> cat ifcfg-eth0.sample:
>> #
>> # example for a "normal" INTERFACE with no VLANs and no BRIDGING
>> #
>> DHCP=no
>> #DHCP=yes
>> #DHCP=server
>> # options passed directly to dhcpcd on startup
>> #DHCP_OPTIONS=""
>> ONBOOT=yes
>> DEVICE=eth0
>> IP=10.90.1.200
>> NETMASK=255.255.255.0
>> #BROADCAST=10.90.1.255
>> #MAC=
>> MODULE=pcnet32
>> #MODULE_OPTS=
>> #
>>
>> ########################################################
>> # ROUTE=" ...... "
>> # where ROUTE is a key word and the line with ROUTE
>> # should not have spaces between the beginning of
>> # the line and the keyword
>> # Route statement is a any valid "ip route"# command,
>> # without "ip route add" prefix - it will be added
>> # automatically
>> #
>> # IPV6ROUTE="...."
>> # IPV6ROUTE keyword can be used for ipv6 routes.
>> #
>> # RULE=" ...... "
>> # where RULE is a key word and the line with RULE
>> # should not have spaces between the beginning of
>> # the line and the keyword
>> # Rule statement is a any valid "ip rule" command,
>> # without "ip rule add" prefix - it will be added
>> # automatically
>> #
>> # $DEVICE can be used to directly specify the interface
>> #
>> ###### samples for several possible scenarios
>> #
>> # route to network 192.168.254.0/255.255.255.0 via gateway 10.90.1.252
>> #ROUTE="192.168.254.0/255.255.255.0 via 10.90.1.252"
>> # or
>> #ROUTE="192.168.254.0/24 via 10.90.1.252"
>> #
>> #
>> # route to host 192.168.3.1 via 10.90.1.252
>> #ROUTE="192.168.3.0/32 via 10.90.1.252"
>> #
>> # route to network that is also reachable via this interface
>> #ROUTE="192.168.3.0/24 dev $DEVICE"
>> #
>>
>> # special routes
>> #ROUTE="unreachable 10.0.0.0/8"
>> #ROUTE="blackhole 192.168.1.0/24"
>> #
>> # add as many ROUTE="...." lines as you need routes
>> #
>> # the next line shows how to set the default gateway
>> #ROUTE="default via 10.90.1.1".
>> #
>> ###### advanced routing
>> # make sure additional routing table is created
>> #
>> # echo "500  bypass" >> /etc/iproute2/rt_tables
>> #
>> #ROUTE="default via 1.234.123.1 table bypass"
>> #RULE="from 10.0.0.0/24 table bypass prio 500"
>> #RULE="from 10.0.1.0/24 table bypass prio 600"
>> #RULE="from 10.0.2.123/32 to 10.8.0.0/16 table main prio 400"
>> #
>>
>> -------------------------------------------------------------------------
>> cat ifcfg-tun0.sample:
>> #
>> # example for a tunnel INTERFACE
>> #
>> ONBOOT=yes
>> TUNNEL=yes
>>
>> # bind the tunnel to the device DEVICE so that tunneled packets
>> # will only be routed via this device and will not be able to escape
>> # to another device when the route to endpoint changes.
>> #DEVICE=eth4
>>
>> # set the fixed local address for tunneled packets.
>> LOCAL=10.90.1.200
>>
>> # set the remote endpoint of the tunnel.
>> REMOTE=1.2.3.204
>>
>> # Available modes depend on the encapsulating address family.
>> # Modes for IPv4 encapsulation available: ipip, sit, isatap and gre.
>> # Modes for IPv6 encapsulation available: ip6ip6, ipip6 and any.
>> MODE=ipip
>>
>> # addtional tunnel options if any
>> TUN_OPTS=""
>>
>>
>>
> 
> 
> 

Does anybody have an opinion on this?

Heiko

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

> Back in April I submitted to Mantis some code for the
> /etc/init.d/network script which added a new 'redetect' options to allow
> redetection of changed network hardware
> https://sourceforge.net/apps/mantisbt/devil-linux/view.php?id=70. This
> was felt to be unnecessary because of the introduction of mactab, but it
> might be worth reconsidering if we are now removing mactab.
>
> Dominic
>
> Here's the help info for it:
>
> 'network redetect' will disrupt any existing network connection and may
> leave it broken. It is intended for use from a local terminal and in
> cases where network hardware has changed and needs to be reconfigured to
> work properly. Or (with 'k' option) where
> /etc/udev/rules.d/70-persistent-net.rules file has been changed
> manually, and the network needs to be restarted to reflect the changes.
> If pre-existing network hardware is working, but additional new network
> hardware is not, 'network redetect' is probably not the right tool -
> instead, configure the new hardware from the NET section of 'setup'.
>
> Usually you first run with option 'r', this stops the network, removes
> any prior information about network devices stored at
> /etc/udev/rules.d/70-persistent-net.rules, redetects network devices,
> recreates this file and then attempts to restart the network. To restart
> the network it needs a network module; if you choose the 'autoselect'
> option when and if requested, it will override any existing module set
> by 'setup' at /etc/sysconfig/nic/ifcfg-ethn and use the module suggested
> by udev.
>
> If this fails, reconfigure /etc/udev/rules.d/70-persistent-net.rules
> manually (for instance, switching the allocation of device NAMEs between
> eth0 and eth1) and then rerun 'network redetect' with the 'k' option.
>
> If you still have problems, check settings for the network device
> (including module) using 'setup'. When you have an operational network,
> save your changes with 'save-config -q'.
>
>>
>> Heiko
>>
>>> -----Original Message-----
>>> From: Heiko Zuerker [mailto:he...@zu...]
>>> Sent: Saturday, August 28, 2010 8:06 AM
>>> To: dev...@li...
>>> Subject: Re: [Devil-linux-develop] Enable "nameif" to associate MAC
>>> address with correct interface name
>>>
>>> Yes I agree, let's take it back out.
>>>
>>> Heiko
>>>
>>>> -----Original Message-----
>>>> From: Stefan Engel [mailto:ma...@en...]
>>>> Sent: Monday, August 23, 2010 4:12 AM
>>>> To: dev...@li...
>>>> Subject: Re: [Devil-linux-develop] Enable "nameif" to associate MAC
>>>> address with correct interface name
>>>>
>>>> Hi Serge,
>>>>
>>>> I just tested my config with
>> /etc/udev/rules.d/70-persistent-net.rules
>>>> with two VMs and it's working without problems. This solution looks
>>> like
>>>> the more elegant way to assign interface names to mac addresses.
>>>>
>>>> Seems that the changes we made for dealing with /etc/mactab and
>>>> /etc/mactable are more or less obsolete by now.
>>>>
>>>> udev already works in the correct way when assigning the interface
>>>> names, without the 'workaround' I made in the network script to get
>>> the
>>>> interface names right. So if nobody really needs the changes we made
>>>> for working with /etc/mactab, /etc/mactable, we could roolback these
>>>> changes.
>>>>
>>>> Regards,
>>>> Stefan
>>>>
>>>> On 08/22/2010 07:56 AM, Serge Leschinsky wrote:
>>>>> Hi guys,
>>>>>
>>>>> DL system has been retired recently and I found that the problem
>>> with
>>>>> MAC-interface name association was solved a bit differently.
>>> Probably
>>>>> I missed something  - in this case I'm sorry in advance.
>>>>>
>>>>> The solution is based on udev rule (70-persistent-net.rules). The
>>> file
>>>>> below is a simple concatenation of 70-persistent-net.rules from 3
>>>>> different DL systems, and I was able to copy configuration tarball
>>>>> between systems without problem with network interface renaming.
>>>> Is it the same what you wish to get?
>>>>>
>>>>>
>>>>> # cat /etc/udev/rules.d/70-persistent-net.rules
>>>>> # This file was automatically generated by the
>>>>> /lib/udev/write_net_rules # program, run by the persistent-net-
>>>> generator.rules rules file.
>>>>> #
>>>>> # You can modify it, as long as you keep each rule on a single #
>>> line,
>>>>> and change only the value of the NAME= key.
>>>>>
>>>>> # PCI device 0x10ec:0x8169 (r8169)
>>>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>>>>> ATTR{address}=="00:14:d1:16:ab:c5", ATTR{type}=="1",
>>>> KERNEL=="eth*", NAME="eth0"
>>>>>
>>>>> # PCI device 0x10ec:0x8139 (8139too) SUBSYSTEM=="net",
>>>>> ACTION=="add", DRIVERS=="?*",
>>> ATTR{address}=="00:0a:e6:88:8f:4d",
>>>>> ATTR{type}=="1",
>>>> KERNEL=="eth*", NAME="eth1"
>>>>>
>>>>> # PCI device 0x10ec:0x8169 (r8169)
>>>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>>>>> ATTR{address}=="00:14:d1:16:a8:cc", ATTR{type}=="1",
>>>> KERNEL=="eth*", NAME="eth1"
>>>>>
>>>>> # PCI device 0x10ec:0x8139 (8139too) SUBSYSTEM=="net",
>>>>> ACTION=="add", DRIVERS=="?*",
>>> ATTR{address}=="00:0d:87:26:33:9e",
>>>>> ATTR{type}=="1",
>>>> KERNEL=="eth*", NAME="eth0"
>>>>>
>>>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>>>>> ATTR{address}=="00:23:4d:0b:87:b2", ATTR{type}=="1",
>>>> KERNEL=="eth*", NAME="wlan0"
>>>>>
>>>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>>>>> ATTR{address}=="00:21:70:bc:07:76", ATTR{type}=="1",
>>>> KERNEL=="eth*", NAME="eth0"
>>>>>
>>>>> # PCI device 0x8086:0x10f5 (e1000e)
>>>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>>>>> ATTR{address}=="00:22:68:13:c2:3b", ATTR{type}=="1",
>>>> KERNEL=="eth*", NAME="eth1"
>>>>>
>>>>> # PCI device 0x8086:0x4237 (iwlagn)
>>>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>>>>> ATTR{address}=="00:1e:65:6b:22:64", ATTR{type}=="1",
>>>> KERNEL=="wlan*", NAME="wlan1"
>>>>>
>>>>>
>>>>> Serge
>>>>>
>>>>>
>>>>> On 06/18/2010 09:13 AM, Stefan Engel wrote:
>>>>>> Sorry for the late reply, holiday and work kept me busy.
>>>>>>
>>>>>> I have seen the bug #73 is resolved and the network script is now
>>>>>> available in the latest CVS snapshot. I am about to build my own
>>>>>> devil distro sometime during the next days. So far the script
>> looks
>>>>>> ok and should work as intended.
>>>>>>
>>>>>> Thanks for all helping to get this task done.
>>>>>>
>>>>>> Regards,
>>>>>> Stefan
>>>>>>
>>>>>>
>>>>>> On 05/25/2010 03:29 AM, Stephen H F Ralph wrote:
>>>>>>> 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...>
>>>>>>>
>>>>>>>
>>> --------------------------------------------------------------------
>>>>>>> ----------
>>>>>
>>>>>
>>> ----------------------------------------------------------------------
>>>>> --------
>>>>> This SF.net email is sponsored by
>>>>>
>>>>> Make an app they can't live without
>>>>> Enter the BlackBerry Developer Challenge
>>>>> http://p.sf.net/sfu/RIM-dev2dev
>>>>> _______________________________________________
>>>>> Devil-linux-develop mailing list
>>>>> Dev...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>> ------------------------------------------------------------------------
>>> ------
>>>> This SF.net email is sponsored by
>>>>
>>>> Make an app they can't live without
>>>> Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-
>>>> dev2dev _______________________________________________
>>>> Devil-linux-develop mailing list
>>>> Dev...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>>
>>>
>>>
>> ------------------------------------------------------------------------
>> ------
>>> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
>>> Be part of this innovative community and reach millions of netbook
>> users
>>> worldwide. Take advantage of special opportunities to increase revenue
>>> and speed time-to-market. Join now, and jumpstart your future.
>>> http://p.sf.net/sfu/intel-atom-d2d
>>> _______________________________________________
>>> Devil-linux-develop mailing list
>>> Dev...@li...
>>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>
>>
>> ------------------------------------------------------------------------------
>> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
>> Be part of this innovative community and reach millions of netbook users
>> worldwide. Take advantage of special opportunities to increase revenue and
>> speed time-to-market. Join now, and jumpstart your future.
>> http://p.sf.net/sfu/intel-atom-d2d
>> _______________________________________________
>> Devil-linux-develop mailing list
>> Dev...@li...
>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>
> ------------------------------------------------------------------------------
> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
> Be part of this innovative community and reach millions of netbook users
> worldwide. Take advantage of special opportunities to increase revenue and
> speed time-to-market. Join now, and jumpstart your future.
> http://p.sf.net/sfu/intel-atom-d2d
> _______________________________________________
> 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.

Seems good to me.
Let's get it in CVS so we can have more testers.
I'm still working on updating all the software packages Alby  
mentioned, including a couple of fixes to the script he provided.

Heiko

Quoting Serge Leschinsky <ser...@gm...>:

> the final final version:
>
> Summary:
>
> - added all types of route
> - added rules
> - added tunnel interface configuration
>
> Serge
>
>
> -------------------------------------------------------------------------
> cat ifcfg-eth0.sample:
> #
> # example for a "normal" INTERFACE with no VLANs and no BRIDGING
> #
> DHCP=no
> #DHCP=yes
> #DHCP=server
> # options passed directly to dhcpcd on startup
> #DHCP_OPTIONS=""
> ONBOOT=yes
> DEVICE=eth0
> IP=10.90.1.200
> NETMASK=255.255.255.0
> #BROADCAST=10.90.1.255
> #MAC=
> MODULE=pcnet32
> #MODULE_OPTS=
> #
>
> ########################################################
> # ROUTE=" ...... "
> # where ROUTE is a key word and the line with ROUTE
> # should not have spaces between the beginning of
> # the line and the keyword
> # Route statement is a any valid "ip route"# command,
> # without "ip route add" prefix - it will be added
> # automatically
> #
> # IPV6ROUTE="...."
> # IPV6ROUTE keyword can be used for ipv6 routes.
> #
> # RULE=" ...... "
> # where RULE is a key word and the line with RULE
> # should not have spaces between the beginning of
> # the line and the keyword
> # Rule statement is a any valid "ip rule" command,
> # without "ip rule add" prefix - it will be added
> # automatically
> #
> # $DEVICE can be used to directly specify the interface
> #
> ###### samples for several possible scenarios
> #
> # route to network 192.168.254.0/255.255.255.0 via gateway 10.90.1.252
> #ROUTE="192.168.254.0/255.255.255.0 via 10.90.1.252"
> # or
> #ROUTE="192.168.254.0/24 via 10.90.1.252"
> #
> #
> # route to host 192.168.3.1 via 10.90.1.252
> #ROUTE="192.168.3.0/32 via 10.90.1.252"
> #
> # route to network that is also reachable via this interface
> #ROUTE="192.168.3.0/24 dev $DEVICE"
> #
>
> # special routes
> #ROUTE="unreachable 10.0.0.0/8"
> #ROUTE="blackhole 192.168.1.0/24"
> #
> # add as many ROUTE="...." lines as you need routes
> #
> # the next line shows how to set the default gateway
> #ROUTE="default via 10.90.1.1".
> #
> ###### advanced routing
> # make sure additional routing table is created
> #
> # echo "500  bypass" >> /etc/iproute2/rt_tables
> #
> #ROUTE="default via 1.234.123.1 table bypass"
> #RULE="from 10.0.0.0/24 table bypass prio 500"
> #RULE="from 10.0.1.0/24 table bypass prio 600"
> #RULE="from 10.0.2.123/32 to 10.8.0.0/16 table main prio 400"
> #
>
> -------------------------------------------------------------------------
> cat ifcfg-tun0.sample:
> #
> # example for a tunnel INTERFACE
> #
> ONBOOT=yes
> TUNNEL=yes
>
> # bind the tunnel to the device DEVICE so that tunneled packets
> # will only be routed via this device and will not be able to escape
> # to another device when the route to endpoint changes.
> #DEVICE=eth4
>
> # set the fixed local address for tunneled packets.
> LOCAL=10.90.1.200
>
> # set the remote endpoint of the tunnel.
> REMOTE=1.2.3.204
>
> # Available modes depend on the encapsulating address family.
> # Modes for IPv4 encapsulation available: ipip, sit, isatap and gre.
> # Modes for IPv6 encapsulation available: ip6ip6, ipip6 and any.
> MODE=ipip
>
> # addtional tunnel options if any
> TUN_OPTS=""
>
>
>



-- 

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


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

the final final version:

Summary:

- added all types of route
- added rules
- added tunnel interface configuration

Serge


-------------------------------------------------------------------------
cat ifcfg-eth0.sample:
#
# example for a "normal" INTERFACE with no VLANs and no BRIDGING
#
DHCP=no
#DHCP=yes
#DHCP=server
# options passed directly to dhcpcd on startup
#DHCP_OPTIONS=""
ONBOOT=yes
DEVICE=eth0
IP=10.90.1.200
NETMASK=255.255.255.0
#BROADCAST=10.90.1.255
#MAC=
MODULE=pcnet32
#MODULE_OPTS=
#

########################################################
# ROUTE=" ...... "
# where ROUTE is a key word and the line with ROUTE
# should not have spaces between the beginning of
# the line and the keyword
# Route statement is a any valid "ip route"# command,
# without "ip route add" prefix - it will be added
# automatically
#
# IPV6ROUTE="...."
# IPV6ROUTE keyword can be used for ipv6 routes.
#
# RULE=" ...... "
# where RULE is a key word and the line with RULE
# should not have spaces between the beginning of
# the line and the keyword
# Rule statement is a any valid "ip rule" command,
# without "ip rule add" prefix - it will be added
# automatically
#
# $DEVICE can be used to directly specify the interface
#
###### samples for several possible scenarios
#
# route to network 192.168.254.0/255.255.255.0 via gateway 10.90.1.252
#ROUTE="192.168.254.0/255.255.255.0 via 10.90.1.252"
# or
#ROUTE="192.168.254.0/24 via 10.90.1.252"
#
#
# route to host 192.168.3.1 via 10.90.1.252
#ROUTE="192.168.3.0/32 via 10.90.1.252"
#
# route to network that is also reachable via this interface
#ROUTE="192.168.3.0/24 dev $DEVICE"
#

# special routes
#ROUTE="unreachable 10.0.0.0/8"
#ROUTE="blackhole 192.168.1.0/24"
#
# add as many ROUTE="...." lines as you need routes
#
# the next line shows how to set the default gateway
#ROUTE="default via 10.90.1.1".
#
###### advanced routing
# make sure additional routing table is created
#
# echo "500  bypass" >> /etc/iproute2/rt_tables
#
#ROUTE="default via 1.234.123.1 table bypass"
#RULE="from 10.0.0.0/24 table bypass prio 500"
#RULE="from 10.0.1.0/24 table bypass prio 600"
#RULE="from 10.0.2.123/32 to 10.8.0.0/16 table main prio 400"
#

-------------------------------------------------------------------------
cat ifcfg-tun0.sample:
#
# example for a tunnel INTERFACE
#
ONBOOT=yes
TUNNEL=yes

# bind the tunnel to the device DEVICE so that tunneled packets
# will only be routed via this device and will not be able to escape
# to another device when the route to endpoint changes.
#DEVICE=eth4

# set the fixed local address for tunneled packets.
LOCAL=10.90.1.200

# set the remote endpoint of the tunnel.
REMOTE=1.2.3.204

# Available modes depend on the encapsulating address family.
# Modes for IPv4 encapsulation available: ipip, sit, isatap and gre.
# Modes for IPv6 encapsulation available: ip6ip6, ipip6 and any.
MODE=ipip

# addtional tunnel options if any
TUN_OPTS=""

Extended version:

########################################################
# ROUTE=" ......"
# where ROUTE is a key word and the line with ROUTE
# should not have spaces between the beginning of
# the line and the keyword
# Route statement is any valid "ip route" command,
# without "ip route add" prefix - it will be added
# automatically
#
# IPV6ROUTE="...."
# IPV6ROUTE keyword can be used for ipv6 routes.
#
# RULE=" ...... "
# where RULE is a keyword and the line with RULE
# should not have spaces between the beginning of
# the line and the keyword
# Rule statement is any valid "ip rule" command,
# without "ip rule add" prefix - it will be added
# automatically
#
# $DEVICE can be used to directly specify the interface
#
###### samples for several possible scenarios
#
# route to network 192.168.254.0/255.255.255.0 via gateway 10.90.1.252
#ROUTE="192.168.254.0/255.255.255.0 via 10.90.1.252"
# or
#ROUTE="192.168.254.0/24 via 10.90.1.252"
#
#
# route to host 192.168.3.1 via 10.90.1.252
#ROUTE="192.168.3.0/32 via 10.90.1.252"
#
# route to network that is also reachable via this interface
#ROUTE="192.168.3.0/24 dev $DEVICE"
#
# special routes
#ROUTE="unreachable 10.0.0.0/8"
#ROUTE="blackhole 192.168.1.0/24"
#
# add as many ROUTE="...." lines as you need routes
#
# the next line shows how to set the default gateway
#ROUTE="default via 10.90.1.1".
#
###### advanced routing
# make sure additional routing table is created
#
# echo "500  bypass" >> /etc/iproute2/rt_tables
#
#ROUTE="default via 1.234.123.1 table bypass"
#RULE="from 10.0.0.0/24 table bypass prio 500"
#RULE="from 10.0.1.0/24 table bypass prio 600"
#RULE="from 10.0.2.123/32 to 10.8.0.0/16 table main prio 400"
#


Serge





On 08/29/2010 07:43 PM, Serge Leschinsky wrote:
> Hi,
> 
> OK, the patch for network script is in the attachment.
> 
> If this approach is OK, I'll add 'RULE' keyword to work with additional routing
> tables.
> 
> The suggest modification of the documentation is below:
> 
> ########################################################
> # ROUTE=" ...... "
> # where ROUTE is a key word and the line with ROUTE
> # should not have spaces between the beginning of
> # the line and the keyword
> # and route statement is a any valid "ip route"
> # command, without "ip route add" prefix - it will
> # be added automatically
> #
> # IPV6ROUTE="...."
> # IPV6ROUTE keyword can be used for ipv6 routes.
> #
> # $DEVICE can be used to directly specify the interface
> #
> ###### samples for several possible scenarios
> #
> # route to network 192.168.254.0/255.255.255.0 via gateway 10.90.1.252
> #ROUTE="192.168.254.0/255.255.255.0 via 10.90.1.252"
> # or
> #ROUTE="192.168.254.0/24 via 10.90.1.252"
> #
> #
> # route to host 192.168.3.1 via 10.90.1.252
> #ROUTE="192.168.3.0/32 via 10.90.1.252"
> #
> # route to network that is also reachable via this interface
> #ROUTE="192.168.3.0/24 dev $DEVICE"
> #
> # special routes
> #ROUTE="unreachable 10.0.0.0/8"
> #ROUTE="blackhole 192.168.1.0/24"
> #
> # add as many ROUTE="...." lines as you need routes
> #
> # the next line shows how to set the default gateway
> #ROUTE="$default via 10.90.1.1".
> #
> 
> 
> 
> Sincerely,
> Serge
> 
> On 08/28/2010 11:38 PM, Serge Leschinsky wrote:
>> Heiko,
>>
>> Yes, thank to my current job I have a LOT of enthusiasm to make something useful :)
>>
>> What do you think about the following solution?:
>>
>> every ifcfg-XXXX can contain routes in form of lines
>>
>> ROUTE="default via xxx.xxx.xxx.xxx"
>> ROUTE="blackhole 10.0.0.0/8"
>> ROUTE="10.1.0.0/16 dev ppp0"
>> ROUTE="192.168.1.0/24 via xxx.xxx.xxx.xxx dev $DEVICE"
>>
>> etc. actually, any "ip route" command is allowed, because the statement is the
>> command itself, but without prefix "ip route add".
>>
>> We will add prefix "ip route add" for each ROUTE statement on 'start' and "ip
>> route del" for each statement on 'stop'.
>>
>> $DEVICE is already defined at the moment of execution (it will be the name of
>> this interface) , so we can use it as well.
>>
>> It seems to be simple and flexible enough.
>>
>> PS. Sorry for the broken thread - I copied the  message from web, because ISP (
>> where my email account was) doesn't accept my credential anymore :(
>>
>>
>> Serge
>>
>>
>>
>>> I hate to delay the release of 1.4 further, but I think you are right.
>>> Would you have time to add it?
>>>
>>> Heiko
>>>
>>>> -----Original Message-----
>>>> From: Serge Leschinsky [mailto:fi...@in...]
>>>> Sent: Friday, August 27, 2010 7:49 PM
>>>> To: dev...@li...
>>>> Subject: [Devil-linux-develop] network configuration script - add
>>>> routes
>>>>
>>>> Hi,
>>>>
>>>> there is a new bug:
>>>>>
>>>> =======================================================
>>>> ===============
>>>>> Summary:                    Cannot add blackhole route
>>>>> Description:
>>>>> There is no way to add blackhole, unreachable etc. type of routes
>>>>> using configuration scripts.
>>>>>
>>>> =======================================================
>>>> ===============
>>>>
>>>> I have taken a look at ROUTE section in network script and have to
>>>> admit
>>>> that old 'route' command doesn't allow us to add new sophisticated
>>>> routes. The main idea is to replace 'route' by 'ip route', but it
>>>> obviously
>>>> causes the config format modification ('ip route' has much more
>>>> options). On the other hand, release 1.4 is a good time to change
>>>> things,
>>>> because 1.2 -> 1.4 migration is a big deal anyway.
>>>>
>>>> So, please advise :)
>>>>
>>>> Serge
>>>>
>>>>
>>>>
>>
>