The power of knowledge warehousing: เมษายน 2010

วันพฤหัสบดีที่ 29 เมษายน พ.ศ. 2553

Object class violation when creating group in LDAP using WebSphere Portal

Technote (troubleshooting)

Problem(Abstract)

When attempting to create a group using IBM® WebSphere® Portal, you receive an "EJPSG0015E: Data Backend Problem" error. The details show that this is caused by the LDAP server returning an error code 65 (object class violation).

Symptom

SystemOut.log will contain:

... WSMM Message E com.ibm.ws.wmm.ldap.LdapRepositoryImpl void create(String DN, Attributes attributes) The following Naming Exception occured during processing: "javax.naming.directory.SchemaViolationException: [LDAP: error code 65 - Object Class Violation]; remaining name 'cn=testgroupname,o=ibm'; resolved object com.sun.jndi.ldap.LdapCtx@28da7087".
... CreateGroupCo E com.ibm.wps.command.puma.CreateGroupCommand AbstractCommand.throwCommandFailedException EJPEB0003E: CreateGroupCommand.execute: An exception occurred.
com.ibm.wps.util.DataBackendException: EJPSG0015E: Data Backend Problem
...
Caused by: com.ibm.websphere.wmm.exception.WMMSystemException: The following Naming Exception occured during processing: "javax.naming.directory.SchemaViolationException: [LDAP: error code 65 - Object Class Violation]; remaining name 'cn=testgroupname,o=ibm'; resolved object com.sun.jndi.ldap.LdapCtx@28da7087". at com.ibm.ws.wmm.ldap.LdapRepositoryImpl.create(LdapRepositoryImpl.java:107)

Resolving the problem

Refer to the 'LDAP: error code ...' technote in the related information below which explains that the LDAP server generates the error code 65. Consult with your LDAP administrator to troubleshoot the failure from an LDAP perspective.
You may have to update the WebSphere Member Manager (WMM) configuration to resolve the problem. For example, this error can occur when attempting to create a group in IBM Tivoli Directory Server (ITDS) using the objectClass accessGroup. Consider the case where wmm.xml contains:

<supportedLdapEntryType name="Group" rdnAttrTypes="cn" objectClassesForRead="accessGroup" objectClassesForWrite="accessGroup" searchBases="o=ibm"/>

and wmmLDAPServerAttributes.xml contains:

<attributeMap wmmAttributeName="groupMember" pluginAttributeName="uniqueMember" applicableMemberTypes="Group" dataType="String" valueLength="1024" multiValued="true" defaultValue="uid=dummy"/>
If you enable the traces recommended in the WebSphere Member Manager MustGather and attempt to create a group in WebSphere Portal, you will see the following in trace.log:
.WMM Trace Log > com.ibm.ws.wmm.ldap.LdapConnectionImpl DirContext createSubcontext(Name name, Attributes attrs) Entry cn=testgroupname,o=ibm {objectclass=objectClass: accessgroup, uniquemember=uniquemember: uid=dummy, cn=cn: testgroupname}
...
WSMM Message E com.ibm.ws.wmm.ldap.LdapRepositoryImpl void create(String DN, Attributes attributes) The following Naming Exception occured during processing: "javax.naming.directory.SchemaViolationException: [LDAP: error code 65 - Object Class Violation]; remaining name 'cn=testgroupname,o=ibm'; resolved object com.sun.jndi.ldap.LdapCtx@1faad592"

This failure occurs because the definition of the accessGroup object class does not include uid and uniquemember attributes:

accessgroup :
{
1.3.18.0.2.6.75
NAME 'accessGroup'
DESC 'A group that is used for access control.'
SUP top STRUCTURAL
MUST cn
MAY (businessCategory $ description $ member $ o $ ou $ owner $ seeAlso)
}
Therefore, to correct the problem you have two options. If your LDAP server is configured such that a defaultValue is required for member (see "Mapping LDAP Attributes" link below), then you must update wmmLDAPServerAttributes.xml replacing the entry for wmmAttributeName="groupMember" with (changing pluginAttributeName and defaultValue):

<attributeMap wmmAttributeName="groupMember" pluginAttributeName="member" applicableMemberTypes="Group" dataType="String" valueLength="1024" multiValued="true" defaultValue="cn=dummy"/>
If your LDAP server does not require a defaultValue, you could use the following instead:

<attributeMap wmmAttributeName="groupMember" pluginAttributeName="member" applicableMemberTypes="Group" dataType="String" valueLength="1024" multiValued="true"/>
Use the check-out/check-in procedure to update the WMM configuration if running in a cluster. Restart WebSphere Portal to read the updated WMM configuration.

Related information

'LDAP: error code ...' messages
WMM MustGather
Mapping LDAP Attributes

วันพุธที่ 7 เมษายน พ.ศ. 2553

Detailed steps for mapping LDAP attributes in WebSphere Portal 6.1

Technote (FAQ)

Question

How can you map attributes in IBM WebSphere Portal 6.1? It appears that there are unmapped attributes by default when initially configuring WebSphere Portal to an LDAP. WebSphere Portal Information Center does not provide detailed steps to explain the process.

Answer

The following step-by-step instructions address attribute mapping in WebSphere Portal and should be considered as supplemental information to the WebSphere Portal Information Center page, Mapping attributes. The instructions in this technote use a stand-alone security setup on Linux with Tivoli Directory Server as the LDAP. However, they can be adjusted to address other LDAPs or operating systems, and can be modified for federated repository setups by using the appropriate properties as outlined on the Information Center page.

------------------

1. Run "ldapsearch" from the Linux console to determine available attributes in LDAP. If you do not have an ldapsearch tool, refer to the related information at the bottom of this technote for a link to a command-line tool.

Command:

Results:

Command:

Results:

------------------

2. Run ./ConfigEngine.sh wp-query-attribute-config to produce output similar to the following in the <wp_profile>/ConfigEngine/log/Configtrace.log:

and then use the above information to modify the wkplc.properties file:

------------------

Additional output in the ConfigTrace.log:

[wplc-validate-ldap-attribute-config] The following attributes are flagged as required in LDAP but not in Portal - You should flag them as required in Portal, too:
[wplc-validate-ldap-attribute-config] [sn, cn]

Modifiy the wkplc.properties file accordingly:

user.attributes.required=sn,cn
-----------------

Additional output in the ConfigTrace.log:

[wplc-validate-ldap-attribute-config] FYI: The following attributes have a diffenrent type in Portal and in LDAP - No action is required:
[wplc-validate-ldap-attribute-config] jpegPhoto: Base64Binary <> 1.3.6.1.4.1.1466.115.121.1.5
[wplc-validate-ldap-attribute-config] password: Base64Binary <> 1.3.6.1.4.1.1466.115.121.1.5
[wplc-validate-ldap-attribute-config] seeAlso: String <> 1.3.6.1.4.1.1466.115.121.1.12

No modifications are required in the wkplc.properties file.

-------------------

Additional output in the ConfigTrace.log:

[wplc-validate-ldap-attribute-config] Possible problems for Group:

[wplc-validate-ldap-attribute-config] The following attribues are defined in Portal but not in LDAP - You should either flag them as unsupported or define an attribute mapping:[wplc-validate-ldap-attribute-config] [modifyTimestamp, groups, members, identifier, displayName, parent, children, entitlementInfo, partyRoles, viewIdentifiers, createTimestamp]

Modify the wkplc.properties file accordingly:

-----------------

Additional output in the ConfigTrace.log:

[wplc-validate-ldap-attribute-config] The following attributes are flagged as required in LDAP but not in Portal - You should flag them as required in Portal, too:
[wplc-validate-ldap-attribute-config] []

No modifications are required in the wkplc.properties file.

-----------------

NOTE: Leave the following line unchanged in the wkplc.properties file:

standalone.ldap.attributes.mapping.entityTypes=PersonAccount,Group
-----------------

3. Run ./ConfigEngine.sh wp-update-standalone-ldap-attribute-config and ensure you receive a BUILD SUCCESSFUL message.

4. Run ./ConfigEngine.sh wp-query-attribute-config and ensure you receive a BUILD SUCCESSFUL message.

5. Once all required attributes are mapped, run the following tasks to propagate the security changes in a standalone (non-clustered) environment:

admin_userid

admin_password

wp_profile_root

WebSphere_Portal

admin_userid

admin_password

wp_profile_root

WebSphere_Portal

wp_profile_root

http://www.ibm.com/support/docview.wss?rs=688&ca=portall2&uid=swg21365605

Related information

Mapping Attributes
Using ldapsearch to debug LDAP configuration problems
Exception related to attributes

วันศุกร์ที่ 2 เมษายน พ.ศ. 2553

Messages In Console: Oracle(9581): Floating-Point Assist Fault At Ip [ID 279456.1]



		Modified 27-JAN-2010 Type PROBLEM Status PUBLISHED

In this Document
Symptoms
Cause
Solution
References

Applies to:

Oracle Server - Enterprise Edition - Version: 10.1.0.2 to 10.1.0.2
Red Hat Enterprise Linux Advanced Server Itanium
UnitedLinux Itanium
Oracle Server Enterprise Edition - Version: 10.1.0.2 to 10.1.0.2
Checked for relevance on 25-Feb-2009

This note is applicable on Itanium Architecture only

Symptoms

In the server console appears messages like

oracle(9581): floating-point assist fault at ip 40000000068c22c2
...
oracle(13763): floating-point assist fault at ip 40000000072b8081

Cause

The messages are not errors,
just information/warning that the operation being performed by the processor needed a software assist.

As reported on
http://h21007.www2.hp.com/portal/site/dspp/menuitem.863c3e4cbcdc3f3515b49c108973a801?ciid=62080055abe021100055abe02110275d6e10RCRD

We reproduce here part of this article titled What's up with those "floating-point assist fault" messages? - Linux on Itanium

When working at the Linux console or looking through the kernel's log file in /var/log/messages,
you may encounter messages of the form:

test-fpsr(1416): floating-point assist fault at ip 40000000000005d2

This message means that program "test-fpsr" with process id 1416 performed a floating-point
operation that required software assistance.
On Itanium, this usually happens when operating on IEEE denormals
(numbers that cannot be represented in normalized form).

Again, just like for unaligned accesses, these operations are emulated in the kernel,
so there is nothing to worry from a correctness point of view. However,
emulating these operations takes time and can slow down a program significantly.
Since most programs don't need full IEEE-compliance, Itanium Linux
provides a function to turn on "flush-to-zero" mode in the processor,
which avoids generating IEEE denormals as a result of ordinary floating-point calculations.
This mode can be turned on using the following code fragment:

#include
:
fesetenv (FE_NONIEEE_ENV);
:

Alternatively, compiler option -ffast-math can be used when linking
the final program to achieve the same effect. For example:

gcc -ffast-math test.o -o test

would build program "test" with flush-to-zero mode turned on.

Note:
the Oracle code cannot be changed or compiled such that the condition that generates the message is eliminated.
This because the hardware doesn't support the floating-point operation being reque

Solution

It is possible to completely turn off the floating-point assist messages from the console (they are still written to /var/log/messages)
To do this, simply issue the command as "root":

$ dmesg -n4

To eliminate them also from /var/log/messages :

1. edit /etc/syslog.conf changing line:

*.info;mail.none;authpriv.none;cron.none /var/log/messages

*.error;mail.none;authpriv.none;cron.none /var/log/messages

This means any facility logging messages below error level will be suppressed

2. restart syslog
service syslog restart

To explain wht is being suppressed:
From the syslog man page:

Every text line in a message has its own loglevel.
This level is DEFAULT_MESSAGE_LOGLEVEL - 1 (6) unless the line starts with <d> where d is a digit in the range 1-7,
in which case the level is d. The conventional meaning of the loglevel is defined in <linux/kernel.h> as follows:

       #define KERN_EMERG    "<0>" /* system is unusable               */
       #define KERN_ALERT    "<1>" /* action must be taken immediately */
       #define KERN_CRIT     "<2>" /* critical conditions              */
       #define KERN_ERR      "<3>" /* error conditions                 */
       #define KERN_WARNING "<4>" /* warning conditions               */
       #define KERN_NOTICE   "<5>" /* normal but significant condition */
       #define KERN_INFO     "<6>" /* informational                    */
       #define KERN_DEBUG    "<7>" /* debug-level messages             */

The n4 in the dmesg command means to filter messages of "warning conditions" of which the floating point software assist messages are. The *.error in syslog.conf means all levels below e

References

BUG:3777000 - FLOATING-POINT ASSIST FAULT(FPSWA) CAUSES POOR PERFORMANCE
BUG:3796598 - KERNEL: ORACLE(570): FLOATING-POINT ASSIST FAULT AT IP CAUSES CONNECTION PROBLEM
http://i-cluster2.inrialpes.fr/doc/misc/fpswa.txt
http://bugpriority.oraclecorp.com/pls/bugpriority/DWB_RFA_HTML.RFA_ADMIN?P_RFA_REQUEST_ID=1158
http://h21007.www2.hp.com/portal/site/dspp/menuitem.863c3e4cbcdc3f3515b49c108973a801?ciid=62080055abe021100055abe02110275d6e10RCRD

Show Related Information Related

Products

Oracle Database Products > Oracle Database > Oracle Database > Oracle Server - Enterprise Edition