Just before Tony's bedtime, William T Wilson wrote:
>Everything you talked about here should be doable using NIS, or
(for the
>security-minded) Kerberos.
>
Well, William (Bill?) I'll gladly trade NDS info for info on NIC
and Kerboros and how to implement it on Linux !
NDS is a encrypted, loosly consistent database spanning servers.
It is organised as a hierachy with Organisation Unit (OU) at the
top, with logical groups below as (Organisation). Eg MyCompany as
the OU and leaves such as Sales, Marketing and Development
undeneath. OU is logically the same as a Unix Domain. I'm happy to
be corrected, but I think the main differences underneath the top
level is that Novell will allow unlimited depth. An example fully
qualified reference would be
cn=admin.o=headoffice.o=sales.ou=my_company where 'admin' is a
super-user name and sales is a leaf underneath headoffice which is
under the OU my_company.
Although one can have an unlimited depth to the tree, most
companies rarely go below three levels underneath the OU. Servers,
Printers and other objects such as Users are entered into the tree
as belonging to a leaf eg SalesServer would belong to the sales
leaf.
On the server volume (volume=Unix filesystem) ALL files and
directories are known to the tree. So it is possible to assign
file and directory rights to a user.
Because the tree spans all servers in the OU, from a global
organisation perspective, a user can log into any server which
will accept that user. Once logged in a user can simply map drives
to other servers and printers to which he has permission.
>From an administration viewpoint, the tree is managed by a gui -
servers and printers and users can be assigned, de-assigned and
permissions and passwords managed from the gui. There is a
non-windows version of the gui but nobody uses that.
>From an architectural point of view the NDS is 'virtual' in that
there is no one server which contains the most up-to-date copy of
the tree - although tree changes are rippled thru the system quite
fast. A copy of the tree can exist on servers in three ways -
Master, Read-Write Replica and Read-Only replica. Not every server
need contain a copy of the tree. In a oragnisation of say 5 file
servers, it is usual and sufficient to have one master and one
read-write replica.
>From a design perspective, it is bad practice to span an OU across
a low-speed wan because of the inter-server tree-updates. I've
spanned the wan on higher speed links with no problems.
Time is also important in a NDS environment. It is vital to ensure
all servers are synchronised time-wise. If not synchronised then
there could be problems identifying the order of changes to the
tree. A typical problem is where a user changes password, and
finds that the password is invalid on certain servers. Time is
quite an interesting subject, and the way Novell manage time is by
means of master time servers and slaves.
Troubleshooting. Usually the NDS will work tranparently for years
without maintenence but in large server farms with many replicas
and time servers there may be problems. The main utility for
fixing problems is DSREPAIR. There are many references to DSREPAIR
in Novell HowTOs and problem-fix reports to help fix the problems.
However fixing obscure NDS problems is probably as complicated as
modifying sendmail.cf - it is still, I think a black art. I've
used DSREPAIR live in large environments quite frequenty, and I
still consider myself a humble apprentice.
Hope this helps!
Kind regards
Tony Wells
Phenomenal Books
"I have made this letter longer than usual because I lack the
time to make it shorter" - Blaise Pascal.
[EMAIL PROTECTED]
bookstuff: www.phenomenal-books.com
anyotherstuff: [EMAIL PROTECTED]
Intnl tel/fax: +44 1524 845559
UK tel/fax: 01524845559
Mobile: (+44) (0) 370 963410
--
PLEASE read the Red Hat FAQ, Tips, Errata and the MAILING LIST ARCHIVES!
http://www.redhat.com/RedHat-FAQ /RedHat-Errata /RedHat-Tips /mailing-lists
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject.
