This document details the importance of the Siteminder server path, how it is used during the webagent boot process and how duplicate inodes can create problems.
This only applies to webagents running on a Linux \ UNIX operating system.
The importance of Serverpath and it's relation to semaphore creation.
Overview of the process
A system call on the Siteminder webagent is used to generate a unique token when the agent starts.
On unix system this token is derived from the inode value of the webagents serverpath (as specified in your webagent.conf), this token is used to create both shared memory segments and semaphores during the webagents startup and must be unique for each serverpath.
When the webagent starts we can see the key been used to create the semaphores and shared memory segments:
As this key is derived from the inode value of the server path it's not only important that each serverpath specified in the webagent.conf is unique but also the inode value for that serverpath is unique too.
How duplicate inodes exist
On the unix file system each file or folder is assigned a unique inode value. Although this value is unique to a particular file system if multiple file systems are mounted, and serverpaths exist on different file systems there is a risk that two server paths could have an identical inode value and thus generate identical tokens causing the webagent to fail.
Finding the duplicate inodes
This simple procedure can be used to find all your duplicate inodes:
- Note down all your serverpaths in webagent.conf.
- Login to the server.
- CD to the serverpaths parent directory (One level above the serverpath).
- use ls -I to display the inode values.
- write down the inode value for the serverpath folder (see diageam below).
- Continue from step 3 until you have documented all your inode values.
- Now you have documented all your inode values check your list for any duplicate inodes values.
Fixing the duplicate inodes
Once you have found your duplicate inodes use the following procedure on one of the conflicting serverpaths.
- Stop the web server
- Create a new serverpath directory under the same parent directory as the conflicting serverpath.
- Copy your data from the old to new serverpath.
- Rename the old serverpath to something unique (eg serverpath_old)
- Rename the new serverpath to the name of the old serverpath (verify this using webagent.conf).
- Check that the LLAWP process is down (use pgrep LLAWP to check).
- Reboot the server or use ipcrm to cleanup any unused semaphores.
- Start the webserver.