[OpenAFS] software for windows start out of OpenAFS Filespace?

[scorch]

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