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).
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- Server Hardening
- May 2016 Issue of Linux Journal
- EnterpriseDB's EDB Postgres Advanced Server and EDB Postgres Enterprise Manager
- The Humble Hacker?
- BitTorrent Inc.'s Sync
- The Death of RoboVM
- The US Government and Open-Source Software
- New Container Image Standard Promises More Portable Apps
- Open-Source Project Secretly Funded by CIA
- ACI Worldwide's UP Retail Payments
In modern computer systems, privacy and security are mandatory. However, connections from the outside over public networks automatically imply risks. One easily available solution to avoid eavesdroppers’ attempts is SSH. But, its wide adoption during the past 21 years has made it a target for attackers, so hardening your system properly is a must.
Additionally, in highly regulated markets, you must comply with specific operational requirements, proving that you conform to standards and even that you have included new mandatory authentication methods, such as two-factor authentication. In this ebook, I discuss SSH and how to configure and manage it to guarantee that your network is safe, your data is secure and that you comply with relevant regulations.Get the Guide