| This page provides links to review drafts of new and changed documentation for the SSH Provisioning project as listed in the SSH Provisioning Documentation Plan.
Mandatory reviewers for each item are listed in each section. Changes to existing documentation since the last release are marked with change bars. No changes are marked in new documentation. Please provide your feedback by adding a comment to this page. To simplify the processing of your comments, please add your comments in the format in the sample comment. Review existing comments to see known issues and avoid duplicates.
Changes to Books High Availability Administration Guide Changes
Upgrade Guide Changes
Domain File Format Reference Changes
| Section |
Documentation Impact |
Reviewers |
Status
|
Element hierarchy
|
Minor
|
Joe Di Pol
Carla Mott
Rajiv Mordani |
Canceled.
|
| node |
New |
Joe Di Pol
Carla Mott
Rajiv Mordani |
Canceled. |
| nodes |
New |
Joe Di Pol
Carla Mott
Rajiv Mordani |
Canceled. |
| ssh-connector |
New |
Joe Di Pol
Carla Mott
Rajiv Mordani |
Canceled. |
| ssh-auth |
New |
Joe Di Pol
Carla Mott
Rajiv Mordani |
Canceled. |
Changes to Man Pages Mandatory reviewers in addition to the reviewers that are listed in the table are as follows:
- Elena Asarina
- Tom Mueller
| Comment ID |
Location |
Comment |
| PMD-001 |
update-node-ssh(1) man page. |
Sample comment. Should provide a proposed fix and correct content if applicable. |
| PMD-002 |
HA Admin Guide, Chapter 8, To Create a Node |
Another sample comment. |
 Posted by pauldavies at Oct 25, 2010 10:56
|
| Comment ID |
Location |
Comment |
| trm-1 |
create-node-ssh, description |
Regarding the sentence starting with "However, the DAS does not use the
SSH connector...", if an SSH node with a node host of the DAS is created, then the DAS will use SSH to talk to that node, even though it is local. So I don't really understand what this sentence is trying to get across. |
| trm-2 |
create-node-ssh, --installdir option |
The 2nd sentence about the default should be qualified with "DAS's" software, i.e., the default comes from where the DAS is installed. |
| trm-3 |
create-node-ssh ,
install-node |
For the --installdir and --nodedir options, there should be some mention of differing conventions for specifying paths. For example, if asadmin is run from Windows, and the DAS is on Windows, but the node is on Linux, what path separator is passed to the command. Also, if the asadmin is on Linux and DAS is on Linux, but the node is on Windows (with SSHD coming from cygwin), what path separate is used? |
| trm-4 |
create-node-ssh, --force option |
It would be helpful to add "in the DAS configuration" after "node is created".
|
| trm-5 |
create-node-ssh, example 2 |
Replace "on" with "for" in "eg1 on the host". In this case, nothing is done on eghost.example.com because it could not be contacted. |
| trm-6 |
create-node-ssh, create-node-config |
The operand section should specify what the valid characters are for a node name. |
| trm-7 |
delete-node-ssh |
The note about the node localhost should be on the delete-node-config page rather than this one, because the localhost node is a config node. |
| trm-8 |
general |
Thinking ahead to the time when we implement other forms of remote communication for nodes, such as bringing back the node-agent feature, we will then have for example, NA nodes. At that point, the config nodes are no longer nodes that are not configured for SSH, but rather nodes that are not configured for remote communication. I'm wondering if this generalization should be made now rather than waiting until later to rewrite all of the config node manual pages. |
| trm-9 |
install-node, uninstall-node |
Description, 1st pp: Although the install-node command is intended to be run from the DAS, it isn't clear to me that this is required. Someone could install the GlassFish software elsewhere, and then run install-node from there (since it is a local command). So it isn't clear that the DAS has to be configured for SSH for this to work. |
| trm-10 |
install-node |
Description, 2nd bullet of 2nd set of bullets - shouldn't this be the --passwordfile option? |
| trm-11 |
install-node |
--archivedir: "creates and archive from the DAS installation" - actually, it creates an archive from the installation of the software from which install-node is run. This isn't necessarily the DAS. There also a mention later down about the software coming from the DAS. |
| trm-11 |
install-node, uninstall-node |
--archivedir: "the user that is running the DAS" - actually, it is the user that is running the install-node subcommand. The DAS might not even be running and is irrelevant since this is a local command. |
| trm-12 |
install-node, uninstall-node |
--sshuser: the default is the user running the install-node command, not the user running the DAS. |
| trm-13 |
install-node, uninstall-node |
--sshkeyfile: the file has to be reachable and readable by the install-node command, not the DAS. |
| trm-14 |
list-nodes, update-node-config, update-node-ssh |
terminology: I would prefer that a "host contains a node" rather than a "node represents a host". So the third bullet in the description would be "The name of the host that contains the node". Could use "hosts" for "contains", but saying "the host that hosts the" is a bit odd :-) |
| trm-15 |
ping-node-ssh |
What does validation actually mean? It does some additional validation at the SSH level, but then it also checks on the version of the GlassFish software on the node and returns it. This ensures that the asadmin command can be executed on the node. |
| trm-16 |
setup-ssh |
Description, 2nd pp, 2nd sentence - this makes it sound like SSH is used for all cluster administration. Add "some" in there somewhere. |
| trm-17 |
setup-ssh |
Description, prerequisites: sshd does not have to be running on the DAS for this to work.
|
| trm-18 |
setup-ssh |
Don't we support MKS for Windows too? |
| trm-19 |
setup-ssh |
--sshuser and -sshkeyfile and -sshpublickeyfile: the default is the user running the setup-ssh command, not the DAS |
| trm-20 |
setup-ssh |
example 1: copyied from the host where the setup-ssh command is run. |
| trm-21 |
setup-ssh |
Do you want to mention that if the SSH password is the same for all of the hosts, then it only needs to be entered once? |
| trm-22 |
update-node-config |
Description, 4th pp: this is incorrect. This command can be run anywhere since it is a remote command. The configuration changes are made on the DAS. |
| trm-23 |
update-node-ssh |
Description, 2nd pp: it might be helpful to say that this command can change a config node into an SSH node. |
| trm-24 |
update-node-ssh |
--sshuser: it says to specify the user that is running the DAS. AFAIK, this is not needed. The DAS reads it's key file from its own home directory, independent of the sshuser value. |
Posted by trmueller at Oct 29, 2010 11:40
|
| Comment ID |
Location |
Comment |
| YKB-1 |
setup-ssh man page para 2 |
"To contact remote hosts.."
-Its not just contacting remote host but also to perform or execute any administration operation on the remote host.
|
| YKB-2 |
setup-ssh man page para 3 |
A private key may or may not be protected by a key passphrase |
| YKB-3 |
setup-ssh man page para 4 |
Generating an SSH key pair
-The lines starting from "If a passphrase-protected key pair.." till the end of the section are incorrect. setup-ssh supports only generation of key without a passphrase. If user wants to use a stronger key, then passphrase protected key would need to be generated manually. After that, user can run setup-ssh to propagate the key to remote host. |
| YKB-4 |
setup-ssh man page para 5 |
Distributing the public key
-In the sentence "user-home is the user's home..", change "host" to "remote host"
-Sentence "If public key authentication is not setup.." is incorrect. If public key auth already works, the command just exits saying that public key authentication is already setup. Password authentication is used to connect to the remote host to propagate the public key. Hence SSH password is mandatory. Password can be specified using a password file or through password prompt (i.e interactive)
Typo in option name "-pasword"
-If the private key is protected by a passphrase, user will be prompted for the key passphrase (in interactive mode) or one can specify the passphrase using password file. |
| YKB-5 |
setup-ssh man page |
To add more info to the point "The subcommand does not modify..." setup-ssh doesn't require any configuration information from domain.xml (all information like ssh user host, port, keyfile location etc. is collected through the options) nor does it store any of the SSH information to domain.xml |
| YKB-6 |
setup-ssh man page |
Prerequisites:
-sshd on DAS host is not necessary.
-On Windows, user can rely on OpenSSH within Cygwin or MKS Toolkit. There are a few things to be taken care of in Windows, following links provide more info: http://wikis.sun.com/display/GlassFish/3.1SSH+-+Installing+Windows+Cygwin+sshdhttp://wikis.sun.com/display/GlassFish/3.1SSH+-+MKS+sshd+tips |
| YKB-7 |
setup-ssh man page |
--sshkeyfile and --sshpubickeyfile sections: Its just "identity" and "identity.pub" (not identitylocation, identitylocation.pub) |
| YKB-8 |
setup-ssh man page |
--generatekey description needs be re-written. SSH password is not related to this option at all, all references to password or passphrase needs to be removed from this section.
-This option is to basically support key generation in non-interactive mode.
-Since default value of this option is false, if no key pair is found, command fails.
-If user specifies --generatekey=true and key already exists, no key pair generation takes place. The already existing key is used for propagation. |
| YKB-9 |
setup-ssh |
The password token AS_ADMIN_SSH_PASSWORD (for SSH user password) can be mentioned under --sshuser since ssh user, password go together. Likewise password token AS_ADMIN_SSH_KEYPASSPHRASE (for key passphrase) can be mentioned under --sshkeyfile |
| YKB-10 |
setup-ssh |
We should also mention that by default, the key pair is expected to be under user-home/.ssh directory on DAS host. In case, there are multiple keys under the .ssh directory, the order of preference is id_rsa, id_dsa, identity. |
| YKB-11 |
Info |
Not sure if you've seen this link on setup-ssh: http://wikis.sun.com/display/GlassFish/3.1SSHPublicKeySetup |
Posted by xyamini at Nov 04, 2010 10:11
|
| jfd-1 |
trm-1 |
Actually if the node-host is detected to be the same as the DAS host then SSH is not used. |
| jfd-2 |
create-node-ssh, description |
"A node must be present on every host..." I prefer: "A node must be created for every host..." |
| jfd-3 |
create-node-ssh, --nodedir |
The default is "installdir/glassfish/nodes". A relative path may be provided (this was recently fixed). The path is relative "installdir/glassfish". |
| jfd-4 |
create-node-ssh, --sshuser |
"...user that is to run the process for connecting to this node." I prefer: "...user that is used when connecting to this node via SSH. |
| jfd-5 |
create-node-ssh, --sshkeyfile |
"identitylocation" should be "identity" |
| jfd-6 |
create-node-ssh, --sshkeyfile |
Should mention how to handle key files that are encrypted with a passphrase. See next comment... |
| jfd-7 |
create-node-ssh |
Should mention the ability to configure an SSH node to use password authentication via the asadmin password file. I think there needs to be a section mentioning that there are AS_ADMIN_SSHPASSWORD and AS_ADMIN_SSHKEYPASSPHRASE adminfile properties that can be used to specify an SSH password for the user and an SSH keyfile phassphrase. |
| jfd-8 |
create-node-ssh, See Also |
Include create-node-config |
| jfd-9 |
create-node-config, Description |
"present on" -> "created for" |
| jfd-10 |
create-node-config |
Mention built in config node "localhost" |
| jfd-11 |
create-node-config |
May want to mention that config nodes can be used for remote hosts, but if they are then you may not use: create-instance/delete-instance, start-instance, start-cluster – but instead must use the local version of those commands (except for start-cluster which does not have a local version) |
| jfd-12 |
asadmin, Options --passwordfile |
AS_ADMIN_SSHPASSWORD: also read by create-node-ssh, update-node-ssh. "AS_ADMIN_PASSPHRASE" should be "AS_ADMIN_SSHKEYPASSPHRASE". Description: key passphrase for reading encrypted SSH key files. Also read by create-node-ssh, update-node-ssh |
| jfd-13 |
asadmin, Options --paswordfile |
I think there should be a mention of the syntax for password aliases,and create-password-alias should be listed in the See Also section. |
Posted by dipol at Nov 04, 2010 15:31
|
| Comment ID |
Response |
| trm-1 |
Decline. See jfd-1. |
| trm-2 |
Done. |
| trm-3 |
Decline. The path separator to use the path separator for whichever OS the user is using. As this convention is intuitively obvious, users might actually be confused if the convention were to be stated. The only situation in which the convention might need to be stated would be a mixed cluster, which is not supported. |
| trm-4 |
Yes. Done. |
| trm-5 |
Done. |
| trm-6 |
Done. |
| trm-7 |
Done. |
| trm-8 |
Yes. Done. |
| trm-9 |
Done. Each man page now states that SSH must be configured on the host where the subcommand is run and any host on which the subcommand operates. |
| trm-10 |
Yes. Done. |
| trm-11 |
Done. |
| trm-11 |
Done, though I assume you mean --installdir, as uninstall-node does not have an --archivedir option. |
| trm-12 |
Done. |
| trm-13 |
Done. |
| trm-14 |
Decline. Given that a node is defined as a representation of a host, it would be confusing to shift emphasis and talk about a host "containing" a node. |
| trm-15 |
Done. |
| trm-16 |
Done, although instead of "some", I have said "that acts on multiple hosts", which is the important point. |
| trm-17 |
Done, though I assume (and have stated) that the DAS needs the ssh client. |
| trm-18 |
Done. |
| trm-19 |
Done. |
| trm-20 |
Done. |
| trm-21 |
Decline. Unncessary detail. |
| trm-22 |
Done. |
| trm-23 |
Decline. It already does. That's what the statement, "If the node is not enabled for remote communication, the subcommand enables SSH communication for the node," means. |
| trm-24 |
Done. |
Posted by pauldavies at Jan 12, 2011 16:24
|
| Comment ID |
Response |
| YKB-1 |
Done. I have said "To contact and administer remote hosts..." |
| YKB-2 |
Done. |
| YKB-3 |
Done. |
| YKB-4 |
1st item decline. user-home is the user's home directory on either the host where the command is run or on a remote host, dependingin the context. Otherwise, done. |
| YKB-5 |
Done. |
| YKB-6 |
Done, but see also my response to trm-17. The details about setting up SSH on Windows will be explained in the HA Admin Guide. |
| YKB-7 |
Done. |
| YKB-8 |
Done. |
| YKB-9 |
I have explained these tokens in the paragraph about distributing the key in the Description section. |
| YKB-10 |
This point is already made in the descriptions of the --sshkeyfile and --sshpublickeyfile options. I have amended these descriptions to state the order of preference. |
| YKB-11 |
Yes, thank you. This information will be useful input to the HA Admin Guide. |
Posted by pauldavies at Jan 12, 2011 16:26
|
| Comment ID |
Response |
| jfd-1 |
No change required. |
| jfd-2 |
Done. Changed to say "must exist for". |
| jfd-3 |
Done. |
| Jfd-4 |
Done. |
| jfd-5 |
Done. |
| jfd-6 |
Done. |
| jfd-7 |
Done. |
| jfd-8 |
Done. |
| jfd-9 |
Done. Changed to say "must exist for". |
| jfd-10 |
Done. |
| jfd-11 |
Done. |
| jfd-12 |
Done. |
| jfd-13 |
Done. |
Posted by pauldavies at Jan 12, 2011 16:27
|
| I would like to comment aboiut Chapter2:
Administering GlassFish Server Nodes. In order to execute the create-node-ssh sub command,
we will specify the public key file and
password alias like follows in most case.
# echo "AS_ADMIN_SSHPASSWORD=${ALIAS=ssh-password}" > /tmp/p
# asadmin \--passwordfile /tmp/p create-node-ssh \--nodehost glassfish-node1 \--sshuser root \--sshkeyfile \~/.ssh/id_rsa \--installdir /usr/local/glssfish3 node1
You may explain the public key and secret key on
Chapter 1. GlassFish Server Compatibility Issues .
However I assume that it may be useful for customer
that you should explain how to use the password alias
and key files on Chapter2 like above.
I think that you mentioned the very simple use case on the manual now.
Actual use case you should specify on the manual.
Thanks & Best Regards.
Yoshio.
Posted by yosshi at Jan 31, 2011 22:58
|
Comment ID
|
Location
|
Comment
|
JC-001
|
Page 37, Chapter 2, "Administering GlassFish Server Nodes"
|
The last topic covered is upgrading a node from a "CONFIG" node to an "SSH" node. I do not see "upgrading a node from an SSH node to a CONFIG node", which also seems to be possible. Please run this by the admin team. If this is possible (and not a bug), then we should change the word "upgrading" to the word "converting" since it is bi-directional.
|
Posted by johnclingan at Feb 03, 2011 09:34
|
| On nodes.pdf
| Comment ID |
Location
|
Comment
|
sre-001
|
p37, Upgrading a CONFIG Node
|
What are the consequences of upgrading the DAS config node to an SSH node?
|
sre-002
|
Following on from JC-001 above
|
You can convert the DAS config node to an SSH node, but you can't go backwards afterwards (does it make sense being able to change it from CONFIG->SSH when its the DAS localhost node?) :
$ asadmin update-node-ssh localhost-domain1
Command update-node-ssh executed successfully.
$ asadmin list-nodes
localhost-domain1 SSH localhost
gfcluster2 SSH virtlab2-dhcp125
$ asadmin update-node-config localhost-domain1
remote failure: Cannot update node localhost-domain1. It is the built-in localhost node.
Command update-node-config failed.
You certainly can go from SSH->CONFIG, so if this is allowed and won't cause problems it should be documented.
$ asadmin list-nodes
localhost-domain1 SSH localhost
gfcluster2 SSH virtlab2-dhcp125
Command list-nodes executed successfully.
$ asadmin update-node-config gfcluster2
Command update-node-config executed successfully.
$ asadmin list-nodes
localhost-domain1 SSH localhost
gfcluster2 CONFIG virtlab2-dhcp125
|
Posted by tecknobabble at Feb 04, 2011 09:01
|
| Comments on nodes.pdf
| Comment ID |
Location |
Comment |
| trm-001 |
p32 |
typo: "servercreates" |
| trm-002 |
general |
Following on JC-001 above, conversion is bidirectional. It is possible to convert an SSH node back to a CONFIG node.
|
| trm-003 |
general |
Regarding sre-002, update-node-ssh should probably not work on localhost-domain1. This could arguably be called a bug. |
| trm-004 |
general |
It might be good to have a reference in this section to the setup-ssh command that is helpful for getting SSH configured. |
Posted by trmueller at Feb 07, 2011 12:34
|
| Chapter 2 Administering GlassFish Server Nodes
Comment Id
|
Location
|
Comment
|
jfd-100
|
p28
|
May want to mention that create-nod-ssh validates the parameters and tests the SSH connection, so that's why it's a good idea to have ssh working before you create the ssh nodes.
|
jfd-101
|
p28
|
How about adding a description of the SSH authentication options available and how to use the asadmin pasword file to pass the password (or aliases) if need be to create-node-ssh?
|
jfd-102
|
p30
|
How about "Reachable" instead of "Usable"?
|
jfd-103
|
trm-3
|
With respect to Tom's comment on paths...Tom was assuming a mixed OS cluster. I still feel we should state that we do *not* support mixed OS deployments. Or at least that we don't support the DAS on Windows and instances on another platform (even though that can work).
|
Posted by dipol at Feb 07, 2011 14:19
|
| Comment ID |
Location |
Comment |
| cm-001 |
p 32 |
There is a reference to "Create an Instance Locally" and in that doc there is a section "Before You Begin" starts with "Ensure that the node on which the instance is to reside exists." I think this is a little confusing. The user can create a config node and the create-local-instance command will populate it with the correct info if needed. In addition create-local-instance will create the node if needed (which is mentioned in the docs). I didn't see mention of the case where the user creates a place holder config node and create-local-command fills in the pertinent info. What we call the offline case. |
Posted by carlavmott at Feb 07, 2011 14:32
|
Comment ID
|
Location
|
Comment
|
JC-002
|
Setting up ssh page 26
|
Change "practicable" to "practical"
|
JC-003
|
Setting up ssh page 26
|
"However, setting up SSH might require much effort, especially on Windows systems." We'll want to tweak this statement a bit. "Most operating systems ship with sshd pre-configured and running, so setup is minimal. Windows hosts do not ship with sshd, and will require additional setup."
|
JC-004
|
Setting up ssh page 27
|
"For the cygwin & MKS versions, we should add an "or greater" or "". So, it would be "Cygwin release 1.7.6" and "MKS Toolkit for Developers release 9.2+"
|
JC-005
|
Setting up ssh page 27
|
"Remote instances are started as the SSH user." should be changed to "Remote instances are started as the SSH user by default".
|
JC-006
|
Setting up ssh page 35
|
One additional step for MAC OS X. After enabling "remote login", users should ensure that either that either "All Users" are allowed access or the user running the DAS or Instance is allowed access (highlighted).
|
JC-007
|
Setting up ssh page 37
|
In troubleshooting section, it would be valuable to state that the command line "ssh" client has the -v option to produce verbose output, and sshd can be run manually with the "-d" option to produce debugging output. How to manually run sshd varies by platform.
|
JC-008
|
Setting up ssh page 39
|
It is stated in the note that "only required options to complete the task" are required. In the first step, "setup-ssh --generatekey=true host-list", the --generatekey options is actually optional. If a user already has a ssh key, a new one does not need to be created (and setup-ssh will test for this). Many, if not most, non-windows developers will already have an ssh key. Verify with joe dipol.
|
JC-009
|
Setting up ssh page 40
|
"When the SSH user runs a subcommand that requires SSH authentication, SSH must be able to authenticate the user without prompting for the passphrase."
This should be re-phrased to state:
"When the SSH user runs a subcommand that requires SSH authentication, GlassFish Server must be able to authenticate the user without prompting for the passphrase."
Joe DiPol may have more specific verbiage for "GlassFish Server", such as "the DAS and asadmin(1M) utility".
|
Posted by johnclingan at Feb 07, 2011 16:37
|
| Comment ID |
Response |
| JC-002 |
Done. Although "practicable" is the grammatically correct choice, it is probably the wrong choice as it confuses even native English speakers. I have used "feasible" instead. |
| JC-003 |
Done. |
| JC-004 |
Decline. |
| JC-005 |
Decline. After double-checking with the engineering subject matter expert, I can confirm that it's not a default. The user that starts the instance must log in as the SSH user. I wonder if you are confusing the SSH user with the DAS user, which is the default SSH user? |
| JC-006 |
Done. |
| JC-007 |
Done. |
| JC-008 |
Done. |
| JC-009 |
Done. |
Posted by pauldavies at Feb 07, 2011 17:32
|
| Comments on ssh-setup.pdf
Comment ID
|
Location
|
Comment
|
| sre-001 |
p29, To Set the Home Directory
|
The path /etc/passwd makes no sense unless you are within a cygwin shell. If you try to run a windows editor to edit the file, e.g. notepad /etc/passwd, notepad will fail to open the file. Two choices would appear to be:
1) Change the path to c:\cygwin\etc\passwd
2) Tell the users to also install "vim" (in the Editors category) so their cygwin install has a common editor, so that vi /etc/passwd is possible.
|
| sre-002 |
p37, Troubleshooting
|
It may be obvious, but worth repeating, that if the machine you've setup an ssh server on has a firewall, then a rule will be needed to allow inbound traffic on port 22.
|
| sre-003 |
p35, SSH setup on Solaris, point 2 and Example 2-2
|
Not sure why "status" is in the command. To find the status of an SMF service you just do svcs <service name>. I don't see why we should be looking for information about the NFS status service in addition to the SSH service.
If you change the command to:
/usr/bin/svcs ssh
you get just the information about the ssh service and not the nfs status service. Hence in the example you'd be able to remove the line with nfs/status on it.
|
sre-004
|
p46, install-node
|
It doesn't appear possible to create multiple installations on the same machine without resorting to trickery. For example if I have:
NODE NAME TYPE NODE HOST INSTALL DIRECTORY REFERENCED BY
localhost-domain1 SSH localhost /support/sfw/gf31 c1-i1, c1-i2, inst1
gfcluster2 SSH virtlab2-dhcp125 /support/sfw/gf31
I can't run install-node like this:
asadmin install-node --installdir=/support/sfw/gf31tmp virtlab2-dhcp125
Node virtlab2-dhcp125 is already installed and configured for use.
But if I fully qualify the host then its happy, i.e.
asadmin install-node --installdir=/support/sfw/gf31tmp virtlab2-dhcp125.uk.sun.com
Created installation zip /support/.ssh/glassfish2983466568029542682.zip
Successfully connected to iplanet@virtlab2-dhcp125.uk.sun.com using keyfile /support/.ssh/id_rsa
Copying /support/.ssh/glassfish2983466568029542682.zip (116753459 bytes) to virtlab2-dhcp125.uk.sun.com:/support/sfw/gf31tmp
Installing glassfish2983466568029542682.zip into virtlab2-dhcp125.uk.sun.com:/support/sfw/gf31tmp
Removing virtlab2-dhcp125.uk.sun.com:/support/sfw/gf31tmp/glassfish2983466568029542682.zip
Fixing file permissions of all files under virtlab2-dhcp125.uk.sun.com:/support/sfw/gf31tmp/bin
Command install-node executed successfully.
works. It appears to base its checks purely on the hostname provided, when really it should look at (install-dir, node-host) to determine if the installation already exists or not.
|
Posted by tecknobabble at Feb 08, 2011 11:05
|
| Chapter 2: Setting Up SSH for Centralized Administration
| Comment ID |
Location |
Comment |
| jfd-200 |
p26 |
I think it is helpful to list the common commands that depend on SSH to function (on remote instances): create-instance, delete-instance, start-instance, start-cluster. |
| jfd-201 |
p29 |
"each user's home directory for Cygwin and Windows must be the same". This is not really true. The discussion on p31 for MKS concerning the trade-off of dual home directories applies to the Cygwin case too. The general issue is the same – the mechanism for changing the home directory is different. |
| jfd-202 |
p30, 3a-c |
ssh-host-config: I think there was some bad info on some wiki pages that got carried over here. Let me try some tests today and get you specifics. |
| jfd-203 |
p31 |
See jfd-201 |
| jfd-204 |
p37 Before "Troubleshooting". |
May want to add a note saying "The first time you connect to a host you may be told that the authenticity can't be established, and asked if you want to continue connection. Assuming you trust the host just anser 'yes'". |
| jfd-205 |
p37 "Setting Up SSH User Authentication" |
First paragraph ("When a GlassFish Server subcommand...") is no longer true and should be removed. |
| jfd-206 |
p38 Table, Public key with passphrase-protected encryption |
"For each SSH user, password aliases are required." -> "For each SSH user GlasFish password aliases are required for the encryption passphrase" |
| jfd-207 |
p38 Table, Password |
"For each SSH user password aliases are required" -> "for each SSH user GlassFish password aliases are required for the SSH password" |
| jfd-208 |
p38 |
"The public key file..." -> "The private and public key files..." |
| jfd-209 |
p39 Step 1 |
Note that setup-ssh should be run as the SSH user, or the --sshuser option should be used to indicate the SSH user. |
| jfd-210 |
p39 Example2-4 |
State that the command is being run by user "gfuser" |
| jfd-211 |
p39 Next Steps |
"...to the SSh user's .ssh directory." -> "...into the SSH user's authorized_keys file. |
| jfd-212 |
p40 |
The paragraph starting "When the SSH user runs..." is misleading and inaccurate. How about something like: "In order for GlassFish to use the encrypted key it needs to know the passphrase that was used to encrypt the key. The secure way to do this is to create a GlassFish password alias for the passphrase." |
| jfd-213 |
p41 Step 1 |
"The ssh-keygen utility prompts...". May want to add "Accepting the default location in ~/.ssh is recommended." |
| jfd-214 |
p42 Step 7 |
"Create an alias" -> "Create a GlassFish alias". I've been recommending adding "GlassFish" to clarify this password alias thingie is a GlassFish concept. |
| jfd-216 |
p42 Note |
The Note isn't quite correct. Once you create the SSH node you do not need to pass SSH credentials to commands. So it is more accurate to say: "This file will be needed when you create SSH nodes with create-node-ssh. You will pass it to the asadmin command using the --passwordfile option." |
| jfd-217 |
p43 |
Similar to jfd-212. The paragraph that starts with "When the SSH user..." is inaccurate. Replace with something like: "When GlassFish connects using SSH it will need the SSH password. This password is provided by the user when running the command create-node-ssh. In order to pass and store this password securely (not in clear text) you will use the GlassFish password alias capability". |
| jfd-218 |
p43, last sentence |
"public key" -> "password" |
| jfd-219 |
p44, Note |
The file will be passed only to create-node-ssh, not all subcommands. |
Posted by dipol at Feb 08, 2011 11:11
|
| Regarding sre-004, I've had similar problems setting up an environment on localhost when creating a lab environment. If I use the IP address (127.0.01) vs localhost (already exists), then it works fine. So the logic must be string-comparing names. This will require the user to either have multiple DNS entries for an IP, a multi-homed host, etc. I wouldn't call this trickery per-se. I can see this check on create-node, but I agree that install-node should remove this check (perhaps an RFE).
Posted by johnclingan at Feb 08, 2011 13:23
|
| Created issue GLASSFISH-15910.
Posted by tecknobabble at Feb 09, 2011 09:29
|
| Comments on ha-intro.pdf
| Comment ID |
Location
|
Comment
|
sre-001
|
p17, Overview of High Availabilty
|
Is this just the open source version of the HA Admin Guide? If its also for the pay-for version shouldn't we also be plugging (pun intended) our own LB Plugin solution in the list of features at the bottom of the page?
|
sre-002
|
p18, Load Balancing with Apache mod_jk
|
While the website is httpd.apache.org the project is known as the Apache HTTP Server, not HTTPD Server.
|
sre-003
|
p18, High Availability Java Message Service
|
Sun Java Systems Message Queue should be GlassFish Message Queue.
|
sre-004
|
p18, High Availability Java Message Service |
GF Message Queue doesn't have a standalone existence anymore. Hence "tightly integrated" might be redundant, and could be replaced simply with "provided".
|
sre-005
|
p22, Recovering the Domain Administration Server
|
GF 3.1 has the capability of creating schedules to allow periodic backups to be taken. Perhaps we need a pointer to the documentation that covers that here.
|
sre-006
|
p23, Recovering GlassFish Server Instances
|
Can the update-admin-server-coordinates/update-admin-server-local-coordinates commands be used to remove the restriction on recovering onto a machine using the same IP address as the failed one?
|
sre-007
|
p23, Recovering the HTTP Load Balancer |
Just backing up the loadbalancer.xml may not be enough. If the DAS certificate has been exported and imported into the Web Server certificate store then either its NSS files should also be backed up, or the administrator will have to re-export and re-import the DAS certificates.
The LB plugin installer currently puts the LB plugin into the glassfish-lbplugin directory within the web server's installation directory.
|
sre-008
|
p23, Recovering Message Queue |
Given Message Queue will not be available standalone, and will be installed as part of the GF 3.1 installation, its unlikely that the MQ config will be under /var/imq, that's really only valid for the older package-based standalone MQ installations, that were part of the JES stack. The location would only be valid if the customer was using an older version of MQ that used such a location, and hadn't changed the broker's varhome to some other location - the broker would need to be configured as a REMOTE JMS Host in the GF configuration for that to be possible.
If a GF Cluster is not using a highly available MQ cluster, then the MQ data will be under each instance in the node directory, e.g. <gf-install-dir>/glassfish/nodes/<node-name>/<instance-name>/imq. Hence a proper backup of the nodes/instances should also provide a backup of the MQ data.
If the GF Cluster is an HA-MQ cluster, then the data will be in a database (ideally clustered) and it would fall back to whatever backup mechanism is appropriate for the database in question.
|
Posted by tecknobabble at Feb 09, 2011 10:00
|
| comments for Setting Up SSH for Centralized Administration
| Comment ID |
Location |
Comment |
| cm-001 |
pg. 39 Next Steps |
For each host, log in first with the unqualified host name and then with the fully qualified name |
Posted by carlavmott at Feb 14, 2011 12:00
|
| Comments on fix-node.pdf: None.
Posted by trmueller at Feb 21, 2011 11:51
|
| Comments on fix-node.pdf
| Comment ID |
Location |
Comment |
| cm001 |
pg47, 1st paragraph under To Correct the... |
If the host is not in the node agent info then the nodehost is on set to localhost it is left blank and so the CONFIG node contains just the node name attribute |
| cm002 |
page 48 |
In the example provide the nodehost name too |
Posted by carlavmott at Feb 21, 2011 14:19
|
| You're welcome and thank you for reviewing this documentation. Procedures for securely using password authentication for SSH logins are provided in the chapter Setting Up SSH for Centralized Administration. These procedures use GlassFish password aliases as an alternative to the creation of a temporary password file as suggested in your comment.
Posted by pauldavies at Feb 25, 2011 14:00
|
| Comment ID |
Response |
| JC-001 |
Done. |
Posted by pauldavies at Feb 25, 2011 14:01
|
| Comment ID |
Response |
| sre-001 |
Answer: Same as for any other CONFIG node. No change required. |
| sre-002 |
The asymmetry of the behavior looks like a bug to me. I have added the general CONFIG>SSH use case. |
Posted by pauldavies at Feb 25, 2011 14:02
|
| Comment ID |
Response |
| trm-001 |
Done. |
| trm-002 |
Done. |
| trm-003 |
See my response to sre-002. |
| trm-004 |
A cross-reference to the chapter about setting up SSH has been added to the 1st para of Creating, Listing, Testing, and Deleting SSH Nodes on p28. |
Posted by pauldavies at Feb 25, 2011 14:03
|
| Comment ID |
Response |
| jfd-100 |
Done. |
| jfd-101 |
Done. |
| jfd-102 |
Done. |
| jfd-103 |
Done - in the Deployment Planning Guide. |
Posted by pauldavies at Feb 25, 2011 14:04
|
| Comment ID |
Response |
| cm-001 |
Done, though we don't call it the offline case. See the descriptions of node-host and install-dir in Step 2 of To Create a CONFIG node and Example 2-6 on p 33. |
Posted by pauldavies at Feb 25, 2011 14:04
|
| Comment ID |
Response |
| sre-001 |
Done (option 1). |
| sre-002 |
Done. |
| sre-003 |
Done. |
| sre-004 |
Decline. This does seem a somewhat unusual use case. |
Posted by pauldavies at Feb 25, 2011 14:08
|
| Done.
Posted by pauldavies at Feb 25, 2011 14:56
|
| Comment ID |
Response |
| jfd-200 |
Decline. The user is more interested in the tasks, which the targets of the existing cross-references list |
| jfd-201 |
Done. |
| jfd-202 |
Done. |
| jfd-203 |
Done. |
| jfd-204 |
Done. |
| jfd-205 |
Done - I assume that only the "without prompting part" is no longer true. |
jfd-206 -
jfd-219 |
Done. |
Posted by pauldavies at Feb 25, 2011 15:01
|
| Comment ID |
Response |
| cm001 |
Done. |
| cm002 |
Done. |
Posted by pauldavies at Mar 11, 2011 14:17
|
|
create-node-ssh.1.pdf (application/pdf)
