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

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

Hi Heiko,

In general, yes, we can. I've looked at my networks schemas and I see that
sometimes I use routes statement for tunnels - they are actually handled by
Quagga but may be static. So, it might be a good addition if we implement
ifcfg-* format to handle tunnel interfaces.

Serge


On 08/29/2010 06:06 AM, Heiko Zuerker wrote:
> Hey,
> 
> I'm wondering if it wouldn't make sense to automatically add the "dev
> $DEVICE".
> 
> Heiko
> 
>> -----Original Message-----
>> From: Serge Leschinsky [mailto:ser...@gm...]
>> Sent: Sunday, August 29, 2010 1:52 AM
>> To: dev...@li...
>> Subject: Re: [Devil-linux-develop] network configuration script - add
>> routes
>>
>> 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 the 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
>>>>
>>>>
>>>>
>>
>>
>>
> ------------------------------------------------------------------------
> ------
>> 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
> 

Thanks for submitting the list!

I'll update the software packages, since I'm doing that right now
anyway.
I didn't get a chance yet to look the rest of the findings.

Heiko

> -----Original Message-----
> From: Benati Alberto [mailto:be...@ec...]
> Sent: Saturday, August 28, 2010 5:05 PM
> To: dev...@li...
> Subject: [Devil-linux-develop] Report on 1.4
> 
> Hi all,
> as usual a very long time!!
> 
> I tested 1.4 and it's a nice work.
> Below there is a report and some changes that I have used, in attach
> there is the patchset.
> if some things are unclear please feel free to ask
> 
> Update src:
>   clamav-0.96.2
>   httpd-2.2.16 (security)
>   libpng-1.2.44 (security)
>   MailScanner-4.81.3-1
>   mhash-0.9.9.9
>   netpbm-10.35.76
>   openldap-2.4.23 (security)
>   p7zip_9.13
>   php-5.2.14 (security)
>   shorewall-4.4.12
>   sudo-1.7.4p2
>   syslog-ng_3.0.8
>   tnef-1.4.7
>   unrarsrc-3.9.10
> 
> 
> 
> Update src/perl-ext: (usefull for MailScanner also)
>   Compress-Raw-Bzip2-2.030
>   Compress-Raw-Zlib-2.030
>   Compress-Zlib-2.015.tar.gz
>   DBD-mysql-4.017
>   DBD-Pg-2.17.1
>   DBD-SQLite-1.29
>   HTML-Parser-3.66
>   Mail-SPF-v2.007.tar.gz
>   MIME-Base64-3.09
>   MIME-tools-5.428
> 
> 
> 
> Typo in: scripts/config/perl-ext
>   Crypt-OpenSSL (not exist)
>   IP-Country (2 items)
>   Pod-Readme (2 items)
> 
> I have many warning in perl-ext for missing modules (but some
installed
> after), look for perl-ext/perl-ext and perl-ext/perl-ext.info with
some
> adjusts
> 
> 
> 
> Typo(?) in: Makefile.build
>   git is in GROUP_20 and GROUP_X
> 
> 
> 
> Patchs:
>   *dovecot_sqlite (add sqlite support)
>   *httpd_ldap_dbd (add ldap and dbd (mysql/pgsql) auth and rewrite
> support)
>   *php_plus (add soap, wddx, ldap-sasl, exif, pcntl for phpsysinfo,
etc..
> and close to devil)
>   *clam_patchset-config_p7zip (drop Clam patchset (look below), and
> add p7zip config)
>   *update MySQL-python and python-ldap from 2.4 to new python
> versions
>   *Denyhosts (debian patch and close to)
>     +add denyhosts_2.6-7.diff.gz in src
>     -drop src/denyhosts_2.5-3.diff.gz and src/denyhosts.diff.gz
>   *perl_typo (typo?)
> 
>   FOR COMPILE BUT NOT TESTED YET:
>   *sagator_Genshi (close to devil and look below for kid) and Genshi
> script
>     +necessary add Genshi-0.6.tar.gz in src
>   *Mailscanner_scripts (there is in src but not config)
>     +necessary add in perl-ext: Sys-SigAction-0.11.tar.gz
> 
> 
> 
> Problems:
> - Clam Antivirus patchset (rar3 and 7-zip support)
>    missing patch for unrar, error in clamav install and in latest
release there
> is internal support for unrar e 7zip
> 
> - Kernel Magic Sysrq
>    freeze build process (in prepare), maybe a interactive input but I
have
> not investigate
> 
> - kid for sagator (if you use webq() for check false-positive), from
> changelog:
>    from 1.2.x python-kid replaced by python-genshi (kid can be deleted
> from devil src!)
>    from 1.3.x python-jinja replace python-genshi (will be obsolete
!??!)
> 
> 
> 
> Delete packages (IMHO):
> - scponly
>    from 0.5 OpenSSH has chroot per user
> 
> 
> 
> At last a question, is correct that:
> install: cfg_runlevel                             log:
> /build/tmp/LOGS/install/cfg_runlevel
> install: copy_libs                                log:
> /build/tmp/LOGS/install/copy_libs
> install: devildoc                                 log:
> /build/tmp/LOGS/install/devildoc
> install: man-pages                                log:
> /build/tmp/LOGS/install/man-pages
> install: cd_cleanup                               log:
> /build/tmp/LOGS/install/cd_cleanup
> install: finalize                                 log:
> /build/tmp/LOGS/install/finalize
> install: setfiledates                             log:
> /build/tmp/LOGS/install/setfiledates
> 
> runs before Makefile.install.custom scripts?
> install: gettext                                  log:
> /build/tmp/LOGS/install/gettext
> install: GeoIP                                    log:
> /build/tmp/LOGS/install/GeoIP
> install: MailScanner                              log:
> /build/tmp/LOGS/install/MailScanner
> install: subversion                               log:
> /build/tmp/LOGS/install/subversion
> install: alby                                     log:
> /build/tmp/LOGS/install/alby
> install: git                                      log:
> /build/tmp/LOGS/install/git
> 
> for example, I must add some users in passwd but
> passwd/group/shadow is already copy in $ETCDIR/etc
> 
> Please keep up your great work
> Alby

Hey,

I'm wondering if it wouldn't make sense to automatically add the "dev
$DEVICE".

Heiko

> -----Original Message-----
> From: Serge Leschinsky [mailto:ser...@gm...]
> Sent: Sunday, August 29, 2010 1:52 AM
> To: dev...@li...
> Subject: Re: [Devil-linux-develop] network configuration script - add
> routes
> 
> 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 the 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
> >>
> >>
> >>
> 
> 
>
------------------------------------------------------------------------
------
> 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

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

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

Hi all,
as usual a very long time!!

I tested 1.4 and it's a nice work.
Below there is a report and some changes that I have used, in attach
there is the patchset.
if some things are unclear please feel free to ask

Update src:
  clamav-0.96.2
  httpd-2.2.16 (security)
  libpng-1.2.44 (security)
  MailScanner-4.81.3-1
  mhash-0.9.9.9
  netpbm-10.35.76
  openldap-2.4.23 (security)
  p7zip_9.13
  php-5.2.14 (security)
  shorewall-4.4.12
  sudo-1.7.4p2
  syslog-ng_3.0.8
  tnef-1.4.7
  unrarsrc-3.9.10



Update src/perl-ext: (usefull for MailScanner also)
  Compress-Raw-Bzip2-2.030
  Compress-Raw-Zlib-2.030
  Compress-Zlib-2.015.tar.gz
  DBD-mysql-4.017
  DBD-Pg-2.17.1
  DBD-SQLite-1.29
  HTML-Parser-3.66
  Mail-SPF-v2.007.tar.gz
  MIME-Base64-3.09
  MIME-tools-5.428



Typo in: scripts/config/perl-ext
  Crypt-OpenSSL (not exist)
  IP-Country (2 items)
  Pod-Readme (2 items)

I have many warning in perl-ext for missing modules (but some installed after),
look for perl-ext/perl-ext and perl-ext/perl-ext.info with some adjusts



Typo(?) in: Makefile.build
  git is in GROUP_20 and GROUP_X



Patchs:
  *dovecot_sqlite (add sqlite support)
  *httpd_ldap_dbd (add ldap and dbd (mysql/pgsql) auth and rewrite support)
  *php_plus (add soap, wddx, ldap-sasl, exif, pcntl for phpsysinfo,
etc.. and close to devil)
  *clam_patchset-config_p7zip (drop Clam patchset (look below), and
add p7zip config)
  *update MySQL-python and python-ldap from 2.4 to new python versions
  *Denyhosts (debian patch and close to)
    +add denyhosts_2.6-7.diff.gz in src
    -drop src/denyhosts_2.5-3.diff.gz and src/denyhosts.diff.gz
  *perl_typo (typo?)

  FOR COMPILE BUT NOT TESTED YET:
  *sagator_Genshi (close to devil and look below for kid) and Genshi script
    +necessary add Genshi-0.6.tar.gz in src
  *Mailscanner_scripts (there is in src but not config)
    +necessary add in perl-ext: Sys-SigAction-0.11.tar.gz



Problems:
- Clam Antivirus patchset (rar3 and 7-zip support)
   missing patch for unrar, error in clamav install and in latest
release there is internal support for unrar e 7zip

- Kernel Magic Sysrq
   freeze build process (in prepare), maybe a interactive input but I
have not investigate

- kid for sagator (if you use webq() for check false-positive), from changelog:
   from 1.2.x python-kid replaced by python-genshi (kid can be deleted
from devil src!)
   from 1.3.x python-jinja replace python-genshi (will be obsolete !??!)



Delete packages (IMHO):
- scponly
   from 0.5 OpenSSH has chroot per user



At last a question, is correct that:
install: cfg_runlevel                             log:
/build/tmp/LOGS/install/cfg_runlevel
install: copy_libs                                log:
/build/tmp/LOGS/install/copy_libs
install: devildoc                                 log:
/build/tmp/LOGS/install/devildoc
install: man-pages                                log:
/build/tmp/LOGS/install/man-pages
install: cd_cleanup                               log:
/build/tmp/LOGS/install/cd_cleanup
install: finalize                                 log:
/build/tmp/LOGS/install/finalize
install: setfiledates                             log:
/build/tmp/LOGS/install/setfiledates

runs before Makefile.install.custom scripts?
install: gettext                                  log:
/build/tmp/LOGS/install/gettext
install: GeoIP                                    log:
/build/tmp/LOGS/install/GeoIP
install: MailScanner                              log:
/build/tmp/LOGS/install/MailScanner
install: subversion                               log:
/build/tmp/LOGS/install/subversion
install: alby                                     log:
/build/tmp/LOGS/install/alby
install: git                                      log:
/build/tmp/LOGS/install/git

for example, I must add some users in passwd but passwd/group/shadow
is already copy in $ETCDIR/etc

Please keep up your great work
Alby

I did remove the mactab feature from CVS.
I had to manually merge a few lines from Serge's last change, so
hopefully I didn't fat-finger anything.

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

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

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

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

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

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

Thanks  :-) , let me know of course if there are any issues with it.

Dominic

On 13/08/2010 12:49, Heiko Zuerker wrote:
> Thanks for the submission, I think this is a very good idea.
> We'll be adding it to DL as soon as one of us gets a chance.
>
> Heiko
>
> Quoting Dominic Raferd<dl...@ed...>:
>> I have developed a Windows script (batch file) which I have called
>> win-install-dl-on-usb, which like the existing install-on-usb linux
>> script can install DL to USB drive, performing formatting, making it
>> bootable etc...

Thanks for the submission, I think this is a very good idea.
We'll be adding it to DL as soon as one of us gets a chance.

Heiko

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

> I have developed a Windows script (batch file) which I have called
> win-install-dl-on-usb, which like the existing install-on-usb linux
> script can install DL to USB drive, performing formatting, making it
> bootable etc. I think it would be a good addition, requiring only 3
> small files in the base directory of the release bundle (same location
> as install-on-usb).
>
> It is aimed primarily at newcomers to DL - makes it easier to get
> started. Installation to USB has previously been very difficult unless
> you already have a Linux-based machine. It does not offer any option to
> save a configuration, but if you already have a configuration on another
> partition of the USB drive, or on another drive, it could be used for OS
> upgrading.
>
> The script includes safety and runtime-error checking, and installation
> is only permitted to a removable drive (so users should not be able to
> wipe their hard disk).
>
> As well as the batch file, it requires 2 open source programs:
> syslinux.exe and fart.exe (yes I know, but it is apparently short for
> find-and-replace-text). All 3 can be found in my Mantis submission at
> https://sourceforge.net/apps/mantisbt/devil-linux/view.php?id=83. It
> also requires an installation of 7-Zip (http://www.7-zip.org), which is
> worth having anyway IMO.
>
> It has been tested under Windows XP 32-bit and Vista 32-bit, but I would
> welcome more testing especially under Windows 7 and/or under 64-bit
> Windows. If it fails, a snapshot of the screen would help me narrow down
> the problem.
>
> Dominic
>
> ------------------------------------------------------------------------------
> 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.

I have developed a Windows script (batch file) which I have called 
win-install-dl-on-usb, which like the existing install-on-usb linux 
script can install DL to USB drive, performing formatting, making it 
bootable etc. I think it would be a good addition, requiring only 3 
small files in the base directory of the release bundle (same location 
as install-on-usb).

It is aimed primarily at newcomers to DL - makes it easier to get 
started. Installation to USB has previously been very difficult unless 
you already have a Linux-based machine. It does not offer any option to 
save a configuration, but if you already have a configuration on another 
partition of the USB drive, or on another drive, it could be used for OS 
upgrading.

The script includes safety and runtime-error checking, and installation 
is only permitted to a removable drive (so users should not be able to 
wipe their hard disk).

As well as the batch file, it requires 2 open source programs: 
syslinux.exe and fart.exe (yes I know, but it is apparently short for 
find-and-replace-text). All 3 can be found in my Mantis submission at 
https://sourceforge.net/apps/mantisbt/devil-linux/view.php?id=83. It 
also requires an installation of 7-Zip (http://www.7-zip.org), which is 
worth having anyway IMO.

It has been tested under Windows XP 32-bit and Vista 32-bit, but I would 
welcome more testing especially under Windows 7 and/or under 64-bit 
Windows. If it fails, a snapshot of the screen would help me narrow down 
the problem.

Dominic

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

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
>



-- 

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


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

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

Hi,

I finally found some time to test /etc/mactab a little bit more and I
discovered, that the handling of /etc/mactab is not working as expected.

See bug 82 for details and a possible patch.

In short:

Suppose you have the following interfaces, which the kernel assigns
during startup

eth0 -> MAC A
eth1 -> MAC B
eth2 -> MAC C

Now /etc/mactab defines

eth0 -> MAC C
eth1 -> MAC A
eth2 -> MAC B

But /sbin/nameif will fail, as eth0 cannot be assigned to MAC C because
eth2 already uses it.

To work around this problem, I reassigned eth0 to eth000 (just append
'00'). Then after every interface defined in /etc/mactab now reads
something like eth000, eth100, ... just let /sbin/nameif run without any
options. In this case nameif reads /etc/mactab and performs the correct
reassignment.

Regards,
Stefan

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...>
> 
> ------------------------------------------------------------------------------
> 
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
> 
> 

On 06/09/10 19:32, Serge Leschinsky wrote:

> CTERA has developed an open-source file system named Next3, based on the
> ubiquitous Ext3 file system, for the purpose of supporting enterprise-grade
> snapshot capabilities.
> 
> Next3 provides the ability to create highly-efficient multiple snapshots that
> create restore points for the entire volume, with minimal impact on file system
> performance.

Doesn't LVM do this?  For any filesystem too.  I'm not sure what the pros and
cons of this approach are.  I'd wait for some user demand.

Dick

-- 
Dick Middleton
di...@fo...
PGP Key ID: 0x9F9434FD

I'd say put it on the list for 1.5, we really need to stop messing  
with 1.4 and release the official version (btw, I just uploaded RC4,  
still need to announce it)

Heiko

Quoting Serge Leschinsky <fi...@in...>:

> http://www.ctera.com/home/next3.html
>
>
> Next3 File System
> Next3®: Enabling Thin Provisioned Snapshots
>
> CTERA has developed an open-source file system named Next3, based on the
> ubiquitous Ext3 file system, for the purpose of supporting enterprise-grade
> snapshot capabilities.
>
> Next3 provides the ability to create highly-efficient multiple snapshots that
> create restore points for the entire volume, with minimal impact on  
> file system
> performance. The Next3 snapshots use dynamically allocated space, so  
> there is no
> need to pre-allocate and waste valuable space on the disk for snapshots, and
> unused space is automatically recovered for file system use.
>
>
> Key Features
>
>     * Dynamic allocation of disk space for snapshot use
>     * Deleted snapshot space automatically recovered for file system use
>     * Supports multiple snapshots with no deterioration in performance
>     * Forward and backward compatible with Ext3
>
>
> Serge
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> 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.

http://www.ctera.com/home/next3.html


Next3 File System
Next3®: Enabling Thin Provisioned Snapshots

CTERA has developed an open-source file system named Next3, based on the
ubiquitous Ext3 file system, for the purpose of supporting enterprise-grade
snapshot capabilities.

Next3 provides the ability to create highly-efficient multiple snapshots that
create restore points for the entire volume, with minimal impact on file system
performance. The Next3 snapshots use dynamically allocated space, so there is no
need to pre-allocate and waste valuable space on the disk for snapshots, and
unused space is automatically recovered for file system use.
		
		
Key Features

    * Dynamic allocation of disk space for snapshot use
    * Deleted snapshot space automatically recovered for file system use
    * Supports multiple snapshots with no deterioration in performance
    * Forward and backward compatible with Ext3


Serge

Hey,

 

Does anyone see an issue with setting CONFIG_NLS_DEFAULT to UTF8 for the
kernel?

 

Regards

  Heiko Zuerker

  http://www.devil-linux.org