|
Page 1 of 5
One of the great strengths of Linux is its multi-faceted network server capabilities, reaching back to its rich UNIX history and the development of TCP/IP on that platform. If you’re a software developer, it’s dead simple to network-enable your own apps too, making them act consistently with other server processes. Here’s how to do it, in two parts.
The task at hand
Firstly, a real world story: I was called to do some work for a local ISP. They used a database system for administration and billing purposes, and a Linux server for user accounts and subscriber Web publishing.
This ISP was reasonably small. Its two system administrators were making all the Linux accounts by hand. They wanted the help desk staff to take over the job in some automated fashion, but didn’t want to give them actual privileged logins to the Linux server. These guys didn’t know Linux either, so sudo wasn’t really a solution.
What they requested was a Web page that the help desk staff could access on their local Intranet. The form allowed new registrations to be manually entered or uploaded from a file. When the staff member clicked OK the user details entered on the form were to be added to both the database and the Linux server, creating an account in the process.
The intranet was not running on the public Linux server; it was on a private machine – so a CGI script wasn’t an option. This called for a client/server solution. The key was to make a server process running on the Linux box which would receive commands to make accounts. It had to be always available because it would be impossible to predict when it may be needed, and thus could not be launched at pre-determined times. The server could then be invoked from a script on the intranet, or through other means. The server process – otherwise known as a daemon – was written in C and used the Berkeley socket implementation to listen for incoming requests and handle them. A username and password was funneled down the network connection and the daemon duly created the account.
This was agreed as the way forward, and the resulting code worked for them. I wanted the daemon to act as similarly as any other Linux daemon. This meant it had to be capable of processing multiple simultaneous requests, and it had to have an rc2.d script to start and stop gracefully.
The functionality of our client/server system
The starting point was to determine what the system ought to do. Obviously, it had to create user accounts. However, feature creep reared its head and the ISP thought some other features would prove useful, namely
-
executing an arbitrary process on the server
-
returning the user group of an arbitrary login ID
-
returning the mail aliases for an arbitrary login ID
-
testing the network connection
-
returning the daemon's version number
|
Information Technology News 
