Issue Details (XML | Word | Printable)

Key: GLASSFISH-15544
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Critical Critical
Assignee: Anissa Lam
Reporter: sss150302
Votes: 0
Watchers: 2
Operations

If you were logged in you would be able to see more operations.
glassfish

[BLOCKING] Cannot login to GUI after upgraded from v2 applying Glassfish 2.1.1Patch8 Enterprise profile

Created: 12/Jan/11 06:01 AM   Updated: 17/Feb/11 12:08 AM  Due: 18/Jan/11   Resolved: 19/Jan/11 08:08 AM
Component/s: admin_gui
Affects Version/s: 3.1_b35
Fix Version/s: 3.1_b39

Time Tracking:
Not Specified

File Attachments: 1. XML File domain_after_upgrade.xml (49 kB) 12/Jan/11 11:30 AM - Bobby Bissett
2. XML File domain_before_upgrade.xml (58 kB) 12/Jan/11 11:30 AM - Bobby Bissett
3. Text File server-cannotCreatClassLoader.log (34 kB) 13/Jan/11 02:41 PM - Anissa Lam
4. Text File server.b38.log (136 kB) 20/Jan/11 04:18 AM - sss150302
5. Text File server.log (184 kB) 12/Jan/11 08:46 PM - sss150302
6. Text File upgrade-31-b38.log (16 kB) 20/Jan/11 04:18 AM - sss150302
7. Text File upgrade-31-b39-nightly-20-jan-2011.log (23 kB) 21/Jan/11 02:27 PM - sss150302

Image Attachments:

1. adminconsole-auth-module.jpg
(216 kB)

2. console-screen-b38.jpg
(111 kB)

3. upgraded-admin-b35-jdk6u23.png
(73 kB)
Environment:

Solaris sparc

Issue Links:
Dependency
 

Tags: 3_1-approved 3_1-blocking 3_1-upgrade 3_1-verified EE Enterprise HADB
Participants: Anissa Lam, Bobby Bissett, kumarjayanti, sirajg, sss150302 and Tim Quinn


 Description  « Hide

Glassfish 2.1.1 Patch8 to 3.1 B35 Upgrade in Enterprise profile.

Follow the steps as per http://java.net/jira/browse/GLASSFISH-15108

After upgrade try to load the admin console at 4848, it does not load and throws a
" Authentication failed " message. Please see the attachment upgraded-admin-b35-jdk6u23.png



sss150302 made changes - 12/Jan/11 06:04 AM
Field Original Value New Value
Attachment upgraded-admin-b35-jdk6u23.png [ 27566 ]
sss150302 made changes - 12/Jan/11 06:16 AM
Summary [BLOCKING] Glassfish 2.1.1Patch8 Enterprise profile (HADB) to Glassfish 3.1 Upgrade Admin Console does not load [BLOCKING] Glassfish 2.1.1Patch8 Enterprise profile to Glassfish 3.1 Upgraded Admin Console does not load
Anissa Lam added a comment - 12/Jan/11 08:04 AM - edited

We tested that GUI launches ok for cases where secure is NOT turned on. It looks to me that secure is turned on for this test case.
I have just fixed GLASSFISH-15421 which is related to secure admin.
Can you try again with 11/12 nightly build to see if you see different result ?


Bobby Bissett added a comment - 12/Jan/11 08:23 AM

Any changes to the users' steps for an EE profile upgrade need to go into the wiki page. I'm adding a depends link for the doc issue to this one.

Am updating my workspace now and will try this again.


Bobby Bissett made changes - 12/Jan/11 08:24 AM
Link This issue blocks GLASSFISH-15157 [ GLASSFISH-15157 ]
Anissa Lam added a comment - 12/Jan/11 08:39 AM

Can you also see if it makes any difference in regards to GUI before and after applying the patch specified ?
thanks


Bobby Bissett added a comment - 12/Jan/11 09:53 AM

I'm using revision 44443 of the workspace. I did the jvm-option changes and copied the files specified in the pre-upgrade steps and then did the upgrade. After starting the server and heading to the admin url, I'm prompted for username/password without any issues. But I can't log in after this. I'm using the same admin username/password I had on the v2.1.1 installation, and I know this info is correct because I can use it with a call to 'asadmin login' and it succeeds. FWIW, I also tried admin:adminadmin and admin:'' (no password) without success.

The only message in the server log is this whenever I try to log in:

[#|2011-01-12T12:48:19.455-0500|WARNING|glassfish3.1|org.apache.catalina.connector.Request|_ThreadID=26;_ThreadName=Thread-1;|PWC4011: Unable to set request character encoding to UTF-8 from context , because request parameters have already been read, or ServletRequest.getReader() has already been called|#]

So this bug as written could be marked fixed and a new one opened; whatever you'd like to do.


Bobby Bissett added a comment - 12/Jan/11 09:54 AM

Oops, when I wrote "So this bug as written could be marked fixed..." I meant that the console does load. We just can't log into it. Perhaps the summary should be changed.


Anissa Lam added a comment - 12/Jan/11 10:56 AM

Thanks Bobby for trying this out.
If user cannot login, seems to be security or web container issue. Not much GUI can do.
Is your experience the same whether you apply the patch specified ?
thanks


Anissa Lam made changes - 12/Jan/11 10:56 AM
Summary [BLOCKING] Glassfish 2.1.1Patch8 Enterprise profile to Glassfish 3.1 Upgraded Admin Console does not load [BLOCKING] Cannot login to GUI after upgraded from v2 applying Glassfish 2.1.1Patch8 Enterprise profile
sirajg added a comment - 12/Jan/11 11:07 AM

Also, Bobby, is secure admin enabled in this case?


Bobby Bissett added a comment - 12/Jan/11 11:22 AM

Anissa: I'm not sure what patch you mean. Can you clarify?

Siraj: Um, maybe? I'll attach the domain.xml both before and after the upgrade if that helps.


Bobby Bissett added a comment - 12/Jan/11 11:23 AM

Added domain.xml before/after the upgrade.


Bobby Bissett made changes - 12/Jan/11 11:23 AM
Attachment domain.xml_before_upgrade [ 27574 ]
Attachment domain.xml_after_upgrade [ 27573 ]
Bobby Bissett made changes - 12/Jan/11 11:27 AM
Attachment domain.xml_after_upgrade [ 27573 ]
Bobby Bissett made changes - 12/Jan/11 11:27 AM
Attachment domain.xml_before_upgrade [ 27574 ]
Bobby Bissett added a comment - 12/Jan/11 11:30 AM

Ok, trying again.


Bobby Bissett made changes - 12/Jan/11 11:30 AM
Attachment domain_before_upgrade.xml [ 27576 ]
Attachment domain_after_upgrade.xml [ 27575 ]
Anissa Lam added a comment - 12/Jan/11 12:15 PM

>> Anissa: I'm not sure what patch you mean. Can you clarify?
Oh, I mean the Glassfish 2.1.1Patch8 Enterprise profile thats mentioned in the bug report.


Bobby Bissett added a comment - 12/Jan/11 12:22 PM

Hi Anissa,

I think the patch is included in the installer. The installer I used is called sges_ee-2_1_1-p08-solaris-sparc.bin.


Anissa Lam added a comment - 12/Jan/11 12:37 PM

As far as I can tell, GUI behaves properly.
It loaded up correctly, detects that anonymous login is not allowed and display the login page.
From that point on, If authentication failed, it is not a GUI issue.
I don't know if this is a security or web container issue.
Let me start with web container first.


Anissa Lam made changes - 12/Jan/11 12:37 PM
Component/s admin_gui [ 10588 ]
Component/s web_container [ 10622 ]
Assignee Anissa Lam [ anilam ] Shing Wai Chan [ swchan2 ]
Shing Wai Chan made changes - 12/Jan/11 12:55 PM
Component/s web_container [ 10622 ]
Component/s security [ 10618 ]
Assignee Shing Wai Chan [ swchan2 ] kumarjayanti [ kumarjayanti ]
kumarjayanti added a comment - 12/Jan/11 06:03 PM

Can someone attach the server.log so i can quickly see what the error is ?.


kumarjayanti added a comment - 12/Jan/11 06:09 PM

I see comments from Bobby indicating server.log had nothing useful:

[#|2011-01-12T12:48:19.455-0500|WARNING|glassfish3.1|org.apache.catalina.connector.Request|_ThreadID=26;_ThreadName=Thread-1;|PWC4011: Unable to set request character encoding to UTF-8 from context , because request parameters have already been read, or ServletRequest.getReader() has already been called|#]

If authentication had to really fail at the security layer we will see an info log about the failed authentication.

Can someone do a cat admin-keyfile and paste it on this bug.


Nazrul made changes - 12/Jan/11 07:12 PM
Due Date 2011-01-18 00:00:00.0
sss150302 added a comment - 12/Jan/11 08:46 PM

cat domain1/config/keyfile
#

  1. Copyright 2004 Sun Microsystems, Inc. All rights reserved.
  2. SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms.
    #
  1. List of users for simple file realm. Empty by default.

sss150302 made changes - 12/Jan/11 08:46 PM
Attachment server.log [ 27578 ]
kumarjayanti added a comment - 12/Jan/11 08:53 PM

hi

i asked to cat admin-keyfile not keyfile.

please cat the contents of admin-keyfile


sss150302 added a comment - 12/Jan/11 08:58 PM

cat admin-keyfile
admin;{SSHA}qetWv1Zn0cWqP59GgnLCh5iW8Jom27XDLKFEKg==;asadmin

  1. Domain User and Password - Do Not Delete Entry Above

kumarjayanti added a comment - 12/Jan/11 09:35 PM

i have put this admin-keyfile in a normal GlassFish V3.1 instance and then i have no problem loggin in as admin/adminadmin

So can you tell me what happens in the admin console after you click login. Are you seeing any response such as authentication failed or does it just hang.


sss150302 added a comment - 12/Jan/11 09:43 PM

I get a Authentication Failed message, the same message if I try again. It does not hang screenshot is attached.
You can take a look at my system : ejp-156s-46.india (aroot/abc123) : /space/31/upgrade/glassfish3/


kumarjayanti added a comment - 12/Jan/11 11:47 PM

where is the right java on that test system. I am default java is 1.5


sss150302 added a comment - 12/Jan/11 11:55 PM

source /space/31/upgrade/setenv.sh which sets java version to 1.6.0_23


kumarjayanti added a comment - 13/Jan/11 02:24 AM

Debugged the problem. We see that during the process of loading the console and till the point the login-form appears, there are several calls to __anonymous-user-enabled (SecurityUtil.getAnonymousUser()). All those calls reach the Backend Security Realm with username="admin" and password="".

However after the login form is thrown to the user and we enter username="admin", password="adminadmin" there is no call to the Security Realm Backend to validate this user.

Instead there is this comment in AdminConsoleAuthModule, which seems to say, it should use Rest Authentication:

-----------------
// Don't use the PasswordValidationCallback... use REST authorization instead.
// char[] pwd = new char[password.length()];
// password.getChars(0, password.length(), pwd, 0);
// PasswordValidationCallback pwdCallback =
// new PasswordValidationCallback(clientSubject, username, pwd);

// Make REST Request
WebResource webResource = Client.create().resource(restURL);
webResource.addFilter(new HTTPBasicAuthFilter(username, password));
ClientResponse resp = webResource.accept(RESPONSE_TYPE).post(ClientResponse.class);
RestResponse restResp = RestResponse.getRestResponse(resp);

// Check to see if successful..
if (restResp.isSuccess()) {
---------------------

And this restResp.isSuccess() returns false here. This causes the authmodule to send an Error Page back to the Browser.

Attached is the screen shot of the debug session, showing the correct username/password and showing that restResp.isSuccess() is returning false in this case.


kumarjayanti made changes - 13/Jan/11 02:24 AM
Component/s security [ 10618 ]
Component/s rest-interface [ 10635 ]
Assignee kumarjayanti [ kumarjayanti ] Jason Lee [ jdlee ]
kumarjayanti added a comment - 13/Jan/11 02:27 AM

Debug session showing problem with RestAuthorization


kumarjayanti made changes - 13/Jan/11 02:27 AM
Attachment adminconsole-auth-module.jpg [ 27584 ]
Anissa Lam added a comment - 13/Jan/11 07:59 AM

Thanks Kumar for looking into this.
We have a hard time setting up the environment because downloading the 2.1.1 patch 8 installer from IEC is so slow that it just doesn't work.
Since you have the env setup, can you try to see if you get go http://<hostname>:4848/management/domain ? The same way as you access GUI but with management/domain in the URL.
thanks


Anissa Lam made changes - 13/Jan/11 08:03 AM
Assignee Jason Lee [ jdlee ] Mitesh Meswani [ mm110999 ]
Bobby Bissett added a comment - 13/Jan/11 09:43 AM

When I try hitting <host>:4848/management/domain on my system, it lets me in after a basic auth check. But <host>:4848 still fails as above.


Anissa Lam added a comment - 13/Jan/11 10:22 AM

Based on Bobby's previous comment, doesn't seem to be a REST issue.
I'll take this and look into this.


Anissa Lam made changes - 13/Jan/11 10:22 AM
Component/s rest-interface [ 10635 ]
Component/s admin_gui [ 10588 ]
Assignee Mitesh Meswani [ mm110999 ] Anissa Lam [ anilam ]
Anissa Lam added a comment - 13/Jan/11 10:59 AM

I finally have this 2.1.1 patch 8 installed on my Solaris Sparc.
Can someone post the exact steps on how to reproduce it ?
I did see "Follow the steps as per http://java.net/jira/browse/GLASSFISH-15108" , however, that bug report has lots of discussion, and many steps, workaround to try out etc. It is too hard to follow.
Please help me to reproduce the problem quickly so i can work on it.
thanks


Anissa Lam added a comment - 13/Jan/11 11:17 AM - edited

comment removed to not cause confusion.


Bobby Bissett added a comment - 13/Jan/11 12:10 PM

Assuming you get set up, here are some simplified instructions for seeing this issue.

I'm assuming you have SUNWappserver and glassfish3 both installed under <somedir> and you're in <somedir>. Refer to these instructions below: http://wikis.sun.com/display/GlassFish/NSS+upgrade+instructions

1. Copy SUNWappserver/domains/domain1 to <somedir>. That way you can edit it without clobbering the original.

2. Copy the three files specified above from glassfish3/glassfish/domains/domain1/config to ./domain1/config.

3. Edit ./domain1/config/domain.xml according to the pre-upgrade steps above.

4. Perform the upgrade with:
./glassfish3/glassfish/bin/asupgrade -s ./domain1 -t ./glassfish3/glassfish/domains -c
...that will rename your 3.1 domain1 to domain1.original, copy ./domain1 to the 3.1 domains dir, and perform the upgrade. When prompted for master password, just accept the default since the original was overwritten in step 2 above.

5. Now start up the 3.1 server and you're all set to try logging into the admin console. For your copy/paste pleasure:
./glassfish3/glassfish/bin/asadmin start-domain domain1


Anissa Lam added a comment - 13/Jan/11 02:40 PM

Bobby gave me a tar ball for the domain and a few steps so i can reproduce that on Mac.
I followed, i can startup the upgraded domain, go to :4848/manage/domain , deploy hello.war and launch that.
However, I cannot get GUI to get up far enough to go to the login screen. It dead earlier for not able to create classloader.

Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission createClassLoader)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
at java.security.AccessController.checkPermission(AccessController.java:546)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at java.lang.SecurityManager.checkCreateClassLoader(SecurityManager.java:594)
at java.lang.ClassLoader.checkCreateClassLoader(ClassLoader.java:178)
at java.lang.ClassLoader.<init>(ClassLoader.java:207)
at org.glassfish.admingui.common.plugin.ConsoleClassLoader.<init>(ConsoleClassLoader.java:86)
... 65 more

#]

I am attaching server-cananotCreateClassLoader.log
I am blocked by this.


Anissa Lam made changes - 13/Jan/11 02:41 PM
Attachment server-cannotCreatClassLoader.log [ 27595 ]
Anissa Lam added a comment - 13/Jan/11 05:44 PM

I am able to fix my solaris sparc, install 2.1.1 patch8 and start the v2 server.
I followed the instructions to upgrade and FINALLY see the login screen which of course always gives authentically failed as reported here.
All this happened on the Solaris.

If i test my luck, copy this upgraded domain/config directory to my Mac, and start it. I got the same experience as using the 'upgraded domain' that Bobby zip up for me. ie, I can go to REST , deploy hello.war, launch it, but I can't startup GUI.

Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission createClassLoader)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
at java.security.AccessController.checkPermission(AccessController.java:546)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at java.lang.SecurityManager.checkCreateClassLoader(SecurityManager.java:594)
at java.lang.ClassLoader.checkCreateClassLoader(ClassLoader.java:178)
at java.lang.ClassLoader.<init>(ClassLoader.java:207)
at org.glassfish.admingui.common.plugin.ConsoleClassLoader.<init>(ConsoleClassLoader.java:86)
... 65 more

#]

My debugging will made easier if someone can tell me what may cause this so i can debug on my Mac.

But for the time being, I can dig into this using my 10 years old 1G memory Solaris box


kumarjayanti added a comment - 13/Jan/11 08:33 PM

You will need to put the code in ConsoleClassLoader in a doPrivileged block when System.getSecurityManager() returns non-null.


Anissa Lam added a comment - 13/Jan/11 08:55 PM

Kumar, can you tell me why I only see this class loader issue on Mac ? With Solaris, it doesn't get into this issue, but gets going further, like what you experienced, that it is able to bring up the login screen.


kumarjayanti added a comment - 13/Jan/11 09:42 PM

not sure. It maybe due to the JDK version then. I am assuming you have the latest workspace on the MAC right ?.


Anissa Lam added a comment - 13/Jan/11 10:29 PM

Yes, I have the latest workspace.
On Solaris, i am using
java version "1.6.0_24"
Java(TM) SE Runtime Environment (build 1.6.0_24-b03)

On Mac, I am using
java version "1.6.0_22"
Java(TM) SE Runtime Environment (build 1.6.0_22-b04-307-9M3263)


kumarjayanti added a comment - 13/Jan/11 10:43 PM

not sure what is going on. Can you not access the SQE system where everything is setup for you and ready to debug. It is a machine in india though.


Anissa Lam added a comment - 14/Jan/11 06:24 PM

Kumar, thanks.
I am able to setup my env after spending almost the entire day on this trying different setup.

What i find out is that, the following lines doesn't go to the RestAdapter

webResource.addFilter(new HTTPBasicAuthFilter(username, password));
ClientResponse resp = webResource.accept(RESPONSE_TYPE).post(ClientResponse.class);
RestResponse restResp = RestResponse.getRestResponse(resp);

Supposedly, it should reach RestAdapter to do the authentication, but that never happens.
We just get back a response with status 302.

I am not sure who should look into this ? Grizzly team ? or whoever familiar with Jersey Client to take over ?


kumarjayanti added a comment - 14/Jan/11 07:29 PM

right, it appears to me the HTTPBasicAuthFilter never got called. Where is the code for HTTPBasicAuthFilter ?. is it in Jersey ?.

It may be worthwhile to consult jersey folks at this point.


Tim Quinn added a comment - 14/Jan/11 09:26 PM

Status code 302 is for redirection, which would be expected if secure admin is enabled and if the REST connection is using http (as opposed to https). In that case the Grizzly config on the DAS will redirect http to https.

The Java SE classes to not allow automatic redirection-following from http to https; the client needs to handle it explicitly. I do not know what happens within Jersey.

Mitesh might know more; he might have dealt with similar issues with the REST monitoring work.


Anissa Lam added a comment - 15/Jan/11 08:07 AM - edited

This issue only occurs when upgrading from 2.1 Enterprise Profile (which is using NSS) to 3.1.
We have no issue setting secure admin in 3.1, or upgrade from 2.1 Developer/Cluster Profile. Maybe some component isn't handling the upgrade correctly ?


kumarjayanti added a comment - 16/Jan/11 02:10 AM

If you want to know what is different between upgrading from 2.1 to 3.1 Vs setting secure admin in 3.1, then the first thing that is different is that the admin-realm in V2.1EE does not have the user admin with empty password. Instead the password is adminadmin

And when debugging i saw that the AdminConsoleAuthModule is being repeatedly invoked to handle isAnonymousUserEnabled or something like that. I believe the stateless nature of the new Admin-GUI/RestInterface is causing this command to be executed again and again before the login-page appears. As an aside i feel this complete stateless nature can cause performance problems since we are going to the backend again and again for something that can be cached after a first query.


Anissa Lam added a comment - 16/Jan/11 08:23 AM

>> the first thing that is different is that the admin-realm in V2.1EE does not have the user admin with empty password. Instead the password is adminadmin

Understand. However, 2.1 Cluster Profile also has 'adminadmin' as the password but has NO issue after the upgrade. Only the Enterprise Profile which was using NSS before has the problem.

Even though we keep making request repeatedly to REST, we have an authentication token which REST gave to us upon first authentication. This is unavoidable, and i don't see performance hit upon each page refresh due to this.


Nazrul made changes - 18/Jan/11 04:45 PM
Priority Major [ 3 ] Critical [ 2 ]
Anissa Lam added a comment - 18/Jan/11 05:13 PM

In domain.xml, we have a property restAuthURL under <message-security-config> that specifies the endpoint.
<property name="restAuthURL" value="http://localhost:${ADMIN_LISTENER_PORT}/management/sessions"></property>

In 3.1, 'enable-secure-admin' change will change the scheme from 'http' to 'https'.
However, during the upgrade process, this sheme change didn't happen, although the upgraded domain has secure-admin enabled.
So, GUI was still using 'http' instead of 'https'. I believe this can be considered a bug in the upgrade code for not changing this.

However, AdminConsoleAuthModule should be more robust, and test that if secure-admin is on, uses 'https' instead.

I am going to fix AdminConsoleAuthModule to test if secure-admin is on, and ensure that we are using https.


Anissa Lam added a comment - 18/Jan/11 05:35 PM

1. How bad is its impact? (Severity)
Very Severe, Console doesn't allow anyone to login.

2. How often does it happen? (Frequency)
Everytime when v2.1 Enterprise Profile is upgraded to 3.1

3. How much effort is required to fix it? (Cost)
The fix is easy, but figuring out the issue takes couple days.

4. What is the risk of fixing it? (Risk)
Risk is min.

5. Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
A work around is to edit domain.xml and change the restAuthURL to start with "https" after the upgrade.

6. If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
Yes.

Here is the svn diff

Index: src/main/java/org/glassfish/admingui/common/security/AdminConsoleAuthModule.java
===================================================================
— src/main/java/org/glassfish/admingui/common/security/AdminConsoleAuthModule.java (revision 44518)
+++ src/main/java/org/glassfish/admingui/common/security/AdminConsoleAuthModule.java (working copy)
@@ -67,6 +67,7 @@
import org.glassfish.admingui.common.util.RestResponse;
import org.jvnet.hk2.component.Habitat;
import com.sun.enterprise.config.serverbeans.Domain;
+import com.sun.enterprise.config.serverbeans.SecureAdmin;
import com.sun.enterprise.security.SecurityServicesUtil;
import org.glassfish.admingui.common.util.RestUtil;

@@ -107,7 +108,7 @@

  • information needed to continue is present.</p>
    */
    public void initialize(MessagePolicy requestPolicy, MessagePolicy responsePolicy, CallbackHandler handler, Map options) throws AuthException {
  • this.handler = handler;
    + this.handler = handler;
    if (options != null) { // Save the REST URL we need to authenticate the user. this.restURL = (String) options.get("restAuthURL"); @@ -128,13 +129,21 @@ + "must be supplied as a property in the provider-config " + "in the domain.xml file!"); }
    + Habitat habitat = SecurityServicesUtil.getInstance().getHabitat();
    if (restURL.contains(TOKEN_ADMIN_LISTENER_PORT)) { - Habitat habitat = SecurityServicesUtil.getInstance().getHabitat(); Domain domain = habitat.getComponent(Domain.class); String port = domain.getServerNamed("server").getConfig().getNetworkConfig().getNetworkListener("admin-listener").getPort(); restURL = restURL.replace(TOKEN_ADMIN_LISTENER_PORT, port); }
  • }
    +
    + //If secure admin is enabled, we need to ensure using https
    + if (! restURL.startsWith("https"))
    Unknown macro: {+ SecureAdmin secureAdmin = habitat.getComponent(SecureAdmin.class);+ if (SecureAdmin.Util.isEnabled(secureAdmin)) { + restURL = restURL.replace("http", "https"); + }+ }

    + }
    }

/**


Anissa Lam made changes - 18/Jan/11 05:42 PM
Tags 3_1-upgrade EE Enterprise HADB Qa asupgrade profile testing upgrade 3_1-blocking Blocker adminconsole admin BLOCKING 3_1-blocking 3_1-review 3_1-upgrade BLOCKING Blocker EE Enterprise HADB Qa admin adminconsole asupgrade profile testing upgrade
Nazrul made changes - 18/Jan/11 08:43 PM
Tags 3_1-blocking 3_1-review 3_1-upgrade BLOCKING Blocker EE Enterprise HADB Qa admin adminconsole asupgrade profile testing upgrade 3_1-blocking 3_1-review 3_1-upgrade BLOCKING Blocker EE Enterprise HADB Qa admin adminconsole asupgrade profile testing
Nazrul made changes - 18/Jan/11 08:43 PM
Tags 3_1-blocking 3_1-review 3_1-upgrade BLOCKING Blocker EE Enterprise HADB Qa admin adminconsole asupgrade profile testing 3_1-blocking 3_1-review 3_1-upgrade BLOCKING Blocker EE Enterprise HADB Qa admin adminconsole asupgrade profile
Nazrul made changes - 18/Jan/11 08:43 PM
Tags 3_1-blocking 3_1-review 3_1-upgrade BLOCKING Blocker EE Enterprise HADB Qa admin adminconsole asupgrade profile 3_1-blocking 3_1-review 3_1-upgrade BLOCKING Blocker EE Enterprise HADB Qa admin adminconsole asupgrade
Nazrul made changes - 18/Jan/11 08:43 PM
Tags 3_1-blocking 3_1-review 3_1-upgrade BLOCKING Blocker EE Enterprise HADB Qa admin adminconsole asupgrade 3_1-blocking 3_1-review 3_1-upgrade BLOCKING Blocker EE Enterprise HADB Qa admin adminconsole
Nazrul made changes - 18/Jan/11 08:43 PM
Tags 3_1-blocking 3_1-review 3_1-upgrade BLOCKING Blocker EE Enterprise HADB Qa admin adminconsole 3_1-blocking 3_1-review 3_1-upgrade BLOCKING Blocker EE Enterprise HADB Qa admin
Nazrul made changes - 18/Jan/11 08:43 PM
Tags 3_1-blocking 3_1-review 3_1-upgrade BLOCKING Blocker EE Enterprise HADB Qa admin 3_1-blocking 3_1-review 3_1-upgrade BLOCKING Blocker EE Enterprise HADB Qa
Nazrul made changes - 18/Jan/11 08:43 PM
Tags 3_1-blocking 3_1-review 3_1-upgrade BLOCKING Blocker EE Enterprise HADB Qa 3_1-blocking 3_1-review 3_1-upgrade BLOCKING Blocker EE Enterprise HADB
Nazrul made changes - 18/Jan/11 08:44 PM
Tags 3_1-blocking 3_1-review 3_1-upgrade BLOCKING Blocker EE Enterprise HADB 3_1-blocking 3_1-review 3_1-upgrade Blocker EE Enterprise HADB
Nazrul made changes - 18/Jan/11 08:44 PM
Tags 3_1-blocking 3_1-review 3_1-upgrade Blocker EE Enterprise HADB 3_1-blocking 3_1-review 3_1-upgrade EE Enterprise HADB
Nazrul made changes - 18/Jan/11 08:44 PM
Tags 3_1-blocking 3_1-review 3_1-upgrade EE Enterprise HADB 3_1-blocking 3_1-upgrade EE Enterprise HADB
Nazrul made changes - 18/Jan/11 08:44 PM
Tags 3_1-blocking 3_1-upgrade EE Enterprise HADB 3_1-approved 3_1-blocking 3_1-upgrade EE Enterprise HADB
Anissa Lam added a comment - 18/Jan/11 09:39 PM

Issue resolved.
Ludo reviewed the code and suggested more explicit test instead of testing not starting with "https". I have modified that if test.

Project: glassfish
Repository: svn
Revision: 44585
Author: anilam
Date: 2011-01-19 05:36:30 UTC
Link:

Log Message:
------------
GLASSFISH-15544. Fix the issue where Upgrading from v2 Enterprise Profile to 3.1 results in not being able to login to GUI.
Upgrade process didn't change the restAuthURL property from "http" to "https". AdminConsoleAuthModule now tests if secure-admin is enabled and change the scheme if secure-admin is on.
Approved: Anissa
Reviewer: Ludo

Revisions:
----------
44585

Modified Paths:
---------------
trunk/v3/admingui/common/src/main/java/org/glassfish/admingui/common/security/AdminConsoleAuthModule.java

Diffs:
------
Index: trunk/v3/admingui/common/src/main/java/org/glassfish/admingui/common/security/AdminConsoleAuthModule.java
===================================================================
— trunk/v3/admingui/common/src/main/java/org/glassfish/admingui/common/security/AdminConsoleAuthModule.java (revision 44584)
+++ trunk/v3/admingui/common/src/main/java/org/glassfish/admingui/common/security/AdminConsoleAuthModule.java (revision 44585)
@@ -67,6 +67,7 @@
import org.glassfish.admingui.common.util.RestResponse;
import org.jvnet.hk2.component.Habitat;
import com.sun.enterprise.config.serverbeans.Domain;
+import com.sun.enterprise.config.serverbeans.SecureAdmin;
import com.sun.enterprise.security.SecurityServicesUtil;
import org.glassfish.admingui.common.util.RestUtil;

@@ -107,7 +108,7 @@

  • information needed to continue is present.</p>
    */
    public void initialize(MessagePolicy requestPolicy, MessagePolicy responsePolicy, CallbackHandler handler, Map options) throws AuthException {
  • this.handler = handler;
    + this.handler = handler;
    if (options != null) { // Save the REST URL we need to authenticate the user. this.restURL = (String) options.get("restAuthURL"); @@ -128,13 +129,19 @@ + "must be supplied as a property in the provider-config " + "in the domain.xml file!"); }
    + Habitat habitat = SecurityServicesUtil.getInstance().getHabitat();
    if (restURL.contains(TOKEN_ADMIN_LISTENER_PORT)) { - Habitat habitat = SecurityServicesUtil.getInstance().getHabitat(); Domain domain = habitat.getComponent(Domain.class); String port = domain.getServerNamed("server").getConfig().getNetworkConfig().getNetworkListener("admin-listener").getPort(); restURL = restURL.replace(TOKEN_ADMIN_LISTENER_PORT, port); }
  • }
    +
    + //If secure admin is enabled, we need to ensure using https
    + SecureAdmin secureAdmin = habitat.getComponent(SecureAdmin.class);
    + if (restURL.startsWith("http:") && (SecureAdmin.Util.isEnabled(secureAdmin))) { + restURL = restURL.replace("http:", "https:"); + }
    + }
    }

/**


Anissa Lam made changes - 18/Jan/11 09:39 PM
Status Open [ 1 ] Resolved [ 5 ]
Fix Version/s 3.1_b38 [ 12251 ]
Resolution Fixed [ 1 ]
Bobby Bissett added a comment - 19/Jan/11 07:01 AM

There's just one little detail left, buried in this early comment:
http://java.net/jira/browse/GLASSFISH-15544?focusedCommentId=189847&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_189847

Can you let me know if the post-upgrade instruction here needs to be removed/changed/left alone?
http://wikis.sun.com/display/GlassFish/NSS+upgrade+instructions#NSSupgradeinstructions-ManualStepstobeCarriedoutafterupgrade

Search for '15544' in the wiki page if the above link doesn't take you right to it.


Bobby Bissett made changes - 19/Jan/11 07:01 AM
Resolution Fixed [ 1 ]
Status Resolved [ 5 ] Reopened [ 4 ]
Anissa Lam added a comment - 19/Jan/11 08:08 AM

There are many steps documented in the wiki page in the section 'Manual Steps to be carried out after upgrade'.
I am not sure what is the purpose or consequences after performing all these steps. Not sure if those are intended for other components either.

But as far as GUI is concerned, with today's build that has the fix above, no steps is needed after upgrade in order to launch and access GUI.


Anissa Lam made changes - 19/Jan/11 08:08 AM
Status Reopened [ 4 ] Resolved [ 5 ]
Resolution Fixed [ 1 ]
Bobby Bissett added a comment - 19/Jan/11 08:11 AM

No, just that one step referenced in my comment (and the step has a reference to this bug as well). Here's the text:

— begin —
1. Start the server and run the following command (note: this may not be needed. Currently issue 15544 is tracking the problem of logging into the admin console):

./asadmin --secure=true create-ssl --type http-listener --certname s1as admin-listener

Make sure that the domain.xml contains the ssl element for the admin-listener under the protocols element.

Make sure client-auth-enabled is false for this element.
— end —

Is this still needed? Doc issue GLASSFISH-15157 depends on that.


Bobby Bissett added a comment - 19/Jan/11 08:12 AM

Reading you last comment better, I think it answers my last comment. I'll remove that part from the wiki page and can add it back if we need it.


kumarjayanti added a comment - 19/Jan/11 07:55 PM

Please remove this step from the wiki because the AdminUpgradeService takes care of automatically creating an SSL Listener once it detects that we are upgrading from a V2.X EE.


sss150302 made changes - 20/Jan/11 04:17 AM
Attachment console-screen-b38.jpg [ 27658 ]
sss150302 made changes - 20/Jan/11 04:18 AM
Attachment upgrade-31-b38.log [ 27659 ]
sss150302 made changes - 20/Jan/11 04:18 AM
Attachment server.b38.log [ 27660 ]
sss150302 added a comment - 20/Jan/11 04:25 AM

I have tried the new build B38, and I still can't login to the admin console.
Have attached
1) the output of ./asadmin start-domain --upgrade domain1 as "upgrade-31-b38.log"
2) domain1 server.log as server.b38.log
3) screenshot console-screen-b38.jpg
You can take a look at my setup ejp-156s-46.india ( /space/31/upgrade/glassfish3 )
source /space/31/upgrade/setenv.sh to use jdk1.6.0_23

Bobby, Have you tried the upgrade with B38?


Bobby Bissett added a comment - 20/Jan/11 06:55 AM

No, and I don't know when b38 was built.


Anissa Lam added a comment - 20/Jan/11 09:39 AM

The fix didn't make it to build 38.

According to this page: http://wikis.sun.com/display/GlassFish/3.1BuildSchedule
Build 38 is based on rev# 44543
and as specified in my comment, the rev with my fix is #44585

Project: glassfish
Repository: svn
Revision: 44585
Author: anilam
Date: 2011-01-19 05:36:30 UTC
Link:

So, Sanjay, can you try to verify the fix using latest nightly build ? or build after 1/19 ?
thanks


Anissa Lam made changes - 20/Jan/11 09:39 AM
Fix Version/s 3.1_b39 [ 12371 ]
Fix Version/s 3.1_b38 [ 12251 ]
sss150302 added a comment - 21/Jan/11 07:37 AM - edited

Wow, Finally, the fix is working fine. Kudos to the teamwork!
I have verified it with Latest Nightly Build B39, Dated 20 jan 2011.

However I would not like to see the annoying Bundle exception in felix on the console as ( details log attached)as upgrade-31-b39-nightly-20-jan-2011.log

Error while starting bundle: file:/space/31/upgrade/glassfish3/glassfish/modules/autostart/org.apache.felix.eventadmin.jar: org.osgi.framework.BundleException: Cannot start bundle org.apache.felix.eventadmin [245] because its start level is 1, which is greater than the framework's start level of 0.
org.osgi.framework.BundleException: Cannot start bundle org.apache.felix.eventadmin [245] because its start level is 1, which is greater than the framework's start level of 0.
at org.apache.felix.framework.Felix.startBundle(Felix.java:1690)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:922)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:1157)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:1135)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.processAllBundles(DirectoryWatcher.java:1128)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:438)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:245)
Error while starting bundle: file:/space/31/upgrade/glassfish3/glassfish/modules/autostart/osgi-javaee-base.jar: org.osgi.framework.BundleException: Cannot start bundle org.glassfish.osgi-javaee-base [246] because its start level is 1, which is greater than the framework's start level of 0.
org.osgi.framework.BundleException: Cannot start bundle org.glassfish.osgi-javaee-base [246] because its start level is 1, which is greater than the framework's start level of 0.
at org.apache.felix.framework.Felix.startBundle(Felix.java:1690)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:922)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:1157)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:1135)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.processAllBundles(DirectoryWatcher.java:1128)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:438)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:245)
Error while starting bundle: file:/space/31/upgrade/glassfish3/glassfish/modules/autostart/osgi-cdi.jar: org.osgi.framework.BundleException: Cannot start bundle org.glassfish.osgi-cdi [247] because its start level is 1, which is greater than the framework's start level of 0.
org.osgi.framework.BundleException: Cannot start bundle org.glassfish.osgi-cdi [247] because its start level is 1, which is greater than the framework's start level of 0.
at org.apache.felix.framework.Felix.startBundle(Felix.java:1690)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:922)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:1157)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:1135)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.processAllBundles(DirectoryWatcher.java:1128)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:438)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:245)


sss150302 made changes - 21/Jan/11 02:27 PM
Anissa Lam added a comment - 21/Jan/11 03:59 PM

Thanks for verifying. Please file a separate bug regarding the Bundle Exception. thanks.


Bobby Bissett added a comment - 21/Jan/11 05:39 PM

This is already a known issue. See GLASSFISH-15441 and GLASSFISH-15519.


sss150302 made changes - 17/Feb/11 12:04 AM
Tags 3_1-approved 3_1-blocking 3_1-upgrade EE Enterprise HADB 3_1-approved 3_1-blocking 3_1-upgrade 3_1-verified EE Enterprise HADB