Mailing List Archive

Tyrel Beede wrote:
>
> About 6 or so months ago the corporation I worked for at the time, and
> still have a very close relationship with( the story is I graduated from
> high school and went to work there and I ended up kinda running
> everything unix related as the my boss didn't know much about the
> matter... but then after a year of working I went back to school so now
> I kinda just remote manage everything) has been running a copy of the

I remember.

> LVS which I modified to meet the requirements that they made of the
> product. It was just a few simple in-kernel and ipvsadm mods to support
> overflow between servers. I have also built a web interface to generate

Well, that sounds interesting...

> reports which count users through the server and allows management of
> the servers over a web interface to the non-unix people can work with
> it. Anyway to make a long story short we have been running with the LVS
> in place and everything has been great, no problems to speak of.
> I though it was really cool that it had been stable and I wanted to let
> the community know about it( if you want to play with it just give me an
> email, i didn't want to post a bunch of stuff). I've also got all the

Please send it to me, ASAP :)
And send a copy to Wensong, he'll have a look at it too, I'm sure.

> additional stuff I've written for it, some of which was kinda quick and
> dirty, but it gets the job done and from all I can tell seems to be
> stable. Also I was hoping Wensong or somebody out there would like to
> discuss adding some more scheduling algorithms, concentrating on the
> ones listed under the "To Do" section of the web site. I'm interested
> in if or how we could use the new "stateful" firewalling code in the
> linux kernel to implement some kinda fastest response scheduling

How do you mean "stateful" firewalling? This would already exist. Tell
us more about your ideas.

> algorithm. Anyways if anybody would like to share ideas about LVS
> development I would be more than happy to hear what you have to say...

Best regards,
Roberto Nibali, ratz

--
mailto: `echo NrOatSz@tPacA.cMh | sed 's/[NOSPAM]//g'`

Well, for everybody that is interested the package of mods I have made to the
lvs and some of other tools like the rlogind deamon are included. the web
interface is a collection of cgi scripts and some a c application called jpeg
which are focused on report generation. It also has a feature to add/remove
servers to the cluster but that stuff is currently fixed for the installation
where I work. It isn't hard at all to change it though, and it would only
take a second to built a more compleate interface, which is on my to do
list. Right now everything it kinda rough around the edges and I suppose
that it will take a few moments of looking around to acutally come up with an
idea of how it all works. For anybody that is interested I would consider
this package pretty primitive in the sence that things are configured mostly
to my needs and all of the documentation is in my head for the most part.
However, I am going to be putting a good amount of effort in to cleaning
everything up and making it something which would be more than just a "quick
and sometimes dirty collection". However, I must say that everything has
been pretty stable as things go and I would really like to hear any feedback
you guys have conerning the collection of stuff. So I suppose if some of you
out there feel motivated about building a compleate and clean lvs tools
related to anything I've been doing or maybe anything at all we can merge
code and throw some suggestions out on the drawing board. I'm already
working on increassing the functionality and cleanliness of my current
projects plus I'm currently researching a way to use the "stateful"
firewalling code( stateful means that it keeps connection information for the
established connections running through it, thus allowing the firewall to
defeat stealth scan type attacks as seen by the nmap utility, which btw if
you haven't checked out is a bad ass utility which you can d/l from
www.insecure.org) to allow for a fastest responce type scheduling
algorithm... I don't really see why the code couldn't keep(or allow us to
derive) information about the responce time because the netfilter code also
has the ability to shape bandwidth through an add on( the compleate details
of which I still need to read up on in the code) but at least it seems
possible. Anyhow, I hope you like the code and I know there are may ways in
which the work I have done can be imporved and I would like to see these
things accomplished.

Anyway, enough of my babble... here is a list of what comes in the package
attached to this email...

cgi-bin.tar -----> a collection of three cgi scripts to do reporting and
admin of the cluster

jpeg.tar -------> a stupid name but it reads a file( which I call
'usercount') and crunches the information in that to
produce a jpeg image or text output
depending on the report type requested.

ipvs-metrolist.patch -----> patch for the 2.2.14 linux kernel.... it
shouldn't be hard to get it to work with newer kernels in the
2.2.x series... currently the mods only apply to the wlc scheduling... also
I don't know what is up with DR or TUN as we use NAT because the traffic to
the machines isn't really outstanding considering they are only serving up
rlogin connection information....

netkit-rsh-0.10.tar ------> I modified a copy of the rlogind server so
instead of exec'ing the login program it exec's a program called overflow
which prints a message back to the end users informing them that the cluster
is currently full.... we have a cluster of HP 9000s which server up database
information over rlogin connections....

overflow.tar -------> the program mentioned above

ipvsadm.tar -------> I have made a few mods to this which support outputing
the total number of users connected to the cluster 'ipvsadm -t' and
'ipvsadm'(for the normal output + total users) and an option -h which allows
servers to be put into what I call 'hunt groups' this is a value currnetly
from 0-9 for a total of ten hunt groups... machines in lower numbered hunt
groups fill up first... they fill to the point where the total number of
active connections is equal to the their weight value... this is cool because
it the magnitude of the weight value is unimportant as long as it is at a
percentage level equal to whatever load you want it to recive(wlc) and this
is cool because if you say 100 100 50 as the weight values it works for both
connection capping and load sharing.... Also it must be run chmod u+s and
owned by root for the web interface to work for cluster managment :-( yeah,
this is really high on the make "better" list

xinetd.tar ------> nice util if you havn't used it, I like it better and it
is what we use to I though i would included it...


Anyway, I know that some of this stuff is rough around the edges and maybe
some is stuff is just a plain dirty hack but I would like to see it grow and
mature, so if you have any suggestions about how I can imporve the stuff(
beyond the normal stuff) I would really be appreciative. Also I don't have
any formal education so everything I know I've had to teach myself(I'm only a
freshman at Chico state and learning to program in java really dosen't have
anything to do with this) so if you find any really really stupid errors or
other stuff I apologize in advance.

Thanks, Tyrel

On Tue, 23 Jan 2001, Tyrel Beede wrote:

> Well, for everybody that is interested the package of mods I have made to the

Thanks for the code.

Unfortunately there weren't any attachments when it arrived. Do
attachments survive the LVS mailing list (Lars?)

Joe


--
Joseph Mack mack@ncifcrf.gov

Hi Tyrel,

[... a lot of brabbeling ...]

You did a proof-of-concept, this is never clean, so no problem. We
can help you cleaning up the stuff.

> projects plus I'm currently researching a way to use the "stateful"
> firewalling code( stateful means that it keeps connection information for the
> established connections running through it, thus allowing the firewall to
> defeat stealth scan type attacks as seen by the nmap utility, which btw if

Wrong!!! Stateful packetfiltering doesn't necessarily prevent the TCP/IP
stack from sending out the needed information for fingerprinting or open
ports. Please read the man page of nmap and the passive-fingerprinting
howto from fyodor about this. And, no again, nmap doesn't run stealth
scan type attacks, never did and will never do. If stacks fail due to a
scan they're implemented wrong and should be fixed. If nmap closes your
link, play with the timing. nmap should be part of any security aware
person, dealing with todays network security.

> you haven't checked out is a bad ass utility which you can d/l from
> www.insecure.org) to allow for a fastest responce type scheduling
> algorithm... I don't really see why the code couldn't keep(or allow us to

Well, as far as I see the LVS code, there is already some kind of stateful
connection handling. On the other hand I have to admit that if you fake
sequence numbers and a SYN -> SYN/ACK timeshifted you could fill up the
LVS-table, maybe.

> derive) information about the responce time because the netfilter code also
> has the ability to shape bandwidth through an add on( the compleate details

The traffic bandwidth shaping IMHO isn't done by the netfilter code,
it's in the routing and QoS code. Netfilter can hook to the QoS code
and profit from it. But maybe we are also talking about completely
different things ;)

> of which I still need to read up on in the code) but at least it seems
> possible. Anyhow, I hope you like the code and I know there are may ways in
> which the work I have done can be imporved and I would like to see these
> things accomplished.
>
> Anyway, enough of my babble... here is a list of what comes in the package
> attached to this email...

Hmm, maybe it was to big ...

> Anyway, I know that some of this stuff is rough around the edges and maybe
> some is stuff is just a plain dirty hack but I would like to see it grow and
> mature, so if you have any suggestions about how I can imporve the stuff(
> beyond the normal stuff) I would really be appreciative. Also I don't have
> any formal education so everything I know I've had to teach myself(I'm only a
> freshman at Chico state and learning to program in java really dosen't have
> anything to do with this) so if you find any really really stupid errors or
> other stuff I apologize in advance.

;)

Best regards,
Roberto Nibali, ratz

--
mailto: `echo NrOatSz@tPacA.cMh | sed 's/[NOSPAM]//g'`

Hello,

On Wed, 24 Jan 2001, ratz wrote:

> > you haven't checked out is a bad ass utility which you can d/l from
> > www.insecure.org) to allow for a fastest responce type scheduling
> > algorithm... I don't really see why the code couldn't keep(or allow us to
>
> Well, as far as I see the LVS code, there is already some kind of stateful
> connection handling. On the other hand I have to admit that if you fake
> sequence numbers and a SYN -> SYN/ACK timeshifted you could fill up the
> LVS-table, maybe.

There is another danger: creating one connection and sending
many packets. When one real server dies, continue with the next one.
I'm not sure whether the netfilter's target "limit" will prevent this.
May be we need per-connection packet rate limit in LVS? Or the user
needs more complex setup, for example using QoS features?

> > derive) information about the responce time because the netfilter code also
> > has the ability to shape bandwidth through an add on( the compleate details
>
> The traffic bandwidth shaping IMHO isn't done by the netfilter code,
> it's in the routing and QoS code. Netfilter can hook to the QoS code
> and profit from it. But maybe we are also talking about completely
> different things ;)

Yes, QoS hooks in the pre-routing, pri=1. DNAT/BALANCE will not
benefit but LVS will do.

> Best regards,
> Roberto Nibali, ratz
>
> --
> mailto: `echo NrOatSz@tPacA.cMh | sed 's/[NOSPAM]//g'`


Regards

--
Julian Anastasov <ja@ssi.bg>