|
Joe, Julian,
> lsmod | grep ipip
>
> is fine.
>
> If (! in kernel)&&(! module loaded)
> then insmod ipip.o
> fi
I haven't replied to Joe's posting because I'm still fighting
whether I should tell you my opinion on this or not. I do now: I
don't think grepping for anything is a feasable and well-enough
solution to find out the current machine state. I mean you,
obviously you can find information in:
o System.map
o /proc/ksyms
o /proc/kcore
o lsmod
o dmesg
This is old news but I thought that I could find a better way
and propose it to you. Meanwhile I came to the conclusion that
you have following choices:
o document and tell the user that certain things have to be done.
You cannot expect your script to detect everything. And by not
trying to detect things you would also cope with the current
documentary status where we once defined the minimal requirements.
o you might use existing tools related to the problem. dmesg is not
a solution which can be used to solve your problem. 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; }
This at least tries to check the problem without you having to
grep away the invariants.
o Generally fail to execute the configure.pl in the above situation
and just describe in the end why it failed and what can be done to
fix the problem.
The above 3 things are part of a tradeoff you have to take responsability
for by deciding if configure.pl should reach product status or be a
very handy and easy-to-debug LVS setup tool.
I just don't like huge deviations in a tool. Keep it simple, stupid
or document the features. Because if people will not be able to fix
the problem of a missing ipip module, I don't think they will be
able to understand the rest of the load balancing stuff.
YMMV and it's your code. Just my 3.5 cents,
Roberto Nibali, ratz
--
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
|
