A Conversation with Alfredo Delgado of Inalambrica.net

Inlambrica is rolling out a network management platform with a difference--the package manager is a PostgreSQL database. ELJ's Phil Hughes asks Alfredo Delgado about Linux, databases and business.

Alfredo Delgado

In October 2001, while I was in Costa Rica, I met with a
number of Linux advocates. Some were in the public sector and
others in private industry. One private company that bases their
whole product on Linux is Inalambrica.net. I interviewed their CTO
for an article in Linux Journal but also saw
some interesting stuff they were doing that I felt was of interest
to ELJ readers.

This article is based on a conversation I had with Alfredo
Delgado (Alf) who came to Inalambrica on January 1, 2001 and is in
charge of their systems design and integration. Inalambrica.net
needed an embedded Linux system on which to base their product, and
they came up with what I see as a unique solution.

ELJ: Briefly describe the
products that Inalambrica is producing.

Alf: Our goal is to build a
cheap and easy-to-use network management appliance (internet access
and bandwidth control), with several connectivity options, aimed at
SOHO and small-to-midsized businesses and networks. The appliance
has a web interface to handle everything from configuration to
reports to system maintenance (package upgrades, new hardware,
etc.).

Not being a hardware company, our main product is the
software to drive such an appliance, not the appliance itself. The
idea is to be able to send out the software (our own distro and its
modular web interface) to distributors and even, sometime in the
not-so-distant future, directly to customers.

Ultimately we'd like to send out just a CompactFlash with an
IDE interface and a list of compatible hardware, but it will take
some time for us to get to that point.

ELJ: Let's get some
background. Prior to your joining of Inalambrica, what were they
using as far as the Linux base for their products?

Alf: Handcrafted machines
with Debian or Slackware.

ELJ: What were the
shortcomings of this base?

Alf: Lack of
standardization, bloat, time-consuming installations--both are
great distros, but they were not well tailored to the task at hand,
especially as the number of machines started growing; the
customizations to the base distros piled up, the different
connectivity options spawned different sets of package,
configuration and interface options, and in general, everything
became bigger, slower and more complex.

ELJ: You decided to use a
real (by that, I mean a general-purpose SQL-based product) database
to manage the distribution. Before you picked this, did you have
other ideas?

Alf: Yes. But I scraped them
very early in the process. Our first idea was just to hatchet,
chisel and mold Slackware to our purposes; thus, our first test
machines were cut-down Slackwares with a lot of extra packages, and
the web interface had to be tailored for every installation. We'd
gained some standardization, killed a bit of bloat and improved our
installation time, but we were far from happy with the results. As
soon as customers started to spring up in several countries, with
very different hardware and connectivity needs, we realized we were
going to face huge support issues very soon if we did not find a
better (more flexible and automatic) way to do things.

ELJ: You elected to use
PostgreSQL as the database. Most people would consider this rather
heavy. Why PostgreSQL rather than, for example, MySQL?

Alf: Our web interface uses
PostgreSQL extensively. There wasn't much sense in having two
separate DBMSes. Also, I've always been a PostgreSQL guy, so I was
already on the right side of the debate. I use referential
integrity, subselects and other features regularly, and they were
not supported on MySQL the last time I checked.

ELJ: Describe the structure
of the database you have built. That is, what is in the
tables?

Alf: Every package has its
own database. The base installer holds the DBMS system, of course,
and the main database holds package and file information (installed
packages, versions, dependencies, reference counts for files and
directories, upgrade history, etc.).

Each new package creates a database with the package's name
to hold configuration options, interface information, etc. Each
package maintainer is responsible for the respective
database.

ELJ: You say, "Every package
has its own database.'' Is that really a database or just a new
table?

Alf: Let's take the base
networking package as an example. The package is called network, so
it CREATEs DATABASE (network) in PostgreSQL. This database holds
several tables: 1) device, which holds physical interface
information; 2) interface, which holds logical interfaces
information (IP addresses, netmasks and data rates, for instance);
3) host, which holds host entries for DNS use with DNRD; and 4)
nservers, nameserver addresses--also for DNRD.

There are also historical tables to keep track of
configuration changes, although I have yet to finish rollback and
roll-forward on this.

ELJ: How have you built the
glue? That is, the programs that you use to put packages into the
database and manage the contents of a distribution?

Alf: Right now everything is
shell scripts and a lot of documentation on standards for the
package maintainers. The idea is to stick to the KISS principle,
and with all the developers in the same building this is not too
hard to do. All the complex issues actually are interface-related
and are separated from the base installer, configuration files and
databases by one level of abstraction: the configuration,
administration and control scripts in each system package.

ELJ: Describe the install
process.

Alf: The process is boot,
partition, format, install the base, fire up the database, install
packages and reboot. There's nothing more to it. Our package
installer takes care of the main database, and each package handles
its own database.

ELJ: How much user
interaction is required?

Alf: Short answer: Pop the
disk in and lie still until I'm done. After the installation
process finishes, all interaction with the user is through the web
interface.

ELJ: How long does it
take?

Alf: That depends a bit on
hardware, how many partitions the installer has been instructed
(hard-coded) to build, how many of these will be encrypted, which
packages are on the installer, etc. My test installation takes
about eight minutes on a 750MHz PIII with 128MB RAM, a 128MB
SanDisk CompactFlash and a 20GB hard disk, with everything but the
/boot partition on ReiserFS.

ELJ: What is a recovery
like?

Alf: Hell to program. Can't
say much more at the time, as it's what I'm working on right
now.

ELJ: When do you expect to
have it completed?

Alf: Late November/early
December 2001. I'm working on the rollback (taking the system to a
prior state) and roll-forward (redoing changes from a certain state
on) features, and running into nice problems like hardware failure
notification, database corruption and so on. Designing solutions
(and interfaces) for each one of them is what's slowing me
down.

ELJ: What future
functionality do you intend on adding? How does it take advantage
of the database?

Alf: I'd talk of planned
rather than future functionality: rollback and roll-forward of the
installation (upgrades, configuration checkpoints, access levels),
many more report generators, auto-upgrade. Since the package system
uses the database to keep track of things (all the way to the
"who's using this file?'' level), I guess it's safe to state that
the database is what allows these functions to be implemented.
There are, of course, other ways to implement them, but databases
are remarkably well suited to handling information.

Something I'd really love to work on in the future is using
the database directly from each package, as opposed to having it as
a backup for regular configuration and log files. I envision a
system where users are not in /etc/passwd, but rather stored in a
database, with all their files being BLOBs. But that's a long-term
project.

ELJ: Inalambrica's products
are proprietary in nature but based on GPLed software. Please
explain the relationship between Inalambrica and the Open Source
community.

Alf: Most of the software we
use is open source under some license or other, a lot of it GPLed.
Our work has consisted, mainly, in combining the pieces in new and
interesting ways and, of course, writing interfaces.

Our relationship to the Open Source community is mainly
through our local LUG, where many of us are active members. Our
contract with Inalambrica provides each one of us technicians with
two hours per day to work on open-source projects. We've used it
mainly to give time back to our local Linux community in the form
of e-mail support and our IRC channels at
http://www.openprojects.net/.

ELJ: With the "two hours a
day to give back to the community'', it sounds like that is mostly
in the form of support. Is that correct, or is there some other
software project that has happened or is happening?

Alf: Support and project
coordination, mostly--events like Conquered, our booth at
Compuexpo. Our InstallFests take a lot of time to set up, and our
community hours are used quite lavishly for these purposes.

On the software side of things, we are working on a
weather-station monitoring program to be GPLed. I also help out
with some PHP and database work on the non-main-web site part of
our LUG's web site.

ELJ: Open source?

Alf: Our interfaces are
proprietary and, right now, so is our distro. We plan on releasing
a version of our distro as soon as we are better established in the
market. Meanwhile, any modifications we make to open-sourced
products are, of course, to be released back to the community in
accordance with the licensing requirements. Right now this includes
only some patches to work with encrypted filesystems, which will
probably be ready (and available for download) by January
2002.

Trending Topics

Upcoming Webinar

Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report

August 27, 2015
12:00 PM CDT

DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.