Managing Serviceguard Extension for SAP Version B.05.10, September 2010

id_dsa
id_dsa.pub
The file id_dsa.pub contains the security information (public key) for the user@host pair
e.g. root@<local>. This information needs to be added to the file
$HOME/.ssh/authorized_keys2 of the root and <sid>adm user.
Create these files if they are not already there. This will allow the root user on <local> to
remotely execute commands via ssh under his own identity and under the identity of <sid>adm
on all other relevant nodes.
On each cluster node where a SGeSAP package can run, test the remote access to all relevant
systems as user root with the following commands:
ssh <hostN> date
ssh -l <sid>adm <hostN> date
Do these tests twice since the first ssh command between two user/host pairs usually requires
a keyboard response to acknowledge the exchange of system level id keys.
Make sure that $HOME/.ssh/authorized_keys2 is not writable by group and others. The
same is valid for the complete path.
Permissions on $HOME should be 755. Permissions on $HOME/.ssh/authorized_keys2 must
be 600 or 644.
Allowing group/other write access to .ssh or authorized_keys2 will disable automatic
authentication.
After successful installation, configuration and test of the secure shell communication ssh can
be used by SGeSAP. This is done via setting the parameter REM_COMM to ssh in the SAP-specific
configuration file sap.config under section Configuration of the optional Application Server
Handling.
# REM_COMM=ssh
# REM_COMM=remsh
Installation Step: IS280
If storage layout option 1 is used, create all SAP instance directories below /export as specified
in chapter 2.
Example:
su - <sid>adm
mkdir -p /export/sapmnt/<SID>
mkdir -p /export/usr/sap/trans
exit
MAXDB Database Step: SD290
Create all MAXDB directories below /export as specified in chapter 2.
Example:
su - sqd<sid>
mkdir -p /export/sapdb/programs
mkdir -p /export/sapdb/data
mkdir -p /export/var/spool/sql/ini (MaxDB < 7.8 only)
mkdir -p /export/sapdb/client (MaxDB >= 7.8 only)
exit
MAXDB Database Step (>=7.8 only): SD295
Switch off autostart for installation specific x_server.
With “isolated installation” each 7.8 database has its own associated vservers. The general vserver
still exists for older databases and to forward requests to the vserver of a 7.8 database. The startup
of the generic vserver will also startup the installation-specific vserver out of the DB specific bin
directory (while stopping of the generic won’t stop the specific ones). When running more than
one 7.8 database in a clustered environment this startup behavior may lead to error messages
(because the filesystem of the other DB isn’t mounted) or even busy filesystems belonging to the
HP-UX Configuration 61