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

Hi Frank,

> is ipsec supposed to be working in 1.4RC2?

I'm using one IPsec tunnel between 1.4RC2 (exactly ipsec-tools-0.7.2) and 
Cisco router in one of my departaments. This connection is stable.

But rest 12 tunnels are running on OpenVPN. I prefer this solution.

Regards

-- 
Andrzej Odyniec

Hi,

is ipsec supposed to be working in 1.4RC2?

I have some trouble with it, but I don't know if this is due to my
ignorance regarding ipsec in 2.6.

One thing I have seen is this:
I made a Tunnel between an DL-1.4RC2 box and an DL-1.2.15 box.

>From the 1.2.15 side I can ping a host behind the DL-1.4RC2 through the
tunnel.

The other way round it won't work: in fact the DL-1.4RC2 doesn't seem to
know that this traffic must go through the tunnel; I get
'adminstratively prohibited' replies from the default gw on the
DL-1.4RC2 side...


Am I missing something really obvious?

Thanks a lot

Frank
-- 
_______________________________________________
 Centre de Technologie de l'Education
 29 avenue John F. Kennedy
 L-1855 Luxembourg-Kirchberg
 email: Fra...@ct...
 tél.: +352 247-85973
 fax: +352 333797
_______________________________________________

Ooops, sorry for that.

Right now we don't really know which packages compile file with -j X, should
we remove the parameter from all scripts and slowly turn it back on script
by script?
This way we could make certain the packages compile fine and we could just
turn it on for the big ones. We may also be able to increase the value for
-j.

Thoughts? Comments?

Heiko

> -----Original Message-----
> From: Andrzej Odyniec [mailto:an...@ma...]
> Sent: Friday, October 02, 2009 7:31 PM
> To: dev...@li...
> Subject: Re: [Devil-linux-develop] Compilation problems...
> 
> Hi,
> 
> I think, reduction of CONFIG_PMAKE was fine decision, but:
> 
> in build-iso script now is no value for -p parameter in mkzftree
> command and
> ISO build stops with error. I changed it temporarily in my set to:
> 
> mkzftree -z 9 -p $CONFIG_PARALLEL_JOBS $CDDIR $CDDIR.z
> 
> and now ISO build was done :)
> 
> BTW: I think, in linux script making need -j $CONFIG_PARALLEL_JOBS
> because
> linux is compiling alone consuming relive long time, and with -j 1
> especially
> on my machine three cores are iddle.
> 
> Best regards
> 
> Andrzej Odyniec
> 
> -----------------------------------------------------------------------
> -------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart
> your
> developing skills, take BlackBerry mobile applications to market and
> stay
> ahead of the curve. Join us from November 9-12, 2009. Register
> now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop

Hi,

I think, reduction of CONFIG_PMAKE was fine decision, but:

in build-iso script now is no value for -p parameter in mkzftree command and 
ISO build stops with error. I changed it temporarily in my set to:

mkzftree -z 9 -p $CONFIG_PARALLEL_JOBS $CDDIR $CDDIR.z

and now ISO build was done :)

BTW: I think, in linux script making need -j $CONFIG_PARALLEL_JOBS because 
linux is compiling alone consuming relive long time, and with -j 1 especially 
on my machine three cores are iddle.

Best regards

Andrzej Odyniec

* Serge Leschinsky (fi...@in...) wrote:
> Philippe Weill wrote:
> > Hi everybody
> > 
> > we are testing a new firewall with 1.4RC2
> > 
> > network is bonding + vlan
> > routing is ospf
> > 
> > if we load the iptable_nat module
> > even without any nat and firewall rules
> > 
> > ospf is not working anymore
> > 2009/10/01 06:40:22 OSPF: Link State Acknowledgment: Neighbor[192.168.20.9] state Init is less than 
> > Exchange
> > 
> > any idea what we could test ?
> 
> Does tcpdump show normal OSPF negotiation?

Thanks for your replies, I finally found the problem. Good news, this is
not a bug !

The first problem is our IP address to the net is a private address
(192.168.x.x), so to communicate I added a SNAT rules for everythings
going outside our firewall to the net with a private address.

But OSPF must not be NAT, never, otherwise it does work.

The interesting is after, because we try to stop iptables rules to see
if the was problem was there.

Not let see what append.

Since the the NAT is added the connection must be tracked, to perform
the reverse NAT for the reply.
The timeout for such connection (OSPF use protocol 89, so a state less
connection, unlike tcp) is 300 second by default.

Restarting iptables does not flush the connection tracking table (which
is normal, you do not want to break connection because you restart
iptables rules). So everything with same protocol and IP is still NATed
up to timeout.

OSPF sent an HELLO every 30 seconds, which is less than the timeout, so
once ospfd is running, no chance to reach the conntrack timeout...

The solution is adding an iptable rules to not NAT OSPF (-p 89) and to
reboot the firewall to flush the connection tracking table.

Since everything work fine.

Regards.

-- 

Olivier Thauvin
CNRS  -  LATMOS
♖ ♘ ♗ ♕ ♔ ♗ ♘ ♖

I started with a clean lfssystem.

I didnt try the patch... I will try it this weekend

regards



On Thu, Oct 1, 2009 at 2:38 PM, Heiko Zuerker <he...@zu...> wrote:

> Never saw that error before.
> Did you start with a clean lfssystem?
> Did you try the patch?
>
> Heiko
>
> Quoting warptrosse <war...@gm...>:
>
> > Hi, I'm trying to build the last cvs revision, but when execute
> > "make install" (with default config), glibc gives me
> > following error:
> >
> >
>
> ========================================================================================================================
> > /usr/bin/install -c -m 644 ../sysdeps/ieee754/ieee754.h
> > /build/tmp/tmp.glibc.3250/usr/include/ieee754.h
> > gcc -fPIC -fno-stack-protector -U_FORTIFY_SOURCE -nonow -nopie
> > ../sysdeps/i386/fpu/ftestexcept.c -c -std=gnu99 -Wall -Winline
> > -Wwrite-strings -fmerge-all-constants -march=i686 -mtune=i686
> > -Wstrict-prototypes -mpreferred-stack-boundary=4  -fPIC
> > -Wno-uninitialized -D__NO_MATH_INLINES
> > -D__LIBC_INTERNAL_MATH_INLINES -I../include
> > -I/build/tmp/glibc-build/math -I/build/tmp/glibc-build
> > -I../sysdeps/i386/elf -I../nptl/sysdeps/unix/sysv/linux/i386/i686
> > -I../nptl/sysdeps/unix/sysv/linux/i386
> > -I../sysdeps/unix/sysv/linux/i386 -I../nptl/sysdeps/unix/sysv/linux
> > -I../nptl/sysdeps/pthread -I../sysdeps/pthread
> > -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu
> > -I../sysdeps/unix/common -I../sysdeps/unix/mman
> > -I../sysdeps/unix/inet -I../sysdeps/unix/sysv/i386
> > -I../nptl/sysdeps/unix/sysv -I../sysdeps/unix/sysv
> > -I../sysdeps/unix/i386 -I../nptl/sysdeps/unix -I../sysdeps/unix
> > -I../sysdeps/posix -I../sysdeps/i386/i686/fpu
> > -I../nptl/sysdeps/i386/i686 -I../sysdeps/i386/i686
> > -I../sysdeps/i386/i486 -I../nptl/sysdeps/i386/i486
> > -I../sysdeps/i386/fpu -I../nptl/sysdeps/i386 -I../sysdeps/i386
> > -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/ldbl-96
> > -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32
> > -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic
> > -I../nptl  -I.. -I../libio -I.  -D_LIBC_REENTRANT -include
> > ../include/libc-symbols.h  -DPIC -DSHARED -DNOT_IN_libc=1
> > -DIS_IN_libm=1    -o /build/tmp/glibc-build/math/ftestexcept.os -MD
> > -MP -MF /build/tmp/glibc-build/math/ftestexcept.os.dt -MT
> > /build/tmp/glibc-build/math/ftestexcept.os
> > /tmp/ccU9UrVB.s: Assembler messages:
> > /tmp/ccU9UrVB.s:44: Error: suffix or operands invalid for `fnstsw'
> > make[3]: *** [/build/tmp/glibc-build/math/ftestexcept.os] Error 1
> > make[3]: Leaving directory `/build/tmp/glibc-2.5.1/math'
> > make[2]: *** [math/subdir_install] Error 2
> > make[2]: Leaving directory `/build/tmp/glibc-2.5.1'
> > make[1]: *** [install] Error 2
> > make[1]: Leaving directory `/build/tmp/glibc-build'
> > ERROR
> > /build/scripts/glibc install failed
> > check log file /build/tmp/LOGS/install/glibc for details
> > make: *** [install] Error 1
> >
>
> ========================================================================================================================
> >
> > googling, I found this link
> > http://forums.gentoo.org/viewtopic-t-659645-start-0.html... anyone
> > have this problem too?
> >
> > regards
> >
> > --
> > WARPTROSSE {The knowledge of a man belongs to all the humanity}
>
> --
>
> Regards
>   Heiko Zuerker
> http://www.devil-linux.org
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>



-- 
WARPTROSSE {The knowledge of a man belongs to all the humanity}

Serge Leschinsky a écrit :
> Philippe Weill wrote:
>> Hi everybody
>>
>> we are testing a new firewall with 1.4RC2
>>
>> network is bonding + vlan
>> routing is ospf
>>
>> if we load the iptable_nat module
>> even without any nat and firewall rules
>>
>> ospf is not working anymore
>> 2009/10/01 06:40:22 OSPF: Link State Acknowledgment: Neighbor[192.168.20.9] state Init is less than 
>> Exchange
>>
>> any idea what we could test ?
> 
> Does tcpdump show normal OSPF negotiation?
> 
> Serge
> 

OK we found the problem
first we had a problem with a nat rule at boot
but as a side effect even when stopping firewall
iptables -t nat -Lnv doesn't show any rules

but bad nat continue with nf_conntrack (at least for 600 secondes )
root@sphinx:~ # more /proc/sys/net/netfilter/nf_conntrack_generic_timeout
600

removing nat module permit to ospf to work
but reloading the module before waiting 10 minutes make the problem to restart

thanks to have tried
hope this could help somebody else

-- 
  Weill Philippe -  Administrateur Systeme et Reseaux
  CNRS/UPMC/IPSL   LATMOS (UMR 8190)

Philippe Weill wrote:
> Hi everybody
> 
> we are testing a new firewall with 1.4RC2
> 
> network is bonding + vlan
> routing is ospf
> 
> if we load the iptable_nat module
> even without any nat and firewall rules
> 
> ospf is not working anymore
> 2009/10/01 06:40:22 OSPF: Link State Acknowledgment: Neighbor[192.168.20.9] state Init is less than 
> Exchange
> 
> any idea what we could test ?

Does tcpdump show normal OSPF negotiation?

Serge

Quoting Philippe Weill <phi...@ae...>:

> Hi everybody
>
> we are testing a new firewall with 1.4RC2
>
> network is bonding + vlan
> routing is ospf
>
> if we load the iptable_nat module
> even without any nat and firewall rules
>
> ospf is not working anymore
> 2009/10/01 06:40:22 OSPF: Link State Acknowledgment:  
> Neighbor[192.168.20.9] state Init is less than
> Exchange
>
> any idea what we could test ?

Are you using the latest and greatest 1.4 from the testing directory?  
Quagga got updated to 0.99.15 a short while back.
Did you find anything on the Quagga website?

-- 

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


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

Never saw that error before.
Did you start with a clean lfssystem?
Did you try the patch?

Heiko

Quoting warptrosse <war...@gm...>:

> Hi, I'm trying to build the last cvs revision, but when execute
> "make install" (with default config), glibc gives me
> following error:
>
>
========================================================================================================================
> /usr/bin/install -c -m 644 ../sysdeps/ieee754/ieee754.h
> /build/tmp/tmp.glibc.3250/usr/include/ieee754.h
> gcc -fPIC -fno-stack-protector -U_FORTIFY_SOURCE -nonow -nopie
> ../sysdeps/i386/fpu/ftestexcept.c -c -std=gnu99 -Wall -Winline
> -Wwrite-strings -fmerge-all-constants -march=i686 -mtune=i686
> -Wstrict-prototypes -mpreferred-stack-boundary=4  -fPIC   
> -Wno-uninitialized -D__NO_MATH_INLINES
> -D__LIBC_INTERNAL_MATH_INLINES -I../include
> -I/build/tmp/glibc-build/math -I/build/tmp/glibc-build
> -I../sysdeps/i386/elf -I../nptl/sysdeps/unix/sysv/linux/i386/i686
> -I../nptl/sysdeps/unix/sysv/linux/i386
> -I../sysdeps/unix/sysv/linux/i386 -I../nptl/sysdeps/unix/sysv/linux
> -I../nptl/sysdeps/pthread -I../sysdeps/pthread
> -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu
> -I../sysdeps/unix/common -I../sysdeps/unix/mman
> -I../sysdeps/unix/inet -I../sysdeps/unix/sysv/i386
> -I../nptl/sysdeps/unix/sysv -I../sysdeps/unix/sysv
> -I../sysdeps/unix/i386 -I../nptl/sysdeps/unix -I../sysdeps/unix
> -I../sysdeps/posix -I../sysdeps/i386/i686/fpu
> -I../nptl/sysdeps/i386/i686 -I../sysdeps/i386/i686
> -I../sysdeps/i386/i486 -I../nptl/sysdeps/i386/i486
> -I../sysdeps/i386/fpu -I../nptl/sysdeps/i386 -I../sysdeps/i386
> -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/ldbl-96
> -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32
> -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic
> -I../nptl  -I.. -I../libio -I.  -D_LIBC_REENTRANT -include
> ../include/libc-symbols.h  -DPIC -DSHARED -DNOT_IN_libc=1
> -DIS_IN_libm=1    -o /build/tmp/glibc-build/math/ftestexcept.os -MD
> -MP -MF /build/tmp/glibc-build/math/ftestexcept.os.dt -MT
> /build/tmp/glibc-build/math/ftestexcept.os
> /tmp/ccU9UrVB.s: Assembler messages:
> /tmp/ccU9UrVB.s:44: Error: suffix or operands invalid for `fnstsw'
> make[3]: *** [/build/tmp/glibc-build/math/ftestexcept.os] Error 1
> make[3]: Leaving directory `/build/tmp/glibc-2.5.1/math'
> make[2]: *** [math/subdir_install] Error 2
> make[2]: Leaving directory `/build/tmp/glibc-2.5.1'
> make[1]: *** [install] Error 2
> make[1]: Leaving directory `/build/tmp/glibc-build'
> ERROR
> /build/scripts/glibc install failed
> check log file /build/tmp/LOGS/install/glibc for details
> make: *** [install] Error 1
>
========================================================================================================================
>
> googling, I found this link
> http://forums.gentoo.org/viewtopic-t-659645-start-0.html... anyone
> have this problem too?
>
> regards
>
> -- 
> WARPTROSSE {The knowledge of a man belongs to all the humanity}

-- 

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

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

Hi everybody

we are testing a new firewall with 1.4RC2

network is bonding + vlan
routing is ospf

if we load the iptable_nat module
even without any nat and firewall rules

ospf is not working anymore
2009/10/01 06:40:22 OSPF: Link State Acknowledgment: Neighbor[192.168.20.9] state Init is less than 
Exchange

any idea what we could test ?
-- 
  Weill Philippe -  Administrateur Systeme et Reseaux
  CNRS/UPMC/IPSL   LATMOS (UMR 8190)

Hi, I'm trying to build the last cvs revision, but when execute "make
install" (with default config), glibc gives me following error:

========================================================================================================================
/usr/bin/install -c -m 644 ../sysdeps/ieee754/ieee754.h
/build/tmp/tmp.glibc.3250/usr/include/ieee754.h
gcc -fPIC -fno-stack-protector -U_FORTIFY_SOURCE -nonow -nopie
../sysdeps/i386/fpu/ftestexcept.c -c -std=gnu99 -Wall -Winline
-Wwrite-strings -fmerge-all-constants -march=i686 -mtune=i686
-Wstrict-prototypes -mpreferred-stack-boundary=4  -fPIC   -Wno-uninitialized
-D__NO_MATH_INLINES -D__LIBC_INTERNAL_MATH_INLINES -I../include
-I/build/tmp/glibc-build/math -I/build/tmp/glibc-build -I../sysdeps/i386/elf
-I../nptl/sysdeps/unix/sysv/linux/i386/i686
-I../nptl/sysdeps/unix/sysv/linux/i386 -I../sysdeps/unix/sysv/linux/i386
-I../nptl/sysdeps/unix/sysv/linux -I../nptl/sysdeps/pthread
-I../sysdeps/pthread -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu
-I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet
-I../sysdeps/unix/sysv/i386 -I../nptl/sysdeps/unix/sysv
-I../sysdeps/unix/sysv -I../sysdeps/unix/i386 -I../nptl/sysdeps/unix
-I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/i386/i686/fpu
-I../nptl/sysdeps/i386/i686 -I../sysdeps/i386/i686 -I../sysdeps/i386/i486
-I../nptl/sysdeps/i386/i486 -I../sysdeps/i386/fpu -I../nptl/sysdeps/i386
-I../sysdeps/i386 -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/ldbl-96
-I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754
-I../sysdeps/generic/elf -I../sysdeps/generic -I../nptl  -I.. -I../libio
-I.  -D_LIBC_REENTRANT -include ../include/libc-symbols.h  -DPIC -DSHARED
-DNOT_IN_libc=1 -DIS_IN_libm=1    -o
/build/tmp/glibc-build/math/ftestexcept.os -MD -MP -MF
/build/tmp/glibc-build/math/ftestexcept.os.dt -MT
/build/tmp/glibc-build/math/ftestexcept.os
/tmp/ccU9UrVB.s: Assembler messages:
/tmp/ccU9UrVB.s:44: Error: suffix or operands invalid for `fnstsw'
make[3]: *** [/build/tmp/glibc-build/math/ftestexcept.os] Error 1
make[3]: Leaving directory `/build/tmp/glibc-2.5.1/math'
make[2]: *** [math/subdir_install] Error 2
make[2]: Leaving directory `/build/tmp/glibc-2.5.1'
make[1]: *** [install] Error 2
make[1]: Leaving directory `/build/tmp/glibc-build'
ERROR
/build/scripts/glibc install failed
check log file /build/tmp/LOGS/install/glibc for details
make: *** [install] Error 1
========================================================================================================================

googling, I found this link
http://forums.gentoo.org/viewtopic-t-659645-start-0.html... anyone have this
problem too?

regards

-- 
WARPTROSSE {The knowledge of a man belongs to all the humanity}

Sorry for that....

> -----Original Message-----
> From: Andrzej Odyniec [mailto:an...@ma...]
> Sent: Sunday, September 13, 2009 8:07 AM
> To: dev...@li...
> Subject: [Devil-linux-develop] Compilation problems...
> 
> Dears,
> 
> Copmilation problems are (as for now) two:
> 1) libnetfilter_contrack now depends from pkgconfig but in "Required-
> Start:"
> there no dependency, so if compiling before pkgconfig, compilation
> stops

Fixed in CVS

> 2) lsof_4.82.tar.bz2 is not properly unpacked, (one level of packing to
> much),
> so build script stops

Uploaded the correct file.

Heiko

Dears,

Copmilation problems are (as for now) two:
1) libnetfilter_contrack now depends from pkgconfig but in "Required-Start:" 
there no dependency, so if compiling before pkgconfig, compilation stops
2) lsof_4.82.tar.bz2 is not properly unpacked, (one level of packing to much), 
so build script stops

Regards

-- 
Andrzej Odyniec

> -----Original Message-----
> From: Heiko Zuerker [mailto:he...@zu...]
> Sent: Friday, July 24, 2009 11:26 AM
> To: Devil-Linux Developer Mailinglist; Devil-Linux Discuss Mailinglist
> Subject: [Devil-Linux-discuss] new testing release
> 
> I uploaded a new testing release to the FTP server.
> 
> If you did submit bugs, please download and test if they're resolved
> now.
> Please respond to your bugs, so we can close them if they're fixed.

I uploaded the latest testing version to the FTP server.

Heiko

The menuconfig part is actually pretty simple, take a look at what we're
doing in scripts/configuration and scripts/configuration/help

Heiko

> -----Original Message-----
> From: Andrzej Odyniec [mailto:an...@ma...]
> Sent: Tuesday, September 08, 2009 5:13 AM
> To: dev...@li...
> Subject: Re: [Devil-linux-develop] Should I try to compile Digium
> Asterisk into Devil-Linux?
> 
> Heiko Zuerker wrote:
> 
> > I never tried compiling it and I'm not aware of anyone else trying.
> 
> Thanks for answer. So I will. I think, I will write scripts for
> compilation
> correctly, but for menu for make menuconfig I will need help.
> 
> Asterisk need many other packages, not present in DL yet. So for this I
> need
> some weeks. After it I will test general functioning in real context of
> my
> company. This will need month or two.
> 
> I think -- after all it will be possible to connect Asterisk to
> development DL.
> 
> Best regards
> 
> Andrzej Odyniec
> 
> -----------------------------------------------------------------------
> -------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day
> trial. Simplify your report design, integration and deployment - and
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop

Heiko Zuerker wrote:

> I never tried compiling it and I'm not aware of anyone else trying.

Thanks for answer. So I will. I think, I will write scripts for compilation 
correctly, but for menu for make menuconfig I will need help.

Asterisk need many other packages, not present in DL yet. So for this I need 
some weeks. After it I will test general functioning in real context of my 
company. This will need month or two.

I think -- after all it will be possible to connect Asterisk to development DL.

Best regards

Andrzej Odyniec

I never tried compiling it and I'm not aware of anyone else trying.

Heiko

> -----Original Message-----
> From: Andrzej Odyniec [mailto:an...@ma...]
> Sent: Friday, September 04, 2009 11:38 AM
> To: dev...@li...
> Subject: [Devil-linux-develop] Should I try to compile Digium Asterisk
> into Devil-Linux?
> 
> Dears,
> 
> I'm trying last days to compile Digium Asterisk 1.6 into DL.
> But now I asked myself a question: maybe this is done by anyone of You?
> If not, I will try to do it. I think, this is important component in
> modern
> router.
> 
> Regards
> 
> Andrzej Odyniec
> 
> -----------------------------------------------------------------------
> -------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day
> trial. Simplify your report design, integration and deployment - and
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop

Dears,

I'm trying last days to compile Digium Asterisk 1.6 into DL.
But now I asked myself a question: maybe this is done by anyone of You?
If not, I will try to do it. I think, this is important component in modern 
router.

Regards

Andrzej Odyniec

>>>>>>>> Syslog-ng works fine with the default config, but not if you upgrade
>>>>>>>> an older system.
>>>>>>>> Can we add something simple to upgrade-config to make the upgrade
>>>>>>>> life easier?
>>>>>>>
>>>>>>> Hmm... Probably we can try to apply the diff for syslog-ng config,
>>>>>>> I think on
>>>>>>> most systems the diff should apply, because the changes affect only
>>>>>>> main options.
>>>>>>
>>>>>> It shouldn't be a problem unless they customized their syslog-ng config.
>>>>>> And if they customized it, there is a really good chance a patch
>>>>>> would fail.
>>>>>>
>>>>>> I'm not sure of the best solution for this.
>>>>>
>>>>> There's not too much we can do if folks change their config files, but
>>>>> I think we should be able to modify those specific lines if they're
>>>>> not changed.
>>>>
>>>> If the config file hasn't changed, it should update to the new version
>>>> by default.  Isn't that the way it works?
>>>
>>> That is correct.
>>> But isn't it highly likely that somebody added lines for i.e. a remote
>>> log? At least I have all my servers set up this way.
>>
>> It seems like the last time I looked, those lines are already in the
>> config file commented out, so all you have to do is uncomment them.
>>
>> And I don't think a patch will work on a line that has changed at all.
>>  Even just a "#" removed.
>
> Another options would be using sed and just replacing the lines in question.

That would stand a much better chance of working (IMO).

 - BS

Quoting Bruce Smith <bw...@re...>:

>>>>>>> Syslog-ng works fine with the default config, but not if you upgrade
>>>>>>> an older system.
>>>>>>> Can we add something simple to upgrade-config to make the upgrade
>>>>>>> life easier?
>>>>>>
>>>>>> Hmm... Probably we can try to apply the diff for syslog-ng config,
>>>>>> I think on
>>>>>> most systems the diff should apply, because the changes affect only
>>>>>> main options.
>>>>>
>>>>> It shouldn't be a problem unless they customized their syslog-ng config.
>>>>> And if they customized it, there is a really good chance a patch
>>>>> would fail.
>>>>>
>>>>> I'm not sure of the best solution for this.
>>>>
>>>> There's not too much we can do if folks change their config files, but
>>>> I think we should be able to modify those specific lines if they're
>>>> not changed.
>>>
>>> If the config file hasn't changed, it should update to the new version
>>> by default.  Isn't that the way it works?
>>
>> That is correct.
>> But isn't it highly likely that somebody added lines for i.e. a remote
>> log? At least I have all my servers set up this way.
>
> It seems like the last time I looked, those lines are already in the
> config file commented out, so all you have to do is uncomment them.
>
> And I don't think a patch will work on a line that has changed at all.
>  Even just a "#" removed.

Another options would be using sed and just replacing the lines in question.

-- 

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


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

>>>>>> Syslog-ng works fine with the default config, but not if you upgrade
>>>>>> an older system.
>>>>>> Can we add something simple to upgrade-config to make the upgrade
>>>>>> life easier?
>>>>>
>>>>> Hmm... Probably we can try to apply the diff for syslog-ng config,
>>>>> I think on
>>>>> most systems the diff should apply, because the changes affect only
>>>>> main options.
>>>>
>>>> It shouldn't be a problem unless they customized their syslog-ng config.
>>>> And if they customized it, there is a really good chance a patch
>>>> would fail.
>>>>
>>>> I'm not sure of the best solution for this.
>>>
>>> There's not too much we can do if folks change their config files, but
>>> I think we should be able to modify those specific lines if they're
>>> not changed.
>>
>> If the config file hasn't changed, it should update to the new version
>> by default.  Isn't that the way it works?
>
> That is correct.
> But isn't it highly likely that somebody added lines for i.e. a remote
> log? At least I have all my servers set up this way.

It seems like the last time I looked, those lines are already in the
config file commented out, so all you have to do is uncomment them.

And I don't think a patch will work on a line that has changed at all.
 Even just a "#" removed.

 - BS

Quoting Bruce Smith <bw...@re...>:

>>>>> Syslog-ng works fine with the default config, but not if you upgrade
>>>>> an older system.
>>>>> Can we add something simple to upgrade-config to make the upgrade
>>>>> life easier?
>>>>
>>>> Hmm... Probably we can try to apply the diff for syslog-ng config,
>>>> I think on
>>>> most systems the diff should apply, because the changes affect only
>>>> main options.
>>>
>>> It shouldn't be a problem unless they customized their syslog-ng config.
>>> And if they customized it, there is a really good chance a patch  
>>> would fail.
>>>
>>> I'm not sure of the best solution for this.
>>
>> There's not too much we can do if folks change their config files, but
>> I think we should be able to modify those specific lines if they're
>> not changed.
>
> If the config file hasn't changed, it should update to the new version
> by default.  Isn't that the way it works?

That is correct.
But isn't it highly likely that somebody added lines for i.e. a remote  
log? At least I have all my servers set up this way.

-- 

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


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

>>>> Syslog-ng works fine with the default config, but not if you upgrade
>>>> an older system.
>>>> Can we add something simple to upgrade-config to make the upgrade
>>>> life easier?
>>>
>>> Hmm... Probably we can try to apply the diff for syslog-ng config,
>>> I think on
>>> most systems the diff should apply, because the changes affect only
>>> main options.
>>
>> It shouldn't be a problem unless they customized their syslog-ng config.
>> And if they customized it, there is a really good chance a patch would fail.
>>
>> I'm not sure of the best solution for this.
>
> There's not too much we can do if folks change their config files, but
> I think we should be able to modify those specific lines if they're
> not changed.

If the config file hasn't changed, it should update to the new version
by default.  Isn't that the way it works?

 - BS

Quoting Bruce Smith <bw...@re...>:

>>> Syslog-ng works fine with the default config, but not if you upgrade
>>> an older system.
>>> Can we add something simple to upgrade-config to make the upgrade  
>>> life easier?
>>
>> Hmm... Probably we can try to apply the diff for syslog-ng config,  
>> I think on
>> most systems the diff should apply, because the changes affect only  
>> main options.
>
> It shouldn't be a problem unless they customized their syslog-ng config.
> And if they customized it, there is a really good chance a patch would fail.
>
> I'm not sure of the best solution for this.

There's not too much we can do if folks change their config files, but  
I think we should be able to modify those specific lines if they're  
not changed.

-- 

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


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