Sun Java Web Console
This is a little rant from several angles.
Sun’s Java Web Console is a nice little toy. Great for those people who prefer the less extreme learning curve of a CLI, and great for manager types who like pictures.
I’ve used it several times before, but thought I’d try it in on x86 Solaris10u6 box I have here. Bloody Sun. You think a released version implies that it’s stable, and working.
For me the issue was that when I originally installed the server, I used a temporary hostname, and DHCP for network because I couldn’t be bothered to change my local DNS and figure out a spare IP. I then changed to fixed IP and hostname later.
The ramifications of this is that my hostname ended up being assigned to localhost, (aka 127.0.0.1). This means that when the WebConsole was initially installed and configured it used 127.0.0.1 throughout it’s hardcoded, (stupid Tomcat — hate it with a vengence), config files.
This is something that annoys the heck out of me: I understand developers making ‘packages’ that they can ‘deploy’ to a web server, (Tomcat). It’s nice to be able to ‘deploy’ a package. But for heck’s sake, why shove hostname/IP/port definitions in not just one file, but 50 stupid files that are zipped up along with shared libs and binaries? Why? Haven’t they heard of /etc/hosts, or even putting these definitions into somewhere common? Why do they have to have these definitions in multiple places?
Another great example of letting the developer take the lead in systems management.
Anyway, digging around the net trying to resolve my issue showed up a lot of similar complaints, but nothing really to sort it out. ‘wcadmin’ refused to start the ‘deployed’ packages, because they couldn’t connect to the Tomcat server running on my old hostname.
root@somewhere % wcadmin list Deployed web applications (application name, context name, status): console ROOT [stopped] console com_sun_web_ui [stopped] console console [stopped] console manager [stopped] console zfs [stopped] Registered jar files (application name, identifier, path): console audit_jar /usr/lib/audit/Audit.jar console console_jars /usr/share/webconsole/lib/*.jar console jato_jar /usr/share/lib/jato/jato.jar console javahelp_jar /usr/jdk/packages/javax.help-2.0/lib/*.jar console shared_jars /usr/share/webconsole/private/container/shared/lib/*.jar Registered login modules (application name, service name, identifier): console ConsoleLogin userlogin console ConsoleLogin rolelogin Persistent Jvm options: -server -Xmx128m -XX:+UseParallelGC -XX:ParallelGCThreads=4
I tried using wcadmin ro ‘undeploy’ and ‘deploy’ packages, and even the brut force method of
root@somewhere % find /var/webconsole /usr/share/webconsole /etc/webconsole /usr/lib/webconsole -type f | xargs egrep -l '127.0.0.1|localhost'
and manually modifying any config files found.
In the end I did a pkgrm/remove configs/pkgadd cycle:
1. Remove WebConsole packages.
system SUNWasac Sun Java System Application Server Admin Client application SUNWmcon Sun Java(TM) Web Console 3.0.2 (Core) system SUNWmconr Sun Java(TM) Web Console 3.0.2 (Root) application SUNWmcos Implementation of Sun Java(TM) Web Console (3.0.2) services application SUNWmcosx Implementation of Sun Java(TM) Web Console (3.0.2) services application SUNWmctag Sun Java(TM) Web Console 3.0.2 (Tags & Components) application SUNWzfsgr ZFS Administration for Sun Java(TM) Web Console (Root) application SUNWzfsgu ZFS Administration for Sun Java(TM) Web Console (usr)
The usual removal:
root@somewhere % pkgrm SUNWzfsgu SUNWmcosx SUNWmcos SUNWasac SUNWmcon SUNWzfsgr SUNWmconr SUNWmctag
Then remove all the config files:
root@somwehere % rm -rf /var/webconsole /usr/share/webconsole /etc/webconsole /usr/lib/webconsole
Or tarball up and then remove:
root@somewhere % tar cvf /tmp/webconsole.tar /var/webconsole /usr/share/webconsole /etc/webconsole /usr/lib/webconsole root@somewhere % rm -rf /var/webconsole /usr/share/webconsole /etc/webconsole /usr/lib/webconsole
2. Re-install the WebConsole packages:
If you have your original install DVD/CD handy, then just chuck it in, and install the packages from the Product directory:
root@somewhere % pkgadd -d /cdrom/cdrom0/s2/Solaris_10/Product SUNWzfsgu SUNWmcosx SUNWmcos SUNWasac SUNWmcon SUNWzfsgr SUNWmconr SUNWmctag The following packages are available: 1 SUNWasac Sun Java System Application Server Admin Client (i386) 8.2,REV=2006.08.16.08.46 2 SUNWmcon Sun Java(TM) Web Console 3.0.2 (Core) (i386) 3.0.2,REV=2006.12.08.20.48 3 SUNWmconr Sun Java(TM) Web Console 3.0.2 (Root) (i386) 3.0.2,REV=2006.12.08.23.39 4 SUNWmcos Implementation of Sun Java(TM) Web Console (3.0.2) services (i386) 3.0.2,REV=2006.12.08.23.39 5 SUNWmcosx Implementation of Sun Java(TM) Web Console (3.0.2) services (i386) 3.0.2,REV=2006.12.08.23.39 6 SUNWmctag Sun Java(TM) Web Console 3.0.2 (Tags & Components) (i386) 3.0.2,REV=2006.12.08.20.48 7 SUNWzfsgr ZFS Administration for Sun Java(TM) Web Console (Root) (i386) 1.0,REV=2006.10.24.20.44 8 SUNWzfsgu ZFS Administration for Sun Java(TM) Web Console (usr) (i386) 1.0,REV=2006.10.24.20.44
Even though you are installing version 3.1 of the Java Web Console, it actually appears as 3.0.2 for some stupid reason.
Everything will startup as expected using the new hostname defined.
root@somewhere % wcadmin list Deployed web applications (application name, context name, status): console ROOT [running] console com_sun_web_ui [running] console console [running] console manager [running] console zfs [running] Registered jar files (application name, identifier, path): console audit_jar /usr/lib/audit/Audit.jar console console_jars /usr/share/webconsole/lib/*.jar console jato_jar /usr/share/lib/jato/jato.jar console javahelp_jar /usr/jdk/packages/javax.help-2.0/lib/*.jar console shared_jars /usr/share/webconsole/private/container/shared/lib/*.jar Registered login modules (application name, service name, identifier): console ConsoleLogin userlogin console ConsoleLogin rolelogin Persistent Jvm options: -server -Xmx128m -XX:+UseParallelGC -XX:ParallelGCThreads=4
No related posts.
