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

>> After fixing a problem, what is the correct way to update Mantis?
>>
>> I see two possible options.  Change it to "closed" or "resolved"?
>> I'm not sure I understand the difference (and have been using closed).
>>
>> >From the stats, there are a number of both "closed" & "resolved"
>> issues, so I may not be the only one who's not sure.
>
> Not sure if I remember right, but I think this is what Serge suggested (and
> I agreed):
> Set issue to 'resolved" once you think it's fixed, then 'close' it once the
> user confirms that it's fixed.
>
> Now that I think of it, this really depends on the user getting back to
> us....
> We could just 'close' them, it is pretty simple in Mantis to reopen the
> issue. This would keep things quite a bit cleaner.
>
> Thoughts?

I'm fine with just closing them.

I guess we could use "resolved" if there is some doubt about the fix
and user confirmation is wanted.

 - BS

> -----Original Message-----
> From: Bruce Smith [mailto:bw...@re...]
> Sent: Thursday, November 05, 2009 2:56 PM
> To: Devil Linux
> Subject: [Devil-linux-develop] Closing Mantis issues.
> 
> After fixing a problem, what is the correct way to update Mantis?
> 
> I see two possible options.  Change it to "closed" or "resolved"?
> I'm not sure I understand the difference (and have been using closed).
> 
> >From the stats, there are a number of both "closed" & "resolved"
> issues, so I may not be the only one who's not sure.

Not sure if I remember right, but I think this is what Serge suggested (and
I agreed):
Set issue to 'resolved" once you think it's fixed, then 'close' it once the
user confirms that it's fixed.

Now that I think of it, this really depends on the user getting back to
us....
We could just 'close' them, it is pretty simple in Mantis to reopen the
issue. This would keep things quite a bit cleaner.

Thoughts?

Heiko

After fixing a problem, what is the correct way to update Mantis?

I see two possible options.  Change it to "closed" or "resolved"?
I'm not sure I understand the difference (and have been using closed).

>From the stats, there are a number of both "closed" & "resolved"
issues, so I may not be the only one who's not sure.

 - BS

Bruce Smith wrote:

>>
>> To test other thing I temporary disabled "make test" in coreutils script.
> 
> I don't see "make test" in the coreutils scripts.
> There is a "make check".  Is that what you removed?
Exactly. Sorry for confusing.

Serge

>> executing coreutils with option build (in /data/build/tmp/coreutils-7.5)
>> *** %n in writable segment detected ***
>> ERROR
>> /data/build/scripts/coreutils build failed
>> check log file /data/build/tmp/LOGS/build/coreutils for details
>> make: *** [build] Error 1
>
> Bruce, due to some personal reasons, I cannot investigate it deeply. Prima facie
> , it's the result of failed test. At least on my system it is so

I restarted the make build, and it completed the second time.
Then I started over with a new LFSsystem and mrproper,
and it's not done yet, but is past the build of coreutils.

>  1 of 290 tests failed
>  (91 tests were not run)
>  See tests/test-suite.log
>  Please report to bug...@gn...
>
> To test other thing I temporary disabled "make test" in coreutils script.

I don't see "make test" in the coreutils scripts.
There is a "make check".  Is that what you removed?

 - BS

Bruce Smith wrote:
> New lfs / mrproper compile last night (logfile attached):
> 
> 
> executing conntrack-tools with option build (in
> /data/build/tmp/conntrack-tools-0.9.13)
> 
> executing coreutils with option build (in /data/build/tmp/coreutils-7.5)
> *** %n in writable segment detected ***
> ERROR
> /data/build/scripts/coreutils build failed
> check log file /data/build/tmp/LOGS/build/coreutils for details
> make: *** [build] Error 1
> 

Bruce, due to some personal reasons, I cannot investigate it deeply. Prima facie
, it's the result of failed test. At least on my system it is so

 1 of 290 tests failed
 (91 tests were not run)
 See tests/test-suite.log
 Please report to bug...@gn...

To test other thing I temporary disabled "make test" in coreutils script.


Serge

>> executing conntrack-tools with option build (in
>> /data/build/tmp/conntrack-tools-0.9.13)
>>
>> executing coreutils with option build (in /data/build/tmp/coreutils-
>> 7.5)
>> *** %n in writable segment detected ***
>> ERROR
>> /data/build/scripts/coreutils build failed check log file
>> /data/build/tmp/LOGS/build/coreutils for details
>> make: *** [build] Error 1
>
> My nightly build went through without any problems.
>
> It seems it failed here: FAIL: tail-2/pid (exit: 1).
> sed: can't read /proc/15684/status: No such file or directory
>
> Did you proc filesystem  within the lfssystem got unmounted for some reason?
> Or maybe that process died all the sudden. Not really sure.

Donno.  I'll add the couple updates you just committed and start over.

 - BS

> -----Original Message-----
> From: Bruce Smith [mailto:bw...@re...]
> Sent: Thursday, November 05, 2009 7:59 AM
> To: Devil Linux
> Subject: [Devil-linux-develop] Help, build abort... :-(
> 
> New lfs / mrproper compile last night (logfile attached):
> 
> 
> executing conntrack-tools with option build (in
> /data/build/tmp/conntrack-tools-0.9.13)
> 
> executing coreutils with option build (in /data/build/tmp/coreutils-
> 7.5)
> *** %n in writable segment detected ***
> ERROR
> /data/build/scripts/coreutils build failed check log file
> /data/build/tmp/LOGS/build/coreutils for details
> make: *** [build] Error 1

My nightly build went through without any problems.

It seems it failed here: FAIL: tail-2/pid (exit: 1).
sed: can't read /proc/15684/status: No such file or directory

Did you proc filesystem  within the lfssystem got unmounted for some reason?
Or maybe that process died all the sudden. Not really sure.

Heiko
 

New lfs / mrproper compile last night (logfile attached):


executing conntrack-tools with option build (in
/data/build/tmp/conntrack-tools-0.9.13)

executing coreutils with option build (in /data/build/tmp/coreutils-7.5)
*** %n in writable segment detected ***
ERROR
/data/build/scripts/coreutils build failed
check log file /data/build/tmp/LOGS/build/coreutils for details
make: *** [build] Error 1


 - BS

>>> We could go a completely new route:
>>> Setup is only very basic, just enough to get the network up and
>>> running. Then use Webmin for the rest.
>>> We would only need to add DL specific changes to Webmin, which has a
>>> pretty nice web interface. Webmin is all Perl.
>>
>> Aside from the fact I don't know perl, there are advantages and
>> disadvantages to both approaches.
>
> What a great learning opportunity. ;-)

I have no problem learning perl, if we decide webmin is the best way
to proceed.  (is it?)

I gave perl a try a few years ago.  I didn't have any project to
actually program in perl, so I didn't do much with it, and now I've
forgotten much of what I learned.  What I remember for sure is it was
a weird language!  :-)

 - BS

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

>> We could go a completely new route:
>> Setup is only very basic, just enough to get the network up and
>> running. Then use Webmin for the rest.
>> We would only need to add DL specific changes to Webmin, which has a
>> pretty nice web interface. Webmin is all Perl.
>
> Aside from the fact I don't know perl, there are advantages and
> disadvantages to both approaches.

What a great learning opportunity. ;-)

-- 

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


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

Bruce Smith wrote:

> The setup/console/curses approach requires physical access to the
> console of the machine (unless ssh is activated), making it much more
> secure.  Plus the lower resource requirements.  Of course the
> disadvantage is it's clunky to use and looks like crap.  That's why I
> was hoping there was something like 'dialog' that looked better and
> was easier to program.
> 
> Are the potential security risks worth going to a web based admin?
> More thoughts?  :-)

Personally, I have no interest whatsoever in a web based interface to set-up 
DL. Generally these things are a hindrance not a help. Rant suppressed :)

Dick

* Bruce Smith (bw...@re...) wrote:
> > We could go a completely new route:
> > Setup is only very basic, just enough to get the network up and
> > running. Then use Webmin for the rest.
> > We would only need to add DL specific changes to Webmin, which has a
> > pretty nice web interface. Webmin is all Perl.
> 
> Aside from the fact I don't know perl, there are advantages and
> disadvantages to both approaches.
> 
> The advantages of a web interface is it looks much nicer, easier to
> use, and easier to program (at least it would be in PHP).
> 
> The disadvantages of a web interface is it's a potential security
> hole.  This gives root access via a web interface to the machine, and
> someplace for bad people to brute force attach the password remotely.
> Without a certificate, passwords would be sent plain text across the
> network.  And it could accidentally be exposed to the internet.  One
> more disadvantage is the overhead of requiring a web server to be
> running all the time (increase the memory requirements!).

Security hole is not the fact of the language. How many php application
get buggy and have at lease one security update per month ?

I do myself application using perl + Catalyst framework. It is very easy
to create a secure web apps, and easier to test since Catalyst provide
in same way an autonomous server, cgi and fast-cgi.

The manrdriva Corporate server admin tools is a web apps using Catalyst.
Created by Raphael Garcia-Suarez, the authentication is done over PAM,
and allow to install packages, setup basis configuration, etc...

Catalyst:
http://www.catalystframework.org/

Here an example of web site in catalyst:
http://sophie.zarb.org/

I am not arging perl si the solution, just saying perl is not less
secure than php. Security problem in programming design are the same:
system() call with forged variable will have same effect everywhere,
especially since the command have to be ran as root.

The only thing making me saying than perl is more secure is perl is
ofter used by Sys-admin, more looking side effect on security than web
designer mostly using php (I hope it's the case ! :)

Regards.

> 
> The setup/console/curses approach requires physical access to the
> console of the machine (unless ssh is activated), making it much more
> secure.  Plus the lower resource requirements.  Of course the
> disadvantage is it's clunky to use and looks like crap.  That's why I
> was hoping there was something like 'dialog' that looked better and
> was easier to program.
> 
> Are the potential security risks worth going to a web based admin?
> More thoughts?  :-)
> 
>  - BS
> 
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) 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/devconference
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
-- 

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

> We could go a completely new route:
> Setup is only very basic, just enough to get the network up and
> running. Then use Webmin for the rest.
> We would only need to add DL specific changes to Webmin, which has a
> pretty nice web interface. Webmin is all Perl.

Aside from the fact I don't know perl, there are advantages and
disadvantages to both approaches.

The advantages of a web interface is it looks much nicer, easier to
use, and easier to program (at least it would be in PHP).

The disadvantages of a web interface is it's a potential security
hole.  This gives root access via a web interface to the machine, and
someplace for bad people to brute force attach the password remotely.
Without a certificate, passwords would be sent plain text across the
network.  And it could accidentally be exposed to the internet.  One
more disadvantage is the overhead of requiring a web server to be
running all the time (increase the memory requirements!).

The setup/console/curses approach requires physical access to the
console of the machine (unless ssh is activated), making it much more
secure.  Plus the lower resource requirements.  Of course the
disadvantage is it's clunky to use and looks like crap.  That's why I
was hoping there was something like 'dialog' that looked better and
was easier to program.

Are the potential security risks worth going to a web based admin?
More thoughts?  :-)

 - BS

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

> Right now the 'setup' program uses the "dialog" commands for curses  
> type menus.
>
> Does anyone know an alternative for "dialog"?
>
> I'm mainly looking for something that is easier to use from a bash
> script (dialog is a real pain).  Something that has nicer looking, and
> more powerful screens would be nice too.

We could go a completely new route:
Setup is only very basic, just enough to get the network up and  
running. Then use Webmin for the rest.
We would only need to add DL specific changes to Webmin, which has a  
pretty nice web interface. Webmin is all Perl.

Thoughts?

-- 

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


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

Bruce Smith wrote:
> Right now the 'setup' program uses the "dialog" commands for curses type menus.
> 
> Does anyone know an alternative for "dialog"?
> 
> I'm mainly looking for something that is easier to use from a bash
> script (dialog is a real pain).  Something that has nicer looking, and
> more powerful screens would be nice too.

There's whiptail but it's pretty much the same.

Dick

Right now the 'setup' program uses the "dialog" commands for curses type menus.

Does anyone know an alternative for "dialog"?

I'm mainly looking for something that is easier to use from a bash
script (dialog is a real pain).  Something that has nicer looking, and
more powerful screens would be nice too.

 - BS

Thanks,
I'll do one more build this night and then provide the needed scripts.


-----Ursprüngliche Nachricht-----
Von: Bruce Smith [mailto:bw...@re...]
Gesendet: Montag, 26. Oktober 2009 16:14
An: dev...@li...
Betreff: Re: [Devil-linux-develop] Keepalived

Since DL is not losing any functionality, and only gaining a package,
I don't see any problem adding keepalived to DL.

I uploaded keepalived source to the FTP site (1.3 dir).
Feel free to commit any time.

 - BS


> Hi Bruce,
> Both of them are individual packages.
> Currently I have heartbeat and keepalived on my ISOs, since I wanted to switch configurations in a few seconds.
>
> The main reason for me to switch was that I now have more than 200 virtual IP addresses on my boxes and heartbeat (with ldirectord) needs up to 60 seconds on my box to bring the ips up/down in case of failovers.
>
> Greetings,
> Björn
>
> -----Ursprüngliche Nachricht-----
> Von: Bruce Smith [mailto:bw...@re...]
> Gesendet: Montag, 26. Oktober 2009 15:35
> An: dev...@li...
> Betreff: Re: [Devil-linux-develop] Keepalived
>
> Do we need to replace heartbeat with keepalived, or can they both be
> on the CD allowing individuals to choose between the two?
>
>  - BS
>
>
>> Hi DL-Developers,
>>
>>
>> I have recently switched from heartbeat to keepalived for my LVS-director
>> software on the latest DL.
>>
>>
>> From the homepage:
>>
>> What is Keepalived ?
>>
>> The main goal of the keepalived project is to add a strong & robust
>> keepalive facility to the Linux Virtual Server project. This project is
>> written in C with multilayer TCP/IP stack checks. Keepalived implements a
>> framework based on three family checks : Layer3, Layer4 & Layer5/7. This
>> framework gives the daemon the ability of checking a LVS server pool states.
>> When one of the server of the LVS server pool is down, keepalived informs
>> the linux kernel via a setsockopt call to remove this server entrie from the
>> LVS topology. In addition keepalived implements an independent VRRPv2 stack
>> to handle director failover. So in short keepalived is a userspace daemon
>> for LVS cluster nodes healthchecks and LVS directors failover.
>>
>>
>>
>> IMHO: keepalived is the easier choice if one would only have some virtual ip
>> addresses with some realservers watched and there is no need to set up some
>> BIG cluster with harddisk failovers ore stonith-devices.
>>
>>
>>
>> Keepalived works great with conntrackd; conntrackd already provides a bunch
>> of sample-scripts in its /etc-directory to get things working.
>>
>>
>>
>> If you are interested in including keepalived in the DL distribution I could
>> check in the needed scripts.
>>
>>
>>
>> But one of you with FTP-Access would need to put
>> http://www.keepalived.org/software/keepalived-1.1.19.tar.gz into the src.
>>
>>
>>
>>
>> Mit freundlichen Grüßen/Kind regards,
>>
>> Björn Rudner
>> Systems Engineer
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) 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/devconference
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
> ____________________________________________________________________________
>
> baulogis GmbH
> Zamdorfer Str. 100
> 81677 München / Munich
> Deutschland / Germany
> www.baulogis.com
>
> Geschäftsführer / Managing Director: Thomas Bachmaier
> HRB 133832, Amtsgericht München
> Ust-ID: DE 212 020 193
>
>
> Der Inhalt dieser E-Mail ist vertraulich und ausschließlich für den bezeichneten Adressaten bestimmt.
> Wenn Sie nicht der vorgesehene Adressat dieser E-Mail oder dessen Vertreter sein sollten,
> so beachten Sie bitte, dass jede Form der Kenntnisnahme, Veröffentlichung,
> Vervielfältigung oder Wiedergabe des Inhalts dieser E-Mail unzulässig ist.
> Bitte setzen Sie sich in diesem Fall mit dem Absender der E-Mail in Verbindung (br...@ba...).
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) 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/devconference
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) 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/devconference
_______________________________________________
Devil-linux-develop mailing list
Dev...@li...
https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
____________________________________________________________________________

baulogis GmbH
Zamdorfer Str. 100
81677 München / Munich
Deutschland / Germany
www.baulogis.com

Geschäftsführer / Managing Director: Thomas Bachmaier
HRB 133832, Amtsgericht München
Ust-ID: DE 212 020 193


Der Inhalt dieser E-Mail ist vertraulich und ausschließlich für den bezeichneten Adressaten bestimmt.
Wenn Sie nicht der vorgesehene Adressat dieser E-Mail oder dessen Vertreter sein sollten,
so beachten Sie bitte, dass jede Form der Kenntnisnahme, Veröffentlichung,
Vervielfältigung oder Wiedergabe des Inhalts dieser E-Mail unzulässig ist.
Bitte setzen Sie sich in diesem Fall mit dem Absender der E-Mail in Verbindung (br...@ba...).

Since DL is not losing any functionality, and only gaining a package,
I don't see any problem adding keepalived to DL.

I uploaded keepalived source to the FTP site (1.3 dir).
Feel free to commit any time.

 - BS


> Hi Bruce,
> Both of them are individual packages.
> Currently I have heartbeat and keepalived on my ISOs, since I wanted to switch configurations in a few seconds.
>
> The main reason for me to switch was that I now have more than 200 virtual IP addresses on my boxes and heartbeat (with ldirectord) needs up to 60 seconds on my box to bring the ips up/down in case of failovers.
>
> Greetings,
> Björn
>
> -----Ursprüngliche Nachricht-----
> Von: Bruce Smith [mailto:bw...@re...]
> Gesendet: Montag, 26. Oktober 2009 15:35
> An: dev...@li...
> Betreff: Re: [Devil-linux-develop] Keepalived
>
> Do we need to replace heartbeat with keepalived, or can they both be
> on the CD allowing individuals to choose between the two?
>
>  - BS
>
>
>> Hi DL-Developers,
>>
>>
>> I have recently switched from heartbeat to keepalived for my LVS-director
>> software on the latest DL.
>>
>>
>> From the homepage:
>>
>> What is Keepalived ?
>>
>> The main goal of the keepalived project is to add a strong & robust
>> keepalive facility to the Linux Virtual Server project. This project is
>> written in C with multilayer TCP/IP stack checks. Keepalived implements a
>> framework based on three family checks : Layer3, Layer4 & Layer5/7. This
>> framework gives the daemon the ability of checking a LVS server pool states.
>> When one of the server of the LVS server pool is down, keepalived informs
>> the linux kernel via a setsockopt call to remove this server entrie from the
>> LVS topology. In addition keepalived implements an independent VRRPv2 stack
>> to handle director failover. So in short keepalived is a userspace daemon
>> for LVS cluster nodes healthchecks and LVS directors failover.
>>
>>
>>
>> IMHO: keepalived is the easier choice if one would only have some virtual ip
>> addresses with some realservers watched and there is no need to set up some
>> BIG cluster with harddisk failovers ore stonith-devices.
>>
>>
>>
>> Keepalived works great with conntrackd; conntrackd already provides a bunch
>> of sample-scripts in its /etc-directory to get things working.
>>
>>
>>
>> If you are interested in including keepalived in the DL distribution I could
>> check in the needed scripts.
>>
>>
>>
>> But one of you with FTP-Access would need to put
>> http://www.keepalived.org/software/keepalived-1.1.19.tar.gz into the src.
>>
>>
>>
>>
>> Mit freundlichen Grüßen/Kind regards,
>>
>> Björn Rudner
>> Systems Engineer
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) 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/devconference
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
> ____________________________________________________________________________
>
> baulogis GmbH
> Zamdorfer Str. 100
> 81677 München / Munich
> Deutschland / Germany
> www.baulogis.com
>
> Geschäftsführer / Managing Director: Thomas Bachmaier
> HRB 133832, Amtsgericht München
> Ust-ID: DE 212 020 193
>
>
> Der Inhalt dieser E-Mail ist vertraulich und ausschließlich für den bezeichneten Adressaten bestimmt.
> Wenn Sie nicht der vorgesehene Adressat dieser E-Mail oder dessen Vertreter sein sollten,
> so beachten Sie bitte, dass jede Form der Kenntnisnahme, Veröffentlichung,
> Vervielfältigung oder Wiedergabe des Inhalts dieser E-Mail unzulässig ist.
> Bitte setzen Sie sich in diesem Fall mit dem Absender der E-Mail in Verbindung (br...@ba...).
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) 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/devconference
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>

Hi Bruce,
Both of them are individual packages.
Currently I have heartbeat and keepalived on my ISOs, since I wanted to switch configurations in a few seconds.

The main reason for me to switch was that I now have more than 200 virtual IP addresses on my boxes and heartbeat (with ldirectord) needs up to 60 seconds on my box to bring the ips up/down in case of failovers.

Greetings,
Björn

-----Ursprüngliche Nachricht-----
Von: Bruce Smith [mailto:bw...@re...]
Gesendet: Montag, 26. Oktober 2009 15:35
An: dev...@li...
Betreff: Re: [Devil-linux-develop] Keepalived

Do we need to replace heartbeat with keepalived, or can they both be
on the CD allowing individuals to choose between the two?

 - BS


> Hi DL-Developers,
>
>
> I have recently switched from heartbeat to keepalived for my LVS-director
> software on the latest DL.
>
>
> From the homepage:
>
> What is Keepalived ?
>
> The main goal of the keepalived project is to add a strong & robust
> keepalive facility to the Linux Virtual Server project. This project is
> written in C with multilayer TCP/IP stack checks. Keepalived implements a
> framework based on three family checks : Layer3, Layer4 & Layer5/7. This
> framework gives the daemon the ability of checking a LVS server pool states.
> When one of the server of the LVS server pool is down, keepalived informs
> the linux kernel via a setsockopt call to remove this server entrie from the
> LVS topology. In addition keepalived implements an independent VRRPv2 stack
> to handle director failover. So in short keepalived is a userspace daemon
> for LVS cluster nodes healthchecks and LVS directors failover.
>
>
>
> IMHO: keepalived is the easier choice if one would only have some virtual ip
> addresses with some realservers watched and there is no need to set up some
> BIG cluster with harddisk failovers ore stonith-devices.
>
>
>
> Keepalived works great with conntrackd; conntrackd already provides a bunch
> of sample-scripts in its /etc-directory to get things working.
>
>
>
> If you are interested in including keepalived in the DL distribution I could
> check in the needed scripts.
>
>
>
> But one of you with FTP-Access would need to put
> http://www.keepalived.org/software/keepalived-1.1.19.tar.gz into the src.
>
>
>
>
> Mit freundlichen Grüßen/Kind regards,
>
> Björn Rudner
> Systems Engineer

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) 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/devconference
_______________________________________________
Devil-linux-develop mailing list
Dev...@li...
https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
____________________________________________________________________________

baulogis GmbH
Zamdorfer Str. 100
81677 München / Munich
Deutschland / Germany
www.baulogis.com

Geschäftsführer / Managing Director: Thomas Bachmaier
HRB 133832, Amtsgericht München
Ust-ID: DE 212 020 193


Der Inhalt dieser E-Mail ist vertraulich und ausschließlich für den bezeichneten Adressaten bestimmt.
Wenn Sie nicht der vorgesehene Adressat dieser E-Mail oder dessen Vertreter sein sollten,
so beachten Sie bitte, dass jede Form der Kenntnisnahme, Veröffentlichung,
Vervielfältigung oder Wiedergabe des Inhalts dieser E-Mail unzulässig ist.
Bitte setzen Sie sich in diesem Fall mit dem Absender der E-Mail in Verbindung (br...@ba...).

Do we need to replace heartbeat with keepalived, or can they both be
on the CD allowing individuals to choose between the two?

 - BS


> Hi DL-Developers,
>
>
> I have recently switched from heartbeat to keepalived for my LVS-director
> software on the latest DL.
>
>
> From the homepage:
>
> What is Keepalived ?
>
> The main goal of the keepalived project is to add a strong & robust
> keepalive facility to the Linux Virtual Server project. This project is
> written in C with multilayer TCP/IP stack checks. Keepalived implements a
> framework based on three family checks : Layer3, Layer4 & Layer5/7. This
> framework gives the daemon the ability of checking a LVS server pool states.
> When one of the server of the LVS server pool is down, keepalived informs
> the linux kernel via a setsockopt call to remove this server entrie from the
> LVS topology. In addition keepalived implements an independent VRRPv2 stack
> to handle director failover. So in short keepalived is a userspace daemon
> for LVS cluster nodes healthchecks and LVS directors failover.
>
>
>
> IMHO: keepalived is the easier choice if one would only have some virtual ip
> addresses with some realservers watched and there is no need to set up some
> BIG cluster with harddisk failovers ore stonith-devices.
>
>
>
> Keepalived works great with conntrackd; conntrackd already provides a bunch
> of sample-scripts in its /etc-directory to get things working.
>
>
>
> If you are interested in including keepalived in the DL distribution I could
> check in the needed scripts.
>
>
>
> But one of you with FTP-Access would need to put
> http://www.keepalived.org/software/keepalived-1.1.19.tar.gz into the src.
>
>
>
>
> Mit freundlichen Grüßen/Kind regards,
>
> Björn Rudner
> Systems Engineer

Hi DL-Developers,

I have recently switched from heartbeat to keepalived for my LVS-director software on the latest DL.

>From the homepage:
What is Keepalived ?
The main goal of the keepalived project is to add a strong & robust keepalive facility to the Linux Virtual Server project. This project is written in C with multilayer TCP/IP stack checks. Keepalived implements a framework based on three family checks : Layer3, Layer4 & Layer5/7. This framework gives the daemon the ability of checking a LVS server pool states. When one of the server of the LVS server pool is down, keepalived informs the linux kernel via a setsockopt call to remove this server entrie from the LVS topology. In addition keepalived implements an independent VRRPv2 stack to handle director failover. So in short keepalived is a userspace daemon for LVS cluster nodes healthchecks and LVS directors failover.

IMHO: keepalived is the easier choice if one would only have some virtual ip addresses with some realservers watched and there is no need to set up some BIG cluster with harddisk failovers ore stonith-devices.

Keepalived works great with conntrackd; conntrackd already provides a bunch of sample-scripts in its /etc-directory to get things working.

If you are interested in including keepalived in the DL distribution I could check in the needed scripts.

But one of you with FTP-Access would need to put http://www.keepalived.org/software/keepalived-1.1.19.tar.gz into the src.



Mit freundlichen Grüßen/Kind regards,

Björn Rudner
Systems Engineer

phone: +49 (89) 930 839-16<tel:+49-89-930839-16>
pers. fax.: 01805-456 987-200 16<fax:+49-1805-456987-20016>
mobile: +49 (151) 121 623 71
e-mail: br...@ba...<mailto:br...@ba...>


________________________________
baulogis GmbH
Zamdorfer Str. 100
81677 München / Munich
Deutschland / Germany
www.baulogis.com<http://www.baulogis.com/>

Geschäftsführer / Managing Director: Thomas Bachmaier
HRB 133832, Amtsgericht München
Ust-ID: DE 212 020 193

Der Inhalt dieser E-Mail ist vertraulich und ausschließlich für den bezeichneten Adressaten bestimmt.
Wenn Sie nicht der vorgesehene Adressat dieser E-Mail oder dessen Vertreter sein sollten, so beachten Sie bitte, dass jede Form der Kenntnisnahme, Veröffentlichung, Vervielfältigung oder Wiedergabe des Inhalts dieser E-Mail unzulässig ist.
Bitte setzen Sie sich in diesem Fall mit dem Absender der E-Mail in Verbindung (br...@ba...).

Hi Frank,

You wrote:
> when the tunnel is up, do you see a special route on the 1.4RC2? With 
> DL-1.2.x, there is an ipsec0 device, and all remote networks that are 
> tunneled get routed through that device. I don't see anything like it in 
> DL-1.4. Even stranger ping works from the remote side, (ie icmp reply's 
> find their way through the tunnel), but I can't ping to the remote side.

There are no routes to remote IPsec-ed networks. There are only routes to 
locally connected and routed networks.  I use DL from 1.3, so I'm not sure, 
how it works in 1.2, but I suppose, in 1.2 was used 2.4 kernel and StrongSwan. 
This implementation of IPsec gives for tunnel pseudointerface (i.e. ipsec0). 
And naturally, IP stack need records in routing table for properly forwarding 
packets.

But in 2.6 kernels is builtin native IPsec stack. Because IPsec tunelling 
protocol is on 3rd level of OSI (network, not transport), in this native 
implementation there is no pseudointerfaces. Using ipsec-tools you need inject 
into kernel, using setkey, tunelling policies, containig info about source 
(your) CIDR address, destination (other side) CIDR address and via which 
tunnell (source and destination interface IP) this traffic will be routed. 
Racoon daemon is used to negotiate tunnels according to load needs.

Suppose, you have private network 192.168.0.0/24 and on other (remote) side is 
private network 172.16.0.0/24. Your internet interface has address 1.2.3.4 and 
on other side internet interface has address 5.6.7.8.

Then you define in /etc/ipsec-tools/setkey.cfg script, using spadd command, 
speeking that trafic from 192.168.0.0/24 to 172.16.0.0/24 should be encrypted 
as load into IPsec tunnel from 1.2.3.4 to 5.6.7.8. In racoon.conf You specify 
how to negotiate and establish tunnels.

When in IP stack will born traffic from 192.168.0.1 to 172.16.0.1, it will be 
compared to IPsec this policy and then encrypted into IPsec packet from 
1.2.3.4 to 5.6.7.8. If there is no negotiated tunnel between this addresses, 
IPsec stack will call racoon daemon for this tunnel to be negotiated and 
keyed. And now (!) is used routing table to properly forward this encrypted 
packet.

So in routing table there is no records for 192.168.0.0/24 and 172.16.0.0/24 
aggregates.

> Can you do site2site with OpenVPN? I use it for Point-of-Sales that 
> connect to a central DB, and am quite fond of it, but I have always 
> thought that it's more of a client-server thing, no?

Yes and no. OpenVPN is 4th OSI level tunnel, so it uses pseudointerfaces and 
routing table directioning. OpenVPN goes through all NAT translations and 
gives all possibilities. I use site2site (point-to-point) tunnels between my 
central in Warsaw and divisions in other cities on dedicated ports. So all 
corporation communicates on internal addresses. Additionally in central and in 
divisions I have OpenVPN servers for road-warriors (on 1194 port), so if one 
is working home, he establish from his notebook personal OpenVPN tunnel to 
central (or his own division) and now he has access to all hosts on private 
addresses in connected division directly and in other divisions via above 
point-to-point inter-division tunnels.

As routers I use DL in central and bigger divisions and ASUS WL-500W with 
Oleg's firmware in other places.

The one division is using old Cisco router. Cisco have not implemented 
OpenVPN, so in this direction IPsec is MHB.

After one year, 200 people get OpenVPN keys/certificates, learned how to 
install OpenVPN clients, installed it on his mobile computers and now are 
working on corporate resources from home, customer companies etc. Now I closed 
near all open ports. Additionally central WLAN segment has no acces to LAN in 
central site, but only to OpenVPN server. Our APs are near open (for guests 
use), but our workers after establishing OpenVPN tunnel have access to all 
corporate resources on this same table, where guest have access only to DMZ 
and Internet.

I think, this all is relatively simple. If You have specific question, you can 
ask on private.

Best regards

-- 
Andrzej Odyniec

Frank Weis wrote:
> Hi,
> 
> is ipsec supposed to be working in 1.4RC2?
> 
Yes, I use it for road-warrior access. It works.

Serge

Andrzej Odyniec wrote:
> 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.
>   
Hi Andzrej,

when the tunnel is up, do you see a special route on the 1.4RC2? With 
DL-1.2.x, there is an ipsec0 device, and all remote networks that are 
tunneled get routed through that device. I don't see anything like it in 
DL-1.4. Even stranger ping works from the remote side, (ie icmp reply's 
find their way through the tunnel), but I can't ping to the remote side.



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

Can you do site2site with OpenVPN? I use it for Point-of-Sales that 
connect to a central DB, and am quite fond of it, but I have always 
thought that it's more of a client-server thing, no?


Thanks for your input,
and have a nice day,

Frank