[sf-lug] mass copy of one file to multiple user accounts
Michael Paoli
Michael.Paoli at cal.berkeley.edu
Fri Sep 5 05:00:36 PDT 2008
> Date: Tue, 2 Sep 2008 09:28:27 -0700
> From: "Christian Einfeldt" <einfeldt at gmail.com>
> Subject: [sf-lug] mass copy of one file to multiple user accounts
> To: "sf-lug at linuxmafia.com List" <sf-lug at linuxmafia.com>
Well, my $0.02 worth or so ... many other suggestions were already made
along this "thread".
I might suggest/comment:
o *copying* the file per target account would be rather/quite wasteful
- particularly talking about larger file, and identical content, to
every - or many - accounts.
o linking - hard or soft links - much more space efficient and
generally more maintainable than the above, but generally has the
problem that users would typically be able to write in their $HOME
directories, and as long as they can do that, they can generally
remove file (or link) placed there - or at minimum, rename it rather
arbitrarily. There are more esoteric means one could go to to
prevent users from removing/renaming item(s) placed there, but that
would likely just cause more problems and confusion for yourself
and/or the next person that has to figure out what's going on there,
and how to maintain (update/change/etc.) it. Although one could have
user $HOME directories, where users couldn't write (and thus not
rename/remove items there) in their $HOME directories, that would
generally introduce quite another set of problems - at least for most
relatively typical usage (e.g. if one is trying to make a generally
fairly useful environment for the user(s), rather than a much more
restrictive, nailed down, and can't muck with much of anything,
learn, experiment, etc. environment, one would typically have users
normally able to write in their own $HOME directories).
o as was suggested by some other(s), placing the file where it can be
served up (e.g. fileserver or webserver) is a rather generally good
idea - it can be suitably protected, and (read) access opened up as
widely as deemed appropriate. A webserver might be the simplest
solution (e.g. Apache, and locate the file appropriately, and give
the students the URL - perhaps even (pre-)load it into the bookmarks
for their browser(s).
o Among suggestions related to the above, since the file is
(relatively) large (media file, not some teensy little text file),
primary audience is quite local (school lab), and availability to
that audience is much more important than serving the file up to the
Internet at large (which could also be done, or be done separately,
if desired), it would seem most logical to have it hosted on a system
in the school lab (would be much more reliably available, reduce
external bandwidth costs/congestion, avoid dependence upon external
resources for availability/updates/maintenance/etc. So, ... I'd
basically advocate that - put it on a local Apache server (or other
fileserver), and have the students access it that way.
Anyone have a (much) better idea given the (reasonably) presumed
objectives and design criteria? (if so, please explain, including
rationale).
> I am trying to copy one file, a test song, from one directory in my user's
> account on an LDAP network to multiple accounts on the same network. I want
> to make sure that when the file arrives in each user's directory, they will
> be able to play it, but not change it. The program that we are using is GNU
> Denemo, although that doesn't really matter. This is a run-of-the-mill
> permissions question, except that we are talking about copying one file to
> probably 200 directories or so.
More information about the sf-lug
mailing list