> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
> Behalf Of Per-Ola Mard
> Sent: Friday, December 04, 1998 12:31 PM
> To: [EMAIL PROTECTED]
> Subject: AFS/Novell integration
>
>
> Hello AFS land,
>
> I have two questions around this,
>
> 1) Is there anybody out there that have come across a site that use a
> combination of Novell and AFS. Could be in terms of introducing an
> AFS cell to an existing Novell oriented administration?
We do a significant amount of both throughout campus. The central
academic computing group relies on AFS heavily as an institutional
filesystem, along with the College of Engineering and the College of
Physical and Mathematical Sciences. Other Colleges within the University
are primarily NetWare(Bindery and NDS), although the College of Textiles
has a lot of NT Server. The administrative computing side is pretty much
NetWare only, but we have a lot of hybrid folks and services. The merge
point for NDS and AFS services comes in our burgeoning NT labs, where AFS
is the primary filestore, but we use NDS for printing and application
management (NAL).
Novell services mean much, much, more than filespace, which is why things
work out pretty well with both on our campus. AFS is a filesystem. Novell
has a filesystem (and print servers, and application management, and a
directory services, etc.), which makes it a bit of an apples<->oranges
perspective.
However, just comparing fileservices: The arguments in my mind
(I'm not an AFS administrator, so some of this is an outsider
looking in) for AFS are:
*) Location independence from the user perspective: You might be able to
fake this in Netware with login scripts and directory map objects, but
it's still not going to be as good as the database server.
*) The "volume-per-user" concept: From my perspective, this makes moving
volumes around, and allocating additional space for, much easier.
Three others that might be strengths:
*) TCP/IP transport: NetWare 5 is pretty impressive, but I haven't done
a lot of filesystem-over-tcp/ip testing, neither has the marketplace,
so I guess you could say that AFS has "more mature" TCP/IP support
*) Replication: The database/location servers in AFS make this better.
NRS is interesting, but it's an add-on to the NetWare file system.
AFS's replication is, as I guess you could say again, "more mature."
*) Better Unix client support. Maybe a double-edged sword. Kinda of a
"duh" point at any rate.
Weaknesses
*) Client support: Zero support for non-Windows NT windows clients and the
Macintosh, and I'm personally not overly impressed with the Windows NT
client, at least in comparison to the Unix clients. (Microsoft doesn't
give them much to work with there, I know).
Samba w/AFS support (or PC Enterprise) and Netatalk go a long way
toward client support, but it's still translation, and it's always
going to be slower than native support. I realize there are things
coming up in 3.5 that may help, but it's still not native support.
(80, 90, 95% - whichever number you read this week - of the desktop
computers run Windows or MacOS, kinda hard to pump all those systems
through translators)
*) Distributed Administration: NetWare's file system uses NDS and NDS
provides in my mind, much, much better distributed administration.
This may be an arguable weakness, depending on the structure of your
organization.
========
And keep an eye out on the horizon for NSS. The technical architect for
NSS at Novell came from the AFS team. He knows his stuff, and the promises
for NSS look pretty rosy.
>
> 2) Does anybody have any type of figures on performance comparing Novell
> and AFS?
I'd love to see these. An anecdotal, how does it "feel" test:
>From the NT Client, NetWare file space wins hands down at initial
access. By the time things are cached, most small read/writes are
perceptibally even. Medium read/writes (5-15MB) are NetWare
favored, I haven't tried large read/writes. A lot goes into
this though, and read/writes, server load, network conditions/support,
time of day, phase of moon, matter greatly. I don't think I could
get an apples<->apples comparison going, even if it's possible.
>
> --- Begin brainstorm;
> I guess the first level of integration would be to share the AFS tree,
> make it visible to Novell clients, by using SAMBA. Then comes the
> issue of user-admin and tokens... Novell has a repository of user
> acounts, how do you integrate this with AFS kas/pts etc?
I think this would be possible (hell, everything's possible with
money and programmers), but would require rewrites to the AFS backend
and extensions to NDS. I've heard rumours of rumours of rumours
of some KDC integration into NDS, but that's about it. Novell intercepted
a PDC's SAM and redirected it to NDS, I imagine you could do the same
with kaserver and ptserver. I wouldn't want to do it though.
> Is there a way to extend the Novell login procedure on a PC
> having the Novell client installed to reach out for a token to the AFS
> cell at the time of login?
There is now an interface to Novell's login that you can intercept
login/logout "events" through an COM interface and do what you wish.
We haven't gone down this route, so I don't have involved it is.
Primary authentication would be NDS.
> Would it be reasonable to think that the
> AFS/NT client would happily coexist with the Novell client on a PC?
Sure does, at least from our perspective. We have a aklog-style
environment. We roll our accounts into Kerberos/AFS out of Sybase
(from HR and Reg/Records data). We use the same Sybase data to
populate same-userid accounts into NDS. (We also have accounts in
departments and various other places supported by the individual
departments). The large group of NDS accounts is currently geared
mostly to students and student-lab support.
> If so, how would you integrate the login procedure?
> Would this be a version of the Notredame/GINA way to do things.
Sortof. We had an early version of the nd_gina that formed the
foundation for our own Gina. The nd_gina is a stub-gina, layering
on top of the msgina.dll or whatever gina.dll. We couldn't get our
initial modications to work as well as we'd like on top of the
msgina.dll and it was a little worse on top of the nwgina.dll (not
a nd_gina issue, more netware gina + netware network provider + microsoft
+ us + random acts of non-kindness). We wrote a full replacement that
logs into Kerberos, aklog's, and logs into NDS (also runs user's login
scripts, etc.). We do what we can to make the Kerberos and NDS account
look like one (a password change web page for changing passwords, a
"Synchronization Wizard" in the client to try and handle mismatched
passwords (if the user remembers his/her last password).
It seems to work quite well, we can't do ZENworks related-things
(which requires "workstation" authentication that the netware gina
does). We may could go back to a stub-gina to do it. Some
limited information is at http:/www.ncsu.edu/nt/ncsugina
> Guy's I'm in real deep water
> here, anyone care to through me a rope or something?
I think the rope I've thrown you might be made of tissue paper,
but that's our story.
Jason
----------------------------------------------
Jason Adam Young, [EMAIL PROTECTED]
NC State University Computing Services
