By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,532 Members | 1,514 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,532 IT Pros & Developers. It's quick & easy.

Install DB2 on Linux MC/ServiceGuard Cluster

P: n/a
Hi,

We are currently installing a DB2 V9 ESE on a Linux server
(RHEL4U4-x86_64). Installation runs successfully on each node. Database
user environment is OK and the instance is well created. To be sure,
we've started the database with db2start =successfull. And then shut
it down again successfully too.

The tricks appears when we switch the hp MC/ServiceGuard (A.11.16 for
Linux) package to the other node... the database does not want to start
up. It fails with that message:

[root@node2 ~]# su db2r01 -c /db2/R01/sqllib/adm/db2start
SQL1092N "DB2R01 " does not have the authority to perform the
requested command.

[That's the manual issued command but the behaviour is identical within
the hp MC/ServiceGuard Control Script]

For information, each node (the cluster is composed with only 2 nodes)
has its own DB2 binaries+userspaces. The instance is named db2r01 and
datafiles are stored in /db2/R01 filesystem. This filesystem is on a SAN
device and presented to all cluster nodes (mounted only on active node).

We will appreciate any help and thank you in advance for your spent time
on that problem!!!

To sum up, is there a very detailed cookbook explaining how install DB2
in a ServiceGuard (for Linux) environment?

Best regards,
Bruno LIVERNAIS, Mohamed SALHI
Apr 27 '07 #1
Share this Question
Share on Google+
3 Replies


P: n/a
If none of you knows something about MC/ServiceGuard, may be someone
could help us about DB2 V9 in a cluster HA environment (HACMP, or
whatever...)

Please help!!!!!

Bruno LIVERNAIS a écrit :
Hi,

We are currently installing a DB2 V9 ESE on a Linux server
(RHEL4U4-x86_64). Installation runs successfully on each node. Database
user environment is OK and the instance is well created. To be sure,
we've started the database with db2start =successfull. And then shut
it down again successfully too.

The tricks appears when we switch the hp MC/ServiceGuard (A.11.16 for
Linux) package to the other node... the database does not want to start
up. It fails with that message:

[root@node2 ~]# su db2r01 -c /db2/R01/sqllib/adm/db2start
SQL1092N "DB2R01 " does not have the authority to perform the
requested command.

[That's the manual issued command but the behaviour is identical within
the hp MC/ServiceGuard Control Script]

For information, each node (the cluster is composed with only 2 nodes)
has its own DB2 binaries+userspaces. The instance is named db2r01 and
datafiles are stored in /db2/R01 filesystem. This filesystem is on a SAN
device and presented to all cluster nodes (mounted only on active node).

We will appreciate any help and thank you in advance for your spent time
on that problem!!!

To sum up, is there a very detailed cookbook explaining how install DB2
in a ServiceGuard (for Linux) environment?

Best regards,
Bruno LIVERNAIS, Mohamed SALHI

--

DSLAM shm67-1 ligne 10 / 1 / 3
Apr 30 '07 #2

P: n/a
Bruno LIVERNAIS wrote:
Hi,

We are currently installing a DB2 V9 ESE on a Linux server
(RHEL4U4-x86_64). Installation runs successfully on each node. Database
user environment is OK and the instance is well created. To be sure,
we've started the database with db2start =successfull. And then shut
it down again successfully too.

The tricks appears when we switch the hp MC/ServiceGuard (A.11.16 for
Linux) package to the other node... the database does not want to start
up. It fails with that message:

[root@node2 ~]# su db2r01 -c /db2/R01/sqllib/adm/db2start
SQL1092N "DB2R01 " does not have the authority to perform the
requested command.
I dont know anything about MC/ServiceGuard, but have you checked out
what the help suggests?

[lelle@53dbd181 lelle]$ db2 "? SQL1092N"
SQL1092N "<authorization-ID>" does not have the authority to
perform the requested command.

Explanation:

Possible causes are:

1. The user attempted to execute a command or operation without
having the proper authority for that command or operation.

2. You are using Kerberos authentication in a Windows
environment, and have attempted to log on to the machine with
an account which is not a domain account. Only domain users
can use Kerberos authentication in a Windows 2000
environment.

3. If you are using LDAP support, the userid you are using or
the DB2 Connect gateway might not have the authority to
perform the CATALOG DATABASE, NODE and DCS DATABASE
commands.

4. If in a Windows environment, the DB2 Server logon userid,
DB2_GRP_LOOKUP setting, and other group enumeration settings
might not be configured properly, preventing you from gaining
access using "<authorization-ID>". The following is a
very common sample scenario:

- You are attempting to connect to the DB2 Server using a
domain userid.

- The logon userid for the DB2 Server instance is LocalSystem
or a local account.

- Groups (SYSCTRL, SYSADM, SYSMAINT) are defined to be domain
groups.

- DB2_GRP_LOOKUP is not set. As a result, an attempt is made
to enumerate the groups at the location where
"<authorization-ID>" is defined. This fails
because the DB2 Server instance is running under the
context of LocalSystem or the local account, and so
cannot access the network resources required to do so.

- To fix this problem change the logon userid for the DB2
Server instance to be a domain account and add this
domain account to the local Administrators group. If DB2
Extended Security is enabled, then the domain account
must also be added to the DB2ADMNS group or its
equivalent.

5. If in a Windows environment running with DB2 Extended
Security enabled, the userid "<authorization-ID>" might
be attempting to use or modify a database resource, while not
a member of the local DB2USERS or DB2ADMNS group. This is
not allowed. The command cannot be processed.

The command cannot be processed.

Federated system users: this situation can also be detected by
the data source.

User Response:

Solutions to problem causes described above are:

1. Log on as a user with the correct authority and retry the
failed command or operation. Correct authorities may include
SYSADM, SYSCTRL, SYSMAINT, and DBADM. DBADM is granted on
databases and all other authorities are determined by
membership in the groups defined in the database manager
configuration (eg. if sysctrl_group in the database manager
configuration file is defined as 'beatles', then you must
belong to the group 'beatles' to have SYSCTRL authority).
Refer to the Command Reference or the SQL Reference for the
listing of required authorities for the attempted command or
operation.

2. Log on to the machine with an account which is a domain
account.

3. Invoke the command "UPDATE DBM CFG USING CATALOG_NOAUTH YES"
at the client or the gateway to correct the problem.

4. Make appropriate configuration settings changes. For more
information on Windows OS security and groups, search the DB2
Information Center
(http://publib.boulder.ibm.com/infocenter/db2luw/v9) using
phrases such as "db2_grp_lookup" and "Windows authentication"
Apr 30 '07 #3

P: n/a
I've installed my instance on each Linux node in exactly the same way.
/etc/passwd and /etc/group are identical on each node.

Lennart a écrit :
Bruno LIVERNAIS wrote:
>Hi,

We are currently installing a DB2 V9 ESE on a Linux server
(RHEL4U4-x86_64). Installation runs successfully on each node.
Database user environment is OK and the instance is well created. To
be sure, we've started the database with db2start =successfull. And
then shut it down again successfully too.

The tricks appears when we switch the hp MC/ServiceGuard (A.11.16 for
Linux) package to the other node... the database does not want to
start up. It fails with that message:

[root@node2 ~]# su db2r01 -c /db2/R01/sqllib/adm/db2start
SQL1092N "DB2R01 " does not have the authority to perform the
requested command.

I dont know anything about MC/ServiceGuard, but have you checked out
what the help suggests?

[lelle@53dbd181 lelle]$ db2 "? SQL1092N"
SQL1092N "<authorization-ID>" does not have the authority to
perform the requested command.

Explanation:

Possible causes are:

1. The user attempted to execute a command or operation without
having the proper authority for that command or operation.

2. You are using Kerberos authentication in a Windows
environment, and have attempted to log on to the machine with
an account which is not a domain account. Only domain users
can use Kerberos authentication in a Windows 2000
environment.

3. If you are using LDAP support, the userid you are using or
the DB2 Connect gateway might not have the authority to
perform the CATALOG DATABASE, NODE and DCS DATABASE
commands.

4. If in a Windows environment, the DB2 Server logon userid,
DB2_GRP_LOOKUP setting, and other group enumeration settings
might not be configured properly, preventing you from gaining
access using "<authorization-ID>". The following is a
very common sample scenario:

- You are attempting to connect to the DB2 Server using a
domain userid.

- The logon userid for the DB2 Server instance is LocalSystem
or a local account.

- Groups (SYSCTRL, SYSADM, SYSMAINT) are defined to be domain
groups.

- DB2_GRP_LOOKUP is not set. As a result, an attempt is made
to enumerate the groups at the location where
"<authorization-ID>" is defined. This fails
because the DB2 Server instance is running under the
context of LocalSystem or the local account, and so
cannot access the network resources required to do so.

- To fix this problem change the logon userid for the DB2
Server instance to be a domain account and add this
domain account to the local Administrators group. If DB2
Extended Security is enabled, then the domain account
must also be added to the DB2ADMNS group or its
equivalent.

5. If in a Windows environment running with DB2 Extended
Security enabled, the userid "<authorization-ID>" might
be attempting to use or modify a database resource, while not
a member of the local DB2USERS or DB2ADMNS group. This is
not allowed. The command cannot be processed.

The command cannot be processed.

Federated system users: this situation can also be detected by
the data source.

User Response:

Solutions to problem causes described above are:

1. Log on as a user with the correct authority and retry the
failed command or operation. Correct authorities may include
SYSADM, SYSCTRL, SYSMAINT, and DBADM. DBADM is granted on
databases and all other authorities are determined by
membership in the groups defined in the database manager
configuration (eg. if sysctrl_group in the database manager
configuration file is defined as 'beatles', then you must
belong to the group 'beatles' to have SYSCTRL authority).
Refer to the Command Reference or the SQL Reference for the
listing of required authorities for the attempted command or
operation.

2. Log on to the machine with an account which is a domain
account.

3. Invoke the command "UPDATE DBM CFG USING CATALOG_NOAUTH YES"
at the client or the gateway to correct the problem.

4. Make appropriate configuration settings changes. For more
information on Windows OS security and groups, search the DB2
Information Center
(http://publib.boulder.ibm.com/infocenter/db2luw/v9) using
phrases such as "db2_grp_lookup" and "Windows authentication"
.

5. Add the userid "<authorization-ID>" to the local windows
security groups DB2USERS or DB2ADMNS using the Windows Computer
Management tool. A workaround is to disable Extended Security but
this is not recommended.

Federated system users: if necessary isolate the problem to the
data source rejecting the request (see the problem determination
guide for procedures to follow to identify the failing data
source) and ensure that the authorization id specified has the
proper authority on that data source.

Contact the System Administrator for authority request
assistance. Do not attempt to execute the command without
appropriate authorization.

>>
[That's the manual issued command but the behaviour is identical
within the hp MC/ServiceGuard Control Script]

For information, each node (the cluster is composed with only 2 nodes)
has its own DB2 binaries+userspaces. The instance is named db2r01 and
datafiles are stored in /db2/R01 filesystem. This filesystem is on a
SAN device and presented to all cluster nodes (mounted only on active
node).

We will appreciate any help and thank you in advance for your spent
time on that problem!!!

To sum up, is there a very detailed cookbook explaining how install
DB2 in a ServiceGuard (for Linux) environment?

Best regards,
Bruno LIVERNAIS, Mohamed SALHI
Bruno LIVERNAIS wrote:
>Hi,

We are currently installing a DB2 V9 ESE on a Linux server
(RHEL4U4-x86_64). Installation runs successfully on each node.
Database user environment is OK and the instance is well created. To
be sure, we've started the database with db2start =successfull. And
then shut it down again successfully too.

The tricks appears when we switch the hp MC/ServiceGuard (A.11.16 for
Linux) package to the other node... the database does not want to
start up. It fails with that message:

[root@node2 ~]# su db2r01 -c /db2/R01/sqllib/adm/db2start
SQL1092N "DB2R01 " does not have the authority to perform the
requested command.

I dont know anything about MC/ServiceGuard, but have you checked out
what the help suggests?

[lelle@53dbd181 lelle]$ db2 "? SQL1092N"
SQL1092N "<authorization-ID>" does not have the authority to
perform the requested command.

Explanation:

Possible causes are:

1. The user attempted to execute a command or operation without
having the proper authority for that command or operation.

2. You are using Kerberos authentication in a Windows
environment, and have attempted to log on to the machine with
an account which is not a domain account. Only domain users
can use Kerberos authentication in a Windows 2000
environment.

3. If you are using LDAP support, the userid you are using or
the DB2 Connect gateway might not have the authority to
perform the CATALOG DATABASE, NODE and DCS DATABASE
commands.

4. If in a Windows environment, the DB2 Server logon userid,
DB2_GRP_LOOKUP setting, and other group enumeration settings
might not be configured properly, preventing you from gaining
access using "<authorization-ID>". The following is a
very common sample scenario:

- You are attempting to connect to the DB2 Server using a
domain userid.

- The logon userid for the DB2 Server instance is LocalSystem
or a local account.

- Groups (SYSCTRL, SYSADM, SYSMAINT) are defined to be domain
groups.

- DB2_GRP_LOOKUP is not set. As a result, an attempt is made
to enumerate the groups at the location where
"<authorization-ID>" is defined. This fails
because the DB2 Server instance is running under the
context of LocalSystem or the local account, and so
cannot access the network resources required to do so.

- To fix this problem change the logon userid for the DB2
Server instance to be a domain account and add this
domain account to the local Administrators group. If DB2
Extended Security is enabled, then the domain account
must also be added to the DB2ADMNS group or its
equivalent.

5. If in a Windows environment running with DB2 Extended
Security enabled, the userid "<authorization-ID>" might
be attempting to use or modify a database resource, while not
a member of the local DB2USERS or DB2ADMNS group. This is
not allowed. The command cannot be processed.

The command cannot be processed.

Federated system users: this situation can also be detected by
the data source.

User Response:

Solutions to problem causes described above are:

1. Log on as a user with the correct authority and retry the
failed command or operation. Correct authorities may include
SYSADM, SYSCTRL, SYSMAINT, and DBADM. DBADM is granted on
databases and all other authorities are determined by
membership in the groups defined in the database manager
configuration (eg. if sysctrl_group in the database manager
configuration file is defined as 'beatles', then you must
belong to the group 'beatles' to have SYSCTRL authority).
Refer to the Command Reference or the SQL Reference for the
listing of required authorities for the attempted command or
operation.

2. Log on to the machine with an account which is a domain
account.

3. Invoke the command "UPDATE DBM CFG USING CATALOG_NOAUTH YES"
at the client or the gateway to correct the problem.

4. Make appropriate configuration settings changes. For more
information on Windows OS security and groups, search the DB2
Information Center
(http://publib.boulder.ibm.com/infocenter/db2luw/v9) using
phrases such as "db2_grp_lookup" and "Windows authentication"
.

5. Add the userid "<authorization-ID>" to the local windows
security groups DB2USERS or DB2ADMNS using the Windows Computer
Management tool. A workaround is to disable Extended Security but
this is not recommended.

Federated system users: if necessary isolate the problem to the
data source rejecting the request (see the problem determination
guide for procedures to follow to identify the failing data
source) and ensure that the authorization id specified has the
proper authority on that data source.

Contact the System Administrator for authority request
assistance. Do not attempt to execute the command without
appropriate authorization.

>>
[That's the manual issued command but the behaviour is identical
within the hp MC/ServiceGuard Control Script]

For information, each node (the cluster is composed with only 2 nodes)
has its own DB2 binaries+userspaces. The instance is named db2r01 and
datafiles are stored in /db2/R01 filesystem. This filesystem is on a
SAN device and presented to all cluster nodes (mounted only on active
node).

We will appreciate any help and thank you in advance for your spent
time on that problem!!!

To sum up, is there a very detailed cookbook explaining how install
DB2 in a ServiceGuard (for Linux) environment?

Best regards,
Bruno LIVERNAIS, Mohamed SALHI
Apr 30 '07 #4

This discussion thread is closed

Replies have been disabled for this discussion.