monit-general
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]