LINUX

MAKING IT WORK FOR YOU







January 7 & 9, 1997



Revised 1/5/96

WHAT IS LINUX?

	A free operating system for Intel processors 
(and other platforms)

	A platform similar to the operating systems on 
Athena workstations.

	A way of turning your Intel machine into an 
Athena workstation

	A POSIX-compliant development platform

	A way of using your network to its full 
potential

Linux was written by Linus Torvalds and many 
contributors on the Internet.  Unlike most 
software systems,  the development of Linux is 
open and distributed, so many people contribute 
to its improvement and stability.



LINUX FEATURES



	Multitasking	

	Multiple users

	Demand-paged executables	

	Paged virtual memory	

	Adaptive disk cache

	Dynamically linked shared libraries

	Core dumps for debugging

	POSIX, System V, BSD source-level compatibility

	SCO, SVR3, SVR4 binary compatibility (mostly)		

	International keyboard support	

	TCP/IP networking

	Multiple virtual consoles	

	Multiple filesystems, including DOS, VFAT, NTFS

	Can be installed on a DOS filesystem

WHAT DOES LINUX REQUIRE?

Linux will run on any Intel x86 processor from 
386 upwards. It requires 4MB of memory to run 
reasonably, 8MB if you want to use X Windows 
or AFS.  Linux and X will run significantly 
faster with 16MB or 32MB of memory.

You also need a hard drive with at least 150 to 
200 MB free for the distribution files and swap 
space.

Versions of Linux are available for other 
processors including Sparc and PowerPC, but 
they are not as well supported as the Intel 
version.

WHAT IS A LINUX 
DISTRIBUTION?

Linux by itself is just the kernel of an operating 
system.  A Linux distribution combines the 
kernel with the basic C libraries and system 
programs to give you a complete operating 
system.  Most Linux distributions also include 
development tools and applications as optional 
packages.  The X Window System is also a part 
of most Linux distributions.

The SIPB supports the RedHat Linux 
distribution. It is a complete system that 
provides everything necessary for a fully 
functional Linux workstation. It also has a 
thorough user's manual and an easy system for 
updating your system software.

WHAT IS LINUX-ATHENA?

Linux-Athena is a port of the Athena 
environment to Linux, developed and 
maintained by the Student Information 
Processing Board.  

The Linux-Athena software is installed as part of 
the Redhat installation. Once the installation 
completes, your PC will become a fully 
functional Athena workstation.

For more details, see Inessential Linux-Athena 
from the SIPB office, or print it out from the 
Linux-Athena help page at

http://web.mit.edu/linux/www/

LINUX RESOURCES

	Visit the Linux-Athena Help Page at

	http://web.mit.edu/linux/www/

	Send questions about Linux to linux-help@mit.edu.

	Subscribe to linux-announce@mit.edu to receive 
announcements about Linux-Athena. Type:

blanche -a $USER linux-announce

	Many people on the "help" zephyr instance know about 
Linux.  You can subscribe to instance help with "zctl sub 
message help \*" and send messages to it with "zwrite -i 
help".  To subscribe permanently, use the command 
"zctl add message help \*".

	There is a "linux-netbsd" category in OLC where you 
can ask questions.  To use OLC, just type "olc" and 
follow the instructions.

	There are many Usenet newsgroups about Linux.  You 
can ask questions on the  newsgroups 
comp.os.linux.hardware or comp.os.linux.setup.  You 
can subscribe to comp.os.linux.announce and 
comp.os.linux.answers to read announcements and 
informational postings about Linux.

	The linux locker ("add linux", then look in /mit/linux) 
contains information (/mit/linux/docs), Athena packages 
(/mit/linux/packages), and some Linux software (/mit/
linux/linuxbin).

	Many Athena lockers contain Linux binaries.  These 
include the sipb, outland, gnu, consult, graphics, and 
mime lockers, among others.

	There are two major FTP archives for Linux, tsx-
11.mit.edu:pub/linux and sunsite.unc.edu:pub/Linux.  
For the latest kernel version, look in 
ftp.cs.helsinki.fi:pub/Software/Linux/Kernel.

INSTALLING LINUX

This slide just lists some basic resources; see 
Installing RedHat-Athena Linux on MITnet 
(available in the SIPB office or from the web 
page) and the documents it references for more 
information.

	Get your IP address from your dorm's RCC.

	You will need to have an empty partition on 
your disk for Linux before installing.  You can 
try to non-destructively shrink a DOS partition 
using a program called FIPS, available via FTP 
to sunsite.unc.edu in the directory pub/Linux/
system/Install.  Back up any important data in 
your DOS partition first, though, since these 
things are dangerous.

	Because new versions of DOS keep a separate 
copy of the disk's partition table inside the 
DOS partition, you should create your DOS 
partitions with DOS fdisk and your Linux 
partitions with Linux fdisk.

	Make a bootdisk according to the instructions 
in the Installing RedHat-Athena Linux on 
MITnet guide.

	Boot with this floppy and follow the onscreen 
instructions.

AUTOMATIC X STARTUP

When the installation completes, your system 
should boot up and present you with a text-style 
login prompt. X will not start automatically yet.

In order to make X start automatically, you must 
make a small change to your /etc/inittab file.

1. Log in as root. 

2. Type: 

/usr/athena/bin/emacs /etc/inittab

3. Change the line:

id:3:initdefault:

to:

id:5:initdefault:

4. Save and exit.

5. Type: 

/sbin/telinit 5

SECURE REMOTE LOGINS

To log in to your machine from an Athena 
workstation using Kerberos, you will need to 
obtain a service key, or srvtab, from Network 
Operations.  To do this, send mail to net-
help@mit.edu giving your machine name and 
asking for an rcmd srvtab.  They will respond 
with directions for retrieving the srvtab; you 
should install it in /etc/athena/srvtab.

Once you have done this, people with accounts 
on your system can log into your machine 
securely from an Athena workstation using the 
command "telnet -safe machinename" or "rlogin 
machinename -x".

You can also create a file ~root/.klogin 
containing your Kerberos principal 
("username@ATHENA.MIT.EDU") to allow 
you to log into your machine as root from an 
Athena workstation, using the command "rlogin 
machinename -l root -x".

BUILDING A KERNEL

Here are the steps for build installing a new 
kernel for your machine:

	Choose a kernel version.  Even-numbered 
minor versions (2.0) are more stable; odd-
numbered minor versions (2.1) are 
development kernels.

	FTP the kernel source from tsx-11.mit.edu:/
pub/linux/sources/system in the subdirectory 
v2.0 or v2.1.

	Unpack the tar file, configure the kernel, and 
build it.  As an example, if you have the Linux 
2.0.24 tarfile in /var/tmp:

cd /usr/src
mv linux linux.old
tar xzf /var/tmp/linux-2.0.24.tar.gz
cd linux
make menuconfig
[Answer the questions it asks]
make dep; make clean; make zImage

	Install the new kernel (assuming you're using 
LILO to boot):

cp /vmlinuz /vmlinuz.old
cp arch/i386/boot/zImage /vmlinuz
rdev -R /vmlinuz 1
lilo

The image may be named just zImage instead of 
arch/i386/boot/zImage. For more information, 
read /usr/src/linux/README.

USING LILO

LILO, the Linux loader, is the program which 
boots Linux off of your hard disk.  Normally, the 
Slackware installation utility writes your LILO 
configuration file for you and you just run the 
command "lilo" when you replace your kernel.  
However, it's useful to know how to modify the 
LILO configuration file /etc/lilo.conf yourself.

In addition to a few general parameters, /etc/
lilo.conf contains entries for each operating 
system you would like to be able to boot.  
Entries begin with "image=" for Linux partitions 
or "other=" for other operating systems.  A 
Linux entry usually looks something like:

image=/vmlinuz
	label=linux
		root=/dev/hda1

An entry for a different operating system (like 
DOS) looks like:

other=/dev/hda2
	table=/dev/hda
	label=netbsd

You can specify other options within an entry; 
these are described in detail in /usr/doc/lilo/
README.  One such option is 
`append="flags"', which lets you specify flags to 
the Linux kernel.  This is important if you need 
to specify flags to the Linux kernel to boot your 
system.

Three important general options are 
"boot=device", which tells LILO which device 
your system boots off of, "delay=time", which 
tells LILO how many tenths of a second to wait 
after the boot prompt before defaulting to the 
first entry, and "linear", which tells LILO to use 
logical addresses and may be necessary for large 
IDE disks.

FILESYSTEM LAYOUT

Here is a short explanation of the way directories 
are laid out on a Linux system.  For more details, 
see the Linux Filesystem Standard, which you 
can FTP from tsx-11.mit.edu in pub/linux/docs/
linux-standards/fsstnd.

The most important tip is this: if you would like 
to make your system as easily upgradable as 
possible, make your local modifications in /etc 
and in /usr/local, and avoid modifying other 
directories if possible.

/bin	Root partition binaries used by normal users
/boot	Files needed to boot the system
/dev	Device special files
/etc	System configuration files
/home	User home directories
/lib	Root partition languages library files
/root	The super-user's home directory
/sbin		Root partition binaries used bythe 	super-user
/tmp	Root partition temporary data
/usr	Files not needed in single-user mode
/usr/bin	Binaries used by normal users
/usr/lib	Language libraries and system 	data
/usr/local	Local additions to the operating 	system
/usr/local/bin	Local binaries used by normal users
/usr/local/sbin	Local binaries used by the super-user
/usr/sbin	Binaries used by the super-user
/var	Data written to automatically by programs
/var/adm	Log files and other system admin 		files
/var/lib	Application-specific read-write data
/var/tmp	Temporary data
/var/spool	Processing queues for mail, news, etc.

DEVICES

Here is a brief, non-comprehensive explanation 
of the device special files in /dev.  These files 
provide interfaces to hardware devices or to 
"virtual" devices like virtual console and 
pseudo-ttys.  "#" stands for a number.

/dev/tty#	Virtual console
/dev/console	Alias for /dev/tty0
/dev/ttyS#	Serial port
/dev/ptyp#	Pseudo-terminal (also ptyq#, ptyr#)
/dev/par#	Parallel port (sometimes /dev/lp#)
/dev/fd#	Floppy disk
/dev/hda	First IDE hard disk (up to
	/dev/hdd)
/dev/hd1a	First hard disk on second controller
	(up to /dev/hd1d)
/dev/xda	First XT hard disk (up to
	/dev/xdd)
/dev/sda	First SCSI hard disk (up to
	/dev/sdi)
/dev/hda#	Partition on first IDE hard disk
/dev/st0		First SCSI tape (up to /dev/st1)
/dev/ram	Ramdisk device
/dev/audio	Audio device
/dev/mem	System memory
/dev/kmem	Kernel memory
/dev/null	Bitbucket (data written to it goes
	nowhere)
/dev/zero	Zero file (reads from it return all
	zeros)
/dev/full	Full disk file (writes to it always
	act like the disk is full)
/dev/tty	Current controlling tty

The file /dev/MAKEDEV allows you to make 
devices easily, and also contains information 
about devices not listed above (CDs, busmice, 
joysticks, etc.).

/etc/inittab

The /etc/inittab file specifies what operations 
your system performs at boot time.  The program 
/sbin/init reads /etc/inittab and creates processes 
depending on what /etc/inittab says and the 
current system runlevel.  The runlevel is usually 
5; you can set it with the telinit command.  A 
typical /etc/inittab line looks like:

c3:456:respawn:/sbin/agetty 38400 tty3

The first field, "c3", is just a unique tag 
identifying the entry.  The second field, "456", 
specifies the runlevels at which the entry takes 
effect.  Runlevels can be numbers or "S", which 
indicates single-user mode.  The third field, 
"respawn," is the action, a special keyword 
which indicates how /sbin/init should treat the 
line.  The keyword "respawn" indicates that init 
should run the command ("/sbin/agetty 38400 
tty3") upon startup and every time the process 
dies.

The init and inittab manpages ("man init" and 
"man inittab") describe the various keywords in 
detail.

/etc/fstab

The /etc/fstab file specifies what filesystems 
your system should have mounted.  A typical 
entry looks like:

/dev/sda2  /usr  ext2  defaults

The first field, "/dev/sda2", specifies the device 
containing the filesystem,  in this case the second 
partition on the first SCSI disk.  The second 
field, "/usr", specifies the mountpoint for the 
fileseystem, or where it should appear in the 
directory heirarchy.  The third field, "ext2", 
specifies the type of the filesystem; the second 
extended filesystem is the most common Linux 
filesystem type.  The fourth field, "defaults", 
specifies flags for the mount, which can be 
useful for NFS filesystems.

One of the more interesting filesystems is the 
procfs, specified by the line:

none   /proc   proc   defaults

This is not a filesystem on your disk; rather, it 
contains various kernel information about 
processes and other system resources.  For 
instance, the file /proc/modules contains a list of 
dynamically loaded kernel modules currently 
loaded into your kernel, /proc/version contains 
the kernel version, and /proc/1/cmdline contains 
the command line of the first process (which is 
always /sbin/init).

For more details, see the fstab man page ("man 
fstab") and the mount command man page 
("man 8 mount").  In particular, the mount man 
page explains the various flags you can use for 
the filesystem.

/etc/inetd.conf

The /etc/inetd.conf file specifies the system 
services your machine provides to the network.  
The program /usr/sbin/inetd reads this file and 
responds to the connections by running 
programs.  A few system services are built into 
inetd, for efficiency reasons.

A typical /etc/inetd.conf line looks like:

ftp   stream  tcp   nowait  root  in.ftpd in.ftpd

The first field, "ftp", specifies the name of the 
service.  inetd looks up the service name in the /
etc/services file to find the port number of the 
service.  The second and third fields, "stream" 
and "tcp", specify the protocol type for the 
connection; tcp specifies a stream-oriented 
protocol, while "dgram" and "udp" would 
specify a packet-oriented protocol.  The fourth 
field, "nowait", tells inetd not to wait for the 
process to complete before accepting new 
connections on the port; "wait" would prevent 
inetd from serving more than one request at a 
time for that service.  The fifth field, "root", 
contains the name of the user to run the program 
as.  

The sixth field, "/usr/sbin/in.ftpd", contains the 
name of the program to run.  The seventh and 
remaining fields contain the arguments to the 
program.  Normally, the first argument is the 
same as the program name, but sometimes the 
program uses the first argument to determine 
which service to provide.

You may wish to disable the non-Kerberized 
remote access services on your system (shell and 
login, in particular) for improved security.  You 
can use the command "kill -HUP `cat /etc/
inetd.pid`" to make init re-read its configuration 
file.  The inittab and init man pages ("man 
inittab" and "man init") contain more detailed 
information.

/etc/profile, /etc/csh.cshrc, /etc/
csh.login

Most shell programs are derived from either sh, 
the Bourne shell, or csh, the C shell.  Both of 
these shells read a system configuration file on 
startup (/etc/profile for the Bourne shell, /etc/
csh.login for the C shell), in addition to the 
user's .profile or .login file.  The C shell also 
reads the file /etc/csh.login each time it is run, in 
addition to the user's .cshrc file.

If your system has multiple users, you can 
modify these files to set environment variables 
and perform other customizations for all of your 
users.  Unfortunately, there are some shells 
which read different  system configuration files 
or none at all, so there is no good way to set 
environment variables for all users.

On a Slackware system, the /etc/profile and /etc/
csh.login files set up aliases to make the system 
more friendly (for instance, a "dir" command for 
DOS users), and the /etc/csh.cshrc file is empty.

The man pages for the most common shells 
("man bash" and "man tcsh") have more detailed 
information.  Unfortunately, most Linux systems 
do not have man pages for the C shell (tcsh is 
derived from csh, but the tcsh man page does not 
describe csh functionality), so you may need to 
read the csh man page on an Athena worsktation 
to find information about csh customiation.

/etc/passwd

The /etc/passwd file contains information about 
the users on your system.  A typical entry in the /
etc/passwd file looks like:

ghudson:*:3622:101:Greg Hudson:/mit/ghudson:/afs/sipb/
project/tcsh/tcsh

The first field, "ghudson", contains the 
username.  The second field, "*", contains the 
encrypted password; a password of "*" indicates 
that no password will work.  (Because Athena 
logins are done using Kerberos authentication, 
"*" is common in the passwd field on Linux-
Athena workstations.)  "3622" specifies the ID 
of the user, used for file ownership and other 
purposes.  "101" is the user's group ID, which is 
generally not too important on a modern Unix 
system since users can belong to multiple 
groups.  "Greg Hudson" is a comment field (also 
known as a GECOS field) containing 
information about the user.  The sixth field,  "/
mit/ghudson", is the home directory of the user, 
and the seventh field, "/afs/sipb/project/tcsh/
tcsh", is the user's shell program.

On a Linux-Athena system, you can create a file 
/etc/passwd.local containing local accounts, 
which will be copied into /etc/passwd when the 
machine reactivates.  This helps keep your 
password file clean.

You can obtain /etc/passwd entries for an Athena 
account using the command "hesinfo username 
passwd".  Thus, adding an account for an Athena 
user (for remote access, for instance) is as simple 
as the command:

hesinfo username passwd >> 
/etc/passwd.local

/etc/group

The /etc/group file specifies which users are in 
which local groups.  This can be confusing on a 
Linux-Athena workstations: local system groups 
are distinct from Moria groups (an Athena 
concept), but xlogin or the Athena /bin/login will 
create entries in /etc/group so that local system 
groups mirror the Moira groups you are in.  
Unfortunately, most systems can't handle more 
than 16 or so groups per users, so not all of your 
Moira groups are entered into /etc/group.

A typical /etc/group line looks like:

gsipb:*:15001:svalente,ghudson

The first field gives the name of the group, the 
second field gives the encrypted password 
(almost always "*" since group passwords are 
almost entirely meaningless), the third field 
gives the group ID, and the fourth field contains 
a list of users for the group.

Most of the time, you can ignore local system 
groups because most of the files you share with 
other users are in AFS.  For NFS permissions, 
however, or if you have different users on your 
system, local system groups can be important.

You can create a file /etc/group.local containing 
a local set of group information, which will be 
copied over /etc/group when the system 
reactivates.  This reduces clutter if you have lots 
of different users logging in, since the Athena 
login programs don't clean up /etc/group when 
users log out (they do clean up /etc/passwd).

/etc/syslog.conf

The /etc/syslog.conf file specifies how system 
log messages are stored on your system.  A 
typical line looks like:

*.=info    /var/adm/messages

(You have to use tabs in the /etc/syslog.conf file 
instead of spaces, unfortunately.)  The first part 
of the line specifies a list of facilities and log 
levels; the second part specifies a file.

Facilities and log levels are separated by a 
period; the facility can be "*" for any facility.  
Valid facilities are listed in the syslog.conf man 
page ("man syslog.conf"); "kern", for example, 
is the kernel. Log levels can be "emerg", "alert", 
"crit", "err", "warning", "notice", "info", 
"debug", or "none", in decreasing order of 
severity.  "none" is special; it means to exclude 
the given facility when it would otherwise by 
included.

 Normally, a log level specifies all levels above a 
certain point, so that "daemon.info" would get 
all log messages from daemon of level info or 
above.  You can override this by preceding the 
log level with an equals sign; in the case of the 
example, only messages of log level info and 
notice are logged to /var/adm/messages.

You can log messages to the console by 
specifying /dev/console as the output file.  It is 
also possible to have log messages sent out via 
Zephyr by running /etc/athena/syslogd instead of 
/usr/sbin/syslogd and specifying a list of 
usernames in place of the filename; if you want 
to try this and can't figure out how, send mail to 
linux-help@mit.edu.

MISCELLANEOUS CONFIG 
FILES

There are a few more system configuration files 
which deserve mention, but which aren't 
complicated enough to deserve a full slide.  Most 
of these files have corresponding man pages 
which you can read using the command "man 8 
filename".

	/etc/hosts contains a list of hosts your system 
can look up without using Domain Name 
Service resolution.  Normally, this file contains 
just the local system name and "localhost".

	/etc/resolv.conf contains configuration data 
for name service lookups, including your 
system's local domain and the name server.  If 
you have named installed, the name server is 
usually 127.0.0.1.

	/etc/named.boot and the other /etc/named.* 
files specify the configuration for named, 
which performs DNS lookups and caches their 
results to avoid overloading the MIT name 
servers.

	/etc/services contains a list of service names 
your system can look up; this allows programs 
to avoid hardcoding port numbers for services.

	/etc/exports contains a list of directories your 
system will export via NFS; you may also have 
to enable nfsd and mountd in the startup script 
/etc/rc.d/rc.inet2 to make NFS exports work.
