LDP
/
LDP
mirror of https://github.com/tLDP/LDP
0
1
Fork 0
Code Releases Activity

updated

This commit is contained in:
gferg 2003-09-30 14:08:04 +00:00
parent dd60333953
commit b9a6794691
4 changed files with 209 additions and 78 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

91
LDP/howto/docbook/Apache-WebDAV-LDAP-HOWTO.xml
View File

@ -23,6 +23,15 @@
<revhistory>
<revision>
<revnumber>v4.1.1</revnumber>
<date>2003-09-29</date>
<authorinitials>sa</authorinitials>
<revremark>
Updated the SSL section based on the feedback received from readers.
</revremark>
</revision>
<revision>
<revnumber>v4.1.0</revnumber>
<date>2003-09-02</date>
@ -668,7 +677,88 @@ The following is a over-simplified structure of the layers involved in SSL.
<para><emphasis role="strong">Message Digest</emphasis> The server uses message digest algoritm such as HMAC, SHA, MD5 to verify the integrity of the transferred data.</para>
</sect3>
<sect3><title>Ensuring Authenticity and Integrity</title>
<para>Encryption Process</para>
<screen>
Sender's Receiver's
PrivateKey PublicKey
,-. ,-.
( ).......... ( )..........
`-' ''''|'|'|| `-' ''''''''||
| | |
| | |
.----------. | | .----------. | .----------.
| | V | | | V | |
|Clear Text|--------->|CipherText|--------->|CipherText|
| | Step1 | 1 | Step2 | 2 |\
`----------' | `----------' `----------' \ __
| | \ [_'
| | step5 \ |
|Step3 | __ --|--
| | _.--' |
V | _..-'' / \
.---------. | .---------. _..-'' Receiver
| SHA 1 | V | Digital | _..-''
|MsgDigest|--------->|Signature|' _
`---------' Step4 `---------' _ (_)
_____ ____ ____ ____ _ _ ____ _| |_ _ ___ ____
| ___ | _ \ / ___)/ ___) | | | _ (_ _) |/ _ \| _ \
| ____| | | ( (___| | | |_| | |_| || |_| | |_| | | | |
|_____)_| |_|\____)_| \__ | __/ \__)_|\___/|_| |_|
(____/|_|
</screen>
<itemizedlist mark='opencircle'>
<listitem><para>Step1: In this step the Original "Clear Text" message is encrypted using the Sender's Private Key, which results in Cipher Text 1. This ensures the Authenticity of the sender.</para></listitem>
<listitem><para>Step2: In this step the "CipherText 1" is encrypted using Receiver's Public Key resulting in "CipherText 2". This will ensure the Authenticity of the Receiver i.e. only the Receiver can decipher the Messsage using his Private Key.</para></listitem>
<listitem><para>Step3: Here the SHA1 Message Digest of the "Clear Text" is created.</para></listitem>
<listitem><para>Step4: SHA1 Message Digest is then encrypted using Sender's Private Key resulting in the Digital Signature of the "ClearText". This Digital Signature can be used by the receiver to ensure the Integrity of the message and authenticity of the Sender.</para></listitem>
<listitem><para>Step5: The "Digital Signature" and the "CipherText 2" are then send to the Receiver.</para></listitem>
</itemizedlist>
<para>Decryption Process</para>
<screen>
Receiver's Sender's
PrivateKey PublicKey
,-. ,-.
( ).......... ( )..........
`-' ''''''''|| `-' '''''''|||
| | |
| | |
.----------. | .----------. | | .----------.
| | V | | V | | | .---#1----.
|CipherText|--------->|CipherText|--------->|ClearText |------>| SHA 1 |
| 2 | Step1 | 1 | Step2 | | | Step3 |MsgDigest|
`----------' `----------' | `----------' `---------'
| ||
| ||Step5
| ||
| ||
.---------. | .---------.
| Digital | V | SHA 1 |
|Signature|---------------------->|MsgDigest|
_ `---------' Step4 _ `---#2----'
| | _ (_)
__| |_____ ____ ____ _ _ ____ _| |_ _ ___ ____
/ _ | ___ |/ ___)/ ___) | | | _ (_ _) |/ _ \| _ \
( (_| | ____( (___| | | |_| | |_| || |_| | |_| | | | |
\____|_____)\____)_| \__ | __/ \__)_|\___/|_| |_|
(____/|_|
</screen>
<itemizedlist mark='opencircle'>
<listitem><para>Step1: In this step the "CipherText 2" message is decrypted using the Receiver's Private Key, which results in Cipher Text 1.</para></listitem>
<listitem><para>Step2: In this step the "CipherText 1" is decrypted using Sender's Public Key resulting in "ClearText".</para></listitem>
<listitem><para>Step3: Here the SHA1 Message Digest of the "Clear Text" is created.</para></listitem>
<listitem><para>Step4: The "Digital Signature" is then decrypted using Sender's Public Key, resulting the "SHA 1 MSG Digest".</para></listitem>
<listitem><para>Step5: The "SHA1 MsgDigest #1" is then compared against "SHA1 MsgDigest #2". If they are equal, the data was not modified during transmission, and the integrity of the Original "Clear Text" has been maintained</para></listitem>
</itemizedlist>
</sect3>
</sect2>
<sect2><title>Test Certificates</title>
@ -1001,3 +1091,4 @@ One way to secure the decrypted Private Key is to make readable only by the root
</article>

2
LDP/howto/docbook/HOWTO-INDEX/howtoChap.sgml
View File

@ -4551,7 +4551,7 @@ implementation, plus auxiliary packages like Ghostscript. </Para>
Text-Terminal-HOWTO</ULink>,
<CiteTitle>Text-Terminal HOWTO</CiteTitle>
</Para><Para>
<CiteTitle>Updated: January 2003</CiteTitle>.
<CiteTitle>Updated: September 2003</CiteTitle>.
Explains what text terminals are, how they work, how to install and
configure them, and provides some info on how to repair them. </Para>
</ListItem>

2
LDP/howto/docbook/HOWTO-INDEX/hwSect.sgml
View File

@ -322,7 +322,7 @@ virtual User-Mode Linux (UML) machines. </Para>
Text-Terminal-HOWTO</ULink>,
<CiteTitle>Text-Terminal HOWTO</CiteTitle>
</Para><Para>
<CiteTitle>Updated: January 2003</CiteTitle>.
<CiteTitle>Updated: September 2003</CiteTitle>.
Explains what text terminals are, how they work, how to install and
configure them, and provides some info on how to repair them. </Para>
</ListItem>

192
LDP/howto/linuxdoc/Text-Terminal-HOWTO.sgml
View File

@ -1,11 +1,15 @@
<!doctype linuxdoc system>
<article>
<title> Text-Terminal-HOWTO
<author> David S. Lawyer <url url="mailto:dave@lafn.org">
<date> v1.31, January 2003
<date> v1.32, September 2003
<!--
Change log:
v1.32: Sept. 2003: man page console_codes, name: serial
monitor/console, "init string" rewrite, netrik text browser, new url
for terminfo
v1.31 Jan. 2003: more on printer port, error char. appearance, devfs,
removed all mention of obsolete /dev/cua, pin numbering, new
X-Terminal HOWTO, Hydra date is 1998 (not 1988), edited thin clients
@ -124,7 +128,7 @@ provided that you:
<item> If it's not a translation: Email a copy of your derivative work
(in a format LDP accepts) to the author(s) and maintainer (could be
the same person). If you don't get a response then email the LDP
(Linux Documentation Project): submit@linuxdoc.org.
(Linux Documentation Project): submit@en.tldp.org.
<item>License the derivative work in the spirit of this license or use
GPL. Include a copyright notice and at least a pointer to the
license used.
@ -186,7 +190,7 @@ url="http://tldp.org/mirrors.html">. Various formats are
available. If you only want to quickly check the date of the latest
version look at <url
url="http://tldp.org/HOWTO/Text-Terminal-HOWTO.html">. The
version your are currently reading is: v1.31, January 2003 .
version your are currently reading is: v1.32, September 2003 .
<sect1>New in Recent Versions:
<p> For a full revision history going back to the first version see
@ -194,6 +198,9 @@ the source file (in linuxdoc format) at <url
url="http://www.ibiblio.org/pub/linux/docs/HOWTO/other-formats/sgml/Text-Terminal-HOWTO.sgml.gz">.
<itemize>
v1.32: September 2003: man page console_codes, name: serial
monitor/console, "init string" rewrite, netrik text browser, new url
for terminfo
<item>v1.31 Jan. 2003: more on printer port, error char. appearance,
devfs, removed all mention of obsolete /dev/cua, pin numbering, new
X-Terminal HOWTO, Hydra date is 1998 (not 1988), edited thin clients
@ -336,12 +343,15 @@ asynchronous serial ports (RS-232-C = EIA-232-D) of the host computer
and the terminal. Sometimes the connection is via modem or terminal
server, etc.
Other names for text terminals are "dumb terminal", "serial terminal",
Other names for text terminals are "serial monitor", "serial console"
(if it's used like a console), "serial terminal", "dumb terminal",
"character-cell terminal", "character terminal", "ASCII/ANSI
terminal", "asynchronous terminal", "data terminal", "video terminal",
"video display terminal" (VDT), and "green terminal" (since many used
green displays). In olden days "video display unit" (VDU) was used
for terminals but strictly speaking, it excludes the keyboard.
green displays). The names "serial monitor" and "serial console" may
refer to a PC that is running a program to emulate a text terminal.
In olden days "video display unit" (VDU) meant text terminal but
strictly speaking, it excludes the keyboard.
"Block mode" was used exclusively by old IBM mainframe terminals but
many modern terminals also have this capability (which is not used
@ -965,35 +975,42 @@ permission on /dev/ttyS1. Similarly, typing "cat my_file >
<sect1>Pseudo Terminals
<p> Pseudo terminals are pairs of devices such as /dev/pty/m3
(formerly /dev/ptyp3) and /dev/pty/s3 (formerly /dev/ttyp3). There is
no physical device directly associated with either of them, not even a
serial port connector. But if a program treats s3 (ttyp3) like it was a
serial port, what is read and written to that port appears on the
other member of the pair m3 (ptyp3) which another program uses to read
and write to. Thus two programs talk to each other via this method
and one program (on s3=ttyp3) thinks it's talking to a serial port.
and /dev/pty/s3 (or respectively /dev/ptyp3 and /dev/ttyp3 if you're
not using the device filesystem). There is no physical device
directly associated with either of them, not even a serial port
connector. But if a program treats s3 (ttyp3) like it was a serial
port, what is read and written to that port appears on the other
member of the pair m3 (ptyp3) which another program uses to read and
write to. Thus two programs talk to each other via this method and
one program (on s3=ttyp3) thinks it's talking to a serial port. It's
something like a "pipe" between m3 and s3.
You can't just take a pair of programs and make them talk to each
other this way without modifying the source C code of one of the pair
(for example, the one that talks to m3). Thus it's mainly
For talking to s3 (ttyp3), any program designed to talk to a serial
port will do. But for the other program that talks to m3 (ptyp3) it
must have been specially written to talk to m3. It's mainly
programmers that must concern themselves with pseudo terminals and
most users don't need to worry about them.
For example, if someone connects via telnet to your computer over a
network, they may wind up connected to the device m2 (ptyp2) (a pseudo
terminal port). The login process logs them in to s2 (ttyp2). Here
the login program and the telnet program talk to each other via a
Here's an example: If someone connects via telnet to your computer
over a network, the part of the telnet program handling this
connection on your computer may wind up connected to the device m2
(ptyp2) (a pseudo terminal port). A getty program should be running
on the corresponding s2 (ttyp2). When telnet gets a character from
the remote, it goes thru m2 to s2 to getty which then sends back "login:"
routed to s2, m2, your telnet program, and then out to the network.
Here the login program and the telnet program talk to each other via a
"pseudo terminal". In X Window, the terminal emulator program, xterm
(or rxvt), uses pseudo terminals. Ham radio programs under Linux also
use them. Using certain application software it is possible to have 2
or more pseudo terminals attached to the same physical serial port.
use them. By using certain application software, it is possible to
have 2 or more pseudo terminals attached to the same physical serial
port.
For a pseudo terminal pair such as m3 (ptyp3) and s3 (ttyp3), the m...
(pty...) is the master or controlling terminal and the s... (tty...)
is the slave. The device filesystem notation makes this clear (m is
for master, s is for slave). The slave is like a serial port so think
of s as also standing for serial. In the old notation, tty.. is like a
serial port ttyS (which in olden days was just tty).
for master, s is for slave). The slave is like a serial port so also
think of s as standing for "serial". In the old notation, tty.. is
like a serial port ttyS (which in olden days was just tty).
Prior to the device filesystem a complex notation was used in order
to get a large number of pseudo terminals. There are only 16 ttyp's:
@ -1018,11 +1035,12 @@ automatically created as /dev/pts/3. It thus supplies a pty on demand.
The /dev/pts directory is considered to be a file system of type
devpts and appears in the lists of mounted filesystems. While the
"file" /dev/pts/3 looks like it would be an entry in the device
filesystem, it's really a wholly different filesystem.
filesystem, it's really a wholly different kind of filesystem.
While other unix-like systems have a manual page for pseudo terminals
(may be named "pty") Linux lacks one. A page devoted to only to
pseudo terminals is needed for Linux. There is both a Linux pty
(may be named "pty") Linux lacks one for the general user. But there
is a man-page for programmers: (openpty or forkpty) which assumes that
you already understand pseudo terminals. There is both a Linux pty
module and a /usr/include/pty.h file.
<sect1> The Controlling Terminal /dev/tty
@ -1493,8 +1511,9 @@ may be programmed to send out a sequence of bytes (characters). See
an escape sequence is sent to the host to tell it where the mouse is.
For a mouse on VT terminals see <url
url="http://www.cs.utk.edu/~shuford/terminal/dec_vt_mouse.html"> These
escape codes for mice are called "DEC Locator sequences". Do any
linux applications support this ?? Which text-terminals have it ??
escape codes for mice are called "DEC Locator sequences". The FALCO
Infinity Series of terminals, model ANSI-G supports it. Do any linux
applications support this ??
<sect> Terminal Emulation (including the Console) <label id="term_emulation">
@ -1594,13 +1613,14 @@ url="http://ibiblio.unc.edu/pub/Linux/utils/console/">
<sect1> The Linux Console <label id="console_">
<p> The console for a PC Linux system is normally the computer monitor
in text mode. It emulates a terminal of type "Linux". There is no
way (unless you want to spend weeks rewriting the kernel code) to get
it to emulate anything else. Setting the TERM environment variable to
type of terminal other than "Linux" will not result in emulating that
other terminal. It will only result in a corrupted interface since
you have falsely declared (via the TERM variable) that your "terminal"
is of a type different from what it actually is. See <ref
in text mode. It emulates a terminal of type "Linux" and the escape
sequences it uses are in the man page: console_codes. There is no way
(unless you want to spend weeks rewriting the kernel code) to get it
to emulate anything else. Setting the TERM environment variable to
any type of terminal other than "Linux" will not result in emulating
that other terminal. It will only result in a corrupted interface
since you have falsely declared (via the TERM variable) that your
"terminal" is of a type different from what it actually is. See <ref
id="term_not_for_emulation" name="Don't Use TERM For Emulation">
In some cases, the console for a Linux PC is a text-terminal. One may
@ -2105,7 +2125,7 @@ DCD Carrier Detect 1 <--|
DSR Data Set Ready 6 <--|- 20 DTR Data Terminal Ready
RTS Request To Send 7 ----> 5 CTS Clear To Send
CTS Clear To Send 8 <---- 4 RTS Request To Send
(RI Ring Indicator 9 (not needed)
RI Ring Indicator 9 (not needed)
</verb></tscreen>
(Yes, the pins 2 and 3 really do have opposite meanings for DB9 and
DB25 connectors!)
@ -2545,10 +2565,20 @@ One advantage of making your own cable is that the skills you learn
will come in handy if a cable breaks (or goes bad) or if you need to
make up another cable in a hurry.
<sect2> Pin numbers
<p> The numbers of the pins should be engraved in the plastic of the
connector. Each pin should have a number next to it. You may need a
magnifying glass to read them.
<sect2> Pin numbers of 9 and 25 pin connectors
<p> The pin numbers are often engraved in the plastic of the
connector but you may need a magnifying glass to read them.
Note DCD is sometimes labeled CD. The numbering of the pins on a
female connector is read from right to left, starting with 1 in the
upper right corner (instead of 1 in the upper left corner for the male
connector as shown below). --> direction is out of PC.
<tscreen><verb>
___________ ________________________________________
\1 2 3 4 5/ Looking at pins \1 2 3 4 5 6 7 8 9 10 11 12 13/
\6 7 8 9/ on male connector \14 15 16 17 18 19 20 21 22 23 24 25/
------ -----------------------------------
</verb></tscreen>
<sect2> Installing DB connectors on cable ends <label id="db_conn_install">
<p> See <ref id="db_conn" name="DB Connectors"> for a brief description
@ -3501,9 +3531,9 @@ signal ground) you should let getty know this by using a "local" flag.
The format of this depends on which getty you use.
<sect2> Getty exits after login (and can respawn)
<!-- getty_seq.H begin (in MM, TT)
<!-- getty_seq.D begin (in MM, TT)
This is the sequence of events that happens after getty starts up.
<sect2> Getty "exits" after login (and can respawn).
<sect2> How getty respawns
-->
<p>After you log in you will notice (by using "top", "ps -ax", or
"ptree") that the getty process is no longer running. What happened
@ -3519,7 +3549,7 @@ replaces the login process. Note that one process replaces another
and that the bash shell process originally started as the getty
process. The implications of this will be explained below.
Now in the /etc/inittab file getty is supposed to respawn (restart) if
Now in the /etc/inittab file, getty is supposed to respawn (restart) if
killed. It says so on the line that calls getty. But if the bash shell
(or the login process) is killed, getty respawns (restarts). Why?
Well, both the login process and bash are replacements for getty and
@ -3771,7 +3801,8 @@ Nov. 2002 Debian's /var/lib/serial.conf
are some minor differences, depending on which HOWTO it appears in.
<sect2> Introduction
<p> If you have a Laptop (PCMCIA) don't use <tt/setserial/ until you
<p>
If you have a Laptop (PCMCIA) don't use <tt/setserial/ until you
read <ref id="laptops_" name="Laptops: PCMCIA">. <tt/setserial/ is a
program which allows you to tell the device driver software the I/O
address of the serial port, which interrupt (IRQ) is set in the port's
@ -4459,14 +4490,15 @@ fi
</code>
<sect1> Character Mapping: mapchan <label id="mapchan_">
<p> There is a program named "mapchan" which will map characters
(bytes) typed at a terminal keyboard (input) into different
characters per a user-supplied mapping table. It can also map
characters which are sent to the screen (output). This is nice for
remapping the keyboard for foreign language alphabets. Most
distributions don't seem to supply it (let me know if any do). Source
code by Yura Kalinichenko (Ukraine) is at <url
url="http://www.kron.vinnica.ua/free/download/">
<p> There is a free program named "mapchan" which will map characters
(bytes) typed at a terminal keyboard (input) into different characters
per a user-supplied mapping table. It can also map characters which
are sent to the screen (output). This is nice for remapping the
keyboard for foreign language alphabets. Most distributions don't
seem to supply it (let me know if any do). Source code by Yura
Kalinichenko (Ukraine, but in Russian with English manual) was at
"http://www.kron.vinnica.ua/free/download/" but this link is dead in
2003.
<sect>Terminfo and Termcap (detailed) <label id="termcap2">
@ -4558,7 +4590,7 @@ termcap(5) for the format required to create (or modify) these source
files. The file terminfo.src may be in various locations on your
computer or it may not be included with your Linux distribution. Use
the <tt/locate/ command to try to find it. It is available on the web
at <url url="http://www.tuxedo.org/terminfo/">.
at <url url="http://catb.org/terminfo/">.
<sect2> Terminfo Compiler (tic) <label id="tic">
<p> The data in the source files is compiled with the "tic" program
@ -4639,19 +4671,21 @@ noted at the start of the source file for terminfo (or termcap).
<p> Included in the terminfo are often a couple of initialization
strings which may be sent to the terminal to initialize it. This may
change the appearance of the screen, change what mode the terminal is
in, and/or make the terminal emulate another terminal. An
initialization string is not automatically sent to the terminal to
initialize it. One might expect that the getty program should do this
but if it did, one could make a change to the set-up at the terminal
and this change wouldn't be happen because the init string would
automatically cancel it. Application programs don't seem to
initialize either. To do this you must use a command given on the
command line (or in a shell script such as /etc/profile) to send the
init strings. Such commands are: "tset", "tput init", or "setterm
-initialize". Sometimes there is no need to send the init strings
since the terminal may set itself up correctly when it is powered on
(using options/preferences one has set up and saved in the
non-volatile memory of the terminal).
in, and/or make the terminal emulate another terminal. No
initialization string is automatically sent to the terminal to
initialize it. One might expect that the getty program should do
this. If it did, one could make a change to the set-up stored inside
the terminal but this change wouldn't happen because the init string
would override it. Application programs don't seem to initialize
(send an init string per terminfo) either.
To actually send an init string you must use a command given on the
command line (or in a shell script such as /etc/profile). Such
commands are: "tset", "tput init", or "setterm -initialize".
Sometimes there is no need to send an init string since the terminal
may set itself up correctly when it is powered on (using
options/preferences one has set up and saved in the non-volatile
memory of the terminal).
<sect1> TERM Variable <label id="term_var">
<p> The Environment variable TERM should be set to the name of
@ -4699,7 +4733,7 @@ sends the init string and sets TERM to this terminal name (type).
/etc/termcap have info about various versions of termcap files,
naming conventions for terminals, and special capabilities code named
u6-u9. If you don't have one, go to <url
url="http://tuxedo.org/terminfo/">
url="http://catb.org/terminfo/">
<item> "Termcap and Terminfo" is a book published by O'Reilly in
1988.
</itemize>
@ -5291,9 +5325,10 @@ switching runlevels may vary.
<sect1>Browsers for Terminals
<p>The "lynx" browser works correctly with all text terminals. There
are two other text browsers: "w3m" and "links" that only work with the
Linux console or vt100 terminals. For "links", you must set your
terminal to 8-bits with no parity. All 3 are available in versions
that support ssl (secure socket layer) for encoded communication.
Linux console, xterm, or vt100 terminals. The "netrik" browser
requires a color terminal. For "links", you must set your terminal to
8-bits with no parity. All (including netrik ??) support ssl
(secure socket layer) for encoded communication.
"w3m" and "links" overcome some of the "lynx" deficiencies. They can
usually display tables better and can display frames side-by-side.
@ -5305,8 +5340,13 @@ disappear from the screen. So in some cases, using "lynx" may be
better.
Unfortunately "w3m" and "links" don't have numbered links like lynx
does nor do they have good support for cookies. Of these these 3 text
browsers only "links" supports Javascript.
does, nor do they have good support for cookies. None of the text
browsers as yet have good support for Javascript, but some are
allegedly working on it (as of 2003). Links and netrik currently have
only partial support for Javascript.
There are still other text browser projects. Some of them seem to be
dead.
<sect> Special Uses for a Terminal
<sect1>Make a Serial Terminal the Console <label id="term_as_console">
@ -5663,8 +5703,8 @@ sections show possible causes and fixes.
<sect2>Getty line in /etc/inittab file incorrect
<p>Make sure the the line which calls getty in /etc/inittab is
correct. A typo in ttySx (or DTxxxx for uugetty) may cause this
problem.
correct. A typo in "ttySx" (or "DTxxxx" for uugetty) or in "getty"
may cause this problem.
<sect2> No modem control signal
<p> If the terminal doesn't send the PC a CD signal on one of the pins