On Mon, Jan 27, 2003 at 08:44:55PM -0500, Neal Lippman wrote: > I am looking for an approach to the problem of having multiple > installations of debian on each computer on my lan that I use. While it > is certainly reasonable to have a minimal install on each system, > consisting of a basic debian system, it seems counterproductive to have > to install each program that I use on each workstation, rather than > having such software "served" by a central applications server.
Nitpicky point of terminology, but one which is actually relevant here: What you go on to describe is still a fileserver, just one that happens to be used to store files which are executable. In my experience, "application server" refers to a remote machine on which applications are run at the request of the local machine. That said, have you considered using X as the basis of an actual application server, with software running on the app server and displaying themselves on the local workstations? This can be done at two levels: Using ssh with X tunnelling, in which case you are normally using the local workstation, but can connect to the app server to run specific problems; or using XDMCP, which essentially turns the local workstation into a pure display terminal, running all software on the app server. Having implemented something like this at work, with a mix of smart terminals using ssh and dumb terminals using XDMCP (and even a few machines running both simultaneously in separate X servers), I have to say that the resource requirements for the app server are much lower and the overall system performance is much higher than I had expected. And as far as administration, well... the software is only installed in one place, so no synchronization or update hassles. > My present setup consists of a fileserver which exports various > directories via nfs, including both a network-wide data store (called > /share, for lack of a better idea), LFS defines "share" as a (sub)directory for architecture-independent shared data. From what little you mention here, that seems appropriate, although I would personally mount it under /var/local/share rather than /share. But that's purely a matter of taste. > By way of example, the workstation mounts server:/home onto /nfs; my > home directory on the workstation (/home/nl) is a symlink to /nfs/nl. > This way, no matter which workstation I log into, I have my global > /home/nl directory. Network-wide logins are handled by nis. Why do you mess around with the symlinks instead of just mounting server:/home under /home on the workstations? > Since /etc would be local to each workstation, the same install could > conceivably be used by each system with it operating differently because > of different config files (X comes to mind here, since hardware may > differ). Aye, and there's the rub... If you install everything to an app directory on a fileserver to be run on local workstations, you then have to keep the relevant bits of /etc and /var up-to-date yourself. This would likely give apt fits as well (apt on the workstations wouldn't have any idea of what's actually installed) and may the gods help you if you upgrade the server to a new version which isn't backwards-compatible with the config files on (some or all of) the workstations... > A problem, however, is that (as far as I can > tell) KDE does not understand multiple simultaneous logins, and > therefore I risk file corruption (or worse?) if I log in twice to my > account at the same time. Are you sure about that? I see odd directories (can't recall the name offhand) appear in the homes of KDE-using users which appear to be related to the KDE object model and include the hostname of the machine they're running from. Oh, yeah - .dcop-hostname or something close to it. I don't do KDE myself and none of my users run on two machines simultaneously, so I can't say how well it works, but this appears to be intended to address the situation you're describing. > Theoretically, I would need to do this for any porgrams that cannot > sucessfully sync shared storage (like evolution), however - so this > isn't really a good overall solution. You know, this reminds me of the locking problems I used to have with mutt... Are you sure your problem isn't at the NFS level rather than the application level? If you're running the user-space NFS daemon, it doesn't support file locking. (Or at least it didn't the last time I checked.) Build yourself a kernel on the file server with NFS support and install the kernel-space NFS daemon instead, if you haven't already done so. That should take care of most of your concurrency issues. > Any advice, pointers to references, etc, thoughts greatly appreciated. In theory, it's certainly possible to install your binaries on a file server and run them locally on each workstation. I've considered it myself and decided that it would most likely be even more trouble than managing local installations of each application. (Under debian, at least. If you were building everything from source, then it could well be worthwhile, but just running apt-get on each workstation would be easier than trying to make sure that /etc and /var are always in sync with /usr.) If you want to centralize your application installations, consider going to a full-blown app server, either with X apps tunnelled over ssh or by setting up XDMCP terminals. -- The freedoms that we enjoy presently are the most important victories of the White Hats over the past several millennia, and it is vitally important that we don't give them up now, only because we are frightened. - Eolake Stobblehouse (http://stobblehouse.com/text/battle.html) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
