[naviserver-tracker] [ naviserver-Feature Requests-1119365 ] Watchdog/binder process

[SourceForge.net <no...@so...>]

Feature Requests item #1119365, was opened at 2005-02-09 15:43
Message generated for change (Comment added) made by seryakov
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=719009&aid=1119365&group_id=130646

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Vlad Seryakov (seryakov)
Assigned to: Vlad Seryakov (seryakov)
Summary: Watchdog/binder process

Initial Comment:
I find current binder and -b command line option not
very usefull and easy to administer. Can we revert back
to 3.x binder and combine it with simple watchdog
process, so on start ns forks watchdog/biner process,
check for exit status and accepts
requests for socket allocation.

----------------------------------------------------------------------

>Comment By: Vlad Seryakov (seryakov)
Date: 2005-02-11 14:05

Message:
Logged In: YES 
user_id=184124

In case of icmp sockets, thet are just raw sockets without
any ports, so for exampe for SNMP monitoring package i have,
i need 100 sockets pre-opened that i can use to perform
pings. So, i specify
-b 0/icmp/100
just ot keep the syntax same with other protocols.

----------------------------------------------------------------------

Comment By: Stephen Deasey (sdeasey)
Date: 2005-02-11 03:59

Message:
Logged In: YES 
user_id=87254


Yeah, 0.0.0.0 works for me, too  :-)

I don't know enough about icmp/raw sockets to know if that
makes sense (what is 'count' for?), but /protocl looks good.
 I haven't looked at this at all for multi-protocol stuff,
but it's obviously desirable.  It's great that Vlad's
already done this and I dont have to!

Although I run daemontools and Linux exclusively, I do have
one instance where I ship an AOLserver out to customers and
daemontools is just not appropriate there.  So Zoran's
watchdog sounds great, too.



----------------------------------------------------------------------

Comment By: Zoran Vasiljevic (vasiljevic)
Date: 2005-02-10 19:39

Message:
Logged In: YES 
user_id=95086

Aha! This I will have to check and see if this works 
for me also. 

----------------------------------------------------------------------

Comment By: Vlad Seryakov (seryakov)
Date: 2005-02-10 19:30

Message:
Logged In: YES 
user_id=184124

I use -b 0.0.0.0 currently, 4.0.10 and 4.1 worked fine.
When use -b 0.0.0.0 then address for nssosck should be
0.0.0.0 as well, not empty.

----------------------------------------------------------------------

Comment By: Zoran Vasiljevic (vasiljevic)
Date: 2005-02-10 17:33

Message:
Logged In: YES 
user_id=95086

This is what I'Ve done (nsd/driver.c) 
 
void 
NsStartDrivers(void) 
{ 
    Driver *drvPtr; 
 
    /* 
     * Listen on all drivers. 
     */ 
 
    drvPtr = firstDrvPtr; 
    while (drvPtr != NULL) { 
#if 0 /* zv */ 
        drvPtr->sock = Ns_SockListenEx(drvPtr->bindaddr, 
drvPtr->port, 
            drvPtr->backlog); 
#else 
        /* Listen on all known interfaces/addresses */ 
        drvPtr->sock = Ns_SockListenEx(NULL, drvPtr->port, 
            drvPtr->backlog); 
#endif 
 
I tried -b 0.0.0.0 but somehow it didn't work 
hence I reverted to heavy guns :) 

----------------------------------------------------------------------

Comment By: Vlad Seryakov (seryakov)
Date: 2005-02-10 17:14

Message:
Logged In: YES 
user_id=184124

Do you mean -b 0.0.0.0:80?
It will listen on all interfaces for port 80?


----------------------------------------------------------------------

Comment By: Zoran Vasiljevic (vasiljevic)
Date: 2005-02-10 10:55

Message:
Logged In: YES 
user_id=95086

Eventually, the watchdog/binder combination seems not 
the way to go (privileges issue).  I see. 
 
Concerning binder: I would need an option, (may be even 
compile-time one, don't care) for the server to listen on 
all network interfaces, including loopback. Apart from this,  
I have no immediate nor mid-term needs to modify  
anything there so I suppose I will be perfectly happy with 
any changes you guys need  in this area.  
 
Concerning watchdog: we can't use daemontools nor init. 
Also, we do have windows as platform, remember. 
We have struggled to get *minimum* interface to the rest 
of the system hence our product is easily installable and 
removable from the system. Actually, the only point we  
have in common (config-wise) are entries in the startup 
machinery. Therefore, a control-process from within the  
nsd is ideal for our needs. I have done this with  
--enable-watchdog and it is #ifdef'ed in the code so for 
just about any other user of the server this is pretty 
invisible and obscure (no backward compat problems also). 
 

----------------------------------------------------------------------

Comment By: Vlad Seryakov (seryakov)
Date: 2005-02-09 21:00

Message:
Logged In: YES 
user_id=184124

Here is the new syntax i added to the binder:

addr:port[/protocol]
port[/protocol]
0/icmp[/count]

where protocol can be tcp,udp,unix,icmp is special case of
raw socket, added by count.


----------------------------------------------------------------------

Comment By: Stephen Deasey (sdeasey)
Date: 2005-02-09 20:55

Message:
Logged In: YES 
user_id=87254


Adding support for socket types other than TCP to the binder
sounds like a great idea.


----------------------------------------------------------------------

Comment By: Vlad Seryakov (seryakov)
Date: 2005-02-09 19:55

Message:
Logged In: YES 
user_id=184124

I agree, i use inittab for aolserver myself calling bach
script which parses nsd.tcl for address/port keyworkd and
builds -b options on the fly. In case of inittab, no need in
watchdog as well.
It is not even on my wish list, i just figured if watchdog
is to berunning as root, then it can include binder support.
Let's put aside binder as separate process issue for a
while, but i'd like to add to regular 4.x binder what i did
for supporting UDP/TCP/UNIX/RAW sockets. They still need to
be pre-bound but then can be used from within AS, this is
how snmp and dns modules uses those sockets.


----------------------------------------------------------------------

Comment By: Stephen Deasey (sdeasey)
Date: 2005-02-09 19:52

Message:
Logged In: YES 
user_id=87254


Hmm...  I guess you could split the config into multiple
pieces, let admins manage everything except address and port
to bind to.  But would we mandate that in the defautl
set-up, or just hope people didn't screw up in practice?


----------------------------------------------------------------------

Comment By: Stephen Deasey (sdeasey)
Date: 2005-02-09 19:49

Message:
Logged In: YES 
user_id=87254


I think the issue here is that you need root privs to bind
to port 80.  The address and port are specified in the
config file.  The config file is a Tcl script.

So to allow someone to change your webserver config file you
need to give away root privs on your server.  I'm not super
keen on this :-)

IIRC in 3.x there was a lot of code to make sure that the
config script was evaled in a safe interp, and the
motivation for the binder was code reduction/simplification.

This also impacts the chroot functionality.  Idealy you want
to chroot as the last thing you do before dropping root
privs so that you can open all your fileslink to libraries
etc., and not have to recreate a complete copy of your
environment in the jail.  But you need to know which
directory that is, and that's in the config file, which is a
script...

Personaly, I use daemontools to manage my servers.  You need
to create a simple wrapper script for this to work and I
find that is the ideal place to set some environment
variables for the IP, PORT etc.  I can pass those along on
the command line and extract them from the env in the tcl
config script with [env get IP] and so on.

The binder is a neat solution, but in practice it trips a
lot of people up and it's just a pain.  Giving away root is
not a great solution though...  :-(



----------------------------------------------------------------------

Comment By: Zoran Vasiljevic (vasiljevic)
Date: 2005-02-09 17:23

Message:
Logged In: YES 
user_id=95086

Honestly, I did forget already how 3.x did the binding :-What we do in 4.0 is to bind on all interfaces 
(I modified that in our private version).
But I'm open to all variants. I suppose I should look 
back in 3.x code how that was done... 
Or, you have a crystal-clear picture already in which 
case I will simply believe you ;-)
As soon as we create the sandbox, we can start hacking
this in. 



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=719009&aid=1119365&group_id=130646