Asterisk

What is Asterisk?

Asterisk is an open source PBX (Personal Branch Exchange). A PBX is a phone system commonly found in office settings that allows you to make calls between cubicals just by dialing that extension. A PBX also allows things like Automated Attendant, which creates those annoying messages that say "Press 1 to talk to a human" or "Press 2 if you are willing to pay to talk to a human".

Asterisk however takes this to a new level by integrating the Internet into your PBX and allowing you to do Voice Over IP (VOIP). The big benefit of VOIP is now your office doesn't have to be located in one place. You can have phones ring is several places at the same time and who ever picks it up first gets the call.

You are not even confined to the same country. For instance, you can get a US based phone number and have it ring in Australia. As long as your phone can plug into the internet, you can make and receive phone calls as though you were in your office. If you are extension 1234 at work, just take your phone with you and when you plug it in to the Internet, you will still be extension 1234.

Because it is open source, it is quite a bit cheaper than most commerical PBX systems. 

Asterisk comes in two pieces: the PBX which is called asterisk and the hardware drivers for phones and phonelines called zaptel. You can use asterisk without any of the hardware drivers if you only need VOIP capabilities.

I've mostly used asterisk for voip and analog lines.  Analog lines come in two flavors: FXO and FXS. What kind of line it is depends on whether or not it has a dial tone. An FXO line can receive a dial tone and functions much like a computer modem. An FXS line generates a dial tone. For instance, a telephone handset and a computer modem are both FXO devices. Neither of them generates the dial tone. So, if you were to plug a telephone into the computer modem, you wouldn't get a dial tone. An FXS line emulates the incoming line from the telephone company.

If you attach a telephone to the FXS line in an Asterisk box, it will give you a dial tone and allow you to make outgoing calls. It then passes the digits you dial to an FXO line that is connected to the telephone company, thus completing your call. Asterisk can also make FXS to FXS calls, where one extension rings another internal extension off the same PBX.

FXS -> PBX -> FXO -- Make an outgoing call.
FXS -> PBX -> FXS -- Ring an internal Extension
FXO -> PBX -> FXS -- Incoming call passed to Extension

When you add VOIP in to the mix, the combinations become endless. But I think you get the picture.

Managing Filesystems: fstab

Understanding how the BSD filesystem manages disk space is critical to successfully managing a BSD server or workstation. However, this topic is generally overlooked since it is rarely used outside of installation and upgrades. It is also a very simple topic and most people assume you understand how it all works.

This article gives a quick synopsis on filesystem layout and tries to briefly explain how to understand /etc/fstab. The fstab(5) man pages, while good, do little to teach the basics to new sysadmins.

The first thing to realize when dealing with the Unix filesystem is that everything can be addressed as a file. Even system hardware has a file representation that is used to access it. Those special files live in /dev.

The second thing to understand is the starting location for all these files is / and pronounced "root". Those are the two points of Unix doctrine that everyone expects you to already understand before even thinking about trying BSD.

But what does that mean to me? First, if you have used a Microsoft operating system, you will notice there is no "C:" drive or any other drive letters. Unix has no concept of the drive letter mentality. With Unix all things exist in one directory structure. This may seem very unusual at first given the way you may be used to dealing with removable media. Instead of assigning a drive letter to removable media, you must find a place in the existing file structure to attach it.

Think of it like docking a module on to a very large space station. You find an empty docking station, connect the module. While the module is connected, the entire contents of the module are accessible for storage or removal by authorized personnel.

Dealing with Disconnection

I sometimes work at home from a VPN Internet connection. I also have a small home network of about 4 computers of various types. All of them route through my BSD box to the Internet. However, like most people I travel back and forth to the office each day. Sometimes, when I'm working, I don't want to stop what I'm working on remotely just because its time to leave.

I use ssh from my BSD desktop to connect to the computers I work on. They are all remotely hosted and I have never actually seen any of the boxes. Usually, I am editing files using vi(1), managing asterisk servers from the console or setting up opensips processes.

My biggest problem working remote is not the lack of speed, highspeed internet really solved that, not like in the old days when I first started doing this. I remember dealing with that - push a key, go eat lunch, no real problem. But when working remote, the biggest problem is getting disconnected. Its really frustrating when I am in the middle of a project and the VPN gets disconnected or the WiFi just loses signal because someone turns on the microwave and I lose all my work.  vi(1) can sometimes be forgiving, but it's far from the ideal method. I can usually recover part of my work.

Back when dialup was the only option, I would often get disconnected and log back in and the program I was working on was still running. Using w(1), I could see that the server still thought that I was logged in and hadn't terminated the program.

I was still working from dialup back when a friend of mine introduced me to screen(1). He ranted and raved about how wonderful screen(1) was and how the world needed to know about it. I've been using it ever since.

Philip Paeps - FreeBSD, Detangling and debugging

Philip recommends debugging without using the debug tools.

"Debugging is universally anticipated with distaste, performed with reluctance and bragged about forever"  -- anonymous.

One of the biggest drawbacks to using the debug tools is losing an entire day rebuilding the system to include the debug symbols and then to figure out that the problem was a simple typo that you could have caught with five minutes of critical thinking and some code review.

Suggestions to debug without the debugger

• Printf's are boring.  Instead when your program crashes, have it print a stack trace.
•  Cookies -- Write an unsigned long as a global variable and use it as a poor man's running stack trace.  Write to it  (fiddle with the bits) in the different subsystems to keep track of where you have been.  Works great for embedded systems.
• GCC is your friend.  Don't silence the debugger with a cast, fix the problem.
• use GCC -E  -- It goes through the pre-processor and prints out the info.
• Know your -w flags.  Use -w Error to stop the program on warnings and fix them.  Lots of problems can go away when you fix the warnings.
• Use GCC instrumentations  -- Very useful in userspace, not so much in kernel.
• Do an object dump. -- Useful, but you need to know a lot to use it.  Also you have to remove the -fomit-frame-pointer flag on intel platforms, or this process is useless.  You can use this method to disassemble  your program and figure out where the program crashed.  Very useful in trace analysis. 

Summary

Try not to debug, try to think first.

Take shortcuts.  You have already broken something, cheating won't make it worse.

Remember who your friends are, like nm and object dump.

Document your clever tricks.

SSH Primer

When you ask how you can make your BSD box more secure, the first thing people will tell you is to use SSH if you aren't already. If you are new to BSD or Unix in general, you might still be mastering the art of logging in to the console and not have given a thought to logging in remotely. If you are using Mac OS X, you may not have even realized that you can log in remotely.

When you login to the console, BSD gives you a login: prompt and asks for your user name. You are then prompted for your password. If you successfully give both, it logs you in and presents you with a shell prompt. The alternative situation is if you are using a GUI login such as xdm, kdm, or Mac OS X. The login process will be the same; however, you will be presented with a windowing system upon login instead of the shell. To get to a shell from this point, you will need to run an xterm or the Terminal App in Mac OS X, which is found in the utilities folder.

From the shell prompt, you can use the ssh utility. In its most basic form, ssh gives you secure, console access to another computer. All the traffic that goes between the two computers is encrypted so it can't be intercepted in transit. Previously a utility called telnet handled the same duties, however it did so using unencrypted protocols. It became very easy for hackers to intercept telnet sessions and discover passwords used to remotely manage systems.

OpenBSD, NetBSD, FreeBSD, Mac OS X, and Darwin all come with OpenSSH installed as part of the base installation. OpenSSH was developed by the OpenBSD project and has quickly become the de facto standard for ssh. If you don't like using ssh as a command line, people have developed GUI front ends to ssh, but I'm not covering that in this article.

AsiaBSDCon 2011 -- Call for Papers

Hiroki Sato is calling for papers for AsiaBSDCon 2011.

 It will be held on March 17-20th 2011 in Tokyo Japan. That would be an fun conference to attend. I've been to asia before, but not Japan specifically.

The details on submitting a paper for the conference can be found at http://2011.asiabsdcon.org/.  Submission deadline is December 20th, 2010.

I'm going to have to go back and watch all the videos from last year to catch up.

Advances in Embedded ARM processors, for performance

Dimitri works for Marvell, a semiconductors company. Most of the chips they make have to do with networking. I was surprised to learn how many ARM cpus there are out there. ARM processors are optimized for cost, but still very high performance, reaching up to 2Ghz as of this video.

Marvell makes a point of working with compliers like GCC and operating systems like BSD and Linux to make sure all the advanced features of the CPU can be taken advantage of.

Marvell also makes a plug computer. A small computer that plugs into an outlet. Seems like its a micro server that fits in a plug and is designed to work in a home setting. The entire plug computer consumes less than 15 watts of power.

What to do AFTER you have BSD installed

The first time you install BSD, you face a huge learning curve. Unless you come from a UNIX environment, it's a totally new way of thinking. There are several things that people assume you know and therefore leave out of the documentation, or they have arranged the documentation in such a way that you have to know about it to find it.

This happens a lot in the UNIX world. The man(1) pages which are the primary source of UNIX online documentation, assume that you already know what command you are trying to learn about and how it is spelled. (Commands found in the manual are often tagged with their manual section in parenthesis like this: man(1).  The 'man' command is found in section 1 of the manual. Try typing 'man man' for more information on the 'man' command.)

 If you don't already know the command you are trying to learn, the man pages won't help much. Another place people seem to cut short on documentation is immediately after installation.

The install process on BSD is getting easier and easier, therefore more people with fewer UNIX skills are getting through the install process. Because of this, there seems to be a growing number of people that get BSD installed, and have no clue what to do when presented with the first login prompt.

Darwin/BSD (localhost) (console)

  login:

Because BSD is a highly secure operating system, unless the new user knows the default login name and password, the newly installed BSD system is useless to them. The command line interface is also foreign to most new generation users.

Creating an SSL Certificate on FreeBSD for ApacheSSL

This is just a quick syntax guide for creating a CSR for Apache SSL.  I do this a couple of times a year for the different domains I manage and I have to look up the syntax each time.  So, I'm recording it here so I can look it up easily.

Creating A CSR

A CSR is a Certificate Signing Request.  Its what you send to the SSL provider so they can create your actual certificate.

sudo openssl req -new -key /path/to/your/private/ssl/server.key \

-out /path/to/your/new/signingrequest.csr

The server.key is the private key for your server.  It identifies your computer and should be locked with a password.  In case someone breaks in and copies it, they can't use it without the password.  If evil doers manage to get a hold of your server key, they can pretend to be your website and people will trust them, because they have your ID.

The only draw back to using a password protected key is that apache will not start until you put in the password manually.  If you have apache set to load on boot up, it will actually keep you from logging into the server, because the boot process will stop, waiting on you to enter your password.

FreeBSD RC Scripts

The real problem is that SSH hasn't started at the time apache is trying to load.  One way to solve this problem is to add/modify the following line in the FreeBSD rc.d script for apache.

# REQUIRE: LOGIN cleanvar sshd

The REQUIRE field tells the RC system to wait for certain things to happen before loading. Since I use sshd to login remotely, I absolutely want to make sure that sshd is running before apache tries to load and things get stuck.

Yes, the # is part of the line. I worried the first time I tried it that it was commented out and I would have to remove the # to make it work.  But it works fine with the # sign, because it is parsed by the RC scripts as a directive instead of by the shell parser as a command to be executed.

Normally, I don't bother running secure apache from the rc scripts.  I just run apache manually, but just in case, I like to make sure it won't hang the server on boot up.

One side effect this will have though.  If sshd isn't running for any reason, you won't be able to start apache using the RC scripts.  You can still start it using apachectl though.

Ramon Tancinco - meetBSD 2010 Welcome Intro

Marko Zec - Network emulation using the virtualized network stack in Fre...

A Brief History of the BSD Fast Filesystem, Kirk McKusick

A Narrative History of BSD, Dr. Kirk McKusick

Hardware Crypto Suport- Philip Paep. MeetBSD 2008

Isilon and FreeBSD. Zach Loafman. MeetBSD 2008