Corrections to spec file and scripts and update to the micasad.

doc/Readme.txt

@@ -41,7 +41,7 @@ Common Authentication Service Adapter (CASA)
         process that makes the IDK API calls. The
         credentials, which are stored by applications in
         miCASAd, are maintained in memory and written to 
-	  disk for this release. Session-based secrets implies
+	disk for this release. Session-based secrets implies
         secrets that are stored in an in-memory cache, are
         available only as long as the user is in session on
         the desktop, and are destroyed when miCASA daemon
@@ -57,7 +57,7 @@ Common Authentication Service Adapter (CASA)
         placed as the last module in the auth and session
         stacks of xdm, gdm, kdm, login and sshd PAM
         configuration files. The functionality of this 
-	  module is to store the credentials in miCASAd. 
+	module is to store the credentials in miCASAd. 
 
         Any PAM module that uses the IDK APIs must set its
         effective user id temporarily to that of the user
@@ -88,8 +88,8 @@ Common Authentication Service Adapter (CASA)
 3.0  Known issues
      
      - Secrets with IDs using reserved characters may fail.
-     These will be fixed in a future release. Reserved 
-     characters are 
+       These will be fixed in a future release. Reserved 
+       characters are 
 	:
 	\
 
@@ -100,11 +100,89 @@ Common Authentication Service Adapter (CASA)
        (1.1.9 or later) available for download at 
        http://www.mono-project.com/Downloads.
 
-    - CASA install rpm that is intended for 32 bit architecture
-      should not be installed on 64 bit architecture because
-      it can cause runtime problems.
-	
+     - CASA install rpm that is intended for 32 bit architecture
+       should not be installed on 64 bit architecture because
+       it can cause runtime problems.
 
+     - Since CASA is tied to the Linux login process via PAM,
+       events that cause the system to become inconsistent or 
+       unstable may cause a user to be unable to login to the
+       workstation.  Some possible causes of inconsistency or
+       instability are:
+        
+         - Installing 32 bit CASA RPMs on a 64 bit OS
+	 - Performing a hard reset on the machine
+	
+       Following the steps below will restore the ability to 
+       login.
+         
+	 1) Reboot machine
+	 2) When boot loader menu appears, type "init=/bin/bash"
+	    (without quotes) on the options line and then Enter.
+	    This will cause the machine to boot into a command 
+	    shell with root privileges.
+	 3) At the command prompt type "chkconfig micasad off"
+	    (without quotes).  This will prevent the CASA daemon
+	    from being loaded during bootup.
+	 4) With a console based text editor (i.e. vi, emacs) 
+	    remove all lines referencing the pam_micasa module in
+	    the following pam configuration files (some files may 
+	    not exist depending on what desktop managers have 
+	    been installed:
+	    
+	    - /etc/pam.d/gdm
+	    - /etc/pam.d/xdm
+	    - /etc/pam.d/kdm
+	    - /etc/pam.d/sshd
+	    - /etc/pam.d/login
+	         
+	 5) At the command prompt type "init 5" (without quotes)
+	    to boot into runlevel 5.  This will provide you with a
+	    graphical login prompt.  You should be able to login
+	    at this point.
+	    
+       After you have restored login capabilities, you will need
+       to resolve the inconsistency that prevented login in the
+       first place.  If you had installed a 32 bit CASA package
+       on a 64 bit OS, you will need to uninstall the 32 bit
+       package and install a CASA package built for 64 bit
+       architectures.  If you are recovering from a hard reset
+       no further action should be needed.
+       
+       To make it so CASA will run at boot time, open a shell and
+       at the prompt type "chkconfig micasad 1235" (without 
+       quotes).  This will cause micasad to be run at runlevels
+       1, 2, 3, and 5.
+
+     - When logged in to a KDE session, the gnome-keyring-daemon
+       does not run by default.  Therefore, all apps that access
+       the daemon, including our CASAManager will not be able to
+       manage/access the gnome-keyring.
+         
+       You can manually start the daemon by running the following
+       command from a shell prompt:
+       
+       gnome-keyring-daemon 
+       
+       When the gnome-keyring-daemon starts, it prints the
+       GNOME_KEYRING_SOCKET environment variable and its value to
+       the terminal. In Gnome, the daemon is started and the 
+       environment variable is loaded into your X session 
+       environment by default, but in KDE, you will
+       have to manually load it.
+        
+       To load this environment variable, run a command similar to
+       the following command from a shell prompt (replacing the 
+       value of the environment variable with what the daemon
+       output to the screen when you started it):
+       
+       export GNOME_KEYRING_SOCKET=/tmp/keyring-oaTsPs/socket
+       
+       Then you can run CASAManager GUI (from the same terminal
+       you exported the variable from) and you will be able to
+       manage and use the gnome-keyring in KDE just like you
+       could if you were logged into Gnome.
+       
 4.0  Legal Notices
 
      Novell, Inc. makes no representations or warranties