• Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

Comments (8)

1 localhost commented Permalink

Nice trick Bill, I'll have to remember that.

2 localhost commented Permalink

Great tip, Bill. I've hit this problem in the past and my solution was simply to nuke WAS and start over. Didn't occur to me to use wsadmin. I'll have to remember that.

3 localhost commented Permalink

Nice article. When I forgot the password for my RAD Test Environment, I used the following technique.[code]Goto C:\{RAD}\runtimes\base_v6\profiles\{profile}\config\cells\{cellname}[/code],open security.xml and look for the tag...

4 localhost commented Permalink

Hi Chris and thanks for your comment. I appreciate that you posted this information about editing the security.xml file. You obviously understand both how security state is implemented in WAS v6 but you also understand why using the wsadmin tool is preferable. For anyone out there reading this who doesn't understand why wsadmin is preferable, here's why:It's always preferable to use public commands / APIs rather than internal data structures (whether we're talking about using WAS or just in general), because:

  1. Any mistake you make while editing an internal data structure might put the system in an inconsistent, unrecoverable state, and
  2. Internal data structures frequently change, so a valid change in the current release may become an invalid change in a subsequent release
It turns out that in this case, the wsadmin command I used performs the exact same action that Chris performed - it sets security.xml's enabled=true flag to enabled=false. But although this is a happy coincidence today, there's nothing stopping the WAS team from altering the data structures in a future release so that hacking security.xml only partially alters the system's security state. If this occurred WAS might get very confused when it tries to start up. However, if you get in the habit of using published administrative commands, you're shielded from changes to internal data structures. You're using the same commands and observing the same results; it's just that the commands may be performing different internal functions.Note that when I first figured out the root problem, a good friend pointed out the same solution that Chris pointed out (edit security.xml). But I decided to figure out the right way to change this so that I didn't get into bad habits that could eventually lead to a great deal of pain.

5 localhost commented Permalink

If it's going about WAS Test Environment server in WSAD/RAD, then there is anothersafe way would be to use WSAD/RAD to do it: 1. Open server configuration editor (double-click server entry in Servers view) 2. Click Security tab 3. Uncheck "Enable security" checkbox there 4. Save (Ctrl-S) 5. Start the test server - it should start up without checking security nowIt might look like another solution for the problem Chris64 addressedhowever it mitigates the risk of damaging internal server configuration data.

6 localhost commented Permalink

I'll be damned. Where were you last Sunday roman.l?

7 localhost commented Permalink

found this article very useful, thanks to my dearcollegue who pointed me to this article when I was about to break my head.

8 localhost commented Permalink

This is a life-saver! Many thanks!

Add a Comment Add a Comment