The installer should disable the admin console in the RHQ Server. This: http://localhost:6990/console/index.html should not be accessible after you fully install the RHQ Server. This means we need to execute this remove client command by the installer: /core-service=management/management-interface=http-interface/:write-attribute(name=console-enabled,value=false)
git commit to master: 2e3f2b2
To be clear what is happening: 1) download RHQ Server and unzip it 2) run the RHQ Server using rhq-server.sh At this point, what is running is a stock app server with nothing RHQ-related deployed in it. It is just a blank app server WITH the admin console running (so the admin console is here because it is deployed by default in all stock app servers). However, you can't log into the admin console - there are no users defined in stock AS7/EAP app servers. So what the browser will show if you try to access the admin console at this point in time is: "...you have not yet added any users to be able to access the admin console. ... After you have added the user, click the following link to access the Management Console." 3) run the RHQ Server installer script rhq-installer.sh At this point, RHQ Server is running fully BUT the admin console is now gone. It is completely disabled and you can't even see it at its http endpoint (the browser will display an error). So to be clear, there is a small window where the admin console is running (between the time of running the unzipped server and running the installer script) but you can't even log into it. After the install is completely, you can't even see the admin console anymore - it is fully disabled.
Adding a NEEDINFO for Larry to look at comment #2 - Charles wanted me to make sure Larry is OK with having a brief period of time (between starting the unzipped server and running rhq-installer.sh) where the console is alive still (even though it shows an error message and you can't log in).
Can we not do this on the container at build time? I agree that the window is very small and the fact that it is there for a moment is probably harmless but if we are going to disable the console anyway, why not disable it in the container as part of our build so that it is already disabled?
(In reply to Larry O'Leary from comment #4) > Can we not do this on the container at build time? > > I agree that the window is very small and the fact that it is there for a > moment is probably harmless but if we are going to disable the console > anyway, why not disable it in the container as part of our build so that it > is already disabled? I'm not even sure where the console IS (probably inside one of the modules??) but if we strip that out, does anything else break? I dunno. It isn't made like the old JBossAS 4.x jboss console where its a simple war that you just don't deploy. The admin console apparently is built into the core somewhere and the "right" way to disable it is how we are doing it (through the management API). To me, worrying about this is bordering on hyper-paranoia and if it were up to me, I would say we are good. The admin console is essentially useless out of box (this is true with any AS/EAP distro that is unzipped) because there are no user credentials that come with it out of box. So we are doing nothing out of the ordinary that AS/EAP isn' doing itself. And the fact we immediately disable it upon installation completion means we are doing it the "right" way - that is, using the API that AS/EAP provides to disable the console (as opposed to ripping out some guts to do it).
> why not disable it in the container as part of our build so that it > is already disabled? Note also ripping it out of our own build wouldn't solve the problem of disabling it if installing RHQ in an external AS (in other words, RHQ would still need to make the API call to disable the console in the case someone provided their own app server).
(In reply to John Mazzitelli from comment #5) > I'm not even sure where the console IS (probably inside one of the > modules??) but if we strip that out, does anything else break? I dunno. It > isn't made like the old JBossAS 4.x jboss console where its a simple war > that you just don't deploy. The admin console apparently is built into the > core somewhere and the "right" way to disable it is how we are doing it > (through the management API). It is done via configuration in the standalone.xml or domain.xml configuration files from what I recall. > To me, worrying about this is bordering on hyper-paranoia and if it were up > to me, I would say we are good. The admin console is essentially useless > out of box (this is true with any AS/EAP distro that is unzipped)... The fact that, "The admin console is essentially useless," is the key. I am looking at this from a user perspective. Why have it if it is in deed useless? (In reply to John Mazzitelli from comment #6) > Note also ripping it out of our own build wouldn't solve the problem of > disabling it if installing RHQ in an external AS (in other words, RHQ would > still need to make the API call to disable the console in the case someone > provided their own app server). Which is why we should disable it as well if we feel that we need to. However, in the context of "my own AS" should we be dictating how one should use AS?
> The fact that, "The admin console is essentially useless," is the key. I am > looking at this from a user perspective. Why have it if it is in deed > useless? Well, realize of course that it will be gone within 5 minutes of unzipping/running the RHQ distro. We won't have it after that - the only time we'll have it (in a useless state) is in that all-but-brief moment in time between unzipping/running rhq-server.sh and running the installer. The reason why we do it this way is because we can very easily upgrade the underlying server in our build scripts. Today, the build does NOT tweek the out of box config at all - we just ship EAP/AS's files (and specifically the config in standalone-full.xml) as it comes from the manufacturer (except we remove things like docs, domain configs we don't use and other trivial things like that). We do this because now it makes upgrading to new versions of AS7/EAP/Wildfly easy - we were able to pretty easily (with very little build code changes) upgrade from AS7.1.1.Final to EAP 6 because of this design. And I think for JON builds, we should be able to easily swap out EAP alpha with EAP GA and not have to duplicate any custom config settings RHQ builds did - because we specifically avoided doing ANY custom config changes in the RHQ builds). If we go and start messing with out of box config files, we then have to be careful to make sure we track changes to config files in later versions (and make sure JON builds track the RHQ changes). It is nice not having to worry about this. So, to get a console to go away completely (even though its already useless) for just those additional 5 or so minutes prior to running rhq-installer.sh, we'd have to introduce something in the build structure that we purposefully have avoided up to now. I just don't see that this is such a big deal to force us to change that now.
First, we should not be using the out-of-the-box standalone-full.xml as is. This is only intended as an example/starting point. Instead, you should be creating an configuration file that describes the AS container that is required. Second, to provide a better user experience without introducing additional confusion or complications from the user's point-of-view, it is sometimes necessary to handle these issues in the build itself. That being said, I do understand the convenience of limiting what is customized in the bits that are pulled into the build. The less we tweak the better. In this case however, we are disabling this component anyway so in the event that this changes in AS itself, disabling this in the installer will also be broken. Therefore, it is still my recommendation that we disable the management console via configuration during build/packaging. And in the cases of putting RHQ into an existing AS container, we should not be disabling/modifying the configuration in the user's configuration file but instead in our own copy of the configuration.
Bulk closing of old issues now that HRQ 4.9 is in front of the door. If you think the issue has not been solved, then please open a new bug and mention this one in the description.