admin@glassfish.java.net

Re: The content of the troubleshooting section

From: Elena Asarina <elena.asarina_at_oracle.com>
Date: Thu, 12 Aug 2010 12:13:28 -0700

Hello Bill,

Any node when it would be created will be marked in domain.xml either
SSH or CONFIG

And I think that we need to explain clearly that if a node was marked
CONFIG, then it doesn't have ssh info, correspondingly an instance for
that node can be created only locally. And then only local commands can
be executed against instances that belong to this node.
But if not local command would be executed, as I understood, please
correct me, if I'm wrong, for example stop-instance or start-instance,
has to be seen an error message. If so, this example with an error
message has to be provided.

Unfortunately I don't see a consistent behavior in this area.
For example, I've just created on Windows a node using
create-node-config, then create-local-instance, then
start-local-instance. But then can execute stop-instance/start-instance
against such instance without any issues.

It is it an expected behavior or not?

Thank you,

Elena

Bill Shannon wrote:
> Elena Asarina wrote on 08/11/2010 05:24 PM:
>> Hello,
>>
>> I would like to start a discussion about the content of the
>> troubleshooting section of our docs.
>>
>> Answering on the question of my colleges regarding cluster/instances
>> configuration, I can see the same pattern of the questions/issues.
>> Probably our customers will have the same questions. I will try to
>> summarize the questions:
>> 1) How to setup SSH without password. I can say that on Linux,
>> Solaris and Mac it is an easy procedure, but on windows not. I was
>> able to setup ssh without password only on two machines, only under
>> Administrator id and with a work around. I believe we need to
>> provide a reliable windows procedure.
>
> I agree.
>
>> 2) Just to be able to run remote commands like asadmin
>> create-node-ssh, asadmin start-instance, asadmin stop-instance, ssh
>> without password has to be preconfigured.
>
> Yes.
>
>> 3) There are "local" and "remote" commands. If an object, for example
>> a node, was created using "local" command, the remote commands can
>> not be executed against this object, unless it was upgraded to the
>> "remote" object. (How?). I think it has to explained clearly with
>> wrong and correct examples and error messages.
>
> It's not "local" vs. "remote", it's whether you've configured the ssh
> information for the node or not. The create-local-instance command does
> not, and largely exists for those cases where you're not going to use
> ssh.
> If you're going to use ssh, you'll need to configure it with
> create-node-ssh
> and then you can use create-instance.
>
>> 4) Any remote command needs in java on the remote machine. It will
>> take whatever there, on our Solaris, Linux machines it just
>> /usr/bin/java. Usually /usr/bin/java is linked with jdk 4 or 5. So
>> there will be error messages (for jdk4 a bad error message). Users
>> have to be advised to execute from machine A: ssh <machine B> java
>> -version. And if it is not JDK 6, change it, for example, recreate
>> /usr/bin/java link pointing to the suitable java.
>
> The GlassFish installation on the remote node should be
> installed/configured
> in a way that it finds the correct JDK. If "java" doesn't give you the
> right version, this should be configured by setting AS_JAVA in
> config/asenv.conf. I would expect the installer to do this. If you
> install by unzipping (for example) then you'll need to do this yourself.
>
> And yes, the installation documentation should describe this.
>
>> 5) If ssh without password was created, before any asadmin command
>> that use ssh would be executed, ssh manually with the machine name
>> that would be used, to put info about the machine in known_hosts.
>> For example, if from machine A ssh <machine B without domain>, but
>> then will try execute asadmin command using a full machine name with
>> domain, it would not work.
>
> Yes, setting up ssh properly is a pain and needs to be clearly
> documented,
> although to a large extent the reason we're using ssh is because we think
> people have already figured all this out already and are likely using ssh
> for their normal administration tasks anyway.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>