Lars Schimmer wrote:
Sorry if I ask a bit further, is this still true with more users?
EG setting up one install in AFS filespace and office 2003 works for all
(10-2000) customers out of AFS space without an extra need of install
local at each PC?
this would be a good time for a slightly off-topic explanation about
32-bit windows s/w.... unix lovers go back to your dens of daemons :-)
IMHO don't go putting app binaries into AFS space until your windows
folks can already deploy apps in a secured fashion onto managed
workstations. by all means use afs to serve a campus-wide home folder.
but i really don't see the gain for app deployment in these days of
large local disks. in fact i didn't see it even in 1990s either FWIW.
long story short, while you can probably get almost all applications to
run out of AFS with some black magic for non-conforming ones, AFS will
not give you much additional benefit from the app mgmt viewpoint. you'll
always need to push some stuff (either config files into a users
profile, or registry entries into the HKEY_CURRENT_USER hive) for each
machine/user. AFS doesn't help you there aside from give you a common,
secured place to get "the bits" from.
so, you will always need a good s/w deployment & snapshotting tool, or
some truly killer customised login scripts. don't plan on returning to
see your replacement after you left; this person is going to come back
with an axe. this needs to be able to cope with deploying patches,
updates, changed configurations, resetting lost user settings, managing
2 or more different versions of apps (e.g. office to name 1), and
providing either a licence compliance system or some other control
mechanism. etc. etc. etc.
IMHO securing a university windows environment (e.g. uni of graz if i'm
not mistaken) is not really an afs problem. you can almost as easily
lock down the local machine with ACLs, & use the deployment tools from
above to ensure apps are identical across locations, without adding into
the equation (Open)AFS.
the long story:
this is from a number of years experience in universities & commercial
s/w distributions, & dealing with this from windows 3.x through nt40,
2000 & onwards;
- vast numbers of applications are not written for ease of use insecured
or multi-user environments, notably:
splitting data from executables & libraries
storing temporary files in "sensible" locations
managing different versions of common runtime libraries
storing per-system or per-user settings in "sensible" locations
referring to drive mappings, UNC paths, or shortcuts the "wrong way"
from what you needed
deploying sub-components "on demand" rather than built into the build
-in other words, expect to spend a minimum of 2 days per simple app for
a good windows admin identifying the above issues, & then integrating
through whatever black arts are deemed appropriate into your core builds.
that aside, windows apps should/might store things in different places
depending on the version of windows that they were written from:
dos & windows 3.x - whereever, some settings found in a .ini file in the
%windows% folder
nt40 - beginnings of moving parameters into the registry, split into a
"LOCAL MACHINE" section (OS & per-system parameters) and a "USERS"
section (one per user profile + one for machine-user settings), and a
separate section CLASSES for linking file types (not unlike mime from a
webserver) to the expected application hooks. startup files for excel,
word etc could be stored in a per-system folder, or in a per-user folder
depending on the configuration & the application.
w2000 - further changes to profiles, registry & .ini remappings to
better support windows terminal server & align with citrix
functionality. profile bloat becomes a significant issue for those who
tried to keep a standard desktop build, & keep user settings & files
stored "safely" on centrally managed servers.
so you can see now that stats packages, desktop office suits, custom
apps from lecturers, printer drivers, library catalog software, popular
web browsers, rampant security holes, poor documentation, students keen
on using games, pr0n, etc etc complicate the picture enough. AFS will
not simplify any of the mgmt issues above for you - & i believe that
once you've solved the above, there's no significant advantage in
storing the apps in AFS. today's 20+GB desktop drives can hold all the
packages you need without referring to a further cache for the application.
apologies to the MS world for the simplification & i am sure Jeff A
could have written a better summary.
generally:
avoid adding a NFS to the equation until you have your s/w packaging &
deployment issues sorted out. after this moving apps into afs will be
trivial in comparison :-)
set aside drive letters that will be standard site-wide for AFS
sub-mounts to allow future deployment where appropriate. i've done this
once for a site-wide novell deployment & this actually worked ok.
spend lots of time with windows admins discussing the issues above on
how they plan/can solve them before mentioning AFS.
i hope that helps!
PS if that turns out to be genuinely useful i can re-write it for the
wiki. please reply off-list.
a+
scorch
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
