MILLE-XTERM and LTSP
Diskless terminals need a way to store configuration data, such as screen resolution and available printers. Under LTSP, a central file called lts.conf stores the configuration of terminals and has to be edited manually. With thousands of terminals, you need a hierarchical database—that's the purpose of the configurator.
This component is written in PHP and has two interfaces. The first is dedicated to terminals. During the boot process, the terminal requests its configuration from the server using its MAC address as a parameter. The server generates the corresponding configuration and sends it to the terminal in the standard lts.conf format. A wrapper around the getltscfg command ensures backward compatibility with the other LTSP scripts.
The other interface lets administrators manage the configuration of the terminals via a Web browser. Administrators can organize terminals hierarchically by groups and apply configurations according to specific criteria, such as location or hardware type. But the configurator serves yet another function. It is designed to work with links, a console text browser, as shown in Figure 3. The terminal can boot in a special admin mode that does not require running the X server. To boot in this mode, the option mode=admin is appended to the kernel options in the bootloader configuration. Then, links is launched with the terminal configurator URL and MAC. The administrator can change the terminal settings directly. When complete, the terminal reboots and receives its new configuration.
The configurator also is useful for building terminal inventories. Hardware information is sent to the configurator during the boot process. Administrators can generate reports regarding the state of the terminals. Also, every connection to the configurator is logged and then can be analyzed to determine terminal usage, user login information and much more. You know how managers like reports!
When a terminal boots, it requests a display from the application server. To dispatch users on available application servers, MILLE-XTERM provides a load balancer. The first version of the load balancer (proof of concept) required five lines of PHP and returned a random address from a static list of application servers. Although simple, this approach had some drawbacks. First, an off-line server should be removed from the list and not be returned to the terminals. And, to provide reliable load balancing, several factors, such as number of processors, speed and load average have to be taken into account. Therefore, a much more robust and complete Python system has replaced the initial prototype (Figure 4). The load balancer agent runs on every application server, collecting data on the state of the application server and waiting for load-balancer server requests. The balancer is also a Python script that runs on the boot server. It contacts each load-balancer agent to determine its state and computes a weight for each server. A greater weight indicates that the server is less loaded and will be selected more often statistically to accept new users. A terminal request for an application server will then prompt the load-balancer server to get a randomly chosen application server in the weighted list.
Let's examine a concrete example: three application servers and two boot servers. Install the mille-xterm-lbagent package on each application server, and install mille-xterm-lbserver on each boot server. Make sure that the respective services are started, lbagent and lbserver. Add one node entry for each application server in the file /etc/mille-xterm/lbsconfig.xml:
<?xml version="1.0"?> <lbsconfig> <nodes> <group default="true" name="PROD"> <node address="http://10.0.0.1:8001" name="xapp1"/> <node address="http://10.0.0.2:8001" name="xapp2"/> <node address="http://10.0.0.3:8001" name="xapp3"/> </group> </nodes>
Copy this file on every boot server. Fire up a browser and enter the URL of the load balancer to see it in action. By default, lbserver listens on port 8008, so don't forget to append the port to the URL: http://localhost:8008/. IP addresses of the chosen application server will be displayed. Press the refresh button to get a new IP and you're set!
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
- Interview with Patrick Volkerding
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
- Tech Tip: Really Simple HTTP Server with Python
- Parsing an RSS News Feed with a Bash Script
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