OES 2 Linux servers can be accessed by
Local (POSIX) users that are created on the server itself.
eDirectory users that are given local access through Linux User Manager (LUM).
However, there are some issues you need to consider:
There is no cross-checking between POSIX and eDirectory™ to prevent the creation of users or groups with duplicate names.
When duplicate names occur, the resulting problems are very difficult to troubleshoot because everything on both the eDirectory side and the POSIX side appears to be configured correctly. The most common problem is that LUM-enabled users can’t access data and services as expected but other errors could surface as well.
Unless you are aware of the users and groups in both systems, especially those that are system-created, you might easily create an invalid configuration on an OES 2 Linux server.
The following examples illustrate the issue.
There is a default system-created group named shadow that is used by certain Web-related services, including the OES 2 QuickFinder™ server, but it has no relationship with Dynamic Storage Technology (DST) and shadow volumes.
Because shadow is a local POSIX group, there is nothing to prevent you from creating a LUM-enabled second group in eDirectory that is also named shadow. In fact, this could be a logical name choice for many administrators in conjunction with setting up shadow volume access for Samba/CIFS users.
However, using this group name results in LUM-enabled users being denied access by POSIX, which looks first to the local shadow group when determining access rights and only checks eDirectory for a group named shadow if no local group is found.
There is another default system-created group named users that is not used by OES 2 services but is nevertheless created on all SLES 10 (and therefore, OES 2 Linux) servers.
Creating an eDirectory group named users would seem logical to many administrators. And as with the shadow group, nothing prevents you from using this name.
Unfortunately, having a LUM-enabled eDirectory group named users is not a viable configuration for services requiring POSIX access. The local users group is always checked first, and the LUM-enabled users group in eDirectory won’t be seen by POSIX.
NOTE:Do not confuse eDirectory Group objects with Organizational Unit (OU) container objects.
Creating an OU container in eDirectory named users is a valid option and does not create conflicts with POSIX.
Conflicts between group and user names also occur when administrators create local and eDirectory groups with the same name.
For example, one administrator creates a group named myusers on the local system and another creates a LUM-enabled group in eDirectory with the same name. Again, the LUM-enabled users who are members of the eDirectory group won’t have access through POSIX.
This is why we recommend that, as a general rule, administrators should not create local users or groups on OES 2 Linux servers. You should only make exceptions when you have determined that using LUM-enabled users and groups is not a viable option and that objects with the same names as the POSIX users and groups will not be created in eDirectory in the future.
Having duplicate users and groups is easily avoided by following these guidelines:
We recommend that you use the YaST Group Management/User Management module to check for names you might duplicate by mistake.
Open the YaST Control Center.
Click either or .
Click > .
Select both options ( and ), then click .
All users or groups as displayed, including those that exist only in eDirectory and are LUM-enabled.
To avoid duplication, keep this list in mind as you create eDirectory users and groups.
NOTE:The list of users and groups in Section I.0, System User and Group Management in OES 2 SP1 is not exhaustive. For example, the users group is not listed.
For OES 2 Linux services, the LUM technology eliminates the need for local users and groups. We recommend, therefore, that you avoid the problems discussed in this section by not creating local users and groups.