Devil-Linux

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:serge.leschinsky+dl@...]
>> Sent: Monday, August 30, 2010 3:08 PM
>> To: devil-linux-develop@...
>> 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 <serge.leschinsky+dl@...>:
>>>
>>>> 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
>> Devil-linux-develop@...
>> 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
> Devil-linux-develop@...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>

Yes that would make sense.

H.

> -----Original Message-----
> From: Serge Leschinsky [mailto:serge.leschinsky+dl@...]
> Sent: Sunday, September 05, 2010 1:29 PM
> To: devil-linux-develop@...
> 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:serge.leschinsky+dl@...]
> >> Sent: Monday, August 30, 2010 3:08 PM
> >> To: devil-linux-develop@...
> >> 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 <serge.leschinsky+dl@...>:
> >>>
> >>>> 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
> >> Devil-linux-develop@...
> >> 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
> > Devil-linux-develop@...
> > 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
> Devil-linux-develop@...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop

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.
>

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.
>

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:serge.leschinsky+dl@...]
> Sent: Sunday, September 05, 2010 5:37 PM
> To: devil-linux-develop@...
> 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
> Devil-linux-develop@...
> 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:serge.leschinsky+dl@...]
>> Sent: Sunday, September 05, 2010 5:37 PM
>> To: devil-linux-develop@...
>> 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
>> Devil-linux-develop@...
>> 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
> Devil-linux-develop@...
> 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:serge.leschinsky+dl@...]
>>> Sent: Sunday, September 05, 2010 5:37 PM
>>> To: devil-linux-develop@...
>>> 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
>>> Devil-linux-develop@...
>>> 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
>> Devil-linux-develop@...
>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>
>

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:serge.leschinsky+dl@...]
> Sent: Monday, September 06, 2010 2:17 PM
> To: devil-linux-develop@...
> 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:serge.leschinsky+dl@...]
> >>> Sent: Sunday, September 05, 2010 5:37 PM
> >>> To: devil-linux-develop@...
> >>> 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
> >>> Devil-linux-develop@...
> >>> 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
> >> Devil-linux-develop@...
> >> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
> >>
> >

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).

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 <serge.leschinsky+dl@...>:

> 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.

Fixed

Heiko

Quoting Stefan Engel <mail@...>:

> 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 <mail@...>:
>>> 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 <mail@...>:
>>>>> 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
>>>>> Devil-linux-develop@...
>>>>> 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
>>> Devil-linux-develop@...
>>> 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
> Devil-linux-develop@...
> 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.

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@...>:
>>>>
>>>>> 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:heiko@...]
>>>>>>> Sent: Saturday, August 28, 2010 8:06 AM
>>>>>>> To: devil-linux-develop@...
>>>>>>> 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:mail@...]
>>>>>>>> Sent: Monday, August 23, 2010 4:12 AM
>>>>>>>> To: devil-linux-develop@...
>>>>>>>> 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"<shfralph@...>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> --------------------------------------------------------------------
>>>>>>>>>>> ----------
>>>>>>>>>
>>>>>>> ----------------------------------------------------------------------
>>>>>>>>> --------
>>>>>>>>> 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
>>>>>>>>> Devil-linux-develop@...
>>>>>>>>> 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
>>>>>>>> Devil-linux-develop@...
>>>>>>>> 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
>>>>>>> Devil-linux-develop@...
>>>>>>> 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
>>>>>> Devil-linux-develop@...
>>>>>> 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
>>>>> Devil-linux-develop@...
>>>>> 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
>>> Devil-linux-develop@...
>>> 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
>> Devil-linux-develop@...
>> 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
> Devil-linux-develop@...
> 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@...>:
>>>
>>>> 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:heiko@...]
>>>>>> Sent: Saturday, August 28, 2010 8:06 AM
>>>>>> To: devil-linux-develop@...
>>>>>> 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:mail@...]
>>>>>>> Sent: Monday, August 23, 2010 4:12 AM
>>>>>>> To: devil-linux-develop@...
>>>>>>> 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"<shfralph@...>
>>>>>>>>>>
>>>>>>>>>>
>>>>>> --------------------------------------------------------------------
>>>>>>>>>> ----------
>>>>>>>>
>>>>>> ----------------------------------------------------------------------
>>>>>>>> --------
>>>>>>>> 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
>>>>>>>> Devil-linux-develop@...
>>>>>>>> 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
>>>>>>> Devil-linux-develop@...
>>>>>>> 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
>>>>>> Devil-linux-develop@...
>>>>>> 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
>>>>> Devil-linux-develop@...
>>>>> 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
>>>> Devil-linux-develop@...
>>>> 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
>> Devil-linux-develop@...
>> 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
> Devil-linux-develop@...
> 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@...>:
>>>>
>>>>> 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:heiko@...]
>>>>>>> Sent: Saturday, August 28, 2010 8:06 AM
>>>>>>> To: devil-linux-develop@...
>>>>>>> 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:mail@...]
>>>>>>>> Sent: Monday, August 23, 2010 4:12 AM
>>>>>>>> To: devil-linux-develop@...
>>>>>>>> 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"<shfralph@...>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> --------------------------------------------------------------------
>>>>>>>>>>> ----------
>>>>>>>>>
>>>>>>> ----------------------------------------------------------------------
>>>>>>>>> --------
>>>>>>>>> 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
>>>>>>>>> Devil-linux-develop@...
>>>>>>>>> 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
>>>>>>>> Devil-linux-develop@...
>>>>>>>> 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
>>>>>>> Devil-linux-develop@...
>>>>>>> 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
>>>>>> Devil-linux-develop@...
>>>>>> 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
>>>>> Devil-linux-develop@...
>>>>> 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
>>> Devil-linux-develop@...
>>> 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
>> Devil-linux-develop@...
>> 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
> Devil-linux-develop@...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop