Building a Call Center with LTSP and Soft Phones
A new customer approached us with a need to provision the office. The customer was receptive to open-source software and was interested in using Linux. Being a nonprofit organization, the budget for the project was tight.
We provisioned the new office with a server running software from the Linux Terminal Server Project (LTSP) to make the desktop economical from the start. We then installed an Asterisk server as a PBX for the call center. To make things easier for the staff, we wanted to have a working soft phone on their terminals with headsets for hands-free operation.
This article discusses the installation and use of the LTSP build environment to build Qt and KPhone so the staff members could run KPhone locally on their terminals. I do not discuss the installation of Linux or Asterisk here, but I have included the relevant context for KPhone, which resides in the Asterisk sip.conf file. We used Gentoo for this particular LTSP server, but any Linux distribution can do the job.
The main software packages needed for this project were LTSP, KPhone and the LTSP build environment (LBE). LTSP easily provides thin-client access to a main server. We often recommend LTSP as an economical way to equip an office, because it focuses monetary resources on the main server rather than on the individual stations. The incremental cost of adding a new user to the office is relatively small, and administration is simplified.
The customer's new office is intended to be a small call center, so hands-free phone operation is a big benefit. We wanted to try using headsets and amplifiers that use a computer sound card for their connectivity rather than hardware phones. These headsets, coupled with software SIP phones on each user's local station, allowed us to meet their phone needs without having to buy separate phone equipment.
Because we already were using Asterisk (see the on-line Resources) as the PBX for the office, it seemed logical to use an open-source software phone. We decided to use KPhone (see Resources) as the software SIP phone, because it had proven reliable on standalone systems previously tested. One of the drawbacks of every SIP soft-phone package we investigated at the time was none supported a network-enabled sound protocol. As a result, they were required to run locally on the station that physically has the sound card. As these stations are thin clients that boot from the main server, KPhone needs to be resident in the filesystem on each station. When a user runs KPhone from the desktop, which runs on the server, the KPhone process needs to start in the local terminal environment.
KPhone is not a standard part of the LTSP package, so we needed to build it inside the local stations' root filesystem that is NFS-mounted from the server at boot time. Building software for the terminals' root filesystem requires LBE (see Resources). Building software in LBE also requires that all necessary libraries be present in the filesystem. One of the other benefits of KPhone is the Qt library is the only library required beyond those already in LTSP.
Installation and configuration of LTSP are detailed in the LTSP documentation (see Resources). One deviation from the standard install of LTSP is that the DHCP configuration file must reference the root filesystem that LBE builds rather than the root filesystem installed with the LTSP package (Listing 1).
Listing 1. Our LTSP Section of dhcpd.conf
# LTSP Path Options option root-path "192.168.42.254:/usr/local/src/lbe/opt/ltsp/i386"; #LTSP boot image (relative to the TFTP root) filename "/pxe2/pxelinux.0";
Technically, we did not need the LTSP package because LBE includes the necessary boot image and root filesystem. However, if you are not already familiar with LTSP, I recommend you install that package first and get it operational. Deploying LTSP involves the configuration of other standard software included with almost all Linux distributions: DHCP for assigning IP addresses, boot images and root filesystem information for the stations; TFTP for client stations to retrieve their boot images; and NFS for thin clients to remote-mount their root filesystems and the /home filesystem for running remote applications. Installing LTSP provides demo configurations for all of these packages that makes setup much easier for a novice.
The main LTSP documentation describes well most of the preparation for running applications locally on the clients. Their installation and configuration also are covered on the LTSP 4.1 Web page. In addition to the software mentioned above, you also need to configure SSH client and NIS on the server.
SSH is the means we used for starting the process on the remote client. Notice that the LTSP 4.1 documentation demonstrates the use of rsh for launching the applications. Although that would work, the required dæmons for rsh no longer are part of the LTSP package. SSH is now the norm for launching local applications. You can find information about preparing for SSH launching of local applications in the Local Applications section of the LBE documentation.
NIS is needed because the thin clients need to authenticate users through SSH as they launch the applications. NIS configuration is guided by the NIS HOWTO. One item that was not immediately obvious from the documentation was that NIS would complain that /etc/publickey was not present. Creating that file with touch /etc/publickey solved the problem.
Once all the supporting software is in place, configuring LTSP to run local applications is easy: set LOCAL_APPS = Y in /etc/lts.conf within the LTSP root filesystem. This causes the clients to mount the /home directory from the server with NFS. Also, NIS is made active by /var/yp/nicknames, /etc/yp/conf being created on the clients, domainname being run with the value of the NIS_DOMAIN entry in the lts.conf file and ypbind being run. The sshd dæmon also is activated on the client.
For SSH operations to be transparent to users, we need SSH keys created without expecting users to do it themselves. To accomplish that, we installed superadduser in Gentoo, which is reported to be adduser from Slackware (see Resources) and modified it to generate the SSH keys automatically for the user when the user is created (Listing 2).
Practical Task Scheduling Deployment
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.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- Stunnel Security for Oracle
- The Firebird Project's Firebird Relational Database
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
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