Assorted information Access count 3773

Assorted information

Linux is a unix clone. The server we'll have located in Maryland or in
Washington DC (I'm not sure of the exact address) will be connected to the
internet via an ethernet cable. The server will be running linux as the
main OS, RedHat 5.0 for x86 machines. The server will be providing at least
the following services:
http (web pages)
ftp (file transfers)
named (irrelevant, has to do with host name lookup)
pop3/pop2 mail service (email server)
rlogin+telnet (for people with accounts on the server, such as us)

To configure the server we'll telnet in under our personal accounts,
then use 'su' to become root. Everyone will have to know the root password
and I don't want to send that over the internet, instead people will have to
call me. You have to have the root password in order to do any administrative
work, such as adding new user accounts, setting up web domains, or installing
new software. Only the 5 of us should know the root password, so don't go
telling it to any of your clients. With root priviledges people can really
mess up the system.

Under unix/linux when you telnet in to the machine, enter your username and
password you will drop into a shell. I've set everyone's shell up to be
/bin/tcsh. This shell gives you command line history and editing with the
arrow keys, backspace and delete. Also you can hit the tab key and the
shell will complete filenames for you. When you're entering a command you
can hit control-d and the shell will list all commands that begin with the
characters you've typed.

Under unix/linux everything is command driven:
ls = list files (like dos's dir)
cd = change directory. cd with no directory name will move you to your home
     directory.
mv = rename files
cp = copy files
cat = print out files
pwd = print current working directory, tells you where you are
rm = remove files
man  = show manual page for 
vi = visual editor which is what you'll have to use to edit text files.
     Very tedious to use.
su = become root, must enter the root password
adduser  = Must be root, this adds a user to the list of users and
     creates a home directory in /home for their files.
passwd = change your password
passwd  = must be root, this lets you set the password for someone
    else's account.
ps = list current taks running ("ps aux" lists all tasks running)
chmod = change permissions on files
mkdir = create directory
rmdir = remove directory
apropos  = show relavent man pages

As a security measure redhat linux sets it up so you can't telnet in as
root, you have to telnet in as someone else the use 'su' to become root.

Interesting files:
/etc/passwd = the list of users and information about them
/etc/httpd/conf/httpd.conf = The apache web server configuration file.
/home = directory containing users' accounts + files for virtual web sites.

Apache web configuration file:
The /etc/httpd/conf/httpd.conf file, down at the bottom, contains the
following:

ServerAdmin webmaster@eom.net
DocumentRoot /home/epyx/htdocs
ServerName www.epyx.com
ResourceConfig /home/epyx/srm.conf


This sets the computer up as a virtual host www.epyx.com. If you look there
is a user epyx listed in /etc/passwd. epyx's home directory is /home/epyx.
Inside /home/epyx is a file /home/epyx/htdocs, which is listed in the
DocumentRoot command above. There is also a file /home/epyx/srm.conf file
mentioned as the ResourceConfig which tells specific details about this
site.

The apache web server handles outside requests via HTTP. So when a computer
somewhere in the world tries to access www.epyx.com, it will try to open
port 80 on the server, and apache will be listening to that port and will
respond with appropriate information. Apache is free software but it is
used by most of the web sites on the net, I believe. It's very powerful (or
so I hear) and it is very reliable.

When a person somewhere in the world is browsing the web and tries to open
the web page www.epyx.com, his computer must figure out the IP address
associated with www.epyx.com. This is a complicated procedure and involves a
lot of passing the buck, but currently looking up www.epyx.com will return
207.239.91.6. When the server is up on the network for real and I'm satisfied,
I'm going to contact internic and have them change the www.epyx.com domain
name servers to point to our server, and I'll configure the server to have
www.epyx.com point to itself.

Meanwhile we'll have internic point to our server for all the domain names
we host, such as Mike's thegrove.net and artisan-software.com. All of these
names will resolve to the same IP address. It is a feature of the HTTP that
the hostname appears in the www request. So for example if I'm trying to
fetch
http://www.epyx.com/current.txt
The machine that receives the request (207.239.91.6) will be told that the
request is for www.epyx.com. That's how the web server can know which web
page to present, and that's what virtual web hosting is.

Assuming artisan-software.com, thegrove.net and epyx.com all are pointing
to our server, since I've got an account dash already set up someone could
send me email to dash@ any of those domain names, and it will get to the same
dash account on the server. I named the server thegrove.net just because it
was convenient, and you've got to pick some name during the redhat linux
installation. Since Mike has 2 domain names it might make sense to borrow one
(artisan-software.com) and have internic point that name to our server once
it is installed and we know its IP address. I assume Mike's not using
artisan-software.com as much as thegrove.net because it's longer and harder
to type.

So to create a virtual domain for a client who has paid internic $70 for
registering a domain name for 2 years, you'd have to log in, become root,
choose a user account name for the client (let's say "client"), then do an
adduser command:
adduser client
Then set the password:
passwd client
Write the username and password down to possibly inform the client later if
he/she is going to be managing their own web pages.
Then you've got to add lines to the /etc/httpd/conf/httpd.conf file like
the ones above. You'll have to create a ~client/srm.conf file for yourself,
but you can use ~epyx/srm.conf as a guide. Then you'll have to create a
directory ~client/htdocs and put any html docs or files there to be accessable
on the virtual web site.

All of the files must be chmod'd 755 which gives each file the following
access:
owner: read, write and execute
group: read and execute
other: read and execute
(Under unix every file contains permission information telling whether it
is readable, writable or executable by the owner, his group and everyone else.
3x3 = 9 yes or no bits. An octal digit represents 3 binary digits together,
so chmod uses 3 octal numbers together to set the permissions. For each
octal digit,
1 = execute
2 = write
4 = read
So you just add the numbers you want together.
chmod 755 ~client/htdocs
      ^   This represents the owner's permissions
       ^  This represents the owner's group's permissions
        ^ This represents the permissions for everyone else
You can basically ignore the group permissions and only concern yourself with
owner and other permissions. You want to give other people read and execute
permissions so they can view your web pages and enter your directory. The
"ls -l" command lists file information and shows the status of each file's
permissions for owner, group and other.

All these permissions apply only to user accounts. As root you can do anything
and the permissions are ignored. That's why it is dangerous to be root for
your everyday computing--you can easily wipe out whole directory trees or
in general screw stuff up, and the file permissions can be an aid to avoid
catastrophes like that.

Once all the above steps have been done, you can look at the virtual web site
by telling your computer to associate the server's IP address with the
domain name you just entered. I could tell you how to do this under unix/linux
but win95 users are on their own. In the end you'll probably have to wait for
internic to percolate the information around before the web site becomes
visible to the outside world.

There are other steps involved if you want to have sites hung off any of
the virtual domain names. I don't know the details at the moment but it will
involve just more configuration commands in the apache startup scripts.
BTW before apache notices the new scripts you've got to restart the apache
by sending it a -HUP signal. As root you do a ps -aux and find the lone
httpd task running. httpd is the apache server, the 'd' on the end means it
is running as a daemon which is more unix talk. httpd spawns many other copies
of itself in order to be ready to handle lots of traffic. Each copy is
waiting for incoming requests, so if you've got a lot listening all together
you won't lose anything. When you do "ps -aux" you'll see a group of httpd
tasks all in a bunch, then a lone "httpd" by itself, usually with a lower
process ID. Assuming the ID of the lone task is 314, you'd issue the command
(as root)
kill -HUP 314
That sends a HUP signal to the httpd program and the effect is to have the
running httpd program reread its configuration files. Under win95 you'd have
to restart the machine to make changes like that most likely. Under unix the
machine stays up, and you just effectively restart a specific program all by
itself.

A good book to get about linux and unix might be O'Reilly's Running Linux
which probably costs about $30. I've heard it's a good book...Mostly all
the information you'll need can be found on the net and by using the 'man'
command.

Once you do the adduser command, you create an email account also for that
specific account name. In the example above it would end up being
client@hisdomain.com
client@epyx.com
client@thegrove.net
client@artisan-software.com
All of the above addresses will end up going to the person's email account
on the server. A client can retreive his email by logging onto the unix
account using his username and password and using any of the unix mail
commands. Alternatively the client could configure a mail program like netscape
to use pop3. The client would enter hisdomain.com as the server, and
client as the account, and his password for the password. The server will
have a pop3 server running, as it is now.

Most everything we want to do will just magically work.

Well I'm getting tired of typing this in right now so I'll stop.