Hi,

Agreed that novlxsrvd is not required anymore. Tracking to remove with upcoming OES releases.

On usage of Novell Registry, it's used for more purposes that for the values/entries contained are more than their apparent use and registry is tightly coupled with xtier. So, we will continue to have registry.

Finally, for the question "And lastly, why can those LUM-enabled services not interact directly with Edir as e.g. Netware could", LUM enabled services use eDirectory only as identity service and interact with eDirectory through LUM as required.

Lokesh

Okay, the removal of novlxsrvd in the future is good news.

That sfcb and httpstkd work as LUM-enabled services is okay, but why tsafs can't use Edirectory is not clear to me - as this is a service, which was ported from Netware to OES and therefore originally had no idea of LUM. And if I remember correctly, that was not LUM-enabled in some earlier versions of OES, too. I explicitly ask for tsafs, because this does run as root - so no need to authenticate via LUM and secondly the file-system rights for NSS-volumes cannot be translated into LUM-rights as you can give NSS-file-rights to things like OUs etc, which have no representation in LUM.

Though tsafs (smdrd) runs as root, it does backup/restore or the file/folder moves during DFS move/split or migration using miggui/migfiles as the user who initiates these operations. On Linux, unlike NetWare, access to NSS is based on the "fsuid" of the process. The tsafs sets "fsuid" of the process to the "uid" of the user before making calls to NSS. LUM provides that "uid".

Though tsafs (smdrd) runs as root, it does backup/restore or the file/folder moves during DFS move/split or migration using miggui/migfiles as the user who initiates these operations. On Linux, unlike NetWare, access to NSS is based on the "fsuid" of the process. The tsafs sets "fsuid" of the process to the "uid" of the user before making calls to NSS. LUM provides that "uid".

Okay, I understand this approach.

But on the other hand ncp-fileaccess and cifsd are not LUM-enabled and also able to follow filesystem rights via eDir I presume. And the fsuid, which is set to the tsafs-process via setfsuid is just used by the nss-filsystem read/write processes to lookup this user in Edir to get the rights of this user. So you first create an UID for an Edir user via LUM, then set this UID as FSUID via setfsuid to the tsafs-process and then the nss-filsystem read/write processes use this FSUID to get the Edirectory user of the process, to get its filesystem rights. Wouldn't it be much more straghtforward, to directly pass the edir user of the user who invoked the tsafs to the nss read/write processes?