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

updated

This commit is contained in:
gferg 2000-11-05 17:56:43 +00:00
parent 9a5c0dd907
commit bb244863d2
7 changed files with 1816 additions and 1158 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1862
LDP/howto/linuxdoc/Ecology-HOWTO.sgml
View File

File diff suppressed because it is too large Load Diff

358
LDP/howto/linuxdoc/FBB.sgml
View File

@ -6,7 +6,7 @@
<title>FBB Packet-radio BBS mini-HOWTO
<author>Miroslav "Misko" Skoric, YT7MPB,
<tt/m.skoric@eunet.yu/
<date>v1.0, 19 September 2000
<date>v1.2, 05 October 2000
<abstract>
<nidx>linux windows nt amateur packet radio</nidx>
This mini-HOWTO covers the installation and use of
@ -25,8 +25,8 @@ connecting computers via amateur radio stations.
<p>
I have been using FBB amateur radio software since
early nineties. It was the time of DOS operating
system, so most of us, system administrators (so
called system operators - sysop's) used various
system, so most of us, system administrators (or, so
called system operators - sysop's), used various
packet radio software for DOS. Versions of FBB
packet radio BBS software for DOS, today are
known as DosFBB.
@ -47,21 +47,23 @@ their client software under DOS, Windows, Linux
or any other operating system that offer amateur
packet radio abilities.
<p>Two years ago, after I got my new Pentium 166
box with 32 MB of RAM and VGA color graphics, I
<p>Two years ago, after I got my new box, Pentium 166
with 32 MB of RAM and VGA color graphics, I
switched to a Windows version of FBB (so called
WinFBB). Author of the software, an radio amateur
from France, Jean-Paul F6FBB, made several
versions of WinFBB, including 16 bit and 32 bit
versions for Windows 3.x and Windows 9x and NT.
versions of WinFBB, including 16 bit variant for
Windows 3.x and Windows 9x as well as 32 bit variant for
Windows NT. I have run both versions until now
(at the moment it is WinFBB v7.00g25 under Windows
NT 4.0).
<p>I have run both versions until now (WinFBB
v7.00g25 under Windows NT 4.0). The main
<p>The main
difference between DosFBB and WinFBB is that the
second one offers you to do other jobs with your
computer while FBB runs as just one of several
applications. Beside that, it is always nice to
copy a text from another application (for example
computer, while FBB is running as just any other
application. Beside that, it is always nice to
copy a text from another application (for example,
from an Internet email) and to paste it into a
packet radio message.
@ -72,7 +74,7 @@ disk that has enough room to try Linux...
<sect>INSTALLATION
<p>
<sect1>How to install X11 version of LinFBB
<sect1>How to install X11 (Xwindows) version of LinFBB
<p>
<itemize>
@ -84,43 +86,46 @@ disk that has enough room to try Linux...
<p>
<item>Download or copy LinFBB (the main ftp site
is ftp.f6fbb.org but there are many mirror
is <url url="http://ftp.f6fbb.org/" name=
"ftp.f6fbb.org"> but there are many mirror
sites too). For example, if you get a file
like x700e_full.tgz it means that it is X11
version 7.00e and it contains all you need
in tgz archive to install the BBS. On the
other hand, name like xd700g_full.tgz means
that it is not X11 but daemon version 7.00g
like <tscreen><verb>x700e_full.tgz</verb></tscreen>
it means that it is X11 version 7.00e and it
contains all you need in tgz archive to install
the BBS. On the other hand, a name like
<tscreen><verb>xd700g_full.tgz</verb></tscreen>
means that it is not X11 but daemon version 7.00g
and it is also complete to unpack. Further,
x700f01.tgz and x700g.tgz are "upgrades" to
any previous "full" package.
<tscreen><verb>x700f01.tgz</verb></tscreen>
and <tscreen><verb>x700g.tgz</verb></tscreen>
are "upgrades" to any previous "full" package.
<p>
<item>Copy the archive file in /tmp directory.
<item>Copy the archive file in <bf>/tmp</bf> directory.
<p>
<item>You have to make a "base" directory where
your FBB will be installed. For example you
may type: mkdir /usr/local/fbb if you want
may type: <bf>mkdir /usr/local/fbb</bf> if you want
FBB to be there. You have to be logged as
'root' or 'superuser' to install FBB.
<p>
<item>Then, you should locate yourself in that
directory: cd /usr/local/fbb.
directory: <bf>cd /usr/local/fbb</bf>.
<p>
<item>Now, you should unpack the archive:
tar xvzf /tmp/x700b25.tgz (<-- use the right
<bf>tar xvzf /tmp/x700b25.tgz</bf> (<-- use the right
name of the archive here).
<p>
<item>When you finished unpacking the archive,
you may continue installing the software:
./install.sh is the command for that. The
<bf>./install.sh</bf> is the command for that. The
setup will ask you for the 'base' directory
where FBB will be installed. If you chose
/usr/local/fbb again, you will be told that
<bf>/usr/local/fbb</bf> again, you will be told that
such directory already exists and all files
will be overwritten. It is ok, so you should
answer yes. If everything is ok, you should
@ -129,19 +134,19 @@ disk that has enough room to try Linux...
of that procedure, program will ask you for
bbs's callsign, name of the city, QTH
locator, your name etc. That details will
become a part of /usr/local/fbb/init.srv
become a part of <bf>/usr/local/fbb/init.srv</bf>
file.
<p>
<item>Beside that, you MUST check this file
again manualy and fix other details if
<bf>again</bf> manually and fix other details if
needed (because installation script does
not fix all parts of init.srv).
<p>
<item>Well, so far - so good. After you checked
all configuration files, you may start the
software: ./xfbb.sh (<-- type this within
software: <bf>./xfbb.sh</bf> (<-- type this within
an xterm or something similar). When you
start FBB for the first time, it will ask
you to create some files it needs, so you
@ -207,10 +212,10 @@ exchange last time (and vice versa). </em>
be renamed:
<p>
init.srv -> init_w.srv
<tscreen><verb>init.srv -> init_w.srv
forward.sys -> forw_w.sys
port.sys -> port_w.sys
protect.sys -> prot_w.sys
protect.sys -> prot_w.sys</verb></tscreen>
<p>
FBB is able to recognize those changes.
@ -228,22 +233,22 @@ exchange last time (and vice versa). </em>
<p>
<item>Mount a shared FAT directory:
mount vfat /dev/hda2 /mnt/win
<bf>mount -t vfat /dev/hda2 /mnt/win</bf>
<p>
<item>Copy LinFBB archive to /tmp directory.
<item>Copy LinFBB archive to <bf>/tmp</bf> directory.
<p>
<item>Locate yourself to a 'base' directory:
cd /usr/local/fbb (for example).
<bf>cd /usr/local/fbb</bf> (for example).
<p>
<item>Unpack the archive: tar xvzf /tmp/filename.
<item>Unpack the archive: <bf>tar xvzf /tmp/filename</bf>.
<p>
<item>Start the installation script ./install.sh
<item>Start the installation script <bf>./install.sh</bf>
and, after asked for the 'base' installation
directory, chose /usr/local/fbb. Doesn't
directory, chose <bf>/usr/local/fbb</bf>. Doesn't
matter if the program warns you that such
directory already exists so existing files
will be overwritten (by the way, if you
@ -254,47 +259,280 @@ exchange last time (and vice versa). </em>
like before).
<p>
<item>Copy /usr/local/fbb to /mnt/win/fbb but do
not over-write existing files with files
with same names.
<item>Copy <bf>/usr/local/fbb</bf> to <bf>/mnt/win/fbb</bf> but do
*not* over-write existing files with new files
having the same names.
<p>
<item>Copy /mnt/win/fbb/init_w.srv to a file
/mnt/win/fbb/init_l.srv
<item>Copy <bf>/mnt/win/fbb/init_w.srv</bf> to a file
<bf>/mnt/win/fbb/init_l.srv</bf>
<p>
<item>Edit /mnt/win/fbb/init_l.srv to what is
<item>Edit <bf>/mnt/win/fbb/init_l.srv</bf> to what is
needed for Linux. You may use the existing
file /mnt/win/fbb/init.srv as an example.
file <bf>/mnt/win/fbb/init.srv</bf> as an example.
<p>
<item>Copy newly edited /mnt/win/fbb/init_l.srv
over the /mnt/win/fbb/init.srv (if you do
not do that, maybe you can't start LinFBB
using ./xfbb.sh , like me).
<item>Copy newly edited <bf>/mnt/win/fbb/init_l.srv</bf>
over the <bf>/mnt/win/fbb/init.srv</bf> (if you do
not do that, maybe you couldn't start LinFBB
using <bf>./xfbb.sh</bf> , like me).
<p>
<item>Copy /mnt/win/fbb/system/port_w.sys to
/mnt/win/fbb/system/port_l.sys file.
<item>Copy <bf>/mnt/win/fbb/system/port_w.sys</bf> to
<bf>/mnt/win/fbb/system/port_l.sys</bf> file.
<p>
<item>Edit /mnt/win/fbb/system/port_l.sys to
<item>Edit <bf>/mnt/win/fbb/system/port_l.sys</bf> to
what is needed for Linux. You may use the
existing file /mnt/win/fbb/system/port.sys
existing file <bf>/mnt/win/fbb/system/port.sys</bf>
as an example.
<p>
<item>Edit /mnt/win/fbb/xfbb.sh in order to fix
<item>Edit <bf>/mnt/win/fbb/xfbb.sh</bf> in order to fix
the right path.
<p>
<item>Start the script ./xfbb.sh to run LinFBB.
<item>Ensure that you are in FBB's main directory:
<bf>cd /mnt/win/fbb</bf> (for example).
<p>
<item>Start the script <bf>./xfbb.sh</bf> to run LinFBB.
If everything is ok, LinFBB under Linux
should run with the same parameters as
WinFBB do under Windows.
WinFBB does under Windows.
</itemize>
<p>
<sect1>How to install Protus password utility
<p>
<em>Notice: Well, I have been using Protus
connection filters for a long time now. At
first, it was version 3.1/1.2 for DosFBB515c
and, later, version 3.3 for Dos/WinFBB700.
I have found Protus as very useful utility
because of its implementation of BBS-to-BBS
forwarding protection using MD2 algorythm.
One of the reasons I am going to cover Protus
in this document is a fact that its author
haven't made a manual in english yet. I keep
trying to translate the original manuals
from spanish into english, but it is a hard
process. Any good 'spanish-to-english'
translator is welcomed to contact me.</em>
<p>
Protus offers several interesting features:
<p>
<itemize>
<item>It can send a presentation message to
all users, informing about possibility
to make users' access more safe,
<p>
<item>It can send messages to users who have
normal access, informing about utility's
existence,
<p>
<item>It can send messages to users who have no
valid access (before disconnecting them),
<p>
<item>It can send messages to new users who have
connected for the first time, informing
them about the password utility.
<p>
<item>It can send messages to users who entered
wrong password (before disconnecting them),
<p>
<item>It can inform sysop about quite everything
related to users' connections (new user on
the system, unsuccessful connections etc),
<p>
<item>Messages mentioned above could be translated
into various languages, similar to various
languages FBB uses,
<p>
<item>Messages mentioned above could be different
for different BBS ports,
<p>
<item>Protus could be activated/deactivated at various
intervals of time using CRON.SYS system file,
<p>
<item>Passwords could be remotely managed, using an
external server developed by Jose EB5IVB,
<p>
<item>...
</itemize>
<p>
Let's see what should be done in order to
implement secure access to the FBB packet
radio BBS, using Protus type of <em>c_filter</em>:
<p>
<itemize>
<item>Users of Dos/WinFBB versions of Protus
already know that it is needed to create a new
directory <bf>\FBB\PROTUS</bf> where several *.PRT
files should be placed. In addition, the
main C_FILT*.DLL files should be copied
into <bf>\FBB\BIN</bf> as well as a couple of "system",
i.e. config *.PRT files that are going to be
within <bf>\FBB\SYSTEM</bf> directory.
<p>
<item>After the sysop has copied all files into
the proper locations, it is needed to make
some configuration. The most important files
are two "system" ones: <tt>CONFIG.PRT</tt> and <tt>USERS.PRT</tt>
that should be carefully adopted to any
particular situation. Other *.PRT files will
work as they are in original, but they might
be translated because they are originated
in spanish (those files are just textual
information that are sent to users who
connect to the BBS). For your information,
I usualy don't care much about, because my
BBS's are so called "open systems". It means
they work quite normal for all users in the
same way as they worked before using Protus.
Only a couple of callsigns have password
implemented and, when connecting, they know
what they are doing, so, they don't need
any additional info. Your mileage may vary.
<p>
<item>So far - so good. When everything mentioned is
done, you have to restart your FBB in order
for Protus utility to be activated. In all
connections to your BBS (including console),
you should see a line like this: <bf>{PROTUS-4.0}</bf>
just after a line [FBB-7.00-AB1FHMRX$]. It
only designates that Protus is active on the
system. Users of your system who don't have
their password, connect normally as before.
Users who's callsigns have password implemented,
are prompted for password just after connections.
<p>
<item>The author of Protus, Jesus EB5AGF, has made
several working "modes" of its utility. It
is possible for users to have various kinds
of security: a fixed phrase as a password
(similar when you connect to the Internet
via telephone line, but this way the phrase
can be masqueraded within the longer answer);
a changeable answer to the 5 numbers (just
like usual FBB sysop's password); a mode
that uses automatic answer from user's client
packet programs; implementation of MD2 and
MD5 algorythms; FBB-to-FBB automatic forward
protection etc.
<p>
<item>Well, the situation regarding the position
of files under LinFBB is somewhat different.
I have become used to the directory structure
that DosFBB and WinFBB versions of Protus have
been using, so I considered that it was enough
just to copy the same directory structure when
I wanted to implement Protus under LinFBB. It
was wrong. After I have pulled out the
remaining hair, the thing started to work, so
now I am going to tell you what to do.
<p>
<item>I think I have already told you that I have
been running here both WinFBB under Windows NT
and LinFBB under Linux (see also <tt>Linux+WinNT
mini-HOWTO</tt> and <tt>Lilo mini-HOWTO</tt>). That means
all Protus stuff has already been installed,
except Linux executable of <em>c_filter</em> file. I
put that file into <bf>/fbb/bin</bf> directory and,
after the next restart of LinFBB, I got the
info mentioned above: {PROTUS-4.0}. But the
password protection was not likely to work.
I was told to make a new directory <bf>/var/ax25/fbb/protus</bf>
and put *.prt files there. I <em>didn't move</em> *.PRT
files from <bf>\FBB\PROTUS</bf> but <em>copied</em> them into
the new location, because I wanted Protus to
run further under WinFBB as before. The utility
still didn't want to run, unless I copied
<em>also</em> *.PRT files from <bf>\FBB\SYSTEM</bf> to the
new location (<bf>/var/ax25/fbb/protus</bf>). After I
did that, everything became good.
<p>
<item>Well, I suppose, the above info would be
useful for those of you who intend to run
both Windows and Linux on the same machine.
For the majority of LinFBB users, it is only
important to make <bf>/var/local/fbb/protus</bf>
where <em>all</em> *.prt files should be placed. <em>Only</em>
c_filter executable should go to <bf>/fbb/bin</bf>
and that's it.
<p>
<item>About FBB-to-FBB protection: *both* partners
have to install Protus and password for the
forwarding partner's callsign must be the
same at *both* sides of the link. The versions
of Protus don't need to be the same (neither
the versions of FBB, neither the operating
systems, HI!). Anyway, MD5 algorythm will only
work if both parties have Protus 4.x and
above (I still don't use that, but it is not
a problem, because my two boxes, DosFBB/Protus3.3 and
WinFBB/LinFBB/Protus4.0, make all things ok).
<p>
<item>One of the interesting features of Protus is to
log unsuccessful connections. Due to the
<em>different</em> locations of *.prt files here, I have
separate logs for WinFBB and LinFBB. Those of
you who are going to run only one version of
FBB, will have <em>one</em> complete log of connection
errors, your users make when they try
connecting your BBS.
<p>
<item>As it was told earlier, if you implemented
password protection for only <em>some</em> of your
users (but not for all of them who connect
normally) - your system is considered as
an "open" one. It means that will be logged
only unsuccessful tries to enter the system
by "protected" callsigns. But, if you decided
that your BBS can be accessed by <em>only</em> those
callsigns who are protected with Protus, it
means that your system is the "closed" one.
Then, there is no way a user could enter your
FBB unless its callsign has given a password
within your Protus. Any unauthorized try to
connect your BBS is logged. In addition,
you may decide to have a "guest" access or
a "read-only" as default for some ports as
well for users who enter the wrong password.
Many combinations are possible. You could
even password protect your own FBB console!
</itemize>
<sect>FURTHER INFORMATION
<p>
@ -311,7 +549,7 @@ that meets the Manifesto. What follows is a
boilerplatte license.
</em>
<p>
Copyright (c) 2000 by Miroslav Skoric, YT7MPB.
Copyright (c) 2000 by Miroslav "Misko" Skoric, YT7MPB.
<P>
Please freely copy and distribute (sell or give
away) this document in any format. It is
@ -367,12 +605,12 @@ at regular intervals.
<p>
This is the first release of this mini-HOWTO. I
This is not the first release of this mini-HOWTO. I
hope to improve it whenever possible. Beside that,
there are other documents that may help you to
use amateur radio stuff on your computer. You may
look for AX.25 (mini-)HOWTO at the same location
where you get FBB mini-HOWTO
where you get FBB mini-HOWTO.
<em>This mini-HOWTO would be improved from time
to time. If you think that the HOWTO on your
@ -391,6 +629,7 @@ homepage.
<tscreen><verb>
Jean-Paul Roubelat, F6FBB, the author of FBB.
Per Olsen, LA6CU, the author of FBB documentation.
Jesus R., EB5AGF, the author of Protus.
</verb></tscreen>
@ -399,4 +638,3 @@ email address:
<htmlurl url="mailto:m.skoric@eunet.yu"
name="m.skoric@eunet.yu">.
</article>

297
LDP/howto/linuxdoc/Firewall-Piercing.sgml
View File

@ -5,7 +5,7 @@
<title>Firewall Piercing mini-HOWTO</title>
<author>François-René Rideau, <tt>fare@tunes.org</tt></author>
<date>v0.6a, 3 November 2000</date>
<date>v0.7, 4 November 2000</date>
<abstract>
Directions for using ppp over ssh or telnet
@ -26,7 +26,7 @@ Also applies to VPN construction.
</p>
<p>
<bf>
I hereby disclaim all responsibility for this hack.
I hereby disclaim all responsibility for <em>your</em> use of this hack.
If it backfires on you in any way whatsoever,
that's the breaks. Not my fault.
If you don't understand the risks inherent in doing this, don't do it.
@ -55,8 +55,7 @@ I haven't been actively developing this mini-HOWTO recently;
in particular, the french version is lagging behind.
I'm looking for a maintainer to take over this document,
and maybe develop software to make it easier to pierce firewalls.
It has been considered to merge this document into the NASG,
but that wasn't done. I also have a lot of ideas for active maintainers
I also have a lot of ideas for active maintainers
to expand this HOWTO, if anyone is interested.
</sect1>
@ -68,18 +67,28 @@ together with the french version.
Neither version is truly the translation of the other,
though each is somehow partly translated from the other.
Both are the ``original version''.
NO MORE TRUE. I'VE ABANDONNED MAINTENANCE OF THE FRENCH VERSION.
</sect1>
-->
<sect1>Credits
<p>
Even though I rewrote most everything but the disclaimers,
I'm indebted to <URL URL="mailto:bap@cs.unm.edu" name="Barak Pearlmutter">
for his Term-Firewall mini-HOWTO:
I think there was a necessity for a mini-HOWTO about piercing firewalls,
Even though the only thing left is the disclaimers,
this document owes a lot to the
<htmlurl url="http://www.linuxdoc.org/HOWTO/mini/Term-Firewall.html"
name="Term-Firewall mini-HOWTO">
by <URL URL="mailto:bap@cs.unm.edu" name="Barak Pearlmutter">.
Barak's mini-HOWTO relies on
an ancient and no-more-supported program named Term
(a great program in its time,
and maybe still useful in some unhappy circumstances),
as well as on peculiarities of a not-so-standard telnet implementation,
that is, many obsolete and non-portable facts.
Nevertheless, there was a necessity for a mini-HOWTO about piercing firewalls,
and despite its shortcomings, his mini-HOWTO was a model and an encouragement.
I'd also like to thank
I'd also like to congratulate
<URL URL="mailto:lars@nocrew.org" name="Lars Brinkhoff">
<!-- URL
URL="mailto:ajje@wombat.ludvika.se" name="Andreas 'Ajje' Pettersson"-->
@ -95,28 +104,47 @@ for their fine http, mail and icmp tunnels.
<sect1>Foreword
<p>
Because system administrators and users have different
constraints and proficiencies,
it so happens that a user may find himself behind a firewall,
This is document with a moral. And the moral is:
<bf>a firewall cannot protect a network against its own internal users,
and should not even try to.</bf>
When an internal user asks you system administrator
to open an outbound port to an external machine,
or an inbound port to an internal machine,
then you should do it for him.
Of course you should help the user to make sure
that his transactions are secure, and that his software is robust.
But a flat out denial of service is plain incompetence.
For unless he is so firewalled as be completely cut from the outside world,
with no ssh, no telnet, no web browsing, no email, no ping, no phone line,
no radio, no nothing,
then the user can and will use firewall piercing techniques to access
the machines he wants nonetheless,
and the net result for security will be
an unaudited connection with the outside world.
So either you trust your users, after proper training and selection,
or you shouldn't grant them access to the network at all.
You can and you shall protect them from the outside world,
but you can't protect them from themselves.
Because there exists such things as system administrators
who are either unresponsive, absent, plain incompetent,
or more generally managed by incompetent people,
it so happens that a user may find himself behind a firewall
that he may cross, but only in awkward ways.
This mini-HOWTO explains a generic and portable way
to use standard Internet tools seamlessly across such firewalls,
by the use of an IP emulator through a tunnel
achieved by a telnet, http, or mail connection.
It is freely inspired by the Term-Firewall mini-HOWTO by
<URL URL="mailto:bap@cs.unm.edu" name="Barak Pearlmutter">,
which relies on an ancient and no-more-supported program named Term
(a great program at its time,
and still useful in some unhappy circumstances),
as well as on peculiarities of a not-so-standard telnet implementation,
that is, many obsolete and non-portable facts.
to pierce tunnels into firewalls,
by turning any tiny small crack into a full-fledged information superhighway,
so the user can seamlessly use standard tools to access computers
on the other side of the firewall.
The very same technique can be used by competent system administrators
to build virtual private networks (VPN).
</sect1>
<sect1>Security problems
<sect1>Security issues
<p>
Of course, if your sysadm has setup a firewall,
Of course, if your sysadm has setup a firewall
s/he might have a good reason,
and you may have signed an agreement to not circumvent it.
On the other hand, the fact that you can use
@ -212,18 +240,12 @@ use the addresses below:
<URL URL="http://www.openssh.com/">.
<item><tt>fwprc</tt> and <tt>cotty</tt> can be found at
<URL URL="http://fare.tunes.org/files/fwprc/">.
<!-- what happened to the following site?
or
URL URL="ftp://ftp.noch.net/pub/fwprc/" -->
<item><tt>httptunnel</tt> can be found at
<URL URL="http://www.nocrew.org/software/httptunnel/">.
<item><tt>mailtunnel</tt> can be found at
<URL URL="http://www.detached.net/mailtunnel/">.
<item><tt>icmptunnel</tt> can be found at
<URL URL="http://www.detached.net/icmptunnel/">.
<!-- find and give precise information about:
http://sites.inka.de/sites/bigred/sw/ssh-ppp-new.txt
-->
</itemize>
</sect1>
</sect>
@ -243,61 +265,101 @@ you know where to look for.
The first step toward understanding the problem
is to give a name to relevant concepts.
So we'll herein call "local" the machine that initiates the connection,
As usual, we'll herein call "local" the client machine
that decides to initiate the connection,
as well as programs and files on that machine;
conversely, we'll call "remote" what's on the other side of the connection.
conversely, we'll call "remote" what's on the other side of the connection,
where a server runs that waits for connections.
</sect1>
<sect1>The problem
<sect1>The main problem
<p>
The goal is to connect the input and output of a local IP emulator
to the output and input respectively of a remote IP emulator.
The main problem with firewall piercing is to create a tunnel:
a continuous connection from the local machine to a remote machine
on the other side of the firewall,
that allows for bidirectional exchange of information.
Optionally, this connection should be a secure one.
The secondary problem is to transform this connection
into a full IP access for normal programs to use transparently.
Only the communication channels with which IP emulators interact
are either direct devices (in the usual case of <tt>pppd</tt>),
or the "current tty".
The previous case obviously does not happen with telnet sessions.
The latter is tricky, because when you launch the local emulator
from the command line, the "current tty" is linked to the command-line user,
not to a remote session;
also, should we open a new session (local or remote) on a new terminal,
we must synchronize the launching and connection of IP emulators on both sides,
least one session's garbage output is going to be executed
as commands on the other session, which would recursively produce more garbage.
For the main problem, we'll assume that
either (1) you can establish normal TCP/IP connections
from the local side of the firewall to some port on a remote machine
where a sshd runs or can be set to run, or
(2) you can somehow establish a telnet connection through a telnet proxy.
In case you cannot, we give you pointers to other software that allows you
to pierce a tunnel accross a firewall.
Although we only give a secure solution in the first case,
you can hack your own secure solution in the other cases,
if you understand the principle
(if you don't, someone, e.g. I, can do it for you in exchange for money).
</sect1>
<sect1>Additional difficulty
<sect1>The secondary problem
<p>
To get the best ease of use,
the local IP emulator has to provide IP to kernel networking,
hence be <tt>pppd</tt>.
However, <tt>pppd</tt> is dumb enough to only accept having data
through <tt>/dev</tt> or through the current tty;
it must be a tty, not a pair of pipe
For the secondary problem,
IP emulators (<tt>pppd</tt> or <tt>SLiRP</tt>)
are run on each side of the tunnel.
On the side that wants full IP access to the other side,
you'll want to run <tt>pppd</tt>.
On the other side, you want to run <tt>pppd</tt>
if you also want full IP access to the first side,
or <tt>SLiRP</tt> if you want to prevent any access.
Go to your usual pppd or SLiRP documentation for more information,
if you have specific needs not covered by the examples given below.
Although this is conceptually trivial,
it nonetheless requires a few silly tricks, so as to work, since
(a) in case you're using some kind of programmed interactive shell session
to start the remote IP emulator on either side, you need to correctly
synchronize the start of the IP emulator on the other side,
so as not to send garbage into the shell session,
and
(b) IP emulators are designed to be run on a "tty" interface
so you have to convert your tunnel's interface into a tty one.
Issue (a) is just your usual synchronization problem,
and doesn't even exist if you use <tt>ssh</tt>,
that transparently handles remote command launching.
Issue (b) requires the use of a simple external utility.
We wrote one, <tt>cotty</tt> just for that purpose.
&lt;FLAME ON&gt;
Among the silly problems caused by <tt>pppd</tt> maintainers' shortmindedness,
you can only run it through
either a device in <tt>/dev</tt> or the current tty.
You cannot run it through a pair of pipe
(which would be the obvious design).
This is fine for the remote <tt>pppd</tt> if any,
as it can use the telnet session's tty;
but for the local <tt>pppd</tt>, this sucks,
as it can't launch the telnet session to connect to;
hence, there must some kind of wrapper around it.
as it can use the <tt>telnet</tt> or <tt>ssh</tt> session's tty;
but for the local <tt>pppd</tt>, this conflicts with
the possible use of <tt>telnet</tt> as a way to establish a connection.
Telnet behaves <em>almost</em> correctly with a pair of pipe,
Indeed, <tt>telnet</tt>, too wants to be on a tty;
it behaves <em>almost</em> correctly with a pair of pipe,
except that it will still insist on doing ioctl's to the current tty,
with which it will interfere;
using telnet without a tty also causes race conditions,
using <tt>telnet</tt> without a tty also causes race conditions,
so that the whole connection will fail on "slow" computers
(fwprc 0.1 worked perfectly on a P/MMX 233,
(<tt>fwprc</tt> 0.1 worked perfectly on a P/MMX 233,
one time out of 6 on a 6x86-P200+, and never on a 486dx2/66).
All in all, when using <tt>telnet</tt>, you need <tt>cotty</tt>
to run as a daemon to copy output from one tty on which runs <tt>pppd</tt>
into another tty on which runs <tt>telnet</tt>, and conversely.
&lsqb;Note: if I find the sucker
(probably a MULTICS guy,
If I find the sucker (probably a MULTICS guy,
though there must have been UNIX people stupid enough to copy the idea)
who invented the principle of "tty" devices
by which you read and write from a "same" pseudo-file,
instead of having clean pairs of pipes,
I strangle him!&rsqb;
I strangle him!
&lt;/FLAME&gt;
</sect1>
</sect>
@ -307,18 +369,25 @@ I strangle him!&rsqb;
<sect1>Principle
<p>
Let's assume that your site administrator allows
transparent TCP connections to some port,
transparent TCP connections to some port on some remote machine,
(be it the standard SSH port 22, or an alternate destination port,
like the HTTP port 80 or whatever),
or that you somehow managed to get some port in one side of the firewall
to get redirected to a port on the other side
(using <tt>httptunnel</tt> or <tt>mailtunnel</tt> or whatever).
(using <tt>httptunnel</tt>, <tt>mailtunnel</tt>, <tt>icmptunnel</tt>,
some tunnel over <tt>telnet</tt>, or whatelse).
Then, you can run an <tt>sshd</tt> on the remote port,
and connect to it with an <tt>ssh</tt> on the local port.
On both sides of the ssh connection, you run IP emulators (<tt>pppd</tt>),
On both sides of the <tt>ssh</tt> connection,
you run IP emulators (<tt>pppd</tt>),
and there you have your VPN, Virtual Public Network,
that circumvents the stupid firewall limitations.
<p>
that circumvents the stupid firewall limitations,
with the added bonus of being encrypted for privacy
(beware: the firewall administrator still knows the other end of the tunnel,
and whatever authentication information you might have sent before to run
<tt>ssh</tt>).
The exact same technology can be used to build a VPN, Virtual Private Network,
whereby you securely join physical sites into a one logical network
without sacrificing security with respect to the transport network
@ -328,6 +397,18 @@ between the sites.
<sect1>A sample session
<p>
Below is a sample session to integrate in a shell script
(it assumes sh/bash syntax; YMMV).
Be sure to edit this into a script
with the right values for your needs.
Use option <tt>-p</tt> for <tt>ssh</tt> to try another port than port 22
(but then, be sure to run <tt>sshd</tt> on same port).
You can use <tt>slirp</tt> on the remote end,
if you are not <tt>root</tt> there, or simply want to screen your
local network from outbound connections.
Automatic reconnection is left as an exercise to the reader.
<verb>
REMOTE_ACCOUNT=root@remote.fqdn.tld
@ -336,15 +417,9 @@ LOCAL_PPPD="pppd silent 192.168.0.1:192.168.0.2"
cotty -d -- $LOCAL_PPPD -- ssh -t $REMOTE_ACCOUNT $REMOTE_PPPD
</verb>
This command requires <tt>cotty</tt> 0.4 or later.
Be sure to edit this into a script with the right values.
Use option <tt>-p</tt> for <tt>ssh</tt> to try another port than port 22
(but then, be sure to run <tt>sshd</tt> on same port).
You can use <tt>slirp</tt> on the remote end,
if you are not <tt>root</tt> there, or simply want to screen your
local network from outbound connections.
Automatic reconnection is left as an exercise to the reader.
(Note: this command requires <tt>cotty</tt> 0.4 or later.)
</sect1>
</sect>
<sect>Unsecure solution: piercing using telnet
@ -367,13 +442,19 @@ and the other will be the local <tt>pppd</tt>.
with a chat script as usual.
Actually, if your telnet proxy allows connection to an arbitrary port,
and you can reliably run a daemon on the remote host
and if you can reliably run a daemon on the remote host
(with a cron job to relaunch it in case of breakage),
then you'd better write some program that will just connect
a local port to the remote one through the proxy,
so you can use the above secure solution,
possibly using some variant of <tt>ssh -t -o "ProxyCommand ..."</tt>
(if you submit it to me, I'll integrate it to the <tt>fwprc</tt> distribution).
(if you submit it to me, I'll gladly integrate such a solution
to the <tt>fwprc</tt> distribution).
Note: if you must use the unsecure telnet-based solution,
be sure that nothing lies in your target account
that you want to keep secret or untampered,
since the password will be sent in clear text accross the Internet.
</sect1>
<sect1>fwprc
@ -383,11 +464,6 @@ to pierce firewalls, <tt>fwprc</tt>,
available from
<URL URL="http://fare.tunes.org/files/fwprc/"
name="my site">,
<!-- what happened to the following site?
as well as
URL URL="ftp://ftp.noch.net/pub/fwprc/"
name="this mirror"
-->
together with <tt>cotty</tt>
(which is required by <tt>fwprc</tt> 0.2 and later).
At the time of my writing these lines, latest versions are
@ -428,7 +504,7 @@ in your home directory.
Then replace variable values with stuff that fits your configuration.
Finally, copy to the other host, and test.
<p>
Default behavior is to use <tt>pppd</tt> locally, and slirp remotely.
Default behavior is to use <tt>pppd</tt> locally, and <tt>slirp</tt> remotely.
To modify that, you can redefine the appropriate function
in your <tt>.fwprcrc</tt> with such a line as:
<tscreen>
@ -437,16 +513,15 @@ remote_IP_emu () { remote_pppd }
<p>
Note that <tt>SLiRP</tt> is safer than <tt>pppd</tt>,
and easier to have access to,
since it does not require being root on the remote machine.
Another safe feature is that it will drop packets not directly coming
from the connected machine (which feature becomes a misfeature
if you attempt to route a subnetwork onto it with masquerading).
since it does not require being root on the remote machine,
and needn't additional firewall configuration to prevent
connections from the outside world into the firewalled network.
The basic functionality in <tt>SLiRP</tt> works quite well,
but I've found advertised pluses (like run-time controllability)
to be deficient;
of course, since it is free software,
but I haven't managed to get some advertised pluses to work
(like run-time controllability).
Of course, since it is free software,
feel free to hack the source
so as to actually implement whichever feature you need.
so as to actually implement or fix whichever feature you need.
</sect1>
</sect>
@ -614,19 +689,39 @@ including example use of <tt>getroute.pl</tt> from <tt>/etc/ppp/ip-up</tt>.
</sect1>
<sect1>Related Documents
<p>
The <url url="http://www.linuxdoc.org/"
name="LDP">
publishes many documents related to this mini-HOWTO,
most notably
the <htmlurl url="http://www.securityportal.com/lskb/"
name="Linux Security Knowledge Base">,
the <htmlurl url="http://www.linuxdoc.org/HOWTO/VPN.html"
name="VPN HOWTO">,
the <htmlurl url="http://www.linuxdoc.org/HOWTO/mini/VPN.html"
name="VPN mini-HOWTO">.
Then again, when facing a problem with some program,
one reflex for any Linux user should be to RTFM:
Read The Fscking Manual pages for the considered programs.
</sect1>
<sect1>Extra copy of IMPORTANT DISCLAIMER --- BELIEVE IT!!!
<p>
<quote>
<bf>
I hereby disclaim all responsibility for this hack. If it backfires
on you in any way whatsoever, that's the breaks. Not my fault. If
you don't understand the risks inherent in doing this, don't do it.
If you use this hack and it allows vicious vandals to break into your
company's computers and costs you your job and your company millions
of dollars, well that's just tough nuggies. Don't come crying to me.
I hereby disclaim all responsibility for <em>your</em> use of this hack.
If it backfires on you in any way whatsoever,
that's the breaks. Not my fault.
If you don't understand the risks inherent in doing this, don't do it.
If you use this hack and it allows vicious vandals
to break into your company's computers and costs you your job and
your company millions of dollars, well that's just tough nuggies.
Don't come crying to me.
</bf>
</quote>
</sect1>
</sect>
</article>

160
LDP/howto/linuxdoc/From-PowerUp-To-Bash-Prompt-HOWTO.sgml
View File

@ -6,7 +6,7 @@
<TITLE>From Power Up To Bash Prompt
<AUTHOR>Greg O'Keefe, <tt>gcokeefe@postoffice.utas.edu.au</tt>
<DATE>v0.8, September 2000
<DATE>v0.9, November 2000
<ABSTRACT>
This is a brief description of what happens in a Linux system, from the time
@ -577,6 +577,14 @@ file system (VFS). I won't go into any detail on this though. There is a
discussion of it in ``The Linux Kernel''
(see section <REF ID="Kernel" NAME="The Linux Kernel"> for a url)
<P>
A completely different kind of filesystem gets mounted on <TT>/proc</TT>.
It is really a representation of things in the kernel. There is a
directory there for each process running on the system, with the process
number as the directory name. There are also files such as <TT>interrupts</TT>,
and <TT>meminfo</TT> which tell you about how the hardware is being used.
You can learn a lot by exploring <TT>/proc</TT>.
<SECT1>Configuration
<P>
There are parameters to the command <TT>mke2fs</TT> which creates ext2
@ -610,7 +618,10 @@ Check out the ext2 filesystem code in the Kernel.
to it in
<URL URL="http://www.netspace.net.au/~gok/power2bash"
NAME="Building a Minimal Linux System from Source Code">
<ITEM>man pages for <TT>mount</TT>, <TT>fstab</TT>, <TT>fsck</TT> and <TT>mke2fs</TT>
<ITEM>man pages for <TT>mount</TT>, <TT>fstab</TT>, <TT>fsck</TT>, <TT>mke2fs</TT>
and <TT>proc</TT>
<ITEM>The file <TT>Documentation/proc.txt</TT> in the Linux source code explains
the <TT>/proc</TT> filesystem.
<ITEM>EXT2 File System Utilities
<URL URL="http://web.mit.edu/tytso/www/linux/e2fsprogs.html"
NAME="ext2fsprogs"> home page
@ -632,10 +643,6 @@ Check out the ext2 filesystem code in the Kernel.
<SECT>Kernel Daemons
<P>
Unfortunately, this section contains more conjectures and questions than facts.
Perhaps you can help?
<P>
If you issue the <TT>ps aux</TT> command, you will see something like the following:
@ -656,79 +663,93 @@ root 70 0.0 10.6 1472 708 1 R Sep 11 0:01 ps aux
</VERB>
<P>
This is a list of the processes running on the system. Note that <TT>init</TT>
This is a list of the processes running on the system. The information comes
from the <TT>/proc</TT> filesystem that I mentioned in the previous section.
Note that <TT>init</TT>
is process number one. Processes 2, 3, 4 and 5 are kflushd, kupdate, kpiod and
kswapd. There is something strange here though: notice that in both the virtual
storage size (SIZE) and the Real Storage Size (RSS) columns, these processes
have zeroes. How can a process use no memory? These processes are really part
of the kernel. The kernel does not show up on process lists at all, and you can
have zeroes. How can a process use no memory?
<P>
These processes are the kernel daemons. Most of the kernel
does not show up on process lists at all, and you can
only work out what memory it is using by subtracting the memory available from
the amount on your system. The brackets around the command name could signify
that these are kernel processes(?)
the amount on your system. The kernel daemons are started after init,
so they get process numbers like normal processes do. But their code and
data lives in the kernel's part of the memory.
<P>
<TT>kswapd</TT> moves parts of programs that are not currently being used
from real storage (ie RAM) to the swap space (ie hard disk). <TT>kflushd</TT>
writes data from buffers to disk. This allows things to run faster. What
There are brackets around the entries in the command column
because the <TT>/proc</TT> filesystem does not contain command line information
for these processes.
<P>
So what are these kernel daemons for?
Previous versions of this document had a plea for help,
as I didn't know much about the kernel daemons.
The following partial story has been patched together
from various replies to that plea, for which I am most grateful.
Further clues, references and corrections are most welcome!
<P>
Input and output is done via <em>buffers</em> in memory.
This allows things to run faster. What
programs write can be kept in memory, in a buffer, then written to disk in
larger more efficient chunks. I don't know what <TT>kupdate</TT> and
<TT>kpiod</TT> are for.
larger more efficient chunks. The daemons <TT>kflushd</TT> and <TT>kupdate</TT>
handle this work:
<TT>kupdate</TT> runs periodically (5 seconds?)
to check whether there are any dirty buffers. If there are, it gets
<TT>kflushd</TT> to flush them to disk.
<P>
This is where my knowledge ends. What do these last two daemons do? Why do
kernel daemons get explicit process numbers rather than just being anonymous
bits of kernel code? Does init actually start them, or are they already running
when init arrives on the scene?
Processes often have nothing to do, and ones that are running often
don't need all of their code and data in memory. This means we can
make better use of our memory, by shifting unused parts of running programs
out to the swap partition(s) of the hard disk.
Moving this data in and out of memory as needed is done by
<TT>kpiod</TT> and <TT>kswapd</TT>. Every second or so, <TT>kswapd</TT>
wakes up to check out the memory situation, and if something out on
the disk is needed in memory, or there is not enough free memory,
<TT>kpiod</TT> is called in.
<P>
I put a script to mount <TT>/proc</TT> and do a <TT>ps aux</TT> in <TT>/sbin/init</TT>. Process 1 was the script itself, and processess 2, 3, 4 and 5 were the kernel daemons just as under the real init. The kernel must put these processes there, because my script certainly didn't!
<P>
The following ramblings were contributed by David Leadbeater:
<P>
These processes seem to take care of disk reads and writes, they seem to be
started by the kernel but after it runs the init process, it seems that being
run as kernel processes rather than seperate processess they are protected from
being killed (kill -9 dosen't stop them), I am not sure why they are run as
seperate threads (it seems to be something with disk access)
<p><em>kflushd and kupdate</em>
These two processes are started to flush dirty (changed) buffers back to disk.
kflushd is run when the buffers are full and kupdate runs periodically (5
seconds?) to sync the disk and the buffers in memory.
<p><em>kpiod and kswapd</em>
These deal with paging out pages (sections) of memory into the swap file so
main memory never gets exhausted, these are similar to kflushd and kupdate in
that one is run when needed kpiod and the other kswapd is run peridically (1
second intervals)
<p><em>Other Kernel Daemons</em>
On a default install of RH6 kupdate is missing but update is running as a user
space daemon so it seems it needs to be run! Also another daemon mdrecoveryd is there, this seems to be dealing with software RAID, looking at the kernel source it seems that some SCSI drivers also start seperate processes.
<p>
I am still unsure of the meaning of the brackets but it seems that they appear
when the RSS of a process is 0 meaning it isn't using any memory?
<p>
(end of ramble, thanks David)
There might also be a <TT>kapmd</TT> daemon running on your system if you
have configured automatic power management into your kernel.
<P>
<SECT1>Configuration
<P>
I don't know of any configuration for these kernel daemons.
The program <TT>update</TT> allows you to configure <TT>kflushd</TT> and <TT>kswapd</TT>.
Try <TT>update -h</TT> for some information.
<P>
Swap space is turned on by <TT>swapon</TT> and off by <TT>swapoff</TT>.
The init script (<TT>/etc/rc.sysinit</TT> or <TT>/etc/rc.d/rc.sysinit</TT>)
usually calls <TT>swapon</TT> as the system is coming up.
I'm told that <TT>swapoff</TT> is handy for saving power on laptops.
<SECT1>Exercises
<P>
Find out what these processes are for, how they work, and write a new ``Kernel Daemons'' section for this document and send it to me!
Do an <TT>update -d</TT>, note the blatherings on the
last line about ``threshold for buffer fratricide''.
Now there's an intriguing concept, go investigate!
<P>
Change directory to <TT>/proc/sys/vm</TT> and <TT>cat</TT> the
files there. See what you can work out.
<SECT1>More Information
<P>
The Linux Documentation Project's ``The Linux Kernel''
(see section <REF ID="Kernel" NAME="The Linux Kernel"> for a url),
and the kernel source code are all I can think of.
(see section <REF ID="Kernel" NAME="The Linux Kernel"> for a url)
<P>
The Linux kernel source code, if you are brave enough!
The <TT>kswapd</TT> code is in <TT>linux/mm/vmscan.c</TT>,
and <TT>kflushd</TT> and <TT>kupdate</TT>
are in <TT>linux/fs/buffer.c</TT>.
<SECT>System Logger
@ -897,6 +918,7 @@ It has a full and up to date list of the packages that go into a Linux system
as well as instructions on how to build them.
<SECT>Conclusion
<P>
One of the best things about Linux, in my humble opinion, is that you can get
inside it and really find out how it all works. I hope that you enjoy this as
@ -922,6 +944,9 @@ as does its companion ``Building a Minimal Linux System from Source Code''.
There is a French translation at
<URL URL="http://www.freenix.fr/unix/linux/HOWTO/From-PowerUp-To-Bash-Prompt-HOWTO.html"
NAME="From Powerup To Bash Prompt"> thanks to Dominique van den Broeck.
A Japanese by Yuji Senda is coming soon, if it's not at
<URL URL="http://www.linux.or.jp/JF" NAME="Japanese Documentation and FAQ Project">
already.
@ -962,13 +987,30 @@ For correcting my hexidecimal arithmetic.
For pointing out some typos.
<TAG>David Leadbeater</TAG>
For contributing some ``ramblings'' about the kernel deamons.
<TAG> Dominique van den Broeck </TAG>
<TAG>Dominique van den Broeck </TAG>
For translating this doc into French.
<TAG>Matthieu Peeters </TAG>
For some good information about kernel deamons.
<TAG>John Fremlin</TAG>
For some good information about kernel deamons.
<TAG>Yuji Senda</TAG>
For the Japanese translation.
<TAG>Antonius de Rozari</TAG>
For contributing a GNU assembler version of UNIOS
(see resources section on the home page)
</DESCRIP>
<SECT1>Change History
<SECT2>0.7 -> 0.8
<SECT2>0.8 -> 0.9 (November 2000)
<P>
<ITEMIZE>
<ITEM>Incorporated some information from Matthieu Peeters
and John Fremlin on
kernel deamons and the <TT>/proc</TT> filesystem.
</ITEMIZE>
<SECT2>0.7 -> 0.8 (September 2000)
<P>
<ITEMIZE>
<ITEM> Removed instructions on how to build a system, placing them in a

11
LDP/howto/linuxdoc/LILO.sgml
View File

@ -10,7 +10,7 @@
<title>Lilo mini-Howto
<author>Miroslav Skoric (<tt/m.skoric@eunet.yu/)
<date>v3.1, 28 October 2000
<date>v3.2, 05 November 2000
<abstract>
LILO is the most used <bf/Li/nux <bf/Lo/ader for the x86 flavour of
Linux; I'll call it Lilo rather than LILO here because I don't
@ -215,8 +215,15 @@ table. You must also mark the DOS partition as bootable.
<sect1>How to make a ram disk?
<p>
<em>If you find this part of text hard to read, you may also look for
a web page: http://surfer.nmr.mgh.harvard.edu/partition/ramdisk.html
</em>
by Tony Harris
16 Oct 2000
ram disk eenie-weenie HOWTO
<p>
@ -440,8 +447,6 @@ to have both Linux and NT entries under Lilo menu:
entry into /etc/lilo.conf file. After you do that, restart Lilo
and, after the next re-boot, you will have both 'linux' and 'nt'
entries under Lilo menu.
</itemize>
</sect>
<sect>Installing <tt/hdc/ to Boot as <tt/hda/ and Using <tt>bios=</tt>

161
LDP/howto/linuxdoc/Linux+WinNT.sgml
View File

@ -5,13 +5,14 @@
<title>Linux+WindowsNT mini-HOWTO
<author>Miroslav Skoric, <tt/m.skoric@eunet.yu/
<date>v2.2, 07 August 2000
<date>v2.3, 05 November 2000
<abstract>
<nidx>windows nt</nidx>
This mini-HOWTO covers some ways on how to install both Linux and Windows
NT on the same computer and how to boot either of them from within LILO menu.
There is also another mini-HOWTO "Linux+NT-Loader" that covers how to boot
either of them from within NT Loader menu.
This mini-HOWTO covers some ways on how to install both Linux
and Windows NT on the same computer and how to boot either of
them from within LILO menu. There is also another mini-HOWTO
"Linux+NT-Loader" that covers how to boot either of them from
within NT Loader menu.
</abstract>
<sect>INTRODUCTION
@ -43,6 +44,12 @@ situation on your hard disk(s) you have, before and after you used
an utility called Partition Magic by Power Quest. This utility
might be needed to 'shrink' your NT (either NTFS or FAT) partition,
in order to get some free space for your further Linux' partitions.
(After a while, I recognized that 'shrinking' used partition
might not be needed. Actually, if you start from 'scratch', it
might be the best way to re-format your whole disk(s) using
<bf>FDISK</bf> command. You should make a DOS boot floppy diskete
where DOS commands FDISK and FORMAT have to be also copied.
More details later...)
<em>"I installed Linux first and then NT, but based on my experience, I
might now be able to install NT first and then Linux."</em>
@ -53,7 +60,7 @@ Linux. We'll see how to do that and how to use <bf/LILO/ (<bf/Li/nux
we'll see the procedure that Bill Wohler, the previous maintainer of
this mini-HOWTO, has been using:
<sect>HOW TO INSTALL: LINUX FIRST, WINDOWS NT AFTER
<sect>HOW TO INSTALL: LINUX <em>FIRST</em>, WINDOWS NT <em>AFTER</em>
<p>
1. Install a minimal Linux (hold off on installing the rest until
@ -63,12 +70,13 @@ this mini-HOWTO, has been using:
first partition, but I don't know if that is essential or not.
<p>
2. Edit /etc/lilo.conf and use boot=/dev/sda (I was not successful
2. Edit <tt>/etc/lilo.conf</tt> and use <bf>boot=/dev/sda</bf> (I
was not successful
at installing LILO on the Linux partition--/dev/sda3 in my case) and
run "lilo". You'll have to use the editor ae. You'll live.
<p>
3. Save the MBR with this: dd if=/dev/sda of=/dev/fd0 bs=512 count=1
3. Save the MBR with this: <bf>dd if=/dev/sda of=/dev/fd0 bs=512 count=1</bf>
Use a floppy. Trust me. Also do this each time you change the disk
partition table.
@ -79,11 +87,11 @@ this mini-HOWTO, has been using:
<p>
5. Add NT stanza to /etc/lilo.conf, e.g.:
other=/dev/sda1
<tt>other=/dev/sda1
label=NT
table=/dev/sda
table=/dev/sda</tt>
and run lilo. If lilo complains about this (I forget the message),
add the "linear" flag to /etc/lilo.conf near the "compact" keyword.
@ -130,9 +138,9 @@ Partition 1 does not end on cylinder boundary:
previously. Clear and restore the MBR (but not the signature) with:
<p>
dd if=/dev/zero of=/dev/sda bs=512 count=1
<bf>dd if=/dev/zero of=/dev/sda bs=512 count=1
dd if=/dev/fd0 of=/dev/sda bs=510 count=1
dd if=/dev/fd0 of=/dev/sda bs=510 count=1</bf>
<p>
8. Install the rest of Linux. Easy, huh?
@ -142,12 +150,12 @@ Partition 1 does not end on cylinder boundary:
<itemize>
<item>dd if=/dev/zero of=/dev/sda bs=446 count=1 (in Linux) or perform
<item><bf>dd if=/dev/zero of=/dev/sda bs=446 count=1</bf> (in Linux) or perform
a low-level format with the SCSI utilities. I've heard that a
low-level format of an IDE disk is fatal, so don't do it.
<item>fdisk /mbr (you've obviously already created a DOS boot disk that
contains fdisk).
<item><bf>fdisk /mbr</bf> (you've obviously already created a DOS boot
disk that contains fdisk).
<item>delete NT partition and create it again in NT install.
@ -178,7 +186,7 @@ Partition 1 does not end on cylinder boundary:
further information. I use NT about one day a year. Under duress.
<sect>HOW TO INSTALL: WINDOWS NT FIRST, LINUX AFTER
<sect>HOW TO INSTALL: WINDOWS NT <em>FIRST</em>, LINUX <em>AFTER</em>
<p>
<sect1>If you have <em>only one</em> IDE hard disk
@ -194,10 +202,11 @@ Partition 1 does not end on cylinder boundary:
would be placed into the MBR (Master Boot Record) of your hard
disk. But, there is a possibility for a previous content of
the MBR to remain within the MBR (especially any previous
Lilo), so I would suggest you (before installation of NT) to
Lilo), so I would suggest you (<em>before</em> installation of NT) to
boot the computer with a DOS floppy diskette having DOS version
of FDISK. At the prompt a:\ just enter the command: fdisk /mbr
and restart the computer again (without that floppy).
of FDISK. At the prompt a:\ just enter the command:
<bf>fdisk /mbr</bf> and restart the computer again (without
that floppy).
<p>
<item>After you have successfully installed your NT, you will see that
@ -210,13 +219,13 @@ Partition 1 does not end on cylinder boundary:
diskette with Partition Magic utility by Power Quest. It is a
graphical tool able to see all partitions on all hard disks you
have. The best thing is that you can make some changes with your
partitions but not to destroy your existing data. One of the
partitions but <em>not</em> to destroy your existing data. One of the
available changes is to make your existing partition(s) smaller,
so to get some free space on the disk(s) for other purposes.
Although you are advised to make a backup before you make any
changes to the partitions, I usually practise to 'shrink' NT's
partition before I installed anything but NT itself (so, if
needed, a repetitive re-installation wouldn't be a problem).
partition(s) before I install anything else onto this NT (so, if
needed, a repetitive NT re-installation wouldn't be a problem).
Well, Partition Magic (or any other similar utility you are
familiar with) will shrink your NT's partition (either NTFS or
FAT) to a smaller measure and place it to either the beginning
@ -228,6 +237,30 @@ Partition 1 does not end on cylinder boundary:
NT in order to check the new situation: you may use Windows
Explorer or Disk Administrator for that.
<p>
<item>As it was said in Introduction, it might <em>not</em> be needed
always to use such tools like Partition Magic. It is better to say
that this tool is of a great value in all those cases you have been
running Windows NT for a long time, so you don't want to start
from 'scratch'. For example, you are fully satisfied with your
beloved NT and related applications. You are not likely to kill
NT, but you have recognized that you have enough <em>unused</em>
space on NT's partition(s) (i.e. NT's partition(s) might look not
much populated). That case, Partition Magic is your choice.
But, if you do start from the beginning, or you don't mind
re-formatting the disk, it might be suitable to get a blank
floppy diskette, make it to be DOS bootable and copy two DOS
tools on it: FDISK and FORMAT. So, restart your computer with
such floppy and at <bf>A:\</bf> prompt enter <bf>fdisk</bf>.
There you'll find several options that allow re-partition of
your hard disk(s). Now you could make a part of the disk a FAT
partition (where you'll later install your beloved NT). The rest
of space you'd better leave alone (i.e. do not attempt making
Linux partition(s) right now, using DOS's version of FDISK). If
you <em>really</em> want to make Linux-type partitions now, you
should look after Linux version of FDISK.
<p>
<item>So far so good. Next step is to install your Linux. Case you
are familiar with RedHat distribution (I hope with other distros
@ -235,35 +268,43 @@ Partition 1 does not end on cylinder boundary:
CD in the drive and re-boot the computer). Well, when you are about
to choose what type of installation it will be (Gnome or KDE
Workstation, Custom, etc.) you may choose whatever you planned
before, but I would suggest to install a Workstation at first.
This is good because Linux setup will find automatically the
before, but I would suggest to install a Workstation <em>at first</em>.
This is good because Linux setup will find <em>automatically</em> the
free space on the (first) hard disk, make all partitions needed
for Linux, format them properly, make majority of options by
default so you won't have much pain during the setup (later, if
you want, you may either add missing components or re-install
Linux as Custom over the existing linux partitions). Lilo should
go to the MBR.
default so you won't have much pain during the setup (<em>later</em>,
if you want, you may either <bf>add</bf> missing components or
<bf>re-install</bf> RedHat Linux as Custom over the existing linux
partitions). Lilo should go to the MBR.
<p>
<item><bf>Don't forget to make Linux boot floppy diskette. You'll never
know when you may need it. If something goes wrong with the MBR,
and you don't have boot floppy, your Linux might become not accessible,
so you might have to re-install it again.</bf>
<p>
<item>After it looks that Linux installation is finished, you are going
to re-start the computer and there you will only see Lilo
with one Linux entry to boot (or maybe more than one Linux
entry, in case your hardware is multi-processor one). But, don't
panic! Your Windows NT is still there where you had installed it
to re-start the computer and there you will only see <bf>Lilo</bf>
with only one entry to boot: Linux (or maybe more than one Linux
entry, in case your hardware is multi-processor one or so). But, don't
panic! Your Windows NT is still there - where you had installed it
before Linux. You should become some familiar with Linux as soon
as possible, in order to be able to find and edit your new
/etc/lilo.conf file. When you open this file for the first time,
<bf>/etc/lilo.conf</bf> file. When you open this file for the first time,
you'll see that there is only one (or more) Linux entry. Well,
you should know the exact position (read: a partition) where
Windows NT has been installed, so you could add an appropriate
entry into /etc/lilo.conf file. After you do that, restart Lilo
and, after the next re-boot, you will have both 'linux' and 'nt'
entry into /etc/lilo.conf file. After you make those changes, restart
Lilo with a command: <bf>/sbin/lilo</bf> and, after the next re-boot,
you will have both 'linux' and 'nt' (or 'dos' or similar)
entries under Lilo menu.
<p>
<item>My added NT entry is:
<p>
<tt>
other=/dev/hda1
label=nt
@ -293,9 +334,10 @@ Partition 1 does not end on cylinder boundary:
other=/dev/hda1
label=nt
</tt>
<p>
<item>Some more explanations regarding details from my /etc/lilo.conf
<item>Some more explanations regarding details from my <tt>/etc/lilo.conf</tt>
file: After I have installed Windows NT, I assigned the letter C:
to that drive. Beside that, I wanted to have another NTFS
partition in order to store and backup important files, case I
@ -307,6 +349,12 @@ Partition 1 does not end on cylinder boundary:
near 1.9 GB and /swapp part of cca 100 MB (/dev/hda3 and /dev/hda4
respectively). Lilo went to the MBR and all has been running fine.
<p>
For your information, I <em>wanted</em> to make these linux
partitions that time. Later, I found that it was not needed, so
now I let Linux setup to make partitions from the free space in
a way it likes to do that. I trust it :-)
</itemize>
<sect1>If you have <em>more than one</em> (SCSI) hard disk
@ -383,6 +431,30 @@ process shouldn't change too much, if any.
NT can 'see' all (other) disks you have in your machine (either
partitioned or as 'free space' areas).
<p>
<item>Once again, as it was said earlier, it might <em>not</em> be needed
always to use such tools like Partition Magic. It is better to say
that this tool is of a great value in all those cases you have been
running Windows NT for a long time, so you don't want to start
from 'scratch'. For example, you are fully satisfied with your
beloved NT and related applications. You are not likely to kill
NT, but you have recognized that you have enough <em>unused</em>
space on NT's partition(s) (i.e. NT's partition(s) might look not
much populated). That case, Partition Magic is your choice.
But, if you do start from the beginning, or you don't mind
re-formatting the disk(s), it might be suitable to get a blank
floppy diskette, make it to be DOS bootable and copy two DOS
tools on it: FDISK and FORMAT. So, restart your computer with
such floppy and at <bf>A:\</bf> prompt enter <bf>fdisk</bf>.
There you'll find several options that allow re-partition of
your hard disk(s). Now you could make a part of the disk a FAT
partition (where you'll later install your beloved NT). The rest
of space you'd better leave alone (i.e. do not attempt making
Linux partition(s) right now, using DOS's version of FDISK). If
you <em>really</em> want to make Linux-type partitions now, you
should look after Linux version of FDISK.
<p>
<item>So far so good. Next step is to install your Linux. Case you
are familiar with RedHat distribution (I hope with other distros
@ -464,7 +536,7 @@ process shouldn't change too much, if any.
label=nt
<p>
<item>Some more explanation, regarding details from my /etc/lilo.conf
<item>Some more explanation, regarding details from my <tt>/etc/lilo.conf</tt>
file: After I have installed Windows NT on the <bf/first/ disk,
I assigned the letter C: to that drive. After I made enough free
space <em>after</em> the NTFS partition, I let Linux setup to
@ -513,11 +585,13 @@ process shouldn't change too much, if any.
everything looked fine, but neither Lilo was not installed, nor the
boot floppy was made. Investigating that, I studied the structure of all
existing partitions. I was surprised when recognized that new born
logical partitions (within the new extended one) were numbered as
if they were physically positioned <em>after</em> the NT partition!
In the other words, there I have a 'funny' order: /dev/sda5, /dev/sda6,
/dev/sda7 and, finally, /dev/sda1. Looked like the system was a bit
confused.
<em>logical</em> partitions (within the new born <em>extended</em> one)
were numbered as if they were physically positioned <em>after</em> the
NT partition! In the other words, there I have got a 'funny' order:
/dev/sda5, /dev/sda6, /dev/sda7 and, finally, /dev/sda1. Looked like
the system was a bit confused. So I considered that it is advisible
to make the 'free space' <bf>after</bf> already existing NT
partition(s).
<p>
<item>Regarding two similar Linux images (differ in 'smp'). It is a server
@ -545,7 +619,7 @@ You can use any license that meets the Manifesto.
What follows is a boilerplate licence.
</em>
<p>
Copyright (c) 2000 by Miroslav Skoric.
Copyright (c) 2000 by Miroslav "Misko" Skoric.
<P>
Please freely copy and distribute (sell or give away) this document in
any format. It's requested that corrections and/or comments be fowarded
@ -785,4 +859,3 @@ little annoying.
</article>

125
LDP/howto/linuxdoc/Xinerama-HOWTO.sgml
View File

@ -4,11 +4,11 @@
<!-- Xinerama Howto (MultiHead X) -->
<title>Using the Xinerama Extensions to MultiHead X V. 4.0
<title>Using the Xinerama Extensions to MultiHead XFree86 V. 4.0+
<author>Dennis Baker <tt/drbaker@softhome.net/
<date>v1.0, May 2, 2000
<date>v2.0 Revised November 2, 2000
<abstract>
This document describes how to configure XFree86 Version 4.0 with Multiple monitors and the Xinerama extentions.
This document describes how to configure XFree86 Version 4.0+ with Multiple monitors and the Xinerama extentions.
</abstract>
<!-- Table of contents -->
@ -17,42 +17,90 @@ This document describes how to configure XFree86 Version 4.0 with Multiple monit
<!-- Begin the document -->
<sect>Introduction
Many changes made based input from Nico Schottelius <tt/nicos@pcsystems.de/
<p> This is not meant to be a guide on how to set up your specific monitor, or videocard. In fact, I assume that you already have X windows running for your setup. Please refer to the XF86 Documentation for more information.
<sect1>What is Xinerama?
As far as I know, there are no limits to which video cards you can configure this way, nor does it seem to matter if you mix different types of video cards in a setup, The sample configuration I use in this documentation uses two different video cards, a AGP Fire GL 1000 and a PCI Matrox Millenium II. What effect this has on 3d Accelleration I don't know as I don't currently accellerate either of my video cards.
<P>Why do you need Xinerama ? And what is it ? The Xinerama extensions were introduced to the XFree86 system in version 4.0. Xinerama is an extension to XFree86 Release 6 Version 4.0 (X4.0) which allows applications and window managers to use the two (or more) physical displays as one large virtual display.
<P>This Howto assumes that you know how to edit text files, do basic video card configuration for X Windows, add and remove hardware from your system, start and stop system services, and follow simple instructions. If feel you will have trouble with any of these things, please seek help. I am not responsible if you damage any of your stuff.
<P>The beauty of the Xinerama extensions is that they are totally transparent to user space. Previously, applications could only reside on one of the displays and could not be moved between the two. Window managers had to be specially written to support the two displays. With Xinerama, window managers and applications don't have to be specially written to support the larger "Virtual Desktop" which Xinerama creates.
<sect1>Guidelines
<p>This is not meant to be a guide on how to set up your specific monitor, or videocard. In fact, I assume that you already have X Window running for your setup. Please refer to the XF86 Documentation for more information.
<P>As far as I know, there are no limits to which video cards you can configure this way, nor does it seem to matter if you mix different types of video cards in a setup, The sample configuration I use in this documentation uses two different video cards, an AGP Fire GL 1000 and a PCI Matrox Millenium II. What effect this has on 3d Accelleration I don't know as I don't currently accellerate either of my video cards.
<P>This Howto assumes that you know how to edit text files, do basic video card configuration for X Window, add and remove hardware from your system, start and stop system services, and follow simple instructions. If feel you will have trouble with any of these things, please seek help. I am not responsible if you damage any of your stuff.
<sect>Planning
<P>Planning a Xinerama setup is pretty straight forward. There as essentially three things you need to take into account, screen resolution, color depth, and screen layout.
<P>It is possible to have each physical screen in your Xinerama setup to have a different resolution. There are some advantages to this, I was able to use an old monitor which only operates at 640x480, and a bigger 17" at 1280x1024 in my setup. I have also heard of web developers and graphics designed who use one big "preview" screen and flank it with one or two smaller screens. I think this is one of the great things about the Xinerama extensions.
<sect1>What you need
<P>There is one significant problem with using multiple screen reolutions. Current generation window managers assume the screen is rectangular and will assume this rectangle is equal in size to the heighth and width of your total desktop. If you have one monitor at 1600x1200 and another at 800x600, your window manager will assume your desktop is 2400x1200. This leaves a big area below the smaller screen which the window manager interprets as "Empty", many window managers will try to utilize this space for new windows. There are ways to configure your window manager to minimize this problem but is a nuisance. As window managers become Xinerama aware and this problem will go away quickly.
<P>You will need at least 2 graphics cards (a dual headed one should work, too) and two monitors, an operating system on which XFree runs (for instance Linux or Solaris) and XFree86 version 4.0. I assume your setup works, and that your two video cards are supported by XFree86.
<P>Unless you recently upgraded or installed linux you are probably running an older version of X. Verify that you are running version 4.0 or better by typing the following command:
<P><tscreen><tt>papel:/home/nico/X/bin # X -version</tt></tscreen>
<P>You should now see something like this:
<P><tscreen><code>
XFree86 Version 4.0 / X Window System
(protocol Version 11, revision 0, vendor release 6400)
Release Date: 8 March 2000
If the server is older than 6-12 months, or if your card is newer
than the above date, look for a newer version before reporting
problems. (see http://www.XFree86.Org/FAQ)
Operating System: Linux 2.3.46 i686 [ELF]
Module Loader present
</code></tscreen>
<P>If the version is not 4.0 or higher ( first line ), you will need to upgrade. Use your distributions package manager to upgrade to version 4.0 or better or download it directly from XFree86 and install it.
<P><tscreen><tt>ftp://ftp.xfree86.org/pub/XFree86/4.0/</tt></tscreen>
<P>or better use one of the mirrors found at
<P><tscreen><tt>http://www.xfree86.org/4.0/ftp.html</tt></tscreen>
<P>After download the files install the new X with the Xinstall.sh shellscript. Please note, if you install X this way it is bypassing any package management your system has.
<Sect1>Design considerations
<P>It is possible to have each physical screen in your Xinerama setup to have a different resolution. There are some advantages to this, I was able to use an old monitor which only operates at 640x480, and a bigger 17" at 1280x1024 in my setup. I have also heard of web developers and graphics designed who use one big "preview" screen and flank it with one or two smaller screens. I think this flexibility is one of the great things about the Xinerama extensions.
<P>There are several UI issues which are specific to Xinerama with most current generation window managers (see the section on <ref id="Window Managers">) do not address well. The most anoying is the poor handling of dead areas.
<P>Window managers assume the display area is a rectangle equal in size to the heighth and width of your total desktop. If you use more than one display resolution in a Xinerama setup your desktop will be non-rectangular. This results in "dead areas", areas which do not exist on your display, but window manager interpret as "Empty". Many window managers will try to utilize this dead area for new windows. The result is windows which are inaccessable. As window managers become Xinerama aware and this problem will go away quickly.
<P>Window managers also don't handle the concept of maximizing a window when you are running Xinerama. Usually what happens is it maximizes your window across all available screens. Having Netscape spread across 2 displays is generally not the best way to surf the net.
<P>Unlike with screen resolotion, Xinerama limits your entire virtual screen to one color depth. If you were planning on pulling out a cheap video card for your second display you need to keep this in mind. If your old video card only supports 8 bit color you might get a bigger display but most newer programs look lousy in 256 colors.
<P>Layout decisions are fairly simple, you just need to decide how you want to lay out your monitors. Most people will simply place their monitors in a row and view their desktop as one giant monitor. It is also possible to overlap displays, or place them in more complex layouts. Keep in mind though what I said above about window managers expecting rectangular displays.
<sect1>Layout
<P>Layout decisions are fairly simple, you just need to decide how you want to physically lay out your monitors. Most people will simply place their monitors in a row and view their desktop as one giant monitor. It is also possible to overlap displays, or place them in more complex layouts. Keep in mind though what I said above about window managers expecting rectangular displays.
<sect>Video Card set up.
<P> This is a good time to back up your existing config file:
I did it like this:
<P> This is a good time to back up your existing config file
<P>I did it like this:
<P><tscreen><tt>root# > cp /etc/X11/XF86Config /etc/X11/XFree86Config.working</tt></tscreen>
<P>Before we start the multihead portion of this process you need to have ALL of your existing cards working properly with the display they will have in the final configuration. If you haven't already, configure and install each different video card/ monitor combination you are going to have in your final setup. If you have several identical video cards you can get away with configuring one and copying the configuration for the other cards.
<P>Note, it is possible configure and test your video cards without physically swapping them. If you use the technique in the scan <ref id="PCI Bus Section"> below and specify the bus ID.
<P>After you have each card set up, back up or print it's config file as you will need it later.
Here's how I did it:
<P><tscreen><tt>root# > cp /etc/X11/XF86Config /etc/X11/XFree86Config.Matrox</tt></tscreen>
<P>On Some setups the XF86Config file is stored in /etc so you would do it like this:
<P><tscreen><tt>root# > cp /etc/XF86Config /etc/XFree86Config.Matrox</tt></tscreen>
<P>If your video cards are identical you can probably get away with just one copy. However don't skip this step, If all else fails this will be you backup config file incase my instructions lead you astray.
<P>Once you have all of your displays configured you are almost there...
<sect>Scan the PCI Bus
<sect>Scan the PCI Bus
<P>This is a good time to put all of your video cards into your system and set up your monitors. Set everything up the way you want it when you are done, as you will have to repeat steps later if you change things.
<P> This next step needs to be done from the console with-out X running. If you are in X, exit now. If your system uses a display manager such as xdm or gdm exit you need to stop that service.
If you need to stop a display manager from RedHat the easiest way is like this:
@ -62,7 +110,7 @@ If you need to stop a display manager from RedHat the easiest way is like this:
<P>If neither of these methods work you, reboot your computer and start up in single user mode.
<P>In a multi-head setup you need to explicitly identify each video card in your config file. To do this you need to use the PCI Bus Identifier your system assigns the card. At this time, all video cards need to be in your system.
<P>To find out what your PCI bus IDs are: <label id="prior step">
<P>To find out what your PCI bus IDs are: <label id="PCI Bus Section">
<tscreen><P><tt>root# > XFree86 -scanpci </tt></tscreen>
<P>X will then output a code for each device on your PCI bus.
<tscreen><code>
@ -82,18 +130,18 @@ If you need to stop a display manager from RedHat the easiest way is like this:
<sect>Editing your XConfig File
<P>If I haven't lost you so far, we are in the home stretch now. This section is pretty confusion so I suggest you also read the manpage for XF86Config, or at least skim it. Do it now... I'll wait.
<P>If I haven't lost you so far, we are in the home stretch now. This section is pretty confusiing so I suggest you also read the manpage for XF86Config, or at least skim it. Do it now... I'll wait.
<P><tscreen><tt> root# > man XF86Config </tt></tscreen>
<sect1>Adding all of your video cards
<P>Open your current XF86Config file and scroll down to the Monitor Section. You want to copy the following sections from the XF86Config backup files you created above : Monitor, Device, Screen. These sections should go in your XF86Config file after the coresponding section in the file you have open. As you copy each section make certain that the Identifier is unique for each section, you will reference these identifies later.
<P>Open your current XF86Config file and scroll down to the Monitor Section. You want to copy the following sections from the device specific XF86Config backup files you created above : Monitor, Device, Screen. These sections should go in your XF86Config file after the coresponding section in the file you have open. As you copy each section make certain that the Identifier is unique for each section, you will reference these Identifiers later.
<P>Clear as Mud Right? You should now have a Monitor Section, a Device Section, and a Screen Section for EACH video card/monitor combination, each Section should have a unique Identifier. If you are still confused reread the prior paragraph. If that doesn't help, look at the sample <ref id="XF86Config"> I have included at the end. You did read the manpage right?
<sect1>Identifying Your Video Cards
<P>Now you need to add the coresponding PCI BusID as an option at the end of each Device Section. The entry should look like this: BusID "PCI:0:12:0", substituting the three numbers with the PCI bus ID which identifies YOUR video card you should have this ID from the <ref id="prior step">. Here is a sample Device Section for one of my video cards.
<P>Now you need to add the coresponding PCI BusID as an option at the end of each Device Section. The entry should look like this: BusID "PCI:0:12:0", substituting the three numbers with the PCI bus ID which identifies YOUR video card you should have this ID from the <ref id="PCI Bus Section">. Here is a sample Device Section for one of my video cards.
<tscreen><code>
Section "Device"
@ -143,7 +191,44 @@ Hopefully you can now enjoy X with multiple partners... er that is, Monitors.
<P><tscreen><tt> 0=/usr/bin/X11/X +xinerama </tt></tscreen>
I am certain configuring KDE, and xdm to start xinerama are equally easy, if you figure it out please drop me a note and I will add it to this Howto.
<P>I have never set up kdm, or xdm for Xinerama, but I got the following tip from Dalibor "dali@dali.net.nz".
<P><tscreen><code>
Here's my changes to startup files for slackware 7.x
(i use KDM and x4.01)
edit /var/X11R6/lib/xdm/Xservers
add +xinerama to the end of last line
ie.
:0 local /usr/X11R6/bin/X +xinerama
It appears that KDM uses standard XFree xdm files, so this should work if you
use xdm as well
</code></tscreen>
<sect>Window Managers and Xinerama <label id="Window Managers">
<P>As I mentioned above, a window manager does not need to be written to support Xinerama. However there are certain enhancements which window manager developers can do to make Xinerama users lives easier. Features which I thought were desireable include:
<P>* Intelligent placement of windows. Window managers should not place windows in dead areas or across the borders of two heads. New windows should be placed in the current desktop.
<P>* Maximizing windows should maximize the window to the current head only.
<P>* Window Movements should have edge resistance between heads (Much like they have resistance to other windows).
<P>* Dialogs and informative messages should not pop up Between Heads.
<P>I searched the mailing lists, FAQs, and emailed the developers of most of the major window managers to see if they were working on any Xinerama related extensions. The Window Managers/ Desktop environments I reviewed included Blackbox, Enlightenment, KDE, WindowMaker, and XFCE. Enlightenment and Sawfish were the only two which I found significant enhancements for Xinerama. I have detailed what I discovered below.
<sect1>Enlightenment
<P>From their news page: Sun Mar 26 2000
<P>E with Xinerama support
<P><tt>
We just got done adding real xinerama support to E this weekend. Now you have edge resistance moving windows between heads, windows will always pop up on the currently focused head (unless it wants to go someplace else by geom settings or you have it saved to go someplace else), maximize (unless you use "absolute" maximize) stays on the current head also. If you have xinerama and you run E out of CVS, test this and give us feedback.
</tt>
<Sect1>Sawfish
<P>From the Sawfish mailing list I have discovered that they are actively developing Xinerama support. Features which are currently in the development version include :
<code>
* Preventing Windows from being mapped across heads
* Preventing Windows from being mapped in dead spots
* Edge resistance moving between heads
* Centered and Random placement modes place windows on the current Head
</code>
I have not tested this functionality.
<sect>Sample XF86Config Files <label id="XF86Config">
<P>My current XF86Config File :
@ -284,6 +369,12 @@ Section "ServerLayout"
InputDevice "Keyboard1" "CoreKeyboard"
EndSection
</code>
<sect>Credits
<P>Much of the introduction and first sections are based loosely on a document submitted to me from Nico Schottelius <tt/nicos@pcsystems.de>/. As mentioned, KDM and xdm configuration included based on an email from Dalibor <tt/dali@dali.net.nz>/.
<P>Also thanks to the many people who have emailed me with spelling tips, and suggestions. I have incorporated them whenever I could.
</article>