荔园在线
荔园之美，在春之萌芽，在夏之绽放，在秋之收获，在冬之沉淀
[回到开始]
[上一篇][下一篇]
发信人: HbBdByXc.bbs@bjsing.net (奋斗无止境·爱拼才会赢), 信区: Linux
标 题: GnuDIP Release 2.3.4 - INSTALL File
发信站: DQPI (Tue Nov 26 23:27:20 2002)
转信站: SZU!news.tiaozhan.com!news.bjsing.net!DQPI
This document needs to be fleshed out - an Installation and Configuration
Manual would be nice. Does anyone want to volunteer? Sign up for the
mailing list and send an E-mail to it.
-----------------------------------------------------------------------------
---
Installation Steps
Follow these steps:
Copy the directory gnudip to /usr/local.
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.db to do the first part the upgrade.
Or you can read and edit the contents of upgrade.db, setting the mySQL
database name, and then use:
# mysql -fvp < upgrade.db
The upgrade.db 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.db
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 gnudip/html/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.db
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.db to define the mysql database and user.
Or you can read and edit the contents of gnudip.db setting the mySQL
database name, and the user name and password to connect to mySQL with, and
then use:
# mysql -vp < gnudip.db
If you have no existing GnuDIP database and do not wish to use mySQL,
create a new "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_sql.pm and
/usr/local/gnudip/lib/dbusers_sql.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 processes that create and update files in these directories will be
running as user nobody (see below).
These names can be changed in /usr/local/gnudip/etc/gnudip.conf. You must
keep in mind that the processes that create and update these files will be
running as user nobody.
Note that the dbprefs.pm and dbusers.pm scripts are completely independent
of each other. You could for example use dbprefs_flat.pm with
dbusers_sql.pm.
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.
The description provided in this step assumes you are using BIND 9 and that
you will use key security with the BIND update-policy configuration clause.
For BIND 8 or other BIND 9 options please read the BIND documentation.
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.
Choose a zone or zones, and get BIND setup for dynamic updates for these
zones. Use "dns-sec" to generate key files. This goes something like this
sample:
dnssec-keygen -a hmac-md5 -b 128 -n HOST gnudip-key
Examine the files that were generated to determine the key that has was
generated. Plug this key into the BIND named.conf file to control dynamic
update access to the zones (same key for all gnudip controlled zones). For
BIND 9 this goes something like this sample:
include "gnudip-key";
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; };
};
Notice above that the zone file is in a subdirectory called run. This
directory should be owned by user nobody, so that named may create files in
it (see comments later in this file).
The file gnudip-key should be readable only by the owner and owned by user
"nobody". You should run the named daemon as user "nobody". If your user
ID-s are set up in the normal way, the nobody user ID cannot be logged in
to. It can only be reached through the "root" user ID. The file gnudip-key
would contain something like this sample:
key gnudip-key {
algorithm hmac-md5;
secret "e/8+oOmo2yE0HuHoXduZUw==";
};
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 CNAME ????.you.net
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
CNAME record can of course be an A record if this is appropriate, or the
SOA, NS and CNAME records may point into an entirely different domain.
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.
Copy the key files to /usr/local/gnudip/etc. Remove the samples that are
already there. Update the definition of the "nsupdate" parameter in the
/usr/local/gnudip/etc/gnudip.conf file (see below), following this sample:
# BIND nsupdate command
nsupdate = /usr/local/bind/bin/nsupdate -v -k
/usr/local/gnudip/etc/Kgnudip-key.+157+36000.private
Or you could do:
# BIND nsupdate command
nsupdate = /usr/local/bind/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.
Edit /usr/local/gnudip/etc/gnudip.conf. There are comments in the sample
that is already there.
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", and not writable by any user. Apache will
run the GnuDIP CGI script as nobody. You should also run the (X)INETD
server as nobody (see samples below). If your user ID-s are set up in the
normal way, the nobody user ID cannot be logged in to. It can only be
reached through the "root" user ID.
You may wish to move (i.e. rename) the directory /usr/local/gnudip/etc to
/etc/gnudip, and set /usr/local/gnudip/etc as a symbolic link to the new
name. This practice allows the switch to a new Release in production
environments to consist of two directory renames, which would take only a
few seconds.
Add these lines to your Apache configuration file:
ScriptAlias /gnudip/cgi-bin/ /usr/local/gnudip/cgi-bin/
Alias /gnudip/html/ /usr/local/gnudip/html/
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 compatibilty 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. The details of such
a configuration are not given here. When running under mod_perl, adding the
line "persistance = YES" to gnudip.conf will cause the web tool to use
persistant database connections, and to retain the preferences from the
globalprefs table and the list of domains from the domains table in memory,
rather than re-accessing these tables. Make sure that persistance is not on
when configuring your system while running under mod_perl.
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.
Add an entry to /etc/services like this sample:
gnudip 3495/tcp
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
}
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
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.
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 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 has been correctly defined by using
gnudip/sbin/gdipinet.pl at the command line. This should go something like
this:
# gdipinet.pl
3IA9JN1hg3
Could not get IP address of client
Ensure that the message "Could not get IP address of client" also appears
in your system log.
In what follows, 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.
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
This will ensure that the file that is created is owned by user "nobody",
and can be used by the GnuDIP CGI script.
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.
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 "rndc stop"
delete the file run/zone-dyn.you.net.jnl
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
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.
Install GnuDIP clients as appropriate. See gnudip/html/help.html or "Help"
in the Web Tool.
If you plan to operate a public installation of GnuDIP, and want to be
listed on the GnuDIP home page, sign up for the mailing list and send an
E-mail to it. You may also want to notify some of the suppliers of Windows
GUI clients that support GnuDIP (see
http://gnudip2.sourceforge.net/clients.html).
--
▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁
▏错误! × ▏
▏ Windows 发生严重错误，立即请小男孩去吃烧烤！ ▏
▏ ▁▁▁▁▁ ▏
▏ ｜ 确定 ▏ ▏
▏ ▔▔▔▔▔ ▏
※ 来源:·北极星BBS站 bjsing.net·[FROM: 218.14.112.7]
[回到开始]
[上一篇][下一篇]
荔园在线首页 友情链接：深圳大学 深大招生 荔园晨风BBS S-Term软件 网络书店