[asterisk-users] Asterisk on Debian Etch

Tzafrir Cohen tzafrir.cohen at xorcom.com
Wed Apr 25 12:08:19 MST 2007

On Wed, Apr 25, 2007 at 10:23:19AM -0600, Stephen Bosch wrote:
> Diego Iastrubni wrote:
> > On Tuesday 24 April 2007 16:24, Stephen Bosch wrote:
> >> Well, I can't speak for anybody else, but I haven't had a problem with
> >> reproducing a source install.
> > How about time?
> > 
> > 2 minutes download+install, vs 10-20 minutes compilation.
> > Then, how do you 
> > uninstall? How do you know which version do you have? 
> If you don't have 10-20 minutes for compilation you have no business
> installing a PBX of any stripe, let alone Asterisk.

I not it pretty well. But why should I waste my time on it?

Packages are reproducable builds.

> And if you don't know how to get the version number of your Asterisk
> install... are you actually administering Asterisk installations for users?

A common practice in Asterisk is to delete the contents of 
/usr/lib/asterisk/modules when installing a new version. Why? because
you have no idea what comes from the current installation and what comes
from a different package.

With Debian you can use:

  dpkg -S /usr/lib/asterisk/modules/*

and also check those packages with debsums.

In rpm you can run:

  rpm -qf /usr/lib/asterisk/modules/*

or even:
  rpm -Vf /usr/lib/asterisk/modules/*

Those tell you not only from which package comes each module, but also
if it has changed since its installation.

So if you install Asterisk from source, do you actually know what is the
version number of Asterisk that you run?

The above is trivial Linux management knowledge, without the need for a
lifetime experince with the specific program Asterisk.

> If you're new to this, fine, it's okay to prefer packages and not know
> how to determine the version number of your install -- but don't be
> handing out dangerous advice that makes people unnecessarily afraid of
> performing tasks vital to the successful administration of a piece of
> software. This isn't difficult, and there's plenty of help available.

If my distro does not have a recent enough version for me, I package a
newer version on my own. This is generally the same stability tradeoff
as in installing from source.

I may also try packages from a popular repository such as backports.org
and hope that others will encounter similar issues.

> >> Can you tell I'm a Gentoo user? :P
> <snip>
> > And even gentoo uses packages. Sorry, but "make install" is something for 
> > developers - not users.
> Yes, and I've already acknowledged I use mostly packages. The
> distinction with Gentoo is that the packages are source packages and are
> built at install time.
> Even so, for Asterisk, I *still* install from tarballs.
> If by user you mean somebody using a phone, then touché -- I don't
> expect my phone users to be doing 'make install' either.
> But we're talking about administering Asterisk, here. Seriously -- if
> you can't do a 'make install', then you should stay away from both
> Asterisk *and* Linux. This is not rocket science. It's like flying a
> plane on auto-pilot, or flying a plane without knowing how to taxi.
> Being able to steer in flight is not good enough -- if you can't land
> and take off, you have no business in the cockpit.

It's not that I can't land my plain. It's just that I rather spend more
time in the air than in the process of landings.

> To say that 'make install' is something 'for developers - not users' is
> beyond absurd.

The main problem is that the developers develop a great software. But
they tend to give the first priority to that software. They are masters
of dealing with that software and can't easily grasp what it's like not
to knowe the software.

And it is also important to understand that Asterisk, as important a
ballerina as it is, is still part of a complete system. For the
developers of Asterisk it may be convinient to use some generic
procedures. But you need that those procedures will fit well with the
standards of your distribution.

> My Linux servers started working the day I stopped wasting my time with
> packages, idiotic package dependency chains and hardware
> incompatibilities with binaries and learned how to install from sources.
> And no, I'm not a developer (nor am I a rocket scientist, though I do
> think rockets are cool).

A few "idiotic dependencies":

|   Ensure that your system contains a compatible compiler and development
| libraries.  Asterisk requires either the GNU Compiler Collection (GCC) version
| 3.0 or higher, or a compiler that supports the C99 specification and some of
| the gcc language extensions.  In addition, your system needs to have the C
| library headers available, and the headers and libraries for OpenSSL,
| ncurses and zlib.
| On many distributions, these files are installed by packages with names like
| 'glibc-devel', 'ncurses-devel', 'openssl-devel' and 'zlib-devel' or similar.

But this is actually a very partial list and not very helpful. You'll have to 
figure out what features you actually need, and then dig to find their actual 
build dependencies. And those are not trivial.

On debian you get the basic build dependencies installed by:

  apt-get install build-essentials

The build dependencies of Asterisk are installed with:

  apt-get build-dep asterisk

Take a look at the control file of 

> > The good thing about package managers, is that they tell you which package has 
> > been modified (a user changes a file, someone breaks into your machine and 
> > modifies a binary). In rpm it's done via "rpm -qVa" and in debian it's done 
> > by the command "debsums". I am not sure about gentoo.
> Utilities from gentoolkit will do this in Gentoo.
> > On a developers users - I would say install from source. On a *users* list : 
> > install always from your distribution packages. When was the last time you 
> > installed X from sources? KDE? Mozilla? OpenOffice? Why is asterisk 
> > different?
> Because X versions don't differ materially from minor version to minor
> version; because X isn't updated nearly as often Asterisk; because
> Asterisk, unlike X, doesn't take days to compile; because X, in general,
> isn't used to provide many users with a vital service -- if your X
> breaks, it's your tears, not the whole department's.

A new version of gnome is released twice a year. That's more than

X issues new releases at about the same rate. It supports new cards and
adds new and exceiting features.

I believe that KDE has a similar cycle.

Users tend to get all of them from the distributions. Well-integrated.

> Look, this is not the local Quake III server we're talking about -- this
> is phone service. The biggest mental hurdle that IT people have to get
> over is that it is absolutely *not* okay when the phones break, for any
> reason, for any period of time. This is a whole new world of user
> expectation. The PSTN people already get what I'm talking about. (They
> get too much undeserved shit from IT people who have no concept what a
> feat it is to run a network with 99.999% uptime. Say what you will about
> my local telco; I haven't lost a dialtone on my local phone in more than
> 5 years, and before that it had been 21. Respect the experienced PSTN
> technician -- he is worthy of it.)

Technitians I know use the best tools they have in order to use their
time effectively.

> I'm sorry -- for Asterisk, I have to disagree with you categorically.
> The depth of support available for someone who has installed from
> original sources is deeper and the installation is guaranteed to be
> current. Updating a source install is also trivial; and if somebody
> needs help doing that, I'm happy to provide some advice in that
> department (I've updated Asterisk on a production machine twice in the
> last month, and it took less than 10 minutes both times -- the same
> can't be said for my X, KDE or Mozilla installations).

I have upgraded complete systems from packages. It took a whole lot
longer than 20 minutes, but then again, there's a whole lot more code

As with the upgrade of Asterisk, the main problem is not "how to
technically upgrade". This is simple. 'apt-get install asterisk'.
o need to even spend 20 minutes. The real trick is to design packages
that don't break systems on upgrades. And if you have a fully configured
Asterisk / apache / postfix system, you need to plan the upgrade well to
avoid problems. On a major upgrade the software may change. And it is
your resposibility to prevent breakage.

BTW: when the masters of Asterisk from Digium want to produce a version
of Asterisk that they can easily support, they do what? produce a whole
distribution, where asterisk is built as a binary package.

               Tzafrir Cohen       
icq#16849755                    jabber:tzafrir at jabber.org
+972-50-7952406           mailto:tzafrir.cohen at xorcom.com       
http://www.xorcom.com  iax:guest at local.xorcom.com/tzafrir

More information about the asterisk-users mailing list