G.T.Smith 写道:
I think you are rather hoping you can set it up and leave it.... if
people start using it and it becomes popular they will need support and
unless you have plenty of time it will be wise to consider who has
access, how you monitor that access, how you stop the resource being
compromised (security), and how you are going to assist the user community.
Unfortunately (for me) G. T. Smith said the truth: I even didn't realize myself that I was thinking how to save MY time doing this. I always want to have students who are interested to help administration, hoping that would reduce the work. This small project have little funds and we need to use existing resource.

I googled a lot and found I am outdated: FTP protocol can do encoding conversion. There is a new RFC2640 specified how to do this. I think vsftpd can save me a lot of maintenance for being secure and simple, but I found vsftp does not follow this RFC. After I read the RFC I go to vsftpd source, features.c and add one line of code to make it complaint with the new RFC (so much of goodness of opensource). So now if Windows user use standard complaint FTP client (FileZilla or smartftp, later I didn't test only heard of), they can get the filenames in correct encoding.

Security: as long as the server is not compromised, the file integrity is not my concern, because other campus services also have this problem (integrity) for years and they even offering .exe file for downloading (from a Windows server, oh, let's just hope they have patched everything), here I only got audio files, I am sure there will not be so much compliance.

The solution would be offering vsftpd server as well as NFS client. Most users will only use FTP, so I guess it's easy to control access (plenty of options in vsftpd.conf for controlling access). The Linux library and laboratory computers can use NFS share. I am pretty sure NFS share will not be a traffic problem because Linux users are still only a very very small percentage.
There are other issues, your network support people may not be too happy
if your archive stuffs the network if it gets popular, you may need to
look into things like multi-casting and QoS with them. You may and your
users may not be to happy if it the server collapses under the load.
Your solution needs to take into account how many people are expected to
use the resource, how often, and from where. While 100G may not seem a
lot,  100 people accessing 100G is an awful lot of data moving around
wires.

I am thinking about possible solutions:

     1. FTP -> can handle heavy load, can do bath upload, not
        random-accessible, auto-charset conversion not supported;
Hmm. usually hard work for the user. PUTTY in the Windows world does
offer a fairly simply command interface. Using cygwin on windows
machines to setup the machines up as a X terminal is a further route.
     2. apache -> batch download not easy for users, handle charset
        conversion nicely, not random access
Web is really down to how you setup the web access, it is up to you how
easy for the users to access the data and how it is presented. External
access becomes a viable option. Plenty of search options, and support
pages can be setup. Probably easiest solution because you will have
minimal security concerns, and only one thing to look after.
     3. NFS -> I don't know any free-as-in-beer Windows client software
        for it and I don't know if that client software can do charset
        conversion; for Linux clients it's perfect;
NFS within a university environment is a security no-brainer. I believe
NFS can be made to work under cygwin though I have not tried this myself.
     4. Samba -> I don't know if charset conversion is easy with it. If
        a SuSE client connects to it, can suse client select which
        charset to use without forcing user to use commandline? And how
        about windows, can windows connect to the samba share and do
        charset conversion automatically?
For raw file store access within the institution is OK. External access
usually a no-no. Sorting out authentication may be an interesting
experience if you are within an AD environment. Samba performs most of
things a domain server, you can set up the server end to use specific
character sets but the interaction with client may a bit odd if client
is configured for something different.
     5. DC++ -> looks very nice for charset conversion, I also tried it,
        nice. But I don't know if there are Linux server-end software.
        Need to check.

If it is peer to peer access is what is required e-Mule/e-Donkey is
another option, and there are other options. Personally do not use and
do not recommend P2P, security is down to the weakest link and P2P is
somewhat like unprotected sex... you never no what you are going to
catch. P2P solutions do need careful thought about security.

I am thinking perhaps combine two solutions together might be the best,
e.g. setting up FTP server for Windows users and set up NFS server for
Linux users. Still I am not sure what's the best solution, and there
might be better solutions than what I listed that I never heard of.

* In all above discussion "charset conversion" means charset conversion
for file names, not the content. Content is in mp3/ogg format.

Thanks for any comments!


The thing to remember in the University environment you have a lot of
talented individuals, and will regard any shared resource as fair game
to so you need to think paranoid. It may be a war zone in the outside
internet world but it can be like living in the middle of armageddon
within a University.



--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to