Build your own Linux server

Manek Dubash ZDNet.co.uk

Published: 22 Apr 2004

• 
• 
• 
• 
• 

Web caching

Web caching speeds up browsing for all users, and saves download volumes by storing frequently used objects so they can be delivered to users quickly from local storage. It's part of RHL and comes with a sensibly configured configuration file (/etc/squid/squid.conf -- you can recognise it as a configuration file from its .conf extension). What's more, the configuration file, although large, is well self-documented which makes the task much easier.

Access control

Squid's default settings work fine as a basic proxy and caching server, so the main issue is to define who can have access to the cache and who can't. You'll want to provide access to nodes on the local network while denying access to anyone from the outside. Assuming your LAN uses the subnet 192.168.1.0, you would do this by adding the subnet to the access control list as follows:

http_access allow 192.168.1.0/255.255.255.0

For most small addresses outside that subnet will be refused. However, making it explicit by adding:

http_access allow localhost
http_access deny all

is good practice. We also changed the default IP port of 3128 to the more memorable 8080:

http_port 8080

Performance

Improving performance is the next step. We increased the amount of memory that Squid devotes to caching objects -- the server won't have a huge amount else to do, and we've stuffed it with memory for this reason. So we changed the default cache_mem setting as follows:

cache_mem 50 MB

Then we increased the maximum size of object Squid will save in RAM to 32MB:

maximum_object_size 32768 KB

That's probably all you need to get started.

Windows server

Known as Samba, the SMB service ships free with RHL and with most Linux distributions. Firing it up using the services module then allows you to get stuck into configuring the system. The first task is to create users in Samba, which then can then be mapped onto Linux users -- there must be an equivalent Linux user account for each Samba account. You can then create Samba-specific access permissions on top of the Linux privileges.

It's convenient for each user to have a private area and a public share for all. If you're having problems creating the right access privileges in the file system, use the chmod command. This lucid description provides a good handholding guide. Note that our shares were created on a separate mechanism from the OS, which simplifies backing up.

Once that's done, Samba's graphical interface makes configuration pretty straightforward. If you want to fine-tune your access permissions though, you're best advised to edit the smb.conf file (/etc/samba/smb.conf). For instance, you can restrict access to IP addresses in your local subnet and, better still, ensure that the shares for those in one department are completely invisible to those in another. Separating out the accounts workers' shares would be a typical example.

You can also fine-tune your password strategy -- whether or not to use encryption for example, since Windows 98 machines and below don't encrypt:

encrypt passwords = yes

You can also set password complexity:

password level = 8

decide whether the machine should be the browser master:

local master = yes

and select which machine (if any) stores passwords for security purposes:

password server = betelgeuse [password server] yes

Samba is fairly simple to set up and, once up and running, can usually be left to its own devices except when users change.

• 
• 
• 
•