|
Nodes - Help |
||
|
Help for this subject Other Help Topics |
SummaryThe Node record type is the most common record accessed by LNAs. Node records include essential information about networked devices like name, hardware address, CPU type. This is also where LNAs assign IP addresses. Differences from NetDB2MX (or Mail Aliases)- In NetDB2, to redirect mail from user@alpha.stanford.edu to a mail server called beta.stanford.edu, you would edit alpha's NetDB2 entry and put "beta" under the field "Direct Mail To". In NetDB3, MX records are entered on the mail server record, i.e., in reverse: you would edit beta's NetDB3 entry and add "alpha" as an MX. For more information, see the MX section below. New Fields- These fields are explained in further depth below. This is a brief summary:
Interfaces- In a NetDB2 host record, each hardware address could be mapped only to one required IP address. With NetDB version 3, the association between IP addresses, hardware addresses, DHCP/Bootp and Roaming DHCP is much more flexible. For more information, see the Interface Section below. Each interface can have the following:
Here's an example of this added flexibility: With NetDB2,
a student that lives off campus and brings his laptop to school has to
be assigned a dummy IP address to use Roaming DHCP on campus because NetDB2
will not register a hardware address without an IP address. Also, in NetDB2,
Roaming DHCP is turned on by putting "ROAM" in the Comment field. With NetDB3,
that laptop simply needs a Node record with one interface. This interface
would have the hardware address of the laptop's network adapter with Roaming
DHCP turned on. In NetDB3, several NetDB2 objects (Appletalk gateway, terminal server, router, mail alias) were combined into the Node record. However, there are 5 Node types- Regular, Template, IPC, Router and Advanced. Most LNAs will only need access to the Regular and Template Node types. A Node can be more than one type.
Regular- This is the most common type of Node. Regular Nodes are used for most computers, printers and networking equipment. Regular Nodes have one DNS name assigned. Template- This new Node type does not have an IP address but an address space instead. It was designed for the LNA who administers multiple networks or buildings and does not want to waste IP addresses. All NetDb users with Node record access can also create Nodes of type Template. IPC (Internet Connectivity Provider)- This Node type reserves a range of addresses to be handed out and is typically used for Shiva Fastpaths and terminal servers. Most LNAs do not have access to this Node type. Router- This Node type has the same fields as a Regular Node. However, router Node types have separate access restrictions. Usually, only staff who maintain routers on campus or in the Medical Center have access to router records. Advanced- This new Node type allows multiple DNS names, DNS names for interfaces and DNS names for IP addresses. This would be useful for a computer with multiple network adapters that hosts multiple websites. Also, alias and MXes are associated with a particular name. Generally, access is given to Advanced Node types on special request. When doing a reverse DNS lookup, names are returned in the following order if they exist:
For example:
If a reverse DNS lookup is sent for 171.64.2.2, the name returned will be www.stanford.edu. Changing Node Type To change the Node type, simply click on the buttons at the top of the Create Node or Modify Node page. The checkmark on the button means that Node type is selected. A Node can be an Advanced IPC Router. But Template Nodes cannot also be Advanced, IPC or Router types.
|
| NetDB term | DNS record type |
| Node Name | A (authoritative name) |
| Alias | CNAME (canonical name) |
| Mail Alias | MX |
These 3 fields must obey the following Internet naming standards:
For Node name, alias and mail alias, if no Domain name is specified, your default Domain (set in User Profile) is used. For most Users, the default Domain is stanford.edu.
Name- Name is simply the name of the Node. An Advanced Node can have multiple names. If no Domain name is specified, your default Domain (set in User Profile) is used. For most Users, the default Domain is stanford.edu.
Alias- Alias is the alias for the Node and is equivalent to a CNAME record in DNS.
MX- MX or Mail Alias allows email to be redirected. If "box1" is entered as a mail alias for Node "box2", that means that mail sent to anyone@box1 will actually be redirected to box2. A name can only be added as an MX if the node corresponding to that name is in the same group as the user. For instance, if a user tries to enter node2 as an MX for node1 (i.e., node1 will receive mail for node2), the user must have group rights to node2.
For example, suppose Node A has a mail alias B. When SMTP (simple mail transport protocol) server C is asked to send mail to somebody@B.stanford.edu. Server C will ask the Stanford DNS servers for the MX for B.stanford.edu. The DNS servers will return the IP address for A.stanford.edu. Server C then will send the mail to A.stanford.edu. In another example, if server C is asked to send mail to somebody@A.stanford.edu, server C will query the DNS servers for the MX for A.stanford.edu. In this case, there is no MX record for A.stanford.edu. Then server C will query the DNS servers for an A record for A.stanford.edu. The DNS servers will return the IP address for A.stanford.edu.
Note: MXes can only be added by modifying an existing Node.
Verifying Name, Alias and MX
Because of the nature of web pages, IP addresses cannot be confirmed as soon as they are entered. The "Verify Name, Alias and MX" button tells NetDB to check for the following:
Moving Name to Alias and vice-versa
To swap the name and alias of a Node, do the following:
Here's a technical explanation of why this is more difficult in NetDB3 than NetDB2:
Take a Node where the name is A and the alias is B. Simply
swapping A and B on the Modify Node page gives errors because a Node name
and alias are quite different in the world of DNS (domain name service).
In NetDB2, this would work because when B is removed from the alias field
and the cursor is moved to the name field, B is immediately removed as
an alias. However, in NetDB3, because of the stateless nature of HTML,
B is not actually removed as an alias until the revised form is saved.
Node Type- Select the desired
Node types by clicking on the buttons. Selected Node types will have checkmarks
on the button. The page will also be refreshed to add the fields associated
with additional Node types. Note that a template Node cannot be combined
with other Node types.
Department- department the computer
belongs to. Select the desired department from list.
To add a new department or to change the list of departments, send email
to NetDB support.
Location- the building where
the computer is located. Select the desired location from the list. To
add a new building or to change the list of buildings, send email to NetDB
support.
Room- the room where the computer
is located
Make and Model- the type of
computer it is. Select the Make and Model from the lists. To add a new
model, click on the New button. To add a new Make, send email requesting
it to NetDB support.
Operating System- Select an
operating system from the dropdown list.If the computer has multiple operating
systems, click on Add Another. To create a new operating system, click
on New.
Administrators- Administrators
are individual people or Admin Teams that are responsible for a computer.
List individuals by using their full names or their
SUNet IDs. These will be checked against the online Stanford directory;
if they are not found in the directory or if a name matches multiple people
in the directory, an error will occur. You can click on Verify to have
NetDB check and resolve the names before you try to save the record. If
an exact match is found, the person will be returned with a checked box.
If multiple matches are found, a list of people and associated departments
will be returned unchecked. Check to select the right administrator. The
verification process is thus especially useful if you use SUNet IDs since
it will show you information about the people connected to the SUNet IDs
so you'll know if you entered the right SUNet IDs. Note that the directory
lookup looks for matches on SUNet IDs, last name and email address.
Admin Teams are a set of people who are responsible
for the computer. For example, the Computer Resource Center may contract
with a department to support their computers. Instead of listing all the
people in CRC as administrators, it's simpler to list the CRC Admin Team
as an administrator. Admin Teams are generally named in all capital letters
and must be followed by a semicolon when entered as a node administrator.
(e.g., "CRC;").
If the administrator is not associated with Stanford and
does not have a sunetid, list Admin Team "OUTSIDE;"
as the administrator and add contact information in the
Comment field. Users- This optional field lists
the user of this computer. List individuals by using their full name or
their SUNet IDs. These will be checked against the online Stanford directory;
if they are not found in the directory or if a name matches multiple people
in the directory, an error will occur. You can click on Verify to have
NetDB check and resolve the names before you try to save the record. If
an exact match is found, the person will be returned with a checked box.
If multiple matches are found, a list of people and associated departments
will be returned unchecked. Check to select the right user. The verification
process is thus especially useful if you use SUNet IDs since it will show
you information about the people connected to the SUNet IDs so you'll
know if you entered the right SUNet IDs.
Custom Fields- These 2 custom
fields allow NetDB Users to create their own fields for searching and
reporting. Some examples: Asset Tag #, Lab Name, or Department Division.
Each field has a label and a value; for example "Label: Lab Name"
and "Value: Smithfield Lab" would make one custom field.
In a NetDB2 host record, each hardware address could only
be mapped to one required IP address. With NetDB version 3, the association
between IP addresses, hardware addresses, DHCP/Bootp and Roaming DHCP
is much more flexible. Each interface can have the following: Add Another Interface
Interfaces roughly correspond to network cards. If a Node
has multiple network cards (for example, docking station at office, PCMCIA
card at home), assigning multiple interfaces allows the Node to get different
IP addresses based on what hardware address is seen. To add another interface,
click on the "Add Another Interface" button
in the Interface Information bar (about halfway down the Create Node or
Modify Node page).
Hardware address- This 12-character
hexadecimal number can be entered in the common hardware address formats
below but will always be shown in the dotted format (1234.5678.9abc).
Hardware addresses must be unique throughout NetDB. Hardware addresses
are also required in order to enable DHCP/BootP and Roamng DHCP.
Interface Name (Advanced Node type only)-
Interface names would probably be used for computers that
host multiple websites or services.
DHCP/BootP- Checking the DHCP/BootP
box tells the DHCP servers to respond to DHCP requests from the associated
hardware address. This flag cannot be set without a hardware address.
This flag is also required to enable Roaming DHCP. For more information
about DHCP, see DHCP Help.
Roaming- Checking the Roaming
box enables Roaming DHCP. Roaming DHCP is usually used for laptops that
move from building to building. To set Roaming, a valid hardware address
and the DHCP/BootP flag are also required. For more information, see
DHCP Help.
IP Address- IP addresses can
be assigned in a number of ways.
Otherwise, NetDB will look for the next available address
in the address space, starting from the specified address.
Valid IP Address format is in dotted octet form: 171.64.20.1.
Valid Address space formats are shown below:
For more information, see Address
Spaces .
Because of the nature of web pages, IP addresses cannot
be confirmed as soon as they are entered. The "Verify address"
button tells NetDB to see check if the addresses are already used.
IP Address Name (Advanced Node type only)-
IP address names would probably be used for computers that
host multiple websites or services. To check if the names are already
used, click on the "Verify address & name" button.
DHCP Options- Because DHCP Options
are rare in Nodes, the window is normally hidden. To add DHCP options,
click on the Display options and add the desired options. If a Node has
DHCP options, this window will automatically be opened. For more information
about DHCP options, see DHCP Help
IPC Section
(IPC Node type only)
IPC addresses are addresses that this Node will pass out.
The most common IPC is a Shiva Fastpath that is providing IP address for
locatalk machines. The easiest way to assign a block of IPC addresses
is to select an address space (usually the same as the address space
of the IPC) and put the number of desired addresses in the Count box.
NetDB will try to find a contiguous block of IP addresses to assign. To
see these addresses before saving the Node record, click on "Verify
address & name" in the IPC section. Note that IPC addresses are
automatically assigned names.
IPC Address- List of addresses
that an IPC Node will pass out.
IPC Address Name- Automatically
assigned to an IPC address, this name is generated as follows:
For example, for IPC address 171.64.20.2, the automatic
name would be "DNAB401402" (hex AB = 171, hex 64 = 40, etc.)
This name can be changed, but that is not generally recommended.
Count- Count is the number of
requested IPC addresses. If Count is not specified, Count is assumed to
be 1. Expiration Date- Expiration
Date is a new date string field added to facilitate Residential Computing's
periodic purging of student computer records. For example, all the Nodes
in a freshman dorm may have an expiration date of 7/1/2001, just after
the end of the school year. During the summer, the administrator could
search on all expiration dates expiring before 8/1/2001 and delete those
records since the students have moved out. NOTE: NetDB does not take
any action based on the expiration date- this is purely an informational
field for you.
Group- Only Users in the same
Group as this record or with All Group access can modify or delete this
Node. User must also have record access to Nodes and the appropriate Node
types. A Node can be in multiple Groups.
Comment- This searchable field
is for any additional information.
Created By- This field gives
the full name and SUNet Id of the NetDB User who created this Node and
the date it was created.
Last Modified By- This field
gives the full name and SUNet Id of the NetDB User who last modified this
Node and the date it was last modified.
No punctuation
123456789abc
Dotted
1234.5678.9abc
Dashed
12-34-56-78-9a-bc
Colon
123456:789abc
Colons
12:34:56:78:9a:bc
DN<IPC address in hex>
© 2000 Stanford University. All Rights
Reserved.
|