|
Hello Joe,
> I thought you were busy in London and I wouldn't hear from you
> for a while :-)
This was last week, this week I'm actually also not here officially
but I thought it might be interesting to pick up the commercial
aspect of LVS as a name. This week there is a big showcase in Switzer-
land and on Wednesday maddog is giving a talk. I've got an invitation
and if you like I might talk with him afterwards about the legal
issues of Linux Virtual Server again. Send me stuff to my private
address and we can discuss it off the list.
> fine except users don't read documents. This is reasonable in
:) This is an old problem, people are lazy.
> a lot of ways. If I'm trying something new, I execute the obvious
> commands. If it does something sensible and looks well written,
> then I look at the docs to get it to work my way.
Ok.
> I put the tests in initially because someone came up on the mailing list
> because the configure script wouldn't run.
> It turns out he hadn't compiled something into the kernel.
> I didn't want people coming to me to find out what to do everytime.
Yep, this is the black side of my approach.
> The most common question for a while about the configure.pl script
> was about the "file not found" error. They didn't have perl installed
> or it wasn't in the same location as the script was looking for it.
Sorry to sound somewhat eleetish but this should really be basics which
people should be able to understand or just not use a technology as LVS
at all. Of course I'm not the one that has to give support for all those
countless lazy fools out there but I reckon you time is limited too.
> These sorts of questions drive me nuts. I'll do a lot not to get them.
procmail helps :)
> > If you absolutely
> > want to be fool-proof, then do something like
> > ip link add dev tun0 || { echo "Sorry, mate, but we need the ipip.o
> > support in the kernel."; exit 23; }
>
> Sounds good.
Yeah, but just in theory or whan ratz is on drugs. The correct version is:
ip link set tun0 up 2>/dev/null 1>&2 || { echo "RTFM"; exit 1;}
> I won't have to keep up with every new format of output from dmesg etc in the
> kernel
> either
That was my point of the whole explanation. Providing support for a
framework already providing some kind of API is best done by using them
and not writing third party blush which introduces too many invariants.
> This was what I was trying to do. However testing for stuff in the kernel,
> and then
> in modules and then attempting to load the module if I don't find it each
> time, winds
> up being a lot of code. (Of course all names are different for 2.2. and 2.4)
Btw, do you check the insmod/modprobe versions? If people would still be
using 2.1.* modutils binaries, you can try to load ipip as long as you
want, it's not going to happen :). And this is really a problem sometimes.
LVS always goes more or less with the latest kernel development cicle but
the latest cicle sometimes also includes new versions of user space tools
which are not checked by anyone except the cautious non-lazy user that
always reads the kernel docs. And what if I disable module support in the
kernel? Your script will be huge testing for every invariant people figure
out. I mean that's the freedom we have to accept while using Linux as OS.
> OK, if a command fails tell them what sort of things to do, rather than
> trying to fix it in the script.
This would definitely the case for stuff which has to be working before
you can even start to proceed with the initial task of your script, which
would be setting up the LVS services from a checked configuration file.
[Can you say "start to proceed" in English?]
> sure, but there's no point in writing code that no-one will use :-)
Granted. But then separate the try_to_be_intelligent_and_fix_the_stupid_
user_problems and the real setup program and make it a configuration
option. Let's say, you add a new variable to your config file:
# This is for people that are not able to read documentation
IDONTLIKETORTFM=0
and in your code you do branch to the code path that checks for all
this basic stuff, like perl path, modinfo version, ipip module loaded/
statically in, ip tool installed, ipvsadm version matching the LVS
code, proc-fs support enabled, bash version >2.02, interface cards
present, netfilter support enabled, ...
Cheers,
Roberto Nibali, ratz
--
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
|
