If you logged in at the start of this WACS session, you will be using the lease-based security mechanism - this is the easiest type in which to change your account status to gain access to the administration tools. To make the change, you first need to log out of WACS; this can be done very simply by clicking on the logout link at the top right hand corner of the WACS main menu (aka front page). Once you've logged out you need to edit the main WACS configuration file, usually called /etc/wacs.d/wacs.cfg and find adminusers. This can be done with any text editor capable of working with XML or plain text files which you are familiar with. Once you've found the adminusers entry, simply add your account name to the list, separated from the other entries by a comma if necessary.

In this example we'll add johnd to an existing admin users list that includes the wacs account itself, and two other users called Karl D and Julie K (account names karld and juliek respectively).

Before:

  <adminusers>wacs,karld,juliek</adminusers>

After:

  <adminusers>wacs,karld,juliek,johnd</adminusers>

	Note
	In keeping with normal Unix practices we do not allow spaces in user names. Our accounts are of course often the same as the Unix account names; definitely so if we're using Host Authentication but still a good idea even if we're not.

Once the account name has been added to this file and the modified file saved, we simply log in again using the normal WACS login page and our user status will have changed. We can then proceed the next major section (the section called “Everything Looks Different”) on how to make use of our new found additional priviledges.

The actual current level of access is determined by the role field within the active leases file. If you want to grant extra priviledge for only the duration of the current lease, you can do this by directly editing the lease file. The default location of this file is /var/run/wacs/leases.acl and if you call this file up in an editor you just need to find the entry with the correct IP address and username and change the role in that entry from viewer to admin.

Here we have to deal with a slightly different concept. If you make the changes detailed above, whenever and from whereever you log in, your account will take on the elevated status it has been assigned. This is because whenever you login your right to elevated status is checked for in the configuration file and your access right record for that IP address in the leases file set accordingly. A permanent access right is based upon a particular permanent IP address and doesn't go through this assignment process. It is therefore completely possible for a given person's PC (so long as it has a fixed IP address) to be given administrator access but for that person not to have any elevated access when using their account from other system. In some cases, this may be what you want, although it would preclude that person working from home, etc. Similarly you can also use this mechanism to offer automatic administrator priviledge to anyone logged in on the local system itself.

The permanent access rights are controlled by a file called wacs.acl which lives in the same directory as the main Wacs configuration file. This will typically be /etc/wacs.d , but might be elsewhere especially if multiple Wacs servers are running on the same web server. If the Wacs install has been done using the packaged versions (.rpm or .deb), a sample entry showing how to do this will be included but commented out in the installed default wacs.acl file. Once uncommented, this looks like this:

<?xml version='1.0' standalone='yes'?>
<accesslist>
 <ipv4-127.0.0.1>
   <user>wacs</user>
   <type>permanent</type>
   <date></date>
   <role>admin</role>
   <prefexcl>D,B,C,F</prefexcl>
   <usedirect>yes</usedirect>
 </ipv4-127.0.0.1>
</accesslist>

Each section of the file is enclosed by a <ipv4-host_IP> and the entries within apply to that host address only. There is one magic entry, <ipv4-all> which can be added to disable the access control system entirely. Looking through the fields in each entry, the first one, user, gives the user name to attribute accesses from this host to. The second attribute, type, is either permanent or lease. If it is permanent, access will always be granted as the specified user to this IP address. If it is lease, access will be granted until the time/date given in this field (in unix seconds since epoch date format). The role field defines what level of access this user should be given to make modifications to the database.

In many cases where the site owner is not worried about security or who can access the Wacs system (providing they have access to the machine), uncommenting the entry for ipv4-127.0.0.1 in the wacs.cfg is probably the easiest thing to do. Generally this lets the console user manage the system fully and requires everyone connecting in over the network to have to log in. However this mechanism is a little simple-minded and can be circumvented by someone with some knowledge and a genuine login account on the server.

You can also use the same mechanism to grant permanent access to any other IP address on the internet, including obviously certain machines on your local network. Shown below is a sample file that grants such access to two machines on the local network - in this example johnd is an administrator and billw is either telephone support or a salesman - he's only a power user!

<?xml version='1.0' standalone='yes'?>
<accesslist>
 <ipv4-192.168.1.15>
   <user>johnd</user>
   <type>permanent</type>
   <date></date>
   <role>admin</role>
   <prefexcl>C,F</prefexcl>
   <usedirect>yes</usedirect>
 </ipv4-192.168.1.15>

 <ipv4-192.168.1.17>
   <user>billw</user>
   <type>permanent</type>
   <date></date>
   <role>power</role>
   <prefexcl>D,B,C,F</prefexcl>
   <usedirect>no</usedirect>
 </ipv4-192.168.1.17>
</accesslist>

	Warning
	Of course if you're using the IP addresses for this purpose you do need to make sure that they are statically allocated and that each person's PC is always assigned the same address. You wouldn't want billw getting administrator access just because he was the first person to switch on his PC one morning, now would you?