Amazon - Website
This is an excellent idea. It will let you use the machines that are in your closet now because they were not powerful enough to run standalone. The benefits include sharing hard drives, zipdrives, CDROMs, modem, printers, even soundcards, running programs remotely (the text or graphics mode), browsing the Internet on all computers at the same time over one phone connection. If you ever lose control of your machine, you may also be able to shut it down remotely and thus avoid possible problems--see the answer on shutting down for details.
Hardware. Your hardware must be set up properly. Your network card should have been set up during the initial RedHat installation. If you added your card later, chances are it was autodetected and configured during a subsequent bootup (by kudzu). If it wasn't, you may want to set up your network card now. If you have more than one network card on your computer, you will also need to set up the second cards manually, since Linux will autodetect only 1 network card.
Under Linux, most drivers for network cards are implemented as modules. So setting up a card manually involves just inserting the proper module with its parameters. You don't need to recompile the kernel, nor even reboot your computer (unless you have an uncommon card). To figure out what module(s) and parameters you need, you may want to consult the documentations that comes with the kernel source code:less /usr/src/linux-2.4/Documentation/networking/net-modules.txt
If needed, you can list all the modules available for your kernel using something like:
modprobe -l | more
If you need more help, see the Linux Network Administrator Guide (file/usr/share/doc/LDP/nag on your system or check http://www.tldp.org/LDP/nag/). This excellent guide is known as nag.
There are many ways of inserting a module into a kernel. For a network card, the simplest is to start, as root, netconf and specify the module name there. An alternative is to start an X-terminal, execute "su" (to make yourself a root) and then run /usr/bin/kernelcfgIn most cases, you don't have to specify the parameters (IRQ and address) for your module--the module will know what they should be. However, the parameters were a problem during my setup of two network cards on one computer--you must make sure that you don't have any hardware conflicts. A common source of problems is that the card wants to configure on IRQ 5, which is occupied by the SoundBlaster, or IRQ 3 which conflicts with the second serial port (COM2, cua1, ttyS1). Inspecting the files /proc/interrupts, /proc/ioport and reading bootup messages may help.
For example, my WD8013 card (same as SMC Elite and SMC Elite plus, according to nag) runs under IRQ 10 (set by a jumper on the card and I specified the IRQ in the kernel module setup), under the address 0x300 and uses the "WD" module. My "SMC EtherEZ" card (no jumper settings on the card) runs under IRQ 9, address 0x240 and uses "SMC EtherEZ" module. Please make sure you don't omit the leading "0x" in the address--it means "hexadecimal" and must be there else the number will be interpreted as decimal.
After the module is inserted, you may want to inspect the file /proc/modules to see if the module is indeed loaded (or run lsmod as root). The module configuration file is /etc/modules.conf so if you encounter difficulties (for example, I had difficulty removing modules inserted by mistake), just edit and adjust this file manually, e.g., using pico.
Network configuration. After setting up the network cards and connecting the cables, set up the network by running (as root):
netconf
This program has help! netconf can also be run under GUI, but I did not really try it. If you need more understanding of how networking works, you may want to read the previously mentioned nag. Also, reading this material may be of help: http://ieee.uow.edu.au/~mjp16/wylug-netlinux/notes.html.
It also contains very clear examples on how to set up a small office network that, like our home setup, has only part-time connection to the outside world.How and what to fill up in netconf depends on your network. You surely want to fill up "Basic Host Information" (enable the first ethernet interface, eth0, fill in the name, aliases and IP number of your local computer) and the "Information About Other Hosts" (names, aliases and IPs of other computers on your home network). This information goes to the files: /etc/hosts and /etc/sysconfig/network, so you may want to inspect these files and adjust them manually.
When setting up the network, don't mess up with the "loopback driver" which has the IP 127.0.0.1. It is always there--it is the IP through which the computer talks to itself.
If you don't have an IP address (as will typically be the case for a home network with no permanent connection to the outside world), you may want to invent one. It does not matter very much what it is since when connecting to the outside world by your modem, you will be dynamically allocated an IP address (a machine can have many IP addresses at the same time). Your invented IP must be formally correct and the net mask must match the class of the network (class A, B or C). See the chapter on IP addresses in the already mentioned Network Administrator Guide (nag) (/usr/doc/LPD/nag on your system, or if you don't have it, download it now from http://metalab.unc.edu/mdw/index.html#guide.
For a home network, you might want to invent a class C network (up to 254 machines, the smallest) IP number which has the first three digits between 192 to 223. The last three digits identify the machine on your class C network and must be between 1 and 254 (don't use 0, it means "whole network" or 255 which is the "broadcast address"). The middle two sets of digits can be anything from 0 to 255. Thus 223.223.223.1 is the first machine on the class C network 223.223.223.0 (the last zero signifies the whole network), with the broadcast address 223.223.223.255. The network mask for a class C network is always 255.255.255.0 (unless you subdivide your network into smaller "subnet", which is not discussed here).Rather than completely inventing an IP number, it might be safer/better to use one of the numbers reserved for "private networks". For me, the IP number 192.168.1.1 works just fine. This way, your "invented" IP address is guaranteed never to interfere with any IP that may exist in the world.
Typically, the first machine on a network is the one that is expected to have the connection to the outside world (since it was connected first, but there is no standard for that). So, I filled up the GATEWAY to xxx.xxx.xxx.1 (my first machine) on all machines, except for the machine xxx.xxx.xxx.1, where I left this field blank. Actually, although I left the field blank, netconf inserted the gateway 0.0.0.0 into the /etc/sysconf file. This was a source of an annoying error message during the loading of the network card on the bootup. To get rid of the message, I edited /etc/sysconfig/network and set it to something like this:
GATEWAYDEV=
GATEWAY=
[You don't want a gateway on your ethernet interface on this machine if it does not lead to the outside world. The ppp interface on this first machine will be set up as a default gateway once you connect through your modem, e.g. using kppp.]
The name of a computer is entirely arbitrary--the main user normally chooses a short word s/he likes. The domain name of the home network is also entirely arbitrary, unless you have a permanent connection in which case a domain name is registered to you. Try to invent something that does not exist yet--it could make your life easier once you have a permanent connection.
As for the DNS (domain name server, also called "named" = name daemon), RedHat 5.2 and 6.0 comes with DNS preinstalled as "caching-only" so it is easy to configure as such. You may also choose not to use local DNS at all--if your local DNS is looking up an "outside" server and can't find it, it can be a real show-stopper (the machine can appear to be hanged for up to a few minutes). To use local DNS, the "named" service must be enabled-- check this by running setup. To set up the caching-only DNS, fill up the appropriate boxes in netconf. E.g., I filled "nameserver 1" to my first machine on all computers (I entered the loopback address 127.0.0.1 on the machine xxx.xxx.xxx.1, and the proper xxx.xxx.xxx.1 address on all other machines).
No routes to other networks and hosts were required in my network, since I don't have other local networks. So I left this field blank.
Other than setting up the hardware correctly and filling up the info under netconf on each computer, as described above, I did not have to do anything on the standard RedHat to get my network working.
Reboot all computers one by one in any order (this is not necessary, but won't hurt you) and watch the boot messages (if they scroll too fast off screen, use <Shift><PgUp> to scroll up, or use dmesg from the command line to view them later). Did your cards configure correctly? Use the command route (as root) to see if the eth0 interface is running. Use the ping command to test the connections between individual machines. Try to telnet your local computer to see it the loopback-only (lo) interface works:
telnet name_of_the_machine_you_are_sitting_at
After a successful login, you can exit the telnet session by typing
exit
Finally, try to telnet another computer on your network:
telnet name_of_a_remote_machine
If this works on all machines, your eth0 network interface is set up.
After setting up your ppp and connecting to your Internet Service Provider (ISP), you will have another network interface (ppp0) and then will be able to telnet any machine in the world.
GUI. If I were you, I would install kde and use kppp. kppp is really easy to configure and run. To set up your ppp dial out, run kppp (it is under the "K" menu "Internet, or you can run it from the xterm by typing kppp), press the "setup" button, create an account, and fill out the information required: telephone number, authentication protocol, and your Internet Service Provider's (ISP) domain name and the Domain Name Server (DNS) number of your ISP. All this information should have been provided to you by your ISP.
Next, I check if a device called /dev/modem exists and points to the right port. If necessary, I create it by symbolically linking it to the device /dev/ttyS1 (as root):
ls -l /dev/modem
ln -s /dev/ttyS1 /dev/modem
ttyS1 should work if your modem is on the port that DOS calls COM2. Use ttyS0 for COM1 and ttyS2 for COM3 and ttyS3 for COM4. The modem will not dial at all if a wrong port is chosen. For non-standard serial port setups, see the command setserial.
With old versions of kppp, you may get an error message complaining about a "lock". The solution then is to make sure that the file /etc/ppp/options is empty by editing it (as root):
pico /etc/ppp/options
and deleting the word "lock", then saving the file. This problem does not exist in the more recent versions of kppp.
RedHat 6.0 required one additional step: setting the "suid" ("substitute user id") so that "kppp" runs with the effective user id of root (because it needs to access hardware directly). Without it, kppp complains that "it was not properly set up" and "can't create lock file". This has to be done as root:
cd /usr/bin/
chmod a+s kppp
Troubleshooting. If your modem refuses to dial on the port that you are positive is chosen properly, maybe the modem is not set up properly (or maybe it is a "winmodem"? Then throw it away and buy a proper modem).For example, in one instance, I had to run kppp setup, edit the "modem commands" and input ATZ1 as the "initialization string" (instead of the default ATZ for a standard Hayes-compatible modem). Otherwise, this particular modem would not dial.
If your telephone line requires pulse dialing (instead of the default touch-tone dialing), you may need to change the modem dialup command from "ATDT" (="ATtantion Dial Touchtone") to "ATDP" (="ATtantion Dial Pulse"). These commands work with any standard Hayes-compatible modem.
If your modem dials correctly and you are able to connect, but your authentication fails, perhaps your Internet Service Provider (ISP) uses a different authentication protocol. Call them and ask what authentication protocol they use. Or try "pap", "terminal-based" or "chap" (in your kppp setup) until you find the one which works with your ISP.
In one instance, I had a problem with the reliability of establishing a connection (the error would pop up saying something like: "time-out for the pppd startup", and the connection would establish only once every few trials). The problem was solved by changing the "flow control" option (in the kppp "setup" under "device") from "CRTSCTS" to XON/XOFF. (Still CRTSCTS is the recommended flow control method in most cases.)Random disconnects (after some time of correct connection) can have many causes. (1) They may be caused by "glitchy" drops of "data terminal ready" (DTR) signal or "carrier" signal. e.g., due to a noisy line. Most modems respond to that by hanging up. To change this default behaviour, you may need to add to your "modem initialization string" something like S10=50 . This sets the duration of DTR loss (in 0.01 s) after which hangup is executed (check your modem manual, "US Robotics" modems may need something like S25=200). (2) Call-waiting feature on your phone line may disconnect you when somebody tries to call you. (3) Old phone cables and dirty or corroded phone plugs or sockets are a common source of problems. Check the connections, replace the cables. Run the cables further away from sources of great electrical noise. (4) Too high modem speed for your village long and noisy phone cables. Drop the modem speed (or move to a city). (5) Many ISPs will diconnect you after some period of inactivity (30 min?).
If you keep having problems setting up ppp, you may want to try minicom to see if you can get your modem working from there. minicom is something like PROCOMM for Linux. It should be present on your system if you chose to install it during your RedHat initial setup. Here is a post from a newsgroup comp.os.linux.help which explains how to start ppp manually using minicom (edited for space):
From: mark <balthazaar@one.net.au> Subject: Re: pppd problem with kppp
BachuZ wrote:
>>Also, for an experiment, try using minicom to connect to your ISP, start ppp manually ... this can prove buggy scripts. >how would u do that?
Easy!! If your ISP doesn't allow a manual logon then you might be in trouble. Every ISP I've ever used does allow this, so.. 1. Start minicom. 2. dial your ISP. 3. Log in. 4. AFter your ISP starts PPP, quit minicom with ALT-Q (or whatever the sequence is to 'quit without reset'). 5. start pppd, eg:
pppd -d -detach /dev/modem 115200 &
OK, PPP will be running. Try pinging your ISP or another known IP address. That will test everything is OK. BTW, this is all in the PPP-HOWTO. If you can get PPP running this way, then you have a scripting problem. If PPP doesn't work, you have a PPP configuration problem. Cheers.
Command line. If you would like to start your ppp from the command line, run netconf (as root) to configure your first ppp interface (ppp0). The information you must enter is similar to what you entered when setting up kppp (have a look above!): the proper device for the modem port, modem initialization and dialup strings, the telephone number of your Internet Service Provider (ISP), the proper authentication protocol (by entering the login name and password into the right slot). In older versions, the netconf utility lacked a place to enter the IP addresses of my ISP DNS server, so I edited the file /etc/ppp/pap-secrets (I use PAP authentication protocol) and added the two DNS IP addresses at the end of the setup line which was created by netconf so it looked like this:
# added by linuxconf
my_login_name ppp0 my_password 111.111.111.111 222.222.222.222
When done with the settings, I could start my ppp0 interface using the command (as root, unless I specified in netconf that normal users can start the interface):
ifup ppp0
and shut it down with
ifdown ppp0
Setting up the command line ppp was not more difficult on my machine than running kppp and the connection is more reliable for me. There is lots of command line scripts to start/stop ppp, but they apparently are not so easy to set up and use, and many newbies seem to have problems with them. Badly misfired ppp connections can be killed without rebooting using (as root):killall pppd
If this minimalistic setup of ppp does not work for you, here are some useful links:
Roderick A. Anderson < raanders@altoplanos.net > wrote:
I have a web page on setting up diald to work with RedHat Linux 5.x that works for me every time. It is at http://home.altoplanos.net/~raanders/diald.html
Bill Unruh < unruh@physics.ubc.ca > wrote:
I just wanted to bring your attention to the page http://axion.physics.ubc.ca/ppp-linux.html for detailed instructions for setting up ppp. This is especially for cases in which the remote side uses (perhaps without the ISP even telling you) PAP or CHAP. While kppp is useful, there are a number of situations where it can fail.
Another computer on your network must have a modem (or another Internet connection) though :-). Set up IP masquerading. This way, all requests going from your network to your Internet Service Provider (ISP) appear to have originated from a single computer, and your ISP will let them through.ON REDHAT 5.2, simple masquerading required just one command (on the computer with the modem):
/sbin/ipfwadm -F -p m
This sets up masquerading as your default forwarding policy of your IP firewall, and therefore is insecure but probably ok for a home user. (The danger is that if somebody hacked your computer, s/he can use it as an annonymous forwarder to hide his identity. Whatever malicious the hacker does to anybody, you take the blame. The hacker can even set his route to "tunnel" back to your network thus concealing his identity from you.) For more info, please check the file /usr/doc/HOWTO/mini/IP-Masquerade. A more secure setup is shown here:
ipfwadm -F -p deny
ipfwadm -F -a m -S 192.168.1.1/32 -D 0.0.0.0/0
ipfwadm -F -a m -S 192.168.1.3/32 -D 0.0.0.0/0
ipfwadm -F -a m -S 192.168.2.0/24 -D 0.0.0.0/0
This sets up the default policy to "deny" and explicitly masquerades two machines with IPs 192.168.1.1 and 192.168.1.3. It also masquerades any machine from the network 192.168.2.0. The number /32 stands for point-to-point networking (this means "machine-to-machine"), the option /24 identifies a class C network. The -D 0.0.0.0/0 identifies the default route that the machines to be masqueraded use to go out to the Internet.
ON REDHAT 6.0 THE NAME OF THE COMMAND is ipfwadm-wrapper (instead of ipfwadm) and I had to use the second, more secure method (setting up masquerading as the default policy does not seem to work on my system any more). Also, with newer kernels (2.0.34 and later) forwarding is disabled by default and must be turned on using:echo "1" > /proc/sys/net/ipv4/ip_forward
Actually, ipfwadm-wrapper is a wrapper because it lets me use the old rules of setting up the firewall policies using the brand new firewalling kernel code. Doing something like this may work better for you:
ipchains -P forward DENY
ipchains -A forward -s 192.168.1.0/24 -j MASQ
If you would like to have this command(s) always executed on your system startup, add it as the last line(s) to the file /etc/rc.d/rc.local . This file is something like AUTOEXEC.BAT in DOS. As always, it is recommended to read the manual page and other documentation to see what the command(s) does and what are the other options:
less /usr/doc/HOWTO/mini/IP-Masquerade
man ipfwadm
man ipchainsON REDHAT 7.1 (KERNEL 2.4.x) the firewalling can be set up using the new iptables command. You can still use the old ipchains, provided you don't run iptables at the same time. So perhaps use ntsysv to make sure ipchains is enabled, and iptables is disabled.
Samba (smb) is for Linux-MS Windows networking. It is a program that makes a Linux computer pretend to be a MS Windows NT server, and thus lets your MS Windows 3.1/95/98-based computers connect to the network. Samba not only replaces WinNT--it is acclaimed to do a much better job than WinNT!
One of the three machines on my home network is a dual Linux/Win95 boot. I configured my network so that if I boot Win95, another Linux machine acts as a Samba server. This way, the Win95 machine has access to the network printer, shared directories on Linux, can telnet, browse the Internet through a modem on Linux, etc. I can also access the files on the remote Win95 machine from Linux computers.
It is necessary to configure Samba only on one Linux machine.
First, I ran setup as root, choose "System Services" (RH6.0) or "ntsysv" (RH5.2) from the menu, and make sure that the "smb" service is enabled. (The program setup has help if you press F1. Just in case you were curious what the different services are for.) If smb is not listed there, maybe you did not install it during your RedHat setup? You may want to put your RedHat CD into the CDROM, mount the CD, start glint (RH5.2) or gnorpm (RH6.0) installation utility (as root) and add Samba to your system.
The second part is to configure Samba. This is relatively simple since the Samba configuration is done through a single, well commented file: /etc/smb.config . The minimum setup includes specifying the workgroup name. Note that if you don't fill up the "host allow" option, all hosts are allowed, which is probably ok for the home network. The other options in the example /etc/smb.conf supplied with your RedHat CD may require adjustment to suit your particular needs, but they didn't have to be changed to get a Windows machine connected to my Samba server.
Check that the options
domain master = yes
domain logons = yes
are enabled in /etc/smb.conf. You probably want them.
Under RH6.0, you may also perform a basic samba setup using (as root):
netconf
The third step is to configure your MS Windows 95 (or whatever) for networking. This is done exactly as if you were connecting to a WinNT server. Make sure to enable the networking ("client for Microsoft Network") and fill up the workgroup name. To login on the network when booting MS Windows, use your Linux user ID and password. To see if it worked, click on the icon "Network Neighborhood"--your Linux server should be listed there, and underneath you should see the shared directories and printers that you chose to share in the file /etc/smb.conf.
If you can't see or use the public directories, make sure that you created them and set the proper read/write permissions for all users.
MS Windows 95b and above (95c, 98, and newer NTs) may use password encryption. This will make your logins from the Window's machine fail, and you may need to enable this option in the /etc/smb.conf file:
encrypt passwords = yes
On the Linux server, you can start, stop, restart and check the Samba status using these commands (as root):
samba start
samba status
samba restart
samba stop
You need to re-start samba after making changes to your /etc/smb.conf file.
You can browse the net using your Netscape for Windows if you are connected to your Linux computer through Samba and the Linux machine is currently connected to the Internet. To do this, the IP masquerading must be set up on the Linux machine with the modem (described here) and you must enable the Samba dns name resolution in /etc/smb.conf :
dns proxy = yes
and then tell Windows to enable the dns server, specify the Linux server name and IP address (in ControlPanel-Network-TCP/IP).
You can also mount a remote Windows directory onto your Linux filesystem. Look here to see how.
The above described just a minimal Samba setup. You can get more information from:
man samba; man smb.conf; man smbclient; man smbmount
less /usr/doc/HOWTO/SMB-HOWTO (under RH5.2)
documentation in /usr/doc/samba-2.0.3/doc (under RH6.0)
http://www.sfu.ca/~yzhang/linux/samba/ (samba minihowto)
http://www.germanynet.de/teilnehmer/101,69082/samba.html
and also by studying the file /etc/smb.conf .
Sendmail is the Internet standard mail-transport system and the default mail-transport on RedHat Linux (Mandrake uses PostFix instead). As a user, you don't use sendmail directly--sendmail is the underlying server engine that manages the mail on your machine in the background, for all users.
To read/send mail in the text mode, you probably want to use pine or elm (choose one and stay with it--it can be inconvenient to manage two separate mail boxes). In KDE, you may choose to use the "mail client"(kmail) available from the K-menu. To communicate with the outside world through your ppp dial-out, you probably would like to use the mailer that is built into your Mozilla/Netscape and which communicates directly with your remote Internet-Service-Provider-based mailbox (bypassing the mail server facility on your local computer). Another popular mail client is Evolution.
Sendmail is very powerful, flexible and robust mail server. It is also notoriously difficult to manage if you needed to customize it to your specific needs. Luckily, Red Hat (5.2 or 6.x) comes with the sendmail that runs out-of-box (with some limitations though) and I can easily send email from one user to another on my internal network.
On my home system (default Red Hat setup), I can send mail to another user on the same machine with no problem (e.g. using pine). I can send mail locally or anywhere in the world from any mailer once I am connected to my Internet Service Provider through the modem (IP masquerading enabled). But when I am not connected, the mail sits in the queue and waits for the Internet connection, even if the mail is to be sent to another computer on my home network (a minor annoyance). It gets sent once I connect. (It happens because sendmail is trying to do a DNS lookup and this is not available on my system--RedHat default DNS is cache-only.) If you really want to avoid this on RH6.x, you may use netconf (as root) and specify that sendmail is not to use DNS at all (Linuxconf that comes with RH5.2 does not give you the choice). I do use DNS. Alternatively, I could run a DNS server on my local network.
Under RedHat 6.x, you may also want to use netconf to configure other sendmail options using (as root). I entered the name of my Internet Service Provider and the names of other machines on my home network under "mail deliver system"-"relay to hosts". I also added the names of my home network machines under "relay for by name".
You should also be aware of the limitation of your simple setup that arises if you send e-mail from your home network (for example using pine), to the world beyond your network. If you invented the IP address and your domain name is unregistered, there is no chance you will receive a reply. Your outgoing mail is given a "reply" address in the form: "user_login_name@machine.domain". This is NOT ok since your domain name does not exist, according to any DNS in the outside world, hence no way for any reply to ever get to you. To overcome this, you may use the Netscape mailer to communicate to the outside of your home network. Netscape uses the settings you enter in its "edit-preferences" to communicate directly to your ISP-based mailbox (which resides on a registered server of your ISP) and thus bypasses your unregistered-home-network-based e-mail system. Another possibility is to specify the correct address in the "reply to" field. If you do it in Netscape, you can setup your NetscapeMail to use your local Linux computer as the mail server, and this way be able to send e-mail from your NetscapeMail also to the computers on your home network (not only in the "outside world"). The option "reply-to" can also be set in the KDE "mail client" setting, if you use the KDE mailer. Also in "pine" you can specify the reply-to address under "setup-configure", "customized-hdrs" with something like:
Reply-to: joe@joe_net.net
where "joe@joe_net.net" is your good reply-to e-mail address.If you do wish to fetch your mail from your Internet provider-based mailbox onto your account without the help of Netscape, you may consider installing fetchmail (see man fetchmail).
Please note that it is important to keep your mail server up-to-date with security if the mail server is visible from the outside world. Reason: junk mail is typically sent through mail servers which are cracked into because they were mis-maintained. If you do not need a mail server (on a workstation, you don't)--shut down the service entirely or else you risk that one day thousands of people will receive spam mail that looks like originating from your server.
To set up a simple apache web server was extremely easy under RedHat 6.0. First of all, I made sure to install the apache web server rpm package during my RedHat installation. If you didn't do it, you can put the RH CD in your CDROM now, mount it, and install the package apache-*.rpm (instead of the "*" the name also contains the version number and the platform). If I know what I want to install, it is simple do it (as root):
cd /mnt/cdrom/RedHat/RPMS
rpm -ivh apache*.rpm
Then, I run "setup" (as root) and make sure that the httpd daemon (under "system services") is enabled. [A daemon is a program that sits in the background and wakes up when it is needed. In the case of httpd, it gets awakened when somebody calls on your http server.]
Now, the httpd will start automatically every time I boot the computer. I can also start it manually using (as root):
/etc/rc.d/init.d/httpd start
and shut it down using:
/etc/rc.d/init.d/httpd stop
I should already have the directory: /home/httpd (check if it exists), and under it, the subdirectory html--this is the "root directory" for people accessing my computer from the web ( "their root directory" means that they will not be able to access any directories above the directory /home/httpd/html/ on your system). On default, this directory contains some html files and manual that the apache installation program put there. So I should now be able to connect to my web server from another machine on my home network. For example I would type on the Netscape "Location" line:
http://my_http_server_name
and be able to browse the "apache" manual.
To put my own content on my web server, I move the "apache" sample files somewhere else, and copy or link my html files (the ones which I want to display to the public) to the directory /home/httpd/html/ (don't forget to include the the file index.htmll , this is the one that appears first when somebody connects to your server).
The apache configuration files and log files are in the directory /etc/html/ if you wanted to view/customize them. The log file can be viewed in "real time" using this simple command (as root):
tail -f /etc/httpd/logs/access_log
[The tail command normally displays the end ("tail") of a text file. With the option "-f", "tail" keeps displaying the end of the log file as it grows--really handy to monitor the log file and see who logs onto your server.]
For graphical setup of the Apache server, try this (in an X-window, as root, if you installed "Comanche" from your RedHat CD):
comanche
We do not recommend setting plain ftp servers other then on internal network, behind a firewall, and invisible from the outside world. FTP is insecure in that the login information (the user name and password) travels in plain-text through the network and can be intercepted on an in-between server. Now, imagine a malicious individual administring the server on your internet provider. He probably has a nice tool scanning all the passing-through traffic for the strings which normally accompany login activities. He automatically logs those and after some time has an impressive collection of user IDs and passwords to all kinds of places. Lets hope your important login information does NOT fall into his possession. (Well, this administrator can also read your telnet connection and traffic, and any other un-encrypted communication, including emails, icq traffic, etc. Ftp is not alone in its lack of security).
There are telnet and ftp replacements that use encryption for sending all the data over the network and I use ssh whenver possible when talking through the public Internet. The encryption tools are also built into your web browser (e.g., Mozilla) and it is important to pay attention that your sensitive data (login info, credit card billing, etc) is send only to locations that support secure, encrypted connections.
With older my RedHat Linux distribution (RH<7.1), setting up an ftp server could not be simpler--it just worked out-of-box. This is because the ftp service was enabled on default as one of the standard services (as is telnet and gopher), in the file /etc/inetd.conf. Here is the relevant part of my /etc/inted.conf:
ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd -l -a
telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
gopher stream tcp nowait root /usr/sbin/tcpd gn
The second part of my ftp server setup is in the file /etc/passwd which defines the ftp account:
ftp:*:14:50:FTP User:/home/ftp:
The ":" is a field separator. The first field is the account (user) name "ftp", the "*" in the second field indicates that the password is disabled (nobody can login under the "ftp" user name), the user id is 14, group id is 50, "FTP User" is a comment, the home directory is /home/ftp, the last field is empty (for "normal" user accounts, it specifies the name of the shell for the user).
Because this setup was already done for me by RedHat, anybody can ftp my computer and either login as a user (will be prompted for password and directed to his/her home directory), or login as "anonymous" and give his/her e-mail address as a password. Any user can also enter something like this on the Netscape "location" line:
ftp://my_computer_name
and connect automatically (Netscape will take care of sending the "anonymous" user name and the e-mail address as password).
The "anonymous" ftp users are directed to the directory /home/ftp , which appears to be a root directory to them (they cannot access any directory above it). I put the files I want to serve in the subdirectory /home/ftp/pub .
The directory /home/ftp/bin contains the commands that the remote users are able to execute. On my system these are: compress,cpio,gzip,ls,sh,tar,zcat; all with execute-only (111) permissions.
The directory /home/ftp/etc contains the setup files necessary for the anonymous account to function (edited passwd,group,ld.so.cache). The directory /home/ftp/lib contains the libraries (I guess these libraries are used by the commands that the anonymous ftp users are allowed to run).Red Hat 7.1 uses xinetd in place of the older inetd, and most of the network services are disabled on default. If you cannot telnet to yourself or another network service you need is disabled, you may want to inspect the files in the directory /etc/xinetd.d, and edit the file with the name of the service, so that it contains: disable = no . This is for for security reasons--you have to choose the services you need and enbable just those. Don't enable ftp unless you require it--ftp used to have quite a few security glitches in the past. If you enable network services, make sure you conservatively setup the files /etc/hosts.allow and /etc/host.deny for security.
Example file /etc/xinetd.d/tpfp showing the service disabled:
service tftp
{
disable = yes
socket_type = dgram
protocol = udp
wait = yes
user = root
server = /usr/sbin/in.tftpd
server_args = -s /tftpboot
}
If you don't have this file, do cat to see what services you installed. The daemon for most services will start automatically on system startup if this startup is enabled using command setup (as root).
The only difficulty is that your IP address is dynamically allocated to you by your Internet Service Provider (ISP) from their IP address pool, and therefore the IP address is not the same every time you connect (unless you made specific arrangements with your ISP). To telnet, ftp, or access your web pages (served by your appache web server) from the outside world, one has to know your current IP address. To find out my current IP address, I use this "interface configuration" command which, when run without any parameters, just displays info on all active network interfaces present on your machine:
/sbin/ifconfig
On my machine this displays three paragraphs of information on: eth0 (the first ethernet network interface that leads to other computers on my home network), lo (the loopback-only interface, the one with IP 127.0.0.1, this one must be present on every machine), and ppp0 (the first point-to-point protocol interface). My current IP address, assigned to me by my ISP, is displayed under the ppp0 heading. (Your Linux machine can have multiple IP addresses assigned at the same time, so if you have a "static" IP that you use on your home network, it is still valid but visible only on your home network.)
Once I know the IP address, I can send it through ICQ or e-mail to a friend, who can then, for example, telnet or ftp my computer (s/he must have an account on my machine) and run a program on my linux machine, or enter http://my_ip_address on the "location" line in the browser to browse my home web pages, etc. If the friend has Xwindows on his/her local machine, s/he can even run a GUI program on a my server and direct the display on his computer.I can also write a short script that will automatically notify my friend when I am connecting to the Internet and enter the name of the script under kppp-setup-account-edit-dial-"execute program upon connect". Here is my script which notifies me at work when somebody in my house is going on-line (I entered the text into a text file and made the file executable using chmod o+x file_name) :
#!/bin/bash
sleep 15
/sbin/ifconfig | mail -s notification my_email_address
The first line of this script tells my computer to interpret this text file as a bash shell script. The second line makes the script wait 15 seconds (just to make sure that the e-mail is not sent before the ppp connection is fully established). The third line executes the ifconfig command and pipes the output to the mail utility that sends it to my_email_address under the subject "notification".
A more flexible way to access your home computer remotely is to configure it as a dial-up ppp server (as opposed to the dial-in client that you use when you connect to your ISP). If somebody has a simple recipe how to do it, please drop a line.To summarize, unlike MS Windows 3.x/95/98 which severely restricts traffic to your computer, Linux is very network oriented and it is easy to make all kinds of network connections both FROM and TO your Linux computer. The powerful networking features are generally considered a Linux a strength but, from a real newbie point of view, they can be a problem (see the next question).
Unfortunately, this is perfectly possible and attempts to do so are quite common. Every time you are connected to your Internet Service Provider (ISP) you are at risk. Read the previous answer if you would like to know how it is possible. Obviously, the risk is much higher if you have a permanent Internet connection (e.g. cable modem), and it is lower if your connections are more transient (as typical with short-duration, over-the phone modem connections).
The real danger is that the intruder, if s/he is able to login onto your machine on any account, may find (may know of) a "local security exploit" and get root access. This is particularly possible if you are a real newbie administrator and/or your machine is not really security oriented (you are at home, aren't you--who would care about security, you think!).
To protect yourself, just never let a stranger log onto your computer. Have fairly long passwords that contain both numbers and letters for all accounts on your computer. Change the passwords occasionally. The best way to enforce the password policies on all users of your computer is to run (as root, available in RedHat) linuxconf and under "password and account policies" change the minimum password length to 6 or more characters, the minimum number of non-alpha characters (i.e., not-letters) to 1 or 2, the number of days after which the password must be changed to something like 90 or less, and set a warning about password expiry to something like 7 days before the expiration. Check here (FAQ2.htm#pass_security) for more info on weak passwords. Absolutely NEVER create an account with no password, or with a silly weak password. Do not habitually work on your computer as "root"--if you run a program with a known "security hole" as root, somebody may find a way to hack you. Older Linux distribution have known security holes, so use an updated version if you let untrusted people log onto your computer, or if you run "server side" network services (e.g., ftp or http server).
It is also an excellent idea to occasionally screen the files that contain a record of all the logins onto your computer: /var/log/secure (the most recent log) /var/log/secure.1 (older log) /var/log/secure.2 (yet older log), etc. There are also other useful log files in the directory /var/log that you might want to view, check them out from time to time. The most typical "warning" sign is a scanning of the ports on your computer: there are repeated entries on connection request from the same IP number to your system telnet, ftp, finger and other ports--somebody tried to learn more about your system.
If you never use remote connections to your home Linux machine, it is an excellent idea to restrict the rights to use the "server side" network services (all the network services are listed in the file /etc/inetd.conf) to the machines on your home network. The access is controlled by two files:/etc/hosts.allow and /etc/hosts.deny . These access-control files work as follows. When an outside connection is requested, the file /etc/host.allow is scanned first and if the name of the machine from which the connection is requested is matched, the access is granted (irrespectively of any entry in /etc/host.deny ). Otherwise, the file /etc/host.deny is scanned, and if the name of the machine from which the connection is requested is matched, the connection is closed. If no matches are found in either file, the permission is granted.
B. Staehle (a Linux modem guru) wrote to me to advice not to install network services at all. "If your network services are not configured properly, you may wind up with your computer owned by some script kiddie. A newbie should _never_ be allowing services (ftp, telnet, www) to the world. If you "must" install these, make sure to only permit connections from systems you control. The file /etc/hosts.deny should containGo to Part: 5 - Linux Shortcuts and CommandsALL: ALL
and /etc/hosts.allow should only have
ALL: 127.0.0.1
to permit connections only from that named host. Do NOT use hostnames! " <end of Bill advice>.
Indeed, my /etc/host.deny is exactly as adviced above (ALL: ALL), but my /etc/hosts.allow two extra trusted computers to connect to all my network services, and another computer to access telent and ftp: (the IP numbers are fake):
ALL: 127.0.0.1, 100.200.0.255, 100.200.69.1
in.telnetd, in.ftpd: 100.200.0.2In the examples above "ALL: ALL" stands for "ALL services, ALL Hosts", meaning "connections to any local network service" coming from "any host".
For more info, check the excellent "Linux Network Administrator Guide" which is surely present on your RedHat (or whatever) distribution CD. I printed this book and had it hardcovered.
To verify which services your computer offers to the outside world, you may want to use a web-based tool. Go to: http://scan.sygatetech.com/ and click on "scan now".
Here are some other places that may be able to scan you: http://crypto.yashy.com/ http://davidovv2.homestead.com/freetoolsservices.html http://privacy.net/ http://scan.sygatetech.com/ http://security1.norton.com/us/intro.asp http://suicide.netfarmers.net/ http://trojanscanner.com/cgi-bin/nph-portscanner http://www.doshelp.com/dostest.htm http://www.dslreports.com/secureme/ http://www.dslreports.com http://www.earthlink.net/freescan/ http://www.grc.com http://www.hackerwhacker.com/ http://www.nessus.org http://www.netcop.com/newscan/fullscan.html http://www.privacyscan.org http://www.sdesign.com/cgi-bin/fwtest.cgi http://www.sdesign.com/securitytest/index.htmll http://www.securityspace.com/ http://www.vulnerabilities.org/nmapemail.html http://grc.com http://www.dslreports.com/scan http://www.dslreports.com/security/sec025.htmFor security reasons, it is also a good idea not to advertise the OS/version that you use. I replaced the contents of the file /etc/issue and /etc/issue.net which on my computer read:Red Hat Linux release 6.2 (Zoot)
Kernel 2.2.14-5.0 on an i586with something like this:
WARNING: THIS IS A PRIVATE NETWORK
UNAUTHORIZED USE IS PROHIBITED AND ALL ACTIVITIES ARE LOGGED
IBM S/390 LINUXThis blends a joke with a little bit more security (I hope).
The contents of the files /etc/issue and /etc/issue.net are recreated at every reboot (when the script /etc/rc.local is run). So, to make the changes permanent, I can make these files read-only for all users (as root):
chmod a=r /etc/issue*
Instead of the last command, I could have edited (as root), the script /etc/rc.d/rc.local and commented out 5 lines with ### so that the relevant part reads:
# This will overwrite /etc/issue at every boot. So, make any changes
# want to make to /etc/issue here or you will lose them when you reboot
### echo "" > /etc/issue
### echo "$R" >> /etc/issue
### echo "Kernel $(uname -r) on $a $SMP$(uname -m)" >> /etc/issue
### cp -f /etc/issue /etc/issue.net
### echo >> /etc/issueAnother good security measure is to disable ping. Ping is a sonar-like response that your computer sends back when inquired by another computer. It is mostly useful for setup and debugging, to probe whether your machine is available on the network. It can also be used for probing your machine and/or attacking it by flooding with ping requests ("ping of death"). To disable my machine response to pingging from the net, I use the IP masquarading. I took and slightly modified the following command and explanation from http://www.securityfocus.com/focus/linux/articles/linux-securing2.html:
ipchains -A input -p icmp --icmp-type echo-request -i ppp0 -j REJECT -l
(1) (2) (3) (4) (5) (6) (7)
The ipchains flags explained:
1. (A)ppend a new rule.
2. The chain to apply the rule to, in this case the rule will apply to ingress (input) packets.
3. (P)rotocol to apply the rule to. In this case, it is icmp.
4. ICMP type, in this case all icmp echo requests will be blocked. "ICMP echo" means ping.
5. Interface name. In this case, it is the first over-the-phone connection, ppp0.
6. Target, or what should actually be done with the packet in question.
7. Log all packets matching the rules criteria to system log file.IP masquarading was described in more detail in the chapter on masquerading of this Guide.
Another security precaution I take. I occassionally check if somebody hasn't installed a "root kit" on my system. I use the utility "chkrootkit" (very small, 25k, download from http://www.chkrootkit.org/). After downloading the tarball do:
su [provide password]
cd /usr/local
tar xvzf /home/my_name/chkrootkit.tar.gz
cd /usr/local/chkro<tab>
make
./chrootkitThe last command actually runs the search for a rootkit on my system. "Rootkit" is a software hidden backdoor that somebody who gained once access to your system (as "root") could install in order to listen, monitor, protect her access, etc.