Install and test renewable energy system for ICT networks ICTSUS4183A

raspgiantsneckΔιακομιστές

9 Δεκ 2013 (πριν από 4 χρόνια και 23 μέρες)

293 εμφανίσεις


Lesson
8



Course Units



Install and test renewable energy system for ICT
networks

ICTSUS4183A


Install and test power saving hardware

ICTSUS4184A


Install and test power management software

ICTSUS4185A


Install thin client applications for power over

Ethernet

ICTSUS4186A

Develop workplace policy and procedures for
sustainability


BSBSUS501A



Grading

U
: Your result will be recorded and reported to you as Competent or Not yet

Competent.


G
: Your result will be recorded and reported to you as Distinc
tion or Credit or

Competent or Not yet Competent.


Assessment

evidence can be gained through a minimum of two assessment tools. For
example:




Lesson Tasks



Team Project



Individual Report and Presentation



Teacher observation,
questioning

and discussion





R
eference
s
:



http://civitsustainability.wikispaces.com/



Teacher:
Stanley.Tonkins@tafensw.edu.au














Unit Summaries:


ICTSUS4183A



In
stall and test renewable energy system for ICT
networks


This unit describes the performance outcomes, skills and knowledge required to
install a renewable energy system and integrate it into the network.


ICTSUS4184A

Install and test power saving hardw
are


This unit describes the performance outcomes, skills and knowledge required to
install and test power saving hardware components in servers, motherboards and
other networking equipment installed in ICT applications.


ICTSUS4185A

Install and test power

management software


This unit describes the performance outcomes, skills and knowledge required to
install and test power management software in network elements.


ICTSUS4186A

Install thin client applications for power over Ethernet



This unit describes

the performance outcomes, skills and knowledge required to
install and configure thin client applications to enable power over ethernet (PoE) on
a low powered workstation.

Thin client refers to a remote office with low band width.


Elective

BSBSUS501A


De
velop workplace policy and procedures for
sustainability

This unit describes the performance outcomes, skills and knowledge required to
develop and implement a workplace sustainability policy, including the modification
of the policy to suit changed circum
stances.


















ICTSUS4186A

Install thin client applications for power over
Ethernet




ELEMENT

PERFORMANCE CRITERIA

1. Plan to install thin client
applications

1.1. Assess extent of applications to
be implemented using feasibility
report and

organisational guidelines

1.2. Highlight issues associated with
adoption of Web 2.0 applications

1.3. Produce an implementation plan
and present to
customer

1.4. Liaise with
appropriate person
to
obtain approval for the plans with any
recommendations

1.5. Notify customer for site access

2. Evaluate appropriate applications

2.1. Develop criteria for Web 2.0
applications to satisfy enterprise
needs

2.2. Test and evaluate Web 2.0
applications according to agreed
criteria

2.3. Present findings to the
customer
with recommendations on Web 2.0
applications

3. Install hardware components and
applications

3.1. Follow occupational health and
safety (OHS) and environmental
requirements according to plan and
manufacturer's specifications

3.2. Develop imple
mentation plans
with prioritised tasks and contingency
arrangements for minimum disruption
to customer

3.3. Install
hardware components
and
thin client software
needed for the
work according to network and
organisational requirements

3.4. Bench test perf
ormance of
applications

3.5. Resolve identified problems

4. Complete work and document
activities

4.1. Document the installation and
integration process according to
organisational guidelines

4.2. Provide user documentation

4.3. Notify customer and o
btain sign
off























Edubuntu

thin

Client





When Installing an LTSP Server:

http://edubuntu.org/documentation/11.10/installation
-
guide



LTSP
-
Cluster



LTSP
-
Cluster is a set of LTSP plugins and client
-
side tools that allows you to deploy and
centrally manage large numbers of thin
-
clients. It allows you to run thousands of thin
-
clients that are able to connect to a load
-
balanced cluster of GNU/Linux and
-
or Microsoft
Windows terminal servers.


LTSP
-
Clust
er Features:


Central Configuration web interface

Load balanced thin clients across multiple servers

Complete autologin support with account creation

Store hardware information for all clients in the control center

Managed PXE configuration, creating links

to a specific configuration for a specific node

Integration with iTalc

Components

LTSP
-
Cluster is formed by several components. The most user
-
visible component is the
LTSP
-
Cluster Control Center which provides the web interface for the system. Visit the
T
echnical Introduction page for more information on LTSP
-
Cluster components. Below
are some screenshots for the control center:

https://www.ltsp
-
cluster.org/
















Power over Ethernet

http://en.wikipedia.org/wiki/Power_over_Ethernet



Given
a single ethernet cable, a PoE splitter provides both data (gray cable) and power
(black cable) for a wireless LAN access point, thus eliminating the need for a nearby
power outlet.




Power over Ethernet or PoE technology describes a system to pass electrical power
safely, along with data, on Ethernet cabling. The IEEE standard for PoE requires category
5 cable or higher for high power levels, but can operate with catego
ry 3 cable if less
power is required.[1] Power is supplied in common mode over two or more of the
differential pairs of wires found in the Ethernet cables and comes from a power supply
within a PoE
-
enabled networking device such as an Ethernet switch or ca
n be injected
into a cable run with a midspan power supply.


The original IEEE 802.3af
-
2003[2] PoE standard provides up to 15.4 W of DC power
(minimum 44 V DC and 350 mA[3][4]) to each device.[5] Only 12.95 W is assured to be
available at the powered devic
e as some power is dissipated in the cable.[6]


The updated IEEE 802.3at
-
2009[7] PoE standard also known as PoE+ or PoE plus,
provides up to 25.5 W of power.[8] The 2009 standard prohibits a powered device from
using all four pairs for power.[9] Some vendo
rs have announced products that claim to be
compatible with the 802.3at standard and offer up to 51 W of power over a single cable
by utilizing all four pairs in the Category 5 cable.[10]




YouTube

thin client boot


http://www.youtube.com/watch?v=tPQev
-
yU6cA&feature=related


http://www.youtube.com/watch?v=hh8trqdaQwc








Introduction to the PXE Protocol
-

How a thin clien
t boots

http://lancore.sourceforge.net/en/thin_client_pxe_network_boot.html


Preboot execution environment (PXE) protocol (see PXE Internet Draft) is a
mixture of two well
-
known protocols: the Dynamic Host Configuration Protocol
(DHCP) and the Trivial File Transfer Protocol (TFTP). However, to be compliant with
the Intel PXE Specification version 2.1 both protocols, DHCP and TFTP, require
some modifications to its original s
pecification, as discussed below.


The former protocol, DHCP, is probably the most widely used protocol today for
the management and allocation of IP addresses on a local area network (LAN). It is
a common client/server protocol and, in general, from the v
iewpoint of the client,
this protocol is implemented by a program that runs after the operating system
boots. However, this protocol is used in PXE to assign an IP address to each thin
client when it boots. Thus, a thin client can be started without a pre
-
installed
operating system, and for this reason, a thin client includes an implementation of
the PXE protocol in the BIOS.


Once the thin client has an IP address, and since it may not have operating system,
the client must be able to download an operating

system through the network. It
has to be noted that a thin client does not have any information about the network
during the boot, the IP addresses of servers and other connected devices are
unknown to the thin client. Therefore, the PXE protocol should p
rovide that
information. To this end, the PXE protocol uses an extension of the DHCP protocol
(see below) to provide this information to the thin client. The thin client is then
able to locale an appropriate boot server and the corresponding operating syst
em
that can be downloading using a file transfer protocol, the Trivial FTP or TFTP.


PXE Boot Process

http://pxe.dev.aboveaverageurl.com/index.php/PXE_Booting


http://www.google.c
om.au/imgres?q=pxe+boot&start=15&num=10&um=1&hl=en&biw
=1024&bih=653&tbm=isch&tbnid=P7YkfS4he
-
xPBM:&imgrefurl=http://www.intel.com/technology/itj/2008/v12i4/5
-
paper/4
-
embedded
-
2.htm&docid=WJxjynyBZisg_M&imgurl=http://www.intel.com/technology/itj/2008/v12
i4/
5
-
paper/figures/PXE_Boot_02.jpg&w=370&h=222&ei=F3LET9H1IcyVmQXMoYHRCg
&zoom=1&iact=hc&vpx=522&vpy=173&dur=104&hovh=174&hovw=290&tx=150&ty
=133&sig=113398230769818374539&page=2&tbnh=121&tbnw=201&ndsp=17&ved=1
t:429,r:10,s:15,i:27








1. PXE client boots up, starts up PXE boot ROM.

2. The PXE boot ROM sends a DHCP request.

3. The responding DHCP request (should) contain an additional DHCP o
ption, the
"filename" options. (This is why the average hardware router won't work. You can't
specify the needed options.)

4. The PXE client attempts to

download

the file specified ov
er TFTP. (If not specified, the
client tries to connect to the computer that gave it the DHCP lease. If the "next
-
server"
param is specified, it will instead attempt to download the file off of that server. Note that
DNS is

not

available here, so it must b
e an IP address. There is no way around this.)

5. If the PXE client

downloads

the file, it then executes this file and from there PXE is out
of the picture. That's the entire PXE proc
ess.

6. If any of the above steps fail, the computer should

continue

on with the boot process.


HOWTO:

Updating

LTSP

client

chroot


http://www.youtube.com/watch?v=bARxhOn3mKo&feature=related


Edubuntu 12.04 LTS Gnome
http://www.youtube.com/watch?v=0PI16wed6bY&feature=related


Here

i

am

go
ing

to

show

you,

how

to

install/setup

LTSP

on

top

of

an

already

running

desktop

system

http://reviewhubs.com/linuxtips/2010/12/howto
-
install
-
ltsp
-
in
-
ubuntu
-
10
-
10
-
maverick
-
reuse
-
your
-
old
-
computers
-
with
-
out
-
hard
-
disk
-
and
-
thin
-
clients.html



Building a custom Tinycore kernel


http://www.parkytowers.me.uk/thin/Linux/TinycoreCK.shtml


PXE Boot


Thin Client LTSP Config


http://www.bgevolution.com/blog/px
e
-
boot
-
thin
-
client
-
ltsp
-
config/


LTSP How to Etch
-

debian


http://wiki.debian.org/LTSP/Howto/Etch


customizing
-
thin
-
client

http://doc.ubuntu.com/edubuntu/edubuntu/handbook/C/customizing
-
thin
-
client.html


LTSP
-

Linux Terminal Server Project
-

v4.1

ftp://ftp.ula
kbim.gov.tr/ltsp/docs/ltsp
-
4.1
-
en.html



PXE

http://www.syslinux.org/wiki/index.php/PXELINUX




http://www.parkytowers
.me.uk/thin/wyse/3150se/build.shtml










Linux Terminal Server Project

http://www.freesoftwaremagazine.com/articles/linux_terminal_server



LTSP, the

Linux

Terminal

Server

Project

is a free software project intended to
make the setup easy
(??)
. The clients configure via DHCP (Dynamic Host
Configuration Protocol) and

download

a

minimal GNU/Linux operating system
from the server using TFTP (Tiny File Transfer Protocol). The GNU/Linux
operating system for the client boots and uses a file system on the server and
the memory of the client to do everything. Th
e initial network boot can be done
by a ROM (Read Only Memory) resident program on the client. Most PCs since
1998 have this capability built into the BIOS if there is a Network Interface
Controller (NIC) built into the motherboard. The BIOS setup may ment
ion PXE,
Pre
-
Execution Environment or network in the booting section. Others can
incorporate a boot loader in a socket on the NIC into the BIOS of the PC, or
boot from a floppy, USB device, hard drive or CD.


The only software installation required is on t
he server. You can use a GNU/Linux
distribution designed for use in schools and by teachers with modest expertise.
Because the LTSP scripts can be a hassle for a novice, the folks who made
Edubuntu (Ubuntu plus a few packages and configurations for schools
) put in
automatic installation of the simplest, and most common setup, the server running a
private LAN with your clients. This works well for a classroom, a computer lab, an
office or a small school. Except for multimedia intensive stations the LTSP conc
ept
works for about thirty clients from a single 32 bit CPU with 2GB RAM. Using a dual
-
core 64 bit CPU and 4GB RAM, one server can handle sixty clients. With multiple
servers or multiple socket motherboards the system will scale to well over one
hundred cl
ients. You only have to eliminate bottlenecks on the LAN by using a
gigabit per second connection between server and switch. 100Mbps works well from
switch to client. 10Mbps works, too, but there are noticeable delays.

What an LTSP Server wants

The specs f
or an LTSP server are pretty simple:



512MB RAM for the idling system with all of its services



50MB per client to hold user data and the first copy of common applications



100MHz of 32 bit processing power or about 75MHz of 64 bit power per
client. AMD or In
tel work, but AMD gives more computing power per watt and
has an on
-
chip memory controller in 64 bit. The competition between these two
makes price/performance good for our use. It is important to select components
that match motherboard/CPU/memory/NICs if

you build from parts.



A gigabit NIC for the private LAN (100 megabit is OK for small LANs with
patient users, random boots or client always on)



10/100 baseT NIC for the ISP

The gigabit NIC is optional unless you want to save seconds on the boot over the
n
etwork when everyone shows up to work in the same minute and transfers 4 MB of
kernel. Many motherboards come with a gigabit NIC and they are cheap. The
following examples don’t include a monitor, keyboard, mouse, CDROM drive or video
card which are only n
eeded for installation. The BIOS can be set up to boot on
restoration of power and to ignore lack of a keyboard. The X configuration can be
set to use a dummy driver when the video card is absent. The server can be
maintained remotely by SSH (Secure SHell)

or LTSP. A backup hard drive with USB
connection is also recommended.

An example of a server good for up to sixty clients:



AMD Opteron 170 dual core 2 MB cache CAD$519



4GB ECC DDR333 RAM CAD$500



ASUS A8N
-
E motherboard CAD$125



ATX case and power supply w/4
00
-
500W capacity CAD$200+



10/100 baseT NIC CAD$15



dual 200GB hard drives SATA CAD$210



Total CAD$1570

A good server for up to thirty clients could use the same setup but with an AMD64
3200 processor and 2GB non
-
ECC RAM, costing about CAD$1000.

For up to 10
clients, and modest services, use a recent desktop PC with 1GB of RAM
and an extra NIC.

For 120 clients, use a dual socket Opteron motherboard with suitable processors
and 6GB ECC registered RAM costing about CAD$4300 or more:



AMD Opteron 275 dual core 2MB

cache 2 X CAD$1353 = CAD$2706



ASUS K8N
-
DL motherboard CAD$287



ATX case and 500W power supply CAD$250



10/100 baseT NIC CAD$15



dual 200GB hard drives SATA CAD$210



6GB DDR400 ECC registered RAM 6 X CAD$150 = CAD$900



Total CAD$4368




Customizing thin client
behaviour

http://doc.ubuntu.com/edubuntu/edubuntu/handbook/C/customizing
-
thin
-
client.html

YouTube

http
://www.youtube.com/watch?v=NC
DfnImh67E


By default, most thin clients will automatically configure themselves
correctly, and just work when they're plugged in. However, sometimes
you may wish to customize their behavior. You would do this by
editing the
l
ts.conf

file.

Format of the lts.conf file

When LTSP was designed, one of the issues that needed to be dealt
with was varying hardware configurations for the thin client. Certainly,
whatever combination of processor, network card and video card
available t
oday would not be available in 3 months, when you want to
add more thin clients to the network.

So, LTSP.org devised a way of specifying the configuration of each thin
client. The configuration file is called
lts.conf

and it lives in the
/opt/ltsp/i386/et
c
directory.

The format of the lts.conf allows for 'default' settings and individual
thin client settings. If all of your thin clients are identical, you could
specify all of the configuration settings in the '[Default]' section.

Section headings

Section

headings begin with an identifier in square brackets. the
identifier can be one of:



a mac address for a workstation, in the form of
XX:XX:XX:XX:XX:XX, where X is the digits 0
-
9, or A
-
F. You
can usually read the mac address for a network card from
a stick
er on the card itself, or use some kind of network
tool to discover it. The
ifconfig

can tell you the mac
address of your network cards.



an IP address. You'll need to statically assign host IP
addresses for this to work, as by default, Edubuntu ships
with

a
dhcpd.conf

that hands out dynamic addresses. This
means there's no guarantee which host will get what IP
address.



a hostname. Same issue as an IP address, but additionally,
you must have either defined the hostname in DNS, or in
/etc/hosts
.



The specia
l section heading [Default]. This section can set
defaults that apply to all terminals.

Variable Assignments

After the section heading, you can then define variables. Variables are
ether boolean values, requiring a True/False or Y/N answer. Note that
you
can either use True or False, Yes or No, or Y or N. Whichever you
prefer. Other variables may simply be strings, supplied after the =
sign. The general format of an assignment looks like:

BOOLEAN_VARIABLE = True

STRING_VARIABLE = Information




Comments can be inserted into the file for your documentation
purposes. Comments start with a # character, and everything after the
# for the rest of the line is considered a comment.

Location of the lts.conf filename

In order to speed up LTSP, by def
ault, we're using NBD (Network Block
Devices) rather than NFS. The
/opt/ltsp/i386

still exists, but now, it's
compressed into a squashfs image, so it's much smaller than simply
exporting via NFS. This means that the client uses less network
bandwidth than
before. However, it would mean that every time you
change the
lts.conf

file, you'd have to re
-
create this image using the
command
ltsp
-
update
-
image
. This takes a while to do. So, in order
to avoid this, we've moved the
lts.conf

file to the TFTP directory,
in
/var/lib/tftpboot/ltsp/i386
. This means you can make changes to the
file immediately, and simply reboot the terminal, without recompiling
the image.

About using NBD instead of NFS

Using NBD instead of NFS has several advantages:



Using a squashfs image
we can now merge that together
in a unionfs to get writeable access which is a lot faster
during bootup.



A squashed root filesystem uses less network bandwidth.



Many users and administrators have asked us to eliminate
NFS, for reasons of site policy. Sin
ce the squashed image
is now served out by
nbd
-
server
, which is an entirely
userspace program, and is started as the user nobody, this
should help to eliminate concerns over NFS shares.

However, some people still want to use NFS. Fortunately, it's easy to

switch back to NFS, if it's so desired:



On the server, use the
chroot

command to maintain the
LTSP chroot:



sudo chroot /opt/ltsp/i386





Now edit
/etc/default/ltsp
-
client
-
setup

and change the
value of the root_write_method vari
able to use bind
mounts instead of unionfs, it should look like this
afterwards:



root_write_method="bind_mounts"





Next, create the file
/etc/initramfs
-
tools/conf.d/ltsp

and
add the following line (set the value of the BOOT vari
able
to nfs):



BOOT=nfs





Regenerate the initramfs:



update
-
initramfs
-
u





Hit CTRL
-
D to exit the chroot now. Make sure LTSP uses
the new initramfs to boot:



sudo ltsp
-
update
-
kernels




Sample lts.conf file

Here is an example of the lts.conf file:

################

# Global defaults for all clients

# if you refer to the local server, just use the

# "server" keyword as value

# see lts_parameters.txt for valid values

#############
###

[default]


X_COLOR_DEPTH=16


LOCALDEV=True


SOUND=True


NBD_SWAP=True


SYSLOG_HOST=server


XKBLAYOUT=de


################

#[MAC ADDRESS]: Per thin client settings

################

[00:11:25:84:CE:BA]


XSERVER = vesa


X_MOUSE_DEV
ICE=/dev/ttyS0


X_MOUSE_PROTOCOL=intellimouse


###############

# A Thin Client Print server

# (switch off X by pointing tty7 to shell,

# to save ressources)

###############

[00:11:25:93:CF:00]


PRINTER_0_DEVICE=/dev/usblp0


SCREEN_07=shell


######
#########

# A workstation that executes a specific

# command after login

###############

[00:11:25:93:CF:02]


LDM_REMOTECMD=/usr/bin/myloginscript



The LDM display manager

The LTSP Display Manager, or
ldm

is the display manager speci
fically
written by the LTSP project to handle logins to a GNU/Linux server. It
is the default display manager for LTSP thin clients running under
Edubuntu, and has a lot of useful features:



It is written in C, for speed and efficiency on low end
clients.



It supports logging in via either a greeter (a graphical login
application) or autologin.



It can be configured to encrypt X Windows traffic, for
increased security, or leave it unencrypted, for better
performance on slower clients.



It contains a simple
load
-
balancing system, to allow the
system administrator to allow load balancing across
several servers.

We'll go over the
lts.conf

entries you'll need to control these features
below.

Theory of operation

To help understand the following sections, a bit
of an explanation of
how
ldm

does it's work is needed. Most thin client display managers
tend to run up on the server. The
ldm

display manager is unique in
that it runs on the thin client itself. This allows the thin client to have a
lot of choice as to ho
w it will set up the connection. A typical login
session goes as follows:



ldm

launches and starts up the X Windows display on the
thin client.



ldm

starts up the greeter, which is a graphical program
which presents the user with a nice login display and
a
llows them to select their session, language, and host
they'd like to log into.



ldm

collects the information from the greeter, and starts
an ssh session with the server. This ssh connection is used
to create an ssh master socket, which is used by all
subs
equent operations.



Now, the users selected session is started via the master
socket. Depending on whether or not an encrypted
connection has been requested, via the LDM_DIRECTX
parameter, the session is either connected back to the
local display via the s
sh tunnel, or via a regular TCP/IP
connection.



During the session, any memory sticks, or other local
devices that are plugged in, communicate their status to
the server via the ssh control socket.



When the user exits the session, the ssh connection is
cl
osed down, the X server is stopped, and
ldm

restarts
itself, so everything starts with a clean slate.

Encrypted versus unencrypted sessions

By default, LTSP5 encrypts the X session between the server. This
makes your session more secure, but at the cost o
f increased
processing power required on the thin client and on the server. If
processing power is a concern to you, it's very easy to specify that the
connection for either an individual workstation, or the default setting
should use an unencrypted connec
tion. To do so, simply specify:

LDM_DIRECTX=True



in your
lts.conf

file in the appropriate stanza.

Auto login features

This new version of LDM supports auto login of accounts, if specified in
the
lts.conf

file. Simply create a config stan
za for each of the
terminals you want to log in automatically (you can use either MAC
address, IP address, or hostname) and specify the variable
LDM_USERNAME

and
LDM_PASSWORD
. Note that you must have
created these accounts on the server, with the passwords

specified. An
example will serve to illustrate how to use this:

[00:E0:81:27:D6:AE]


LDM_USERNAME=station1


LDM_PASSWORD=sekrit1


[00:30:48:73:FC:A3]


LDM_USERNAME=station2


LDM_PASSWORD=sekrit2



Load balancing features

In thi
s version of LTSP, there's a simple load
-
balancing solution
implemented that allows administrators to have multiple Edubuntu
servers on the network, and allow the thin client to pick which one of
the servers it would like to log into.

The host selection s
ystem is simple and flexible enough to allow
administrators to implement their own policy on how they want the
load balancing to happen: either on a random, load
-
based, or round
robin system. See
the section called “Multiple server setup”

for details.

General thin client parameters

There are several variables that one can define in the lts.conf file
which control how the thin client inte
racts with the server. These are:

SERVER


This is the server that is used for the XDM_SERVER,
TELNET_HOST, XFS_SERVER and SYSLOG_HOST, if any of
those are not specified explicitly. If you have one machine
that is acting as the server for everything, then
you can
just specify the address here and omit the other server
parameters. If this value is not set, it will be auto
detected.

SYSLOG_HOST


If you want to send logging messages to a machine other
than the default server, then you can specify the machine
here. If this parameter is NOT specified, then it will use the
'SERVER' parameter described above.

NBD_SWAP


Set this to
Y

if you want to turn on NBD swap. The default
is
Y
.

SWAP_SERVER


The NBD swap server can exist on any server on the
network that is
capable of handling it. You can specify the
IP address of that server. The default is whatever the
value of SERVER set to.

NBD_PORT


The port on which NBD swapping will occur. This is set to
9572 by default.

USE_LOCAL_SWAP


If you have a hard drive insta
lled in the thin client, with a
valid swap partition on it, this parameter will allow the thin
client to swap to the local hard drive. The default is
N
.

DNS_SERVER


Used to build the resolv.conf file. Not needed by default.

SEARCH_DOMAIN


Used to build t
he resolv.conf file.

SOUND


This parameter enables sound for the thin client. The
default is
Y
.

LOCALDEV


This parameter enables local devices support, like CD's and
USB sticks. Users plugging them in should see them on the
desktop, after they've been add
ed to the fuse group on the
server. You can do this by going to: System


Administration


Users and Groups selecting the user,
clicking on "Properties", the going into the "User
Privileges" tab, and making sure the "Allow use of FUSE
filesystems..." box i
s checked. The default is:
Y
.

Screen Scripts

Screen scripts are how LTSP determines what type of login will run on
what virtual screen. Most GNU/Linux machines have 12 virtual
consoles, which you can access by pressing Control
-
Alt
-
F1, through
Control
-
Alt
-
F12. There is a text based getty that is started on screen
1, but you normally can't log into it, as there are no local users on the
thin client.

However, for debugging purposes, you may want to set up root to log
in on the thin client. You may need to do

this if you're debugging
problems with local devices, for example. Fortunately, it's easy to do:
on the server, just chroot into the LTSP chroot, and set the password
with passwd.

sudo chroot /opt/ltsp/i386

passwd



By default, if there's noth
ing else mentioned in
lts.conf
, an LDM
session will be started on screen 7.

Parameters relating to screen scripts


SCREEN_01

thru
SCREEN_12


Up to 12 screen scripts can be specified for a thin client.
This will give you up to 12 sessions on the thin clien
t, each
accessible by pressing the Ctrl
-
Alt
-
F1 through Ctrl
-
Alt
-
F12
keys.

SCREEN_07 = ldm

SCREEN_02 = shell



Currently, possible values include:



ldm
: This is the default display manager. It collects
a username and password, an
d then establishes a
secure, encrypted tunnel to the server via
ssh
. This
should be good for most environments. Edubuntu
deployments with lower
-
powered clients or servers
may find that the extra overhead involved in
encrypting the X traffic might slow thei
r sessions,
and may wish to enable the
LDM_DIRECTX

parameter described in
the section called “The LDM
display manager”




sd
m
: Similar in functionality to ldm, but a little less
graphically intensive.



startx
: Older X connection requiring the use of
XDMCP to connect to the server. Some legacy
installations may want to use it, however, the
intruduction of the
LDM_DIRECTX

paramet
er has
eliminated much of the need to run it. Enabling this
will require you to turn on XDMCP for the
gdm

login
manager. As an administrative user, go to System


Administration


Login Window and in the "Remote"
tab, change the drop down to "Same as local
".
Additionally, you may wish to click on the "Configure
XDMCP" button on the lower corner, and increase the
"Maximum remote sessions" to something a little
higher than the number of thin clients you have.
Please note that doing this means local devices
wi
ll not work for you, as they rely on the ssh
tunnel that ldm provides.



telnet
: Text screen telnet into whatever host
TELNET_HOST is set to. See below for an
explanation.



shell
: spawns a shell on the thin client. Useful for
testing.



rdesktop
: spawns an r
desktop session to a remote
windows server. Note that you must have the
rdeskop

package installed in the chroot.

Look in the
/opt/ltsp/i386/usr/lib/ltsp/screen.d

directory
for more scripts, or write your own, and put them there.

TELNET_HOST


If the thin
client is setup to have a character based
interface, then the value of this parameter will be used as
the host to telnet into. If this value is NOT set, then it will
use the value of
SERVER

above.

Modules and startup scripts

For the most part, LTSP does a

very good job of detecting what
hardware's on your thin client. However, it's possible that you may
want to manually specify a kernel module to load after boot.
Alternatively, you may have a script you've written that you've put in
the chroot, and want to

make sure gets run at startup. LTSP provides
some hooks to allow you to do this.

MODULE_01

thru
MODULE_10


Up to 10 kernel modules can be loaded by using these
configuration entries. The entire command line that you
would use when running insmod can be s
pecified here. For
example:

MODULE_01 = uart401.o

MODULE_02 = "sb.o io=0x220 irq=5 dma=1"

MODULE_03 = opl3.o



If the value of this parameter is an absolute pathname,
then
insmod

will be used to load the module. Otherwise,
modpr
obe

will be used.

In normal circumstances, you shouldn't need to specify
anything here, as most hardware will be auto
-
detected.

RCFILE_01

thru
RCFILE_10


Additional RC scripts can be executed by the
ltsp
-
client
-
setup

script. Just put the script in the
/o
pt/ltsp/i386/etc/init.d

directory, and specify the name
of the script in one of these entries.

X
-
Windows parameters

Setting up X windows on the thin client's normally a pretty easy
operation. The thin client uses X.org's own auto configuration mode to
let

X determine what it thinks is installed in the box. The thin client
just runs the command
Xorg
-
configure
, and then uses that output,
slightly modified, for the X config file.

However, sometimes, this doesn't always work. Either due to
strange/buggy hard
ware, or buggy drivers in X.org, or because X
detects default settings that you don't want. For instance, it may
detect that your monitor is capable of doing 1280x1024, but you'd
prefer it to come up in 1024x768 resolution. Fortunately, you can
tweak indiv
idual X settings, or, alternatively, simply provide your own
xorg.conf

to use.

X.org configuration


X_CONF


If you want to create your own complete X.org config file,
you can do so and place it in the
/opt/ltsp/i386/etc/X11

directory. Then, whatever you d
ecide to call it needs to be
entered as a value for this configuration variable. For
example:

X_CONF = /etc/X11/my
-
custom
-
xorg.conf



Note that for the thin client, you reference it from
/etc/X11
.

X_RAMPERC


Some programs alloc
ate a large amount of ram in the
X.org server running on your thin client. Programs like
Firefox

and
Evince

can use up so much ram, that they
eventually exhaust all your physical ram, and NBD swap,
causing your thin client to crash. If you find your client
s
being booted back to a login prompt, or freezing up when
viewing certain PDF's or web pages, this may be the
problem.

The X_RAMPERC variable stands for X RAM PERCent, and
is a number between 0 and 100 that specifies how much of
the free space on your th
in client X.org is allowed to
consume. You'll generally want to set it at something lower
than 100 percent, if you're having problems.
Experimentation has shown a value between 80 and 90 will
usually keep the terminal alive. What will then happen is
the pr
ogram consuming the memory will die, as opposed
to the thin client itself. If you're having unexplained
terminal problems, specifying:

X_RAMPERC = 80



in your
lts.conf

file may improve things.

XDM_SERVER


If you're using the o
lder
startx

screen script, and need to
specify a different server, then you can specify the server
here. If this parameter is NOT specified, then it will use the
'SERVER' parameter described above.

XSERVER


You can use this parameter to override which X s
erver the
thin client will run. For PCI and AGP video cards, this
parameter should not be required. The thin client should
normally be able to auto
-
detect the card.

If, for some reason you do need to manually set it, here
are the valid values:



ark



ati



at
imisc



chips



cirrus_alpine



cirrus



cirrus_laguna



cyrix



dummy



fbdev



fglrx



glint



i128



i740



i810



imstt



mga



neomagic



newport



nsc



nv



r128



radeon



rendition



riva128



s3



s3virge



savage



siliconmotion



sis



sisusb



tdfx



tga



trident



tseng



v4l



vesa



vga



via



vmware



voodoo

X_M
OUSE_DEVICE


This is the device node that the mouse is connected to. If
it is a serial mouse, this would be a serial port, such as
/dev/ttyS0

or
/dev/ttyS1
. This is not needed for PS/2
or USB mice, as they are auto
-
detected.

X_MOUSE_PROTOCOL


Should be au
to
-
detected. However, valid entries include:



sunkbd



lkkbd



vsxxxaa



spaceorb



spaceball



magellan



warrior



stinger



mousesystems



sunmouse



microsoft



mshack



mouseman



intellimouse



mmwheel



iforce



h3600ts



stowawaykbd



ps2serkbd



twiddler



twiddlerjoy

X_MOUSE_EMULATE3BT
N


Normally unset, may need to be set to
Y

for certain 2
button mice.

X_COLOR_DEPTH


This is the number of bits to use for the color depth.
Possible values are
8
,
16
,
24

and
32
. 8 bits will give 256
colors, 16 will give 65536 colors, 24 will give 16 milli
on
colors and 32 bits will give 4.2 billion colors! Not all X
servers support all of these values. The default value for
this is
24
.

USE_XFS


You have a choice of running the X Font Server (XFS) or
reading the fonts through the file system. XFS has been
p
retty much superceeded by the RENDER extention of
X.org, but for special cases, you can specify it. The 2
values for this option are
Y

and
N
. The default value is
N
.
If you do want to use a font server, then you can use the
XFS_SERVER

entry to specify whic
h host will act as the
font server.

XFS_SERVER


If you are using an X Font Server to serve fonts, then you
can use this entry to specify the IP address of the host that
is acting as the font server. If this is not specified, it will
use the default server
, which is specified with the
SERVER

entry described above.

X_HORZSYNC


This sets the X.org
HorizSync

configuration parameter.
This should be auto
-
detected for your monitor, however, if
you want to force a lower resolution, use this parameter to
do so.

X
_VERTREFRESH


This sets the X.org
VertRefresh

configuration parameter.
This should be auto
-
detected for your monitor. If you need
to force a lower resolution, use this parameter to do so.

X_VIDEORAM


This sets the X.org
VideoRam

configuration parameter.
T
his should be auto
-
detected for your monitor. If you need
to force a different video ram setting, use this parameter
to do so.

X_OPTION_01 through X_OPTION_12


This allows you to specify
Option

settings in the
xorg.conf

file, to add options to the video d
river. A common use for
this will be to test turning off accelleration in your driver, if
you're having trouble. An example usage would be:

X_OPTION_01 = "
\
"NoAccel
\
""

X_OPTION_02 = "
\
"AnotherOption
\
"
\
"True
\
""



. You probably
won't need these except in special
circumstances.

X_MODE_0, X_MODE_1, and X_MODE_2


These sets the X.org
ModeLine

configuration. For
example, if your thin client comes up in a higher resolution
than what you want, say, 1280x1024, specifying:

X_MODE_0 = 1
024x786



should get your desired resolution on startup.

Printer configuration parameters

Sometimes, it's convenient to hang a printer off of a thin client in a
lab, so that the computer lab has access to local printing resource
s.
Fortunately, LTSP can accomodate printing on the workstation.

LTSP can connect up to 3 printers per workstation to the network via a
small daemon called JetPipe. Both parallel and USB printers are
supported. JetPipe makes the printer look like a standa
rd HP Jet Direct
printer interface. You can then create any cups printer on your server,
and point it at the printer via a Jet Direct connection.

In your
dhcpd.conf

file that controls your thin client IP assignments,
you'll want to assign a static IP for
the terminal with the printers, to
guarentee that it gets the same IP address every time it boots.
Otherwise, your printing won't work if the terminal leases a different IP
address.

Printing related parameters


PRINTER_0_DEVICE


The device name of the pri
nter. Names such as
/dev/lp0
,
or
/dev/usblp0

are allowed.

PRINTER_0_PORT


The TCP/IP Port number to use. By default, it will use '
9100
', for PRINTER_0_DEVICE, '
9101
' for
PRINTER_1_DEVICE, and '
9102
' for PRINTER_2_DEVICE.

Keyboard parameters

All of the k
eyboard support files are copied into the /opt/ltsp/i386
hierarchy, so configuring international keyboard support is simply a
matter of configuring X.org. There are several configuration
parameters for this.

The values for the above parameters are from th
e X.org
documentation. Whatever is valid for X.org is valid for these
parameters.

We would like to add documentation to show what values are needed
for each type of international keyboard. If you work with this and can
configure your international keyboar
ds, feedback to Edubuntu would
be greatly appreciated.

CONSOLE_KEYMAP


Allows you to specify a valid console keymap for
TELNET_HOST sessions. Default is
en
.

XKBLAYOUT


Consult the X.org documentation for valid settings.

XKBMODEL


Consult the X.org docume
ntation for valid settings.

XKBVARIANT


Consult the X.org documentation for valid settings.

XKBRULES


Consult the X.org documentation for valid settings.

XKBOPTIONS


Consult the X.org documentation for valid settings.







Theory of operation




Multiple server setup




7.2. Troubleshooting DHCP

ftp://ftp.ulakbim.gov.tr/ltsp/docs/ltsp
-
4.1
-
en.html#AE
N801

Youtube

http://www.youtube.com/watch?v=OcFnIPhCRhw


Once the network card is initialized, it will send out a DHCP broadcast on the local
network, looking for a DHCP server.

If the workstation

gets a valid reply from the DHCP server, then it will configure the
network card. You can tell if it worked properly if the IP address information is displayed
on the screen. Here's an example of what it should look like:

ROM segment 0x0800 length 0x4000
reloc 0x9400

Etherboot 5.0.1 (GPL) Tagged ELF for [LANCE/PCI]

Found AMD Lance/PCI at 0x1000, ROM address 0x0000

Probing...[LANCE/PCI] PCnet/PCI
-
II 79C970A base 0x1000, addr
00:50:56:81:00:01

Searching for server (DHCP)...

<sleep>

Me: 192.168.0.1, Server: 1
92.168.0.254, Gateway 192.168.0.254

If you see the line that starts with 'Me:', following by an IP address, then you know that
DHCP is working properly. You can move on to checking to see if TFTP is working.

If instead, you see the following message on
the workstation, followed by lots of <sleep>
messages, then something is wrong. Although, it is common to see one or two <sleep>
messages, after which the dhcp server replies.

Searching for server (DHCP)...

Figuring out what is wrong can sometimes be di
fficult, but here are some things to look
for.


7.2.1. Check the connections

Is the workstation physically connected to the same network that the server is connected
to?

With the workstation turned on, make sure that the link lights are lit at all of the
connections.

If you are connecting directly between the workstation and the server (no hub or switch),
make sure that you are using a cross
-
over cable. If you are using a hub or switch, then
make sure you are using a normal straight
-
through cable, both bet
ween the workstation
and hub, and also between the hub and server.


7.2.2. Is dhcpd running?

You need to determine whether

dhcpd

is running on the server. We can find the answer a
couple of ways.

dhcpd

normally sits in the background, listening on udp por
t 67. Try running the

netstat

command to see if anything is listening on that port:

netstat
-
an | grep ":67 "

You should see output similar to the following:

udp 0 0 0.0.0.0:67 0.0.0.0:*

The 4th column contains the IP address and port,

separated by a colon (':'). An address of
all zeroes ('0.0.0.0') indicates that it is listening on all interfaces. That is, you may have an

eth0

and an

eth1

interface, and

dhcpd

is listening on both interfaces.

Just because netstat shows that something i
s listening on udp port 67, it doesn't mean that
it is definitely

dhcpd

that is listening. It could be

bootpd
, but that is unlikely, because

bootp

is no longer included on most distributions of Linux.

To make sure that it is the

dhcpd

that is running, try
running the

ps

command.

ps aux | grep dhcpd

You should see something like the following:

root 23814 0.0 0.3 1676 820 ? S 15:13 0:00 /usr/sbin/dhcpd

root 23834 0.0 0.2 1552 600 pts/0 S 15:52 0:00 grep dhcp

The first line shows that

dhcpd

is runni
ng. The second line is just our

grep

command.

If you don't see any lines showing that dhcpd is running, then you need to check that the
server is configured for runlevel 5, and that

dhcpd

is configured to start in runlevel 5. On
Redhat based systems, you
can run the

ntsysv

and scroll down to make sure

dhcpd

is
configured to start.

You can try starting

dhcpd

with this command:

service dhcpd start

Pay attention to the output, it may show errors.


7.2.3. Double
-
check the dhcpd configuration

Does the
/etc/d
hcpd.conf

file have an entry for our workstation?

You should double
-
check the 'fixed
-
address' setting in the config file, to make sure it
exactly matches the card in the workstation.


7.2.4. Is ipchains or iptables blocking the request?

7.2.4.1. Checking
for ipchains

Run the following command to see what it says:

ipchains
-
L
-
v

If you see something like this:

Chain input (policy ACCEPT: 229714 packets, 115477216 bytes):

Chain forward (policy ACCEPT: 10 packets, 1794 bytes):

Chain output (policy ACCEPT:
188978 packets, 66087385 bytes):

Then it isn't ipchains that is getting in the way.


7.2.4.2. Checking for iptables

Run the following command to see what it says:

iptables
-
L
-
v

If you see something like this:

Chain INPUT (policy ACCEPT 18148 packet
s, 2623K bytes)


pkts bytes target prot opt in out source
destination


Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)


pkts bytes target prot opt in out source
destination


Chain OUTPUT (policy ACCEPT 1
7721 packets, 2732K bytes)


pkts bytes target prot opt in out source
destination

Then it is not iptables getting in the way.


7.2.5. Is the workstation sending the request?

Try watching the
/var/log/messages

file while the work
station is booting. You can do
that with the following command:

tail
-
f /var/log/messages

This will 'follow' the log file as new records are written to it.

server dhcpd: DHCPDISCOVER from 00:50:56:81:00:01 via eth0

server dhcpd: no free leases on subnet

WORKSTATIONS

server dhcpd: DHCPDISCOVER from 00:50:56:81:00:01 via eth0

server dhcpd: no free leases on subnet WORKSTATIONS

If you see messages like those above, saying 'no free leases', that indicates that

dhcpd

is
running, but it doesn't know anything

about the workstation that is requesting an IP
address.



http://www.youtube.com/watch?v=Wi_jY4iE_
-
M&feature=related


Wyse thin client overview. Discusses benefits of thin c
l
ient

technology.


Resources

http://www.disklessworkstations.com/blog/how
-
to
-
install
-
ltsp
-
ubuntu
-
11
-
04/



http://smashingweb.ge6.org/root
-
login
-
in
-
ubuntu
-
11
-
10/



https://www.edubuntu.org/documentation/11.10/installation
-
guide



http://www.informit.com/articles/article.aspx?p=1643921&seqNum=4


Linux Terminal Server Project (LTSP) is a free and open source terminal server
for Linux that allows many people to simultaneously use the same computer.
A
pplications run on the server with a terminal known as a thin client (also known
as an X terminal) handling input and output. Generally, terminals are low
-
powered, lack a hard disk and are quieter and more reliable than desktop
computers because they do no
t have any moving parts.


This technology is becoming popular in schools as it allows the school to provide
pupils access to computers without purchasing or upgrading expensive desktop
machines.[citation needed] Improving access to computers becomes less c
ostly
as "new" thin client machines can be older computers that are no longer suitable
for running a full desktop OS. By extending the useful life of obsolescent
computers, costs can be cut. Even a relatively slow CPU with as little as 128MB
of RAM can del
iver excellent performance as a thin client. In addition, the use
of centralized computing resources means that more performance can be gained
for less money through upgrades to a single server rather than across a fleet of
computers.


By converting existi
ng computers into thin clients, an educational institution can
also gain more control over how their students are using computing resources as
all of the user sessions can be monitored on the server. See Epoptes (A Lab
Management Tool).


In its current for
m (v5.x), LTSP relies on distributions to integrate the LTSP
architecture into their respective products. In the v4.x series, LTSP was an
add
-
on package to any distribution. Several distributions integrate LTSP either
into their mainline (Ubuntu, Debian) o
r as a separate product, such as Edubuntu
(Ubuntu), K12LTSP (CentOS) and Skolelinux (Debian), KIWI
-
LTSP (SUSE). LTSP
is a registered trademark of DisklessWorkstations.com, LLC.


LTSP to Windows Terminal Server (RDP)

http://www.youtube.com/watch?v=zJmMcNPBgig


LTSP
-
Cluster

:

Windows

Terminal

Serve
r

application

integration

with

U
buntu

thin

client


http://www.youtube.com/watch?v=8OEs2AWFTWc



H
OWTO: Install LTSP server in Ubuntu Linux


http://www.youtube.com/watch?v=8yD0QV_Cm2w


Setting up a server for PXE network booting

h
ttp://www.debian
-
administration.org/articles/478


HOWTO: Install LTSP server in Ubuntu Linux


http://www.youtube.com/watch?v=8yD0QV_Cm2w


PXE Booting

http://pxe.dev.aboveaverageurl.com/index.php/PXE_Booting

http://www.debian
-
administration.org/articles/478

http://www.linuxjournal.com/magazine/pxe
-
magic
-
flexible
-
network
-
booting
-
menus

http://www.syslinux.org/wiki/index.php/PXELINUX



Wyse Thin Client
Specifica
tions


http://www.parkytowers.me.uk/thin/wyse/3125se/index.shtml


Reviews

http://edwinfriesen.nl/content/?p=451

http://www.10zig.com/images/thinclientsforiSeries.pdf





Other Resources


http://www.retrevo.com/s/Wyse
-
3
125SE
-
Desktops
-
review
-
manual/id/23511bh644/t/1
-
2/




Thin Clients


Linux/LTSP thin clients in education

http://www.youtube.com/watch?v=V3u44VeX73M&feature=related


Ubuntu
Thin Clie
nts

https://help.ubuntu.com/community/UbuntuLTSP


LTSP cluster

https://help.ubuntu.com/community/UbuntuLTSP/LTSP
-
Cluster





Comparing web browsing performance


http://www2003.org/cdrom/papers/refereed/p741/p741
-
yang.htm

http
://net.educause.edu/ir/library/html/cmr9934/cmr9934.html


In measuring and comparing the web browsing performance of thin
-
client systems
against the traditional HTTP clients under wireless network conditions of various
quality, we have demonstrated the co
nventional wisdom that web browsing should be
done on a locally running browser does not apply under degraded network conditions.
Our findings indicate that the conventional HTTP clients have the performance
advantage when the network conditions are close
to ideal, but when the wireless
client encounters a degraded network quality, browsing the web through a thin
client ensures more reliable web transactions and faster response time.

REVIEW

Case Study

JISC
-

Greening ICT: Case study Queen Margaret Universit
y

http://www.youtube.com/watch?v=re8eXdRFfks


ICT

Green

Boot

Camp

Session

1

-

part

6


http://www.youtube.com/watch?v=7W0B_MfmAJY&feature=results_video&playnex
t=1&list=PL39B2F1D10E67ABA4






















GENERAL RESOURCES


FFITS.ORG


FFITS.ORG is a global, non
-
profit organisation. The organisation's mission is to
promote the sustain
able use of technology through Educating individuals,
corporations and government;


http://www.ffits.org/


Information about assessment:
http
://www.tafensw.edu.au/courses/about/assessment_guide.htm



Tech Republic
-

this is comprehensive source of information on computer related
technical issues:
http://techrepublic.com

Windows IT Library
http://www.windowsitlibrary.com

https://www.skillsonline.net.au
/

For more information, contact SkillsOnline,
telephone: (02) 9244 5073, fax: (02) 9266 8549, email:
skillsonline@det.nsw.edu.au

.


E
xample of expectations of a client in website design

http://www.layoutgalaxy.com/pdf/news1.pdf

Great podcasts

http://itunes.apple.com/podcast/science
-
update
-
podcast
-
for/id102800259





A good example of a recommendation report which has much in common with a
feasibility report can be found at:

http://www.io.com/~hcexres/tcm1603/acchtml/recomx2a_non.html

-

this links to
more up to date website

(www.io.com/~hcexres/textbook)





National Centre for Sustainability, October

2006,
Guideline Brief Knowledge &
Skills for Sustainability
, Swinburne University of Technology, contains references
to many resources.