LTSP5

Merge lp:~ltsp-docwriters/ltsp/ltsp-docs-trunk into lp:~ltsp-upstream/ltsp/ltsp-trunk

  1. ltsp-docs-trunk
  2. Merge into ltsp-trunk
Proposed by Richard Kweskin
Status: Rejected
Rejected by: Alkis Georgopoulos
Proposed branch: lp:~ltsp-docwriters/ltsp/ltsp-docs-trunk
Merge into: lp:~ltsp-upstream/ltsp/ltsp-trunk
Diff against target: 13293 lines (+13179/-0) (has conflicts)
22 files modified
.bzrignore (+8/-0)
AUTHORS (+17/-0)
COPYING (+339/-0)
LTSPManual-C.omf (+18/-0)
LTSPManual.xml (+3113/-0)
Makefile.in (+111/-0)
config.guess (+1465/-0)
config.sub (+1569/-0)
configure (+3233/-0)
configure.in (+49/-0)
debian/changelog (+141/-0)
debian/compat (+1/-0)
debian/control (+20/-0)
debian/copyright (+66/-0)
debian/ltsp-docs.doc-base (+11/-0)
debian/rules (+4/-0)
debian/source/format (+1/-0)
debian/watch (+10/-0)
install-sh (+323/-0)
lts.conf.xml (+1878/-0)
release.conf (+3/-0)
savedinfo.xml (+799/-0)
Conflict adding file .bzrignore.  Moved existing file to .bzrignore.moved.
Conflict adding file COPYING.  Moved existing file to COPYING.moved.
Conflict adding file release.conf.  Moved existing file to release.conf.moved.
To merge this branch: bzr merge lp:~ltsp-docwriters/ltsp/ltsp-docs-trunk
Reviewer Review Type Date Requested Status
Alkis Georgopoulos Disapprove
Review via email: mp+318211@code.launchpad.net

Description of the change

Installing LTSP using the LTSP-PNP method

At the time of writing the version of LTSP in Debian Stretch is 5.5.9-2, Debian Jessie is 5.5.4-4, while in Debian Wheezy 5.4.2-6+deb7u1. ltsp-pnp uses the server / (its entire root file system) as a template for the default "chroot". Using this default there is less flexibilty since the clients must run the same version of distribution and platform as the server. The upside is that the model is easier to maintain. Thus a 32bit version (Stretch i386 or Jessie i386 or Wheezy i386) is suggested. While creating additional separate chroots is possible, the usual application where there is no separate chroot (sometimes referred to as ltsp-pnp) is the norm and nbd (rather than nfs) is used to provide a squashfs image.
The use of dnsmasq provides ease of configurability and maintenance and unlike isc dhcpd dnsmasq can be used to provide dhcp-proxy. Often the router is already providing dhcp so this additional option with dnsmasq is the easiest way to avoid conflict arising from there being two dhcp servers on the same subnet.
===============================================================

Note that at the time of writing the Jessie kernel was linux-image-3.16.0-4-586
dpkg-reconfigure linux-image-3.16.0-4-586
This reports update-initramfs: Generating /boot/initrd.img-3.16.0-4-586 adding the changes above and triggers the call to /usr/share/ltsp/update-kernels.

To post a comment you must log in.
Revision history for this message
Richard Kweskin (rkwesk-ltsp) wrote :

I apologize in advance for not processing this in the correct way. If the process for submitting documentation is different I am ready to learn. :))

I have also prepared a piece on hardware for ltsp (using Alkis Georgopoulos as the source) but am confused because I see a different place where another guide has been submitted (https://wiki.debian.org/DebianEdu/Documentation/Stretch/HowTo/NetworkClients?highlight=%28ltsp%29) which in my estimation needs editing and an unmerged document (http://bazaar.launchpad.net/~ltsp-docwriters/ltsp/ltsp-docs-trunk/view/head:/LTSPManual.xml) which I assume is not to be touched.

Any suggestions are welcome.

Richard

Revision history for this message
Alkis Georgopoulos (alkisg) wrote :

I'm setting the state of old merge requests that have been stale for years, to rejected; if someone wants, he can do another merge request in git format, since now ltsp uses git.

review: Disapprove

Unmerged revisions

163. By Vagrant Cascadian

Upload ltsp-docs 1.2-1 to unstable.

162. By Vagrant Cascadian

Update version to 1.2.

161. By Vagrant Cascadian

debian/copyright: Updated and switched to copyright-format 1.0.

160. By Vagrant Cascadian

debian/control: Updated Standards-Version to 3.9.6, some changes
needed.

159. By Vagrant Cascadian

debian/control: Remove obsoleted DM-Upload-Allowed field.

158. By Vagrant Cascadian

Update to debhelper 9.

157. By Vagrant Cascadian

debian/control: Document Vcs-Browser and Vcs-Bzr fields.

156. By Vagrant Cascadian

Fix spelling error ressources -> resources.

155. By Vagrant Cascadian

LDM_PASSWORD_HASH: document versions of ldm/ltsp which contain this feature.

154. By Vagrant Cascadian

update LDM_PASSWORD_HASH description to mention sudo rather than software installation.

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1=== added file '.bzrignore'
2--- .bzrignore 1970-01-01 00:00:00 +0000
3+++ .bzrignore 2017-02-24 11:47:08 +0000
4@@ -0,0 +1,8 @@
5+Makefile
6+autom4te.cache
7+config.log
8+config.status
9+LTSPManual.html
10+LTSPManual.pdf
11+LTSPManual.txt
12+lts.conf.5
13
14=== renamed file '.bzrignore' => '.bzrignore.moved'
15=== added file 'AUTHORS'
16--- AUTHORS 1970-01-01 00:00:00 +0000
17+++ AUTHORS 2017-02-24 11:47:08 +0000
18@@ -0,0 +1,17 @@
19+Scott Balneaves
20+Jordan Erickson
21+Francis Giraldeau
22+Richard Johnson
23+David Johnston
24+Chuck Liebow
25+James McQuillan
26+Jonathan Mueller
27+Gideon Romm
28+Joel Sass
29+Robin Shepheard
30+Susan Stewart
31+Brian Tilma
32+David Van Assche
33+Carol Wiebe
34+Vagrant Cascadian
35+Alkis Georgopoulos
36
37=== added file 'COPYING'
38--- COPYING 1970-01-01 00:00:00 +0000
39+++ COPYING 2017-02-24 11:47:08 +0000
40@@ -0,0 +1,339 @@
41+ GNU GENERAL PUBLIC LICENSE
42+ Version 2, June 1991
43+
44+ Copyright (C) 1989, 1991 Free Software Foundation, Inc.,
45+ 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
46+ Everyone is permitted to copy and distribute verbatim copies
47+ of this license document, but changing it is not allowed.
48+
49+ Preamble
50+
51+ The licenses for most software are designed to take away your
52+freedom to share and change it. By contrast, the GNU General Public
53+License is intended to guarantee your freedom to share and change free
54+software--to make sure the software is free for all its users. This
55+General Public License applies to most of the Free Software
56+Foundation's software and to any other program whose authors commit to
57+using it. (Some other Free Software Foundation software is covered by
58+the GNU Lesser General Public License instead.) You can apply it to
59+your programs, too.
60+
61+ When we speak of free software, we are referring to freedom, not
62+price. Our General Public Licenses are designed to make sure that you
63+have the freedom to distribute copies of free software (and charge for
64+this service if you wish), that you receive source code or can get it
65+if you want it, that you can change the software or use pieces of it
66+in new free programs; and that you know you can do these things.
67+
68+ To protect your rights, we need to make restrictions that forbid
69+anyone to deny you these rights or to ask you to surrender the rights.
70+These restrictions translate to certain responsibilities for you if you
71+distribute copies of the software, or if you modify it.
72+
73+ For example, if you distribute copies of such a program, whether
74+gratis or for a fee, you must give the recipients all the rights that
75+you have. You must make sure that they, too, receive or can get the
76+source code. And you must show them these terms so they know their
77+rights.
78+
79+ We protect your rights with two steps: (1) copyright the software, and
80+(2) offer you this license which gives you legal permission to copy,
81+distribute and/or modify the software.
82+
83+ Also, for each author's protection and ours, we want to make certain
84+that everyone understands that there is no warranty for this free
85+software. If the software is modified by someone else and passed on, we
86+want its recipients to know that what they have is not the original, so
87+that any problems introduced by others will not reflect on the original
88+authors' reputations.
89+
90+ Finally, any free program is threatened constantly by software
91+patents. We wish to avoid the danger that redistributors of a free
92+program will individually obtain patent licenses, in effect making the
93+program proprietary. To prevent this, we have made it clear that any
94+patent must be licensed for everyone's free use or not licensed at all.
95+
96+ The precise terms and conditions for copying, distribution and
97+modification follow.
98+
99+ GNU GENERAL PUBLIC LICENSE
100+ TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
101+
102+ 0. This License applies to any program or other work which contains
103+a notice placed by the copyright holder saying it may be distributed
104+under the terms of this General Public License. The "Program", below,
105+refers to any such program or work, and a "work based on the Program"
106+means either the Program or any derivative work under copyright law:
107+that is to say, a work containing the Program or a portion of it,
108+either verbatim or with modifications and/or translated into another
109+language. (Hereinafter, translation is included without limitation in
110+the term "modification".) Each licensee is addressed as "you".
111+
112+Activities other than copying, distribution and modification are not
113+covered by this License; they are outside its scope. The act of
114+running the Program is not restricted, and the output from the Program
115+is covered only if its contents constitute a work based on the
116+Program (independent of having been made by running the Program).
117+Whether that is true depends on what the Program does.
118+
119+ 1. You may copy and distribute verbatim copies of the Program's
120+source code as you receive it, in any medium, provided that you
121+conspicuously and appropriately publish on each copy an appropriate
122+copyright notice and disclaimer of warranty; keep intact all the
123+notices that refer to this License and to the absence of any warranty;
124+and give any other recipients of the Program a copy of this License
125+along with the Program.
126+
127+You may charge a fee for the physical act of transferring a copy, and
128+you may at your option offer warranty protection in exchange for a fee.
129+
130+ 2. You may modify your copy or copies of the Program or any portion
131+of it, thus forming a work based on the Program, and copy and
132+distribute such modifications or work under the terms of Section 1
133+above, provided that you also meet all of these conditions:
134+
135+ a) You must cause the modified files to carry prominent notices
136+ stating that you changed the files and the date of any change.
137+
138+ b) You must cause any work that you distribute or publish, that in
139+ whole or in part contains or is derived from the Program or any
140+ part thereof, to be licensed as a whole at no charge to all third
141+ parties under the terms of this License.
142+
143+ c) If the modified program normally reads commands interactively
144+ when run, you must cause it, when started running for such
145+ interactive use in the most ordinary way, to print or display an
146+ announcement including an appropriate copyright notice and a
147+ notice that there is no warranty (or else, saying that you provide
148+ a warranty) and that users may redistribute the program under
149+ these conditions, and telling the user how to view a copy of this
150+ License. (Exception: if the Program itself is interactive but
151+ does not normally print such an announcement, your work based on
152+ the Program is not required to print an announcement.)
153+
154+These requirements apply to the modified work as a whole. If
155+identifiable sections of that work are not derived from the Program,
156+and can be reasonably considered independent and separate works in
157+themselves, then this License, and its terms, do not apply to those
158+sections when you distribute them as separate works. But when you
159+distribute the same sections as part of a whole which is a work based
160+on the Program, the distribution of the whole must be on the terms of
161+this License, whose permissions for other licensees extend to the
162+entire whole, and thus to each and every part regardless of who wrote it.
163+
164+Thus, it is not the intent of this section to claim rights or contest
165+your rights to work written entirely by you; rather, the intent is to
166+exercise the right to control the distribution of derivative or
167+collective works based on the Program.
168+
169+In addition, mere aggregation of another work not based on the Program
170+with the Program (or with a work based on the Program) on a volume of
171+a storage or distribution medium does not bring the other work under
172+the scope of this License.
173+
174+ 3. You may copy and distribute the Program (or a work based on it,
175+under Section 2) in object code or executable form under the terms of
176+Sections 1 and 2 above provided that you also do one of the following:
177+
178+ a) Accompany it with the complete corresponding machine-readable
179+ source code, which must be distributed under the terms of Sections
180+ 1 and 2 above on a medium customarily used for software interchange; or,
181+
182+ b) Accompany it with a written offer, valid for at least three
183+ years, to give any third party, for a charge no more than your
184+ cost of physically performing source distribution, a complete
185+ machine-readable copy of the corresponding source code, to be
186+ distributed under the terms of Sections 1 and 2 above on a medium
187+ customarily used for software interchange; or,
188+
189+ c) Accompany it with the information you received as to the offer
190+ to distribute corresponding source code. (This alternative is
191+ allowed only for noncommercial distribution and only if you
192+ received the program in object code or executable form with such
193+ an offer, in accord with Subsection b above.)
194+
195+The source code for a work means the preferred form of the work for
196+making modifications to it. For an executable work, complete source
197+code means all the source code for all modules it contains, plus any
198+associated interface definition files, plus the scripts used to
199+control compilation and installation of the executable. However, as a
200+special exception, the source code distributed need not include
201+anything that is normally distributed (in either source or binary
202+form) with the major components (compiler, kernel, and so on) of the
203+operating system on which the executable runs, unless that component
204+itself accompanies the executable.
205+
206+If distribution of executable or object code is made by offering
207+access to copy from a designated place, then offering equivalent
208+access to copy the source code from the same place counts as
209+distribution of the source code, even though third parties are not
210+compelled to copy the source along with the object code.
211+
212+ 4. You may not copy, modify, sublicense, or distribute the Program
213+except as expressly provided under this License. Any attempt
214+otherwise to copy, modify, sublicense or distribute the Program is
215+void, and will automatically terminate your rights under this License.
216+However, parties who have received copies, or rights, from you under
217+this License will not have their licenses terminated so long as such
218+parties remain in full compliance.
219+
220+ 5. You are not required to accept this License, since you have not
221+signed it. However, nothing else grants you permission to modify or
222+distribute the Program or its derivative works. These actions are
223+prohibited by law if you do not accept this License. Therefore, by
224+modifying or distributing the Program (or any work based on the
225+Program), you indicate your acceptance of this License to do so, and
226+all its terms and conditions for copying, distributing or modifying
227+the Program or works based on it.
228+
229+ 6. Each time you redistribute the Program (or any work based on the
230+Program), the recipient automatically receives a license from the
231+original licensor to copy, distribute or modify the Program subject to
232+these terms and conditions. You may not impose any further
233+restrictions on the recipients' exercise of the rights granted herein.
234+You are not responsible for enforcing compliance by third parties to
235+this License.
236+
237+ 7. If, as a consequence of a court judgment or allegation of patent
238+infringement or for any other reason (not limited to patent issues),
239+conditions are imposed on you (whether by court order, agreement or
240+otherwise) that contradict the conditions of this License, they do not
241+excuse you from the conditions of this License. If you cannot
242+distribute so as to satisfy simultaneously your obligations under this
243+License and any other pertinent obligations, then as a consequence you
244+may not distribute the Program at all. For example, if a patent
245+license would not permit royalty-free redistribution of the Program by
246+all those who receive copies directly or indirectly through you, then
247+the only way you could satisfy both it and this License would be to
248+refrain entirely from distribution of the Program.
249+
250+If any portion of this section is held invalid or unenforceable under
251+any particular circumstance, the balance of the section is intended to
252+apply and the section as a whole is intended to apply in other
253+circumstances.
254+
255+It is not the purpose of this section to induce you to infringe any
256+patents or other property right claims or to contest validity of any
257+such claims; this section has the sole purpose of protecting the
258+integrity of the free software distribution system, which is
259+implemented by public license practices. Many people have made
260+generous contributions to the wide range of software distributed
261+through that system in reliance on consistent application of that
262+system; it is up to the author/donor to decide if he or she is willing
263+to distribute software through any other system and a licensee cannot
264+impose that choice.
265+
266+This section is intended to make thoroughly clear what is believed to
267+be a consequence of the rest of this License.
268+
269+ 8. If the distribution and/or use of the Program is restricted in
270+certain countries either by patents or by copyrighted interfaces, the
271+original copyright holder who places the Program under this License
272+may add an explicit geographical distribution limitation excluding
273+those countries, so that distribution is permitted only in or among
274+countries not thus excluded. In such case, this License incorporates
275+the limitation as if written in the body of this License.
276+
277+ 9. The Free Software Foundation may publish revised and/or new versions
278+of the General Public License from time to time. Such new versions will
279+be similar in spirit to the present version, but may differ in detail to
280+address new problems or concerns.
281+
282+Each version is given a distinguishing version number. If the Program
283+specifies a version number of this License which applies to it and "any
284+later version", you have the option of following the terms and conditions
285+either of that version or of any later version published by the Free
286+Software Foundation. If the Program does not specify a version number of
287+this License, you may choose any version ever published by the Free Software
288+Foundation.
289+
290+ 10. If you wish to incorporate parts of the Program into other free
291+programs whose distribution conditions are different, write to the author
292+to ask for permission. For software which is copyrighted by the Free
293+Software Foundation, write to the Free Software Foundation; we sometimes
294+make exceptions for this. Our decision will be guided by the two goals
295+of preserving the free status of all derivatives of our free software and
296+of promoting the sharing and reuse of software generally.
297+
298+ NO WARRANTY
299+
300+ 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
301+FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
302+OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
303+PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
304+OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
305+MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
306+TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
307+PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
308+REPAIR OR CORRECTION.
309+
310+ 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
311+WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
312+REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
313+INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
314+OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
315+TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
316+YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
317+PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
318+POSSIBILITY OF SUCH DAMAGES.
319+
320+ END OF TERMS AND CONDITIONS
321+
322+ How to Apply These Terms to Your New Programs
323+
324+ If you develop a new program, and you want it to be of the greatest
325+possible use to the public, the best way to achieve this is to make it
326+free software which everyone can redistribute and change under these terms.
327+
328+ To do so, attach the following notices to the program. It is safest
329+to attach them to the start of each source file to most effectively
330+convey the exclusion of warranty; and each file should have at least
331+the "copyright" line and a pointer to where the full notice is found.
332+
333+ <one line to give the program's name and a brief idea of what it does.>
334+ Copyright (C) <year> <name of author>
335+
336+ This program is free software; you can redistribute it and/or modify
337+ it under the terms of the GNU General Public License as published by
338+ the Free Software Foundation; either version 2 of the License, or
339+ (at your option) any later version.
340+
341+ This program is distributed in the hope that it will be useful,
342+ but WITHOUT ANY WARRANTY; without even the implied warranty of
343+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
344+ GNU General Public License for more details.
345+
346+ You should have received a copy of the GNU General Public License along
347+ with this program; if not, write to the Free Software Foundation, Inc.,
348+ 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
349+
350+Also add information on how to contact you by electronic and paper mail.
351+
352+If the program is interactive, make it output a short notice like this
353+when it starts in an interactive mode:
354+
355+ Gnomovision version 69, Copyright (C) year name of author
356+ Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
357+ This is free software, and you are welcome to redistribute it
358+ under certain conditions; type `show c' for details.
359+
360+The hypothetical commands `show w' and `show c' should show the appropriate
361+parts of the General Public License. Of course, the commands you use may
362+be called something other than `show w' and `show c'; they could even be
363+mouse-clicks or menu items--whatever suits your program.
364+
365+You should also get your employer (if you work as a programmer) or your
366+school, if any, to sign a "copyright disclaimer" for the program, if
367+necessary. Here is a sample; alter the names:
368+
369+ Yoyodyne, Inc., hereby disclaims all copyright interest in the program
370+ `Gnomovision' (which makes passes at compilers) written by James Hacker.
371+
372+ <signature of Ty Coon>, 1 April 1989
373+ Ty Coon, President of Vice
374+
375+This General Public License does not permit incorporating your program into
376+proprietary programs. If your program is a subroutine library, you may
377+consider it more useful to permit linking proprietary applications with the
378+library. If this is what you want to do, use the GNU Lesser General
379+Public License instead of this License.
380
381=== renamed file 'COPYING' => 'COPYING.moved'
382=== added file 'LTSPManual-C.omf'
383--- LTSPManual-C.omf 1970-01-01 00:00:00 +0000
384+++ LTSPManual-C.omf 2017-02-24 11:47:08 +0000
385@@ -0,0 +1,18 @@
386+<?xml version="1.0" encoding="UTF-8"?>
387+<!DOCTYPE omf PUBLIC "-//OMF//DTD Scrollkeeper OMF Variant V1.0"
388+ "http://scrollkeeper.sourceforge.net/dtds/scrollkeeper-omf-1.0/scrollkeeper-omf.dtd">
389+<omf>
390+ <resource>
391+ <creator>ltsp-developer@lists.sourceforge.net (LTSP Doc Writers)</creator>
392+ <maintainer>ltsp-developer@lists.sourceforge.net (LTSP Doc Writers)</maintainer>
393+ <title>Linux Terminal Server Project Administrator's Reference</title>
394+ <date>2008-11-18</date>
395+ <subject category="System|Administration"/>
396+ <description>Linux Terminal Server Project Administrator's Reference.</description>
397+ <format mime="text/xml" dtd="-//OASIS//DTD DocBook XML V4.1.2//EN"/>
398+ <identifier url="file:///usr/share/gnome/help/ltsp/C/LTSPManual.xml"/>
399+ <language code="C"/>
400+ <relation seriesid="03c4cb81-ee92-8741-c9ba-b2317b03f6d220"/>
401+ <rights type="GPL" license.version="2.0" holder="Scott Balneaves and other authors"/>
402+ </resource>
403+</omf>
404
405=== added file 'LTSPManual.xml'
406--- LTSPManual.xml 1970-01-01 00:00:00 +0000
407+++ LTSPManual.xml 2017-02-24 11:47:08 +0000
408@@ -0,0 +1,3113 @@
409+<?xml version="1.0" encoding="UTF-8"?>
410+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
411+"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd"
412+[
413+<!ENTITY ldm "<command>ldm</command>ldm;">
414+<!ENTITY ltspfs "<command>ltspfs</command>">
415+<!ENTITY rdesktop "<command>rdesktop</command>">
416+<!ENTITY lts.conf "<filename>lts.conf</filename>">
417+]>
418+<book>
419+ <title>Linux Terminal Server Project Administrator's Reference</title>
420+ <subtitle>
421+ A Guide to LTSP Networks
422+ </subtitle>
423+ <bookinfo>
424+ <title>Linux Terminal Server Project Administrator's Reference</title>
425+ <authorgroup>
426+ <author><firstname>Scott</firstname><surname>Balneaves</surname></author>
427+ <author><firstname>Jordan</firstname><surname>Erickson</surname></author>
428+ <author><firstname>Francis</firstname><surname>Giraldeau</surname></author>
429+ <author><firstname>Richard</firstname><surname>Johnson</surname></author>
430+ <author><firstname>David</firstname><surname>Johnston</surname></author>
431+ <author><firstname>Chuck</firstname><surname>Liebow</surname></author>
432+ <author><firstname>James</firstname><surname>McQuillan</surname></author>
433+ <author><firstname>Jonathan</firstname><surname>Mueller</surname></author>
434+ <author><firstname>Gideon</firstname><surname>Romm</surname></author>
435+ <author><firstname>Joel</firstname><surname>Sass</surname></author>
436+ <author><firstname>Robin</firstname><surname>Shepheard</surname></author>
437+ <author><firstname>Susan</firstname><surname>Stewart</surname></author>
438+ <author><firstname>Brian</firstname><surname>Tilma</surname></author>
439+ <author><firstname>David</firstname><surname>Van Assche</surname></author>
440+ <author><firstname>Carol</firstname><surname>Wiebe</surname></author>
441+ <author><firstname>Vagrant</firstname><surname>Cascadian</surname></author>
442+ </authorgroup>
443+ <date>Aug, 2015</date>
444+ <edition>1.2</edition>
445+ <pubdate>Aug 2015</pubdate>
446+ <copyright>
447+ <year>2008</year>
448+ <year>2015</year>
449+ <holder>Scott Balneaves and other authors</holder>
450+ </copyright>
451+ <legalnotice>
452+ <para>
453+ Permission to use, copy, modify and distribute
454+ the software and its accompanying documentation for any
455+ purpose and without fee is hereby granted in perpetuity under
456+ the terms of the GNU GPL2,
457+ provided that a copy of the GNU GPL2 appears
458+ with it.
459+ </para>
460+ </legalnotice>
461+ <legalnotice>
462+ <para>
463+ The copyright holder makes no representation about the
464+ suitability of this software for any purpose. It is provided
465+ <quote>as is</quote> without expressed or implied
466+ warranty. If you modify the software in any way, identify your
467+ software as a variant of LTSP.
468+ </para>
469+ </legalnotice>
470+ </bookinfo>
471+ <chapter id='intro'>
472+ <title>Linux Terminal Server Project - LTSP</title>
473+ <sect1>
474+ <title>Introduction to LTSP and Thin Client Computing</title>
475+ <para>
476+ One of the key technologies included in modern GNU/Linux
477+ operating systems is the Linux Terminal Server Project (LTSP)
478+ which allows you to boot thin clients from an LTSP server. For
479+ educational environments, LTSP lowers hardware costs by
480+ enabling the use of older or less powerful machines as thin
481+ clients, as well as reduced administration overhead by having
482+ only to install and maintain the software on the server. When
483+ a workstation fails, it can simply be replaced without data
484+ loss or re-installation of the operating system.
485+ </para>
486+ <para>
487+ Thin client computing has been around for a long time in the
488+ UNIX world. Although the implementation has evolved quite a
489+ bit, the concept has remained the same:
490+ </para>
491+ <orderedlist>
492+ <listitem>
493+ <para>
494+ The thin client only takes care of the basic
495+ functions like display, keyboard, mouse and sound.
496+ </para>
497+ </listitem>
498+ <listitem>
499+ <para>
500+ The server does the heavy weightlifting. All the
501+ applications run on the server, and they simply
502+ display on the thin client.
503+ </para>
504+ </listitem>
505+ </orderedlist>
506+ <para>
507+ Because the thin clients have a limited number of tasks to
508+ manage, the hardware for the thin client can be small and
509+ cheap. The thin clients themselves are basically maintenance
510+ free. They last longer because they have no storage with
511+ moving parts like hard disks. If they break no data is lost
512+ since nothing is stored on the client itself. Simply swap the
513+ client with another one and go back to work. If your thin
514+ client is stolen or put in the trash, no data ends up in the
515+ hands of unauthorized people.
516+ </para>
517+ <para>
518+ The terminal server runs all applications and contains all
519+ the data. All the regular maintenance (software updates,
520+ administration) takes place on the terminal server. The number
521+ of thin clients that a terminal server can support is
522+ proportional to the power of the server. Because GNU/Linux
523+ makes efficient use of resources, you can support a surprising
524+ number of thin clients from a machine which might only be
525+ considered a powerful single user system running other
526+ operating systems. Please see for more details.
527+ </para>
528+ <para>
529+ In a thin client computing environment, the stability of the
530+ server is important. It's important to make sure that your
531+ server has good power fallback facilities, like installing a
532+ UPS, and depending on how much availability is required,
533+ redundant power supplies may be called for. As well, users who
534+ have the resources may decide to invest in multiple disks for
535+ RAID support, and other options which may be needed in a High
536+ Availability environment. However, you certainly don't need
537+ them in all environments, and GNU/Linux's high quality means
538+ that in all but the most demanding environments, this won't be
539+ needed.
540+ </para>
541+ </sect1>
542+ <sect1>
543+ <title>LTSP Security</title>
544+ <para>
545+ Security has become a key challenge for administrators and
546+ LTSP both recognizes and handles this quite well. Often
547+ schools lack the specialized IT staff or time to lock and
548+ clean up computers.
549+ </para>
550+ <para>
551+ Operating systems with LTSP included, being Linux-based
552+ operating systems, enjoy the security advantages of its
553+ Unix-like and open source heritages. This translates into
554+ higher quality code and no spyware and viruses, like they
555+ plague other operating systems.
556+ </para>
557+ <para>
558+ In addition, it has a strict, proactive security policy
559+ which means that many common problems, such as open ports or
560+ misconfigured software, never make it into the released
561+ product. Finally, LTSP based systems are true multi-user
562+ operating systems, making it easy to allow users to complete
563+ their tasks without having a level of access that could
564+ compromise the system.
565+ </para>
566+ </sect1>
567+ <sect1>
568+ <title>LTSP Manageability</title>
569+ <para>
570+ With administrators and especially school IT departments
571+ deploying and administering an increasing number of computers,
572+ it is difficult to find time to manage individual machines.
573+ LTSP thin client technology, makes deployment and management
574+ simple and easy. A single server is all that is needed to set
575+ up, manage and administrate an entire network It is recognized
576+ that not every school's setup is the same, so LTSP (and the
577+ underlying operating system) has been made to easily customize
578+ your unique needs.
579+ </para>
580+ </sect1>
581+ <sect1>
582+ <title>It's Green!</title>
583+ <para>
584+ With the ongoing debate about climate change, questions are
585+ finally being asked and answered in the fields of IT,
586+ education and thin client technology in general. A recent
587+ study compared the energy and resource consumption of a
588+ regular PC and Thin Client setups. You can find that study
589+ here: <ulink url="http://it.umsicht.fraunhofer.de/TCecology/index_en.html">
590+ http://it.umsicht.fraunhofer.de/TCecology/index_en.html
591+ </ulink>
592+ </para>
593+ <para>
594+ They found that thin clients use half the energy of
595+ traditional workstations, which not only helps on the cost
596+ savings (calculate that a 40 terminal thin client lab will
597+ save approximately $500-$800 per year), but is ecologically
598+ effective in avoiding electronic waste and high carbon
599+ emissions. Thin client production, assembly and logistics
600+ costs far less and requires less energy than traditional PC
601+ manufacturing. The recycling of old machinery also helps the
602+ environment, making LTSP a green solution to the environmental
603+ and power saving issues many IT managers face today.
604+ </para>
605+ </sect1>
606+ <sect1>
607+ <title>Cost Effective </title>
608+ <para>
609+ With ever-increasing demands on school budgets, expensive
610+ technology is often last on the list. LTSP can help you offer
611+ what your students increasingly require from computer
612+ technology, without breaking the bank. GNU/Linux is and always
613+ will be free to acquire, use and modify, including the
614+ underlying LTSP structure that holds it all together.
615+ </para>
616+ <para>
617+ Need to set up another machine? Or another 100? Just install
618+ them! With GNU/Linux you'll have no more expensive OS upgrades
619+ and licenses, and having specialized programs on only some
620+ computers will become a thing of the past. When you build your
621+ network on Open Source software, you are freed to seek support
622+ for your computers from whomever you wish.
623+ </para>
624+ <para>
625+ GNU/Linux with LTSP can also help you save hardware costs, by
626+ allowing you to redeploy older machines as thin clients using
627+ LTSP technology. Whether you choose to set up many smaller
628+ labs with various LTSP servers or one giant setup with a load
629+ balanced LTSP setup (various servers working together to
630+ manage the users and applications logging on) the cost savings
631+ are always enormous.
632+ </para>
633+ </sect1>
634+ <sect1>
635+ <title>Well Supported</title>
636+ <para>
637+ LTSP support is available from the LTSP community. Many
638+ of the authors of the software included in LTSP, including the
639+ respective developers of the various LTSP GNU/Linux
640+ distribution implementations themselves, can be contacted
641+ directly via mailing lists and IRC channels.
642+ </para>
643+ <para>
644+ There are many forms of support available, including mailing
645+ lists, Wiki websites, IRC channels, and bug trackers. There
646+ are also special support groups for using LTSP and GNU/Linux.
647+ </para>
648+ <para>
649+ The official IRC support channel is found on freenode.org at
650+ #ltsp
651+ </para>
652+ <para>
653+ The official LTSP mailing list is found here:</para>
654+ <para>
655+ <ulink url="https://lists.sourceforge.net/lists/listinfo/ltsp-discuss">
656+ https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
657+ </ulink>
658+ </para>
659+ <para>
660+ In fact, some of the money that would have gone to
661+ purchasing software can instead be spent to hire local experts
662+ to help train you, and to help you support your network. LTSP
663+ can help you take more control over your network while also
664+ benefiting your local economy. With LTSP based systems, these
665+ choices are yours.
666+ </para>
667+ </sect1>
668+ <sect1>
669+ <title>Built for Education, Government and business</title>
670+ <para>
671+ LTSP based distros come with translations for many languages
672+ and localization features that allow people from all over the
673+ world to enjoy their computing experience. Accessibility
674+ features strive to provide a pleasant, high-quality computing
675+ experience to disabled users.
676+ </para>
677+ <para>
678+ The Free nature of GNU/Linux means that the applications a user
679+ is used to at their school or workplace is also available to
680+ them at home. Users can install their favorite
681+ GNU/Linux distribution at home, and have all the same
682+ functionality they are used to. In fact, many GNU/Linux
683+ distributions have Live CD's, which allow users to try, or even
684+ fully use the distribution at home, without even installing it
685+ on their home machine.
686+ </para>
687+ <para>
688+ The LTSP server software allows administrators, IT managers
689+ and teachers to create a low cost computer lab so that users
690+ can have access to the opportunities that GNU/Linux and the
691+ Internet can provide.
692+ </para>
693+ <para>
694+ Since setups can be adjusted to many situations, each thin
695+ client lab can be uniquely tailored to fit the business,
696+ agency or educational facility in question.
697+ </para>
698+ </sect1>
699+ </chapter>
700+ <chapter id='basic-concepts'>
701+ <title>Basic Concepts: Networks and Networking </title>
702+ <para>
703+ There are two components of a network: hardware and software.
704+ This section will give an introduction to both.
705+ </para>
706+ <sect1>
707+ <title>Hardware </title>
708+ <para>
709+ Networking works by breaking files and other data into
710+ little packets of information. These packets are transferred
711+ over a network. The difference between various types of
712+ networks is how they transfer packets.
713+ </para>
714+ <para>
715+ There are two types of networking hardware: wired and
716+ wireless.
717+ </para>
718+ <para>
719+ An important fact to remember is that a network will be only
720+ as fast as the slowest part. Making sure that your network
721+ setup matches your intended use case is an important
722+ consideration in an LTSP network.
723+ </para>
724+ <sect2>
725+ <title>Wired</title>
726+ <para>
727+ Wired networking transfers packets over a cable that
728+ resembles a telephone cord, but with more wires. Wired
729+ networks can transfer packets at one of three possible
730+ speeds: 10 Mbit/sec, 100 Mbit/sec, or (Gigabit) 1000
731+ Mbit/sec.
732+ </para>
733+ <para>
734+ A network is only useful if it can connect multiple
735+ computers. There are some pieces of hardware that allow
736+ multiple computers to be connected in a network. They look
737+ alike, but they function differently and, likewise,
738+ operate at different speeds.
739+ </para>
740+ <para><emphasis>Hub</emphasis></para>
741+ <para>
742+ A hub is the simplest way to connect multiple computers.
743+ A hub has a lot of ports in the front and usually has
744+ several small lights corresponding to each port. The hub
745+ takes a message it receives on one port and re-sends it to
746+ all the ports. As a result, only one port can talk at a
747+ time.
748+ </para>
749+ <para><emphasis>Switch</emphasis></para>
750+ <para>
751+ A switch looks a lot like a hub; it has a lot of ports
752+ in the front and usually has several small lights
753+ corresponding to each port. However, a switch is unlike a
754+ hub because it only makes a connection between the ports
755+ it needs to. A switch can have multiple connections at the
756+ same time. This allows a switch to be faster than a hub.
757+ </para>
758+ <para><emphasis>Router</emphasis></para>
759+ <para>
760+ A router is used to make a connection between two
761+ networks. Routers are also commonly used to connect a LAN
762+ (local area network) to the Internet.
763+ </para>
764+ </sect2>
765+ <sect2>
766+ <title>Wireless</title>
767+ <para>
768+ Some people may wish to try using LTSP in a wireless
769+ environment, for various reasons. This represents some
770+ challenges.
771+ </para>
772+ <para>
773+ Wireless networks typically have more latency than wired
774+ networks, which generally makes interactive programs feel
775+ slow and unresponsive. As well, wireless adaptors cannot
776+ directly PXE boot, as you need to set things such as ESSID,
777+ keys, etc., which wouldn't be there in a PXE capable card.
778+ </para>
779+ <para>
780+ However, for those wishing to use LTSP wirelessly, it is
781+ still possible, but requires more hardware. Wireless
782+ bridge boxes are available, which contain both an ethernet
783+ and a wireless network connection. One can typically
784+ connect to them like a small Internet router box, and
785+ program them with the information pertinent to your
786+ network. You can then use a standard wired network card
787+ connected directly to the bridge, and the bridge itself
788+ will handle the wireless part.
789+ </para>
790+ <para>
791+ This method has been used with success by users of LTSP in
792+ the past. The latency of wireless makes the experience
793+ slower, however, depending on the application you wish to
794+ use, you may find it acceptible.
795+ </para>
796+ </sect2>
797+ </sect1>
798+ <sect1>
799+ <title>Software</title>
800+ <para>
801+ The most common network infrastructure services include:
802+ </para>
803+ <itemizedlist>
804+ <listitem>
805+ <para>
806+ DHCP (Dynamic Host Configuration Protocol)</para>
807+ <para>
808+ Each computer on a network needs a unique identifier
809+ called an IP address. The IP address allows packets to be
810+ directed to the computer, much like a street address
811+ allows mail to be delivered to the correct house. An IP
812+ address follows a specific form: four groups of digits
813+ forming a number from 0 to 255. For example, a local IP
814+ address might be 192.168.2.50.
815+ </para>
816+ <para>
817+ For convenience, a computer's IP address can be given
818+ by a server running the Dynamic Host Configuration
819+ Protocol (DHCP) service. DHCP automatically provides
820+ network settings to the computers on the network. With
821+ DHCP, there is no need to keep track of each computer's
822+ IP address.
823+ </para>
824+ </listitem>
825+ <listitem>
826+ <para>
827+ DNS (Domain Name System)</para>
828+ <para>
829+ DNS is a service that runs on a server, and it is like a
830+ phone book for computers, except that it stores IP
831+ addresses instead of phone numbers. Your computer talks
832+ to a DNS server every time you refer to another computer
833+ system with a name instead of an IP address. For example:
834+ www.ltsp.org, wikipedia.org, and google.com are all DNS
835+ hostnames.
836+ </para>
837+ </listitem>
838+ <listitem>
839+ <para>
840+ NTP (Network Time Protocol)
841+ </para>
842+ <para>
843+ NTP is a service that runs on a server and allows other
844+ computers to synchronize their clocks. The server
845+ synchronizes with an extremely accurate atomic clock, and
846+ then the clients synchronize with the server.
847+ </para>
848+ </listitem>
849+ <listitem>
850+ <para>
851+ Web Server
852+ </para>
853+ <para>
854+ A Web server answers queries using protocols such as
855+ HTTP, and sends content such as web pages back to clients.
856+ Your Web browser almost exclusively talks to Web servers.
857+ </para>
858+ </listitem>
859+ <listitem>
860+ <para>
861+ Web Proxy
862+ </para>
863+ <para>
864+ A Web proxy is a service that runs on a server and
865+ accesses Web sites on behalf of the clients. A proxy can
866+ cache some data to allow faster repeated access to
867+ commonly accessed pages. This is not really needed in
868+ essence for ltsp thin clients, since nothing runs on them,
869+ it all runs on the server. But in order to allow for
870+ content filtering, a proxy is required. In the case of a
871+ mixed network, where some clients are independent from the
872+ the thin client network, a proxy server is useful. The
873+ most common and recommended proxy solution is called
874+ Squid, which can be easily installed through your distro's
875+ package manager.
876+ </para>
877+ </listitem>
878+ <listitem>
879+ <para>
880+ Content Filter or Net Guardian
881+ </para>
882+ <para>
883+ A typical network requires a filtering policy to be
884+ implemented, which can easily be done by software like
885+ dansguardian, squidguard or squid-filter. This allows an
886+ administrator to block and control unwanted traffic like:
887+ </para>
888+ <orderedlist>
889+ <listitem>
890+ <para>
891+ banner ads,
892+ </para>
893+ </listitem>
894+ <listitem>
895+ <para>
896+ user behaviour tracking via cookies,
897+ </para>
898+ </listitem>
899+ <listitem>
900+ <para>
901+ animated pictures,
902+ </para>
903+ </listitem>
904+ <listitem>
905+ <para>
906+ JavaScript, VBScript, ActiveX (dangerous as well
907+ as annoying).
908+ </para>
909+ </listitem>
910+ </orderedlist>
911+ </listitem>
912+ <listitem>
913+ <para>
914+ Firewall &amp; Port Blocker
915+ </para>
916+ <para>
917+ A firewall is usually a service on the server, but often
918+ DSL routers have the basic functionality of a firewall
919+ too. A firewall can protect your server (and clients) by
920+ restricting or allowing computers on the Internet from
921+ initiating connections into your server or network. There
922+ are many programs available for different distros. On
923+ Ubuntu and Debian we recommend using gufw (uncomplicated
924+ firewall), while Fedora has Fedora Firewall GUI, and SuSE
925+ has Yast2 Firewall. If they are not already installed, you
926+ can simply install them with your distro's package manager
927+ </para>
928+ </listitem>
929+ </itemizedlist>
930+ </sect1>
931+ <sect1>
932+ <title>How LTSP Works</title>
933+ <orderedlist>
934+ <listitem>
935+ <para>
936+ LTSP is a collection of software that turns a normal
937+ GNU/Linux installation into a terminal server. This allows
938+ low-powered, low-cost thin-clients (or legacy hardware
939+ you already own) to be used as terminals to the
940+ thin-client server. LTSP is unique from other
941+ thin-client systems in that it is considered by many
942+ as the easiest to maintain. Other thin-client systems
943+ require each client to have software that boots the
944+ system to a point to be able to connect to the
945+ terminal server. This could be a full-blown operating
946+ system, or a minimal OS that simply provides an
947+ interface to connect to the server. Systems such as
948+ this generally require more maintenance and
949+ administration, as the local software that boots the
950+ thin-clients may become corrupt or contain bugs that
951+ require attention. LTSP, on the other hand, requires
952+ no client-side software. It requires only a PXE
953+ capable network interface, which many thin-clients and
954+ PCs have built-in already. This means that you need
955+ absolutely no physical storage media (hard disk,
956+ compact-flash, etc.) for your thin-client to boot to
957+ LTSP. This significantly reduces the amount of
958+ administration required to keep your network running.
959+ The process of booting a thin-client to an LTSP server
960+ is as follows:
961+ </para>
962+ </listitem>
963+ <listitem>
964+ <para>
965+ Thin-clients boot via a protocol called PXE
966+ (Pre-eXecution Environment)
967+ </para>
968+ </listitem>
969+ <listitem>
970+ <para>
971+ PXE requests an IP address from a local DHCP
972+ server
973+ </para>
974+ </listitem>
975+ <listitem>
976+ <para>
977+ The DHCP server passes additional parameters to
978+ the thin-client and downloads a Linux initramfs filesystem image
979+ via TFTP into a RAM disk on the client itself.
980+ </para>
981+ </listitem>
982+ <listitem>
983+ <para>
984+ The thin-client then boots the downloaded Linux
985+ initramfs image, detects hardware, and connects to the LTSP
986+ server's X session (normally handled by <link linkend="ldm">LDM</link>).
987+ </para>
988+ </listitem>
989+ </orderedlist>
990+ <para>
991+ From here, all operations such as authenticating your
992+ username and password, launching applications, and viewing
993+ websites are actually handled on the LTSP server rather than
994+ the thin-client. The LTSP server transfers all graphical
995+ information to the thin-client over the network. This allows
996+ very low powered thin-clients to utilize the power of the
997+ server for all operations. It also allows for large client
998+ deployments with reduced overall resource utilization, as 50
999+ thin-clients all running the popular OpenOffice suite under
1000+ different sessions generally only require enough RAM for a
1001+ single instance of OpenOffice (excluding per-user
1002+ configuration which is minimal). The server shares memory
1003+ between user sessions, so libraries for applications are only
1004+ loaded once and referenced for each user session.
1005+ </para>
1006+ </sect1>
1007+ </chapter>
1008+ <chapter id='tc-hardware'>
1009+ <title>LTSP Thin Client hardware requirements</title>
1010+ <para>
1011+ A lot of LTSP deployments are in classroom environments, and
1012+ usually, in these situations, the primary goal is to re-use
1013+ existing hardware that the school already owns. However,
1014+ specifically designed thin clients can be used also.
1015+ </para>
1016+ <sect1>
1017+ <title>Hardware reuse and sizing</title>
1018+ <para>
1019+ A person setting up a LTSP thin client environment for the
1020+ first time, typically asks two questions:
1021+ </para>
1022+ <orderedlist>
1023+ <listitem>
1024+ <para>
1025+ Will my existing machines work as terminals, or,
1026+ what should I buy to use as a terminal?
1027+ </para>
1028+ </listitem>
1029+ <listitem>
1030+ <para>
1031+ How big a server do I need?
1032+ </para>
1033+ </listitem>
1034+ </orderedlist>
1035+ <para>
1036+ Chances are, hardware that you already have is more than
1037+ sufficient for terminals. One of the great advantages of an
1038+ LTSP Server is that you can set up a high quality lab of
1039+ terminals for your students to use, by leveraging the machines
1040+ you already have. As for servers, usually, it's very easy to
1041+ turn any high-end single user desktop machine into a terminal
1042+ server capable of handling many thin clients. We'll present
1043+ some guidelines that should help in making the most of your
1044+ resources.
1045+ </para>
1046+ </sect1>
1047+ <sect1>
1048+ <title>Clients</title>
1049+ <sect2>
1050+ <title>Older hardware</title>
1051+ <para>
1052+ There are three things to consider when trying to re-use
1053+ existing hardware:
1054+ </para>
1055+ <orderedlist>
1056+ <listitem>
1057+ <para>
1058+ CPU
1059+ </para>
1060+ </listitem>
1061+ <listitem>
1062+ <para>
1063+ Network
1064+ </para>
1065+ </listitem>
1066+ <listitem>
1067+ <para>
1068+ Thin client memory
1069+ </para>
1070+ </listitem>
1071+ <listitem>
1072+ <para>
1073+ Video card
1074+ </para>
1075+ </listitem>
1076+ </orderedlist>
1077+ </sect2>
1078+ <sect2>
1079+ <title>CPU</title>
1080+ <para>
1081+ For using the default, secure mode of LTSP, you'll need
1082+ to have a slightly faster CPU. Any 533 MHz or better CPU
1083+ should provide acceptable performance.
1084+ </para>
1085+ <para>
1086+ If you have slower clients, in the range of 233 MHz to
1087+ 533 MHz, you may be able to use them, if you're willing to
1088+ reduce the security of your thin client network. More
1089+ information on this is available in the chapter on
1090+ <link linkend="ldm">LDM</link>.
1091+ </para>
1092+ </sect2>
1093+ <sect2>
1094+ <title>Network</title>
1095+ <para>
1096+ A thin client boots over the network, using a small
1097+ program called a network boot loader. This network boot
1098+ loader is sometimes located on the card itself, or, for
1099+ older cards without one, the user can provide one on a
1100+ floppy or CDRom which can be used to boot the thin client.
1101+ </para>
1102+ <para>
1103+ Three common network boot loaders which can be used are:
1104+ </para>
1105+ <orderedlist>
1106+ <listitem>
1107+ <para>
1108+ <emphasis>PXE:</emphasis> This one is the most
1109+ common, and many network cards and motherboards
1110+ with built-in network cards support this. If you
1111+ have one of these, you'll be able to boot without
1112+ any problems.
1113+ </para>
1114+ </listitem>
1115+ <listitem>
1116+ <para>
1117+ <emphasis>Etherboot/gPXE:</emphasis> For older cards
1118+ that don't have PXE included on them, you can use
1119+ the Free Software equivalent, Etherboot, or it's
1120+ newer replacement, gPXE. This
1121+ excellent alternative to PXE can either be booted
1122+ from a floppy, memory stick, or CDRom, or, if
1123+ you're handy with electronics, be burned onto a
1124+ EPROM if your card has a socket for one. More
1125+ information on the project can be found at
1126+ http://www.etherboot.org, and you can download
1127+ ready-to-use Etherboot images at
1128+ http://www.rom-o-matic.org.
1129+ </para>
1130+ </listitem>
1131+ <listitem>
1132+ <para>
1133+ <emphasis>Yaboot:</emphasis> For Macintosh PowerPC
1134+ machines (iMac's and later), you can use the built
1135+ in Yaboot network boot.
1136+ </para>
1137+ </listitem>
1138+ </orderedlist>
1139+ </sect2>
1140+ <sect2>
1141+ <title>Thin client memory</title>
1142+ <para>
1143+ The bare minimum for a thin client to work is about
1144+ 48MB, but it will be unusably slow, so it is recommended
1145+ to install at least 128MB Ram, with 256MB Ram if you can
1146+ spare it. This will really help speed up thin clients.
1147+ </para>
1148+ </sect2>
1149+ <sect2>
1150+ <title>Video Card</title>
1151+ <para>
1152+ Typically, any video card that uses the PCI bus and has
1153+ 16 MB or more of memory, should make a reasonable client.
1154+ </para>
1155+ </sect2>
1156+ </sect1>
1157+ </chapter>
1158+ <chapter id='server-hardware'>
1159+ <title>LTSP Server requirements</title>
1160+ <para>
1161+ An LTSP thin client network is quite scalable; a moderately
1162+ powerful machine can serve several thin clients, and if you need
1163+ to add more thin clients, you can either expand the capabilities
1164+ of the existing server, or, simply add more servers.
1165+ </para>
1166+ <sect1>
1167+ <title>Recommended specs</title>
1168+ <para>
1169+ Server sizing in an LTSP network is more art than science.
1170+ Ask any LTSP administrator how big a server you need to use,
1171+ and you'll likely be told "It depends". How big a server you
1172+ need does depend largely on what it is you're planning on
1173+ doing with your thin client network. The server requirements
1174+ needed for a network where the only use will be a little light
1175+ web-browsing, with no Java or Flash, will be greatly different
1176+ from a network where you want to do heavy graphics,
1177+ interactive games, and Flash animation. Here are some common
1178+ guidelines that should fit most "average" cases.
1179+ </para>
1180+ <sect2>
1181+ <title>Memory</title>
1182+ <para>
1183+ A GNU/Linux based operating system makes efficient use
1184+ of memory. The usual formula that's used for adding memory
1185+ to a thin client server is:
1186+ </para>
1187+ <para>
1188+ 256 + (192 * users) MB
1189+ </para>
1190+ <para>
1191+ So, if your target is to have a server with 20
1192+ terminals, you'll need:
1193+ </para>
1194+ <para>
1195+ 256 + (192 * 20) = 256 + 3840 = 4096 MB
1196+ </para>
1197+ <para>
1198+ So, you'll need 4 1 Gig memory sticks. Making sure
1199+ you've got enough memory is the single most important
1200+ thing you can do to help the performance of an LTSP thin
1201+ client server. If you do not have enough memory in your
1202+ server, you'll find your server will have to use the hard
1203+ drive as an overflow "virtual" memory. Hard drives are
1204+ much slower than memory, so you'll find things getting
1205+ very slow if this happens.
1206+ </para>
1207+ <para>
1208+ If you intend to make heavy use of graphics work in your
1209+ curriculum, you may want to add even more, perhaps
1210+ doubling the previous estimate.
1211+ </para>
1212+ </sect2>
1213+ <sect2>
1214+ <title>Processors</title>
1215+ <para>
1216+ How fast a processor you need is entirely dependant on
1217+ what programs you plan to use. Interactive games require a
1218+ bit more than say, a word processor. If you plan to use
1219+ Java and Flash plug-ins in your web browser, these can
1220+ consume a lot of processing power. For a "mixed" model,
1221+ i.e. some people playing TuxMath, a few people browsing
1222+ the web, and a few people typing in OpenOffice.org, a 2GHz
1223+ or better processor should be able to adequately handle 20
1224+ people with some minor delays. A 3GHz processor would be
1225+ better.
1226+ </para>
1227+ <para>
1228+ For larger networks, moving to an SMP (Symmetric Multi
1229+ Processing), or multiple CPU server may be advantageous.
1230+ If you plan to handle 30 or more clients, a newer
1231+ dual-core Xeon server or dual-core Opteron will provide
1232+ good results.
1233+ </para>
1234+ <para>
1235+ Remember, if you need to serve a large number of
1236+ clients, it will be worth your while to configure multiple
1237+ LTSP servers, each handling some of the terminals.
1238+ </para>
1239+ </sect2>
1240+ <sect2>
1241+ <title>Disks</title>
1242+ <para>
1243+ It's advisable to use some form of RAID in the terminal
1244+ servers. Besides saving your data when a single disks
1245+ fails, it improves the performance (especially read
1246+ performance, which is the most common type of file
1247+ access). For people on a budget, setting up software RAID
1248+ 1, with 2 SATA disks with NCQ (Native Command Queueing)
1249+ will provide good results. If you have a bigger budget,
1250+ and a bigger network, setting up your server with RAID 10
1251+ along with 10,000 RPM western digital VelociRaptors will
1252+ give you the best speeds possible. This will provide you
1253+ with top notch performance and reliability.
1254+ </para>
1255+ </sect2>
1256+ </sect1>
1257+ </chapter>
1258+ <chapter id='network'>
1259+ <title>Network</title>
1260+ <para>
1261+ If you have more than 20 users, it is recommended to use Gigabit
1262+ Ethernet connected to a gigabit port on a switch for your LTSP
1263+ servers. Although normal usage ranges from 0.5 to 2mbit, clients
1264+ can peak quite high (70mbit), especially when watching multimedia
1265+ content.
1266+ </para>
1267+ <para>
1268+ Booting a thin client involves several steps. Understanding what
1269+ is happening along the way will make it much easier to solve
1270+ problems, should they arise.
1271+ </para>
1272+ <para>
1273+ There are four basic services required to boot an LTSP thin
1274+ client. They are:
1275+ </para>
1276+ <orderedlist>
1277+ <listitem>
1278+ <para>
1279+ DHCP
1280+ </para>
1281+ </listitem>
1282+ <listitem>
1283+ <para>
1284+ TFTP
1285+ </para>
1286+ </listitem>
1287+ <listitem>
1288+ <para>
1289+ NFS or NBD
1290+ </para>
1291+ </listitem>
1292+ <listitem>
1293+ <para>
1294+ SSH
1295+ </para>
1296+ </listitem>
1297+ </orderedlist>
1298+ </chapter>
1299+ <chapter id='chroot'>
1300+ <title>The LTSP chroot environment</title>
1301+ <para>
1302+ In order to turn a computer into a thin client, we need to run a
1303+ mini version of GNU/Linux on the workstation. It needs to boot
1304+ this mini version of GNU/Linux over the network, since it probably
1305+ won't have a hard drive on it's own. This mini GNU/Linux
1306+ installation needs to live somewhere, and the best place for it is
1307+ on the server.
1308+ </para>
1309+ <para>
1310+ This scaled-down GNU/Linux installation, customized so that
1311+ it's efficient to boot over the network, is called a chroot
1312+ environment. You can have several of them, based upon several
1313+ different CPU architectures.
1314+ </para>
1315+ <para>
1316+ They'll normally live under <filename>/opt/ltsp</filename> on the server, with
1317+ sub directories for each of the architectures. For instance, if you
1318+ have a lab full of old Power PC Macs, and older PC's, you'll
1319+ have an <filename>/opt/ltsp/ppc</filename> and an
1320+ <filename>/opt/ltsp/i386</filename> directory on the
1321+ server.
1322+ </para>
1323+ <para>
1324+ This is the LTSP project's preferred area to store the chroot,
1325+ however, different distros that support LTSP are free to change
1326+ this. Check with your distro's specific LTSP documentation to see
1327+ where the LTSP chroot is stored.
1328+ </para>
1329+ <para>
1330+ The reason why it is called a chroot environment is that to
1331+ install it, the GNU/Linux command chroot is called to actually set
1332+ the installation root to
1333+ <filename>/opt/ltsp/&lt;arch&gt;</filename>. From there, a
1334+ scaled-down version of the distribution is installed. What this
1335+ means is that for you to manage the chroot, performing such things
1336+ as updates, all you need to do is use the chroot command to change
1337+ the root of your installation. Then you can use all your tools
1338+ like you normally would.
1339+ </para>
1340+ <sect1>
1341+ <title>The boot process of a thin client</title>
1342+ <orderedlist>
1343+ <listitem>
1344+ <para>
1345+ Load the Linux kernel into the memory of the thin
1346+ client. This can be done several different ways,
1347+ including:
1348+ </para>
1349+ </listitem>
1350+ <listitem>
1351+ <para>
1352+ Each of the above booting methods will be explained
1353+ later in this chapter. But for now, it should be noted
1354+ that it makes sense in almost all cases to use a PXE
1355+ based network card during booting for the fastest,
1356+ and easiest to setup method.
1357+ </para>
1358+ </listitem>
1359+ <listitem>
1360+ <para>
1361+ Once the kernel has been loaded into memory, it will
1362+ begin executing.
1363+ </para>
1364+ </listitem>
1365+ <listitem>
1366+ <para>
1367+ The kernel will initialize the entire system and all
1368+ of the peripherals that it recognizes.
1369+ </para>
1370+ </listitem>
1371+ <listitem>
1372+ <para>
1373+ This is where the fun really begins. During the
1374+ kernel loading process, an initramfs image will also
1375+ be loaded into memory.
1376+ </para>
1377+ </listitem>
1378+ <listitem>
1379+ <para>
1380+ Normally, when the kernel is finished booting, it will
1381+ launch the new task launcher <command>upstart</command>,
1382+ which will handle starting up a server or workstation.
1383+ But, in this case, we've instructed the kernel to load
1384+ a small shell script instead. This shell script is
1385+ called <command>/init</command>,and lives in the root
1386+ of the initramfs.
1387+ </para>
1388+ </listitem>
1389+ <listitem>
1390+ <para>
1391+ The <command>/init</command> script begins by mounting
1392+ <filename>/proc</filename> and
1393+ <filename>/sys</filename>, starts <command>udev</command> to
1394+ discover and initialize hardware, especially the
1395+ network card, which is needed for every aspect of the
1396+ boot from here on. As well, it creates a small ram
1397+ disk, where any local storage that is needed (to
1398+ configure the <filename>xorg.conf</filename> file, for
1399+ instance) can be written to.
1400+ </para>
1401+ </listitem>
1402+ <listitem>
1403+ <para>
1404+ The <emphasis>loopback</emphasis> network interface is
1405+ configured. This is the networking interface that has
1406+ <emphasis>127.0.0.1</emphasis> as its IP address.
1407+ </para>
1408+ </listitem>
1409+ <listitem>
1410+ <para>
1411+ A small DHCP client called <command>ipconfig</command>
1412+ will then be run, to make another query from the DHCP
1413+ server. This separate user-space query gets
1414+ information supplied in the dhcpd.conf file, like the
1415+ nfs root server, default gateway, and other important
1416+ parameters.
1417+ </para>
1418+ </listitem>
1419+ <listitem>
1420+ <para>
1421+ When <command>ipconfig</command> gets a reply from the
1422+ server, the information it receives is used to
1423+ configure the Ethernet interface, and determine the
1424+ server to mount the root from.
1425+ </para>
1426+ </listitem>
1427+ <listitem>
1428+ <para>
1429+ Up to this point, the root filesystem has been a ram
1430+ disk. Now, the <command>/init</command> script will
1431+ mount a new root filesystem via either NBD or NFS. In
1432+ the case of NBD, the image that is normally loaded is
1433+ <filename>/opt/ltsp/images/&lt;arch&gt;.img</filename>.
1434+ If the root is mounted via NFS, then the directory
1435+ that is exported from the server is typically
1436+ <filename>/opt/ltsp/&lt;arch&gt;</filename>.
1437+ It can't just mount the new filesystem as
1438+ <filename>/</filename>. It must
1439+ first mount it to a separate directory. Then, it will
1440+ do a <command>run-init</command>, which will swap the
1441+ current root filesystem for a new filesystem. When it
1442+ completes, the filesystem will be mounted on
1443+ <filename>/</filename>. At
1444+ this point, any directories that need to be writable
1445+ for regular start up to occur, like
1446+ <filename>/tmp</filename>, or <filename>/var</filename>, are
1447+ mounted at this time.
1448+ </para>
1449+ </listitem>
1450+ <listitem>
1451+ <para>
1452+ Once the mounting of the new root filesystem is
1453+ complete, we are done with the <command>/init</command> shell script and
1454+ we need to invoke the real <command>/sbin/init</command> program.
1455+ </para>
1456+ </listitem>
1457+ <listitem>
1458+ <para>
1459+ The <command>init</command> program will read the
1460+ <filename>/etc/event.d</filename>
1461+ directory and begin setting up the thin client
1462+ environment. From there, upstart will begin reading
1463+ the start up commands in <filename>/etc/rcS.d</filename>.
1464+ </para>
1465+ </listitem>
1466+ <listitem>
1467+ <para>
1468+ It will execute the <command>ltsp-client-setup</command> command
1469+ which will configure many aspects of the thin client environment,
1470+ such as checking if local devices need starting, loading any
1471+ specified modules, etc.
1472+ </para>
1473+ </listitem>
1474+ <listitem>
1475+ <para>
1476+ Next, the <command>init</command> program will begin
1477+ to execute commands in the <filename>/etc/rc2.d</filename> directory
1478+ </para>
1479+ </listitem>
1480+ <listitem>
1481+ <para>
1482+ One of the items in the <filename>/etc/rc2.d</filename>
1483+ directory is the <command>ltsp-client-core</command>
1484+ command that will be run while the thin client is
1485+ booting.
1486+ </para>
1487+ </listitem>
1488+ <listitem>
1489+ <para>
1490+ The &lts.conf; file will be parsed,
1491+ and all of the parameters in that file that pertain to
1492+ this thin client will be set as environment variables
1493+ for the <command>ltsp-client-core</command> script
1494+ to use.
1495+ </para>
1496+ </listitem>
1497+ <listitem>
1498+ <para>
1499+ If Sound is configured at this point, the
1500+ <command>pulseaudio</command>
1501+ daemon is started, to allow remote audio connections
1502+ from the server to connect and play on the thin
1503+ client.
1504+ </para>
1505+ </listitem>
1506+ <listitem>
1507+ <para>
1508+ If the thin client has local device support enabled,
1509+ the <command>ltspfsd</command> program is started to
1510+ allow the server to read from devices such as memory
1511+ sticks or CD-Roms attached to the thin client.
1512+ </para>
1513+ </listitem>
1514+ <listitem>
1515+ <para>
1516+ At this point, any of the screen sessions you've
1517+ defined in your &lts.conf; will be
1518+ executed.
1519+ </para>
1520+ <para>
1521+ Screen sessions are what you want to launch on all
1522+ of the virtual screens on your terminal. These are the
1523+ standard virtual screens that all GNU/Linux
1524+ distributions usually have, i.e.
1525+ <keycombo><keycap>Alt</keycap><keycap>F1</keycap></keycombo>, through
1526+ <keycombo><keycap>Alt</keycap><keycap>F10</keycap></keycombo>.
1527+ </para>
1528+ <para>
1529+ By default, a standard character based getty will be
1530+ run on screen 1 (<varname>SCREEN_01</varname> in the &lts.conf; file).
1531+ </para>
1532+ <para>
1533+ As well, if nothing else is specified in the
1534+ &lts.conf;
1535+ file, an &ldm; screen script is run
1536+ on <varname>SCREEN_07</varname>. The LTSP Display
1537+ Manager (&ldm;)
1538+ is the default login manager for LTSP.
1539+ </para>
1540+ </listitem>
1541+ <listitem>
1542+ <para>
1543+ If <varname>SCREEN_07</varname> is set to a value of
1544+ &ldm;, or <command>startx</command>, then the X
1545+ Windows System will be launched, giving you a graphical user interface.
1546+ </para>
1547+ <para>
1548+ By default, the Xorg server will auto-probe the card,
1549+ create a default <filename>/etc/X11/xorg.conf</filename> file on the
1550+ ram-disk in the terminal, and start up xorg with that custom config.
1551+ </para>
1552+ </listitem>
1553+ <listitem>
1554+ <para>
1555+ The X server will either start an encrypted <command>ssh</command>
1556+ tunnel to the server, in the case of &ldm;, or an an
1557+ XDMCP query to the LTSP server, in the case of
1558+ <command>startx</command>. Either way,
1559+ a login box will appear on the terminal.
1560+ </para>
1561+ </listitem>
1562+ <listitem>
1563+ <para>
1564+ At this point, the user can log in. They'll get a
1565+ session on the server.
1566+ </para>
1567+ <para>
1568+ This confuses a lot of people at first. They are
1569+ sitting at a thin client, but they are running a
1570+ session on the server. All commands they run will be
1571+ run on the server, but the output will be displayed on
1572+ the thin client.
1573+ </para>
1574+ </listitem>
1575+ </orderedlist>
1576+ </sect1>
1577+ </chapter>
1578+ <chapter id='network-boot'>
1579+ <title>Network booting the thin client</title>
1580+ <para>
1581+ Getting the thin client to boot over the network can be
1582+ accomplished in a variety of ways:
1583+ </para>
1584+ <orderedlist>
1585+ <listitem>
1586+ <para>
1587+ Boot ROM
1588+ </para>
1589+ </listitem>
1590+ <listitem>
1591+ <para>
1592+ Local media
1593+ </para>
1594+ </listitem>
1595+ </orderedlist>
1596+ <sect1>
1597+ <title>Boot ROM</title>
1598+ <para>
1599+ Depending on your network card, it may already contain a
1600+ boot ROM, or you may be able to use an EPROM programmer to
1601+ create your own. Check the hardware documentation for the
1602+ network card in your thin client for details.
1603+ </para>
1604+ <sect2>
1605+ <title>Etherboot</title>
1606+ <para>
1607+ Etherboot is a very popular open-source bootrom project.
1608+ It contains drivers for many common network cards, and
1609+ works very well with LTSP.
1610+ </para>
1611+ <para>
1612+ ROM images suitable for booting from floppy, CD-ROM,
1613+ etc., can be obtained from http://www.rom-o-matic.org
1614+ </para>
1615+ <para>
1616+ Linux kernels must be tagged with the <command>mknbi-linux</command>,
1617+ which will prepare the kernel for network booting, by
1618+ prefixing the kernel with some additional code, and
1619+ appending the initrd to the end of the kernel.
1620+ </para>
1621+ <para>
1622+ The kernels that are supplied with LTSP are already
1623+ tagged, and ready to boot with Etherboot.
1624+ </para>
1625+ </sect2>
1626+ <sect2>
1627+ <title>PXE</title>
1628+ <para>
1629+ Part of the 'Wired for Management' specification from the
1630+ late 1990's included a specification for a bootrom
1631+ technology known as the
1632+ <emphasis>Pre-boot Execution Environment</emphasis>
1633+ commonly abbreviated as <emphasis>PXE</emphasis>.
1634+ </para>
1635+ <para>
1636+ A PXE bootrom can load at most a 32 kilo-byte file. A
1637+ Linux kernel is quite a bit larger than that. Therefore,
1638+ we setup PXE to load a 2nd stage boot loader called
1639+ <command>pxelinux</command>, which is small enough
1640+ to be loaded. It knows how to load
1641+ much larger files, such as a Linux kernel.
1642+ </para>
1643+ </sect2>
1644+ </sect1>
1645+ <sect1>
1646+ <title>Local media</title>
1647+ <para>
1648+ If your network card in the thin client doesn't have a boot
1649+ ROM built in, and you don't have access to an EPROM burner,
1650+ have no fear! Chances are, that old machine has a floppy
1651+ drive, or CD-ROM in it. If so, then you can use local media to
1652+ boot the thin client.
1653+ </para>
1654+ <sect2>
1655+ <title>Floppy disk</title>
1656+ <para>
1657+ Booting Etherboot from a floppy is an excellent way of
1658+ booting an LTSP thin client that doesn't have a boot ROM.
1659+ Etherboot is loaded in the boot sector of the floppy.
1660+ Then, it will act just like a bootrom. The boot code will
1661+ be executed, the network card will be initialized, and the
1662+ kernel will be loaded from the network server.
1663+ </para>
1664+ </sect2>
1665+ <sect2>
1666+ <title>Hard disk</title>
1667+ <para>
1668+ The hard disk can be used with LILO or GRUB, to load the
1669+ Linux kernel and initrd. You can also load the Etherboot
1670+ bootrom image from the hard disk, and it will act like a
1671+ bootrom.
1672+ </para>
1673+ </sect2>
1674+ <sect2>
1675+ <title>CD-ROM</title>
1676+ <para>
1677+ A bootable CD-ROM can be loaded either with a Linux
1678+ kernel, or an Etherboot image.
1679+ </para>
1680+ </sect2>
1681+ <sect2>
1682+ <title>USB Memory device</title>
1683+ <para>
1684+ Just like a CD-ROM, Floppy disk and Hard disk, you can
1685+ use a USB Memory device to boot an Etherboot module.
1686+ </para>
1687+ </sect2>
1688+ </sect1>
1689+ <sect1>
1690+ <title>Installation</title>
1691+ <para>
1692+ With the integration of LTSP into distributions, installation
1693+ of LTSP is now usually as easy as adding the LTSP packages in
1694+ your distro's package manager. Consult your distribution's
1695+ documentation for details on how to install LTSP on your
1696+ particular system.
1697+ </para>
1698+ <para>
1699+ However, as a general guideline, usually after you've installed
1700+ your distributions' LTSP packages, and configured your network
1701+ interfaces, and some kind of DHCP3 server, you'd run (as root):
1702+ </para>
1703+ <screen>
1704+sudo ltsp-build-client
1705+ </screen>
1706+ <para>
1707+ If you are on a 64-bit system but your clients
1708+ have another architecture use the --arch option
1709+ e.g. <screen>ltsp-build-client --arch i386</screen>
1710+ </para>
1711+ <para>
1712+ After that, you should be able to boot your first thin
1713+ client.
1714+ </para>
1715+ </sect1>
1716+ </chapter>
1717+ <chapter id='customizing-ltsconf'>
1718+ <title>Customizing thin client behaviour</title>
1719+ <para>
1720+ By default, most thin clients will automatically configure
1721+ themselves correctly, and just work when they're plugged in.
1722+ However, sometimes you may wish to customize their behaviour. You
1723+ would do this by editing the &lts.conf; file.
1724+ </para>
1725+ <sect1>
1726+ <title>Location of the lts.conf file</title>
1727+ <para>
1728+ In order to speed up LTSP, by default, we're using NBD
1729+ (Network Block Devices) rather than NFS. To do this, we'd had
1730+ to move the the lts.conf file out of the chroot and into the
1731+ TFTP directory, in /var/lib/tftpboot/ltsp/&lt;arch&gt;, where
1732+ &lt;arch&gt; is the architecture you are working on (usually i386,
1733+ but could be something else, like amd64 for example). This
1734+ means you can make changes to the file immediately, and simply
1735+ reboot the terminal, without recompiling the image.
1736+ </para>
1737+ </sect1>
1738+ <sect1>
1739+ <title>Sample lts.conf file</title>
1740+ <para>
1741+ Here is an example of the lts.conf file: </para>
1742+ <screen>
1743+################
1744+# Global defaults for all clients
1745+# if you refer to the local server, just use the
1746+# "server" keyword as value
1747+# see lts_parameters.txt for valid values
1748+################
1749+
1750+[default]
1751+ X_COLOR_DEPTH=16
1752+ LOCALDEV=True
1753+ SOUND=True
1754+ NBD_SWAP=True
1755+ SYSLOG_HOST=server
1756+ XKBLAYOUT=de
1757+
1758+################
1759+#[MAC ADDRESS]: Per thin client settings
1760+################
1761+
1762+[00:11:25:84:CE:BA]
1763+ XSERVER = vesa
1764+ X_MOUSE_DEVICE=/dev/ttyS0
1765+ X_MOUSE_PROTOCOL=intellimouse
1766+
1767+###############
1768+# A Thin Client Print server
1769+# (switch off X by pointing tty7 to shell,
1770+# to save resources)
1771+###############
1772+
1773+[00:11:25:93:CF:00]
1774+ PRINTER_0_DEVICE=/dev/usblp0
1775+ SCREEN_07=shell
1776+
1777+###############
1778+# A workstation that executes a specific
1779+# command after login
1780+###############
1781+
1782+[00:11:25:93:CF:02]
1783+ LDM_SESSION=/usr/bin/myloginscript
1784+ </screen>
1785+ </sect1>
1786+ </chapter>
1787+ <chapter id='lts-conf'>
1788+ <title>Format of the lts.conf file</title>
1789+ <para>
1790+ When LTSP was designed, one of the issues that needed to be
1791+ dealt with was varying hardware configurations for the thin
1792+ client. Certainly, whatever combination of processor, network card
1793+ and video card available today would not be available in 3 months,
1794+ when you want to add more thin clients to the network. So, LTSP
1795+ devised a way of specifying the configuration of each thin client.
1796+ The configuration file is called lts.conf and it lives in the
1797+ <filename>/var/lib/tftpboot/ltsp/&lt;arch&gt;/</filename> directory.
1798+ </para>
1799+ <para>
1800+ The format of the lts.conf allows for 'default' settings and
1801+ individual thin client settings. If all of your thin clients are
1802+ identical, you could specify all of the configuration settings in
1803+ the <varname>'[Default]'</varname> section. The file must have a first line
1804+ containing <varname>'[Default]'</varname> in any case.
1805+ </para>
1806+ <sect1>
1807+ <title>Section headings </title>
1808+ <para>
1809+ Section headings begin with an identifier in the form
1810+ [Default] which is used for all computers as mentioned above,
1811+ and [MAC address] for individual workstations, in the form of
1812+ [XX:XX:XX:XX:XX:XX], where X is the digits 0-9, or A-F.
1813+ </para>
1814+ <para>
1815+ You can usually read the MAC address for a network card from
1816+ a sticker on the card itself, or use some kind of network tool
1817+ to discover it. The best way to check for the MAC address of
1818+ the machine is by starting it up, checking its IP number and
1819+ doing a <command>arp -an</command> on the server, this should then tell you
1820+ which IP number has which MAC address.
1821+ </para>
1822+ </sect1>
1823+ <sect1>
1824+ <title>Variable Assignments</title>
1825+ <para>
1826+ After the section heading, you can then define variables.
1827+ Variables are ether boolean values, requiring a True/False or
1828+ Y/N answer. Note that you can either use True or False, Yes or
1829+ No, or Y or N. Whichever you prefer. Other variables may
1830+ simply be strings, supplied after the = sign. The general
1831+ format of an assignment looks like:
1832+ </para>
1833+ <screen>
1834+VARIABLE = value
1835+ </screen>
1836+ <para>
1837+ Comments can be inserted into the file for your
1838+ documentation purposes. Comments start with a # character, and
1839+ everything after the # for the rest of the line is considered
1840+ a comment.
1841+ </para>
1842+ </sect1>
1843+ <sect1>
1844+ <title>The LIKE keyword</title>
1845+ <para>
1846+ The <varname>LIKE</varname> keyword allows you to define a
1847+ general set of parameters under a unique identifier, and then
1848+ assign individual workstations that set of parameters using the
1849+ <varname>LIKE</varname> keyword. An example will illustrate
1850+ it's use.
1851+ </para>
1852+ <para>Let's assume you have 3 kinds of thin clients on your
1853+ network. One set, which are used in the lab, have older video
1854+ cards, and must use 16 bit colour at 1024x768 resolution.
1855+ Another set need to have their video ram set to 8 megs, and a
1856+ third set which auto-detect everything correctly. We don't
1857+ need to specify anything for the third set, but having some
1858+ symbolic names for the first two would help us to maintain the
1859+ &lts.conf; file.
1860+ </para>
1861+ <para>
1862+ Here's an example &lts.conf; that
1863+ illustrates how this would be done:
1864+ </para>
1865+ <screen>
1866+[Lab]
1867+ X_COLOR_DEPTH = 16
1868+ X_MODE_0 = 1024x768
1869+
1870+[Lowram]
1871+ X_VIDEO_RAM = 8096
1872+
1873+[00:40:32:71:77:A1]
1874+ LIKE = Lab
1875+
1876+[00:70:84:BB:27:52]
1877+ LIKE = Lowram
1878+ </screen>
1879+ <para>
1880+ As you can see, using the <varname>LIKE</varname> keyword can
1881+ make your &lts.conf; more readable, by
1882+ allowing you to group related parameters together into a single
1883+ symbolic name.
1884+ </para>
1885+ </sect1>
1886+ </chapter>
1887+ <chapter id='general-parms'>
1888+ <title>General thin client parameters</title>
1889+ <para>
1890+ There are several variables that one can define in the lts.conf
1891+ file which control how the thin client interacts with the server.
1892+ These are:
1893+ </para>
1894+ <xi:include
1895+ href='lts.conf.xml'
1896+ xpointer='lts-conf-general-list'
1897+ xmlns:xi='http://www.w3.org/2001/XInclude' />
1898+ </chapter>
1899+ <chapter id='localdev-parms'>
1900+ <title>Local Device thin client parameters</title>
1901+ <para>
1902+ Local devices such as USB sticks, CD-ROM drives, or even floppy
1903+ disks need special configuration in order to be accessed from the
1904+ thin client. The following values allow to enable or disable the
1905+ use of various local devices:
1906+ </para>
1907+ <xi:include
1908+ href='lts.conf.xml'
1909+ xpointer='lts-conf-localdev-list'
1910+ xmlns:xi='http://www.w3.org/2001/XInclude' />
1911+ </chapter>
1912+ <chapter id='screen-scripts'>
1913+ <title>Screen Scripts</title>
1914+ <para>
1915+ Screen scripts are how LTSP determines what type of login will
1916+ run on what virtual screen. Most GNU/Linux machines have 12
1917+ virtual consoles, which you can access by pressing
1918+ <keycombo><keycap>Control</keycap><keycap>Alt</keycap><keycap>F1</keycap></keycombo>, through
1919+ <keycombo><keycap>Control</keycap><keycap>Alt</keycap><keycap>F12</keycap></keycombo>.
1920+ On some distributions there is a text based getty that is
1921+ started on screen 1, but you normally can't log into it, as there
1922+ are no local users on the thin client.
1923+ </para>
1924+ <para>
1925+ However, for debugging purposes, you may want to set up root to
1926+ log in on the thin client. You may need to do this if you're
1927+ debugging problems with local devices, for example. Fortunately,
1928+ it's easy to do: on the server, as root, just chroot into the LTSP chroot,
1929+ and set the password with passwd.
1930+ </para>
1931+ <screen>
1932+chroot /opt/ltsp/&lt;arch&gt;
1933+passwd
1934+ </screen>
1935+ <para>
1936+ By default, if there's nothing else mentioned in
1937+ &lts.conf;,
1938+ an LDM session will be started on screen 7.
1939+ </para>
1940+ <xi:include
1941+ href='lts.conf.xml'
1942+ xpointer='lts-conf-screen-list'
1943+ xmlns:xi='http://www.w3.org/2001/XInclude' />
1944+ </chapter>
1945+ <chapter id='rdesktop'>
1946+ <title>The "rdesktop" screen script</title>
1947+ <para>
1948+ LTSP includes an &rdesktop; screen script that
1949+ can be used to bring up a full screen RDP connection using
1950+ &rdesktop; on the thin client. This
1951+ screen script can be invoked in one of two ways.
1952+ </para>
1953+ <sect1>
1954+ <title>Single Line</title>
1955+ <para>
1956+ For example, by adding the following
1957+ &lts.conf; parameter:
1958+ </para>
1959+ <screen>
1960+SCREEN_07 = "rdesktop -a 16 192.168.0.253"
1961+ </screen>
1962+ <para>
1963+ That is, calling it with the arguments you normally would on the
1964+ command line. This method of invocation is useful in that you can have
1965+ multiple screens pointing to different RDP servers with different
1966+ arguments and switch between them.
1967+ </para>
1968+ </sect1>
1969+ <sect1>
1970+ <title>Multiple Line</title>
1971+ <para>
1972+ For example, by adding the following parameters to
1973+ &lts.conf;:
1974+ </para>
1975+ <screen>
1976+SCREEN_07 = rdesktop
1977+RDP_SERVER = 192.168.0.253
1978+RDP_OPTIONS = "-a 16"
1979+ </screen>
1980+ <para>
1981+ This method will apply the same arguments and server to all screens.
1982+ </para>
1983+ </sect1>
1984+ <sect1>
1985+ <title>RDP + Local Devices</title>
1986+ <para>
1987+ When you run an &rdesktop; screen script,
1988+ &rdesktop; runs on the thin
1989+ client. The thin client, by default, has no way of automounting
1990+ removable devices, and the normal localdev approach used in an
1991+ &ldm; session in which local devices invoke a call over ssh to have the
1992+ Linux server mount the device obviously won't work.
1993+ </para>
1994+ <para>
1995+ To address this issue in a controlled way, we have chosen to use
1996+ &ltspfs; as a local automounter for RDP
1997+ sessions. To add local device support, you must:
1998+ </para>
1999+ <orderedlist>
2000+ <listitem>
2001+ <para>
2002+ Install ltspfs in the chroot.
2003+ </para>
2004+ </listitem>
2005+ <listitem>
2006+ <para>
2007+ Use folder redirection in &rdesktop; to map the local /media/root
2008+ folder created by ltspfs to the server as a shared drive. For
2009+ example, you could add the following &rdesktop; argument:
2010+ </para>
2011+ <screen>
2012+-r disk:Drives=/media/root
2013+ </screen>
2014+ <para>
2015+ With this redirection, you should get a "Drives" share in Windows
2016+ under My Computer. Inside the "Drives" share, a folder will appear for
2017+ each local device. The local device will be mounted with ltspfs, so
2018+ they can just be removed when the device is not being written to
2019+ without "unmounting".
2020+ </para>
2021+ </listitem>
2022+ </orderedlist>
2023+ </sect1>
2024+ <sect1>
2025+ <title>RDP + Local Sound</title>
2026+ <para>
2027+ You should be able to add sound to your RDP session with the following
2028+ &rdesktop; argument:
2029+ </para>
2030+ <screen>
2031+-r sound:local
2032+ </screen>
2033+ </sect1>
2034+ </chapter>
2035+ <chapter id='modules-scripts'>
2036+ <title>Modules and startup scripts</title>
2037+ <para>
2038+ For the most part, LTSP does a very good job of detecting what
2039+ hardware's on your thin client. However, it's possible that you
2040+ may want to manually specify a kernel module to load after boot.
2041+ Alternatively, you may have a script you've written that you've
2042+ put in the chroot, and want to make sure gets run at startup. LTSP
2043+ provides some hooks to allow you to do this.
2044+ </para>
2045+ <xi:include
2046+ href='lts.conf.xml'
2047+ xpointer='lts-conf-modules-list'
2048+ xmlns:xi='http://www.w3.org/2001/XInclude' />
2049+ </chapter>
2050+ <chapter id='sound'>
2051+ <title>Sound in LTSP</title>
2052+ <para>
2053+ Sound in LTSP is handled by running the
2054+ <command>pulseaudio</command> daemon on the
2055+ thin client, which sits on top of the ALSA kernel drivers. The
2056+ thin client's kernel should detect the thin client sound hardware
2057+ via the usual udev mechanisms, and enable the sound card. At boot
2058+ time, the <command>pulseaudio</command> daemon is run, which allows the thin client to
2059+ receive audio streams via network connections.
2060+ </para>
2061+ <para>
2062+ On login, the LDM sets both the <varname>PULSE_SERVER</varname> and
2063+ <varname>ESPEAKER</varname>
2064+ environment variables for the X windows session, to allow the
2065+ server to re-route the sound over a TCP/IP socket to the thin
2066+ client.
2067+ </para>
2068+ <xi:include
2069+ href='lts.conf.xml'
2070+ xpointer='lts-conf-sound-list'
2071+ xmlns:xi='http://www.w3.org/2001/XInclude' />
2072+ </chapter>
2073+ <chapter id='xwin-parms'>
2074+ <title>X-Windows parameters</title>
2075+ <para>
2076+ Setting up X windows on the thin client's normally a pretty easy
2077+ operation. The thin client uses X.org's own auto configuration
2078+ mode to let X determine what it thinks is installed in the box.
2079+ </para>
2080+ <para>
2081+ However, sometimes, this doesn't always work. Either due to
2082+ strange/buggy hardware, or buggy drivers in X.org, or because X
2083+ detects default settings that you don't want. For instance, it may
2084+ detect that your monitor is capable of doing 1280x1024, but you'd
2085+ prefer it to come up in 1024x768 resolution. Fortunately, you can
2086+ tweak individual X settings, or, alternatively, simply provide
2087+ your own <filename>xorg.conf</filename> to use.
2088+ </para>
2089+ <sect1>
2090+ <title>X.org Configuration</title>
2091+ <xi:include
2092+ href='lts.conf.xml'
2093+ xpointer='lts-conf-xorg-list'
2094+ xmlns:xi='http://www.w3.org/2001/XInclude' />
2095+ </sect1>
2096+ </chapter>
2097+ <chapter id='xrandr'>
2098+ <title>XRANDR setting for managing displays</title>
2099+ <para>
2100+ The new Xorg Xserver has the ability to figure out (for the most part,
2101+ to the extent that the driver helps in the process) the best mode for
2102+ the videocard. Moreover, with the new dependency upon hal and Xrandr,
2103+ it is recommended to add input devices with hal and modify video modes
2104+ with Xrandr 1.2 calls. In essence, the xorg.conf becomes a place really
2105+ to fix deficiencies in poorly written drivers or to force certain
2106+ abnormal driver behavior in a particular environment in a way that can
2107+ not be otherwise done through hal or Xrandr.
2108+ </para>
2109+ <sect1>
2110+ <title>New Xorg structure within LTSP</title>
2111+ <para>
2112+ To accommodate this, Xorg now understands partial xorg.conf files.
2113+ Meaning you only add the sections that you need to force. Otherwise, it
2114+ discovers everything. That's why you might see minimalist xorg.conf
2115+ files in your LTSP chroot.
2116+ </para>
2117+ <para>
2118+ The <filename>screen-session.d/</filename> directory (located in the
2119+ chroot's <filename>/usr/share/ltsp directory</filename>) is a structure of shell scripts all
2120+ of which are sourced in order (similar to
2121+ <filename>Xsession.d/</filename> or <filename>rc.d/</filename> that you
2122+ may be familiar with). These scripts are executed upon the beginning of
2123+ each session but before the Xserver (if the session runs an Xserver) is
2124+ launched. You can make whatever script you want that may need to run at
2125+ that point. For LTSP, one thing we use it for is to set up
2126+ <emphasis>how</emphasis> the
2127+ Xserver will be launched. This entails not just generating a
2128+ <filename>xorg.conf</filename>
2129+ file as needed, but also configuring the parameters that the Xserver
2130+ should be launched with. The nice thing about a collection of sourced
2131+ scripts is that it gives flexibility to the distribution or to the
2132+ administrator to add additional scripts that may be required for that
2133+ distribution or for a particular network environment that will not
2134+ modify existing files (and therefore require more maintenance to care
2135+ for updates in the upstream code).
2136+ </para>
2137+ </sect1>
2138+ <sect1>
2139+ <title>Script structure</title>
2140+ <para>
2141+ Each script is named with a prefix letter, then an order number, then a
2142+ name. The prefix letter determines when the scripts of that prefix are
2143+ executed and the order number determines in what order.
2144+ </para>
2145+ <para>
2146+ PREFIXES:
2147+ Prefixes that may be used include:
2148+ </para>
2149+ <para>
2150+ S - Is a script that runs at the beginning of a session (screen script)
2151+ K - Is a script that runs at the end of a session (screen script)
2152+ XS - Is a script that is only run at the beginning of screen scripts
2153+ that run an Xserver
2154+ </para>
2155+ <para>
2156+ All of the scripts that generate a xorg.conf or modify the Xserver
2157+ arguments are XS* scripts.
2158+ </para>
2159+ <para>
2160+ These scripts are mostly organized by the particular lts.conf parameter
2161+ or function that they affect. For example, XS85-xvideoram adds the
2162+ ability to specify the X_VIDEO_RAM parameter in lts.conf and force the
2163+ amount of video ram used by the driver.
2164+ </para>
2165+ <para>
2166+ If you are going to create your own script, I recommend looking at other
2167+ scripts to understand the structure. Since many hacks may impact the
2168+ same xorg.conf sections, each section has a function of hacks assigned
2169+ to it, and in your script, you would create a function and add it to the
2170+ list of functions for that section. For example, if you add something
2171+ to the Monitor section (that cannot already be added through existing
2172+ functions) you would create a function in your script and add it to the
2173+ monitor_hacks function list. Again, easier to read the code and look at
2174+ examples to understand how to write a new script.
2175+ </para>
2176+ <para>
2177+ Also, please note that one of the lts.conf parameters you can specify
2178+ is: <varname>CONFIGURE_X_COMMAND</varname>
2179+ This should be set to a path to a script. So, if you have the old
2180+ configure-x.sh and like it better, simply copy it into the chroot, to
2181+ say,
2182+ <command>/opt/ltsp/&lt;arch&gt;/usr/share/ltsp/configure-x.sh</command>
2183+ and then in &lts.conf;,
2184+ specify: <screen>CONFIGURE_X_COMMAND =
2185+ "/usr/share/ltsp/configure-x.sh"</screen> and
2186+ you will be back to where you were.
2187+ </para>
2188+ </sect1>
2189+ <sect1>
2190+ <title>XRandR parameters</title>
2191+ <xi:include
2192+ href='lts.conf.xml'
2193+ xpointer='lts-conf-xrandr-list'
2194+ xmlns:xi='http://www.w3.org/2001/XInclude' />
2195+ </sect1>
2196+ </chapter>
2197+ <chapter id='printer'>
2198+ <title>Printer configuration parameters</title>
2199+ <para>
2200+ Sometimes, it's convenient to hang a printer off of a thin
2201+ client in a lab, so that the computer lab has access to local
2202+ printing resources. Fortunately, LTSP can accommodate printing on
2203+ the workstation.
2204+ </para>
2205+ <para>
2206+ LTSP can connect up to 3 printers per workstation to the network
2207+ via a small daemon called JetPipe. Both parallel and USB printers
2208+ are supported. JetPipe makes the printer look like a standard HP
2209+ Jet Direct printer interface. You can then create any cups printer
2210+ on your server, and point it at the printer via a Jet Direct
2211+ connection.
2212+ </para>
2213+ <para>
2214+ In your <filename>dhcpd.conf</filename> file that controls your
2215+ thin client IP assignments, you'll want to assign a static IP for
2216+ the terminal with the printers, to guarantee that it gets the same
2217+ IP address every time it boots. Otherwise, your printing won't
2218+ work if the terminal leases a different IP address.
2219+ </para>
2220+ <xi:include
2221+ href='lts.conf.xml'
2222+ xpointer='lts-conf-printer-list'
2223+ xmlns:xi='http://www.w3.org/2001/XInclude' />
2224+ </chapter>
2225+ <chapter id='keyboard'>
2226+ <title>Keyboard parameters</title>
2227+ <para>
2228+ All of the keyboard support files are copied into the
2229+ <filename>/opt/ltsp/&lt;arch&gt;</filename> hierarchy, so configuring international keyboard
2230+ support is simply a matter of configuring X.org. There are several
2231+ configuration parameters for this.
2232+ </para>
2233+ <para>
2234+ The values for the above parameters are from the X.org
2235+ documentation. Whatever is valid for X.org is valid for these
2236+ parameters.
2237+ </para>
2238+ <para>
2239+ We would like to add documentation to show what values are
2240+ needed for each type of international keyboard. If you work with
2241+ this and can configure your international keyboards, feedback to
2242+ LTSP would be greatly appreciated.
2243+ </para>
2244+ <xi:include
2245+ href='lts.conf.xml'
2246+ xpointer='lts-conf-keyboard-list'
2247+ xmlns:xi='http://www.w3.org/2001/XInclude' />
2248+ </chapter>
2249+ <chapter id='touchscreen'>
2250+ <title>Touchscreen configuration</title>
2251+ <para>
2252+ Description to be added later.
2253+ </para>
2254+ <xi:include
2255+ href='lts.conf.xml'
2256+ xpointer='lts-conf-touchscreen-list'
2257+ xmlns:xi='http://www.w3.org/2001/XInclude' />
2258+ </chapter>
2259+ <chapter id='localapps'>
2260+ <title>Local Applications</title>
2261+ <para>
2262+ Description to be added later.
2263+ </para>
2264+ <xi:include
2265+ href='lts.conf.xml'
2266+ xpointer='lts-conf-localapps-list'
2267+ xmlns:xi='http://www.w3.org/2001/XInclude' />
2268+ </chapter>
2269+ <chapter id='ldm'>
2270+ <title>The LDM display manager</title>
2271+ <sect1>
2272+ <title>Introduction</title>
2273+ <para>
2274+ The LTSP Display Manager, or &ldm; is the
2275+ display manager specifically written by the LTSP project to
2276+ handle logins to a GNU/Linux server. It is the default display
2277+ manager for LTSP thin clients running under LTSP, and has a
2278+ lot of useful features:
2279+ </para>
2280+ <orderedlist>
2281+ <listitem>
2282+ <para>
2283+ It is written in C, for speed and efficiency on low
2284+ end clients.
2285+ </para>
2286+ </listitem>
2287+ <listitem>
2288+ <para>
2289+ It supports logging in via either a greeter (a
2290+ graphical login application) or autologin.
2291+ </para>
2292+ </listitem>
2293+ <listitem>
2294+ <para>
2295+ It can be configured to encrypt X Windows traffic,
2296+ for increased security, or leave it unencrypted, for
2297+ better performance on slower clients.
2298+ </para>
2299+ </listitem>
2300+ <listitem>
2301+ <para>
2302+ It contains a simple load-balancing system, to allow
2303+ the system administrator to allow load balancing
2304+ across several servers.
2305+ </para>
2306+ </listitem>
2307+ </orderedlist>
2308+ <para>
2309+ We'll go over the &lts.conf; entries you'll
2310+ need to control these features below.
2311+ </para>
2312+ </sect1>
2313+ <sect1>
2314+ <title>Theory of operation</title>
2315+ <para>
2316+ To help understand the following sections, a bit of an
2317+ explanation of how &ldm; does it's work is
2318+ needed. Most thin client display managers tend to run up on
2319+ the server. The &ldm; display manager is
2320+ unique in that it runs on the thin client itself. This allows
2321+ the thin client to have a lot of choice as to how it will set
2322+ up the connection. A typical login session goes as follows:
2323+ </para>
2324+ <orderedlist>
2325+ <listitem>
2326+ <para>
2327+ &ldm; launches and starts up the X
2328+ Windows display on the thin client.
2329+ </para>
2330+ </listitem>
2331+ <listitem>
2332+ <para>
2333+ &ldm; starts up the greeter, which is
2334+ a graphical program which presents the user with a
2335+ nice login display and allows them to select their
2336+ session, language, and host they'd like to log into.
2337+ </para>
2338+ </listitem>
2339+ <listitem>
2340+ <para>
2341+ &ldm; collects the information from
2342+ the greeter, and starts an ssh session with the
2343+ server. This ssh connection is used to create an ssh
2344+ master socket, which is used by all subsequent
2345+ operations.
2346+ </para>
2347+ </listitem>
2348+ <listitem>
2349+ <para>
2350+ Now, the users selected session is started via the
2351+ master socket. Depending on whether or not an
2352+ encrypted connection has been requested, via the
2353+ <varname>LDM_DIRECTX</varname> parameter, the session is either connected
2354+ back to the local display via the ssh tunnel, or via a
2355+ regular TCP/IP connection.
2356+ </para>
2357+ </listitem>
2358+ <listitem>
2359+ <para>
2360+ During the session, any memory sticks, or other
2361+ local devices that are plugged in, communicate their
2362+ status to the server via the ssh control socket.
2363+ </para>
2364+ </listitem>
2365+ <listitem>
2366+ <para>
2367+ When the user exits the session, the ssh connection is
2368+ closed down, the X server is stopped, and &ldm;
2369+ restarts itself, so everything starts with a clean slate.
2370+ </para>
2371+ </listitem>
2372+ </orderedlist>
2373+ </sect1>
2374+ <sect1>
2375+ <title>Encrypted versus unencrypted sessions</title>
2376+ <para>
2377+ By default, LTSP5 encrypts the X session between the server.
2378+ This makes your session more secure, but at the cost of
2379+ increased processing power required on the thin client and on
2380+ the server. If processing power is a concern to you, it's very
2381+ easy to specify that the connection for either an individual
2382+ workstation, or the default setting should use an unencrypted
2383+ connection. To do so, simply specify:
2384+ </para>
2385+ <screen>
2386+LDM_DIRECTX = True
2387+ </screen>
2388+ <para>
2389+ in your &lts.conf; file in the appropriate
2390+ section.
2391+ </para>
2392+ </sect1>
2393+ <sect1>
2394+ <title>Auto login features</title>
2395+ <para>
2396+ This new version of LDM supports auto login of accounts, if
2397+ specified in the &lts.conf; file. Simply
2398+ create a config section for each of the terminals you want to
2399+ log in automatically (you can use either MAC address, IP
2400+ address, or hostname) and specify the variable
2401+ <varname>LDM_USERNAME</varname>
2402+ and <varname>LDM_PASSWORD</varname>. Note that you must have
2403+ created these accounts on the server, with the passwords
2404+ specified. An example will serve to illustrate how to use
2405+ this:
2406+ </para>
2407+ </sect1>
2408+ <sect1>
2409+ <title>Load balancing features</title>
2410+ <para>
2411+ In this version of LTSP, there's a simple load-balancing
2412+ solution implemented that allows administrators to have
2413+ multiple LTSP servers on the network, and allow the thin
2414+ client to pick which one of the servers it would like to log
2415+ into.
2416+ </para>
2417+ <para>
2418+ The host selection system is simple and flexible enough to
2419+ allow administrators to implement their own policy on how they
2420+ want the load balancing to happen: either on a random,
2421+ load-based, or round robin system. See for details.
2422+ </para>
2423+ </sect1>
2424+ <sect1>
2425+ <title>RC script capabilities</title>
2426+ <para>
2427+ LDM has a very good system for handling user-supplied rc.d
2428+ scripts. This allows people looking to add site-specific
2429+ customizations to their LTSP setups an easy way to integrate
2430+ this functionality into LTSP.
2431+ </para>
2432+ <para>
2433+ These rc.d scripts can be placed in
2434+ <filename>$CHROOT/usr/share/ldm/rc.d/</filename>. They are
2435+ executed in the usual rc.d type method, so you must make sure
2436+ that any script you write will not make a call to
2437+ <command>exit</command>.
2438+ </para>
2439+ <para>
2440+ The files start with the letter I, S, K, or X, and have two
2441+ digits after them, allowing you to place them in order of
2442+ execution. The letters stand for:
2443+ </para>
2444+ <itemizedlist>
2445+ <listitem>
2446+ <para>
2447+ <emphasis>I</emphasis> scripts are executed at the
2448+ start of LDM, before the greeter has been presented.
2449+ </para>
2450+ </listitem>
2451+ <listitem>
2452+ <para>
2453+ <emphasis>S</emphasis> scripts are executed after the user
2454+ has logged in, but before the X session is run.
2455+ </para>
2456+ </listitem>
2457+ <listitem>
2458+ <para>
2459+ <emphasis>X</emphasis> scripts are executed while the X
2460+ session is being executed.
2461+ </para>
2462+ </listitem>
2463+ <listitem>
2464+ <para>
2465+ <emphasis>K</emphasis> scripts are executed after the X
2466+ session has ended, but before the user logs out entirely.
2467+ </para>
2468+ </listitem>
2469+ </itemizedlist>
2470+ <para>
2471+ Your scripts can make use of the following environment
2472+ variables in the S, X, and K scripts:
2473+ </para>
2474+ <variablelist>
2475+ <varlistentry>
2476+ <term><varname>LDM_USERNAME</varname></term>
2477+ <listitem>
2478+ <para>
2479+ This is the username the user supplied at login.
2480+ </para>
2481+ </listitem>
2482+ </varlistentry>
2483+ <varlistentry>
2484+ <term><varname>LDM_SOCKET</varname></term>
2485+ <listitem>
2486+ <para>
2487+ The path to the ssh control socket that LDM has open
2488+ for communication with the server.
2489+ </para>
2490+ </listitem>
2491+ </varlistentry>
2492+ <varlistentry>
2493+ <term><varname>LDM_SERVER</varname></term>
2494+ <listitem>
2495+ <para>
2496+ The current server that LDM is connected to.
2497+ </para>
2498+ </listitem>
2499+ </varlistentry>
2500+ <varlistentry>
2501+ <term><varname>LDMINFO_IPADDR</varname></term>
2502+ <listitem>
2503+ <para>
2504+ The IP address of the thin client.
2505+ </para>
2506+ </listitem>
2507+ </varlistentry>
2508+ </variablelist>
2509+ <para>
2510+ You can use these variables to create scripts that customize
2511+ behaviors at login time. For instance, lets say you were
2512+ running the GNOME desktop environment, and wanted to force your
2513+ users to have blank-only mode for their screen savers, to save
2514+ network bandwidth.
2515+ </para>
2516+ <para>
2517+ Since the script is actually running <emphasis>on the thin
2518+ client itself</emphasis>, you want this script to set this
2519+ up on the server, where the Gnome session is running. That's
2520+ where you can make use of the <varname>LDM_SOCKET</varname> and
2521+ <varname>LDM_SERVER</varname> environment variables to run an
2522+ <command>ssh</command> command on the server, using the control
2523+ socket that LDM has set up. Here's an example script. You
2524+ could install this into
2525+ <filename>$CHROOT/usr/share/ldm/rc.d/X01-set-blankonly</filename>:
2526+ </para>
2527+ <screen>
2528+#
2529+# sourced with .
2530+#
2531+# Script to automatically switch gnome screensaver to blank
2532+# only mode
2533+#
2534+ssh -S ${LDM_SOCKET} ${LDM_SERVER} "/usr/bin/gconftool-2 --set --type string /apps/gnome-screensaver/mode blank-only"
2535+ </screen>
2536+ <para>
2537+ Using this mechanism, it's easy to customize your LTSP setup to
2538+ your needs.
2539+ </para>
2540+ </sect1>
2541+ <sect1>
2542+ <title>LDM lts.conf parameters</title>
2543+ <xi:include
2544+ href='lts.conf.xml'
2545+ xpointer='lts-conf-ldm-list'
2546+ xmlns:xi='http://www.w3.org/2001/XInclude' />
2547+ </sect1>
2548+ <sect1>
2549+ <title>Multiple server setup</title>
2550+ <para>
2551+ A multiple server setup is useful for larger thin client
2552+ networks. Instead of using one big server, it makes it
2553+ possible to use smaller servers, and dispatch users on them.
2554+ You can adjust computing resources as the demand grows simply
2555+ by adding a new server. To make sure that every server behaves
2556+ the same from the users point of view, new services and
2557+ configurations that are required will be discussed. In
2558+ addition, some configurations specific to thin clients will be
2559+ presented.
2560+ </para>
2561+ </sect1>
2562+ </chapter>
2563+ <chapter id='infrastructure'>
2564+ <title>Infrastructure setup</title>
2565+ <sect1>
2566+ <title>Network topology</title>
2567+ <para>
2568+ The network topology is the same as a standalone server
2569+ setup, except that there are more than one server on the thin
2570+ client LAN.
2571+ </para>
2572+ <para>
2573+ You will need to select one server to behave as the primary
2574+ server. This server will be used to run additional services,
2575+ hold users files, and network boot thin clients.
2576+ </para>
2577+ <para>
2578+ Secondary servers will be used only to run desktop sessions.
2579+ They are simpler, and will be configured to use the central
2580+ services from the primary server.
2581+ </para>
2582+ </sect1>
2583+ <sect1>
2584+ <title>Common authentication</title>
2585+ <para>
2586+ A user should be able to start a session with the same login
2587+ and password, no matter which server it connects to. For this
2588+ purpose, a central authentication mechanism must be used.
2589+ There are many possibilities offered. Here are the major
2590+ technologies:
2591+ </para>
2592+ <orderedlist>
2593+ <listitem>
2594+ <para>
2595+ LDAP authentication: On the master server, setup an
2596+ OpenLDAP server. Configure each servers to use this
2597+ LDAP server as the authentication base.
2598+ </para>
2599+ </listitem>
2600+ <listitem>
2601+ <para>
2602+ NIS authentication: On the master server, setup a
2603+ NIS server. Configure each server to use this NIS
2604+ server for the authentication.
2605+ </para>
2606+ </listitem>
2607+ <listitem>
2608+ <para>
2609+ Winbind authentication: Useful if you already have
2610+ an Active Directory server.
2611+ </para>
2612+ </listitem>
2613+ </orderedlist>
2614+ <para>
2615+ For detailed instructions, see their respective manuals.</para>
2616+ </sect1>
2617+ <sect1>
2618+ <title>Shared home directories</title>
2619+ <para>
2620+ Shared home directories are easy to setup using an NFS server
2621+ on eithe the primary LTSP server, or even better, a standalone
2622+ NFS server. Other more modern, faster (and consequently more
2623+ expensive) options include a SAN, and maybe even moving to a
2624+ fibre-channel raid SAN. Consult your distribution's
2625+ documentation for details and suggestions for setting up an NFS
2626+ server.
2627+ </para>
2628+ </sect1>
2629+ <sect1>
2630+ <title>Shared printers</title>
2631+ <para>
2632+ For printers to be accessible on each server, the cups
2633+ server must be configured to share printers. Refer to the CUPS
2634+ manual for your distribution for detailed setup instructions.
2635+ </para>
2636+ <para>
2637+ Note that an LTSP thin client acting as a print server
2638+ resembles a JetDirect print server.
2639+ </para>
2640+ </sect1>
2641+ <sect1>
2642+ <title>Managing the SSH known hosts file</title>
2643+ <para>
2644+ For security reasons, a thin client won't connect to an
2645+ untrusted server. You must add the keys of secondary servers
2646+ inside the client root on the primary server. To do this,
2647+ first export the key file of the secondary server using LTSP's
2648+ tools. As root, run:
2649+ </para>
2650+ <screen>
2651+ltsp-update-sshkeys --export ssh_known_hosts.myhostname
2652+ </screen>
2653+ <para>
2654+ Then, copy the file
2655+ <filename>ssh_known_hosts.myhostnam</filename>
2656+ to the primary server, in the directory
2657+ <filename>/etc/ltsp/</filename>
2658+ and run <command>ltsp-update-sshkeys</command> on the primary
2659+ server. Then, thin clients will trust the freshly added
2660+ server, and will be able to connect to it.
2661+ </para>
2662+ <para>
2663+ If a secondary server changes it's IP address, then this
2664+ procedure must be repeated.
2665+ </para>
2666+ </sect1>
2667+ <sect1>
2668+ <!-- FIXME: this should be generalized a bit, but since
2669+ iptables SHOULD be available on ALL distros, it can probably
2670+ stay.
2671+ -->
2672+ <title>Setting Network Forwarding or Masquerading</title>
2673+ <para>
2674+ The purpose of IP Masquerading is to allow machines with
2675+ private, non-routable IP addresses on your network to access
2676+ the Internet through the machine doing the masquerading.
2677+ Traffic from your private network destined for the Internet
2678+ must be manipulated for replies to be routable back to the
2679+ machine that made the request. To do this, the kernel must
2680+ modify the <emphasis>source</emphasis> IP address of each
2681+ packet so that replies will be routed back to it, rather than
2682+ to the private IP address that made the request, which is
2683+ impossible over the Internet. Linux uses
2684+ <emphasis>Connection Tracking</emphasis>
2685+ (conntrack) to keep track of which connections belong to which
2686+ machines and reroute each return packet accordingly. Traffic
2687+ leaving your private network is thus "masqueraded" as having
2688+ originated from your gateway machine. This process is referred
2689+ to in Microsoft documentation as Internet Connection Sharing.
2690+ </para>
2691+ <para>
2692+ IP Forwarding with IP Tables
2693+ </para>
2694+ <orderedlist>
2695+ <listitem>
2696+ <para>
2697+ to enable IPv4 packet forwarding by editing
2698+ /etc/sysctl.conf and uncomment the following
2699+ line:</para>
2700+ <screen>net.ipv4.ip_forward=1</screen>
2701+ </listitem>
2702+ <listitem>
2703+ <para>
2704+ If you wish to enable IPv6 forwarding also
2705+ uncomment:
2706+ </para>
2707+ <screen>net.ipv6.conf.default.forwarding=1</screen>
2708+ </listitem>
2709+ <listitem>
2710+ <para>
2711+ Next, execute the sysctl command to enable the new
2712+ settings in the configuration file:
2713+ </para>
2714+ <screen>sudo sysctl -p</screen>
2715+ </listitem>
2716+ <listitem>
2717+ <para>
2718+ IP Masquerading can now be accomplished with a
2719+ single iptables rule, which may differ slightly based
2720+ on your network configuration:
2721+ </para>
2722+ <screen>sudo iptables -t nat -A POSTROUTING -s 192.168.0.0/16 -o eth0 -j MASQUERADE</screen>
2723+ <para>
2724+ The above command assumes that your private address
2725+ space is 192.168.0.0/16 and that your Internet-facing
2726+ device is eth0. The syntax is broken down as follows:
2727+ </para>
2728+ </listitem>
2729+ </orderedlist>
2730+ </sect1>
2731+ </chapter>
2732+ <chapter id='session-dispatching'>
2733+ <title>Session dispatching</title>
2734+ <sect1>
2735+ <title>Define the server list</title>
2736+ <para>
2737+ LDM is a login manager for thin clients. Users can select a
2738+ server from the available ones in the host selection dialogue
2739+ box.
2740+ </para>
2741+ <para>
2742+ The displayed server list is defined by the
2743+ <varname>LDM_SERVER</varname>
2744+ parameter. This parameter accepts a list of server IP address
2745+ or host names, separated by space. If you use host names, then
2746+ your DNS resolution must work on the thin client. If defined
2747+ in the &lts.conf; file, the list order will
2748+ be static, and the first server in the list will be selected
2749+ by default.
2750+ </para>
2751+ <para>
2752+ You can also compute a new order for the server list, by
2753+ creating the script
2754+ <command>/opt/ltsp/&lt;arch&gt;/usr/share/ltsp/get_hosts</command>
2755+ . The parameter
2756+ <varname>LDM_SERVER</varname>
2757+ overrides the
2758+ script. In consequence, this parameter must not be defined if
2759+ the <command>get_hosts</command> is going to be used. The
2760+ <command>get_hosts</command>
2761+ script writes on the standard output each server IP address or
2762+ host names, in the chosen order.
2763+ </para>
2764+ </sect1>
2765+ <sect1>
2766+ <title>Dispatching method</title>
2767+ <para>
2768+ You can change this behaviour by using a script to rearrange
2769+ the list. The simplest way to do it is by randomizing the
2770+ list. First, define a custom variable in the file
2771+ &lts.conf;
2772+ , for example <varname>MY_SERVER_LIST</varname>, that will
2773+ contain the list of servers, the same way as
2774+ <varname>LDM_SERVER</varname>
2775+ Then, put the following script in
2776+ <command>/opt/ltsp/&lt;arch&gt;/usr/share/ltsp/get_hosts</command>
2777+ </para>
2778+ <screen>
2779+#!/bin/bash
2780+# Randomize the server list contained in MY_SERVER_LIST parameter
2781+TMP_LIST=""
2782+SHUFFLED_LIST=""
2783+
2784+for i in $MY_SERVER_LIST; do
2785+ rank=$RANDOM
2786+ let "rank %= 100"
2787+ TMP_LIST="$TMP_LIST\n${rank}_$i"
2788+done
2789+
2790+TMP_LIST=$(echo -e $TMP_LIST | sort)
2791+for i in $TMP_LIST; do
2792+ SHUFFLED_LIST="$SHUFFLED_LIST $(echo $i | cut -d_ -f2)"
2793+done
2794+echo $SHUFFLED_LIST
2795+ </screen>
2796+ <para>
2797+ More advanced load balancing algorithms can be written. For
2798+ example, load balancing can be done by querying ldminfod for
2799+ the server rating. By querying ldminfod, you can get the
2800+ current rating state of the server. This rating goes from 0 to
2801+ 100, higher is better. Here is an example of such a query:
2802+ <screen>nc localhost 9571 | grep rating | cut -d: -f2</screen>
2803+ </para>
2804+ </sect1>
2805+ <sect1>
2806+ <title>Network Swap</title>
2807+ <para>
2808+ Just like on a full fledged workstation, it helps to have
2809+ swap defined for your thin client. "Swap" is an area of disk
2810+ space set aside to allow you to transfer information out of
2811+ ram, and temporarily store it on a hard drive until it's
2812+ needed again. It makes the workstation look like it has more
2813+ memory than it actually does. For instance, if your
2814+ workstation has 64 Megabytes of ram and you configure 64
2815+ Megabytes of swap, it's theoretically possible to load a 128
2816+ Megabyte program.
2817+ </para>
2818+ <para>
2819+ We say, "theoretically", because in practice, you want to
2820+ avoid swapping as much as possible. A hard drive is several
2821+ orders of magnitude slower than ram, and, of course, on a thin
2822+ client, you don't even have a hard drive! You have to first
2823+ push the data through the network to the server's hard drive,
2824+ thus making your swapping even slower. In practice, it's best
2825+ to make sure you have enough ram in your thin client to handle
2826+ all your average memory needs.
2827+ </para>
2828+ <para>
2829+ However, sometimes that's not possible. Sometimes, you're
2830+ re-using old hardware, or you've simply got a program that
2831+ isn't normally used, but does consume a lot of ram on the thin
2832+ client when it does. Fortunately, LTSP supports swapping over
2833+ the network via NBD, or Network Block Devices. We include a
2834+ small shell script called nbdswapd, which is started via
2835+ inetd. It handles creating the swap file, and setting up the
2836+ swapping, and removing the swap file when it's no longer
2837+ needed, after the terminal shuts down.
2838+ </para>
2839+ <para>
2840+ By default, swap files are 64 Megabytes in size. This was
2841+ chosen to give your workstation a little extra ram, but not
2842+ use up too much disk space. If you get some random odd
2843+ behaviour, such as Firefox crashing when viewing web pages
2844+ with a lot of large pictures, you may want to try increasing
2845+ the size of the swap files. You can do so by creating a file
2846+ in the directory <filename>/etc/ltsp</filename> on the LTSP
2847+ server, called <filename>nbdswapd.conf</filename>. In it, you
2848+ can set the SIZE variable to the number of Megabytes you wish
2849+ the file to be sized to. For instance, to create 128 Megabyte
2850+ files, you'll want: SIZE=128 in the <filename>nbdswapd.conf</filename> file.
2851+ </para>
2852+ <para>
2853+ Please note that this is a global setting for all swap files.
2854+ If your server has 40 thin clients, each using 128 Megs of
2855+ memory, you'll need 128 * 40 = 5120, or a little over 5
2856+ Gigabytes of space in your <filename>/tmp</filename>
2857+ directory, where the swap files are stored.
2858+ </para>
2859+ </sect1>
2860+ <sect1>
2861+ <!-- FIXME: Beginning to get too distro specific, and if people
2862+ want us to move to DNSMASQ, then this all changes anyway. Try to
2863+ generalize a bit more.
2864+ -->
2865+ <title>Managing DHCP</title>
2866+ <para>
2867+ DHCP stands for Dynamic Host Configuration Protocol and is the
2868+ very first thing your thin client uses to obtain an IP address
2869+ from the network, in order to allow it to start booting. In
2870+ LTSP, the dhcpd file is located in <filename>/etc/ltsp</filename>.
2871+ Any changes you want to make to booting behaviour should be made there.
2872+ </para>
2873+ <para>
2874+ By default, LTSP ships a <filename>dhcpd.conf</filename> that
2875+ serves thin clients in a dynamic range (i.e. it will hand out
2876+ ip addresses to anyone who asks for them) from 192.168.0.20 to
2877+ 192.168.0.250. The default dhcpd.conf file looks like:
2878+ </para>
2879+ <screen>
2880+#
2881+# Default LTSP dhcpd.conf config file.
2882+#
2883+
2884+authoritative;
2885+
2886+subnet 192.168.0.0 netmask 255.255.255.0 {
2887+ range 192.168.0.20 192.168.0.250;
2888+ option domain-name "example.com";
2889+ option domain-name-servers 192.168.0.1;
2890+ option broadcast-address 192.168.0.255;
2891+ option routers 192.168.0.1;
2892+# next-server 192.168.0.1;
2893+# get-lease-hostnames true;
2894+ option subnet-mask 255.255.255.0;
2895+ option root-path "/opt/ltsp/i386";
2896+ if substring( option vendor-class-identifier, 0, 9 ) = "PXEClient" {
2897+ filename "/ltsp/i386/pxelinux.0";
2898+ } else {
2899+ filename "/ltsp/i386/nbi.img";
2900+ }
2901+}
2902+ </screen>
2903+ <para>
2904+ This <filename>dhcpd.conf</filename> should handle most
2905+ situations.
2906+ </para>
2907+ <para>
2908+ By default, LTSP will detect an unused network interface and
2909+ configure it to be 192.168.0.254. LTSP's recommended single
2910+ server installation is to use a separate network interface for
2911+ the thin clients. If, however, you're not using two network
2912+ interfaces, or you already have an interface in the 192.168.0
2913+ range, then you might have to configure the thin client
2914+ interface differently, which means you may have to adjust the
2915+ <filename>dhcpd.conf</filename> accordingly.
2916+ </para>
2917+ <para>
2918+ If the network interface that you're going to connect the thin
2919+ clients to has, say, a TCP/IP address of 10.0.20.254, you'll
2920+ want to replace every occurrence of 192.168.0 with 10.0.20 in
2921+ the <filename>dhcpd.conf</filename> file.
2922+ </para>
2923+ <para>
2924+ Always remember, you'll need to re-start the dhcp server if
2925+ you make any changes. You can do this by issuing the command:
2926+ </para>
2927+ <screen>sudo invoke-rc.d dhcp3-server restart</screen>
2928+ <para>(at the command prompt.)</para>
2929+ </sect1>
2930+ </chapter>
2931+ <chapter id='static-entries-dhcp'>
2932+ <title>Adding static entries to the dhcpd.conf</title>
2933+ <para>
2934+ Sometimes, you may need to have a certain terminal boot with a
2935+ guaranteed fixed TCP/IP address every time. Say, if you're
2936+ connecting a printer to the terminal, and need to make sure the
2937+ print server can find it at a fixed address. To create a fixed
2938+ address, use a low number in the range of 2-19, or otherwise, if
2939+ you change the range statement in the <filename>dhcpd.conf</filename>.
2940+ </para>
2941+ <para>
2942+ To create a static entry, simply add the following after the
2943+ "option root-path" line:
2944+ </para>
2945+ <screen>
2946+host hostname {
2947+ hardware ethernet MA:CA:DD:RE:SS:00;
2948+ fixed-address 192.168.0.2;
2949+}
2950+ </screen>
2951+ <para>
2952+ Substitude the MAC
2953+ address for the mac address of the thin client you wish to fix the
2954+ address of. The fixed-address will be the TCP/IP address you want,
2955+ and "hostname" is the name you wish to give the host. This kind of
2956+ setup is relatively complex and the admin should have a full
2957+ understanding of how DHCP works before attempting such a setup.
2958+ For more information, check the Internet.
2959+ </para>
2960+ </chapter>
2961+ <chapter id='dhcp-loadbalance'>
2962+ <title>DHCP failover load balancing</title>
2963+ <para>
2964+ Another common method of load balancing is to use DHCP
2965+ load balancing. There's an excellent writeup on the topic at:
2966+ <ulink url="https://wiki.edubuntu.org/EdubuntuDHCPload-balancingFailover">
2967+ https://wiki.edubuntu.org/EdubuntuDHCPload-balancingFailover
2968+ </ulink>
2969+ </para>
2970+ <sect1>
2971+ <!-- FIXME: Should mention KDE's lockdown, and not go into so much
2972+ detail. Generalize a bit.
2973+ -->
2974+ <title/>
2975+ <sect2>
2976+ <title>Lockdown with Sabayon (user profile manager) and
2977+ Pessulus (lockdown editor)
2978+ </title>
2979+ <para>
2980+ A common requirement in both schools and businesses is
2981+ having the ability to lock down the desktop and provide
2982+ certain default configurations.
2983+ </para>
2984+ <para>
2985+ In LTSP, the applications you'll want to use are Sabayon
2986+ and Pessulus. You'll want to add them from the package
2987+ manager.
2988+ </para>
2989+ <para>
2990+ The Sabayon user profile editor looks like a window that
2991+ contains a smaller sized picture of your desktop. Within
2992+ this window, you can create a default layout: add icons to
2993+ panels and the desktop, lock down the panels so they can't
2994+ be modified, remove access to the command line, etc.
2995+ </para>
2996+ <para>
2997+ Once you're done, you can save your profile. You have
2998+ the option of applying your profile to either individual
2999+ users, or all users on the system. Please consult the
3000+ manual included with Sabayon for all the details.
3001+ </para>
3002+ <para>
3003+ More information is available here:</para>
3004+ <para>
3005+ <ulink url="http://live.gnome.org/PythonSabayon">
3006+ http://live.gnome.org/PythonSabayon
3007+ </ulink>
3008+ </para>
3009+ <para>
3010+ <ulink url="http://www.gnome.org/~seth/blog/sabayon">
3011+ http://www.gnome.org/~seth/blog/sabayon
3012+ </ulink>
3013+ </para>
3014+ <para>
3015+ http://www.gnome.org/projects/sabayon/</para>
3016+ </sect2>
3017+ </sect1>
3018+ <sect1>
3019+ <title>Replication of desktop profiles</title>
3020+ <para>
3021+ If you customize user's desktop, then custom desktop profiles
3022+ should be copied to every server. Gnome desktop profiles
3023+ created with Sabayon are located in
3024+ <filename>/etc/desktop-profiles</filename>
3025+ </para>
3026+ </sect1>
3027+ </chapter>
3028+ <chapter id='managing-clients'>
3029+ <!-- FIXME: Same. Too Gnome specific, and not really part of LTSP.
3030+ Should just provide a pointer to a wiki page.
3031+ -->
3032+ <title>Managing the thin client</title>
3033+ <para>
3034+ Previously, there was a program called TCM or thin client
3035+ manager, which was responsible for checking what was happening on
3036+ the various thin terminals, messaging between them, locking, or
3037+ generally offering support from a master terminal. This has now
3038+ been replaced by the use of Italc, which must be separately
3039+ installed depending on your distribution.
3040+ </para>
3041+ <sect1>
3042+ <title>Lockdown Editor</title>
3043+ <para>
3044+ By choosing a single user and right clicking on that users
3045+ name, you will open up the context menu. From here you can
3046+ choose "Lockdown", which will allow you to set options to
3047+ restrict a particular user. Clicking this menu item will
3048+ invoke the "Pessulus" program, which is the Gnome lockdown
3049+ editor. Ticking and unticking options in Pessulus will enable
3050+ and disable certain functions for that particular user. There
3051+ is a padlock next to each option in Pessulus. Ticking this
3052+ will make the option unchangeable by the user. This is called
3053+ a mandatory setting. For further help with Pessulus, please
3054+ refer to the Pessulus documentation.
3055+ </para>
3056+ </sect1>
3057+ </chapter>
3058+ <chapter id='updating-chroot'>
3059+ <!-- FIXME: Distro specific. Mention using a package manager to
3060+ update, and point them to a wiki page with more specific information.
3061+ -->
3062+ <title>Updating your LTSP chroot</title>
3063+ <para>
3064+ At some point in the future, updates will become available for
3065+ your LTSP server. You must remember that although you may have
3066+ applied all the updates to the server itself, as in the
3067+ instructions....HERE it is likely that the LTSP chroot will also
3068+ need updating. To do this you must open up a terminal and use the
3069+ following commands.
3070+ </para>
3071+ <para>
3072+ First make sure the Client environment has the same Package
3073+ lists as the Server, to achieve that, you will copy the
3074+ /etc/apt/sources.list (on Debian and Ubuntu) or the
3075+ /etc/yum.repos.d/fedora.repo file from the Server to the Client
3076+ environment.
3077+ </para>
3078+ <para>
3079+ Now issue the command below.</para>
3080+ <screen>sudo chroot /opt/ltsp/&lt;arch&gt;</screen>
3081+ <para>(replace &lt;arch&gt; with the architecture
3082+ you are working with.)
3083+ </para>
3084+ <para>
3085+ This will change your root directory to be the LTSP clients root
3086+ directory. In essence, anything you now do inside here, will be
3087+ applied to the LTSP clients root. This is a separate small set of
3088+ files that are used to boot the clients into a usable, and enable
3089+ them to contact the LTSP server. Once inside this shell, we must
3090+ type the following command to obtain the latest list of packages
3091+ from the apt/yum servers.
3092+ </para>
3093+ <screen>apt-get get update</screen>
3094+ <para>
3095+ on Debian and Ubuntu
3096+ </para>
3097+ <para>
3098+ You need to mount <filename>/proc</filename> in the chroot before beginning, as some of
3099+ the packages you install may need resources in <filename>/proc</filename> to install correctly.
3100+ </para>
3101+ <screen>mount -t proc proc /proc</screen>
3102+ <para>
3103+ To be sure no deamons are started do the following:</para>
3104+ <screen>export LTSP_HANDLE_DAEMONS=false</screen>
3105+ <para>
3106+ Once this has completed you will have to upgrade the software in
3107+ the chroot by running the following command:
3108+ </para>
3109+ <screen>apt-get upgrade</screen>
3110+ <para>(on Debian and Ubuntu)</para>
3111+ <para>
3112+ or
3113+ </para>
3114+ <screen>yum update</screen>
3115+ <para>(on Fedora)</para>
3116+ <para>
3117+ Just in case <filename>/proc</filename> is still mounted when you exit the chroot,
3118+ unmount it first by doing:</para>
3119+ <screen>umount /proc</screen>
3120+
3121+ <para>
3122+ Once you're done, you must leave the chroot by either typing
3123+ <emphasis>exit</emphasis>
3124+ or by using the key combination Ctrl+D. This will return you to
3125+ the root of the server.
3126+ </para>
3127+ <para>
3128+ If your kernel has been upgraded you must run the LTSP kernel
3129+ upgrade script, to ensure that your LTSP chroot uses the latest
3130+ version. This is performed by running the command below:
3131+ </para>
3132+ <screen>ltsp-update-kernels</screen>
3133+ <para>
3134+ All of your clients will now use the latest kernel upon their
3135+ next reboot.
3136+ </para>
3137+ <para>
3138+ Finally, you must remember to rebuild the NBD boot image from
3139+ your chroot with the following command:
3140+ </para>
3141+ <screen>ltsp-update-image</screen>
3142+ <para>(add architecture using -arch= addition)</para>
3143+ <para>
3144+ Be advised that this may take a few minutes, depending on the
3145+ speed of your server.
3146+ </para>
3147+ </chapter>
3148+ <chapter id='changing-server-ip'>
3149+ <title>Changing the IP of your LTSP server</title>
3150+ <para>
3151+ At some point in time, it may become necessary to change the IP
3152+ address of your LTSP server. Normally this does not present an
3153+ issue, but LTSP servers and clients communicate over and encrypted
3154+ channel and require all SSL certificates to be updated. Without
3155+ this update, <emphasis>no LTSP clients will be able to log in</emphasis>.
3156+ This is done by simply opening a terminal and running the following command.
3157+ </para>
3158+ <screen>
3159+sudo ltsp-update-sshkeys
3160+sudo ltsp-update-image
3161+ </screen>
3162+ </chapter>
3163+ <chapter id='appendix'>
3164+ <title>Appendix I</title>
3165+ <para>
3166+ Here you can find some solutions to common questions and
3167+ problems.
3168+ </para>
3169+ <sect1>
3170+ <title>Using NFS instead of NBD</title>
3171+ <para>
3172+ Using NBD instead of NFS has several advantages:</para>
3173+ <orderedlist>
3174+ <listitem>
3175+ <para>
3176+ Using a squashfs image we can now merge that
3177+ together in a unionfs to get writeable access which is
3178+ a lot faster during bootup.
3179+ </para>
3180+ </listitem>
3181+ <listitem>
3182+ <para>
3183+ A squashed root filesystem uses less network
3184+ bandwidth.
3185+ </para>
3186+ </listitem>
3187+ <listitem>
3188+ <para>
3189+ Many users and administrators have asked us to
3190+ eliminate NFS, for reasons of site policy. Since the
3191+ squashed image is now served out by nbd-server, which
3192+ is an entirely userspace program, and is started as
3193+ the user nobody, this should help to eliminate
3194+ concerns over NFS shares.
3195+ </para>
3196+ </listitem>
3197+ </orderedlist>
3198+ <para>
3199+ However, some people still want to use NFS. Fortunately,
3200+ it's easy to switch back to NFS, if it's so desired:
3201+ </para>
3202+ <orderedlist>
3203+ <listitem>
3204+ <para>
3205+ On the server, use the chroot command to maintain
3206+ the LTSP chroot:</para>
3207+ <screen>sudo chroot /opt/ltsp/&lt;arch&gt;</screen>
3208+ </listitem>
3209+ <listitem>
3210+ <para>
3211+ Now edit /etc/default/ltsp-client-setup and change
3212+ the value of the root_write_method variable to use
3213+ bind mounts instead of unionfs, it should look like
3214+ this afterwards:
3215+ </para>
3216+ <screen>root_write_method="bind_mounts"</screen>
3217+ </listitem>
3218+ <listitem>
3219+ <para>
3220+ Next, create the file
3221+ <filename>/etc/initramfs-tools/conf.d/ltsp</filename> and add the following
3222+ line (set the value of the BOOT variable to nfs):
3223+ </para>
3224+ <screen>BOOT=nfs</screen>
3225+ </listitem>
3226+ <listitem>
3227+ <para>
3228+ Regenerate the initramfs: </para>
3229+ <screen>update-initramfs -u</screen>
3230+ </listitem>
3231+ <listitem>
3232+ <para>
3233+ Hit CTRL-D to exit the chroot now. Make sure LTSP
3234+ uses the new initramfs to boot:
3235+ </para>
3236+ <screen>sudo ltsp-update-kernels</screen>
3237+ </listitem>
3238+ </orderedlist>
3239+ </sect1>
3240+ <sect1>
3241+ <title>Enabling dual monitors</title>
3242+ <para>
3243+ First, I am going to start with a couple assumptions:</para>
3244+ <itemizedlist>
3245+ <listitem>
3246+ <para>
3247+ I will assume that you are operating thin clients
3248+ with an NBD file system in this write-up.
3249+ </para>
3250+ </listitem>
3251+ <listitem>
3252+ <para>
3253+ I will assume that you are running Ubuntu 8.04.1</para>
3254+ </listitem>
3255+ <listitem>
3256+ <para>
3257+ I will assume that you are running LTSP 5</para>
3258+ </listitem>
3259+ <listitem>
3260+ <para>
3261+ I will assume that you are replacing a running
3262+ image that has been properly tested, and is working.
3263+ </para>
3264+ </listitem>
3265+ </itemizedlist>
3266+ <para>
3267+ Create a
3268+ new image to ensure your configuration is congruent with my
3269+ successfully tested configuration.
3270+ </para>
3271+ <screen>
3272+sudo ltsp-build-client --copy-sourceslist --arch i386
3273+ </screen>
3274+ <para>
3275+ (note the --arch i386 command is required for my system
3276+ because it's running an amd64 kernel. It may not be required
3277+ for individuals running a 32-bit kernel)
3278+ </para>
3279+ <para>
3280+ Download the pertinent VIA unichrome driver for your chipset
3281+ from this web site: <ulink url="http://linux.via.com.tw/support/downloadFiles.action">
3282+ http://linux.via.com.tw/support/downloadFiles.action
3283+ </ulink>
3284+ Be sure to select the proper OS as well. The installation
3285+ script is set up specifically for the directory structure of
3286+ each OS, and will error out if the wrong OS release is
3287+ installed. Next we need to move the downloaded file to the
3288+ image directory
3289+ </para>
3290+ <screen>
3291+cp /home/&lt;username/Desktop/chrome9.83-242-sl10.1.tar.gz /opt/ltsp/i386
3292+ </screen>
3293+ <para>
3294+ After that, we need to chroot to the same image directory.</para>
3295+ <screen>
3296+sudo chroot /opt/ltsp/i386/
3297+ </screen>
3298+ <para>
3299+ Unpack the driver in the root directory </para>
3300+ <screen>
3301+tar -zxvf chrome9.83-242-sl10.1.tar.gz
3302+ </screen>
3303+ <para>
3304+ After unpacking, enter the directory:</para>
3305+ <screen>
3306+cd chrome9.83-242-sl10.1/
3307+ </screen>
3308+ <para>
3309+ Run the file contained inside to start the driver installation
3310+ </para>
3311+ <screen>
3312+./vinstall ..................done! Original X config file
3313+was saved as /etc/X11/xorg.conf.viabak
3314+ </screen>
3315+ <para>(The following error: "VIAERROR:The /etc/X11/xorg.conf is
3316+ missing!" Can be ignored. We will be replacing the xorg.conf
3317+ anyway, and the drivers are still installed properly.)
3318+ </para>
3319+ <para>
3320+ Next we need to put a proper xorg.conf in to the proper
3321+ directory.
3322+ </para>
3323+ <screen>
3324+gedit /etc/X11/xorg.conf
3325+ </screen>
3326+ <para>
3327+ Now paste the following in to the empty file:
3328+ </para>
3329+ <screen>
3330+Section "Module"
3331+ Load "extmod"
3332+ Load "dbe"
3333+ Load "dri"
3334+ Load "glx"
3335+ Load "freetype"
3336+ Load "type1"
3337+EndSection
3338+
3339+Section "Files"
3340+ RgbPath "/usr/X11R6/lib/X11/rgb"
3341+ FontPath "/usr/X11R6/lib/X11/fonts/misc/"
3342+ FontPath "/usr/X11R6/lib/X11/fonts/75dpi/:unscaled"
3343+ FontPath "/usr/X11R6/lib/X11/fonts/75dpi/"
3344+ FontPath "/usr/X11R6/lib/X11/fonts/Type1"
3345+ FontPath "/usr/X11R6/lib/X11/fonts/TTF"
3346+EndSection
3347+
3348+Section "ServerFlags"
3349+ Option "Dont Zoom"
3350+ Option "AllowMouseOpenFail" "Yes"
3351+ Option "BlankTime" "20"
3352+ Option "StandbyTime" "0"
3353+ Option "SuspendTime" "0"
3354+ Option "OffTime" "0"
3355+ Option "Xinerama" "on"
3356+EndSection
3357+
3358+Section "InputDevice"
3359+ Identifier "Keyboard1"
3360+ Driver "Keyboard"
3361+ Driver "keyboard"
3362+ Option "AutoRepeat" "500 30"
3363+ Option "XkbRules" "xfree86"
3364+ Option "XkbModel" "pc105"
3365+ Option "XkbLayout" "en_US,en_US"
3366+ Option "XkbOptions" "grp:alt_shift_toggle,grp_led:scroll" EndSection
3367+EndSection
3368+
3369+Section "InputDevice"
3370+ Identifier "USBMouse"
3371+ Driver "mouse"
3372+ Option "Protocol" "IMPS/2"
3373+ Option "Device" "/dev/input/mice"
3374+ Option "ZAxisMapping" "4 5"
3375+ Option "Buttons" "5"
3376+EndSection
3377+
3378+Section "InputDevice"
3379+ Identifier "Mouse1"
3380+ Driver "mouse"
3381+ Option "Protocol" "Auto"
3382+ Option "Device" "/dev/psaux"
3383+ Option "ZAxisMapping" "4 5"
3384+ Option "Buttons" "5"
3385+EndSection
3386+
3387+Section "Monitor"
3388+ Identifier "Monitor0"
3389+ HorizSync 31.5-48.5
3390+ VertRefresh 60
3391+ Option "DPMS"
3392+EndSection
3393+
3394+Section "Device"
3395+ Identifier "CN700"
3396+ Driver "via"
3397+ VideoRam 16384
3398+ Screen 0
3399+ Option "NoDDCValue" "1"
3400+ Option "Simultaneous"
3401+ Option "DPMS" "on"
3402+ BusID "PCI:1:0:0"
3403+EndSection
3404+
3405+Section "Screen"
3406+ Identifier "Screen0DVI"
3407+ Device "CN700DVI"
3408+ Monitor "Monitor0DVI"
3409+ DefaultDepth 24
3410+ Subsection "Display"
3411+ Depth 8
3412+ Modes "1280x1024"
3413+ ViewPort 0 0
3414+ EndSubsection
3415+ Subsection "Display"
3416+ Depth 16
3417+ Modes "1280x1024"
3418+ ViewPort 0 0
3419+ EndSubsection
3420+ Subsection "Display"
3421+ Depth 24
3422+ Modes "1280x1024"
3423+ ViewPort 0 0
3424+ EndSubsection
3425+EndSection
3426+
3427+Section "Monitor"
3428+ Identifier "Monitor0"
3429+ HorizSync 31.5-48.5
3430+ VertRefresh 60
3431+ Option "DPMS"
3432+EndSection
3433+
3434+Section "Device"
3435+ Identifier "CN700DVI"
3436+ Driver "via"
3437+ VideoRam 16384
3438+ Screen 1
3439+ Option "NoDDCValue" "1"
3440+ Option "Simultaneous"
3441+ Option "DPMS" "on"
3442+ BusID "PCI:1:0:0"
3443+EndSection
3444+
3445+Section "Screen"
3446+ Identifier "Screen0"
3447+ Device "CN700"
3448+ Monitor "Monitor0"
3449+ DefaultDepth 24
3450+ Subsection "Display"
3451+ Depth 8
3452+ Modes "1280x1024"
3453+ ViewPort 0 0
3454+ EndSubsection
3455+ Subsection "Display"
3456+ Depth 16
3457+ Modes "1280x1024"
3458+ ViewPort 0 0
3459+ EndSubsection
3460+ Subsection "Display"
3461+ Depth 24
3462+ Modes "1280x1024"
3463+ ViewPort 0 0
3464+ EndSubsection
3465+EndSection
3466+
3467+Section "ServerLayout"
3468+ Identifier "Simple Layout"
3469+ Screen "Screen0" 0 0
3470+ Screen 1 "Screen0DVI" LeftOf "Screen0"
3471+ InputDevice "Mouse1" "CorePointer"
3472+ InputDevice "Keyboard1" "CoreKeyboard"
3473+ InputDevice "USBMouse" "AlwaysCore"
3474+EndSection
3475+ </screen>
3476+ <para>
3477+ <emphasis>IMPORTANT NOTE</emphasis> IN THE ABOVE SECTION PASTED INTO THE XORG.CONF, NOTICE
3478+ THAT THERE ARE RESOLUTIONS SPECIFIED PER MONITOR. PLEASE
3479+ ENSURE THAT YOU HAVE THE PROPER RESOLUTIONS FOR YOU YOUR
3480+ MONITOR ENTERED ON THOSE AREAS. Be sure to save the file as
3481+ xorg.conf and exit out of your chroot'd image. &lt;CTRL+D or
3482+ "exit"&gt; next we need to put in an addendum in the
3483+ lts.conf
3484+ </para>
3485+ <screen>
3486+gedit /var/lib/tfpboot/ltsp/i386/lts.conf
3487+ </screen>
3488+ <para>
3489+ Feel
3490+ free to comment out anything that you need to in the lts.conf.
3491+ I will include my full lts.conf as an example:
3492+ </para>
3493+ <screen>
3494+[DEFAULT]
3495+ #X_COLOR_DEPTH = "16"
3496+ #X_MODE_0 = "1680x1050"
3497+ #X_VERTREFRESH = "43-61"
3498+ #X_HORZSYNC = "28-85"
3499+ #X_OPTION_01 = "\"ForcePanel\" \"True\""
3500+ #X_OPTION_01 = "\"NoPanel\" \"true\""
3501+ #SCREEN_02 = shell
3502+ #SCREEN_07 = ldm
3503+ X_CONF = /etc/X11/xorg.conf
3504+ </screen>
3505+ <para>
3506+ Feel free to copy-paste this in it's
3507+ entirety if you want, but you will only need the last line.
3508+ After you add the X_CONF line, save &amp; exit. Now we need to
3509+ make the changes that we have made take effect in the image
3510+ </para>
3511+ <screen>
3512+# sudo ltsp-update-image --arch i386
3513+ </screen>
3514+ <para>(again, the --arch i386
3515+ will not be required for most, but I am putting it in just in
3516+ case a user has a x64 installation on their server.) That
3517+ should do it! Boot up the client and you should be good to go.
3518+ </para>
3519+ </sect1>
3520+ </chapter>
3521+</book>
3522
3523=== added file 'Makefile.in'
3524--- Makefile.in 1970-01-01 00:00:00 +0000
3525+++ Makefile.in 2017-02-24 11:47:08 +0000
3526@@ -0,0 +1,111 @@
3527+# @configure_input@
3528+
3529+# info about where we are
3530+buildir=@builddir@
3531+abs_builddir=@abs_builddir@
3532+top_builddir=@top_builddir@
3533+srcdir=@srcdir@
3534+abs_srcdir=@abs_srcdir@
3535+top_srcdir=@top_srcdir@
3536+abs_top_srcdir=@abs_top_srcdir@
3537+datarootdir=@datarootdir@
3538+
3539+# install stuff
3540+prefix=@prefix@
3541+exec_prefix=@exec_prefix@
3542+bindir=@bindir@
3543+datadir=@datadir@
3544+mandir=@mandir@
3545+includedir=@includedir@
3546+infodir=@infodir@
3547+libdir=@libdir@
3548+libexecdir=@libexecdir@
3549+localstatedir=@localstatedir@
3550+oldincludedir=@oldincludedir@
3551+sbindir=@sbindir@
3552+sharedstatedir=@sharedstatedir@
3553+sysconfdir=@sysconfdir@
3554+
3555+PDF_CMD=@PDF_CMD@
3556+XMLTO_CMD=@XMLTO_CMD@
3557+PDF_CMD_OPTS=-P latex.class.options=letterpaper,11pt,twoside,openright
3558+XMLTO_CMD_OPTS=
3559+INSTALL=@INSTALL@
3560+INSTALL_DATA=$(INSTALL) -D -m 0644
3561+INSTALL_DIR=$(INSTALL) -d
3562+
3563+# for pkgwrite
3564+DESTDIR=
3565+MANDIR=@mandir@
3566+DATADIR=@datadir@
3567+
3568+##########
3569+# Targets
3570+##########
3571+MANUALS=LTSPManual
3572+MANPAGES=lts.conf
3573+
3574+##########
3575+# Sources
3576+##########
3577+LTSPManual_SRC=LTSPManual.xml
3578+MAN5=lts.conf.5 # config files - refsects in docbook
3579+MAN8= # system commands
3580+
3581+# man pages aren't working yet
3582+all: pdfs html man
3583+
3584+#########################################
3585+# Do Not Edit Below This Line:
3586+# (unless you know what you're doing...)
3587+#########################################
3588+.SECONDEXPANSION:
3589+
3590+pdfs: $(addsuffix .pdf, $(MANUALS))
3591+html: $(addsuffix .html, $(MANUALS))
3592+# txt: $(addsuffix .txt, $(MANUALS))
3593+
3594+# man pages
3595+man: $(MAN5) $(MAN8)
3596+
3597+%.pdf: $$($$*_SRC)
3598+ @echo "building $@...."
3599+ @$(PDF_CMD) $(PDF_CMD_OPTS) ${@:.pdf=.xml}
3600+
3601+%.html: $$($$*_SRC)
3602+ @echo "Building $@...."
3603+ @$(XMLTO_CMD) html-nochunks $(XML_CMD_OPTS) $(@:.html=.xml)
3604+
3605+$(MAN5) $(MAN8): $(MAN5:.5=.xml) $(MAN8:.8=.xml)
3606+ @echo "building man pages"
3607+ @echo "$(addsuffix .xml, $(MANPAGES))" | xargs -n1 $(XMLTO_CMD) man $(DOC_CMD_OPTS)
3608+
3609+# %.txt: $$($$*_SRC)
3610+# @echo "building $@...."
3611+# @$(XMLTO_CMD) txt $(XMLTO_CMD_OPTS) $(@:.txt=.xml)
3612+
3613+none:
3614+
3615+install: all
3616+ $(INSTALL_DIR) $(DESTDIR)$(MANDIR)/man5
3617+ $(INSTALL_DATA) $(MAN5) $(DESTDIR)$(MANDIR)/man5/
3618+ $(INSTALL_DIR) $(DESTDIR)$(datadir)/doc/ltsp
3619+ $(INSTALL_DATA) *.pdf $(DESTDIR)$(datadir)/doc/ltsp/.
3620+ $(INSTALL_DATA) *.html $(DESTDIR)$(datadir)/doc/ltsp/
3621+ $(INSTALL_DIR) $(DESTDIR)$(datadir)/gnome/help/ltsp/C
3622+ $(INSTALL_DATA) *.xml $(DESTDIR)$(datadir)/gnome/help/ltsp/C/
3623+ $(INSTALL_DIR) $(DESTDIR)$(datadir)/omf/ltsp
3624+ $(INSTALL_DATA) *.omf $(DESTDIR)$(datadir)/omf/ltsp/
3625+
3626+clean:
3627+ @bash -c "rm -f *.{5,8,html,doc,pdf,txt,rtf,links,refs,tex,aux}"
3628+ #@bash -c "rm -f ../*.{5,8,html,doc,pdf,txt,rtf}"
3629+ @bash -c "rm -f ../*.pdf"
3630+ @bash -c "rm -rf $(MANUALS)"
3631+ @bash -c "rm -f config.log config.status"
3632+
3633+yelp:
3634+ @bash -c "yelp file:///`pwd`/LTSPManual.xml"
3635+
3636+distclean: clean
3637+ @bash -c "rm -rf autom4te.cache Makefile config.status config.log"
3638
3639=== added file 'config.guess'
3640--- config.guess 1970-01-01 00:00:00 +0000
3641+++ config.guess 2017-02-24 11:47:08 +0000
3642@@ -0,0 +1,1465 @@
3643+#! /bin/sh
3644+# Attempt to guess a canonical system name.
3645+# Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
3646+# 2000, 2001, 2002, 2003, 2004, 2005 Free Software Foundation, Inc.
3647+
3648+timestamp='2005-04-22'
3649+
3650+# This file is free software; you can redistribute it and/or modify it
3651+# under the terms of the GNU General Public License as published by
3652+# the Free Software Foundation; either version 2 of the License, or
3653+# (at your option) any later version.
3654+#
3655+# This program is distributed in the hope that it will be useful, but
3656+# WITHOUT ANY WARRANTY; without even the implied warranty of
3657+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
3658+# General Public License for more details.
3659+#
3660+# You should have received a copy of the GNU General Public License
3661+# along with this program; if not, write to the Free Software
3662+# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
3663+#
3664+# As a special exception to the GNU General Public License, if you
3665+# distribute this file as part of a program that contains a
3666+# configuration script generated by Autoconf, you may include it under
3667+# the same distribution terms that you use for the rest of that program.
3668+
3669+# Originally written by Per Bothner <per@bothner.com>.
3670+# Please send patches to <config-patches@gnu.org>. Submit a context
3671+# diff and a properly formatted ChangeLog entry.
3672+#
3673+# This script attempts to guess a canonical system name similar to
3674+# config.sub. If it succeeds, it prints the system name on stdout, and
3675+# exits with 0. Otherwise, it exits with 1.
3676+#
3677+# The plan is that this can be called by configure scripts if you
3678+# don't specify an explicit build system type.
3679+
3680+me=`echo "$0" | sed -e 's,.*/,,'`
3681+
3682+usage="\
3683+Usage: $0 [OPTION]
3684+
3685+Output the configuration name of the system \`$me' is run on.
3686+
3687+Operation modes:
3688+ -h, --help print this help, then exit
3689+ -t, --time-stamp print date of last modification, then exit
3690+ -v, --version print version number, then exit
3691+
3692+Report bugs and patches to <config-patches@gnu.org>."
3693+
3694+version="\
3695+GNU config.guess ($timestamp)
3696+
3697+Originally written by Per Bothner.
3698+Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005
3699+Free Software Foundation, Inc.
3700+
3701+This is free software; see the source for copying conditions. There is NO
3702+warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE."
3703+
3704+help="
3705+Try \`$me --help' for more information."
3706+
3707+# Parse command line
3708+while test $# -gt 0 ; do
3709+ case $1 in
3710+ --time-stamp | --time* | -t )
3711+ echo "$timestamp" ; exit 0 ;;
3712+ --version | -v )
3713+ echo "$version" ; exit 0 ;;
3714+ --help | --h* | -h )
3715+ echo "$usage"; exit 0 ;;
3716+ -- ) # Stop option processing
3717+ shift; break ;;
3718+ - ) # Use stdin as input.
3719+ break ;;
3720+ -* )
3721+ echo "$me: invalid option $1$help" >&2
3722+ exit 1 ;;
3723+ * )
3724+ break ;;
3725+ esac
3726+done
3727+
3728+if test $# != 0; then
3729+ echo "$me: too many arguments$help" >&2
3730+ exit 1
3731+fi
3732+
3733+trap 'exit 1' 1 2 15
3734+
3735+# CC_FOR_BUILD -- compiler used by this script. Note that the use of a
3736+# compiler to aid in system detection is discouraged as it requires
3737+# temporary files to be created and, as you can see below, it is a
3738+# headache to deal with in a portable fashion.
3739+
3740+# Historically, `CC_FOR_BUILD' used to be named `HOST_CC'. We still
3741+# use `HOST_CC' if defined, but it is deprecated.
3742+
3743+# Portable tmp directory creation inspired by the Autoconf team.
3744+
3745+set_cc_for_build='
3746+trap "exitcode=\$?; (rm -f \$tmpfiles 2>/dev/null; rmdir \$tmp 2>/dev/null) && exit \$exitcode" 0 ;
3747+trap "rm -f \$tmpfiles 2>/dev/null; rmdir \$tmp 2>/dev/null; exit 1" 1 2 13 15 ;
3748+: ${TMPDIR=/tmp} ;
3749+ { tmp=`(umask 077 && mktemp -d -q "$TMPDIR/cgXXXXXX") 2>/dev/null` && test -n "$tmp" && test -d "$tmp" ; } ||
3750+ { test -n "$RANDOM" && tmp=$TMPDIR/cg$$-$RANDOM && (umask 077 && mkdir $tmp) ; } ||
3751+ { tmp=$TMPDIR/cg-$$ && (umask 077 && mkdir $tmp) && echo "Warning: creating insecure temp directory" >&2 ; } ||
3752+ { echo "$me: cannot create a temporary directory in $TMPDIR" >&2 ; exit 1 ; } ;
3753+dummy=$tmp/dummy ;
3754+tmpfiles="$dummy.c $dummy.o $dummy.rel $dummy" ;
3755+case $CC_FOR_BUILD,$HOST_CC,$CC in
3756+ ,,) echo "int x;" > $dummy.c ;
3757+ for c in cc gcc c89 c99 ; do
3758+ if ($c -c -o $dummy.o $dummy.c) >/dev/null 2>&1 ; then
3759+ CC_FOR_BUILD="$c"; break ;
3760+ fi ;
3761+ done ;
3762+ if test x"$CC_FOR_BUILD" = x ; then
3763+ CC_FOR_BUILD=no_compiler_found ;
3764+ fi
3765+ ;;
3766+ ,,*) CC_FOR_BUILD=$CC ;;
3767+ ,*,*) CC_FOR_BUILD=$HOST_CC ;;
3768+esac ;'
3769+
3770+# This is needed to find uname on a Pyramid OSx when run in the BSD universe.
3771+# (ghazi@noc.rutgers.edu 1994-08-24)
3772+if (test -f /.attbin/uname) >/dev/null 2>&1 ; then
3773+ PATH=$PATH:/.attbin ; export PATH
3774+fi
3775+
3776+UNAME_MACHINE=`(uname -m) 2>/dev/null` || UNAME_MACHINE=unknown
3777+UNAME_RELEASE=`(uname -r) 2>/dev/null` || UNAME_RELEASE=unknown
3778+UNAME_SYSTEM=`(uname -s) 2>/dev/null` || UNAME_SYSTEM=unknown
3779+UNAME_VERSION=`(uname -v) 2>/dev/null` || UNAME_VERSION=unknown
3780+
3781+# Note: order is significant - the case branches are not exclusive.
3782+
3783+case "${UNAME_MACHINE}:${UNAME_SYSTEM}:${UNAME_RELEASE}:${UNAME_VERSION}" in
3784+ *:NetBSD:*:*)
3785+ # NetBSD (nbsd) targets should (where applicable) match one or
3786+ # more of the tupples: *-*-netbsdelf*, *-*-netbsdaout*,
3787+ # *-*-netbsdecoff* and *-*-netbsd*. For targets that recently
3788+ # switched to ELF, *-*-netbsd* would select the old
3789+ # object file format. This provides both forward
3790+ # compatibility and a consistent mechanism for selecting the
3791+ # object file format.
3792+ #
3793+ # Note: NetBSD doesn't particularly care about the vendor
3794+ # portion of the name. We always set it to "unknown".
3795+ sysctl="sysctl -n hw.machine_arch"
3796+ UNAME_MACHINE_ARCH=`(/sbin/$sysctl 2>/dev/null || \
3797+ /usr/sbin/$sysctl 2>/dev/null || echo unknown)`
3798+ case "${UNAME_MACHINE_ARCH}" in
3799+ armeb) machine=armeb-unknown ;;
3800+ arm*) machine=arm-unknown ;;
3801+ sh3el) machine=shl-unknown ;;
3802+ sh3eb) machine=sh-unknown ;;
3803+ *) machine=${UNAME_MACHINE_ARCH}-unknown ;;
3804+ esac
3805+ # The Operating System including object format, if it has switched
3806+ # to ELF recently, or will in the future.
3807+ case "${UNAME_MACHINE_ARCH}" in
3808+ arm*|i386|m68k|ns32k|sh3*|sparc|vax)
3809+ eval $set_cc_for_build
3810+ if echo __ELF__ | $CC_FOR_BUILD -E - 2>/dev/null \
3811+ | grep __ELF__ >/dev/null
3812+ then
3813+ # Once all utilities can be ECOFF (netbsdecoff) or a.out (netbsdaout).
3814+ # Return netbsd for either. FIX?
3815+ os=netbsd
3816+ else
3817+ os=netbsdelf
3818+ fi
3819+ ;;
3820+ *)
3821+ os=netbsd
3822+ ;;
3823+ esac
3824+ # The OS release
3825+ # Debian GNU/NetBSD machines have a different userland, and
3826+ # thus, need a distinct triplet. However, they do not need
3827+ # kernel version information, so it can be replaced with a
3828+ # suitable tag, in the style of linux-gnu.
3829+ case "${UNAME_VERSION}" in
3830+ Debian*)
3831+ release='-gnu'
3832+ ;;
3833+ *)
3834+ release=`echo ${UNAME_RELEASE}|sed -e 's/[-_].*/\./'`
3835+ ;;
3836+ esac
3837+ # Since CPU_TYPE-MANUFACTURER-KERNEL-OPERATING_SYSTEM:
3838+ # contains redundant information, the shorter form:
3839+ # CPU_TYPE-MANUFACTURER-OPERATING_SYSTEM is used.
3840+ echo "${machine}-${os}${release}"
3841+ exit 0 ;;
3842+ amd64:OpenBSD:*:*)
3843+ echo x86_64-unknown-openbsd${UNAME_RELEASE}
3844+ exit 0 ;;
3845+ amiga:OpenBSD:*:*)
3846+ echo m68k-unknown-openbsd${UNAME_RELEASE}
3847+ exit 0 ;;
3848+ cats:OpenBSD:*:*)
3849+ echo arm-unknown-openbsd${UNAME_RELEASE}
3850+ exit 0 ;;
3851+ hp300:OpenBSD:*:*)
3852+ echo m68k-unknown-openbsd${UNAME_RELEASE}
3853+ exit 0 ;;
3854+ luna88k:OpenBSD:*:*)
3855+ echo m88k-unknown-openbsd${UNAME_RELEASE}
3856+ exit 0 ;;
3857+ mac68k:OpenBSD:*:*)
3858+ echo m68k-unknown-openbsd${UNAME_RELEASE}
3859+ exit 0 ;;
3860+ macppc:OpenBSD:*:*)
3861+ echo powerpc-unknown-openbsd${UNAME_RELEASE}
3862+ exit 0 ;;
3863+ mvme68k:OpenBSD:*:*)
3864+ echo m68k-unknown-openbsd${UNAME_RELEASE}
3865+ exit 0 ;;
3866+ mvme88k:OpenBSD:*:*)
3867+ echo m88k-unknown-openbsd${UNAME_RELEASE}
3868+ exit 0 ;;
3869+ mvmeppc:OpenBSD:*:*)
3870+ echo powerpc-unknown-openbsd${UNAME_RELEASE}
3871+ exit 0 ;;
3872+ sgi:OpenBSD:*:*)
3873+ echo mips64-unknown-openbsd${UNAME_RELEASE}
3874+ exit 0 ;;
3875+ sun3:OpenBSD:*:*)
3876+ echo m68k-unknown-openbsd${UNAME_RELEASE}
3877+ exit 0 ;;
3878+ *:OpenBSD:*:*)
3879+ echo ${UNAME_MACHINE}-unknown-openbsd${UNAME_RELEASE}
3880+ exit 0 ;;
3881+ *:ekkoBSD:*:*)
3882+ echo ${UNAME_MACHINE}-unknown-ekkobsd${UNAME_RELEASE}
3883+ exit 0 ;;
3884+ macppc:MirBSD:*:*)
3885+ echo powerppc-unknown-mirbsd${UNAME_RELEASE}
3886+ exit 0 ;;
3887+ *:MirBSD:*:*)
3888+ echo ${UNAME_MACHINE}-unknown-mirbsd${UNAME_RELEASE}
3889+ exit 0 ;;
3890+ alpha:OSF1:*:*)
3891+ case $UNAME_RELEASE in
3892+ *4.0)
3893+ UNAME_RELEASE=`/usr/sbin/sizer -v | awk '{print $3}'`
3894+ ;;
3895+ *5.*)
3896+ UNAME_RELEASE=`/usr/sbin/sizer -v | awk '{print $4}'`
3897+ ;;
3898+ esac
3899+ # According to Compaq, /usr/sbin/psrinfo has been available on
3900+ # OSF/1 and Tru64 systems produced since 1995. I hope that
3901+ # covers most systems running today. This code pipes the CPU
3902+ # types through head -n 1, so we only detect the type of CPU 0.
3903+ ALPHA_CPU_TYPE=`/usr/sbin/psrinfo -v | sed -n -e 's/^ The alpha \(.*\) processor.*$/\1/p' | head -n 1`
3904+ case "$ALPHA_CPU_TYPE" in
3905+ "EV4 (21064)")
3906+ UNAME_MACHINE="alpha" ;;
3907+ "EV4.5 (21064)")
3908+ UNAME_MACHINE="alpha" ;;
3909+ "LCA4 (21066/21068)")
3910+ UNAME_MACHINE="alpha" ;;
3911+ "EV5 (21164)")
3912+ UNAME_MACHINE="alphaev5" ;;
3913+ "EV5.6 (21164A)")
3914+ UNAME_MACHINE="alphaev56" ;;
3915+ "EV5.6 (21164PC)")
3916+ UNAME_MACHINE="alphapca56" ;;
3917+ "EV5.7 (21164PC)")
3918+ UNAME_MACHINE="alphapca57" ;;
3919+ "EV6 (21264)")
3920+ UNAME_MACHINE="alphaev6" ;;
3921+ "EV6.7 (21264A)")
3922+ UNAME_MACHINE="alphaev67" ;;
3923+ "EV6.8CB (21264C)")
3924+ UNAME_MACHINE="alphaev68" ;;
3925+ "EV6.8AL (21264B)")
3926+ UNAME_MACHINE="alphaev68" ;;
3927+ "EV6.8CX (21264D)")
3928+ UNAME_MACHINE="alphaev68" ;;
3929+ "EV6.9A (21264/EV69A)")
3930+ UNAME_MACHINE="alphaev69" ;;
3931+ "EV7 (21364)")
3932+ UNAME_MACHINE="alphaev7" ;;
3933+ "EV7.9 (21364A)")
3934+ UNAME_MACHINE="alphaev79" ;;
3935+ esac
3936+ # A Pn.n version is a patched version.
3937+ # A Vn.n version is a released version.
3938+ # A Tn.n version is a released field test version.
3939+ # A Xn.n version is an unreleased experimental baselevel.
3940+ # 1.2 uses "1.2" for uname -r.
3941+ echo ${UNAME_MACHINE}-dec-osf`echo ${UNAME_RELEASE} | sed -e 's/^[PVTX]//' | tr 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' 'abcdefghijklmnopqrstuvwxyz'`
3942+ exit 0 ;;
3943+ Alpha\ *:Windows_NT*:*)
3944+ # How do we know it's Interix rather than the generic POSIX subsystem?
3945+ # Should we change UNAME_MACHINE based on the output of uname instead
3946+ # of the specific Alpha model?
3947+ echo alpha-pc-interix
3948+ exit 0 ;;
3949+ 21064:Windows_NT:50:3)
3950+ echo alpha-dec-winnt3.5
3951+ exit 0 ;;
3952+ Amiga*:UNIX_System_V:4.0:*)
3953+ echo m68k-unknown-sysv4
3954+ exit 0;;
3955+ *:[Aa]miga[Oo][Ss]:*:*)
3956+ echo ${UNAME_MACHINE}-unknown-amigaos
3957+ exit 0 ;;
3958+ *:[Mm]orph[Oo][Ss]:*:*)
3959+ echo ${UNAME_MACHINE}-unknown-morphos
3960+ exit 0 ;;
3961+ *:OS/390:*:*)
3962+ echo i370-ibm-openedition
3963+ exit 0 ;;
3964+ *:z/VM:*:*)
3965+ echo s390-ibm-zvmoe
3966+ exit 0 ;;
3967+ *:OS400:*:*)
3968+ echo powerpc-ibm-os400
3969+ exit 0 ;;
3970+ arm:RISC*:1.[012]*:*|arm:riscix:1.[012]*:*)
3971+ echo arm-acorn-riscix${UNAME_RELEASE}
3972+ exit 0;;
3973+ SR2?01:HI-UX/MPP:*:* | SR8000:HI-UX/MPP:*:*)
3974+ echo hppa1.1-hitachi-hiuxmpp
3975+ exit 0;;
3976+ Pyramid*:OSx*:*:* | MIS*:OSx*:*:* | MIS*:SMP_DC-OSx*:*:*)
3977+ # akee@wpdis03.wpafb.af.mil (Earle F. Ake) contributed MIS and NILE.
3978+ if test "`(/bin/universe) 2>/dev/null`" = att ; then
3979+ echo pyramid-pyramid-sysv3
3980+ else
3981+ echo pyramid-pyramid-bsd
3982+ fi
3983+ exit 0 ;;
3984+ NILE*:*:*:dcosx)
3985+ echo pyramid-pyramid-svr4
3986+ exit 0 ;;
3987+ DRS?6000:unix:4.0:6*)
3988+ echo sparc-icl-nx6
3989+ exit 0 ;;
3990+ DRS?6000:UNIX_SV:4.2*:7* | DRS?6000:isis:4.2*:7*)
3991+ case `/usr/bin/uname -p` in
3992+ sparc) echo sparc-icl-nx7 && exit 0 ;;
3993+ esac ;;
3994+ sun4H:SunOS:5.*:*)
3995+ echo sparc-hal-solaris2`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'`
3996+ exit 0 ;;
3997+ sun4*:SunOS:5.*:* | tadpole*:SunOS:5.*:*)
3998+ echo sparc-sun-solaris2`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'`
3999+ exit 0 ;;
4000+ i86pc:SunOS:5.*:*)
4001+ echo i386-pc-solaris2`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'`
4002+ exit 0 ;;
4003+ sun4*:SunOS:6*:*)
4004+ # According to config.sub, this is the proper way to canonicalize
4005+ # SunOS6. Hard to guess exactly what SunOS6 will be like, but
4006+ # it's likely to be more like Solaris than SunOS4.
4007+ echo sparc-sun-solaris3`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'`
4008+ exit 0 ;;
4009+ sun4*:SunOS:*:*)
4010+ case "`/usr/bin/arch -k`" in
4011+ Series*|S4*)
4012+ UNAME_RELEASE=`uname -v`
4013+ ;;
4014+ esac
4015+ # Japanese Language versions have a version number like `4.1.3-JL'.
4016+ echo sparc-sun-sunos`echo ${UNAME_RELEASE}|sed -e 's/-/_/'`
4017+ exit 0 ;;
4018+ sun3*:SunOS:*:*)
4019+ echo m68k-sun-sunos${UNAME_RELEASE}
4020+ exit 0 ;;
4021+ sun*:*:4.2BSD:*)
4022+ UNAME_RELEASE=`(sed 1q /etc/motd | awk '{print substr($5,1,3)}') 2>/dev/null`
4023+ test "x${UNAME_RELEASE}" = "x" && UNAME_RELEASE=3
4024+ case "`/bin/arch`" in
4025+ sun3)
4026+ echo m68k-sun-sunos${UNAME_RELEASE}
4027+ ;;
4028+ sun4)
4029+ echo sparc-sun-sunos${UNAME_RELEASE}
4030+ ;;
4031+ esac
4032+ exit 0 ;;
4033+ aushp:SunOS:*:*)
4034+ echo sparc-auspex-sunos${UNAME_RELEASE}
4035+ exit 0 ;;
4036+ # The situation for MiNT is a little confusing. The machine name
4037+ # can be virtually everything (everything which is not
4038+ # "atarist" or "atariste" at least should have a processor
4039+ # > m68000). The system name ranges from "MiNT" over "FreeMiNT"
4040+ # to the lowercase version "mint" (or "freemint"). Finally
4041+ # the system name "TOS" denotes a system which is actually not
4042+ # MiNT. But MiNT is downward compatible to TOS, so this should
4043+ # be no problem.
4044+ atarist[e]:*MiNT:*:* | atarist[e]:*mint:*:* | atarist[e]:*TOS:*:*)
4045+ echo m68k-atari-mint${UNAME_RELEASE}
4046+ exit 0 ;;
4047+ atari*:*MiNT:*:* | atari*:*mint:*:* | atarist[e]:*TOS:*:*)
4048+ echo m68k-atari-mint${UNAME_RELEASE}
4049+ exit 0 ;;
4050+ *falcon*:*MiNT:*:* | *falcon*:*mint:*:* | *falcon*:*TOS:*:*)
4051+ echo m68k-atari-mint${UNAME_RELEASE}
4052+ exit 0 ;;
4053+ milan*:*MiNT:*:* | milan*:*mint:*:* | *milan*:*TOS:*:*)
4054+ echo m68k-milan-mint${UNAME_RELEASE}
4055+ exit 0 ;;
4056+ hades*:*MiNT:*:* | hades*:*mint:*:* | *hades*:*TOS:*:*)
4057+ echo m68k-hades-mint${UNAME_RELEASE}
4058+ exit 0 ;;
4059+ *:*MiNT:*:* | *:*mint:*:* | *:*TOS:*:*)
4060+ echo m68k-unknown-mint${UNAME_RELEASE}
4061+ exit 0 ;;
4062+ m68k:machten:*:*)
4063+ echo m68k-apple-machten${UNAME_RELEASE}
4064+ exit 0 ;;
4065+ powerpc:machten:*:*)
4066+ echo powerpc-apple-machten${UNAME_RELEASE}
4067+ exit 0 ;;
4068+ RISC*:Mach:*:*)
4069+ echo mips-dec-mach_bsd4.3
4070+ exit 0 ;;
4071+ RISC*:ULTRIX:*:*)
4072+ echo mips-dec-ultrix${UNAME_RELEASE}
4073+ exit 0 ;;
4074+ VAX*:ULTRIX*:*:*)
4075+ echo vax-dec-ultrix${UNAME_RELEASE}
4076+ exit 0 ;;
4077+ 2020:CLIX:*:* | 2430:CLIX:*:*)
4078+ echo clipper-intergraph-clix${UNAME_RELEASE}
4079+ exit 0 ;;
4080+ mips:*:*:UMIPS | mips:*:*:RISCos)
4081+ eval $set_cc_for_build
4082+ sed 's/^ //' << EOF >$dummy.c
4083+#ifdef __cplusplus
4084+#include <stdio.h> /* for printf() prototype */
4085+ int main (int argc, char *argv[]) {
4086+#else
4087+ int main (argc, argv) int argc; char *argv[]; {
4088+#endif
4089+ #if defined (host_mips) && defined (MIPSEB)
4090+ #if defined (SYSTYPE_SYSV)
4091+ printf ("mips-mips-riscos%ssysv\n", argv[1]); exit (0);
4092+ #endif
4093+ #if defined (SYSTYPE_SVR4)
4094+ printf ("mips-mips-riscos%ssvr4\n", argv[1]); exit (0);
4095+ #endif
4096+ #if defined (SYSTYPE_BSD43) || defined(SYSTYPE_BSD)
4097+ printf ("mips-mips-riscos%sbsd\n", argv[1]); exit (0);
4098+ #endif
4099+ #endif
4100+ exit (-1);
4101+ }
4102+EOF
4103+ $CC_FOR_BUILD -o $dummy $dummy.c \
4104+ && $dummy `echo "${UNAME_RELEASE}" | sed -n 's/\([0-9]*\).*/\1/p'` \
4105+ && exit 0
4106+ echo mips-mips-riscos${UNAME_RELEASE}
4107+ exit 0 ;;
4108+ Motorola:PowerMAX_OS:*:*)
4109+ echo powerpc-motorola-powermax
4110+ exit 0 ;;
4111+ Motorola:*:4.3:PL8-*)
4112+ echo powerpc-harris-powermax
4113+ exit 0 ;;
4114+ Night_Hawk:*:*:PowerMAX_OS | Synergy:PowerMAX_OS:*:*)
4115+ echo powerpc-harris-powermax
4116+ exit 0 ;;
4117+ Night_Hawk:Power_UNIX:*:*)
4118+ echo powerpc-harris-powerunix
4119+ exit 0 ;;
4120+ m88k:CX/UX:7*:*)
4121+ echo m88k-harris-cxux7
4122+ exit 0 ;;
4123+ m88k:*:4*:R4*)
4124+ echo m88k-motorola-sysv4
4125+ exit 0 ;;
4126+ m88k:*:3*:R3*)
4127+ echo m88k-motorola-sysv3
4128+ exit 0 ;;
4129+ AViiON:dgux:*:*)
4130+ # DG/UX returns AViiON for all architectures
4131+ UNAME_PROCESSOR=`/usr/bin/uname -p`
4132+ if [ $UNAME_PROCESSOR = mc88100 ] || [ $UNAME_PROCESSOR = mc88110 ]
4133+ then
4134+ if [ ${TARGET_BINARY_INTERFACE}x = m88kdguxelfx ] || \
4135+ [ ${TARGET_BINARY_INTERFACE}x = x ]
4136+ then
4137+ echo m88k-dg-dgux${UNAME_RELEASE}
4138+ else
4139+ echo m88k-dg-dguxbcs${UNAME_RELEASE}
4140+ fi
4141+ else
4142+ echo i586-dg-dgux${UNAME_RELEASE}
4143+ fi
4144+ exit 0 ;;
4145+ M88*:DolphinOS:*:*) # DolphinOS (SVR3)
4146+ echo m88k-dolphin-sysv3
4147+ exit 0 ;;
4148+ M88*:*:R3*:*)
4149+ # Delta 88k system running SVR3
4150+ echo m88k-motorola-sysv3
4151+ exit 0 ;;
4152+ XD88*:*:*:*) # Tektronix XD88 system running UTekV (SVR3)
4153+ echo m88k-tektronix-sysv3
4154+ exit 0 ;;
4155+ Tek43[0-9][0-9]:UTek:*:*) # Tektronix 4300 system running UTek (BSD)
4156+ echo m68k-tektronix-bsd
4157+ exit 0 ;;
4158+ *:IRIX*:*:*)
4159+ echo mips-sgi-irix`echo ${UNAME_RELEASE}|sed -e 's/-/_/g'`
4160+ exit 0 ;;
4161+ ????????:AIX?:[12].1:2) # AIX 2.2.1 or AIX 2.1.1 is RT/PC AIX.
4162+ echo romp-ibm-aix # uname -m gives an 8 hex-code CPU id
4163+ exit 0 ;; # Note that: echo "'`uname -s`'" gives 'AIX '
4164+ i*86:AIX:*:*)
4165+ echo i386-ibm-aix
4166+ exit 0 ;;
4167+ ia64:AIX:*:*)
4168+ if [ -x /usr/bin/oslevel ] ; then
4169+ IBM_REV=`/usr/bin/oslevel`
4170+ else
4171+ IBM_REV=${UNAME_VERSION}.${UNAME_RELEASE}
4172+ fi
4173+ echo ${UNAME_MACHINE}-ibm-aix${IBM_REV}
4174+ exit 0 ;;
4175+ *:AIX:2:3)
4176+ if grep bos325 /usr/include/stdio.h >/dev/null 2>&1; then
4177+ eval $set_cc_for_build
4178+ sed 's/^ //' << EOF >$dummy.c
4179+ #include <sys/systemcfg.h>
4180+
4181+ main()
4182+ {
4183+ if (!__power_pc())
4184+ exit(1);
4185+ puts("powerpc-ibm-aix3.2.5");
4186+ exit(0);
4187+ }
4188+EOF
4189+ $CC_FOR_BUILD -o $dummy $dummy.c && $dummy && exit 0
4190+ echo rs6000-ibm-aix3.2.5
4191+ elif grep bos324 /usr/include/stdio.h >/dev/null 2>&1; then
4192+ echo rs6000-ibm-aix3.2.4
4193+ else
4194+ echo rs6000-ibm-aix3.2
4195+ fi
4196+ exit 0 ;;
4197+ *:AIX:*:[45])
4198+ IBM_CPU_ID=`/usr/sbin/lsdev -C -c processor -S available | sed 1q | awk '{ print $1 }'`
4199+ if /usr/sbin/lsattr -El ${IBM_CPU_ID} | grep ' POWER' >/dev/null 2>&1; then
4200+ IBM_ARCH=rs6000
4201+ else
4202+ IBM_ARCH=powerpc
4203+ fi
4204+ if [ -x /usr/bin/oslevel ] ; then
4205+ IBM_REV=`/usr/bin/oslevel`
4206+ else
4207+ IBM_REV=${UNAME_VERSION}.${UNAME_RELEASE}
4208+ fi
4209+ echo ${IBM_ARCH}-ibm-aix${IBM_REV}
4210+ exit 0 ;;
4211+ *:AIX:*:*)
4212+ echo rs6000-ibm-aix
4213+ exit 0 ;;
4214+ ibmrt:4.4BSD:*|romp-ibm:BSD:*)
4215+ echo romp-ibm-bsd4.4
4216+ exit 0 ;;
4217+ ibmrt:*BSD:*|romp-ibm:BSD:*) # covers RT/PC BSD and
4218+ echo romp-ibm-bsd${UNAME_RELEASE} # 4.3 with uname added to
4219+ exit 0 ;; # report: romp-ibm BSD 4.3
4220+ *:BOSX:*:*)
4221+ echo rs6000-bull-bosx
4222+ exit 0 ;;
4223+ DPX/2?00:B.O.S.:*:*)
4224+ echo m68k-bull-sysv3
4225+ exit 0 ;;
4226+ 9000/[34]??:4.3bsd:1.*:*)
4227+ echo m68k-hp-bsd
4228+ exit 0 ;;
4229+ hp300:4.4BSD:*:* | 9000/[34]??:4.3bsd:2.*:*)
4230+ echo m68k-hp-bsd4.4
4231+ exit 0 ;;
4232+ 9000/[34678]??:HP-UX:*:*)
4233+ HPUX_REV=`echo ${UNAME_RELEASE}|sed -e 's/[^.]*.[0B]*//'`
4234+ case "${UNAME_MACHINE}" in
4235+ 9000/31? ) HP_ARCH=m68000 ;;
4236+ 9000/[34]?? ) HP_ARCH=m68k ;;
4237+ 9000/[678][0-9][0-9])
4238+ if [ -x /usr/bin/getconf ]; then
4239+ sc_cpu_version=`/usr/bin/getconf SC_CPU_VERSION 2>/dev/null`
4240+ sc_kernel_bits=`/usr/bin/getconf SC_KERNEL_BITS 2>/dev/null`
4241+ case "${sc_cpu_version}" in
4242+ 523) HP_ARCH="hppa1.0" ;; # CPU_PA_RISC1_0
4243+ 528) HP_ARCH="hppa1.1" ;; # CPU_PA_RISC1_1
4244+ 532) # CPU_PA_RISC2_0
4245+ case "${sc_kernel_bits}" in
4246+ 32) HP_ARCH="hppa2.0n" ;;
4247+ 64) HP_ARCH="hppa2.0w" ;;
4248+ '') HP_ARCH="hppa2.0" ;; # HP-UX 10.20
4249+ esac ;;
4250+ esac
4251+ fi
4252+ if [ "${HP_ARCH}" = "" ]; then
4253+ eval $set_cc_for_build
4254+ sed 's/^ //' << EOF >$dummy.c
4255+
4256+ #define _HPUX_SOURCE
4257+ #include <stdlib.h>
4258+ #include <unistd.h>
4259+
4260+ int main ()
4261+ {
4262+ #if defined(_SC_KERNEL_BITS)
4263+ long bits = sysconf(_SC_KERNEL_BITS);
4264+ #endif
4265+ long cpu = sysconf (_SC_CPU_VERSION);
4266+
4267+ switch (cpu)
4268+ {
4269+ case CPU_PA_RISC1_0: puts ("hppa1.0"); break;
4270+ case CPU_PA_RISC1_1: puts ("hppa1.1"); break;
4271+ case CPU_PA_RISC2_0:
4272+ #if defined(_SC_KERNEL_BITS)
4273+ switch (bits)
4274+ {
4275+ case 64: puts ("hppa2.0w"); break;
4276+ case 32: puts ("hppa2.0n"); break;
4277+ default: puts ("hppa2.0"); break;
4278+ } break;
4279+ #else /* !defined(_SC_KERNEL_BITS) */
4280+ puts ("hppa2.0"); break;
4281+ #endif
4282+ default: puts ("hppa1.0"); break;
4283+ }
4284+ exit (0);
4285+ }
4286+EOF
4287+ (CCOPTS= $CC_FOR_BUILD -o $dummy $dummy.c 2>/dev/null) && HP_ARCH=`$dummy`
4288+ test -z "$HP_ARCH" && HP_ARCH=hppa
4289+ fi ;;
4290+ esac
4291+ if [ ${HP_ARCH} = "hppa2.0w" ]
4292+ then
4293+ # avoid double evaluation of $set_cc_for_build
4294+ test -n "$CC_FOR_BUILD" || eval $set_cc_for_build
4295+ if echo __LP64__ | (CCOPTS= $CC_FOR_BUILD -E -) | grep __LP64__ >/dev/null
4296+ then
4297+ HP_ARCH="hppa2.0w"
4298+ else
4299+ HP_ARCH="hppa64"
4300+ fi
4301+ fi
4302+ echo ${HP_ARCH}-hp-hpux${HPUX_REV}
4303+ exit 0 ;;
4304+ ia64:HP-UX:*:*)
4305+ HPUX_REV=`echo ${UNAME_RELEASE}|sed -e 's/[^.]*.[0B]*//'`
4306+ echo ia64-hp-hpux${HPUX_REV}
4307+ exit 0 ;;
4308+ 3050*:HI-UX:*:*)
4309+ eval $set_cc_for_build
4310+ sed 's/^ //' << EOF >$dummy.c
4311+ #include <unistd.h>
4312+ int
4313+ main ()
4314+ {
4315+ long cpu = sysconf (_SC_CPU_VERSION);
4316+ /* The order matters, because CPU_IS_HP_MC68K erroneously returns
4317+ true for CPU_PA_RISC1_0. CPU_IS_PA_RISC returns correct
4318+ results, however. */
4319+ if (CPU_IS_PA_RISC (cpu))
4320+ {
4321+ switch (cpu)
4322+ {
4323+ case CPU_PA_RISC1_0: puts ("hppa1.0-hitachi-hiuxwe2"); break;
4324+ case CPU_PA_RISC1_1: puts ("hppa1.1-hitachi-hiuxwe2"); break;
4325+ case CPU_PA_RISC2_0: puts ("hppa2.0-hitachi-hiuxwe2"); break;
4326+ default: puts ("hppa-hitachi-hiuxwe2"); break;
4327+ }
4328+ }
4329+ else if (CPU_IS_HP_MC68K (cpu))
4330+ puts ("m68k-hitachi-hiuxwe2");
4331+ else puts ("unknown-hitachi-hiuxwe2");
4332+ exit (0);
4333+ }
4334+EOF
4335+ $CC_FOR_BUILD -o $dummy $dummy.c && $dummy && exit 0
4336+ echo unknown-hitachi-hiuxwe2
4337+ exit 0 ;;
4338+ 9000/7??:4.3bsd:*:* | 9000/8?[79]:4.3bsd:*:* )
4339+ echo hppa1.1-hp-bsd
4340+ exit 0 ;;
4341+ 9000/8??:4.3bsd:*:*)
4342+ echo hppa1.0-hp-bsd
4343+ exit 0 ;;
4344+ *9??*:MPE/iX:*:* | *3000*:MPE/iX:*:*)
4345+ echo hppa1.0-hp-mpeix
4346+ exit 0 ;;
4347+ hp7??:OSF1:*:* | hp8?[79]:OSF1:*:* )
4348+ echo hppa1.1-hp-osf
4349+ exit 0 ;;
4350+ hp8??:OSF1:*:*)
4351+ echo hppa1.0-hp-osf
4352+ exit 0 ;;
4353+ i*86:OSF1:*:*)
4354+ if [ -x /usr/sbin/sysversion ] ; then
4355+ echo ${UNAME_MACHINE}-unknown-osf1mk
4356+ else
4357+ echo ${UNAME_MACHINE}-unknown-osf1
4358+ fi
4359+ exit 0 ;;
4360+ parisc*:Lites*:*:*)
4361+ echo hppa1.1-hp-lites
4362+ exit 0 ;;
4363+ C1*:ConvexOS:*:* | convex:ConvexOS:C1*:*)
4364+ echo c1-convex-bsd
4365+ exit 0 ;;
4366+ C2*:ConvexOS:*:* | convex:ConvexOS:C2*:*)
4367+ if getsysinfo -f scalar_acc
4368+ then echo c32-convex-bsd
4369+ else echo c2-convex-bsd
4370+ fi
4371+ exit 0 ;;
4372+ C34*:ConvexOS:*:* | convex:ConvexOS:C34*:*)
4373+ echo c34-convex-bsd
4374+ exit 0 ;;
4375+ C38*:ConvexOS:*:* | convex:ConvexOS:C38*:*)
4376+ echo c38-convex-bsd
4377+ exit 0 ;;
4378+ C4*:ConvexOS:*:* | convex:ConvexOS:C4*:*)
4379+ echo c4-convex-bsd
4380+ exit 0 ;;
4381+ CRAY*Y-MP:*:*:*)
4382+ echo ymp-cray-unicos${UNAME_RELEASE} | sed -e 's/\.[^.]*$/.X/'
4383+ exit 0 ;;
4384+ CRAY*[A-Z]90:*:*:*)
4385+ echo ${UNAME_MACHINE}-cray-unicos${UNAME_RELEASE} \
4386+ | sed -e 's/CRAY.*\([A-Z]90\)/\1/' \
4387+ -e y/ABCDEFGHIJKLMNOPQRSTUVWXYZ/abcdefghijklmnopqrstuvwxyz/ \
4388+ -e 's/\.[^.]*$/.X/'
4389+ exit 0 ;;
4390+ CRAY*TS:*:*:*)
4391+ echo t90-cray-unicos${UNAME_RELEASE} | sed -e 's/\.[^.]*$/.X/'
4392+ exit 0 ;;
4393+ CRAY*T3E:*:*:*)
4394+ echo alphaev5-cray-unicosmk${UNAME_RELEASE} | sed -e 's/\.[^.]*$/.X/'
4395+ exit 0 ;;
4396+ CRAY*SV1:*:*:*)
4397+ echo sv1-cray-unicos${UNAME_RELEASE} | sed -e 's/\.[^.]*$/.X/'
4398+ exit 0 ;;
4399+ *:UNICOS/mp:*:*)
4400+ echo craynv-cray-unicosmp${UNAME_RELEASE} | sed -e 's/\.[^.]*$/.X/'
4401+ exit 0 ;;
4402+ F30[01]:UNIX_System_V:*:* | F700:UNIX_System_V:*:*)
4403+ FUJITSU_PROC=`uname -m | tr 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' 'abcdefghijklmnopqrstuvwxyz'`
4404+ FUJITSU_SYS=`uname -p | tr 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' 'abcdefghijklmnopqrstuvwxyz' | sed -e 's/\///'`
4405+ FUJITSU_REL=`echo ${UNAME_RELEASE} | sed -e 's/ /_/'`
4406+ echo "${FUJITSU_PROC}-fujitsu-${FUJITSU_SYS}${FUJITSU_REL}"
4407+ exit 0 ;;
4408+ 5000:UNIX_System_V:4.*:*)
4409+ FUJITSU_SYS=`uname -p | tr 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' 'abcdefghijklmnopqrstuvwxyz' | sed -e 's/\///'`
4410+ FUJITSU_REL=`echo ${UNAME_RELEASE} | tr 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' 'abcdefghijklmnopqrstuvwxyz' | sed -e 's/ /_/'`
4411+ echo "sparc-fujitsu-${FUJITSU_SYS}${FUJITSU_REL}"
4412+ exit 0 ;;
4413+ i*86:BSD/386:*:* | i*86:BSD/OS:*:* | *:Ascend\ Embedded/OS:*:*)
4414+ echo ${UNAME_MACHINE}-pc-bsdi${UNAME_RELEASE}
4415+ exit 0 ;;
4416+ sparc*:BSD/OS:*:*)
4417+ echo sparc-unknown-bsdi${UNAME_RELEASE}
4418+ exit 0 ;;
4419+ *:BSD/OS:*:*)
4420+ echo ${UNAME_MACHINE}-unknown-bsdi${UNAME_RELEASE}
4421+ exit 0 ;;
4422+ *:FreeBSD:*:*)
4423+ echo ${UNAME_MACHINE}-unknown-freebsd`echo ${UNAME_RELEASE}|sed -e 's/[-(].*//'`
4424+ exit 0 ;;
4425+ i*:CYGWIN*:*)
4426+ echo ${UNAME_MACHINE}-pc-cygwin
4427+ exit 0 ;;
4428+ i*:MINGW*:*)
4429+ echo ${UNAME_MACHINE}-pc-mingw32
4430+ exit 0 ;;
4431+ i*:PW*:*)
4432+ echo ${UNAME_MACHINE}-pc-pw32
4433+ exit 0 ;;
4434+ x86:Interix*:[34]*)
4435+ echo i586-pc-interix${UNAME_RELEASE}|sed -e 's/\..*//'
4436+ exit 0 ;;
4437+ [345]86:Windows_95:* | [345]86:Windows_98:* | [345]86:Windows_NT:*)
4438+ echo i${UNAME_MACHINE}-pc-mks
4439+ exit 0 ;;
4440+ i*:Windows_NT*:* | Pentium*:Windows_NT*:*)
4441+ # How do we know it's Interix rather than the generic POSIX subsystem?
4442+ # It also conflicts with pre-2.0 versions of AT&T UWIN. Should we
4443+ # UNAME_MACHINE based on the output of uname instead of i386?
4444+ echo i586-pc-interix
4445+ exit 0 ;;
4446+ i*:UWIN*:*)
4447+ echo ${UNAME_MACHINE}-pc-uwin
4448+ exit 0 ;;
4449+ amd64:CYGWIN*:*:*)
4450+ echo x86_64-unknown-cygwin
4451+ exit 0 ;;
4452+ p*:CYGWIN*:*)
4453+ echo powerpcle-unknown-cygwin
4454+ exit 0 ;;
4455+ prep*:SunOS:5.*:*)
4456+ echo powerpcle-unknown-solaris2`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'`
4457+ exit 0 ;;
4458+ *:GNU:*:*)
4459+ # the GNU system
4460+ echo `echo ${UNAME_MACHINE}|sed -e 's,[-/].*$,,'`-unknown-gnu`echo ${UNAME_RELEASE}|sed -e 's,/.*$,,'`
4461+ exit 0 ;;
4462+ *:GNU/*:*:*)
4463+ # other systems with GNU libc and userland
4464+ echo ${UNAME_MACHINE}-unknown-`echo ${UNAME_SYSTEM} | sed 's,^[^/]*/,,' | tr '[A-Z]' '[a-z]'``echo ${UNAME_RELEASE}|sed -e 's/[-(].*//'`-gnu
4465+ exit 0 ;;
4466+ i*86:Minix:*:*)
4467+ echo ${UNAME_MACHINE}-pc-minix
4468+ exit 0 ;;
4469+ arm*:Linux:*:*)
4470+ echo ${UNAME_MACHINE}-unknown-linux-gnu
4471+ exit 0 ;;
4472+ cris:Linux:*:*)
4473+ echo cris-axis-linux-gnu
4474+ exit 0 ;;
4475+ crisv32:Linux:*:*)
4476+ echo crisv32-axis-linux-gnu
4477+ exit 0 ;;
4478+ frv:Linux:*:*)
4479+ echo frv-unknown-linux-gnu
4480+ exit 0 ;;
4481+ ia64:Linux:*:*)
4482+ echo ${UNAME_MACHINE}-unknown-linux-gnu
4483+ exit 0 ;;
4484+ m32r*:Linux:*:*)
4485+ echo ${UNAME_MACHINE}-unknown-linux-gnu
4486+ exit 0 ;;
4487+ m68*:Linux:*:*)
4488+ echo ${UNAME_MACHINE}-unknown-linux-gnu
4489+ exit 0 ;;
4490+ mips:Linux:*:*)
4491+ eval $set_cc_for_build
4492+ sed 's/^ //' << EOF >$dummy.c
4493+ #undef CPU
4494+ #undef mips
4495+ #undef mipsel
4496+ #if defined(__MIPSEL__) || defined(__MIPSEL) || defined(_MIPSEL) || defined(MIPSEL)
4497+ CPU=mipsel
4498+ #else
4499+ #if defined(__MIPSEB__) || defined(__MIPSEB) || defined(_MIPSEB) || defined(MIPSEB)
4500+ CPU=mips
4501+ #else
4502+ CPU=
4503+ #endif
4504+ #endif
4505+EOF
4506+ eval `$CC_FOR_BUILD -E $dummy.c 2>/dev/null | grep ^CPU=`
4507+ test x"${CPU}" != x && echo "${CPU}-unknown-linux-gnu" && exit 0
4508+ ;;
4509+ mips64:Linux:*:*)
4510+ eval $set_cc_for_build
4511+ sed 's/^ //' << EOF >$dummy.c
4512+ #undef CPU
4513+ #undef mips64
4514+ #undef mips64el
4515+ #if defined(__MIPSEL__) || defined(__MIPSEL) || defined(_MIPSEL) || defined(MIPSEL)
4516+ CPU=mips64el
4517+ #else
4518+ #if defined(__MIPSEB__) || defined(__MIPSEB) || defined(_MIPSEB) || defined(MIPSEB)
4519+ CPU=mips64
4520+ #else
4521+ CPU=
4522+ #endif
4523+ #endif
4524+EOF
4525+ eval `$CC_FOR_BUILD -E $dummy.c 2>/dev/null | grep ^CPU=`
4526+ test x"${CPU}" != x && echo "${CPU}-unknown-linux-gnu" && exit 0
4527+ ;;
4528+ ppc:Linux:*:*)
4529+ echo powerpc-unknown-linux-gnu
4530+ exit 0 ;;
4531+ ppc64:Linux:*:*)
4532+ echo powerpc64-unknown-linux-gnu
4533+ exit 0 ;;
4534+ alpha:Linux:*:*)
4535+ case `sed -n '/^cpu model/s/^.*: \(.*\)/\1/p' < /proc/cpuinfo` in
4536+ EV5) UNAME_MACHINE=alphaev5 ;;
4537+ EV56) UNAME_MACHINE=alphaev56 ;;
4538+ PCA56) UNAME_MACHINE=alphapca56 ;;
4539+ PCA57) UNAME_MACHINE=alphapca56 ;;
4540+ EV6) UNAME_MACHINE=alphaev6 ;;
4541+ EV67) UNAME_MACHINE=alphaev67 ;;
4542+ EV68*) UNAME_MACHINE=alphaev68 ;;
4543+ esac
4544+ objdump --private-headers /bin/sh | grep ld.so.1 >/dev/null
4545+ if test "$?" = 0 ; then LIBC="libc1" ; else LIBC="" ; fi
4546+ echo ${UNAME_MACHINE}-unknown-linux-gnu${LIBC}
4547+ exit 0 ;;
4548+ parisc:Linux:*:* | hppa:Linux:*:*)
4549+ # Look for CPU level
4550+ case `grep '^cpu[^a-z]*:' /proc/cpuinfo 2>/dev/null | cut -d' ' -f2` in
4551+ PA7*) echo hppa1.1-unknown-linux-gnu ;;
4552+ PA8*) echo hppa2.0-unknown-linux-gnu ;;
4553+ *) echo hppa-unknown-linux-gnu ;;
4554+ esac
4555+ exit 0 ;;
4556+ parisc64:Linux:*:* | hppa64:Linux:*:*)
4557+ echo hppa64-unknown-linux-gnu
4558+ exit 0 ;;
4559+ s390:Linux:*:* | s390x:Linux:*:*)
4560+ echo ${UNAME_MACHINE}-ibm-linux
4561+ exit 0 ;;
4562+ sh64*:Linux:*:*)
4563+ echo ${UNAME_MACHINE}-unknown-linux-gnu
4564+ exit 0 ;;
4565+ sh*:Linux:*:*)
4566+ echo ${UNAME_MACHINE}-unknown-linux-gnu
4567+ exit 0 ;;
4568+ sparc:Linux:*:* | sparc64:Linux:*:*)
4569+ echo ${UNAME_MACHINE}-unknown-linux-gnu
4570+ exit 0 ;;
4571+ x86_64:Linux:*:*)
4572+ echo x86_64-unknown-linux-gnu
4573+ exit 0 ;;
4574+ i*86:Linux:*:*)
4575+ # The BFD linker knows what the default object file format is, so
4576+ # first see if it will tell us. cd to the root directory to prevent
4577+ # problems with other programs or directories called `ld' in the path.
4578+ # Set LC_ALL=C to ensure ld outputs messages in English.
4579+ ld_supported_targets=`cd /; LC_ALL=C ld --help 2>&1 \
4580+ | sed -ne '/supported targets:/!d
4581+ s/[ ][ ]*/ /g
4582+ s/.*supported targets: *//
4583+ s/ .*//
4584+ p'`
4585+ case "$ld_supported_targets" in
4586+ elf32-i386)
4587+ TENTATIVE="${UNAME_MACHINE}-pc-linux-gnu"
4588+ ;;
4589+ a.out-i386-linux)
4590+ echo "${UNAME_MACHINE}-pc-linux-gnuaout"
4591+ exit 0 ;;
4592+ coff-i386)
4593+ echo "${UNAME_MACHINE}-pc-linux-gnucoff"
4594+ exit 0 ;;
4595+ "")
4596+ # Either a pre-BFD a.out linker (linux-gnuoldld) or
4597+ # one that does not give us useful --help.
4598+ echo "${UNAME_MACHINE}-pc-linux-gnuoldld"
4599+ exit 0 ;;
4600+ esac
4601+ # Determine whether the default compiler is a.out or elf
4602+ eval $set_cc_for_build
4603+ sed 's/^ //' << EOF >$dummy.c
4604+ #include <features.h>
4605+ #ifdef __ELF__
4606+ # ifdef __GLIBC__
4607+ # if __GLIBC__ >= 2
4608+ LIBC=gnu
4609+ # else
4610+ LIBC=gnulibc1
4611+ # endif
4612+ # else
4613+ LIBC=gnulibc1
4614+ # endif
4615+ #else
4616+ #ifdef __INTEL_COMPILER
4617+ LIBC=gnu
4618+ #else
4619+ LIBC=gnuaout
4620+ #endif
4621+ #endif
4622+ #ifdef __dietlibc__
4623+ LIBC=dietlibc
4624+ #endif
4625+EOF
4626+ eval `$CC_FOR_BUILD -E $dummy.c 2>/dev/null | grep ^LIBC=`
4627+ test x"${LIBC}" != x && echo "${UNAME_MACHINE}-pc-linux-${LIBC}" && exit 0
4628+ test x"${TENTATIVE}" != x && echo "${TENTATIVE}" && exit 0
4629+ ;;
4630+ i*86:DYNIX/ptx:4*:*)
4631+ # ptx 4.0 does uname -s correctly, with DYNIX/ptx in there.
4632+ # earlier versions are messed up and put the nodename in both
4633+ # sysname and nodename.
4634+ echo i386-sequent-sysv4
4635+ exit 0 ;;
4636+ i*86:UNIX_SV:4.2MP:2.*)
4637+ # Unixware is an offshoot of SVR4, but it has its own version
4638+ # number series starting with 2...
4639+ # I am not positive that other SVR4 systems won't match this,
4640+ # I just have to hope. -- rms.
4641+ # Use sysv4.2uw... so that sysv4* matches it.
4642+ echo ${UNAME_MACHINE}-pc-sysv4.2uw${UNAME_VERSION}
4643+ exit 0 ;;
4644+ i*86:OS/2:*:*)
4645+ # If we were able to find `uname', then EMX Unix compatibility
4646+ # is probably installed.
4647+ echo ${UNAME_MACHINE}-pc-os2-emx
4648+ exit 0 ;;
4649+ i*86:XTS-300:*:STOP)
4650+ echo ${UNAME_MACHINE}-unknown-stop
4651+ exit 0 ;;
4652+ i*86:atheos:*:*)
4653+ echo ${UNAME_MACHINE}-unknown-atheos
4654+ exit 0 ;;
4655+ i*86:syllable:*:*)
4656+ echo ${UNAME_MACHINE}-pc-syllable
4657+ exit 0 ;;
4658+ i*86:LynxOS:2.*:* | i*86:LynxOS:3.[01]*:* | i*86:LynxOS:4.0*:*)
4659+ echo i386-unknown-lynxos${UNAME_RELEASE}
4660+ exit 0 ;;
4661+ i*86:*DOS:*:*)
4662+ echo ${UNAME_MACHINE}-pc-msdosdjgpp
4663+ exit 0 ;;
4664+ i*86:*:4.*:* | i*86:SYSTEM_V:4.*:*)
4665+ UNAME_REL=`echo ${UNAME_RELEASE} | sed 's/\/MP$//'`
4666+ if grep Novell /usr/include/link.h >/dev/null 2>/dev/null; then
4667+ echo ${UNAME_MACHINE}-univel-sysv${UNAME_REL}
4668+ else
4669+ echo ${UNAME_MACHINE}-pc-sysv${UNAME_REL}
4670+ fi
4671+ exit 0 ;;
4672+ i*86:*:5:[78]*)
4673+ case `/bin/uname -X | grep "^Machine"` in
4674+ *486*) UNAME_MACHINE=i486 ;;
4675+ *Pentium) UNAME_MACHINE=i586 ;;
4676+ *Pent*|*Celeron) UNAME_MACHINE=i686 ;;
4677+ esac
4678+ echo ${UNAME_MACHINE}-unknown-sysv${UNAME_RELEASE}${UNAME_SYSTEM}${UNAME_VERSION}
4679+ exit 0 ;;
4680+ i*86:*:3.2:*)
4681+ if test -f /usr/options/cb.name; then
4682+ UNAME_REL=`sed -n 's/.*Version //p' </usr/options/cb.name`
4683+ echo ${UNAME_MACHINE}-pc-isc$UNAME_REL
4684+ elif /bin/uname -X 2>/dev/null >/dev/null ; then
4685+ UNAME_REL=`(/bin/uname -X|grep Release|sed -e 's/.*= //')`
4686+ (/bin/uname -X|grep i80486 >/dev/null) && UNAME_MACHINE=i486
4687+ (/bin/uname -X|grep '^Machine.*Pentium' >/dev/null) \
4688+ && UNAME_MACHINE=i586
4689+ (/bin/uname -X|grep '^Machine.*Pent *II' >/dev/null) \
4690+ && UNAME_MACHINE=i686
4691+ (/bin/uname -X|grep '^Machine.*Pentium Pro' >/dev/null) \
4692+ && UNAME_MACHINE=i686
4693+ echo ${UNAME_MACHINE}-pc-sco$UNAME_REL
4694+ else
4695+ echo ${UNAME_MACHINE}-pc-sysv32
4696+ fi
4697+ exit 0 ;;
4698+ pc:*:*:*)
4699+ # Left here for compatibility:
4700+ # uname -m prints for DJGPP always 'pc', but it prints nothing about
4701+ # the processor, so we play safe by assuming i386.
4702+ echo i386-pc-msdosdjgpp
4703+ exit 0 ;;
4704+ Intel:Mach:3*:*)
4705+ echo i386-pc-mach3
4706+ exit 0 ;;
4707+ paragon:*:*:*)
4708+ echo i860-intel-osf1
4709+ exit 0 ;;
4710+ i860:*:4.*:*) # i860-SVR4
4711+ if grep Stardent /usr/include/sys/uadmin.h >/dev/null 2>&1 ; then
4712+ echo i860-stardent-sysv${UNAME_RELEASE} # Stardent Vistra i860-SVR4
4713+ else # Add other i860-SVR4 vendors below as they are discovered.
4714+ echo i860-unknown-sysv${UNAME_RELEASE} # Unknown i860-SVR4
4715+ fi
4716+ exit 0 ;;
4717+ mini*:CTIX:SYS*5:*)
4718+ # "miniframe"
4719+ echo m68010-convergent-sysv
4720+ exit 0 ;;
4721+ mc68k:UNIX:SYSTEM5:3.51m)
4722+ echo m68k-convergent-sysv
4723+ exit 0 ;;
4724+ M680?0:D-NIX:5.3:*)
4725+ echo m68k-diab-dnix
4726+ exit 0 ;;
4727+ M68*:*:R3V[5678]*:*)
4728+ test -r /sysV68 && echo 'm68k-motorola-sysv' && exit 0 ;;
4729+ 3[345]??:*:4.0:3.0 | 3[34]??A:*:4.0:3.0 | 3[34]??,*:*:4.0:3.0 | 3[34]??/*:*:4.0:3.0 | 4400:*:4.0:3.0 | 4850:*:4.0:3.0 | SKA40:*:4.0:3.0 | SDS2:*:4.0:3.0 | SHG2:*:4.0:3.0 | S7501*:*:4.0:3.0)
4730+ OS_REL=''
4731+ test -r /etc/.relid \
4732+ && OS_REL=.`sed -n 's/[^ ]* [^ ]* \([0-9][0-9]\).*/\1/p' < /etc/.relid`
4733+ /bin/uname -p 2>/dev/null | grep 86 >/dev/null \
4734+ && echo i486-ncr-sysv4.3${OS_REL} && exit 0
4735+ /bin/uname -p 2>/dev/null | /bin/grep entium >/dev/null \
4736+ && echo i586-ncr-sysv4.3${OS_REL} && exit 0 ;;
4737+ 3[34]??:*:4.0:* | 3[34]??,*:*:4.0:*)
4738+ /bin/uname -p 2>/dev/null | grep 86 >/dev/null \
4739+ && echo i486-ncr-sysv4 && exit 0 ;;
4740+ m68*:LynxOS:2.*:* | m68*:LynxOS:3.0*:*)
4741+ echo m68k-unknown-lynxos${UNAME_RELEASE}
4742+ exit 0 ;;
4743+ mc68030:UNIX_System_V:4.*:*)
4744+ echo m68k-atari-sysv4
4745+ exit 0 ;;
4746+ TSUNAMI:LynxOS:2.*:*)
4747+ echo sparc-unknown-lynxos${UNAME_RELEASE}
4748+ exit 0 ;;
4749+ rs6000:LynxOS:2.*:*)
4750+ echo rs6000-unknown-lynxos${UNAME_RELEASE}
4751+ exit 0 ;;
4752+ PowerPC:LynxOS:2.*:* | PowerPC:LynxOS:3.[01]*:* | PowerPC:LynxOS:4.0*:*)
4753+ echo powerpc-unknown-lynxos${UNAME_RELEASE}
4754+ exit 0 ;;
4755+ SM[BE]S:UNIX_SV:*:*)
4756+ echo mips-dde-sysv${UNAME_RELEASE}
4757+ exit 0 ;;
4758+ RM*:ReliantUNIX-*:*:*)
4759+ echo mips-sni-sysv4
4760+ exit 0 ;;
4761+ RM*:SINIX-*:*:*)
4762+ echo mips-sni-sysv4
4763+ exit 0 ;;
4764+ *:SINIX-*:*:*)
4765+ if uname -p 2>/dev/null >/dev/null ; then
4766+ UNAME_MACHINE=`(uname -p) 2>/dev/null`
4767+ echo ${UNAME_MACHINE}-sni-sysv4
4768+ else
4769+ echo ns32k-sni-sysv
4770+ fi
4771+ exit 0 ;;
4772+ PENTIUM:*:4.0*:*) # Unisys `ClearPath HMP IX 4000' SVR4/MP effort
4773+ # says <Richard.M.Bartel@ccMail.Census.GOV>
4774+ echo i586-unisys-sysv4
4775+ exit 0 ;;
4776+ *:UNIX_System_V:4*:FTX*)
4777+ # From Gerald Hewes <hewes@openmarket.com>.
4778+ # How about differentiating between stratus architectures? -djm
4779+ echo hppa1.1-stratus-sysv4
4780+ exit 0 ;;
4781+ *:*:*:FTX*)
4782+ # From seanf@swdc.stratus.com.
4783+ echo i860-stratus-sysv4
4784+ exit 0 ;;
4785+ i*86:VOS:*:*)
4786+ # From Paul.Green@stratus.com.
4787+ echo ${UNAME_MACHINE}-stratus-vos
4788+ exit 0 ;;
4789+ *:VOS:*:*)
4790+ # From Paul.Green@stratus.com.
4791+ echo hppa1.1-stratus-vos
4792+ exit 0 ;;
4793+ mc68*:A/UX:*:*)
4794+ echo m68k-apple-aux${UNAME_RELEASE}
4795+ exit 0 ;;
4796+ news*:NEWS-OS:6*:*)
4797+ echo mips-sony-newsos6
4798+ exit 0 ;;
4799+ R[34]000:*System_V*:*:* | R4000:UNIX_SYSV:*:* | R*000:UNIX_SV:*:*)
4800+ if [ -d /usr/nec ]; then
4801+ echo mips-nec-sysv${UNAME_RELEASE}
4802+ else
4803+ echo mips-unknown-sysv${UNAME_RELEASE}
4804+ fi
4805+ exit 0 ;;
4806+ BeBox:BeOS:*:*) # BeOS running on hardware made by Be, PPC only.
4807+ echo powerpc-be-beos
4808+ exit 0 ;;
4809+ BeMac:BeOS:*:*) # BeOS running on Mac or Mac clone, PPC only.
4810+ echo powerpc-apple-beos
4811+ exit 0 ;;
4812+ BePC:BeOS:*:*) # BeOS running on Intel PC compatible.
4813+ echo i586-pc-beos
4814+ exit 0 ;;
4815+ SX-4:SUPER-UX:*:*)
4816+ echo sx4-nec-superux${UNAME_RELEASE}
4817+ exit 0 ;;
4818+ SX-5:SUPER-UX:*:*)
4819+ echo sx5-nec-superux${UNAME_RELEASE}
4820+ exit 0 ;;
4821+ SX-6:SUPER-UX:*:*)
4822+ echo sx6-nec-superux${UNAME_RELEASE}
4823+ exit 0 ;;
4824+ Power*:Rhapsody:*:*)
4825+ echo powerpc-apple-rhapsody${UNAME_RELEASE}
4826+ exit 0 ;;
4827+ *:Rhapsody:*:*)
4828+ echo ${UNAME_MACHINE}-apple-rhapsody${UNAME_RELEASE}
4829+ exit 0 ;;
4830+ *:Darwin:*:*)
4831+ UNAME_PROCESSOR=`uname -p` || UNAME_PROCESSOR=unknown
4832+ case $UNAME_PROCESSOR in
4833+ *86) UNAME_PROCESSOR=i686 ;;
4834+ unknown) UNAME_PROCESSOR=powerpc ;;
4835+ esac
4836+ echo ${UNAME_PROCESSOR}-apple-darwin${UNAME_RELEASE}
4837+ exit 0 ;;
4838+ *:procnto*:*:* | *:QNX:[0123456789]*:*)
4839+ UNAME_PROCESSOR=`uname -p`
4840+ if test "$UNAME_PROCESSOR" = "x86"; then
4841+ UNAME_PROCESSOR=i386
4842+ UNAME_MACHINE=pc
4843+ fi
4844+ echo ${UNAME_PROCESSOR}-${UNAME_MACHINE}-nto-qnx${UNAME_RELEASE}
4845+ exit 0 ;;
4846+ *:QNX:*:4*)
4847+ echo i386-pc-qnx
4848+ exit 0 ;;
4849+ NSE-?:NONSTOP_KERNEL:*:*)
4850+ echo nse-tandem-nsk${UNAME_RELEASE}
4851+ exit 0 ;;
4852+ NSR-?:NONSTOP_KERNEL:*:*)
4853+ echo nsr-tandem-nsk${UNAME_RELEASE}
4854+ exit 0 ;;
4855+ *:NonStop-UX:*:*)
4856+ echo mips-compaq-nonstopux
4857+ exit 0 ;;
4858+ BS2000:POSIX*:*:*)
4859+ echo bs2000-siemens-sysv
4860+ exit 0 ;;
4861+ DS/*:UNIX_System_V:*:*)
4862+ echo ${UNAME_MACHINE}-${UNAME_SYSTEM}-${UNAME_RELEASE}
4863+ exit 0 ;;
4864+ *:Plan9:*:*)
4865+ # "uname -m" is not consistent, so use $cputype instead. 386
4866+ # is converted to i386 for consistency with other x86
4867+ # operating systems.
4868+ if test "$cputype" = "386"; then
4869+ UNAME_MACHINE=i386
4870+ else
4871+ UNAME_MACHINE="$cputype"
4872+ fi
4873+ echo ${UNAME_MACHINE}-unknown-plan9
4874+ exit 0 ;;
4875+ *:TOPS-10:*:*)
4876+ echo pdp10-unknown-tops10
4877+ exit 0 ;;
4878+ *:TENEX:*:*)
4879+ echo pdp10-unknown-tenex
4880+ exit 0 ;;
4881+ KS10:TOPS-20:*:* | KL10:TOPS-20:*:* | TYPE4:TOPS-20:*:*)
4882+ echo pdp10-dec-tops20
4883+ exit 0 ;;
4884+ XKL-1:TOPS-20:*:* | TYPE5:TOPS-20:*:*)
4885+ echo pdp10-xkl-tops20
4886+ exit 0 ;;
4887+ *:TOPS-20:*:*)
4888+ echo pdp10-unknown-tops20
4889+ exit 0 ;;
4890+ *:ITS:*:*)
4891+ echo pdp10-unknown-its
4892+ exit 0 ;;
4893+ SEI:*:*:SEIUX)
4894+ echo mips-sei-seiux${UNAME_RELEASE}
4895+ exit 0 ;;
4896+ *:DragonFly:*:*)
4897+ echo ${UNAME_MACHINE}-unknown-dragonfly`echo ${UNAME_RELEASE}|sed -e 's/[-(].*//'`
4898+ exit 0 ;;
4899+ *:*VMS:*:*)
4900+ UNAME_MACHINE=`(uname -p) 2>/dev/null`
4901+ case "${UNAME_MACHINE}" in
4902+ A*) echo alpha-dec-vms && exit 0 ;;
4903+ I*) echo ia64-dec-vms && exit 0 ;;
4904+ V*) echo vax-dec-vms && exit 0 ;;
4905+ esac ;;
4906+ *:XENIX:*:SysV)
4907+ echo i386-pc-xenix
4908+ exit 0 ;;
4909+esac
4910+
4911+#echo '(No uname command or uname output not recognized.)' 1>&2
4912+#echo "${UNAME_MACHINE}:${UNAME_SYSTEM}:${UNAME_RELEASE}:${UNAME_VERSION}" 1>&2
4913+
4914+eval $set_cc_for_build
4915+cat >$dummy.c <<EOF
4916+#ifdef _SEQUENT_
4917+# include <sys/types.h>
4918+# include <sys/utsname.h>
4919+#endif
4920+main ()
4921+{
4922+#if defined (sony)
4923+#if defined (MIPSEB)
4924+ /* BFD wants "bsd" instead of "newsos". Perhaps BFD should be changed,
4925+ I don't know.... */
4926+ printf ("mips-sony-bsd\n"); exit (0);
4927+#else
4928+#include <sys/param.h>
4929+ printf ("m68k-sony-newsos%s\n",
4930+#ifdef NEWSOS4
4931+ "4"
4932+#else
4933+ ""
4934+#endif
4935+ ); exit (0);
4936+#endif
4937+#endif
4938+
4939+#if defined (__arm) && defined (__acorn) && defined (__unix)
4940+ printf ("arm-acorn-riscix"); exit (0);
4941+#endif
4942+
4943+#if defined (hp300) && !defined (hpux)
4944+ printf ("m68k-hp-bsd\n"); exit (0);
4945+#endif
4946+
4947+#if defined (NeXT)
4948+#if !defined (__ARCHITECTURE__)
4949+#define __ARCHITECTURE__ "m68k"
4950+#endif
4951+ int version;
4952+ version=`(hostinfo | sed -n 's/.*NeXT Mach \([0-9]*\).*/\1/p') 2>/dev/null`;
4953+ if (version < 4)
4954+ printf ("%s-next-nextstep%d\n", __ARCHITECTURE__, version);
4955+ else
4956+ printf ("%s-next-openstep%d\n", __ARCHITECTURE__, version);
4957+ exit (0);
4958+#endif
4959+
4960+#if defined (MULTIMAX) || defined (n16)
4961+#if defined (UMAXV)
4962+ printf ("ns32k-encore-sysv\n"); exit (0);
4963+#else
4964+#if defined (CMU)
4965+ printf ("ns32k-encore-mach\n"); exit (0);
4966+#else
4967+ printf ("ns32k-encore-bsd\n"); exit (0);
4968+#endif
4969+#endif
4970+#endif
4971+
4972+#if defined (__386BSD__)
4973+ printf ("i386-pc-bsd\n"); exit (0);
4974+#endif
4975+
4976+#if defined (sequent)
4977+#if defined (i386)
4978+ printf ("i386-sequent-dynix\n"); exit (0);
4979+#endif
4980+#if defined (ns32000)
4981+ printf ("ns32k-sequent-dynix\n"); exit (0);
4982+#endif
4983+#endif
4984+
4985+#if defined (_SEQUENT_)
4986+ struct utsname un;
4987+
4988+ uname(&un);
4989+
4990+ if (strncmp(un.version, "V2", 2) == 0) {
4991+ printf ("i386-sequent-ptx2\n"); exit (0);
4992+ }
4993+ if (strncmp(un.version, "V1", 2) == 0) { /* XXX is V1 correct? */
4994+ printf ("i386-sequent-ptx1\n"); exit (0);
4995+ }
4996+ printf ("i386-sequent-ptx\n"); exit (0);
4997+
4998+#endif
4999+
5000+#if defined (vax)
The diff has been truncated for viewing.