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"
