-
Notifications
You must be signed in to change notification settings - Fork 2
Here are some questions that have been posed on the mailing list and to the netreg-bugs email address. The mailing list archive is also searchable.
7.0.1 Q: I'm getting lots of "XXX doesn't exist" ("subnet doesn't exist", "domain doesn't exist") errors, when clearly it does, because I just added it! What gives?
You probably need to add permissions for the resource (the subnet, DNS zone, or whatever you are trying to use.) On the information page for the resource, click "View/Update Protections", then either add "netreg:admins" with level 9 ADD access (if you only want admins to be able to use this resource) or "system:anyuser" with level 1 ADD access. Then try your operation again.
7.0.2 Q: I'm trying to debug DHCP/DNS (running ie "dns.pl -debug", "dhcp.pl -debug") and seeing "Cannot open services file: XXX".
Run $NRHOME/bin/service-dump.pl -debug first. The services file contains information used by many of the backend scripts (such as dns.pl, dhcp.pl).
7.0.3 Q: What is the format of the input file for load-machines.pl (part of the loader collection)?
The machines load format is expected to be:
#hostname|HW_address|IP_address|UID|Dept|status
hostname, HW_address, and IP_address are fairly straightforward. UID is expected to be something like "kevinm" or "didier".
status should be 'C' for most normal machines and 'R' if the HW_address or IP_address fields are blank. There are a couple other valid 'status' codes, but those are the most common. ('S' will get the machine flagged as stolen).
The IP_address field, if the IP is empty, should be '..' (or it's a fairly quick fix to load-machines to change this behavior).
Dept in our case was free form text, for example PRESIDENT'S OFFICE. load-machine uses a 'department mapfile' to map the free form text into a valid group id. The format of the mapfile is:
#dept name|netreg group id|
PRESIDENT'S OFFICE|34|
So in this case, group id #34 in the database would be something like dept:presoffice.
Here's how CMU has it setup:
We have a 'view.default.bind9' service group, of type "DNS View Definition". There are several attributes of the group that are "DNS Parameter"s. They are:
directory "/usr/domain/db" pid-file "/usr/domain/var/named.pid" auth-nxdomain yes fake-iquery yes transfer-format one-answer max-ncache-ttl 120
(Obviously these will vary from site to site, and I'd recommending reading the BIND9 ARM to understand the meaning of the various options.)
There is also a "Server Version" parameter (very important, it's compared with the server type to see if this view matters), of "bind9".
Then we have a "DDNS.dns" service group, type is "DNS Server Group". All of our DNS servers are members, and the attributes on them are "Server Type" ("master" or "slave") and "Server Version" of "bind9".
The view.default.bind9 group is also a member of this service; the attributes are:
"Service View Name" is "default" "Service View Order" is "10".
The service view name is important, since it specifies where in the zonefile to generate the view. default is a "special" identifier, in that it appears as the "global" view.
There are two sets of passwords here:
- The passwords in /home/netreg/etc (/.password*) are used by the web system and support binaries to authenticate to the mysql server. These passwords are/should never be known by end users. In NetReg, the mysql server trusts the web system to do ALL access enforcement (ie, the web server is authenticated to the mysql server with an access level that allows it to add/modify/delete anything in the netdb database).
- The end user passwords used in authenticating to the system. Technically, you authenticate to the web server and NetReg trusts the web server to provide the proper credentials (it just reads the REMOTE_USER environment variable to pull the login name).
A very basic test of authentication would be a .htaccess or statement in httpd.conf that says:
AuthType Basic AuthName NetReg Login AuthUserFile /path/to/userfile require valid-user
Then use 'htpasswd' to add an entry in '/path/to/userfile', and try logging in with this user and password. ( I suspect this is where you are. )
If NetReg doesn't present anything, verify that the username you are logging in with is in the netdb "users" table; a simple way to do this would be:
mysql -u root -p netdb [enter your mysql root password] mysql> select * from users;
This will show you what users are configured in the system. If you don't have any users, then at least the initial administrative user needs to be added. This should be in the archive somewhere (http://asg.web.cmu.edu/bb/archive.netreg-users).
I'm still a bit unclear what you are seeing out of NetReg: most people get a "Unable to view user information" error when they are authenticated but the user is not in the mysql database."
Other things to check: look at your Apache access.log, and see what it says. Make sure that /bin/netreg.pl is actually returning a 200 response code, and that it shows your userid. For example:
128.2.121.236 - [email protected] [08/Oct/2001:11:22:32 -0400] "GET /bin/netreg.pl HTTP/1.0" 200 10804
This shows my authentication. Using Basic Auth you won't have a @REALM.
Some codes and probable causes:
- 401: Generic authentication error?
- 403: Incorrect directory permissions on $NRHOME/htdocs or htdocs/bin
- 404: $NRHOME/htdocs/bin or $NRHOME/htdocs/bin/netreg.pl doesn't exist
- 501: Could be an error with perl finding the right modules, etc. Check the Apache error log...
We would hope the system requirements would cover this, but Cindy Smith compiled a comprehensive list of the extra modules required on a RedHat 7.2 installation:
- Convert-BER-1.31
- Crypt-DES-2.03
- Data-Compare-0.02
- Digest-HMAC-1.01
- Digest-SHA1-2.01
- Expect-1.15
- IO-Stty-.02
- IO-Tty-1.02
- Net-DNS-0.23
- Net-SNMP-4.0.2
- SNMP-4.2.0
- SNMP-MIB-Compiler-0.06
- SNMP-Util-1.8
- Test-Harness-2.26
- Test-More-0.08
- Test-Simple-0.45
Static: This means that a hostname, MAC Address, and IP address are all present. DNS is updated with the hostname and IP, and DHCP has a fixed address statement to assign the machine an IP based on MAC address.
Dynamic: This means that a hostname and MAC Address are present. If the dynamic mode of a subnet (see the subnet information page) is 'restrict', then any machines registered as dynamic will be able to get a dynamic IP. DHCP can be configured to update DNS with the hostname of the record.
Reserved: A hostname must be present, but MAC address and IP are optional. If IP or MAC are specified, then the standard duplicate checking rules apply (no other machine can have that IP, and no other machine on the same subnet can have the MAC address).
Base/Broadcast: These are special modes reserved for a registration of the base or broadcast address of a subnet. This isn't required however.
Pool: These addresses must have an IP address, but no hostname or IP. They are used to provide IPs for dynamic IP allocation on a subnet. The subnet mode must be 'permit' or 'restrict' to allow ANY dynamic IP allocation ('permit' means that anyone, registered or not, will receive a dynamic address; 'restrict' means that the machine must be registered with type 'dynamic' to get an address).
Secondary: In the next NetReg release, the 'secondary' type will be available for a machine with multiple interfaces; the secondary addresses must have a MAC address matching another machine on the subnet (their "parent").
Each entry in the protections table specifies:
- User/Group: Values less than 0 indicate the (positive) group id. A value of 0 applies to all users.
- Table Name: The name of the table to which the protection applies.
- Table ID: The record ID in the table that the protection applies to. A value of 0 applies to all records in the table.
- Rights: The rights can be 'READ', 'WRITE', and/or 'ADD'. See below.
- Level: The level of the access right. The valid values of level currently are 1, 5, and 9. Level 9 indicates the highest level of access.
Read/Write permission is additive between the "whole table" and "individual record" entries. For example, if you had:
netreg:admins, L9 READ on machine:* netreg:admins, L9 WRITE on machine:343
then on record 343 netreg:admins would have both.
However, the ADD bit is special. If a user has ADD access to a particular table, they are authorized to add new entries to this table. For example, ADD access to the machine table authorizes a user to add machines.
ADD access on an individual record, however, means that the user is authorized to "use" this record elsewhere. For example, ADD access on a particular DNS zone means the user is authorized to add new machines into this zone.
We have a project underway to try and document more of the exact permissions combinations necessary to perform various functions. For example, adding a machine requires something like:
- L1 ADD on machine:*
- L1 ADD on the forward DNS zone
- L1 ADD on the reverse DNS zone
- L1 ADD on the subnet
- plus the forward zone needs to be attached to the subnet
[ Contents | First Page | Previous Page | Home | Next Page | Last Page ]
[ 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 ]
Copyright © Carnegie Mellon University 2000-2003. All rights reserved.