Security is a tricky item. Having created hundreds of application servers and Deployment Manager cells, occasionally it has been necessary to manually turn off security. Normally, this happens when first setting up security, whether it be the local z/OS security system, or connecting to an LDAP server...sometimes the set-up has an error and your cell/server will not start, or you are unable to login. This article will cover what is needed to manually turn off security so you can start your cell or server and login to correct the situation.
WebSphere files on z/OS are stored in ascii format. The z/OS system is ebcdic...so the first order of business will be two utility scripts to convert ascii to ebcdic and ebcdic to ascii.
One last note on these scripts....the left and right brackets [ ] are not ebcdic characters....so when you enter them....you need to turn on HEX and make the left bracket [ a x'AD' and the right bracket ] a x'BD'
The following script will convert ascii to ebcdic: (script name 2e)
if [ $# -ne 1 ]; then
echo "Usage : 2e fileName"
echo "Output: fileName.E"
iconv -f ISO8859-1 -t IBM-1047 $1 > $1.E
$ 2e myasciiFile
The following script will convert ebcdic to ascii: (script name 2a)
if [ $# -ne 1 ]; then
echo "Usage : 2a fileName"
echo "Output: fileName.A"
iconv -f IBM-1047 -t ISO8859-1 $1 > $1.A
$ 2a myebcdicFile
These scripts should be saved in a location in z/OS Unix and that location needs to be added to your PATH environment variable. So if you have saved them to /usr/lpp/scripts Then you can either place this directory in your .profile file on the PATH variable or you can export a new PATH variable.
$ export PATH=$PATH:/usr/lpp/scripts
They also need to be executable, so using chmod:
$ cd /usr/lpp/scripts
$ chmod 755 2e 2a
Okay, now the preliminary work is out of the way...we can look at where the security switch is set. For standalone servers the location of the configuration files is:
The location for the Deployment Manager configuration files is:
The mountPoint and cellName locations above were named by you when the server was created. Inside of these directories will be a file named security.xml. Remember, this file is store in ascii format so using the scripts we created earlier, let's convert it to ebcdic.
$ 2e security.xml
You will now have a file that you can view as well as edit. The file name will be security.xml.E.
Using the USS editor, open the file.
$ oedit security.xml.E
On the second line of this file, over to the right...there will be a variable enabled="true" . In order to turn off global security, change the true to false...then save the file. Now we have our ebcdic file with the correct values, but we need it in ascii format. We need to execute the 2a script:
$ 2a security.xml.E
Now we have a file named security.xml.E.A that we need to rename security.xml. Before we do this, we should save the original file...just in case.
$ cp security.xml security.xml.ORIG
Now we can rename or move our ascii file with security turned off.
$ mv security.xml.E.A security.xml
For our last item, we need to make sure the permission bits, the owner and the group ownership on the new file are the same as the original file. Using the chown, chgrp and chmod commands....make the security.xml file the same as security.xml.ORIG.
You now should be able to start your server or deployment manager and using the Administration Console correct any problems with your security set-up.
These types of errors don't happen that often...but when they do, it is always good to know how to manually turn security off so that the server or cell can start.