mirror of https://github.com/tLDP/LDP
hosuecleaning
This commit is contained in:
gferg
parent
18ae67226d
commit
62a07332a5
|
|
@ -1,632 +0,0 @@
|
|||
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
|
||||
<!-- for extra DocBook help check http://www-106.ibm.com/developerworks/linux/library/l-docbk.html -->
|
||||
|
||||
<article>
|
||||
<articleinfo>
|
||||
<title>Linux + XFS HOWTO</title><subtitle>Linux on Steroids</subtitle>
|
||||
<author>
|
||||
<firstname>Russel</firstname>
|
||||
<surname>Ingram</surname>
|
||||
<affiliation>
|
||||
<address>
|
||||
<email>ringram@gargoylecc.com</email>
|
||||
</address>
|
||||
</affiliation>
|
||||
</author>
|
||||
|
||||
<date>v1.1, May 12, 2002</date>
|
||||
|
||||
<revhistory>
|
||||
<revision>
|
||||
<revnumber>v1.1</revnumber>
|
||||
<date>2002-05-12</date>
|
||||
<authorinitials>ri</authorinitials>
|
||||
<revremark>
|
||||
Updated sgi cvs info to match current state; made various changes/clarifications based on reader feedback
|
||||
</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>v1.02</revnumber>
|
||||
<date>2001-10-08</date>
|
||||
<authorinitials>ri</authorinitials>
|
||||
<revremark>
|
||||
Added some note, blockquote and ulink tags.
|
||||
Corrected error in command section of "Finishing Up".
|
||||
Changed note about e2fsprogs-devel to refer to libuuid.
|
||||
</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>v1.01</revnumber>
|
||||
<date>2001-10-04</date>
|
||||
<authorinitials>ri</authorinitials>
|
||||
<revremark>
|
||||
Corrected error in "Finishing up" section; various formatting changes
|
||||
</revremark>
|
||||
</revision>
|
||||
</revhistory>
|
||||
|
||||
<abstract><para>
|
||||
This document describes how to build a Linux system that runs
|
||||
on top of the SGI XFS journaling filesystem.
|
||||
</para></abstract>
|
||||
|
||||
</articleinfo>
|
||||
<sect1>
|
||||
<title>Introduction</title>
|
||||
<sect2>
|
||||
<title> Introduction to XFS for Linux </title>
|
||||
<para>
|
||||
This document describes how to build a Linux system that runs
|
||||
on top of the SGI XFS journaling filesystem. From the XFS FAQ: "XFS
|
||||
is a journalling filesystem developed by SGI and used in SGI's IRIX
|
||||
operating system. It is now also available under GPL for linux. It
|
||||
is extremely scalable, using btrees extensively to support large
|
||||
sparse files, and extremely large directories. The journalling capability
|
||||
means no more waiting for fsck's or worrying about meta-data corruption."
|
||||
Essentialy XFS is the filesystem SGI designed for its highend server
|
||||
systems, hence the subtitle of this document, "Linux on Steroids".
|
||||
:-)
|
||||
</para>
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title> Foreword, Feedback, & Credits </title>
|
||||
<para>
|
||||
As a fairly new member of the Irix System Administrator community
|
||||
I have fallen in love with the robustness of the filesystem that
|
||||
has been developed to support Irix (XFS of course). So, needless
|
||||
to say I've been following the porting effort to Linux for quite
|
||||
some time and have dreamed of being able to run my Linux systems
|
||||
on top of an all XFS filesystem since the beginning. The project
|
||||
has come to a point (actually nearly a year ago at the time of this
|
||||
writing) that this could actually be a reallity. However, as is
|
||||
the case with a great deal of programming/porting projects, the documentation
|
||||
for such task is not always as readily available or easy to follow
|
||||
as one might hope. This document is an attempt to remedy that situation.
|
||||
|
||||
</para>
|
||||
<para>
|
||||
The information contained in this document is based on messages
|
||||
from Jason Walker and Russell Cattelan taken from the XFS development
|
||||
mailing list, information gathered from various places on the SGI
|
||||
Open Source Development web site, and from my own experiences setting
|
||||
up such a system.
|
||||
</para>
|
||||
<para>
|
||||
Please feel free to email me at <email>ringram@gargoylecc.com</email> if you
|
||||
have any corrections or if any imformation/URLs/etc. is missing.
|
||||
The more feedback I get on this HOWTO the more helpful it will be
|
||||
for all.
|
||||
</para>
|
||||
<para>
|
||||
The latest version of this document can be found at
|
||||
<ulink url="http://www.gargoylecc.com/Linux+XFS-HOWTO/t1.html">
|
||||
Gargoyle Computer Consulting
|
||||
</ulink>.
|
||||
</para>
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>Copyright & Disclaimer</title>
|
||||
<para>
|
||||
This document is copyright(c) 2001 Russel Ingram and it is a
|
||||
FREE document. You may redistribute it under terms of the GNU General
|
||||
Public License.
|
||||
</para>
|
||||
<para>
|
||||
The information contained in this document is, to the best of
|
||||
Russel's knowledge, correct. However, the XFS Linux port is written
|
||||
by humans and thus, there is the chance that mistakes, bugs, etc.
|
||||
might happen from time to time.
|
||||
</para>
|
||||
<para>
|
||||
No person, group, or other body is responsible for any damage
|
||||
on your computer(s) and any other losses by using the information
|
||||
in this document. i.e.
|
||||
</para>
|
||||
<para>
|
||||
|
||||
</para>
|
||||
<para>
|
||||
<emphasis>
|
||||
THE AUTHOR IS NOT RESPONSIBLE FOR ANY DAMAGES INCURRED DUE TO
|
||||
ACTIONS TAKEN BASED ON THE INFORMATION IN THIS DOCUMENT.
|
||||
</emphasis>
|
||||
</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
<sect1>
|
||||
<title> Preparation for XFS Installation </title>
|
||||
<sect2>
|
||||
<title> Downloading the Linux 2.4.x-XFS Kernel Source </title>
|
||||
<para>
|
||||
Currently the only place to get the source code for the XFS enabled
|
||||
Linux kernel is straight from SGI's Open Source Development site
|
||||
via CVS.
|
||||
</para>
|
||||
<note>
|
||||
<title>Note</title>
|
||||
<para>two distinct trees are available:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>linux-2.5-xfs: development tree</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>linux-2.4-xfs: stable bug fix only tree</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</note>
|
||||
<para>
|
||||
My experience has been with the 2.4 tree, but I imagine everything
|
||||
will work the same with the development tree. Both trees are kept
|
||||
in sync with their respective mainline kernel tree at least to the
|
||||
point of major release numbers.
|
||||
</para>
|
||||
<para>
|
||||
Here are the steps to download the kernel source tree:
|
||||
|
||||
</para>
|
||||
<para>
|
||||
A. Normally the linux kernel source is installed in the /usr/src
|
||||
directory, so you should start off by switching to that directory.
|
||||
</para>
|
||||
<para>
|
||||
<programlisting>
|
||||
$ cd /usr/src
|
||||
</programlisting>
|
||||
</para>
|
||||
<para>
|
||||
B. Next, you should set the CVSROOT environment variable so that
|
||||
it points to the proper cvs server.
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
If you are running sh, bash, ksh, etc...:
|
||||
<programlisting>
|
||||
$ export CVSROOT=':pserver:cvs@oss.sgi.com:/cvs'
|
||||
</programlisting>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
If you are running csh or tcsh:
|
||||
<programlisting>
|
||||
$ setenv CVSROOT :pserver:cvs@oss.sgi.com:/cvs
|
||||
</programlisting>
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para>
|
||||
If you plan on updating your kernel often (to keep up with the
|
||||
latest changes) you might want to put this in your login script.
|
||||
|
||||
</para>
|
||||
<para>
|
||||
C. Then log in to the cvs server.
|
||||
</para>
|
||||
<para>
|
||||
<programlisting>
|
||||
$ cvs login (the password is "cvs")
|
||||
</programlisting>
|
||||
</para>
|
||||
<para>
|
||||
This needs to be done only ONCE, not everytime you access CVS.
|
||||
|
||||
</para>
|
||||
<para>
|
||||
D. Now grab linux-2.4-xfs. The first time you will want to do
|
||||
something like:
|
||||
</para>
|
||||
<para>
|
||||
<programlisting>
|
||||
$ cvs -z3 co linux-2.4-xfs
|
||||
</programlisting>
|
||||
</para>
|
||||
<para>
|
||||
After you have checked the code out, you can use:
|
||||
</para>
|
||||
<para>
|
||||
<programlisting>
|
||||
$ cvs -z3 update linux-2.4-xfs
|
||||
</programlisting>
|
||||
</para>
|
||||
<para>
|
||||
to update your copy to the latest version from the CVS server.
|
||||
|
||||
</para>
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title> XFS Support as Modules or Compiled Into the Kernel? </title>
|
||||
<para>
|
||||
The option to build XFS support for the Linux kernel as modules
|
||||
is available and will work (or so I am told) with the help of an
|
||||
initial RAM disk and a couple of additions to the lilo configuration.
|
||||
I have not tried this (yet), so I will not include documentation
|
||||
on how this is done other than just to qoute from a message to the
|
||||
development mailing list from Russell Cattelan:
|
||||
</para>
|
||||
<blockquote>
|
||||
<attribution>
|
||||
<author>
|
||||
<firstname>Russell</firstname><surname>Cattelan</surname>
|
||||
</author>
|
||||
</attribution>
|
||||
<para>
|
||||
Actually running xfs as a module isn't very hard. in the
|
||||
directory cmd/xfs/misc there is a modified mkinitrd the will always
|
||||
generate a ram disk with pagebuf xfs_support and xfs.
|
||||
</para>
|
||||
<para>
|
||||
Once that is done just add the initrd line in lilo.conf AND
|
||||
</para>
|
||||
<para>
|
||||
<programlisting>
|
||||
append = "ramdisk_size=25000"
|
||||
</programlisting>
|
||||
</para>
|
||||
<para>
|
||||
The default size is 4096 which isn't nearly large enough to hold
|
||||
xfs.
|
||||
</para>
|
||||
<para>
|
||||
This is from my laptop.
|
||||
</para>
|
||||
<para>
|
||||
<programlisting>
|
||||
punch[12:57am]-=>mount
|
||||
/dev/ide/host0/bus0/target0/lun0/part8 on / type xfs (rw,noatime)
|
||||
none on /proc type proc (rw)
|
||||
/dev/ide/host0/bus0/target0/lun0/part6 on /boot type ext2 (rw,noatime)
|
||||
none on /dev/pts type devpts (rw,mode=0620)
|
||||
/dev/ide/host0/bus0/target0/lun0/part1 on /mnt/windows type vfat (rw,nosuid,nodev,umask=0)
|
||||
/dev/ide/host0/bus0/target0/lun0/part9 on /blam type xfs (rw)
|
||||
|
||||
punch[12:57am]-=>lsmod
|
||||
Module Size Used by
|
||||
autofs 13180 1 (autoclean)
|
||||
usb-uhci 24918 0 (unused)
|
||||
usbcore 35339 0 [usb-uhci]
|
||||
3c59x 25149 1 (autoclean)
|
||||
maestro 29757 0 (unused)
|
||||
soundcore 6085 2 [maestro]
|
||||
vfat 13075 1 (autoclean)
|
||||
fat 37733 0 (autoclean) [vfat]
|
||||
xfs 447888 2
|
||||
xfs_support 13954 0 [xfs]
|
||||
pagebuf 39935 2 [xfs]
|
||||
|
||||
|
||||
image=/boot/vmlinuz-2.4.0-XFS-test13-pre4
|
||||
label=t13p4
|
||||
root=/dev/hda8
|
||||
initrd=/boot/initrd-2.4.0-XFS-test13p4.img
|
||||
append="ramdisk_size=25000"
|
||||
read-only
|
||||
</programlisting>
|
||||
</para>
|
||||
</blockquote>
|
||||
<para>
|
||||
It seems to me that compiling the support into the kernel would
|
||||
be much simpler, so that is how I am doing it at this point. I will
|
||||
try it as a module at a later time and add more detailed instructions
|
||||
then. If anyone has time to document this method before I get around
|
||||
to it please email it to me and I will include it with credit given
|
||||
where credit is due. :-)
|
||||
</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
<sect1>
|
||||
<title> Kernel Configuration and Installation </title>
|
||||
<sect2>
|
||||
<title>Configuring your kernel for XFS support</title>
|
||||
<note>
|
||||
<title>Note</title>
|
||||
<para>
|
||||
If you have never configured and compiled a new linux kernel
|
||||
you might consider reading the Linux Kernel HOWTO before doing this
|
||||
step. It can be found at the
|
||||
<ulink url="http://www.linuxdoc.org/HOWTO/Kernel-HOWTO.html">
|
||||
Linux Documentation Project (LDP)
|
||||
</ulink>
|
||||
or one of its mirrors.
|
||||
</para>
|
||||
</note>
|
||||
<para>
|
||||
After having downloaded the cvs source tree the actual kernel
|
||||
source will be in /usr/src/linux-2.4-xfs(-beta)/linux, so you should
|
||||
switch to that directory before running the make config command of
|
||||
your choice. The main things that must be included in your kernel
|
||||
to provide XFS support are "Page Buffer support" and (duh)
|
||||
"SGI XFS filesystem support." Both options are available
|
||||
in the "File systems" section of the kernel configuration.
|
||||
You will need to have "Prompt for development and/or incomplete
|
||||
code/drivers" selected under "Code maturity level options"
|
||||
for those options to be available to you. Optionally, you may also
|
||||
want to select "Enable XFS Debug mode" and "Enable
|
||||
XFS Vnode Tracing" under "SGI XFS filesystem support."
|
||||
These options may slow your XFS implementation some, but may be useful
|
||||
in tracing the cause of a crash if a crash occurs.
|
||||
</para>
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>Building the kernel and modules</title>
|
||||
<para>
|
||||
As with any kernel build, the following commands must be run
|
||||
to actually build the new kernel:
|
||||
</para>
|
||||
<para>
|
||||
<programlisting>
|
||||
$ make dep
|
||||
$ make bzImage
|
||||
$ make modules
|
||||
</programlisting>
|
||||
</para>
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>Installing the new kernel and modules</title>
|
||||
<para>
|
||||
Again this is standard for any kernel installation:
|
||||
</para>
|
||||
<para>
|
||||
<programlisting>
|
||||
$ make modules_install
|
||||
$ cp arch/i386/boot/bzImage /boot/vmlinuz-2.4.0-XFS
|
||||
</programlisting>
|
||||
</para>
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>Add a new entry to your lilo configuration and re-install lilo</title>
|
||||
|
||||
<para>
|
||||
<programlisting>
|
||||
$ vi /etc/lilo.conf
|
||||
</programlisting>
|
||||
</para>
|
||||
<para>
|
||||
Add a new image section to your lilo.conf file similar to the
|
||||
following:
|
||||
</para>
|
||||
<para>
|
||||
<programlisting>
|
||||
image=/boot/vmlinuz-2.4.0-XFS label=xfs read-only root=/dev/hda2
|
||||
</programlisting>
|
||||
</para>
|
||||
<para>
|
||||
The "root=" line should match the "root="
|
||||
line from the existing image sections in your lilo.conf file. Don't
|
||||
forget to run lilo when you're through editing lilo.conf to make
|
||||
the changes effective.
|
||||
</para>
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>Build and install the XFS utilities</title>
|
||||
<para>
|
||||
There are a number of tools that come with the XFS filesystem that allow
|
||||
you to build and manage your XFS filesystems that must be built as well.
|
||||
These tools are in the /usr/src/linux-2.4-xfs(-beta)/cmd/xfsprogs directory.
|
||||
</para>
|
||||
<note>
|
||||
<title>Note</title>
|
||||
<para>These tools rely on the /usr/lib/libuuid.a shared library. If you
|
||||
do not have this library installed you will need it in order for
|
||||
the XFS utilities to compile. You can find the rpm package for
|
||||
your version of Linux from <ulink url="http://www.rpmfind.net">Rpmfind.net</ulink> by searching for "/usr/lib/libuuid.a." The debian package that contains libuuid is uuid-dev. There will no doubt be other distributions that package this library in another place. A good way to find the correct package on those distributions is to search on the <ulink url="http://www.google.com/linux">Google Linux</ulink> search engine.
|
||||
|
||||
</para>
|
||||
</note>
|
||||
<para>
|
||||
Change to that directory:
|
||||
</para>
|
||||
<para>
|
||||
<programlisting>
|
||||
$ cd ../cmd/xfsprogs
|
||||
</programlisting>
|
||||
</para>
|
||||
<para>
|
||||
Build and install the xfs utilities:
|
||||
</para>
|
||||
<para>
|
||||
<programlisting>
|
||||
$ make install
|
||||
</programlisting>
|
||||
</para>
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>Boot the new kernel</title>
|
||||
<para>
|
||||
<programlisting>
|
||||
$ reboot
|
||||
</programlisting>
|
||||
</para>
|
||||
<note>
|
||||
<title>Note</title>
|
||||
<para>
|
||||
Unless you changed the default label to boot in your lilo.conf
|
||||
file you will need to enter "xfs" at the "LILO Boot:"
|
||||
prompt in order to boot the new kernel image.
|
||||
</para>
|
||||
</note>
|
||||
</sect2>
|
||||
</sect1>
|
||||
<sect1>
|
||||
<title>Filesystem Migration</title>
|
||||
<para>
|
||||
The final part of this whole process is probably actually the
|
||||
trickiest and most dangerous as far as the possibility of losing
|
||||
your data goes. I strongly suggest that you make a complete backup
|
||||
of the system (or at least all important data) before attempting
|
||||
the migration to XFS. This part is also the most difficult to explain
|
||||
as there are probably hundreds of ways you can do this based on
|
||||
the set up of your existing filesystem. I will give you the basic
|
||||
commands for creating the new filesystems, try to give some pointers
|
||||
on how to go about shuffling filesystems, and in general just relay
|
||||
to you the way I went about migrating my own filesystems.
|
||||
</para>
|
||||
<sect2>
|
||||
<title>Migrating the / filesystem</title>
|
||||
<para>
|
||||
Probably the trickiest part of creating a fully XFS system is
|
||||
migrating the / filesystem since that is the system that supports
|
||||
the entire rest of the system and it cannot actually be unmounted
|
||||
while the system is running. If you have extra partitions that
|
||||
can be mounted as / then you will be able to do it something like
|
||||
this(I am using /dev/hda4 as the spare partition and /dev/hda2 as
|
||||
/ for this example):
|
||||
</para>
|
||||
<para>
|
||||
<programlisting>
|
||||
$ mkfs -t ext2 /dev/hda4
|
||||
$ mkdir /mnt/temp
|
||||
$ mount -t ext2 /dev/hda4 /mnt/temp
|
||||
$ cd /
|
||||
$ tar lcf - .|(cd /mnt/temp; tar xpvf - )
|
||||
</programlisting>
|
||||
</para>
|
||||
<para>
|
||||
Notice I have used tar here to copy the files from the / fs to
|
||||
the spare partition. Alternatively you could use cp -dpR, but if
|
||||
you use tar like I've shown here with the -l flag it will copy only
|
||||
files from within the / fs (i.e. if you have another partition mounted
|
||||
as /usr it won't copy those).
|
||||
</para>
|
||||
<para>
|
||||
The next step will be to change all references to /dev/hda2 to
|
||||
/dev/hda4 in /etc/fstab and in /etc/lilo.conf and run lilo. You'll
|
||||
then need to reboot the system again.
|
||||
</para>
|
||||
<para>
|
||||
After rebooting the system /dev/hda4 will be mounted as / and
|
||||
your original / filesystem (/dev/hda2) will not be mounted. You
|
||||
can now create the new XFS filesystem on /dev/hda2.
|
||||
</para>
|
||||
<para>
|
||||
<programlisting>
|
||||
$ mkfs -t xfs /dev/hda2
|
||||
</programlisting>
|
||||
</para>
|
||||
<para>
|
||||
Then mount the new xfs fs:
|
||||
</para>
|
||||
<para>
|
||||
<programlisting>
|
||||
$ mount -t xfs /dev/hda2 /mnt/temp
|
||||
</programlisting>
|
||||
</para>
|
||||
<para>
|
||||
And copy the original / fs back to its original home:
|
||||
</para>
|
||||
<para>
|
||||
<programlisting>
|
||||
$ cd /
|
||||
$ tar lcf - .|(cd /mnt/temp; tar xpvf -)
|
||||
</programlisting>
|
||||
</para>
|
||||
<para>
|
||||
Once again you will need to change all instances of /dev/hda4
|
||||
in /etc/fstab and /etc/lilo.conf and run lilo. You will also need
|
||||
to change the filesystem type for / in /etc/fstab. It should now
|
||||
look something like this:
|
||||
</para>
|
||||
<para>
|
||||
<programlisting>
|
||||
/dev/hda2 / xfs defaults 1 1
|
||||
</programlisting>
|
||||
</para>
|
||||
<note>
|
||||
<title>Note</title>
|
||||
<para>
|
||||
On some linux distributions the options given to the out-of-box
|
||||
fstab may be more in depth than just "defaults." For
|
||||
instance, on Debian systems they use "defaults,errors=remount-ro."
|
||||
The mount options are different for every filesystem with the exception
|
||||
of the keyword "defaults." Unless you know the specific
|
||||
XFS mount options you want you should stick with just the defaults
|
||||
option. In the Debian example given, the errors option is not available
|
||||
with XFS and will cause your filesystem not to mount.
|
||||
</para>
|
||||
<para>
|
||||
Additionally, filesystem labels are becoming more popular so you may see an
|
||||
entry in your fstab that looks something like this:
|
||||
<programlisting>
|
||||
LABEL=/ / ext2 defaults 1 1
|
||||
</programlisting>
|
||||
The easiest way to avoid problems is to simply replace the referenced label
|
||||
with the proper device file name (i.e. if /dev/hda1 is labeled / replace "LABEL=/"
|
||||
with "/dev/hda1").
|
||||
</para>
|
||||
</note>
|
||||
<para>
|
||||
Now reboot the system with the new xfs / filesystem.
|
||||
</para>
|
||||
<para>
|
||||
Of course there are a lot of other ways to accomplish the root
|
||||
filesystem migration and if you think you have a good one I would
|
||||
definitely like to hear it and will put it in this doc if it seems
|
||||
like a simpler way than what is here. I, myself, didn't have a
|
||||
spare partition to work with but had a CD burner so I burnt a cd
|
||||
of my root filesystem to mount as root while I created the new xfs
|
||||
/. In all cases, however, the basic commands for creating and mounting
|
||||
the new filesystem will be the same.
|
||||
</para>
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>Finishing up</title>
|
||||
<para>
|
||||
The last of the process is fairly simple and essentially the
|
||||
same process of swapping around partitions while making new filesystems
|
||||
as was done for /. I recommend that you do the rest of this process
|
||||
with the system in single user mode so you can unmount everything
|
||||
other than / and do all of the swapping without having to reboot
|
||||
a million times. You can boot to single user mode by either issueing
|
||||
a runlevel change command to the init process like so:
|
||||
</para>
|
||||
<para>
|
||||
<programlisting>
|
||||
$ telinit 1
|
||||
</programlisting>
|
||||
</para>
|
||||
<para>
|
||||
or by rebooting and asking for single user mode at the Lilo prompt:
|
||||
|
||||
</para>
|
||||
<para>
|
||||
<programlisting>
|
||||
LILO Boot: xfs single
|
||||
</programlisting>
|
||||
</para>
|
||||
<para>
|
||||
This will boot the system and drop you into a root shell with
|
||||
no outside connections or virtual terminals so there is no chance
|
||||
of any of the filesystems being in use by other users or processes
|
||||
(causing them to be busy so you can't unmount them). Now you can
|
||||
mount the spare partition, as before, copy one of the remaining filesystems
|
||||
to be migrated onto it (you will probably have to remove the existing
|
||||
contents leftover from /), unmount the old filesystem, create the
|
||||
xfs filesystem on it, remount it as xfs, and copy the old filesystem
|
||||
back onto it. Lets say you have a /dev/hda3 partition mounted as
|
||||
/usr. The process would go something like this:
|
||||
</para>
|
||||
<para>
|
||||
<programlisting>
|
||||
$ mount -t ext2 /dev/hda4 /mnt/temp
|
||||
$ cd /usr
|
||||
$ tar lcf - .|(cd /mnt/temp; tar xpvf - )
|
||||
$ cd /mnt/temp
|
||||
$ umount /usr
|
||||
$ mkfs -t xfs /dev/hda3
|
||||
$ mount -t xfs /dev/hda3 /usr
|
||||
$ tar lcf - .|(cd /usr; tar xpvf - )
|
||||
</programlisting>
|
||||
</para>
|
||||
<para>
|
||||
Don't forget to change the filesystem type in /etc/fstab for
|
||||
/usr to xfs.
|
||||
</para>
|
||||
<para>
|
||||
That's all there is to it. The rest of the filesystems to be
|
||||
migrated will work the same way, then you can reboot to full miltiuser
|
||||
mode and you've got your "Linux on Steroids!"
|
||||
</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
</article>
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
Binary file not shown.
|
Before Width: | Height: | Size: 1.7 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 1.2 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 6.1 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 5.9 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 3.9 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 5.0 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 4.5 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 969 B |
Binary file not shown.
|
Before Width: | Height: | Size: 1.9 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 1.6 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 3.1 KiB |
|
|
@ -1,671 +0,0 @@
|
|||
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V3.1//EN">
|
||||
|
||||
<article id="index">
|
||||
|
||||
<!-- Header -->
|
||||
|
||||
<artheader>
|
||||
|
||||
<!-- title of HOWTO, include the word HOWTO -->
|
||||
|
||||
<title>KDE Kiosk Mode HOWTO</title>
|
||||
|
||||
<author>
|
||||
<firstname>Roland</firstname>
|
||||
<surname>Fehrenbacher</surname>
|
||||
<affiliation>
|
||||
<address>
|
||||
<email>rfehrenb@transtec.de</email>
|
||||
</address>
|
||||
</affiliation>
|
||||
</author>
|
||||
|
||||
<author>
|
||||
<firstname>Peter</firstname>
|
||||
<surname>Kruse</surname>
|
||||
<affiliation>
|
||||
<address>
|
||||
<email>Peter.Kruse@wolnet.de</email>
|
||||
</address>
|
||||
</affiliation>
|
||||
</author>
|
||||
|
||||
<revhistory>
|
||||
<revision>
|
||||
<revnumber>1.4</revnumber>
|
||||
<date>2002-09-26</date>
|
||||
<authorinitials>gjf</authorinitials>
|
||||
<revremark>Archived.</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>$Revision$</revnumber>
|
||||
<date>$Date$</date>
|
||||
<authorinitials>$Author$</authorinitials>
|
||||
<revremark>
|
||||
|
||||
<comment>
|
||||
$Log$
|
||||
Revision 1.3 2001/08/14 07:44:07 kruse
|
||||
nicer formatting.
|
||||
|
||||
Revision 1.2 2001/08/14 07:42:50 pkruse
|
||||
.
|
||||
|
||||
Revision 1.1 2001/08/03 13:56:20 pkruse
|
||||
almost published.
|
||||
|
||||
Revision 1.4 2001/07/31 14:15:21 pkruse
|
||||
prepare to check in linuxdoc cvs.
|
||||
|
||||
Revision 1.3 2001/07/31 13:39:12 pkruse
|
||||
variable and filename docbook tags added.
|
||||
|
||||
Revision 1.2 2001/07/31 11:05:51 pkruse
|
||||
first revision.
|
||||
|
||||
Revision 1.1 2001/07/31 10:49:51 pkruse
|
||||
Initial revision
|
||||
</comment>
|
||||
|
||||
</revremark>
|
||||
</revision>
|
||||
|
||||
<!-- Additional (*earlier*) revision histories go here -->
|
||||
</revhistory>
|
||||
|
||||
<abstract>
|
||||
|
||||
<para>
|
||||
The requirements for the desktop environment of users in a large
|
||||
network environment is often very different to a typical homeuser. The
|
||||
number of applications that these users need to run is usually very
|
||||
limited, and the users themselves are not very experienced in solving
|
||||
computing related problems. The administrators of the network
|
||||
therefore need to ensure that the required applications run reliably,
|
||||
and can be started by the users with a minimum of hassle. For
|
||||
security, stability, and also administrative reasons it is then
|
||||
advisable to provide only the absolutely necessary applications and
|
||||
functionality.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
With the advent of modern desktop technology like KDE, this goal has become
|
||||
harder to achieve. Interoperability between different desktop programs, ease
|
||||
of configuration by configuration engines, etc. allow the user a great deal
|
||||
of control over her/his desktop, which is great when needed. The above large
|
||||
network scenario, however, is not addressable in standard KDE. This is where
|
||||
the restricted mode tries to fill in the gap.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<important>
|
||||
<para>
|
||||
<emphasis role="strong">Archived Document Notice: </emphasis>
|
||||
This document has been archived by the LDP because it does not apply
|
||||
to modern Linux systems. It is no longer being actively maintained.
|
||||
Further information on this topic can be found at
|
||||
<ulink url="http://www.brigadoon.de/peter/kde/">http://www.brigadoon.de/peter/kde/</ulink>.
|
||||
</para>
|
||||
</important>
|
||||
</para>
|
||||
</abstract>
|
||||
|
||||
</artheader>
|
||||
|
||||
|
||||
<!-- Section1: intro -->
|
||||
|
||||
<sect1 id="intro">
|
||||
<title>Introduction</title>
|
||||
|
||||
<para>
|
||||
This document describes a by-product of a project, in which a large
|
||||
number of Linux based workstations were provided. Although a
|
||||
kiosk-mode patch exists for KDE 1, this document assumes KDE 2 and the
|
||||
patches apply to KDE version 2.1.1(2).
|
||||
</para>
|
||||
|
||||
<!-- Section2: copyright -->
|
||||
|
||||
<sect2 id="copyright">
|
||||
<title>Copyright Information</title>
|
||||
|
||||
<para>
|
||||
This document is copyrighted (c) 2001 Peter Kruse and Roland
|
||||
Fehrenbacher and is distributed under the terms of the Linux
|
||||
Documentation Project (LDP) license, stated below.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Unless otherwise stated, Linux HOWTO documents are
|
||||
copyrighted by their respective authors. Linux HOWTO documents may
|
||||
be reproduced and distributed in whole or in part, in any medium
|
||||
physical or electronic, as long as this copyright notice is
|
||||
retained on all copies. Commercial redistribution is allowed and
|
||||
encouraged; however, the authors would like to be notified of any
|
||||
such distributions.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
All translations, derivative works, or aggregate works
|
||||
incorporating any Linux HOWTO documents must be covered under this
|
||||
copyright notice. That is, you may not produce a derivative work
|
||||
from a HOWTO and impose additional restrictions on its
|
||||
distribution. Exceptions to these rules may be granted under
|
||||
certain conditions; please contact the Linux HOWTO coordinator at
|
||||
the address given below.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In short, we wish to promote dissemination of this
|
||||
information through as many channels as possible. However, we do
|
||||
wish to retain copyright on the HOWTO documents, and would like to
|
||||
be notified of any plans to redistribute the HOWTOs.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If you have any questions, please contact
|
||||
<email>linux-howto@metalab.unc.edu</email>
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
<!-- Section2: disclaimer -->
|
||||
|
||||
<sect2 id="disclaimer">
|
||||
<title>Disclaimer</title>
|
||||
|
||||
<para>
|
||||
No liability for the contents of this documents can be accepted.
|
||||
Use the concepts, examples and other content at your own risk.
|
||||
As this is a new edition of this document, there may be errors
|
||||
and inaccuracies, that may of course be damaging to your system.
|
||||
Proceed with caution, and although this is highly unlikely,
|
||||
the authors do not take any responsibility for that.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
All copyrights are held by their by their respective owners, unless
|
||||
specifically noted otherwise. Use of a term in this document
|
||||
should not be regarded as affecting the validity of any trademark
|
||||
or service mark.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Naming of particular products or brands should not be seen
|
||||
as endorsements.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
You are strongly recommended to take a backup of your system
|
||||
before major installation and backups at regular intervals.
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
<!-- Section2: newversions-->
|
||||
|
||||
<sect2 id="newversions">
|
||||
<title>New Versions</title>
|
||||
|
||||
<para>
|
||||
This document and the patches are available at
|
||||
<ulink url="http://www.brigadoon.de/peter/kde">http://www.brigadoon.de/peter/kde</ulink>.
|
||||
</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<!-- Section2: credits -->
|
||||
|
||||
<sect2 id="credits">
|
||||
<title>Credits</title>
|
||||
|
||||
<para>
|
||||
<email>Werner.Westerkamp (at) lbbw.de</email> for giving useful
|
||||
tips, and proof-reading this HOWTO
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<email>remalone (at) sympatico.ca</email> for first-time testing
|
||||
the instructions given here
|
||||
</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<!-- Section2: feedback -->
|
||||
|
||||
<sect2 id="feedback">
|
||||
<title>Feedback</title>
|
||||
|
||||
<para>
|
||||
Please send any comments, corrections or additions to one of the authors.
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
</sect1>
|
||||
|
||||
<!-- Section1: intro: END -->
|
||||
|
||||
|
||||
<sect1 id="motivation">
|
||||
<title>Motivation</title>
|
||||
|
||||
<para>
|
||||
The following requirements had to be met:
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para>The user should not be able to open an interactive shell
|
||||
(Terminal), or run arbitrary commands,
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
The user should not have a view to the filesystem, so no
|
||||
filemanager,
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>The user should not be able to modify or create files
|
||||
directly by means provided by KDE (no editor, menuedit, etc.).
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
<para>
|
||||
Note that these are not requirements for the applications that run under KDE.
|
||||
Every application should make sure by itself, that these requirements are met.
|
||||
It is known, that of course many applications have an Open File Dialog, and
|
||||
thus could modify Files under .kde and so make it possible to run arbitrary
|
||||
commands.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The restrictions should only apply when an environment variable
|
||||
<EnVar>KDE_MODE</EnVar> is
|
||||
set to ``restricted''. If it is not set, a normal KDE Desktop should open.
|
||||
|
||||
It follows, that the user can only run applications that are found in
|
||||
the Application menu. So the administrator must be able to provide the
|
||||
applications. A tool is needed to add, remove and modify entries in
|
||||
the menu.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<!-- Section1: samples: END -->
|
||||
|
||||
|
||||
<!-- Section1: structure -->
|
||||
|
||||
<sect1 id="implementation">
|
||||
<title>Implementation</title>
|
||||
|
||||
<sect2 id="patches">
|
||||
<title>Source Code Patches</title>
|
||||
|
||||
<para>
|
||||
Some files in kdebase-2.1.1 have to be patched:
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
appletop_mnu.cpp.patch: Applets on the panel can be moved and removed, but
|
||||
the Preferences dialog is disabled.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
k_mnu.cpp.patch: <guimenuitem>Run Command...</guimenuitem> and
|
||||
<guisubmenu>Configure Panel</guisubmenu> entries are
|
||||
removed from the standard <guimenu>K</guimenu> Menu
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
khc_man.cc.patch: Online Help is completely disabled. This would
|
||||
open konqueror.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
konq_popupmenu.cc.patch: right-mouse menu on icons on the desktop
|
||||
are reduced to <guimenuitem>Cut</guimenuitem>,
|
||||
<guimenuitem>Copy</guimenuitem>, <guimenuitem>Paste</guimenuitem>,
|
||||
<guimenuitem>Delete</guimenuitem>, ... but no <guimenuitem>Open With
|
||||
...</guimenuitem>,
|
||||
no <guimenuitem>Edit File Type...</guimenuitem> and no
|
||||
<guimenuitem>Poperties...</guimenuitem> dialogs.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
pagerapplet.cpp.patch: on minipager selection of type
|
||||
(<guimenuitem>Preview</guimenuitem>,
|
||||
<guimenuitem>Number</guimenuitem>,
|
||||
<guimenuitem>Name</guimenuitem>) is disabled. this caused trouble in
|
||||
multihead environment.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
panel.cpp.patch: right mouse menu on Panel is disabled.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="global-modification">
|
||||
<title>Global modifications</title>
|
||||
|
||||
<para>
|
||||
|
||||
Instead of a dcop call, a program <command>screensaver</command> is
|
||||
executed, which must be found in the <envar>PATH</envar>. Just create
|
||||
a script called <command>screensaver</command>
|
||||
with the following contents:
|
||||
|
||||
<programlisting>
|
||||
#!/bin/bash
|
||||
|
||||
dcop kdesktop KScreensaverIface lock
|
||||
</programlisting>
|
||||
|
||||
make it executable and put it in <filename>$KDEDIR/bin</filename>.
|
||||
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
||||
Instead of the normal procedure, a program <command>klogout</command>
|
||||
is called, which must be found in the <envar>PATH</envar>. Create a
|
||||
script called <command>klogout</command> with the following contents:
|
||||
|
||||
<programlisting>
|
||||
#!/bin/bash
|
||||
|
||||
dcop kdesktop KDesktopIface logout
|
||||
</programlisting>
|
||||
make it executable and put it in <filename>$KDEDIR/bin</filename>,
|
||||
where <filename>$KDEDIR</filename> is the install directory of KDE and
|
||||
<filename>$KDEDIR/bin</filename> is found in your
|
||||
<EnVar>PATH</EnVar>.
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
krootwm.cc.patch: klogout is executed instead of a dcop call
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
systemtrayapplet.cpp.patch: again call of klogout and screensaver
|
||||
instead of dcop calls.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
workspace.cpp.patch: call of klogout instead of dcop call.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
<para>
|
||||
Everything else can be done with normal configuration, that is:
|
||||
|
||||
(Configuration files can be found in <filename>$KDEDIR/share/config</filename>)
|
||||
|
||||
Remove Trash, Templates and Autostart Icons from the desktop and disable
|
||||
<keycombo action="Simul"><keycap>Alt</keycap><keycap>F2</keycap></keycombo>
|
||||
by modifying <filename>kdeglobals</filename>. Make sure the following
|
||||
entries exist:
|
||||
|
||||
<programlisting>
|
||||
[Paths]
|
||||
|
||||
Trash=$HOME/.kde2/Trash/
|
||||
|
||||
Autostart=$HOME/.kde2/Autostart/
|
||||
|
||||
Templates=$HOME/.kde2/Templates/
|
||||
|
||||
Desktop=$HOME/.kde2/Desktop/
|
||||
|
||||
|
||||
[Global Keys]
|
||||
|
||||
Execute command=
|
||||
</programlisting>
|
||||
|
||||
(it may be <filename>.kde</filename> instead of <filename>.kde2</filename>)
|
||||
|
||||
</para>
|
||||
|
||||
<para>
|
||||
disable Desktop menu and tips on start. Make sure the following entry
|
||||
exists in <filename>kdesktoprc</filename>:
|
||||
|
||||
<programlisting>
|
||||
[Mouse Buttons]
|
||||
|
||||
Right=
|
||||
|
||||
[General]
|
||||
|
||||
TipsOnStart=false
|
||||
</programlisting>
|
||||
|
||||
You could also login as the special user, and configure it only for
|
||||
him, then the config files are found in <filename>$KDEHOME/share/config</filename> where
|
||||
<filename>$KDEHOME</filename> is normally <filename>$HOME/.kde</filename>.
|
||||
|
||||
</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 id="kde-mode">
|
||||
<title>How to set the variable KDE_MODE</title>
|
||||
|
||||
<para>
|
||||
To answer this, you must understand what happens after you
|
||||
successfully authorized yourself to the system: Depending on your
|
||||
distribution, some scripts are executed, from which one should be
|
||||
modified to set <EnVar>KDE_MODE</EnVar>. There is a script called
|
||||
<Command>Xsession</Command> under <filename>/etc/X11/xdm</filename> or
|
||||
<filename>/usr/X11R6/lib/xdm</filename>, which you could modify, or
|
||||
<Command>startkde</Command>, that is located under
|
||||
<filename>$KDEDIR/bin</filename>. Note however, that the variable
|
||||
must be set prior to calling the kde processes.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Since we had the need to make a setup for a big environment (now
|
||||
reaching 300 users) we wrote an application that enables us to
|
||||
administer. It also creates the KDE Menus. It writes a file called
|
||||
<filename>.env.sh</filename> in a user's home directory, that will be
|
||||
sourced in <Command>Xsession</Command>. That is what you could do. So
|
||||
you could put in <filename>.env.sh</filename> of that specific user's
|
||||
home directory:
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
#!/bin/sh
|
||||
|
||||
KDE_MODE="restricted"
|
||||
|
||||
export KDE_MODE
|
||||
</programlisting>
|
||||
|
||||
<para>
|
||||
and add to Xsession, somewhere prior to calling startkde:
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
if [ -f $HOME/.env.sh ]; then
|
||||
|
||||
. $HOME/.env.sh
|
||||
|
||||
fi
|
||||
</programlisting>
|
||||
|
||||
<para>
|
||||
We also have two kdedirs that looks like to separate installations of
|
||||
KDE, this was neccessary so "normal" users could still have a
|
||||
full-featured KDE. So we have an original kdedir, and a restricted
|
||||
kdedir, in which we removed entries under
|
||||
<filename>share/applnk</filename> and set the variable
|
||||
<envar>KDEDIR</envar> (under KDE 2 the variable <envar>KDEDIRS</envar>
|
||||
was introduced but <envar>KDEDIR</envar> is still used). The files
|
||||
under <filename>share/applnk</filename> make up the menu. Caution, you
|
||||
cannot just remove all files there, because some are needed to
|
||||
initialize KDE.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
You also set the Variable <envar>KDEDIR</envar> in
|
||||
<command>Xsession</command>, after sourcing
|
||||
<filename>.env.sh</filename> like this:
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
case "$KDE_MODE" in
|
||||
|
||||
restricted)
|
||||
|
||||
KDEDIR=/usr/local/kde/restricted_kdedir
|
||||
|
||||
;;
|
||||
|
||||
*)
|
||||
|
||||
KDEDIR=/usr/local/kde
|
||||
|
||||
esac
|
||||
|
||||
export KDEDIR
|
||||
</programlisting>
|
||||
|
||||
<para>
|
||||
Replace <filename>/usr/local/kde</filename> with the install directory
|
||||
of your KDE. The contents of
|
||||
<filename>/usr/local/kde/restricted_kdedir</filename> looks like:
|
||||
|
||||
<screen>
|
||||
|
||||
bin -> ../bin
|
||||
|
||||
cgi-bin -> ../cgi-bin
|
||||
|
||||
etc -> ../etc
|
||||
|
||||
lib -> ../lib
|
||||
|
||||
share
|
||||
|
||||
</screen>
|
||||
|
||||
</para>
|
||||
|
||||
<para>
|
||||
only share is a real directory, every other directory is a symbolic
|
||||
link pointing to original
|
||||
kdedir. <filename>/usr/local/kde/restricted_kdedir/share</filename>
|
||||
has the following contents:
|
||||
|
||||
<screen>
|
||||
|
||||
aclocal -> ../../share/aclocal
|
||||
|
||||
applnk
|
||||
|
||||
apps -> ../../share/apps
|
||||
|
||||
autostart -> ../../share/autostart
|
||||
|
||||
config -> ../../share/config
|
||||
|
||||
doc -> ../../share/doc
|
||||
|
||||
fonts -> ../../share/fonts
|
||||
|
||||
icons -> ../../share/icons
|
||||
|
||||
locale -> ../../share/locale
|
||||
|
||||
mimelnk -> ../../share/mimelnk
|
||||
|
||||
services -> ../../share/services
|
||||
|
||||
servicetypes -> ../../share/servicetypes
|
||||
|
||||
sounds -> ../../share/sounds
|
||||
|
||||
templates -> ../../share/templates
|
||||
|
||||
wallpapers -> ../../share/wallpapers
|
||||
|
||||
</screen>
|
||||
|
||||
</para>
|
||||
|
||||
<para>
|
||||
only applnk is a real directory. As a minimal requirement remove
|
||||
everything except:
|
||||
|
||||
<screen>
|
||||
|
||||
Settings/Peripherals/mouse.desktop
|
||||
|
||||
Settings/LookNFeel/background.desktop
|
||||
|
||||
/colors.desktop
|
||||
|
||||
/kwinoptions.desktop
|
||||
|
||||
/style.desktop
|
||||
|
||||
/virtualdesktops.desktop
|
||||
|
||||
</screen>
|
||||
|
||||
under <filename>/usr/local/kde/restricted_kdedir/share/applnk</filename>
|
||||
|
||||
</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
</sect1>
|
||||
|
||||
</article>
|
||||
|
||||
<!-- Keep this comment at the end of the file
|
||||
Local variables:
|
||||
mode: sgml
|
||||
sgml-omittag:t
|
||||
sgml-shorttag:t
|
||||
sgml-namecase-general:t
|
||||
sgml-general-insert-case:lower
|
||||
sgml-minimize-attributes:nil
|
||||
sgml-always-quote-attributes:t
|
||||
sgml-indent-step:1
|
||||
sgml-indent-data:nil
|
||||
sgml-parent-document:nil
|
||||
sgml-exposed-tags:nil
|
||||
sgml-local-catalogs:nil
|
||||
sgml-local-ecat-files:nil
|
||||
End:
|
||||
-->
|
||||
|
|
@ -1,417 +0,0 @@
|
|||
<!DOCTYPE ARTICLE PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
|
||||
|
||||
<article>
|
||||
<articleinfo>
|
||||
<title>Using Term to Pierce an Internet Firewall mini-HOWTO</title>
|
||||
|
||||
<copyright><year>1996</year><holder>Barak Pearlmutter</holder></copyright>
|
||||
<copyright><year>2001</year><holder>David C. Merrill</holder></copyright>
|
||||
|
||||
<author>
|
||||
<firstname>Barak</firstname>
|
||||
<surname>Pearlmutter</surname>
|
||||
<affiliation>
|
||||
<address><email>bap@cs.unm.edu</email></address>
|
||||
</affiliation>
|
||||
</author>
|
||||
|
||||
<author>
|
||||
<firstname>David</firstname>
|
||||
<othername>C.</othername>
|
||||
<surname>Merrill</surname>
|
||||
<affiliation>
|
||||
<address>david -AT- lupercalia.net</address>
|
||||
</affiliation>
|
||||
</author>
|
||||
|
||||
<revhistory>
|
||||
<revision>
|
||||
<revnumber>1.1</revnumber>
|
||||
<date>2001-07-14</date>
|
||||
<authorinitials>dcm</authorinitials>
|
||||
<revremark>
|
||||
Cleaned up a bit, reorganized a bit, converted to DocBook SGML
|
||||
and relicensed under GFDL.
|
||||
</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>1.0</revnumber>
|
||||
<date>1996-07-15</date>
|
||||
<authorinitials>pb</authorinitials>
|
||||
<revremark>Initial Release.</revremark>
|
||||
</revision>
|
||||
</revhistory>
|
||||
|
||||
<abstract>
|
||||
<para>
|
||||
This document explains how to use the <command>term</command> program
|
||||
to pierce a firewall from the inside, even without root privileges.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Term is an old program that almost no one uses anymore,
|
||||
because the 7-bit serial lines it is meant to cross are nowhere
|
||||
to be found anymore, and full IP ppp access is dirt cheap.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<important>
|
||||
<para>
|
||||
<emphasis role="strong">Archived Document Notice: </emphasis>
|
||||
This document has been archived by the LDP because it does not apply
|
||||
to modern Linux systems. It is no longer being actively maintained.
|
||||
</para>
|
||||
</important>
|
||||
</para>
|
||||
|
||||
</abstract>
|
||||
|
||||
</articleinfo>
|
||||
|
||||
<sect1 id="preface">
|
||||
<title>Preface</title>
|
||||
|
||||
<sect2 id="disclaimer">
|
||||
<title>Disclaimer</title>
|
||||
|
||||
<para>
|
||||
While every precaution has been taken in the preparation of this document,
|
||||
the Linux Documentation Project and the author(s) assume no responsibility
|
||||
for errors or omissions, or for damages resulting from the use of the
|
||||
information contained herein.
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="license">
|
||||
<title>License</title>
|
||||
|
||||
<para>
|
||||
This document is made available under the terms of the
|
||||
<ulink url="http://www.gnu.org/copyleft/fdl.html"><citetitle>GNU Free Documentation License (GFDL)</citetitle></ulink>,
|
||||
which is hereby incorporated by reference.
|
||||
</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="introduction">
|
||||
<title>Introduction</title>
|
||||
|
||||
<para>
|
||||
The <command>term</command> program is usually used to provide host-to-host services
|
||||
over a modem or serial line.
|
||||
|
||||
However, sometimes it is useful to establish a term
|
||||
connection between two machines that communicate via telnet.
|
||||
The most
|
||||
interesting example is connecting two hosts which are
|
||||
separated by ethernet firewalls or SOCKS servers. Such firewalls
|
||||
provide facilities for establishing a telnet connection through the
|
||||
firewall, typically by using the SOCKS protocol, to allow inside
|
||||
machines to get connections out, and requiring outside users to telnet
|
||||
first to a gateway machine which requires a one-time password. These
|
||||
firewalls make it impossible to, for instance, have X clients on an
|
||||
inside machine communicate with an X server on an outside machine.
|
||||
But, by setting up a term connection, these restrictions can all be
|
||||
bypassed quite conveniently, at the user level.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="basics">
|
||||
<title>The Basic Procedure</title>
|
||||
|
||||
<para>
|
||||
Setting up a term connection over a telnet substrate is a two-phase
|
||||
process. First your usual telnet client is used to set up a telnet
|
||||
connection and log in. Next, the telnet client is paused and control
|
||||
of the established telnet connection is given to term.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="details">
|
||||
<title>Detailed Directions</title>
|
||||
|
||||
<para>
|
||||
First, from a machine inside the firewall, telnet to a target machine
|
||||
outside the firewall and log in.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Unless you are under linux and will be using the proc filesystem (see
|
||||
below) make sure your shell is an sh style shell. Ie if your default
|
||||
shell is a csh variant, invoke telnet by:
|
||||
</para>
|
||||
|
||||
<para><screen>setenv SHELL /bin/sh; telnet machine.outside</screen></para>
|
||||
|
||||
<para>
|
||||
After logging in, on the remote (outside) machine invoke the command:
|
||||
</para>
|
||||
|
||||
<para><screen>term -r -n off telnet</screen></para>
|
||||
|
||||
<para>
|
||||
Now break back to the telnet prompt on the local (inside) machine,
|
||||
using <literal>^]</literal> or whatever, and use the telnet shell escape command
|
||||
<literal>!</literal> to invoke term:
|
||||
</para>
|
||||
|
||||
<para><screen>telnet> ! term -n on telnet >&3 <&3</screen></para>
|
||||
|
||||
<para>
|
||||
That's it!
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If you have a variant telnet, you might have to use some other file
|
||||
descriptor than 3; easy to check using strace. But three seems to
|
||||
work on all bsd descendent telnet clients I've tried, under both SunOS
|
||||
4.x and the usual linux distributions.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Some telnet clients do not have the ! shell escape command. Eg the
|
||||
telnet client distributed with Slackware 3.0 is one such client. The
|
||||
sources that the Slackware telnet client is supposedly built from
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<ulink url="ftp://ftp.cdrom.com:/pub/linux/slackware-3.0/source/n/tcpip/NetKit-B-0.05.tar.gz">
|
||||
<citetitle>ftp://ftp.cdrom.com:/pub/linux/slackware-3.0/source/n/tcpip/NetKit-B-0.05.tar.gz</citetitle></ulink>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
A simple solution is therefore to
|
||||
obtain these sources and recompile them. This unfortunately is a task
|
||||
I have had no luck with. Plus, if you are running from inside a SOCKS
|
||||
firewall, you will need a SOCKSified telnet client anyway. To that
|
||||
end, I was able to compile a SOCKSified telnet client from:
|
||||
</para>
|
||||
|
||||
<para><ulink url="ftp://ftp.nec.com/pub/security/socks.cstc/socks.cstc.4.2.tar.gz">
|
||||
<citetitle>ftp://ftp.nec.com/pub/security/socks.cstc/socks.cstc.4.2.tar.gz</citetitle></ulink>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
or, if you're outside the USA,
|
||||
</para>
|
||||
|
||||
<para><ulink url="ftp://ftp.nec.com/pub/security/socks.cstc/export.socks.cstc.4.2.tar.gz">
|
||||
<citetitle>ftp://ftp.nec.com/pub/security/socks.cstc/export.socks.cstc.4.2.tar.gz</citetitle></ulink>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Alternatively, under linux kernels up to 1.2.13, you can pause the
|
||||
telnet with <literal>^]^z</literal>, figure out its pid, and invoke:
|
||||
</para>
|
||||
|
||||
<para><screen>term -n on -v /proc/&,t;telnetpid>/fd/3 telnet</screen></para>
|
||||
|
||||
<para>
|
||||
This doesn't work with kernels after 1.3.x, which closed some
|
||||
mysterious security hole by preventing access to these fd's by
|
||||
processes other than the owner process and its children.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="termsockets">
|
||||
<title>Multiple Term Sockets</title>
|
||||
|
||||
<para>
|
||||
It is a good idea to give the term socket an explicit name.
|
||||
This is the <literal>telnet</literal>; argument in the invocations
|
||||
of term above.
|
||||
Unless you have the TERMSERVER environment variable set to telnet as
|
||||
appropriate, you invoke term clients with the -t switch,
|
||||
e.g., <literal>trsh -t telnet</literal>.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="termrc.telnet">
|
||||
<title>The <<filename>˜/.term/termrc.telnet</filename> Init File</title>
|
||||
|
||||
<para>
|
||||
I have checked line clarity using linecheck over this medium.
|
||||
I expected it to be completely transparent, but it is not.
|
||||
However, the only bad character seems to be 255.
|
||||
The <filename>˜/.term/termrc.telnet</filename> I use
|
||||
(the <filename>.telnet</filename> is the name of the term connection, see above)
|
||||
contains:
|
||||
</para>
|
||||
|
||||
<para><screen>baudrate off
|
||||
escape 255
|
||||
ignore 255
|
||||
timeout 600</screen></para>
|
||||
|
||||
<para>
|
||||
Perhaps it could be improved by diddling,
|
||||
I am getting a throughput of only about 30k cps over
|
||||
a long-haul connection through a slow firewall.
|
||||
Ftp can move about 100k cps over the same route.
|
||||
A realistic baudrate might avoid some timeouts.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="direction">
|
||||
<title>Direction</title>
|
||||
|
||||
<para>
|
||||
Obviously, if you are starting from outside the firewall and zitching
|
||||
in using a SecureID card or something, you will want to reverse the
|
||||
roles of the remote vs local servers given above. (If you don't
|
||||
understand what this means, perhaps you are not familiar enough with
|
||||
term to use the trick described in this file responsibly.)
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="security">
|
||||
<title>Security</title>
|
||||
|
||||
<para>
|
||||
This is not much more of a vulnerability than the current possibility
|
||||
of having a telnet connection hijacked on an unsecured outside
|
||||
machine. The primary additional risk comes from people being able to
|
||||
use the term socket you set up without you even being aware of it. So
|
||||
be careful out there. (Personally, I do this with an outside machine
|
||||
I know to be pretty secure, namely a linux laptop I maintain myself
|
||||
that does not accept any incoming connections.)
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Another possibility is to add
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<screen>socket off</screen>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
to the remote <filename>˜/.term/termrc.telnet</filename> file, or
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<screen>add "-u off"</screen>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
to the invocation of term.
|
||||
This prevents the socket from being hijacked from the remote end,
|
||||
with only a minor loss of functionality.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="telnet">
|
||||
<title>Telnet Mode</title>
|
||||
|
||||
<para>
|
||||
Be sure the remote telnetd is not in some nasty seven-bit mode.
|
||||
Or if it is, you have to tell term about it when you invoke term,
|
||||
by adding the <literal>-a</literal> switch at both ends.
|
||||
(I sometimes use <literal>>^] telnet> set outbin</literal> or
|
||||
<literal>set bin</literal>, or invoke telnet with a <literal>-8</literal> switch
|
||||
to put the connection into eight-bit mode.)
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="bugs">
|
||||
<title>Bugs and Term Wish List</title>
|
||||
|
||||
<para>
|
||||
The <command>linecheck</command> program has some problems checking telnet connections
|
||||
sometimes. This is sometimes because it doesn't check the return code
|
||||
of the <function>read()</function> call it makes. For network connections,
|
||||
this call to <function>read()</function> can return <literal>-1</literal>
|
||||
with an <literal>EINTR</literal> (interrupted) or
|
||||
<literal>EAGAIN</literal> (try again) error code.
|
||||
Obviously this should be checked for.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
There are a number of features that could ease the use of term over
|
||||
telnet. These primarily relate to an assumption that influenced the
|
||||
design of term, namely that the connection is low bandwidth, low
|
||||
latency, and somewhat noisy.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
A telnet connection is in general high bandwidth, high latency, and
|
||||
error free. This means that the connection could be better utilized
|
||||
if (a) the maximum window size was raised, well above the limit
|
||||
imposed by term's <literal>N_PACKETS/2=16</literal>,
|
||||
(b) there was an option to turn off sending and checking packet checksums,
|
||||
and (c) larger packets were permitted when appropriate.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Also, to enhance security, it would be nice to have a term option to
|
||||
log all connections through the socket it monitors to a log file, or
|
||||
to <literal>stderr</literal>, or both. This would allow one to see if one's term
|
||||
connection is being subverted by nasty hackers on the outside insecure
|
||||
machine.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="tricks">
|
||||
<title>Tricks That Do Not Seem to Work</title>
|
||||
|
||||
<para>
|
||||
Some telnet clients and servers agree to encrypt their communications,
|
||||
to prevent eavesdropping on the connection. Unfortunately, the hack
|
||||
used above (using the network connection that the telnet client has
|
||||
set up while the telnet client is idle) won't work in that case.
|
||||
Instead, one really must go through the telnet client itself, so it
|
||||
can do its encryption. It seems like that requires a simple hack to
|
||||
the telnet client itself, to add a command that runs a process with
|
||||
its <literal>stdin</literal> and <literal>stdout</literal> are connected
|
||||
to the live telnet connection.
|
||||
This would also be useful for various bots, so perhaps someone has
|
||||
already hacked it up.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="resources">
|
||||
<title>Related Resources</title>
|
||||
|
||||
<para>
|
||||
A vaguely related trick is to SOCKSify one's Term library.
|
||||
Details, including patches to SOCKS, are available from
|
||||
Steven Danz <ulink url="mailto:danz@wv.mentorg.com"><citetitle>danz@wv.mentorg.com</citetitle></ulink>.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="acknowledgements">
|
||||
<title>Acknowledgments</title>
|
||||
|
||||
<para>
|
||||
Thanks for valuable suggestions from:
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Gary Flake <ulink url="flake@scr.siemens.com"><citetitle>flake@scr.siemens.com</citetitle></ulink></para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Bill Riemers <ulink url="bcr@physics.purdue.edu"><citetitle>bcr@physics.purdue.edu</citetitle></ulink></para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Greg Louis <ulink url="glouis@dynamicro.on.ca"><citetitle>glouis@dynamicro.on.ca</citetitle></ulink></para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
</sect1>
|
||||
|
||||
</article>
|
||||
|
||||
Loading…
Reference in New Issue