The Government has offered Australia's three mobile operators, and vividwireless, renewal of their existing spectrum allocated on 15 year licences in the late 90s and early 2000s at set prices, while the Government expects to rake in $3 billion.
read more
David M Williams
Monday, 20 August 2007 20:33
Open the Makefile and set CFLAGS to compile with optimisation or with debugging information as preferred. Optimisation is the best option when you are certain the program performs as you require. Comment out the line which is not required.
There are also some necessary constants which have to be set in the header file dwserv.h according to your preferences. The ALIASFILE and GROUPFILE constants are the disk locations of your e-mail aliases and user groups, respectively. These are almost always in /etc/aliases (but sometimes /etc/mail/aliases) and /etc/group. The HOME_PATH constant is the directory prefix for where you store user accounts. Be sure to include the trailing slash (/). On your system, this directory will likely be /home/.
You next need to specify the full path to some external programs the daemon requires, namely useradd and grep. useradd is called to actually create accounts, conforming with policies in place on your system such as copying skeleton files, making directories and so forth. Further, useradd is a known and tested and debugged program; it is sensible to use it to perform the work. You can usually find where your programs are by typing a command like which useradd on the command line at a shell prompt.
Finally, we need to specify the listening port the daemon will use. The default value of 6000 can be changed by editing a line in dwserv.cpp.
Ports below 1024 are reserved for system use; ports from there through 65,535 are free for other purposes. Every TCP/IP protocol runs over a port. Port 80 is the standard port for HTTP web browsing and port 25 is the standard port for SMTP e-mail. Similarly, this daemon needs to choose a port on which it will listen for requests.
Once you have configured the server, run make at the command line. The source code will be compiled and the executable program produced.
Creating an account
The main task of the daemon is to create accounts. This work is performed by the method CreateAccount located in file pwroutines.cpp. This accepts a data string parameter which consists of a space-separated login ID, password and user group. The output message indicates the success or otherwise of the operation.
The string is decoded and then useradd is called, with appropriate parameters passed in - namely, the home directory, login ID, user group and password. One of our ancillary features was to execute arbitrary Linux commands so we have, by necessity, provided a routine called StartProcess. We can thus piggy-back on this to call useradd for the requirement at this point.
login[0] = '\0';
pword[0] = '\0';
group[0] = '\0';
i = j = 0;
while ((i < strlen (data)) && (data[i] != ' '))
login [j++] = data [i++];
login [j] = '\0';
j = 0; i++;
while ((i < strlen (data)) && (data[i] != ' '))
pword [j++] = data [i++];
pword [j] = '\0';
j = 0; i++;
while ((i < strlen (data)) && (data[i] != ' '))
group [j++] = data [i++];
group [j] = '\0';
StartProcess (buf, OutMsg);
}
Most all modern versions of useradd let a password be set at the time the account is created. This is not always so; it is important you determine if your version of useradd has this restriction. man useradd should quickly reveal the answer. If your useradd is lacking you will need extra code to set the password after useradd has performed its work. This means editing the shadow password file and updating the appropriate record.
Fortunately, the Linux kernel provides routines to assist in this endeavour. getspnam locates the appropriate shadow entry. crypt then encrypts the password. putspent stores a memory-based shadow password record. There’s just one catch; putspent won’t overwrite an already existing record but merely appends to the end of the shadow password file thus creating a second entry. This is unfortunate but far from disastrous. It does mean, though, the shadow password file has to be directly operated on and this needs great care. Another kernel routine, lckpwdf, indicates our desire to lock the shadow password file. Any other well-behaved software will honour this request and keep its hands off until we’re done. Once the existing shadow entry has been replaced, ulckpwdf releases the file for other processes to use. This is all performed in the routine SetPassword.
Stay tuned for part two where we finish off, detailing the socket-handling routines and the rc2.d script to start and stop the daemon as well as explain how to use it. Go to the next page to see the code in its entirety.

|
Microsoft Office 365Try an easy-to-use set of web-enabled tools for business-class productivity services. Office 365 provides anywhere-access to email, important documents, contacts, and calendars on almost any device. |