GnuDIP Release 2.3.5 - INSTALL File

Preliminary Steps

Become familiar with the set of low privilege UNIX user IDs used for running daemons on your system.
Many UNIX systems use a very simple system. There is a user ID named nobody. The nobody user ID cannot be logged in to. It can only be reached through the "root" user ID. It also has its own group. A process running under this ID will only be able to read files that are "world readable", and only able to modify or delete files that are "world writable".
Within this set up it is common practice to run the BIND named daemon as user nobody. Also, the sample configuration file that comes with the Apache web server source will run all CGI scripts as user nobody.
Some systems (apparently Red Hat does this) have several "nobody" user ID-s. Each daemon that can be run as a low privilege user gets its own user ID.
In these instructions, we assume that there is a single nobody user ID. When we refer to the nobody user ID, the reader should substitute the appropriate user ID for the daemon being discussed.
Move the directory gnudip to /usr/local (or /opt, or wherever you wish - we will assume /usr/local in what follows). If you copy this directory instead, be careful that the file ownerships of the files in the gnudip/etc/ directory do not change.

The "MiniDIP" Alternative

This package includes a bare bones version of GnuDIP with no database or web tool. There is a single configuration file, which includes the list of host names and their passwords.
The minidip.pl Perl script is a (X)INETD daemon address update server program. The miniupdt.pm Perl script is a CGI address update server program. They use minidip.conf in the GnuDIP configuration directory as the configuration file. The (X)INETD daemon allow the name of the configuration file to be overridden using command argument.
The BIND setup (this option does not support "back ends" - see below) is the same as for the full GnuDIP software.
The (X)INETD daemon setup is the same as for the standard GnuDIP (X)INETD daemon.
The CGI setup is also the same as for the standard GnuDIP CGI, if it is acceptable to have "/gnudip/cgi-bin/miniupdt.cgi" as the URL for the CGI. Otherwise you will need to use "ScriptAlias" definitions to suit your needs.
Combining minidip.pl and miniupdt.pm with the multinsupd.pl script discussed below in "Linking Non-GnuDIP Host Names to a GnuDIP Host Name" can provide a great deal of functionality.

Upgrading an Existing MySQL Database

If you have an existing GnuDIP MySQL database, upgrade this GnuDIP database. Note that there have been no database changes since release 2.3.0.
Start the MySQL client using:
```
# mysql -p
```
Follow the contents of upgrade.mysql to do the first part the upgrade.
Or you can read and edit the contents of upgrade.mysql, setting the MySQL database name, and then use:
```
# mysql -fvp < upgrade.mysql
```
The upgrade.mysql file is designed to upgrade from either either release 2.1.2 or release 2.2.x when used in this "automatic" way. In the latter case however, some error messages may be produced.
Scan the GnuDIP database and generate the statements to complete the database upgrade using:
```
# /usr/local/gnudip/sbin/gdipdbcnv.pl database localhost user password > myupgrade.mysql
```
The arguments are the MySQL database name, the server running MySQL, and the user name and password to connect to MySQL with, respectively. Read and understand the file that gdipdbcnv.pl produced:
- There will be statements to delete and recreate the contents of the globalprefs table.
- If you used DOMAIN_TYPE='GLOBAL' in Release 2.1.2 (which is no longer an option - see release.html), then the value of the domain column will be the empty string for each row of the users table. The statements generated by gdipdbcnv.pl will replace each such row with several replacement rows - one for each domain.
When you have examined these MySQL statements, run them using:
```
# mysql -p < myupgrade.mysql
```

New Database Set Up

If you have no existing GnuDIP database and wish to use MySQL, create a new GnuDIP MySQL database.
Start the MySQL client using:
```
# mysql -p
```
Follow the contents of gnudip.mysql to define the MySQL database and user.
Or you can read and edit the contents of gnudip.mysql setting the MySQL database name, and the user name and password to connect to MySQL with, and then use:
```
# mysql -vp < gnudip.mysql
```
If you have no existing GnuDIP database and wish to use the Linux/UNIX file system, create a new GnuDIP "flat file" database.
Delete the two UNIX symbolic links /usr/local/gnudip/lib/dbprefs.pm and /usr/local/gnudip/lib/dbusers.pm. By default these point to /usr/local/gnudip/lib/dbprefs_mysql.pm and /usr/local/gnudip/lib/dbusers_mysql.pm, respectively, which contain the code to handle MySQL.
Recreate these links using:
```
# ln -s dbprefs_flat.pm /usr/local/gnudip/lib/dbprefs.pm
# ln -s dbusers_flat.pm /usr/local/gnudip/lib/dbusers.pm
```
By default, dbprefs_flat.pm uses a file named /usr/local/gnudip/run/database/globalprefs, and dbusers_flat.pm uses a directory named /usr/local/gnudip/run/database/users.
The directories /usr/local/gnudip/run/database and /usr/local/gnudip/run/database/users are already set up. These directories must be readable and writable only by the owner and owned by user "nobody" (the "nobody" that Apache will run the GnuDIP CGI script as - see step one above). The processes that create and update files in these directories will be running as that user.
These names can be changed in /usr/local/gnudip/etc/gnudip.conf.
If you have no existing GnuDIP database and wish to use PostgreSQL, create a new GnuDIP PostgreSQL database.
Delete the three UNIX symbolic links /usr/local/gnudip/lib/dbcxore.pm, /usr/local/gnudip/lib/dbprefs.pm and /usr/local/gnudip/lib/dbusers.pm. By default these point to /usr/local/gnudip/lib/dbcore_mysql.pm, /usr/local/gnudip/lib/dbprefs_mysql.pm and /usr/local/gnudip/lib/dbusers_mysql.pm, respectively, which contain the code to handle MySQL.
Recreate these links using:
```
# ln -s dbcore_pgsql.pm  /usr/local/gnudip/lib/dbcore.pm
# ln -s dbprefs_pgsql.pm /usr/local/gnudip/lib/dbprefs.pm
# ln -s dbusers_pgsql.pm /usr/local/gnudip/lib/dbusers.pm
```
Start the PostgreSQL client using:
```
# psql -U postgres template1
```
Follow the contents of gnudip.pgsql to define the PostgreSQL database and user.
Or you can read and edit the contents of gnudip.pgsql setting the PostgreSQL database name, and the user name and password to connect to PostgreSQL with, and then use:
```
# psql -U postgres template1 -f gnudip.pgsql
```

You may change from one type of GnuDIP database to another by using the scripts gnudip/sbin/gdipunld.pl and gnudip/sbin/gdipreld.pl to dump and restore your user database:

# gdipunld.pl -h
usage: gdipunld.pl [ -h | [ [-o | -a] outfile ] ]
usage: Dumps the users table to a flat file.
usage: -h: Print this usage message.
usage: -o: Specify file to write output to.
usage: -a: Specify file to append output to.

# gdipreld.pl -h
usage: gdipreld.pl [ -h | [ -i infile ] ]
usage: Loads the users table from a flat file.
usage: -h: Print this usage message.
usage: -i: Specify file to read from.

You will have to re-enter system settings and domains by hand.

DNS Server Set Up

If you are using a legacy version of BIND that cannot be updated using the dynamic DNS protocol by nsupdate, or tinydns, you must set up the GnuDIP "back end" scripts. This is discussed in BACKEND.html.
Otherwise choose a zone or zones, and get BIND setup for dynamic updates for these zones.
The description provided in the next four steps shows one way to achieve this for one zone and key. For other configuration options please read the BIND 8 or BIND 9 documentation.
Generate the key files required by the nsupdate command. This will at the same time generate a "TSIG key" which you will later have to use in configuring the named daemon.
For BIND 8 use "dnskeygen" to generate key files. This goes something like this sample:
```
# dnskeygen -H 128 -h -n gnudip-key
** Adding dot to the name to make it fully qualified domain name**
Generating 128 bit HMAC-MD5 Key for gnudip-key.

Generated 128 bit Key for gnudip-key. id=0 alg=157 flags=513

# ls
Kgnudip-key.+157+00000.key  Kgnudip-key.+157+00000.private
# cat Kgnudip-key.+157+00000.private
Private-key-format: v1.2
Algorithm: 157 (HMAC)
Key: fegHlhVt3opPIiK8V4cjLw==
# cat Kgnudip-key.+157+00000.key
gnudip-key. IN KEY 513 3 157 fegHlhVt3opPIiK8V4cjLw==
```
For BIND 9 use "dnssec-keygen" to generate key files. This goes something like this sample:
```
# dnssec-keygen -a hmac-md5 -b 128 -n HOST gnudip-key
Kgnudip-key.+157+36000
# ls
Kgnudip-key.+157+36000.key  Kgnudip-key.+157+36000.private
# cat Kgnudip-key.+157+36000.private
Private-key-format: v1.2
Algorithm: 157 (HMAC)
Key: fegHlhVt3opPIiK8V4cjLw==
# cat Kgnudip-key.+157+36000.key
gnudip-key. IN KEY 513 3 157 fegHlhVt3opPIiK8V4cjLw==
```
For both Bind 8 and 9, examine the files that were generated to determine the key that was generated. In the examples above this key is:
```
fegHlhVt3opPIiK8V4cjLw==
```
You will use this key later to configure your BIND named daemon, to control dynamic update access to the GnuDIP dynamic zone.
Move the key files generated to /usr/local/gnudip/etc/. Remove the samples that are already there. These files should not be writable by anyone. These files should be readable only by the owner and owned by user "nobody" (the "nobody" that Apache will run the GnuDIP CGI script as - see step one above). The nsupdate command which will read these files will be running as that user.
Update the definition of the "nsupdate" parameter in the /usr/local/gnudip/etc/gnudip.conf file.
For BIND 8 follow this sample:
```
# BIND nsupdate command
nsupdate = /usr/bin/nsupdate -v -k /usr/local/gnudip/etc:gnudip-key.
```
Note that the trailing period (".") is required.
For BIND 9 follow this sample:
```
# BIND nsupdate command
nsupdate = /usr/bin/nsupdate -v -k /usr/local/gnudip/etc/Kgnudip-key.+157+36000.private
```
Or you could do:
```
# BIND nsupdate command
nsupdate = /usr/bin/nsupdate -v
nsupdate = -k /usr/local/gnudip/etc/Kgnudip-key.+157+36000.private
```
Note that parameter names in gnudip.conf may appear more than once. The values are concatentated with an intervening blank.
As shown above, the command line options for nsupdate differ between BIND 8 and BIND 9. However, the nsupdate standard input commands generated by GnuDIP are compatible with either BIND 8 or BIND 9.
Now you must configure the target BIND named daemon to contain the key generated above, and also of course your GnuDIP dynamic zone.
Note that the named daemon may run on a different machine than the machine that will run the GnuDIP CGI (and thereby the nsupdate command). The nsupdate command determines what DNS server to send its update request to by doing a DNS lookup for the "SOA" record for the domain name whose information is being updated. The SOA record identifies the master DNS server for this domain name. The nsupdate command will send the update request to the master DNS server for the domain.
Recall that the sample TSIG key generated above was:
```
fegHlhVt3opPIiK8V4cjLw==
```
Create a file called gnudip-keyfile in your named configuration directory. This file should not be writable by anyone. This file should be readable only by the owner and owned by user "nobody" (the "nobody" that the named daemon will run as - see step one above). The file gnudip-keyfile should contain something like this sample:
```
key gnudip-key {
  algorithm hmac-md5;
  // the TSIG key
  secret "fegHlhVt3opPIiK8V4cjLw==";
};
```
Note that the contents of this file are entirely different from the files created during key generation above. This is not a copy of one of those files. You will have to create this file manually. The sample key "fegHlhVt3opPIiK8V4cjLw==" must be replaced by the key that you generated.
Now you must add a section to define the GnuDIP dynamic zone in your named.conf file.
For BIND 8 the new section would look something like:
```
// include definition of GnuDIP update key
include "gnudip-keyfile";

// define GnuDIP dynamic DNS zone
zone "dyn.you.net" in {
  type master;
  file "run/zone-dyn.you.net";
  allow-query { any; };
  allow-update { key gnudip-key; };
};
```
For BIND 9 the new section would look something like:
```
// include definition of GnuDIP update key
include "gnudip-keyfile";

// define GnuDIP dynamic DNS zone
zone "dyn.you.net" in {
  type master;
  file "run/zone-dyn.you.net";
  allow-query { any; };
  update-policy { grant gnudip-key subdomain dyn.you.net; };
};
```
In the examples above, note that the string gnudip-key refers to the name of the key, whereas the string gnudip-keyfile refers to the file containing the syntax to define that key name.
Notice above that the zone file is in a subdirectory called run. This directory should be owned by user "nobody" (or whatever user ID named runs as) so that named may create files in it.
You can set up $TTL and SOA values for the dynamic zones by setting up an initial zone file for BIND. BIND will read this the first time, and use the values from the file. Continuing the previous example, for the file run/zone-dyn.you.net try something like this sample:
```
$TTL 86400 ; default TTL (1 day)
@          IN SOA   ns.you.net. root.you.net. (
                      0       ; serial
                      3600    ; refresh (1 hour)
                      1800    ; retry (30 minutes)
                      604800  ; expire (1 week)
                      0       ; TTL for NACK-s (0 seconds)
                    )
           IN NS    ns.you.net.
           IN A     IP_address
```
This zone file should again be owned by user nobody, so that named may modify it.
This sample supposes that you want clients to use dyn.you.net as the name of the GnuDIP server, in addition to the name of the GnuDIP subdomain. The A record is required for this. You will not be allowed to use a CNAME record for this, because the name of the record would be the same as the name of the SOA record. You can maintain this A record using nsupdate if the address changes.
The SOA and NS records may point into an entirely different domain.
Note that the base domain you.net can be made the GnuDIP dynamic domain if you wish. If the NS records point to names within you.net, you will need glue records in the usual way.
Note that the default TTL value in this start up file will not apply to the records added using nsupdate. The nsupdate command requires a TTL value with each record added. GnuDIP will use a value of zero for this TTL, unless a value is specified in /usr/local/gnudip/etc/gnudip.conf (see below).
You may want to retain a copy of this inital zone file, for use with the gnudip/sbin/gdipzone.pl script discussed below.
Note that if you are the operator of a serious production shop rather than a home hobbiest, you will need to set up BIND to do "dynamic update forwarding" and "incremental zone transfers" to slave DNS servers from the master DNS server. These details are not explained here.

If the call to the nsupdate command by the GnuDIP CGI script fails for any reason, the precise command that was invoked as well as the input that was passed to it and the output from it will be wriiten to the system log.

The simplest way to debug your BIND configuration is probably by using nsupdate, the dig command and the ping command at the UNIX command prompt. For example, on the machine where the GnuDIP CGI script and nsupdate will run, try:

# dig tester.dyn.you.net. soa

; <<>> DiG 9.1.3 <<>> tester.dyn.you.net. soa
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 34673
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;tester.dyn.you.net.            IN      SOA

;; AUTHORITY SECTION:
dyn.you.net.      0             IN      SOA     you.net. root.you.net. 484 3600 1800 604800 0

;; Query time: 8 msec
;; SERVER: 192.168.0.2#53(192.168.0.2)
;; WHEN: Tue Oct 23 14:47:24 2001
;; MSG SIZE  rcvd: 88

# su - nobody
# /usr/bin/nsupdate -v -k /usr/local/gnudip/etc/Kgnudip-key.+157+36000.private
> update add tester.dyn.you.net. 0 A 127.0.0.1
>
> #
# exit
# ping tester.dyn.you.net.
PING tester.dyn.you.net (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=0.2 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=255 time=0.1 ms

--- tester.dyn.you.net ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.1/0.1/0.2 ms
#

In the "su" command, the "nobody" that the GnuDIP CGI and (X)INETD daemon will run as should be used (see above). You may want to try the nsupdate as root first.

If your nobody user is not set up to allow the use of "su - ...", you may instead try:

# sudo -u nobody /usr/bin/nsupdate -v \
            -k /usr/local/gnudip/etc/Kgnudip-key.+157+36000.private

The output from the dig command shows that nsupdate will send its update request to you.net.

Note that nsupdate accumulates update input lines until it sees an empty line. Only then does it do the updates. To stop nsupdate use "Ctrl-D" to generate an end of file.

Remember that BIND comes with documentation.

You may also want to take advantage of the BIND mailing lists or their archives.

Editing the Configuration File

Edit /usr/local/gnudip/etc/gnudip.conf. There are comments in the sample that is already there.
In particular, check whether you need a "-p" option for the "logger" commands in order to ensure that log messages go somewhere acceptable. One user has suggested "/usr/bin/logger -p local3.err" for Solaris 8 using the default configuration for syslogd.
Also, check the path to your sendmail program (or sendmail clone). For example Solaris 8 by default puts sendmail in /usr/lib/sendmail.
A sendmail alias (or clone equivalent) to direct mail for the "return path" user (the GnuDIP "nobody" user unless the sendmail "-f" option is used) to /dev/null is also a good idea, so returned mail for a bad E-mail address disappears.
If you already have a gnudip.conf file for an existing installation, review the sample gnudip.conf file for new parameters.
Make sure that everything in /usr/local/gnudip/etc/ is readable only by the owner and owned by user "nobody" (the "nobody" that Apache will run the GnuDIP CGI script as - see step one above), and not writable by any user.
You may wish to create a directory /etc/gnudip, move (i.e. rename) the directory /usr/local/gnudip/etc to /usr/local/gnudip/etc_orig (for later reference), and set /usr/local/gnudip/etc as a symbolic link to /etc/gnudip. Then create your configuration files in /etc/gnudip. If you later upgrade, you can then just rename /usr/local/gnudip/etc to /usr/local/gnudip/etc_orig, and recreate the link. This practice allows the switch to a new release in production environments to consist of two "mv" commands and one "ln" command, which would take only a few seconds.

Apache Web Server Set Up

The instructions here are for Apache. But it should be possible to use the web interface with other servers.
The user maintenance commands or remote maintenance daemon described below may be used in place of or in addition to the GnuDIP Web interface. However, the HTTP client update interface is incorporated into the web interface. The Apache configuration can be made simpler if only the HTTP client interface is desired. Only the CGI definition statements are required.

To run as a standard CGI, add these lines to your Apache configuration file:
```
Alias /gnudip/html/ /usr/local/gnudip/html/
<Location /gnudip/html/>
Options Indexes
ReadmeName .README
HeaderName .HEADER
RemoveHandler .pl
RemoveType .pl
AddType text/plain .pl
</Location>
ScriptAlias /gnudip/cgi-bin/ /usr/local/gnudip/cgi-bin/
```
The URL for the Web Tool will be:
```
http://yourserver/gnudip/cgi-bin/gnudip.cgi
```
The self sign up page will be directly available at:
```
http://yourserver/gnudip/cgi-bin/gnudip.cgi?action=signup
```
Note that this URL is different than the URL for GnuDIP following the installation instructions for Release 2.1.2. Following those instructions the URL would be
```
http://yourserver/cgi-bin/gnudip2.cgi
```
To provide compatibility copy the perl script /usr/local/gnudip/cgi-bin/gnudip2.cgi to the cgi-bin directory for your Apache server (or make a symbolic link). This short script will redirect to the new URL. Modify gnudip2.cgi to match any change you made to the two Apache configuration lines above.
Other Apache configurations are possible.

The web tool will run under mod_perl Apache::Registry.

To use mod_perl, instead of the lines described above, add these lines to your Apache configuration file:

Alias /gnudip/html/ /usr/local/gnudip/html/
<Location /gnudip/html/>
Options Indexes
ReadmeName .README
HeaderName .HEADER
RemoveHandler .pl
RemoveType .pl
AddType text/plain .pl
</Location>
Alias /gnudip/cgi-bin/ /usr/local/gnudip/cgi-bin/
<Location /gnudip/cgi-bin/>
SetHandler perl-script
PerlHandler Apache::Registry
Options +ExecCGI
PerlSendHeader On
</Location>

The web tool will run under FastCGI using mod_fastcgi and FCGI.pm.
To use FastCGI, instead of the lines described above, add these lines to your Apache configuration file:
```
Alias /gnudip/html/ /usr/local/gnudip/html/
<Location /gnudip/html/>
Options Indexes
ReadmeName .README
HeaderName .HEADER
RemoveHandler .pl
RemoveType .pl
AddType text/plain .pl
</Location>
Alias /gnudip/cgi-bin/ /usr/local/gnudip/fcgi-bin/
<Location /gnudip/cgi-bin/>
SetHandler fastcgi-script
Options +ExecCGI
</Location>
```
When running under mod_perl or FastCGI, adding the line "persistance = YES" to gnudip.conf will cause the web tool to use persistant database connections, and to retain the contents of gnudip.conf, the preferences from the globalprefs table and the list of domains from the domains table, and any other configuration files in memory, rather than re-accessing these files or tables. Make sure that persistance is not on when configuring your system while running under mod_perl or FastCGI.

Customizing the Web Interface

The parameters header_file and trailer_file in gnudip.conf specify a file of HTML to be included at the top and bottom of each HTML page, respectively. An example of what can be done using these files is provided.
The parameters URL_sendURL, URL_self_signup and URL_delthisuser in gnudip.conf specify URL-s which should take the place of the "Forgotten Password", "Self Registration" and "Delete Current User" form buttons. See the comments in gnudip.conf for more information.
The parameters no_robots_prfx and no_robots_imgcmd in gnudip.conf must be correctly specified in order to user the GnuDIP feature to suppress automated abuse of "Self Registration", "Forgotten Password" and "Change E-mail Address". See the comments in gnudip.conf. If you have ImageMagick installed then the sample/default text image generation script should work for you.
Once you have ensured the defaults will work, or provided and alternative image generation script, you can turn this option on in "System Settings" in the web interface.
Without this, the GnuDIP Web Interface is vulnerable to being used as the "man in the middle" for an E-mail bombardment attack.
A program can "GET" and "POST" the pages that send an E-mail repeatedly to send an E-mail bombardment to a third party. The bombardment will seem to come from the GnuDIP site.

(X)INETD Daemon Set Up

Add an entry to /etc/services like this sample:
```
gnudip          3495/tcp
```
If you use the xinetd replacement for inetd, add an entry to /etc/xinetd.conf like this sample:
```
service gnudip
{
	flags       = REUSE
	socket_type = stream
	protocol    = tcp
	wait        = no
	user        = nobody
	server      = /usr/local/gnudip/sbin/gdipinet.pl
	bind        = 0.0.0.0
        only_from   = 192.168.0.0/24
        only_from   += 127.0.0.1
        only_from   += 24.64.0.0/13
        only_from   += 64.5.210.224/31
        only_from   += 64.5.221.128/27
}
```
You should of course choose values for "only_from" that are appropriate to your circumstances. You may want to just leave these lines out.
Note that the "nobody" user ID used here should be the same one Apache will run the GnuDIP CGI script as (see step one above).
If you have XINETD with TCP wrappers compiled in, make an entry in /etc/hosts.allow like this sample:
```
gdipinet.pl: 24.64.0.0/255.248.0.0        \
             64.5.210.224/255.255.255.232 \
             64.5.221.128/255.255.255.160
```
For early releases of XINETD with TCP wrappers, you must use the service name instead of the process/program name, as follows:
```
gnudip: 24.64.0.0/255.248.0.0        \
        64.5.210.224/255.255.255.232 \
        64.5.221.128/255.255.255.160
```
If you left out "only_from" above, then you would instead use a line like:
```
gdipinet.pl: ALL
```
or for early releases of XINETD
```
gnudip: ALL
```
Or make an equivalent entry in /etc/inetd.conf like this sample:
```
gnudip	stream	tcp	nowait	nobody	/usr/sbin/tcpd	/usr/local/gnudip/sbin/gdipinet.pl
```
Note that the tokens are separated by tab characters.
Note that the "nobody" user ID used here should be the same one Apache will run the GnuDIP CGI script as (see step one above).
Make an entry in /etc/hosts.allow like this sample:
```
gdipinet.pl: 24.64.0.0/255.248.0.0        \
             64.5.210.224/255.255.255.232 \
             64.5.221.128/255.255.255.160
```
If you are not imposing access restrictions, then you would instead use a line like:
```
gdipinet.pl: ALL
```
If you have restricted the IP addresses for gdipinet.pl using /etc/xinetd.conf and/or /etc/hosts.allow, you may want to restrict the IP addresses for this port in your firewall too.
We assume in what follows that you have added /usr/local/gnudip/sbin to your PATH environment variable.
Check that the logger command used by the (X)INETD script has been correctly defined by using gnudip/sbin/gdipinet.pl at the command line. This should go something like this:
```
# su - nobody
# gdipinet.pl
Could not get IP address of client
# exit 
```
Here, the "nobody" that the (X)INETD daemon will run as should be used (see above).
If your nobody user is not set up to allow the use of "su - ...", you may instead try:
```
# pushd /tmp
# sudo -u nobody gdipinet.pl
Could not get IP address of client
# popd
```
Ensure that the message "Could not get IP address of client" also appears in your system log.
This test is important. The (X)INETD daemon has no other way to report errors.
Also, note that the gdipinet.pl script suppresses Perl warning and error messages (that is "STDERR") shortly after it starts, since under (X)INETD these would get sent to the network client. It is however possible to capture these for trouble shooting:
```
# gdipinet.pl -h
usage: gdipinet.pl [ -h | -e STDERR_file ]
usage: GnuDIP (X)INETD Daemon.
usage: -h: Print this usage message.
usage: -e: Specify filename prefix for STDERR output. The file name
usage:     will be this prefix followed by the process ID.
```
You could for example use "gdipinet.pl -e /tmp/gdipinet_STDERR_".

Configure the Web Interface

Create an administrative user for gnudip using gnudip/sbin/gdipadmin.pl:
```
# gdipadmin.pl -h
usage: gdipadmin.pl [ -h | [ -u ] userid password ]
usage: Add GnuDIP administrative user "user" with password "password".
usage: -h: Print this usage message.
usage: -u: Update user if it already exists.
```
If you are using the "flat file" GnuDIP database, then before running gdipadmin.pl do:
```
# su - nobody
```
Here, the same "nobody" as used for the CGI scripts and the (X)INETD daemon should be used (see step one above). This will ensure that the file that is created is owned by user "nobody", and can be used by these GnuDIP scripts.
If your nobody user is not set up to allow the use of "su - ...", you may instead try:
```
# pushd /tmp
# sudo -u nobody gdipadmin.pl ...
# popd
```
Note that administrative users cannot be used as dynamic host names. Unlike "host" users, they do not exist only within a particular domain. Any user name you use for an administrative user will become "reserved", and unavailable as a dynamic host name.

In the next step, or any time you encounter a problem with the web tool, remember to check the system log for error messages from GnuDIP. If the Web Tool encounters any difficulties using the logger command, error messages will be written to the Apache error log.

In particular, look in the system log or Apache error log for error messages if you get an error from the web tool like this:

Error: GnuDIP Configuration or Interface Problem

An internal GnuDIP operation has failed, due to a configuration error, or the failure of a system service required by GnuDIP.

Please report this problem to your administrator if it persists.

Go to the Web Tool and login as this new user.
Using "Administrative Settings", add more configuration stuff. There are explanations on the page. In particular, you will need to set your main GnuDIP domain here.
If you want more than one domain, use "Add Domain" to add them.
If you did not enable self registration for users, use "Add User" to add users.

If in the future you ever remove a domain, or turn off wildcards or mail exchangers, you should use the script gnudip/sbin/gdipdbfix.pl to bring the user database into agreement with the new configuration options:

# gdipdbfix.pl -h
usage: gdipdbfix.pl [ -h ]
usage: Scans the database and modifies or deletes users in
usage: the user database in order to be consistent with the
usage: set of domains and the administrative settings.
usage: -h: Print this usage message.

Keeping DNS in Sync with the Database

You may want to use the script gnudip/sbin/gdipzone.pl in a weekly or monthly scheduled job to reload the zone files from scratch:
# gdipzone.pl -h
usage: gdipzone.pl [ -h | [ -o outfile ] [domain] ]
usage: Scans the database and generates nsupdate input to create zone
usage: records. Scans for all domains unless "domain" is specified.
usage: -h: Print this usage message.
usage: -o: Specify file to write output to.
Following the example above, the process would be:

shutdown named using "ndc stop" for BIND 8 or "rndc stop" for BIND 9.
for BIND 9, delete the file run/zone-dyn.you.net.jnl
Make certain the "rndc stop" worked before you do this!!!
replace the file run/zone-dyn.you.net with an initial zone file like the one used above
restart named
run nsupdate using the output from gdipzone.pl as input

Purging Unused User Names

You may want to use the script gnudip/sbin/gdipdlet.pl in a nightly or weekly scheduled job to delete database rows and any zone records for users whose IP address has not been updated for a specified number of days.
# gdipdlet.pl -h
usage: gdipdlet.pl [ -h | [ -d ] [ -o outfile ] days ]
usage: Generates the nsupdate input needed to delete zone records
usage: not updated within "days" days. Optionally, it also
usage: deletes the user from the database.
usage: -h: Print this usage message.
usage: -d: Delete users from the database.
usage: -o: Specify file to write output to.

User Maintenance Commands

There are four line commands that may be useful for user maintenance from the command line or scripts. These are described in maintenance_commands.html.

Remote Maintenance Daemon

There is also an (X)INETD daemon that may be used to provide the same capabilities as the user maintenance commands via a network protocol. This is described in remote.html.

Linking Non-GnuDIP Host Names to a GnuDIP Host Name

You may want to use the script gnudip/sbin/multinsupd.pl to filter the commands being passed to the nsupdate command, in order to insert non-GnuDIP aliases for GnuDIP host names. See the comments in the script, as well as the example and comments in gnudip/etc/gnudip.conf, gnudip/etc/minidip.conf and gnudip/etc/multinsupd.conf.
This script goes some distance towards addressing the item "A Mechanism to Link Non-GnuDIP Host Names to a GnuDIP Host Name" in TODO.html.

-T, -w, "use warnings;" and All That

Perl fans may notice that the code does not use "-T" or "-w" on the "shebang" line. Nor is "use warnings;" used. This is deliberate. These options are helpful in testing, but a great maintenance nuisance when used in publicly released software.
If you want to add these, go ahead. If you get warning or error messages, fix the problem and submit a patch to the mailing list, explaining what release of Perl you are using, and any upgrades you have made to the core Perl modules. While you are at it, perhaps you should ask in your E-mail about joining the GnuDIP support team.