Labnet Administrator Guide

'

Table of Contents

1Introduction 2

2System Configuration 3

2.1The Master Configuration Database 3

2.2The System Configuration Webtool 6

2.3Server Configuration Daemon 13

2.4Configuration File Management 15

2.5Webtool for Managing Files 20

2.6Writing Labnet File Templates 23

2.7Certificate Management 30

2.8Template Aware TFTP Daemon 30

2.9Configuring a Diskless Linux Client 31

3Image Management Software 33

3.1Replication of Master Images 33

3.2Windows XP Image Booting 39

3.3Windows 7 iSCSI Booting 41

3.3.1iSCSI Motivation 41

3.3.2iSCSI Implementation 41

3.3.3ISCSI Appserver Configuration 44

3.3.4ISCSI Appserver Boot Sequence 48

3.3.5Booting Windows 7 Client 52

3.4Creating Windows 7 iSCSI images 57

3.5Windows XP Imaging 69

3.6Building Servers 72

3.7Network Monitoring 86

4Managing the User's Data 90

4.1Labnet Software for User Support 90

4.2User Authentication 91

4.3Ldap Webtools 93

4.4User Backups 93

4.5The Backup Utility 97

4.6Labnet User Printing 101


Labnet Server and Desktop Management System

User Handbook

by

Michael Rayment

Labnet System Manager

Department of Computer Science


Abstract


Labnet is a computer management system developed at Memorial to manage about 1000 public access computers and 85 servers providing computing services for the academic community. Labnet has at its core a customizable database of system configurations both for servers and desktop clients. The database content is updated and managed by a web based GUI interface. Information from this database is then used to dynamically orchestrate a myriad of system configuration operations via Labnet configuration daemons running on each of the servers and desktop clients. This document will explore the underlying technologies behind the database and the daemons that govern the multifaceted aspects of system configuration including the desktop and server imaging and configuration file management as well as the user account and backup management. Virtually all aspects of the computers are controlled by the daemons and the information contained within the underlying database and software image repository. With Labnet, servers and desktop computers are simply centrally managed network appliances and as such, Labnet is a highly cost effective management strategy for enterprise level computer management.


1 Introduction


Labnet is a multifaceted software management system that performs desktop and server imaging and configuration as well as authentication, printer cost recovery and backups. All Labnet operations are centrally controlled by a database that is updated via a user friendly web based content management system. This same database acts as a repository for all computer specific configuration. Configuration changes to the database are automatically propagated to the desktop computers and servers immediately. Software for all Labnet servers running Linux and client computers running both Linux and Windows XP, is imaged from a master software repository under the direction of this database. Similarly all user data is backed up under the control of the system database. Every facet of our Labnet facility is managed and controlled by the master database.


Labnet currently manages around 85 servers, 100 cluster nodes and 900 desktop computers located in 40 labs across campus. The Labnet user community consists of 15000 students and 900 faculty and staff. Labnet currently offers 30 terabytes of on line data storage to its user community along with on line backups available 24/7 through a user friendly web interface. This data store is also accessible to users with non Labnet computers via Nomad.


Labnet has a ubiquitous presences on campus in student labs, the library, in student residences and in classrooms and, as such, is an ideal vehicle for delivering centralized computing services to the academic community.

Labnet centralized services that are currently supplied are:


  • Single sign on authentication (based on MUN's my.mun.ca account)

  • User data storage

  • Laptop access to data store

  • User backup retrieval

  • Client software imaging

  • Server software imaging

  • Printer cost recovery

  • Special printers for large format color charts

  • Software license managers

  • User web pages

  • Dual Operating system support - Linux and Microsoft


Clearly, Labnet has proven itself to be a viable management tool for administrating student labs across campus and the remainder of this paper will elaborate on the management software that was developed around a core database of configuration information that became Labnet. The discussion is broken down into three broad areas: system configuration, system imaging and user data management.


Of course there are situations that Labnet would not be appropriate. Labnet is best suited for situations where there are many homogenous processors that need to be managed remotely. In our situation this happens to be the case with our computer labs where a consistent environment is an asset. Another situation that would lend itself to Labnet software management would be the deployment of many autonomous processors, linked by Ethernet, used to do remote control and data gathering. The management of computers in a school district would be another application suited for Labnet.

2 System Configuration

2.1 The Master Configuration Database

The master configuration database was designed to be able to capture the differences among server and desktop computer configurations so that management of all Labnet computers could be centrally managed. Linux configuration files can be generalized into two basic structural formats, variable value pairs or tables. For simplicity our database design allows us to represent both configuration formats from a single MySQL database table of variable value pairs as defined below:










'ent_var_vals' table Definition:

Field

Type

Null

Key

Default

ent_id

bigint(20)

NO

PRI


var

varchar(90)

NO

PRI


indx

smallint(6)

NO

PRI


val

text

NO

NULL


mod_time

timestamp

NO

MUL

CURRENT_TIMESTAMP


The 'ent_id' associates this variable value pair with a particular instance of a configuration entity. It should be noted that an 'entity' is an instance of a collection of variable value pairs. It is analogous to a configuration file on a particular host. The 'var' field is the variable name and the 'val' field is the corresponding value. In the event that this variable can have more than one value, the the 'indx' field provides a way to provide an ordering on those values. A typical variable-value style configuration file is represented as a collection of these database records sharing a common 'ent_id'. Note that, if the variable is multivalued, then multiple records having a common 'ent_id' and 'var' fields would be present, one for each value. A typical table style configuration file is represented as a series of multivalued variables, one per column where the variable name is the column name and the index indicates the row number of the cell. For example the following table can be represented by the following series of database records:


Color

Mode

Red

Failed

Yellow

Warning

Green

Okay


Yields:


end_id

var

indx

val

23

Color

1

Red

23

Color

2

Yellow

23

Color

3

Green

23

Mode

1

Failed

23

Mode

2

Warning

23

Mode

3

Okay


Each row in the table represents a cell of the table where the 'ent_id' field associates the record with a particular entity instance and the columns are serially represented column by column where the 'var' field indicates the name of the column and the 'indx' field indicates the row number of this table cell element.


Clearly, the 'ent_id' is not a satisfying way to associate these values with a particular configuration entity. A second MySQL table, described as follows, is used to give a name to these 'entities' or collections of variable value pairs:


'entity' Table Definition:

Field

Type

Null

Key

Default

name

varchar(40)

NO

PRI


type

enum('client','server','standalone', ...)

NO

PRI


ent_id

bigint(20)

NO

MUL


status

enum('active','inactive')

NO


active


Where 'name' is the name associated with the collection of variable value pairs for all records having a matching 'ent_id'. There is a final table that is used by the web interface to manipulate and display the values in the database and the 'type' field is used to associate this entity with the collection of variables and their display characteristics found in the 'var_defs' table, defined as follows:


'var_defs' Table Definition:

Field

Type

Null

Key

Default

entity_type

enum('client','server','standalone','printer', … )

NO

PRI

NULL

name

varchar(90)

NO

PRI


view_type

enum('select','input','selectonly', … )

NO


NULL

link_type

enum('client','server','standalone', … )

YES


NULL

view_group

enum('uniq','Fstab','Rsync', … )

YES


NULL

attributes

set('mandatory','single','unique','table')

YES


NULL

regex

varchar(255)

YES


NULL

query

text

YES


NULL

indx

int(11)

YES


0

tooltip

varchar(2000)

YES


NULL

Where 'entity_type' matches the enumeration of 'type' in the 'entity' table above and 'name' is the name of the variable being defined. For each variable that can be a member of an entity of a given type, there is a corresponding record in this table that names the variable and provides attribute information about it. The next four fields (view_type, link_type, view_group, attributes) are used to control how the data appears on the screen (ie. is it a table or variable value pair, is it multivalued, etc.). The 'regex' field is a regular expression that limits the contents of the value to one that matches the regular expression. The 'query' field can be used to define an SQL query that enumerates the acceptable values that can be accepted as a valid value. The 'indx' field is used as a hint to position the variable on the web display. Finally the 'tooltip' field is used to specify what appears on the screen when there is a mouse over of this variable. Usually it contains hints as to what this variable should contain.


There are currently 60,000 variable-value pairs in the database, in 1700 different entities of 21 types. Some of the more salient entity types are as follows:


  1. client – describes the information that is specific to a diskless client computer

  2. server – describes the information specific to a managed server.

  3. printer – a collection of printer specific information

  4. standalone – basic information about computers in a Labnet vlan that are not fully managed

  5. services – information about the services that run on the servers

  6. rsyncImage – information about the different images

  7. fileMgr – information about the Labnet managed files


These entity types will be described in greater detail in the following discussions.

2.2 The System Configuration Webtool

A web based interface was developed to render the information in the master configuration database. The following screen shot shows the layout of the main features of this tool:




The most basic request would be to view an existing entity, which can easily be done using the commands in the Entity Maintenance box. Simply select the entity type from the drop down menu, enter the entity name and submit the request by clicking on the View Entity button. By selecting type 'standalone' and entering 'discovery' the following entity information is displayed:





This is a very simple entity consisting of 8 variables with their corresponding values plus a two column table with one column named cn_name and the other cn_domain. Note that the variables are divided into two categories, Mandatory and Optional, which indicates if a variable must have a value in order to produce a viable (active) entity. The following table indicates the records that exist in the ent_var_vals table corresponding to this display:


Ent_val_vals table entries for standalone entity 'discovery'

ent_id

var

indx

val

mod_time

1477

cn_domain

0

ichc2009.ca

2009-05-15 16:32:00

1477

cn_domain

1

ichc2009.ca

2009-05-15 16:32:00

1477

cn_name

0

mail

2009-05-15 16:32:00

1477

cn_name

1

www

2009-05-15 16:32:00

1477

domain

0

housing.mun.ca

2007-09-28 01:44:27

1477

ip

0

134.153.83.151

2007-08-23 23:48:21

1477

nms_contactgroup

0

housing_admins

2007-08-23 23:48:22

1477

room

0

UK0000

2007-08-23 23:48:21



Pressing the Use as Template button allows one to create a new entity using these values as the default values. To modify the data stored in an entity, one would simply choose the Modify Entity button instead of the View Entity button which would result in the following screen:



Note that there is a column of check boxes on the left. This column indicates whether or not the column has been modified. Each time one of the fields in the third column are changed, the check disappears, indicating that this field has changed. Clicking on a check box that is not checked will set it back to its original value. When all the values are satisfactory, one can click on Submit Changes to trigger an update to the database. Note that the input box style is not the same for all variables. There are sometimes drop down menus (server, nms_contactgroup), input boxes (mac_address), multivalued select boxes (cname) and a two column table with a row insert Commit button and Remove buttons in front of each row for deleting table rows. It is possible to modify individual table cells as well.


To add a new variable to this standalone entity type, click on the Main Menu button followed by the Variable Maintenance button located on the main page. The following entity type select page will be displayed:




In this case, we would select the 'standalone' entity type from the drop down menu and click on the Next button which would cause the following page to be displayed:




This table displays the variable definitions and their descriptive properties that can be used to control the way that variables are displayed and manipulated on the entity update page. By clicking on the variable names in the left column, one can edit existing variable parameters or, by clicking on the Add Variable button, a new variable can be defined. The following page would be displayed if the cn_domain button were selected:



If a new entity type is required or an old entity type requires removal, then clicking on the Entity Type Maintenance button from the main page would display the following page:




Creating a new entity can be done by.clicking on the Entity Creation button from the main page.


The Entity Search button on the main page is very useful for browsing and searching for various entities based on a variety of search criteria. This feature can also be used to perform batch edit changes and additions to the database based on the results of the variable search. Clicking it will bring you to the following entity type select page:




For this demonstration, let us assume that we are bringing up a new DHCP server called 'nermal' and that we would like to have all the standalone entities that belonged to the cs.mun.ca domain located in room EN1018 to get their DHCP information from this new server. The 'server' variable in the standalone entity controls what server will manage this client, so we must set the 'server' variable to 'nermal for all the standalone entities that match the search criteria. To do this, first we need to get to the page that sets up the search by selecting standalone from the drop down menu and clicking on the Variable Search button. The following page will be displayed:





Note that there is a column of check boxes on the left. By checking one or more of these boxes, we select the list of variables that can be displayed and edited in batch edit mode. For this example, we need to click on the check box along side the 'server' variable. Next, we need to set up the search criteria by selecting the values that must match from the various input options on the right hand column. Note that the matching search results must have all the selected values, ie. this is an AND database operation. At present, we have no way to do an OR select operation. For this example, we need to select the 'cs.mun.ca' domain from the drop down menu to the right of the 'domain' variable and then we need to select room 'EN1018' from the drop down menu to the right of variable 'room'. All that remains is to click on the Search button at the top or bottom of the screen. In this example, the following page is displayed:




The check boxes on the left hand side of the table indicate which entities will take part in the batch edit, thus, if there are some entities that you want to exclude, simply click on the corresponding check box. The next column shows the list of entities that matched the search criteria. Note that each of these entities are buttons that you can click on to bring you to the entity update page for that entity. This is useful if you want to do manual changes on a single selected entity. The remaining columns are the corresponding values of the variables selected for editing. In this case, since we selected the 'server' variable, this is a list of all the corresponding 'server' variable values. Let's assume that we want to batch edit all the listed standalone entities, so we simply click on the Batch Edit button which, in this case, results in the following page:




In the above example, you will notice that the list of batch entities that will be affected by this operation is listed at the top, followed by the name of the entity type of these entities. The remaining entries are the list of variables that are to be changed. In this case, since we chose only one variable, 'server', then that is the only entry displayed. At this point, we either use the drop down menu to select the new value or type in a different value in the adjacent input box. If this were a multivalued variable then a multivalued edit box would be displayed.


Batch editing tables is currently a bit cumbersome and limited but can be done using the Table Search button instead of the Variable Search button on the Entity Search page shown above.

2.3 Server Configuration Daemon

Once the database of configuration information has been established, some method is needed to propagate this information to the client and server computers. Additionally this information must be presented in a way that is compatible with existing client and server applications and administrative operations. To accomplish this, each server runs a configuration daemon called 'lnsysconfigd'.


One of its duties is to maintain an up to date copy of all the database configuration variable value pairs in an XML file format. This XML file format is accessible to all the client computers as they share NFS access to the same XML files used by the controlling application server. This allows each server and client computer to have access to configuration information regardless of whether the database is accessible and, therefore, server and client computers are much more resilient to failures. The format of the XML information is laid out in a directory hierarchy rooted in a directory that is, by default, “/usr/local/etc/labnet”. The information for each entity is stored in a file with a matching file name in a directory with a name that matches the entity type name. For example, the entity information for the entity 'discovery', which is a member of the entity type 'standalone', can be found in the file '/usr/local/etc/labnet/standalone/discovery'. The following is the XML rendering of the database information for 'discovery':


<?xml version="1.0"?>

<Entity_Profile>

<entity>discovery</entity>

<type>standalone</type>

<ConfigurationItem>

<variable>domain</variable>

<value indx="1">housing.mun.ca</value>

</ConfigurationItem>

<ConfigurationItem>

<variable>room</variable>

<value indx="1">UK0000</value>

</ConfigurationItem>

<ConfigurationItem>

<variable>ip</variable>

<value indx="1">134.153.83.151</value>

</ConfigurationItem>

<ConfigurationItem>

<variable>cn_name</variable>

<value indx="1">mail</value>

<value indx="2">www</value>

</ConfigurationItem>

<ConfigurationItem>

<variable>cn_domain</variable>

<value indx="1">ichc2009.ca</value>

<value indx="2">ichc2009.ca</value>

</ConfigurationItem>

<ConfigurationItem>

<variable>nms_contactgroup</variable>

<value indx="1">housing_admins</value>

</ConfigurationItem>

</Entity_Profile>


Contrast this with the information in the Ent_val_vals table entries for standalone entity 'discovery' on page 8. Notice how all the information is captured within the XML format except that the ent_id has been replace by the entity name from the entity table.


Once every 24 hours, or whenever 'lnsysconfigd' starts up or receives a SIGUSR1 signal, 'lnsysconfigd' does a complete sanity check to ensure that the database information is congruent with the XML files. It also performs sanity checks on other functions that it manages.


Unlike most daemons that wait for events to trigger actions, 'lnsysconfigd' sleeps for 1 minute and then polls the master database for changes. This means that the onus is on the servers to ensure that their data is up to date, thereby freeing the database from having to keep track of which computers have or have not been updated. Once 'lnsysconfigd' has initialized itself, it performs the following tasks in an infinite loop:


  1. Sleeps for 60 seconds

  2. Checks to see if the statistics reporting time interval has expired. The time interval is, by default, 5 minutes. If the time is up, then it evaluates the following information and reports the information back to the network monitoring database:

    • Percentage disk space and inode utilization for all mounted disks

    • CPU load average normalized for number of processors

    • Status of the software RAID devices

    • Status of daemons

    • Whether or not each disk partition is scheduled for an fsck

    • Percentage of network bandwidth utilized for transmission and receiving

  1. Checks to see if the sanity check time interval has expired. By default the time interval is 24 hours and, if it has expired, then a complete sanity check is performed with respect to the mysql and XML database values. It then continues on to step #7.

  2. Does a search on the most recent database change time stamp and compares the result with the local copy stored in the file /user/local/etc/last_query.conf. If no change has occurred then it goes back to sleep at step #1.

  3. A list of all the changed variables is down loaded from the database.

  4. For each of these changes, the updated values are applied to the XML data files.

  5. Any managed files that have changed are updated.

  6. All managed template files are processed yielding their corresponding derived files based on current database values. The resulting derived file is checked against the exiting file and installed if different.

  7. Run any scripts that need to be run when a file is updated.

  8. The server certificates are checked and updated if necessary.

  9. Run server function specific configuration. The following server functions trigger actions:

    • appserver – triggers the configuration of clients supported by this server

    • authdns – triggers updates to our authoritative myDNS database

    • masterldap – triggers creation of special machine accounts


  1. Update changes in the runlevel directories

  2. Go back to step 1

2.4 Configuration File Management

One of the most important operations of 'lnsysconfigd' is the management of the client and server configuration files. A special entity type, called 'fileMgr', has been created to direct this operation. Every managed file on our Labnet servers and clients has an entity description that is appropriately named based on the file name itself. The following is a webtool rendering of the 'access.conf' 'fileMgr' entity:


Figure xx:



The first four mandatory variables simply describe the normal file path, ownership and permissions information for this file. The optional 'script' variable is used to indicate to 'lnsysconfigd' that the specified script should be run whenever this particular file changes. The remaining FileTable table indicates what file instances should exist on a particular set of computers. Note that there is no way to enter new rows into this table. This is because of the hash values that must be computed for a given file instance. A special webtool, described later, was created to deal with the updating, deleting and creating of managed file instances. In this particular example, the computers that belong to the 'mscluster' group will all have a '/etc/security/access.conf' file that has a file hash of GpxEs3Rce+D53iStS1kipZxuC7E= if it is up to date. Using this hash, 'lnsysconfigd' can identify what files need to be updated by computing and comparing the file hashes. If the computed hash does not match the new or old hash values, 'lnsysconfigd' assumes that someone has manually made a local change to the file and will make a backup copy that is the filename with the suffix '.lnsyncsave'. Note that the other two file instances are templates and therefore the hashes only match the template file, not the actual file itself. In this instance, the template file hashes are compared and updated as with non template files but then the template file is processed through a macro processor that substitutes information from the database into the template based on the template macro commands. Then, the resulting file is installed into the specified destination. The template file that is associated with the mun@site_server is as follows:


<Template>

<setdefaults><type>server</type><entity><self/></entity>

# DO NOT EDIT THIS FILE

#

# This file was generated automatically by the program:

# /usr/local/sbin/lnsysconfigd

# and should not be modified directly.

#


# Login access control table.

#

################################################################

<if><varVal>ac_permission</varVal><then>


<iterateOverLists>

<iteratorList><varVal>ac_permission</varVal></iteratorList>

<iteratorList><varVal>ac_users</varVal></iteratorList>

<iteratorList><varVal>ac_location</varVal></iteratorList>


<if> <equal><item/><literal>allow</literal></equal> <then>


<literal>+: </literal><item>1</item><literal>: </literal><item>2</item>

<literal>

</literal>

</then>

<elseif> <equal><item/><literal>deny</literal></equal> <then>

<literal>-: </literal><item>1</item><literal>: </literal><item>2</item>

<literal>

</literal>

</then>

</elseif>

</if>

</iterateOverLists>

</then>

<else>

<literal>

+: root wheel: LOCAL .cs.mun.ca .math.mun.ca .pcglabs.mun.ca .</literal><varVal><type>server</type><entity><self/></entity>domain</varVal>

<literal>

-: ALL: ALL

</literal>

</else>

</if>

</setdefaults>

</Template>


What happens in this particular example is that the macro processor checks to see if this server has any Access table variables and, if not, then it dumps some default values. If it does, then the template processor iterates over the table values and fills in the permission field, the user field and the location fields based on the values displayed in the servers Access table. There is a useful Labnet utility that allows one to see what file will be produced from a specific template on a specific server or client. This command is invoked as follows:


templateCat templatefile hostname (client|server)


The templteCat output from the template above for one of our servers is:


# DO NOT EDIT THIS FILE

#

# This file was generated automatically by the program:

# /usr/local/sbin/lnsysconfigd

# and should not be modified directly.

#


# Login access control table.

#

################################################################

+: root wheel: LOCAL .cs.mun.ca .math.mun.ca .pcglabs.mun.ca

+: pbonnah: .ucs.mun.ca .cc.mun.ca

+: bkupclient: .mun.ca

-: ALL: ALL


Note how the macro substitutions embed themselves within the boiler plate text.


The following is the corresponding contents of the Access table for the specified server:





The final aspect that has been alluded to but has not been fully explained is how 'lnsysconfigd' determines what FileTable instance to use on a given server or client computer. In our example above, it was pretty clear that computers belonging to the 'mscluster' group would get that particular instance and that all other servers would get the 'mun@site_server' instance while all the client computers would get the mun@site_client version of the template file. In determining which instance will be used by a specific computer, the algorithm that is used starts at the most specific instance name and works towards the most generic name trying to find a match. Once the match is found that file instance is used on that computer. To generate the names, each computer entity has specific variables that identify it as a member of a file group, department or site. aHowever there are a few note worthy categories that have not been included. The following table illustrates all the possible instance nomenclatures and their meaning:


File Instance Format

Membership

<group name>

All computers that are members of this group get this file

<server_name>@host_server

Specific only to the server host specified

<server_name>@host

Specific only to the server host specified but is copied to the client image to be used by all the clients supported by this application server

<department name>@dept_server

Specific only to the servers that belong to a particular department

<department name>@dept

Specific only to the servers that belong to a particular department but is copied to the client image to be used by all the clients supported by this application server

<site name>@site_server

Specific only to the servers that belong to a particular site

<site name>@site

Specific only to the servers that belong to a particular site but is copied to the client image to be used by all the clients supported by this application server

default@labnet_server

All server computers get this file by default

default@labnet

All client and servers get this file




File Instance Format

Membership

<group name>

All computers that are members of this group get this file

<client_name>@host_client

Specific only to the client host specified

<appserver_name>@host_client

Specific to all clients served by this appserver

<client_name>@host

Specific only to the server host specified but is copied to the client image to be used by all the clients supported by this application server

<department name>@dept_client

Specific only to the clients that belong to a particular department

<department name>@dept

Specific only to the servers that belong to a particular department but is copied to the client image to be used by all the clients supported by this application server

<site name>@site_client

Specific only to the clients that belong to a particular site

<site name>@site

Specific only to the servers that belong to a particular site but is copied to the client image to be used by all the clients supported by this application server

default@labnet_client

All client computers get this file by default

default@labnet

All client and servers get this file


It should be noted that the file instance for a specific host is determined by starting at the top of this table and trying to sequentially find a match , stopping at the first match. For example if the “access.conf” file is being determined for host 'hogwarts' then the first test that is performed is to determine if 'hogwarts' is a member of any group associated with “access.conf”. If so then that group instance is used. Failing that test, the algorithm goes on to see if there is an instance of the name 'hogwarts@host_client' and so on. Since 'hogwarts' is in this case a client computer, the test for 'hogwarts@host_server' is ignored as are any names with the '_server' suffix.


The host name, department name and site name values, used in the matching process, are obtained from the host entity name, value of the dept variable for this entity and value of site variable for this entity respectively. Group associations are accomplished by associating a file_id, the name of the fileMgr entity, with a group name within the Config_Files_Table table for the particular cleint or server entity. For example, the following table entry exists on all 'mscluster' servers:




2.5 Webtool for Managing Files

As alluded to earlier, the fileMgr entities have a special web page interface that must be used to update old files or create new files. This interface is also responsible for updating the file hashes. It can be invoked from the main page by clicking on the Update Config Files button which loads the following page:




There are two alternatives open at this point, to modify an existing file or to create a new fileMgr entity. Selecting the Create New File button does not actually create a new file but it is a short cut to the entity creation page so that we can create the fileMgr entity for the new file that is to come under Labnet management. Note that only files that have entries in the fileMgr entity table can be managed by 'lnsysconfigd'. If an existing file entity is selected from the Select a File drop down menu, the list of existing file instances will be displayed if there are any and a Create New Instance is also displayed so that you can create a new file instance. By selecting the access.conf entity name from the drop down menu, the following page is loaded:




This indicates that there are three instances of the file already in existence, a template for clients, a template for servers and a regular file for all 'mscluster' computers. To edit an existing configuration file instance, simply click on the select button to the left of the corresponding file instance name. Before clicking on the Confirm button at the bottom, it is necessary to select the host on which you wish to edit the configuration file. Clicking on Confirm will load load the following page: