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

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.