Linux Terminal Servers for Any Business
You can set up an LTS for your business in two core ways.
The first option, an LTSP install, requires more hands-on editing of configuration files. The benefit is that you control every aspect and the Linux flavor used. This is important if you already have an existing Linux server and want to add the power of LTSP.
The second option, a complete distribution install, consumes less time. It also offers the simplicity of including almost every necessary library and package. Two popular options include:
The K12LTSP.org version, which uses the latest Fedora Core.
The Edubuntu.org version, which uses Ubuntu (a Debian-based distribution).
If you don't already use one particular Linux flavor and if you are new to server administration, I strongly recommend that you use one of the ready distributions.
Skip to the next section if you want to use a Complete Distribution of LTSP.
However, for those who are well versed with their flavor of choice, I offer this section. It's a brief summary of tips that may help you over some installation hurdles, regardless of which flavor you've chosen.
Begin your installation by first visiting the LTSP.org Web site and wiki. They include some excellent details regarding various flavors and appropriate installation guides.
The LTSP Installer, on the LTSP.org Web site, works well and expedites the installation process. If you have an Internet connection to the LTS, this offers an optimal solution.
Have the following information ready prior to the installation:
Ethernet device name (eth0, eth1 and so on).
Ethernet MAC address(es).
Server's IP address (to be reserved in the DNS in most cases).
Subnet information (you may need to reserve a subset of IP addresses for LTS).
Router IP for your local area network (not the broadband router).
The libwww-perl package and others—you may need to address the libwww-perl dependency, which Jim McQuillan documented on the LTSP.org Web site. This runs the Perl file that actually installs and preps your LTS (ltspadmin).
Be careful which one you download; numerous iterations exist. For example, there are currently 75 RPMs just for the libwww-perl.
Please use your flavor's package manager—RPM, Synaptic PM or YaST—to add this and a number of other essential packages. This allows you to get many dependencies resolved in one fell swoop.
Set your temptations aside and try not to skip steps in the configuration menu (11 steps total). Some of the steps create essential config files that you will then need to edit or rename. To start, choose Show the status of all services from the main tool menu.
Your LTS must run in runlevel 5 to allow your thin-client connections to use graphics. If your server does not boot into runlevel 5, edit this file: /etc/inittab.
Edit the initialization default line to read:
When running in text mode, most flavors make available both vi and nano editors.
Ensure that you start all services prior to LST configuration. I'll use the DHCP service as an example, because it serves an essential role for an LTS, and you need to familiarize yourself with its configuration.
To force-start the DHCP process, you usually use the commands:
cd /etc/init.d ./dhcp3-server start
On some flavors, you may need to force-start the process with something similar to this:
Now, check your syslog to find out whether DHCP generated any errors:
cd /var/log tail syslog
DHCP will fail if you've incorrectly configured your subnet information.
Edit your DHCP configuration file:
On some flavors, the file may be located here:
I offer some more details regarding declaring a subnet in the Final Prototype Configuration section below.
With some flavors, you also may need to edit a file to declare your network device. Edit the line in /default/dhcpd3-server to include your specific Ethernet card(s), for example:
Most installations and configurations go smoothly without a lot of tinkering. But in case you run into hurdles, I include some of the key file locations below.
LTSP configuration files:
/usr/sbin/ltspcfg: the LTSP configuration tool.
/opt/ltsp/i386/etc/lts.conf: the primary configuration file.
DHCPD on some flavors:
/etc/init.d/dhcp3-server: executable script to start/stop service.
/etc/default/dhcpd3-server: default declaration of Ethernet device.
/etc/dhcp3/dhcpd.conf: the configuration file.
/var/lib/dhcp3/dhcpd.leases: the lease file associating IP leases.
DHCPD on other flavors:
/etc/init.d/dhcpd: executable script to start/stop service.
/etc/dhcpd.conf: the configuration file.
/var/lib/dhcp.leases: the lease file associating IP leases.
Hopefully, this section provided tips for a smooth installation. Now, jump ahead to the Final Prototype Configuration section.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Google's SwiftShader Released
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Interview with Patrick Volkerding
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide