6

Anybody knows what changes are necessary for a server to work with xinetd ?

The server being a .NET mailserver that runs on Linux.

See the bottom of this post for reference: Lumisoft Mailserver Forum Post

Note: xinetd, not mono-service. [x]inetd is an internet superserver.
A superserver starts a server service on demand.
(As opposed to the server service running continuously, which is what mono-service does)

AlvaroAV
  • 10,335
  • 12
  • 60
  • 91
Stefan Steiger
  • 78,642
  • 66
  • 377
  • 442

2 Answers2

7

An inetd service runs differently from a standalone server. inetd services read stdin and write to stdout, letting inetd handle the gory details of TCP/IP, rather than keeping track of their own sockets. If you want to make a server run under inetd, it'll have to do the same.

The following program runs just fine under xinetd on my machine:

#include <iostream>
#include <string>

using namespace std;  // yeah, i'm lazy.

int main()
{
    string name;
    cout << "What's your name? " << flush;
    cin >> name;
    cout << "Hi, " << name << "!" << endl;
}

Note i'm not at all worried about sockets -- xinetd arranges things so that the service can read standard input and write to standard output. You just write your app like you'd be running it on the console, for the most part. The socket details are specified in the config file for the service. (Note, you might be able to get/set details about the socket using stdin/stdout, which may be the actual socket -- i'm not sure -- but you really should leave that stuff up to inetd.)

cHao
  • 84,970
  • 20
  • 145
  • 172
  • Is there any sample, C++ or C or otherwise ? – Stefan Steiger Aug 18 '10 at 18:29
  • Thanks, looks indeed very simple. There really is not more to it? So if a client connects to port whatever, he recieves "what is your name", sends his name, and gets back "Hi ". And I suppose the timeout is handled by xinetd. Very funny indeed. I think I have to take a look at xinetd programming, it makes a server look as simple as a single-client console program. – Stefan Steiger Aug 18 '10 at 19:09
  • @Quandary: Yep, it's that simple. There might be more advanced stuff you can do, i'm not sure. But you can pretty much just write the app as if you intend to run it at the console, and let xinetd take care of the TCP/IP stuff. It only gets complicated when you want two clients to be able to talk to each other, but that's not much different than console apps either. I'm not sure about timeouts, but you can do that within the program with signals without too much trouble. – cHao Aug 18 '10 at 19:23
  • @cHao, where does std::cerr go to in your example? Is it joint to cout? – 0x2207 Nov 27 '14 at 08:40
  • @0x2207: I'm not sure, actually. I imagine it'd either go to the same place as `cout`, or to an error log set up by inetd. – cHao Nov 27 '14 at 10:00
2

An inetd services are really great for one off apps that need to take in data and act with some degree of interaction with the user. IT works over tcp/udp by piping the data viva a socket from (x)inetd to std{in,out,err}. inetd apps also works well with tcpwrappers to inhance security though system policy files and ACL.

So yes you would write your app like its a console app since in reality it is a console app. Just think of inetd as a transparent reverse proxy from the network to your app's inputs.

A Word of advice, write your code to handle the process signals correctly and if you need to interact with another process on the system use unix sockets/fifo for that.

Also, don't try to write an app that streams a lot of data all at once or needs a lot of connections. Scalability is an issue as inetd becomes a bottle neck, this is why Apache and Sendmail dropped support for inetd and sit as mono apps instead. HTTP fits this role better and a fastcgi (or insert favorite framework) script with nginx works best for that use case.

A good example for an inetd would be:

lock = Mutex.new

trap :HUP  { #log the connection and cleanup }
trap :USR1 { lock.synchronize do #stuff; end }
trap :TERM { #clean up }
trap :KILL { #clean up and die with error codes }

puts "App name - version"

loop do
  ('%s> ' % Console.prompt).display
  input = gets.chomp
  command, *params = input.split /\s/
  case command
    when /\Ahelp\z/i
      puts App.help_text
    when /\Ado\z/i
      Action.perform *params
    when /\Aquit\z/i
      exit
    else
      puts 'Invalid command'
  end
end
exit

Edit your /etc/services to include your app like this: myapp port#/proto

and add your app to /etc/inetd.conf (or xinetd.d) like this: myapp stream tcp6 nowait myappuser /path/to/myapp myapp -arg_flags

As for xinetd this has its own c like syntax for each config and depending on the distro could live in /etc/xinetd.conf or /etc/xinetd.d/myapp.conf. Would suggest one to read up on the manpage: https://linux.die.net/man/5/xinetd.conf

An example config say in-cpio.conf would look something like:

service ftp 
{ 
  socket_type        = stream 
  wait               = no 
  user               = nobody
  server             = /usr/bin/cpio
  server_args        = -idv
  instances          = 1 
  nice               = 10
  only_from          = 127.0.0.1
}
Dwight Spencer
  • 1,472
  • 16
  • 22