Before you set about changing your role within WACS, you need to first determine how the particular WACS installation you are using handles authentication. There are two options available - host based authentication or database authentication. Host based authentication is where access to the WACS system is controlled by the webserver's own operating system user accounts system. This is where all users log into wacs using the same normal username and password which they use to log into the webserver for other purposes. This is most likely to be used on private servers and on free tube style sites where only people performing collection maintenance are even required to log in. Database authentication is where user accounts for WACS are stored within the database itself. This method is most likely to be used on subscription based sites where people have to pay for access. The setting of the authentication mode is determined by the authmode variable within the security section of the main WACS configuration file wacs.cfg. For a new installation from packages, this will normally default to host based authentication unless the WebHost configuration is choosen.

The nature of the way WACS handles leases and permanent rights is not affected by the authentication method used - once the account is authenticated, the rules set in the lease or permanant access control list is what governs WACS' behaviour.

	Note
	Permanent rights based on a fixed IP address and account combination will not be automatically updated. If you are using permanent leases, you will need to seperately modify the role entry in the section for that IP address to read either admin or power to enable the admin modes

What to do - Database Authentication

Generally things are quite a lot simpler when using database authentication as the WACS user database is usually preloaded with three default accounts :- root, support and guest . Of these root has full admin rights, support has power user rights and guest has normal user access. The default passwords for these accounts are as follows:

Username	Password	Role
root	Svjck981	admin
support	uKiFt126	power
guest	freebie	viewer

	Tip
	These default passwords might change in future, for the current value (ie if these don't work), you can check the file user.xml in the populate directory of the wacs distribution.

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?