Tag Archives: linux

xinetd as a poor man’s web server for issuing redirects

Set up a profile in /etc/xinetd.d called http:

# default: off
# description: Poor man’s http server that simply issues redirects.
service http
{
        flags           = REUSE
        socket_type     = stream
        wait            = no
        user            = root
        server          = /bin/echo
        server_args     = -e HTTP/1.1 301 Moved Permanently\r\nLocation: https://somewhere:8443\r\n
        disable         = no
}

 

(Re-)Start xinetd and now you have a simple redirect server – no httpd or other web server required.

Open-source IP telephony and the systems administration dilemma

1 Comment
To effectively set up, operate, and customize an open-source phone system like Asterisk or FreeSWITCH, you need to be competent at Linux systems administration.
When Asterisk and FreeSWITCH first came about, this was clear, because to go though the process of building the software and running it on your server, you had to decipher and successfully follow compiling instructions and use systems administration skills to get it to work.
Enter the Asterisk+FreePBX “distro.” There are several of them out there now, and their promise is big: insert this CD or flash drive, boot your server, and out comes a working phone system with a configuration GUI. The installers even do a decent job of making the system secure, so that you’re not the victim of the first script kiddie to happen upon your server’s IP address.
Linux is pretty good at figuring out hardware configurations and installing drivers and setting up automatically. So, chances are, when the installer is done, you really do have a working system.
At this point, the person maintaining the phone system has to hope that all problems can be effectively diagnosed and solved through the GUI, that nothing interesting happens with the underlying hardware or operating system that would require troubleshooting, that all logging is available through the GUI, and that the security of the GUI’s web server (typically Apache, firewalled by iptables) is correct. 
What if you are running Asterisk+FreePBX and have a SIP communications issue with a provider? You can’t turn on SIP debugging in FreePBX. You can use the Asterisk Logs module to get some log information but you’d do much better with command line tools such as grep. The truth is, inability to navigate Linux and the Asterisk command line is crippling.
Taking advantage of the open-source system’s openness to customize and add new features, such as Google Voice integration, means getting into the nuts and bolts. Or wait for someone else to write a (probably buggy) GUI module for you.
The fact is, if you want to be hands-off with systems administration, you need to get an appliance-like system such as SwitchVox or the big name brand small business PBXes. You have to pay for these. With your money you will get professional support to operate the low-level controls when an error appears, and you’ll get full GUI access (probably) to everything you should have access to. If it’s not in the GUI, you don’t have access to it.
If you want free, you need to learn systems administration so that you can be your own support person. The forums of FreePBX and various distros are full of questions like, “My phone doesn’t work, what do I do?” Ask them what appears in the logs and they have no idea what you are talking about. It just doesn’t work like that.
This is the dilemma. Free and customizable, with the cost of learning systems administration (and maybe some scripting/programming) skills, or hands-off with the cost of paying the vendor for the software and support?
To be a little more specific about what I am calling systems administration skills, here are the things I believe a person needs to know in order to competently install and maintain an open-source phone system, with or without a GUI, and whether from a CD-installed distro or from RPM packages or from source (not an exhaustive list):
  • ability to navigate the Linux filesystem comfortably and know where certain kinds of files typically are (logs are in /var/log, config files are in /etc, executables in /usr/bin and so on)
  • ability to use a text editor
  • handiness with find, grep
  • ability to correctly configure a firewall or packet filter such as iptables
  • ability to read syslogs and follow clues to solve a problem
  • familiarity with the operating system’s package system (such as yum/RPM with CentOS) so that he/she can easily load necessary tools
  • some familiarity with development tools such as make, gcc, configure scripts, cvs and svn, and the ability to decipher output they produce
  • ability to configure user accounts and passwords
  • some familiarity with network diagnostic tools like netstat and tcpdump
  • for FreePBX, familiarity with command-line MySQL for database troubleshooting
  • for Asterisk’s mail needs (voicemail or fax to e-mail), ability to configure some mail sender

Is it a tall order? Yes, there is a learning curve. It’s not Windows 7. But, like learning a foreign language, when you go into the foreign land (Linux console) and can speak the language, you are empowered.

ssmtp to handle your PBX’s e-mail

Here’s a simple how-to for processing the mail your Asterisk server generates, without running a full mail-transfer agent (MTA) like sendmail or postfix.

First, two assertions:

  • You need to deal with mail, even if you aren’t using Asterisk’s voicemail-attached-to-e-mail feature, because your system daemons like cron are generating mail that you may want to read.
  • Running a mail daemon of any kind is a waste of resources when all you really want to do is get the mail off your Asterisk server to some other server for processing.

In the past, a Linux admin would enable sendmail, set the domain name and basically be done. Mail would work on port 25, everyone would accept everyone else’s mail, and life was good. Then spammers ruined our lives and we have to use strange ports, domain validation and a bunch of other things to make ourselves an official mail server. That’s too much work, especially for a box that’s supposed to be a PBX, not a mail system. And if you’re on a residential Internet connection, forget it–you’re probably in every blacklist.

Enter ssmtp, the simple SMTP sender. We’ll use it to send both Internet e-mail, such as might be produced by Asterisk’s voicemail system, and local root-type mail (e.g. cron alerts) through a legitimate SMTP server. It does not run as a system daemon, only on-demand when something on the server generates e-mail. And it’s simple to set up.

Setup

  • Get the source: http://packages.debian.org/source/sid/ssmtp . The file you want is the orig.tar.bz2 file.
  • tar jxvf ssmtp_(version).orig.tar.bz2 to expand it.
  • ./configure --enable-ssl (if the build fails later, yum install openssl-devel [CentOS/RedHat] to get the necessary SSL libraries)
  • make then make install, as root. On a fresh install, sample configurations are installed in /usr/local/etc/ssmtp/. The program is in /usr/local/sbin/.
  • Edit /usr/local/etc/ssmtp/ssmtp.conf. For a basic configuration that will send all locally-addressed mail to a single address, and Internet-addressed mail to the appropriate address, this is all you need:
    # The person who gets all mail for userids < 1000 root=mailbox@example.com # The place where the mail goes. The actual machine name is required # no MX records are consulted. Commonly mailhosts are named mail.domain.com mailhub=smtp.gmail.com:587 # The full hostname hostname=asteriskbox.example.com fromlineoverride=yes authuser=USERNAME authpass=PASSWORD useTLS=yes useSTARTTLS=yes authmethod=LOGIN

    This example configuration, as you can guess, is for a Gmail account, and will also work with a Google Apps account. Since so many folks use Gmail, you could just cut and paste this, replacing the hostname and credentials with your own. If you are using a different SMTP server, adjust as necessary. With Gmail, the fromlineoverride won’t work–Gmail uses your Gmail address as the From. But it may work on other servers, especially if you are running your own mail server on a different box and send your mail to that.

  • Finally, get rid of sendmail and link to ssmtp in its place. yum erase sendmail will get rid of it from CentOS. Then ln -s /usr/local/sbin/ssmtp /usr/sbin/sendmail to trick your programs into believing sendmail is there, while ssmtp runs instead.

Test it out

You can install mailx with yum install mailx, then try both local mail and Internet mail:

mail root
mail youraddress@example.com

With mail, end your message by pressing Control-D.

Or you can use ssmtp directly: ssmtp root or sendmail root

Try sendmail -t and then fill out the header by typing to: address and so on.

Once you see that mail is moving, you’re done. If you encounter a problem, check /var/log/maillog.

More advanced

If you want to control where mail goes for individual local accounts, check out the revaliases file in /usr/local/etc/ssmtp/. Otherwise, all mail destined to local accounts with UID < 1000 will go to the mailbox specified in the root= line in the config.

Note

If you are using authenticated SMTP (as in the example config above), your ssmtp.conf file contains your SMTP password in plain text. If your box is secure and you are the only user of it, this may not matter. If other users are logging in to the box, and you don’t want them to be able to see the config, you can chmod 600 ssmtp.conf to make it readable only by root, then setuid root the ssmtp binary with chmod +s /usr/local/sbin/ssmtp .

References

Debian wiki on sSMTP

Installing Linux to a headless appliance

We have four x86-platform “server” appliances left over from an abandoned VoIP project by a consulting company that is now no longer in business. What to do with them? Install Linux, of course, and deploy them as remote network probes for a Smokeping network.

Problem: no console (headless), no peripherals, and it will only boot from the hard disk. It has four serial ports available and network connectivity.

Solution: load a modified Linux installer onto the hard disk. It must redirect the console to a serial port and be able to do a network install of the Linux distribution.

Here’s a summary of the steps I took to install CentOS on the appliances. If you’re interested in details, drop me a line.

  1. Download diskboot.img from the CentOS 5 distribution. This is a boot image most often used to boot from a USB key. We’re going to write it to the hard disk instead.
  2. Mount the diskboot.img file on a Linux system and edit the syslinux.cfg file. At the top, add:

    serial 0 9600

    which tells the installer we’re using serial port 0 (COM1) at 9600 baud. Change the “default” line to:

    default text

    because the terminal is initially screwed up so we won’t be able to make a choice; we’ll have to let it default to the right one.

    Now on “label text” add the following to the end of the “append” line:

    console=ttyS0,9600

    which will tell it to boot the kernel and use serial 0 at 9600 baud for the console.

  3. Save the file and unmount the image.
  4. Connect the hard drive from the appliance to the Linux machine, and determine its device name. I’ll call it “appliancedisk”.

    dd if=diskboot.img of=/dev/appliancedisk

  5. Now put the appliance’s disk back in place. Connect a terminal to serial line 0 (COM1) and connect the appliance to the network. Boot up and you can control the install process through the terminal, specifying a network location for the install media. Remember to keep the console=ttyS0,9600 line as a boot option so that the serial console continues to work after installation.