Hi there,

I have a host that has two ethernet interfaces, one for external traffic and one for internal traffic (compute nodes on a cluster).

The problem is sesinetd is using the “internal” interface for it's IP but I need it to grab the “external” IP so it can communicate with the license server which sits on the “external” network.

From sesinetd.log:

12:40:50 01/11/05 sesinetd: server start pid=1658 IP: 10.1.1.128

So how do I tell sesinetd to use a different IP/interface? I looked at the options for sesinetd (see below) but didn't see anything related to setting the IP.

Suggestions?

Thanks!


–Mark

========================================

This program is: Houdini License Manager Version 7.0.278
Usage: sesinetd
To query information from a running license server process, use the
sesictrl application.
Options:
-v Print version information
-n count Specify the number of threads to use for processing
-l file Specify log file
-V level Specify log level
0 = no logging
1 = log errors only
2 = log messages and errors
-z size Specify maximum log file size
e.g. 0.5M = .5 Mb
32k = 32 Kb
5000 = 5000 bytes
-m ipmask Specify read IP mask. Only clients whose address matches
will be granted access to query the server.
-M ipmask Specify write IP mask. Only clients whose address matches
will be granted access to modify the server.

Note: The read/write IP masks cannot be set after sesinetd has started
The default read mask is ‘+.+.+.*’
The default write mask is ‘+.+.+.+’

If I understand you correctly…are you saying that sesinetd(which is the license server) won't run properly because the license info is keyed to your “external” IP and it seems to be grabbing the “internal” eth device by default?

If so, I'm not 100% on this, but I don't think it's typical to have applications key-able to specific ethernet devices via command line params - isn't this sort of thing handled by the iptables? Would you use “route”? This is a little bit too “senior sysadmin” for me , but as an example from the man:

route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0
This is an obscure one documented so people know how to do it. This sets all of the class D (multicast) IP routes to go via “eth0”. This is the correct normal configuration line with a multicasting kernel.

I'm not suggesting the above fixes your problem, but it does seem like certain types of requests are routed with the iptables…perhaps a place to poke about.

Apart from that, I think the default behaviour is for an application to query the first available eth device, and if it works, uses it. Swapping them would be a nice, tacky hack.

Someone with more sysadm skills, please do jump in.

Cheers,

J.C.

Why not just manually retrieve your licenses with the correct server id that sesinetd finds?

Hi John,

JColdrick
If I understand you correctly…are you saying that sesinetd(which is the license server) won't run properly because the license info is keyed to your “external” IP and it seems to be grabbing the “internal” eth device by default?

Yep, I think this is what's happening, but I should also clarify something.

The sesinetd daemon is running on a PC which is on the “external” network. So my first attempt to get Houdini running (hscript actually) was to bring up hserver on the cluster's master node but was puzzled because it couldn't contact the license server.

So I thought I'd start sesinetd on the master node and install a non-commercial license first fro debugging purposes. That's when I discovered (via the /var/log/sesinetd.log file) that sesinetd, and I assume hserver too, was on the “internal” network …

So I thought maybe I could just put a rule in iptables to handle this etc., but then thought that the better solution would be to figure out what was going wrong before opening up a potentially exploitable hole in our kernel's packet forwarding …

JColdrick
If so, I'm not 100% on this, but I don't think it's typical to have applications key-able to specific ethernet devices via command line params - isn't this sort of thing handled by the iptables? Would you use “route”? This is a little bit too “senior sysadmin” for me , but as an example from the man:

route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0
This is an obscure one documented so people know how to do it. This sets all of the class D (multicast) IP routes to go via “eth0”. This is the correct normal configuration line with a multicasting kernel.

Yea, I've used that routing config for streaming servers and such, but I don't think it'll help in this case … maybe I'm wrong, need to think on that one a bit …

JColdrick
I'm not suggesting the above fixes your problem, but it does seem like certain types of requests are routed with the iptables…perhaps a place to poke about.

Apart from that, I think the default behaviour is for an application to query the first available eth device, and if it works, uses it. Swapping them would be a nice, tacky hack.

Right, that's my other solution I suppose, swap the eth configs … it may be difficult as there's other users on the box …

Thanks John!


–Mark

edward
Why not just manually retrieve your licenses with the correct server id that sesinetd finds?

Hi Edward,

Yea, that's right I can get a non-commercial license manually … thanks for the tip!

The server id is for the PC that I do all my Houdini work on but the cluster (where I want to render on) will have a different server id.


–Mark