File Server Connectivity and
Network Access Strategy
Division of Computing and Information Technology
Clemson University
February - 1996
The purpose of this document is to define the configuration of the LAN at Clemson with respect to access to file servers. The configuration is one in which all users at Clemson have access to the network. This connectivity is possible through workstations in labs, offices, dorms, or via remote connection. Users are able to share data and applications across user, group, and building boundaries. Printers are able to be shared by all or a subset of users and controlled/configured remotely.
The LAN infrastructure is built upon Novell Netware 4.1 and Novell’s NDS (Netware Directory Services). Netware supports connectivity from DOS/Windows, Windows ’95, Mac OS, Windows NT, OS/2, and UNIX. Netware Directory Services (NDS) is a distributed and replicated database that holds the object and security definitions about the network. NDS provides the users and the network administration staff with a logical view of the network that conceals the sometimes bewildering complexity of the actual physical topology and configuration.
It is NDS that enables the network to appear as a single cohesive entity to the user. No longer is the view centered on file servers; as file servers and their volumes are just another type of resource on the network that the user may or may not want to access. With NDS, a user performs a single login to the network and is authenticated as necessary with respect to resources on the network.
NDS is structured and represented using the tree model. In Figure 1 above, the root of the tree is the organization name, CLEMSONU. Under the organization name are a number of organizational units. This is usually reflective of structure of the organization. In Figure 1, the org units for DCIT, College of Engineering and Sciences (CES), and the College of Agriculture and Life Sciences (CAFLS) are shown. Org units can themselves contains org units. An example of this is shown with DCIT having org units of ISD, CSO, CTS, CSG, and APS. Org units are sometimes called "containers" since they may contain many types of objects such as users, servers, server volumes, groups, organizational roles, aliases, computers, printers, print queues, and user profiles. The NDS database is collectively referred to as "the tree".
The process of naming objects in the tree follows a "dot" naming convention that conforms to the X.500 standard. For example, the CSO container in Figure 1 may be referred to as ".cso.dcit.clemsonu".
Designing the NDS tree is a subjective process. You can use the organizational model as shown above, or a geographic model if your organization is dispersed. The underlying objective in designing the tree is making the resources in it easy to manage. There are over 30,000 user objects alone in our tree, which makes Clemson one of the largest users of NDS in the world. Given that we want the maintenance of userids to be handled by the Automatic Userid System (AUS), we have taken a hybrid approach to tree design. The clemsonu tree has two distinct flavors that complement each other very well: the first being the traditional organizational model discussed previously and the second being a categorical model based on user type.
In Figure 2 above, see that there are 3 org units that are used at the organizational level to basically hold user objects. They are "students", "employee", and "misc". The students container holds all userids for students. Similarly, the employee container holds all userids for employees. The misc container was created to hold special userids that are not owned by a student or employee. Examples of these might be friends of the University, outside customers of DCIT, or miscellaneous system or test userids that are not expressly owned by a student or employee.
The students, employee, and misc containers each contain 28 org units; one for each letter of the alphabet and one for groups and printers respectively. The containers for each letter of the alphabet hold users whose userid starts with that letter. For example: the userid "amie" belongs to an employee so that user would be in the "a.employee.clemsonu" org unit. This is also referred to as that user’s "context". The complete, or fully distinguished, name of the user is "amie.a.employee.clemsonu". Userids that do not begin with an alphabetic character are placed in the "Z" container.
Because groups of users may have common management and/or security attributes, NDS provides the "group" object. The "groups" container holds them. These groups are maintained by Computer Resources. Users that need to make use of a group may either contact Computer Resources to have a group created and maintained for them, or the user may create and maintain the group himself in the organizational part of the tree. Users that choose to create and maintain groups themselves may obtain assistance from Computer Resources over the telephone or from Client Support. We suggest that you let Computer Resources assist you. Groups may be requested by anyone, consisting of any set of users. For example, a professor could request a group consisting of a set of student users that he wants to permit to a certain set of data on one of his group servers.
The "printers" container holds print queues designated to be serviced by printers located throughout the organization. Most print queues are available to all users. The print queues are serviced by print servers and printers that are located throughout the NDS tree. The printers group is centralized for easy access by users. Also, all printers defined to NDS may be made accessible from other systems across campus such as MVS, VMS, or any UNIX host. Similarly, there are print queues available for printing to printers connected to other systems. Network Services is available to assist you in defining printers to NDS and setting up printing capabilities from/to these other systems, from workstations on the net, or to printers in labs, dorms, offices, or remote locations.
Figure 3 introduces two file servers called employeD and studentD. These servers are referred to as data servers. They hold the personal data, or "home directories", for all users. StudentD holds the home directories for all users in the students container and employeD holds the home directories for all users in both the employee and misc containers. This is a departure from the traditional approach of users having home directories on the departmental (group) server. This is necessary since at this point a number of users do not have access to a group server. Other benefits of this departure are increased manageability, increased per user storage space, high speed backup/restore capability, and the Hierarchical Storage Management (HSM) capabilities of these two servers, as well as increased assistance from Computer Resources. Also, as users move between departments and buildings, there is no data movement required. Students have a home directory disk quota of 5 megabytes per user. Employee and misc users receive a 100 megabyte quota by default. These limits may be increased on a per user basis by contacting Computer Resources.
The students container is also home, as shown in Figure 4 above, to the student application servers. These servers are named student2-student6. They are all exact mirrors of one another and are, for all intents and purposes, read-only. They are placed strategically on the network, basically one per lab, and perform the task of serving up application software and data as well as Microsoft Windows to the lab workstations. The lab workstations locate the nearest application server as the user logs in to the network. The workstation attaches to it for the purpose of obtaining applications and also attaches to the appropriate data server to give the user connectivity to his/her personal data. The data server is studentD if the user is a student or employeD if the user is an employee or misc user. While the application server does serve Windows to the workstation, the user’s home directory contains the configuration files for Windows and other application software available in the lab. This allows the user to control his/her own Windows and other software setup.
In the case where an employee or misc user is using the lab, these configuration files are automatically placed in a subdirectory under the user’s home directory. The name of this subdirectory is "lab$tuff". It ensures that lab configuration files will not conflict with any other setup information that may be there for running software from some other location or configuration, such as the user’s office.
Figure 5 illustrates how a departmental (group) server integrates into the campus wide strategy. The employee user, "berger", is managed by AUS and owns a home directory on employeD. Berger also happens to be a user in the College of Engineering and Sciences (CES), which maintains a presence in the organizational part of the tree. In the CES container, there are resources which the user may or may not have access to. This is at the discretion of a TSP designated by the college and registered with Client Support. Berger is a member of the group "CES Management.groups.employee.clemsonu" which is maintained by Computer Resources, as well as the CES group "everyone.groups.ces.clemsonu" which is managed by the "CES NW Admin". As mentioned previously, whether or not Computer Resources performs management of any or all groups is at the discretion of the college or department.
In the CES container, you will see the "organizational role" by the name of "CES NW Admin". Organizational Roles are another type of object that is part of the NDS tree. When the CES container was created and the TSP for the department or college was named, DCIT created the "CES NW Admin" object and designated that user to be an "occupant" of that role. The org role was given the appropriate authority over the CES container. Any user that is an occupant assumes all rights of the org role. Multiple users can "occupy" an org role.
Continuing to reference Figure 5, see that there is an employee "profile" in the employee container as well as a CES "profile" in the CES container. Each user object in the tree may have a single profile defined to it as an attribute. A profile contains, among other things, a login script. All users in the employee container have their profile set to "employee profile". The employee profile is controlled by Client Support, while the CES profile is controlled by the CES NW Admin org role with assistance from Client Support.
The employee profile login script performs basically three tasks. First, the login script maps drives to resources that the user is entitled to reference as an employee. Second, it checks the user for membership in a group that has been "registered" with Client Support. For example: the CES NW Admin might have registered the group "everyone.groups.CES.clemsonu" and the profile "CES profile.CES.clemsonu". The employee profile login script will check to see if the user performing the login is a member of "everyone.groups.CES.clemsonu" and if so, include the login script for "CES profile.CES.clemsonu". The third, and final, task performed by the employee profile login script is to check to see if the user is performing the login from a workstation in a lab. If so, the appropriate drives are mapped to the nearest application server and the environment for using the lab is initialized as previously defined.
Figure 5, shows CES having one group server, CES-NW1. In fact, CES may have many or no servers defined. The need for a group server is at the discretion of the Server Support Group (SSG) along with the department or group. This is often related to the amount and usage patterns of any shared data or applications. SSG builds and deploys group servers as needs dictate, and there are a myriad of considerations. For example, different groups may share a single group server within a building without a degradation in performance. The resource management is done in such a way that servers may be added or consolidated without impact to users.
In any case, whether or not an entity contains servers at this point is irrelevant to the need for the college, department, or group to have a presence in the organizational portion of the tree. A TSP and corresponding org role need to be defined. Resources may be made available for users and groups at any time. Groups, profiles, printers, and other resources may be put into place, regardless of the presence of a group server.
As the employee or misc user performs the login and the profile login script executes, there are certain resources that the user is automatically connected to via drive mappings. Additional resources may be added, but these are the base standards that should remain a constant:
For those employee users that already maintain a presence in the organizational part of the tree, there will be a transition period. The new userid in the employee container needs to be given the rights and group memberships that the current userid possesses. The user’s home directory data will be moved from the group server to the employeD data server. Lastly the old userid will be retired. Client Support and SSG will coordinate this move for any users that currently have this status.
This paper will be followed by other documents providing detailed information concerning the LAN configuration at Clemson. Other papers will discuss additional resources such as unified authentication services and personal and departmental world wide web page implementation and availability as these capabilities are put into production. If you have questions concerning the design and/or implementation of this strategy, please contact David Condrey (davidc@clemson.edu) of the Server Support Group or Client Support (client@clemson.edu). If you need assistance in implementation, please contact the appropriate group as defined in this document.