[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: The multi interface code
From: |
Jan-Henrik Haukeland |
Subject: |
Re: The multi interface code |
Date: |
01 Jul 2002 21:05:46 +0200 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Civil Service) |
<address@hidden> writes:
> Can you tell me how it makes it messy? Some of the guts of it can
> probably be absteacted into functions.
1) You can not easily add ip-strings and hostnames to bind to in
addition to interfaces, because the code is bound to using
interfaces. E.g. in net.c:
if (ioctl(s, SIOCGIFCONF, &ifc) < 0)
2) Instead of having one server socket you have X which makes the code
in engine.c much more complicated. It also possible to write this
with less code and a bit cleaner (not much tough):
http://lists.debian.org/debian-ipv6/2001/debian-ipv6-200106/msg00022.html
(Check out AF independent server)
Example of other stuff in engine.c: Why do you do this and then
later let the socket_producer allocate W?
for (i=0; i < numberInterfaces; i++) {
W[i] = malloc(sizeof(struct requestwrapper));
}
We use xstrdup not strdup for a reason. Comment the code, and make
sure it does not have any side effects like:
3) start.c and stop.c does not work with your code. Check out
'monit start program' and 'monit stop program'
4) Cat'ing interfaces strings in p.y and reading back with strtok is
messy and:
http://www-rocq.inria.fr/Marc.Thiriet/Langages/tic0226.html#Heading636
(Or google for, 'strok harmful')
A parser parses tokens, so use the parser. Initially I did rewrite
the parser to create a linked list of interfaces that I passed to
create_server_socket and start_http, but when I tried to add
hostnames and IP addresses I started to think, why add all this
messy code, for what?. Then I re-read your mail:
> I disagree. I see the http server in monit as a "control channel". Let
> me give you a few cases were one would want to do this:
>
> 1) I have a master machine and a slave machine. The slave machine
> communicates all of its control info over a VPN to the master machine. I
> also need to be able to have access via localhost. However, I do not
> want the non-VPN ethernet interface to answer (yes I can use ACL's, but
> I do not even want something to appear on a port scan, I believe in the
> "belts and suspenders approach").
>
> 2) I have a large server farm. Each server has a public interface that
> customers access, a private interface that is used for admin, and
> loopback. In this case, I would want to bind to loopback and the private
> interface.
The current code lets you bind to one interface, so bind to the
private interface, and you can access the private interface from
localhost. Or use a firewall and mask out the monit http port and
use ACL.
In other words binding to only one interface or all covers most
situations and you can easily workaround the rest.
5) An independent server (a server that binds to X interfaces) is a
server that typically needs to speak more than one protocol, like
inetd. monit http speaks only HTTP.
6) Finally and most important: Occam's Razor: always choose the
simplest solution to a problem.
> I went thru a lot of effort to maintain the original structure of
> the code. Plus, this is going to make it difficult for me, as now I
> will have to maintain 2 versions.
Yes, I know. You must have worked hard, but this was your itch, not
mine. But after you patched the code I started to itch a lot - sorry.
--
Jan-Henrik Haukeland