Title:

A free Basic UNIX-training with muLinux

Home
deutsch
  
ISBN: 3827316596   ISBN: 3827316596   ISBN: 3827316596   ISBN: 3827316596 
 
  Wir empfehlen:       
 
[Back] [Home] [Forward]       http://rowa.giso.de  

A free Basic UNIX-training with muLinux

Notes: This Text is roughly translated (German to English) by a translating program. Sorry, but I have not time for the translation. Maybe you can do this.

Activating the Webserver PYGMY

What makes a Web server?

A Web server is a program, which nistet on a machine in the network and waits for a Web Browser, which transmits an inquiry, usually because of a file.

Servers and Browser communicate with the help of hypertext transfer Protocol (HTTP), a special language, which was developed particularly for the transmittal by hypertext documents by the Web. Therefore Web servers frequently also httpd are called - servers.

The D is for Daemon . As we know are a Daemon a program, which squats in the background and waits for inquiries. If it receives an inquiry, then it wakes up, processes the request and puts again to then sleep.

A server transmits a file in such a way adds it some specification, which type of file it transmits (for example a GIF file). So the Browser can detect whether it can read her or but an aid programme (Plug in) must start. In addition the HTTPD server transmits to two lines before the actual file as header (English for heading). The first line indicates the so-called MIME type. The second line is empty. MIME means multi-pure float Internet Mail Extensions. That is a standard for describing files. In former times this was used particularly for the classification of at enamels angehangenen files. Thus the Mail program could detect which file type is present and the appropriate program for the representation of this file to start. Today this standard is used by many Internet services.

One can also to that extent extend the behavior Servers that he sends away also files, which are not part of the normal record. Finally Web servers can be created also in such a way that they call scripts and programs, which are based on specification, which the surfer inputs with the help of his Browser. These special programs are called gateway programs or gateway scripts. The specifications in addition Common gateway INTERFACE (cgi). Programming languages for cgi are Perl, that in the HTML code merged PHP, Java and shell Scripte.

The standard Web server is Apache www.apache.org (Aepaetchie is spoken). This printout comes from " a patchy servers ". Apache was composed of the NCSA Webserver and a set of Patch files (Patch = English for patches). Apache is free like Linux open SOURCE and thus. It is available not only for all Unix versions, but also for Windows. Apache runs often on Solaris, FreeBSD and naturally on Linux. One uses the technical term LAMP for the description of the Standardtechnologieen in the Internet technique. L is for Linux, A for Apache, M for those the data base system MySQL and P for the PHP. MySQL and PHP mentioned above is likewise open SOURCE. Normal Web servers can be operated thus perfectly with free software.

On muLinux the diskette is that minimumistic Web server PYGMY. before we these activates looks at we it us somewhat more exactly. We want to know where pygmy are and which for a file that is. This konnen we with an instruction line do. The instruction merged in the inverted commas showing back is executed and the result is analysed by the program which is before it.

/# file `wich pygmy`
/usr/sbin/pygmy: script text
/# _

It thus a Script file, which we regard directly times.

/# cat usr/sbin/pygmy
#!/bin/ash

while [ 1 ]
do
/usr/bin/nc -v -e /usr/sbin/in.pygmy -l -p 80 2>>/var/log/httpd.log
done
/# _

The first line indicates this file as shell Script and it becomes the Shell / bin/ash started. The instruction while , DO and done form a program loop, which will pass through again and again. Thus the program included in this loop is kept constant alive.

The program nc the abbreviation for NetCat is, a network Client with functionality minimum held. One can structure with it both TCP connections to any port and pretend " UDP connections " (faken). It is suitable besides for it, intended port to hear. We look at ourselves times its parameters.

/# nc -h
[V1.10]
connect to somewhere:   nc [-options] hostname port[s] [ports] ...
listen for inbound:     nc -l -p port [-options] [hostname] [port]
options:
        -e prog             program to exec after connect [dangerous!!]
        -g gateway          source-routing hop point[s], up to 8
        -G num              source-routing pointer: 4, 8, 12, ...
        -h                  this cruft
        -i secs             delay interval for lines sent, ports scanned
        -l                  listen mode, for inbound connects
        -n                  numeric-only IP addresses, no DNS
        -o file             hex dump of traffic
        -p port             local port number
        -r                  randomize local and remote ports
        -s addr             local source address
        -t                  answer TELNET negotiation
        -u                  UDP mode
        -v                  verbose [use twice to be more verbose]
        -w secs             timeout for connects and final net reads
        -z                  zero-I/O mode [used for scanning]
port numbers can be individual or ranges: lo-hi [inclusive]
/# _

In the PYGMY Script the following options are used:
-v   Bose (English for geschwaetzig) outputs messages.
-e /usr/sbin/in.pygmy   The following program executes after establishment of contact.
-l   Hears (English to list) on detailed inquiries.
-p 80   Port 80 is heard, thus to WWW port.
2>>/var/log/httpd.log   Error messages are added to the log file.

Thus here NetCat at the port 80 hears and leads with inquiries behind - e mentioned Porgramm out. This is dangerously (English dangerous), there one also numerical control easily a Trojan horse to program can. The log file / var/log/httpd.log records all error messages and only after activating by PYGMY one creates.

/# ls /var/log 
identd.log
/# _

Still is thus none httpd.log available. We look ourselves times the program /usr/sbin/in.pygmy on.

/# less /usr/sbin/in.pygmy

Well is here already somewhat more in it. We cannot natural be impressed of it. As we know simple shell Scripte " from the section ", is the doppelkreuz # the beginning of a comment. In the first line is located a special comment, which defines the program which can be called. Here is that / bin/ash . At the beginning variables are defined for general configuration. A good programming style determines the definitions at the start of the program. Thus modifications can be executed more easily. One does not then only have to search the entire source text (English SOURCE code).

        SED=sed
        ROOT=/home/httpd
        LOGO=/tmp/httpd.logo
        LOGFILE=/var/log/httpd.log

The variable SED defines the program for batch processing of texts. Here that is the Stream wordprocessor sed. That sounds much impressing. We will be occupied only later with this program. ROOT defines the homeland directory Web webservers. There, or in sublists the HTML files and diagrams are situated. We want to check this. In addition we change in to the second console and log.

[Alt] [F2]

/# ls /home/httpd
total 5
0 doc        0 images       2 linux.html
0 download   3 index.html
/# _

Here really are HTML files. One detects it by the ending .html. HTML files are text files, which contain HTML instructions. These instruction are included in pointed < > parentheses. Web Browser understand this code more or less well and present themselves these files as WWW pages. Who wants can times itself such a file also less index.html look at. The file index.htmla special file is in each directory. The Web server supplies this file, if with the inquiry no file separate only one directory one indicated.

But back to the first console and thus to the file in.pygmy.

[Alt] [F1]

The next variables define a Logo for the server and the log file. With the log file we know that them were not created yet. But how is with the Logo? We test this in the second console.

[Alt] [F2]

/# ls /tmp

There is no file httpd.logo. This becomes only in the following code of /usr/sbin/in.pygmy created. In addition we change again into the first console and page through the text downward.

[Alt] [F1]

[Cursor nach unten]

Under the auxiliary functions we see the code for the production of the Logos.

# auxiliary functions

cat > $LOGO <<END
<hr>
<font size=-1> <i>
<center>
powered by PYGMY -- muLinux rustic WWW server, on <b>`hostname` </b>
</center>
</i></font>
</html>
END

With the instruction cat the following text up to END written into the Logo file. That is, with the first WWW inquiry the Logo file is created. We detect here the HTML instruction by the pointed brackets. We will be occupied later in " the section creating a small " Website with it. The Logo is output with messages Web webservers.

After the program section for the production of the Logos some function definitions take place. Functions are used with most programming languages. Those are program modules, which are needed again and again. Before the first call they must be defined only. This takes place with the shell Script as with many languages.

funktionsname()
{
   Befehl
   Befehl
   ...
}

First the function name is determined. With this name the function is called later. Then round brackets come. These serve if necessary for the parameter transfer. Our Web server program has in addition with no function the requirement. Between curved brackets the instruction which can be processed in this function are then written. Look at we and in addition far our small Web server.

# Explorer requires explicitily a standard header
send_header()
{
cat <<END
HTTP/1.0 200 OK
Date: `date`
Server: Pygmy/Mulinux (Rustic) WWW server, v`cat /etc/version`
   Leerzeile
END
}

***TRANSLATION ENDS HERE ***

Die Funktion send_header() sendet beim Aufruf den Header. Die erfolgt wieder mit dem Befehl cat der alles bis zu END ausgibt. Es wird die hier verwendete Version des HTTP ausgegeben und die Meldung "200 OK". Das heißt die angeforderte Datei ist vorhanden und wird anschließend gesendet. Danach wird das Datum und Informationen zum Server dargestellt. Wichtig ist die abschließende Leerzeile. So erkennt der WWW-Browser das Ende des Headers. Was danach kommt ist die angeforderte Datei.

build_error()
{
cat > /tmp/pyg_error.html << END
<html>
<h1>PYGMY (pygmean) www server</h1>
<hr>
<b>Not Found</b>
<p>
The requested URL $1 was not found on this server.
`cat $LOGO`
END

echo /tmp/pyg_error.html

}

Wenn eine angeforderte Datei auf dem Server nicht vorhanden ist, muß eine entsprechende Fehlermeldung gesendet werden. Dafür ist die Funktion build_error() zuständig. Dazu wird mit dem Befehl cat die Datei /tmp/pyg_error.html angelegt mit dem nachfolgenden HTML-Code gefüllt. Dazu gehört auch das Server-Logo. Anschließend wird die Datei mit echo ausgegeben.

build_dir()
{
case "$1" in
*/)
        base="."
        ;;
*)
        base="`basename $1`"
        ;;
esac

/bin/ls -s1 $1 | fgrep -v "total" > /tmp/raw.list

        parent=`dirname $base`

cat > /tmp/html.list <<END
<html>
<h1>Index of $1</h1>
<hr>
<p>
<a href="../"> Parent directory </a> <p>
END


cat /tmp/raw.list | \
$SED "s/ *\([0-9]\+\) *\(.\+\)/\
\<a href=$base\/\2\>    \2 \
\<\/a\> \1k\<p\>/g" >>/tmp/html.list

cat $LOGO >> /tmp/html.list
echo /tmp/html.list
}

Die Funktion build_dir() wird aufgerufen, wenn ein Verzeichnis angefordert wird, indem sich keine Datei index.html oder index.htm befindet. Ist dies der Fall, so wird der Inhalt des Verzeichnisses aufgelistet. Dazu wird der Stream Editor sed verwendet. Dessen Syntax möchte ich hier aber noch nicht erklären. Kommen wir zu wichtigsten Funktion. Das ist die Funktion GET(). Diese Funktion wird bei Anfragen an den Server aufgerufen. Die Anfrage nach einer Datei erfolgt in HTTP mit dem Befehl GET. Deshalb wurde diese Funktion hier so benannt. Sie hätte allerdings auch Pflaumenkuchen() heißen können. Der HTTP-Befehl GET übergibt als Parameter den Namen der Datei. Die Übergabe des ersten Parameter erolgt im Script-Programm mit $1. In der ersten Zeile wird $1 in die Variable page geschrieben.

GET()
{
page=$1

Mit Hilfe der Befehlskombination case (engl. für Fall) ... esac (case rückwärts geschrieben) können Fallunterscheidungen gemacht werden. Hier wird getestet ob am Anfang des Parameters ein Slash / steht. Wenn ja, dann sei die Variable pre leer, wenn nicht, dann sei pre gleich "/". Dann kommt die gleiche Fallunterscheidung für ein mögliches Slash am Ende. Hier wird post entsprechend gesetzt. Dies ist notwendig um jeweils ein Slash als Trennzeichen entsprechend der Unixschreibweise zu erhalten.

# / problem
case "$page" in
/*)
        pre=""
        ;;
*)        pre="/"
        ;;
esac

case "$page" in
*/)
        post=""
        ;;
*)      post="/"
        ;;
esac

Mit Hilfe der Befehlskombination if (engl. für wenn), then (engl. für dann), else (engl. für ansonsten) und fi (if rückwärts) können Entscheidungen getroffen werden. Das heißt: "Wenn etwas richtig ist dann mache das. Ansonsten mache jenes." Hier wird erst getestet ob ein Verzeichnis angefordert wurde. Wenn dies so ist wird versucht entweder die Datei index.htm oder index.html zu finden und mit dem kompletten Pfad zu senden. Ist weder index.htm oder index.html vorhanden so wird mit die Funktion build_dir aufgerufen, die das den Inhalt des Verzeichnisses auflistet. Wenn kein Verzeichnis angefordert wurde, so wird wohl eine Datei gemeint sein und die Variable PAGE mit dem Dateinamen und dem kompletten Pfad gefüllt.

# if a dir? exist index.html?

PAGE=

if [ -d $ROOT$pre$page ] ; then

[ -f $ROOT${pre}${page}${post}index.htm ] \
&& PAGE=$ROOT${pre}${page}${post}index.htm

[ -f $ROOT${pre}${page}${post}index.html ] \
&& PAGE=$ROOT${pre}${page}${post}index.html

[ -z "$PAGE" ] && PAGE=`build_dir $ROOT$sep$page`

else
        PAGE=$ROOT$pre$page         # is a file
fi

Jetzt wird getestet ob die Datei oder das Verzeichnis vorhanden ist. Wenn nicht wird mit build_error eine Fehlermeldung erzeugt.

# exist ?

if [ ! -f "$PAGE" ] ; then
        PAGE=`build_error $PAGE`
fi

Ist alles OK wird mit send_header der Header und danach mit cat die Datei ausgegeben.

# Ok, send page

send_header
cat $PAGE

}

Das waren soweit die Funktionen. Jetzt kommt das kurze Hauptprogramm (engl. main). Das Hauptprogramm wird mit while do ... done am Leben gehalten. Mit read wird die WWW-Browseranfrage gelesen. Danach erfolgt ein Eintrag in der Log-Datei. Mit if wird getestet ob es wirklich eine GET-Anforderung ist. Wenn ja wird die Funktion GET aufgerufen. Wenn nicht ertönt ein akustisches Signal und es wird eine Fehlermeldung ausgegeben.

# Main

while [ 1 ]
do

read x
echo " got [$x]" >> $LOGFILE
set -- $x

if [ "$1" = GET ] ; then
        GET $2
else
        [ "`which wave`" ] && wave -c 800 2
        send_header
        echo "<html> Error: $1 unknown. </html>"
fi
exit
done

Ich hoffe es war nicht zuviel Script-Programmierung auf einmal. Wir werden uns später mit der Script-Programmierung beschäftigen. Wer also hier nicht jedes Detail verstanden hat, braucht deshalb keine großen Sorgen machen. Hauptsache wir haben jetzt eine grobe Vorstellung was ein Webserver mindestens zu tun hat.

Aktivieren des Webservers

Wir wollen jetzt unseren Webserver zum Leben erwecken. Vorher testen wir aber ob nicht vielleicht doch schon ein Port offen ist.

/# nmap localhost
Scanning ports (hosts localhost), wait ...
localhost [127.0.0.1] 113 (auth) open

Nur das Port 113 ist offen. Wir öffnen jetzt Port 80.

/# setup -f httpd
Setting httpd up: ask_the_user

                    - Internal Web Server -

Depending of what addons are mounted, muLinux support
some httpd daemon, running on port 80:

        - Pygmy: the rustic script-based web-server
        - thttpd: the fast web-server, developed by Jef Poskanzer



Do you want a running webserver?: Y

Wir wir sehen gibt es auf einer Add-on-Diskette noch einen zweiten Webserver mit dem Namen thttpd. Dieser ist schon eher ein richtiger Webserver. Wir begnügen uns hier aber mit PYGMY.

Starting PYGMY (rystic) web-server ... 1517

Der Webserver wird gestartet und die Prozessnummer ausgegeben. Diese ist bei Euch sicher anders als hier. Wir testen ob PYGMY läuft.

/# ps aux | grep pygmy
    ...             /usr/sbin/pygmy

Er läuft. Ist das Port auch offen?

/# nmap localhost
Scanning ports (hosts localhost), wait ...
localhost [127.0.0.1] 113 (auth) open
localhost [127.0.0.1] 80  (www) open

Es ist offen. Wäre unser Rechner an das Internet angeschlossen, hätten wir ein großes Sicherheitsloch. PYGMY ist nämlich nicht sehr sicher. Wurde auch eine Log-Datei erzeugt?

/# ls /var/log
httpd.log identd.log
/# _

Na klar! Schauen wir doch mal rein.

/# cat /var/log/httpd.log
connect to [127.0.0.1] from localhost [127.0.0.1] 4194
 got[]
listening on [any] 80 ...
/# _

Testen mit dem WWW-Browser quark

Wir testen ob wir mit dem WWW-Browser Kontakt zum WWW-Server aufnehmen können.

/# quark http://localhost

 [r]eload [g]o [b]ack [v]iew [u]rls [s]ave [d]ownload [P]rint [q]uit    [h]elp 

                    Welcome to PYGMY (pygmean) WWW server!
 ----------------------------------------------------------------------------

 This is a placeholder page installed by the muLinux setup scripts,
 because no home page was installed on this host. You may want to replace
 this as soon as possible with your own web pages, of course....

 PYGMY is a small HTTP server, implemented with a shell script
 (2174 bytes) and netcat port scanner. PYGMY run via /etc/inittab
 and support: images, download and directory browsing. Remember: images
 are fetched one by one, pressing RELOAD button in your browser.
 Ehmm: the image is on the X11 addon ... :(

 http://localhost                                                   Quark v.xx
 cursor up/down, pag up/down to move                       vxx, hyperlink mode

Scheint alles zu funktionieren. Der Server zeigt uns eine Begrüßungsseite, die einige Informationen zum Server bietet. Erst im nächsten Kapitel lernen wir quark genauer kennen. Wir lernen hier nur einen Befehl kennen:

q

Mit Q verlassen wir den Browser wieder. Mit der Befehlswiederholung rufen wir nochmals quark auf. Diesmal geben wir noch den Port 80 an.

/# quark http://localhost:80

Das Ergebnis ist das Gleiche. Port 80 ist das Standardport für WWW und braucht nicht extra angegeben zu werden. Man kann aber auch den WWW-Server auf einen anderen Port betrieben. So können z. B. mehrere WWW-Server auf einen Rechner laufen. Wir probieren nach dem Verlassen von quark noch eine Variante.

/# quark http://localhost:80/index.html

Auch hier haben wir das gleiche Ergebnis. Wir haben ja in dem Script gesehen, daß der Webserver index.html ergänzt, wenn nur ein Verzeichnis angegeben wurde. Wir schauen uns nochmal die Log-Datei an.

/# cat /var/log/httpd.log
connect to [127.0.0.1] from localhost [127.0.0.1] 4194
 got[]
listening on [any] 80 ...
connect to [127.0.0.1] from localhost [127.0.0.1] 4687
 got [GET]
listening on [any] 80 ...
/# _

Er hat unsere Anforderung registriert. Und noch ein Versuch. Wir geben jetzt der Funktion zur Ausgabe der Fehlermeldung eine Chance.

/# quark http://localhost/quatsch

Der WWW-Server zeigt uns seine Fehlerseite.

/# cat /var/log/httpd.log
connect to [127.0.0.1] from localhost [127.0.0.1] 4194
 got[]
listening on [any] 80 ...
connect to [127.0.0.1] from localhost [127.0.0.1] 4687
 got [GET]
listening on [any] 80 ...
connect to [127.0.0.1] from localhost [127.0.0.1] 4687
 got [GET /quatsch]
/# _

Hier wird also genau registriert ob man Quatsch macht. Jetzt versuchen wir zu hacken indem wir zwei Verzeichnisse höher auslesen wollen.

/# quark http://localhost/../../

Entgegen aller Sicherheitsregeln bei Server können wir höher als das HTTPD-Root-Verzeichnis gehen. Wir können uns so jede Datei herunterladen. So z. B.

/# quark http://localhost/../../etc/passwd

Eine Freude für jeden Systemadministrator. Dieser WWW-Server ist also nur zum Test oder für Schulungen geeignet. PYGMY hat noch einen weiteren Nachteil. Er kann pro GET-Anforderung nur eine Datei senden. Meist besteht aber gehören zu einer HTML-Datei noch weitere Dateien, wie z. B. Grafiken. Diese könnten dann nur über ein Reload beim Browser geladen werden.

[Back] [Home] [Forward]      
Robert.Warnke@giso.de (copyleft) Robert Warnke, Berlin (Germany) | http://rowa.giso.de
  
Linux-Kernelprogrammierung. Algorithmen und Strukturen der Version 2.4 (Gebundene Ausgabe)
von Michael Beck
Siehe auch:
Linux-Treiber entwickeln
von Jürgen Quade
Building Embedded Linux Systems. Concepts, techniques, tricks, and traps.
von Karim Yaghmour
Linux Device Drivers.
von Jonathan Corbet
Linux-Kernel Handbuch. Leitfaden zu Design und Implementierung von Kernel 2.6 (Open Source Library)
von Robert Love
 
    
     

Back to the topic site:
StudyPaper.com/Startseite/Computer/Informatik

External Links to this site are permitted without prior consent.
   
  Home  |  deutsch  |  Set bookmark  |  Send a friend a link  |  Copyright ©  |  Impressum