Intranet Hallways Systems Based on Linux
By Justin Seiferth,
[Update 27-Dec-1999: Author's e-mail address. -Ed.]
- Kernel Options
- Support Utilities
- HTML pages and scripts
- Some Configuration Changes
- A Quick installation
- Other things you might do with it
-
Once you've retrieved the distribution, it shouldn't take more than an hour to get things running; let know what you think about the system when you do.
The Opportunity
Microsoft's Windows NT suffers from a file system inherited from its MS-DOS lineage. For those of you who haven't had the displeasure this means file systems are cryptically named A-Z, can't automount and the process of manually mounting them is much more complicated and error prone than the more user friendly tools like Red Hat's fstool. These problems have been worked around somewhat at my agency through a series of .bat files which mount server drives in standard places so users can say "Just look at the T: drive" or something similar. This still left users with problems searching tens of thousands of files spread thousands of directories located on servers across the world. The Microsoft Windows NT operators were trying to figure out a way to present an efficient, agency-wide view of these servers so that users could easily find and retrieve things. We used Linux to integrate and publish these file sharing areas on our intranet.Before theShow
Key to the system is the ability of the Linux kernel (later 2.0 and 2.1 versions) to mount local NTFS and remote SMB volumes. There's nothing esoteric about enabling or using this option, just check it off when you're compiling the kernel. (Don't run away at the thought of compiling a kernel! Most distributions include these options in their default kernel so you probably don't have do anything- just try it out smbmount and see if it works). If any of your network shares are coming from Windows 95 machines, make sure to also select the patch for Windows 95 machines and long file names. If you are just serving Microsoft Windows NT or Samba shares, don't use the Windows 95 option as I've found it has a noticeable impact on the speed of the SMB mount and file operations.Once you've got an SMB capable kernel installed you're almost ready to go. The other critical components are thesmbfs utilities, the wu-ftpd suite, a web server, a search engine and a javascript - capable browser. Your distribution has probably installed an operational FTP and HTTP server and most people nowadays have a Netscape browser installed so all you really need to do is compile the smbfs utilities and setup a search engine. If most of the documents on your SMB shares are in text or HTML format, there are a number of search engines that you can choose from- htdig and glimpse come to mind. If you want to be able to search non-HTML documents then you might need one of the commercial search engine. We use Netscape's catalog server for Solaris.
The system will work without a javascript browser; it just won't be a easy to use. Hit the links to grab the software tools you need from the list above set it up. If you run into problems, be sure and check out the linux HOWTOs and mailing list documentation on the sites offering the software. If you have RedHat's RPM or Debian's package tools somebody else has probably already made a binary available; just check your local archive.
Set andStage
I'm assuming you've tested your kernel to make sure you can indeed mount SMB shares and that your ftp server is up and alive. Before we can start serving your "enterprise information warehouse" there are a few files which need to be added to or modified on your system in addition to the HTML files we'll discuss later. The first addition is a new init.d file for automatically mounting SMB shares when you boot your system. Then we'll enable a few features of your FTP server.First, let's contend with mounting shares automatically. I do this with a standard run-level 3/5 initscript; here's an excerpt with the most critical lines:
# Check that networking is up.
[ ${NETWORKING} = "no" ] exit 0# See how we were called.
case "$1" in
start)
echo -n "Mounting SMB shares..."
echo "Mounting share1"
/usr/sbin/smbmount //hostname/share /home/ftp/mountpoint -n -uftp -gftp -f755 -Ihostnames_IP_address
# mount your other shares
echo ""
;;
stop)
echo -n "Umounting SMB shares..."
/usr/sbin/umount /home/ftp/mountpoint
#insert other mount comments here ....
echo ""
;;
*)
echo "Usage: hallways {start|stop}"
exit 1
esac
The smbmount(8) and umount(8) man pages have more details on what all those flags are about. Basically, we are mounting the shares into a directory accessible via anonymous FTP. The permissions and groups are "fake" in the sense that they don't map to anything sensible in the NT file system; they are only for the convenience and protection of the Unix system. Our common shares are read/write for everyone; if your site is more cautious you may want to review the implications of the file permissions and ownership or perhaps impose access controls using your file system and web server's security mechanisms.Now, let's take a look at the scripts used to startup your FTP server. You have to make sure you're taking advantage of wu-ftpd's ftpaccess(5) configuration capabilities. If you start your FTP daemon using the -a option the /etc/ftpaccess file will allow you to customize many aspects of the FTP server's performance and capabilities. Normally, you enable the -a option of your FTP server in your /etc/inetd.conf file; some people run their FTP full time, in this case check out the startup files in your /etc/rc.d/rc3.d or rc5.d directory and add the option when the daemon is started up. Among the benefits of using ftpaccess is the ability to specify header and trailer messages in the directory listings generated by your FTP server. These directives, message and readme are key to our system's capabilities.
We created an HTML file within the directory structure accessible to the FTP daemon; in our case it is called 'welcome.html', this file is placed in the root directory of the FTP daemon's file area and the entry in ftpaccess looks like:
...
message /welcome.html login
...
Now the contents of welcome.html will be displayed at the beginning of directory listings. The contents of welcome.html are a little tricky if you're not familiar with javascript. They are designed to both dynamically tailor the HTML based on the position of the page within a browser. These dynamic web pages tailor the help message to the context of the display.
<HTML>
<HEAD>
<SCRIPT LANGUAGE="JavaScript">function OpenNewWindow()
{
alert("To Upload a file go to file...Upload File on the browser's button bar")
parent.frames[2].location.protocol = "ftp:"
window.open(parent.frames[2].location.href)
}</SCRIPT>
</HEAD
<BODY bgcolor="#FFFFFF">
<FORM>
<SCRIPT LANGUAGE="JavaScript">
if (self!=top) {
document.write('<i><B>Hi!</b></i>' + "You can preview, download files or search for information here.<p>You can also upload a file<br>" + '<FORM>' +
'<CENTER>' + '<INPUT TYPE="button" Value="Upload File" onClick="OpenNewWindow()
">' + '</CENTER>' + '</FORM>');
}
else
{
document.write('<i><B>Hi!</b></i> This is a special screen for adding information to hallways.<p> To Upload a file, go to FILE | Upload, like <a href="http://webserver/access_directory/file_upload.gif">
this</a>
<p>');
}
</SCRIPT>
</FORM>
</BODY>
</HTML>
This interface is not the first one we tried. I really wanted to make the system intuitive; then we'd have to spend less time answering questions and could spend more time working on new ideas. The tests we conducted showed most people knew how to download files but were not aware you could upload files or view the contents of non-HTML files. We tried HTTP uploads and downloads but settled on the combination of FTP and HTTP generated screens. We needed a design which allowed easy navigation around a complicated system and kept at least minimal help hints in front of the users all the time. The final HTTP based frame design allowed us to put together an attractive interface. Encapsulating the FTP file display simplified uploads and downloads. Unlike a web server, our FTP server labels all files as a single MIME type allowing us to use a single helper application to easily display all files.; Getting this preview function to work will require editing the association of mine types with an application on the user's computer. We use a universal viewer, you can use one of these if your network already has one installed or you might investigate one of the many plug-ins which allow viewing files within the browser itself.
The Curtain Rises
Now the majority of the work and trickery is done; all that remains is a frame based user interface, a few snazzy graphics and some help files. In a nutshell, if the FTP listing is contained within a frame then the if part of the conditional is presented. This HTML allows the user to press an "upload" button which will pop open another browser instance with the FTP directory within the root window. When welcome.html is displayed within this root window, it contains instructions on how to upload a file using the FTP capabilities of the browser. The best way to understand how the code works is of course to just load it up and experiment.This isn't a tutorial on HTML so I'll just let you know you can download this whole package (minus a few of the graphics we used in our user interface) from ftp://www.disa.mil/pub/linux_gazette_stuff.tgz. We can't redistribute some of the graphics we use but you can just draw up your own and stick them into HTML code.
During your review of the code you may notice that our frame definition document distributes this system across several machines; for us this is an important feature. We make use of local proxy servers for FTP and HTTP traffic. These proxy servers keep down the loading of our backbone. Our system is distributed such that the web server documents and graphics will be served from a local departmental web server while the FTP server distributes information from another, centralized location. Since the proxy and web are local to our subnet documents stored on the SMB hallways area are served from the proxy (cache)- speeding up the file transfer times dramatically and reducing our wide area network traffic. We are also using the Solaris version of the Netscape Catalog Server to allow users to expediently find any document or content within a wide variety of popular Unix, MacIntosh and Windows application formats. This feature provides some much needed help to users who must retrieve one of several hundred thousand documents stored on servers spread across the globe; it was absolutely infeasible using the Microsoft Windows NT file manager search feature previously recommended by the Microsoft Windows NT operators
Applause and Royalties
You can provide many other enhancements such as browser access to multiple file system types (NFS, Appleshare, SMB, AFS, etc) and internet/intranet FTP areas are easily added. We are also working on a management add-on using PHP/FI and Postgress to present users with a fully graphical file upload facility which will also store meta data on documents such as the originator of the information, the originators e-mail address, etc. In fact I think with a little more work this system is a pretty good replacement for some the proprietary commercial document management applications that cost tens of thousands of dollars.I hope these ideas and this system will help you and your workplace out. If you have other creative examples of simple systems that help bring people working around the world together, like to here about them. Thanks for listening...
Copyright © 1997, Justin Seiferth
Published in Issue 19 of the Linux Gazette, July 1997
![[ TABLE OF CONTENTS ]](../gx/indexnew.gif)
![[ FRONT PAGE ]](../gx/homenew.gif)
