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: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org