Linux Weekly News just published an article on Conary by Joe 'Zonker' Brockmeier, based largely on an interview with me. Since he wrote Johnson went on to give a detailed example... I decided that I'd like to provide the whole interview text so that interested parties can actually see that detailed example, along with other supporting information.

Thank you very much for the opportunity to talk about Conary!

* I believe Conary 2.2 is due out. When should the final release hit?

Soon.

We have been doing a phased release. Foresight Linux development is
already based on near-final snapshots, and Foresight Linux developers
(especially António Meireles and Martin Bähr) have provided some
great criticism that has helped us refine our new features.

* What are the major changes in 2.2? How do they impact users, and how
do they impact developers?

Conary 2.2 is introducing a new, more flexible way of managing systems.

Conary has done the best job of managing a system when the system is
described by a Conary "group". A Conary group is a specific manifest
of all the exact versions of multiple packages, and it is built into
a Conary repository. It is unlike an anaconda group or apt task
because it lists specific immutable versions, and each group is given
a specific immutable version. This means that a specific version
of a group resolves to the exact contents of every packaged file on
the system. It is also checked for things like file conflicts and
dependency failures when it is built. Normally, the build fails
if there are file conflicts or dependency failures, so you don't
see these kinds of failures when managing a system with Conary.

It is great that Conary can take a system with some random collection
of packages and do whatever it needs to do to make the system
match what is in some specified group. Some users start with a
base, "vanilla" install with only the core OS and then give the
system function by "migrating" to a group with that function--a
web server, a database server, whatever software is included in
the group they specify. However, all the checks that Conary does
while building groups take time, and they are done for each group.
It's not always valuable to build a group for every single slight
variation of systems that might be installed.

Conary 2.2 introduces "system models", which you can think of as
"groups lite". A system model allows you to describe concisely how
a system is different from a group on which it is based. Instead of
building a group for each unique software combination, you can build
fewer base groups, and then express minor unique variations on a
per-system basis where conflict is unlikely. It makes it possible to
have a more dynamic building-block approach to configuring systems,
without giving up the control that Conary provides.

As an example, it is reasonable to have a model that expresses,
"This is one of my web application server systems, built from my
group-mywebapp manifest. It is a Dell server, so I will add to it
the Dell hardware support packages that my organization uses, which I
have bundled together in group-dell-packages. It is being deployed
in my Atlanta data center, so I need to add the administrative
credentials required for all systems deployed in my Atlanta data
center, so also include my atlanta-data-center-credentials package
that sets up those credentials appropriately."

Here is an example of what might happen in practice. Let's assume
that you start with just the basic web app:

    search group-myapps=apps.example.com@example:1/1.0-1-1
    install group-mywebapp

Here, group-mywebapp includes your application and everything it
depends on (including the operating system), and group-mywebapp is
included in group-myapps. The version of group-mywebapp that
is installed on the system is the version found inside group-myapps.

You are deploying this on a Dell server, and so before turning on
the service, you are supposed to put the appropriate packages on
the system, so you run "conary install group-dell-packages". Now
your model looks like this:

    search group-myapps=apps.example.com@example:1/1.0-1-1
    install group-mywebapp
    install group-dell-packages

Conary finds group-dell-packages in group-myapps, so you are using
a set of packages that have been tested to fit together, not a soup of
"whatever happened to be latest when I ran the install command".

At this point, a new group-myapps has been built with security updates
in the operating system, and group-mywebapp has been tested by QA to
not be broken by that critical security update. You need to update to
the latest consistent software set right away! You run the command
"conary updateall" and your model now reads:

    search group-myapps=apps.example.com@example:1/1.0-1-2
    install group-mywebapp
    install group-dell-packages

Conary applies all the relevant updates between the two versions of
group-myapps, including the changes both to group-mywebapps and to
group-dell-packages, deploying a combination of packages that Conary
previously inspected for potential failures (path conflicts, missing
dependencies) and which the QA group already had the chance to fix.

Now, the system is deployed to the remote Atlanta data center, so you
add the appropriate credentials with the command:
"conary install atlanta-data-center-credentials" and you system model
now reads:

    search group-myapps=apps.example.com@example:1/1.0-1-2
    install group-mywebapp
    install group-dell-packages
    install atlanta-data-center-credentials

Your web application is a distributed application behind a front end
load balancer, and load has suddenly increased substantially. You need
to deploy new hardware, right now. The available system is an HP
server, and you need to have the HP hardware support software on it.
No problem. You copy your system model to the re-purposed HP server
that was just handed to you, change "group-dell-packages" to
"group-hp-packages", and synchronize the system to the new model
using the "conary sync" command:

    search group-myapps=apps.example.com@example:1/1.0-1-2
    install group-mywebapp
    install group-hp-packages
    install atlanta-data-center-credentials

Now your Dell and HP servers are running exactly the same software,
except for the hardware support packages. You are confident that
you are ready to add the HP server's IP address to your load balancer.

The overall impact for users and developers overlaps a bit.
Conary 2.2 is faster for many operations. It uses less memory and
network bandwidth to determine what to do. It saves developer time
because developers can build fewer groups. It is more expressive;
the model is saved on the system as a simple text file that is easy
to read and understand, and can be copied between systems. It is
more flexible; you can choose to build groups when that is useful,
but you do not need to do in as many cases--and if you start with
a model, you can trivially turn it into a group if you want.

* In 2005 we talked about rPath and Conary, and you said that rPath
wanted to make a "good distribution on which to base a derivative."
Has this happened at all? I see Ubuntu, Debian, and to a lesser extent
Fedora and SUSE (via SUSE Studio) producing derivatives. But very few
rPath derivatives, if any.

There are hundreds of rPath derivatives; some public, some private.
The derivative products we have in mind are not like the typical
"respin". Our derivative products will be less visible, precisely
because our products were intentionally "unflavored" so that the
derivatives wouldn't require co-branding.

Foresight Linux was built as a derivative of rPath Linux.
OpenFiler is a very different derivative. Many appliances were
built on rBuilder Online as derivatives of rPath Linux.

Every one of rPath's customers builds one or more derivative
products. Some build only a few, some build a great many.

Many of rPath's customers build one or more internal base platforms,
derived from one or more of our supported platforms (including
multiple versions of RHEL, CentOS, and SLES), and then derive
multiple products or system definitions from those base platforms.

We are now greatly expanding that capacity for derivation.

We always wanted rPath Linux to be merely one of several operating
system offerings that you could manage with Conary. We have now
made that happen: Conary 2.1 introduced managing packages for other
package systems, starting with RPM.

Early last year, we had an epiphany about what Conary can do.
Let's start with the obvious: different users find different Conary
capabilities valuable. For some, it's the JeOS capabilities
of Conary's native "components" that avoid pulling in extra
dependencies. For others, JeOS isn't a major issue, and the
packaging done today with RPM and dpkg is sufficiently granular for
them--but they really like Conary's release management capabilities:
not only building and checking complete system manifests (groups),
but also exposing those manifests in a controlled way through the
software development lifecycle.

We realized that we could analyze packages for different packaging
systems (e.g. RPM) and provide the same essential group build
capabilities for sets of packages (e.g. RPMs). So we implemented
support for "encapsulating" non-Conary package types (initially for
RPM; more package types are coming) within Conary, and then managing
them with groups. We "encapsulated" several versions first of RHEL,
then of CentOS and SLES, on top of which our users can now manage
those sets of packages just as they have long been able to do with
native Conary packages. We will continue to add various platform
versions.

* Who is using Conary? What's the audience for it at this point?

Like all great technology, it solves more than one problem and so
has more than one audience.

In terms of total number systems under management, the largest
audience is enterprises using rPath's product line, based on Conary,
to manage diverse systems on a massive scale; what several of our
customers independently named "enterprise appliances". Another
significant audience is ISVs using the same tools to deliver their
software in software, virtual, and hardware appliances to their
customers. Finally, Conary has users (including rPath customers)
who are using Conary's software build capabilities extensively.

As I said, many rPath customers do not desire co-branding, but I
can definitely give you a small sample of our customers who have
mentioned in public that they are using Conary and other rPath
tools for this purpose: EMC, IBM, DoE, Sony, Fujitsu, and Qualcomm.

* Slightly off the topic of Conary... If I remember correctly, Novell
had announced a partnership with rPath to build SUSE Linux Enterprise
appliances, but then went off and did SUSE Studio. Any idea what
happened there?

These are not really related, as strange as it might seem at
first glance. SUSE Studio is basically an image assembly factory.
This happens to overlap superficially with a small subset of
rBuilder features, but that's not really noteworthy.

rPath has had a long-standing relationship with Novell in which
we (rPath and Novell) provided a certain subset of SLES package
contents, re-packaged as native Conary packages, including the
ability to assemble these contents into appliances and appliance
images. This is probably the announcement that you recall.
Additionally, rPath now also provides to our customers the ability
to manage RPM-packaged SLES for several SLES versions, again with
the ability to assemble appliances and appliance images. In both
cases, this also includes Conary's precise and complete system
definition, build, and update capabilities already discussed.

* What should developers who have worked with RPM or Debian packages
know about Conary?

Conary automates many tasks that are manual with RPM or dpkg.
Relax, it's probably easier than you think!

The big mind-shift isn't really package building. Conary package
building is certainly much easier than RPM or dpkg, but that's
not really the important point.

First, a small mind-shift. With Conary, a package isn't a
specialized archive file. Instead, it is a set of relationships in
a database. The fact that it is really a reference to a database
means that a reference to a certain version is immutable for all
time. (Note, a Conary package can still be represented in a file!
We call that a "changeset", and it has the advantage of existing in
both a relative form--the changes from version 1 to version 5--and
absolute form--not relative to anything else--the closest analog
we have to an RPM or dpkg file.)

Immutable packages in a network repository, with globally-unique
versions, are a necessary prerequisite for the big mind-shift.
Conary groups are not just lists of package names. They are
built into lists of exact versions, so that if you have the
one-line-of-text exact version of the group, you know the exact
contents of the entire system, and can take a system in some other
state and move it to the state represented by this group.

It's hard to overstate how huge an advantage that is. It does
take a little getting used to.

* You also mentioned in 2005 that Conary should work "just fine on
BSDs" and that Conary had been successfully installed on Cygwin. Any
uptake of Conary on other OSes?

Only on Linux so far! However, we're building support for managing
Windows packages natively.

Cygwin is not a particularly interesting target (though last we
checked, we fixed a few minor things up and made it build again)
because despite a veneer of POSIXish behavior, it can't make the
underlying system have true POSIX semantics. Our native package
management requires atomic rename, but on Windows that is just
not available for open files. This isn't a fault in Cygwin, it
is a simple limitation of the underlying platform.

For Windows, we're instead building groups of sets of MSIs (which
we either import or build from bundles of files provided by the
user) and then hand off those controlled sets of MSIs to Windows
to install.

We have not received significant feedback from potential customers
indicating that it is commercially feasible for us to package any
of the BSDs as a Conary-managed platform, so it's not on the radar
commercially. That said, there's nothing substantial in the Conary
code that would get in the way.

As my kids are starting to want to "look for things on the internet", I started caring about what they might accidentally stumble onto, even in an appropriately supervised context.

I had vaguely heard about OpenDNS for some time, but had not really paid much attention to it. A few relatively recent articles on using it to make an internet connection somewhat more "family-friendly" caught my attention, and I finally signed up for a free account to try it out.

I have a local caching bind which forwarded to the nameservers that TWC provides to me (and to which I redirect all outgoing nameserver traffic via firewall rules), and I really haven't noticed nameservice being slow, so the "speed up your internet" advertising from OpenDNS wasn't ringing true. But the ability to filter out the worst of the sites dedicated to things that I think don't have a place in my home was interesting. So I signed up for a free account, changed a few lines in my bind configuration, and packaged and installed ddclient according to OpenDNS's instructions so that OpenDNS will continue to associate my home network with my home network settings on those rare occasions when my IP changes.

We weren't seeing lots of questionable content before the switch, so the fact that we've seen a total of two sites blocked since we signed up for the service is fine. It says that I can establish what I think are reasonable controls and it won't get in the way of normal activities.

Purely because I appreciate the service (I don't really care very much about saving statistics for longer), I signed up for a paid account. This service seems to me to be worth the $9.95/year.

A few days ago, OpenDNS rolled out a new free service called FamilyShield -- you can use a pre-configured set of filters without setting up any account at all merely by using 208.67.222.123 and 208.67.220.123 as your DNS servers (they include detailed instructions for how to do this on many different OS variants). This is exactly the same thing you'd get by signing up for their service and enabling the same set of filters for your account, so it's easy enough to upgrade to their free service if you want to customize the filters -- you just sign up for a free account, change the IP address you use for the resolvers, choose the filters you want, associate your IP address with your account, and (if you, like most people, have a dynamic IP) set up one of the many dynamic DNS clients available (they list several) to keep that association up to date.

I'm just a satisfied customer.

My wife found her smartphone screen cracked recently. AT&T told her to suck it up and buy a new phone, and the local independent shop couldn't fix her phone. I had a great deal of trepidation about sending the phone off to some random place I googled, but in the end sent it off to Jet City Devices in Seattle.

They turned the repair in about an hour from the phone's arrival on a Saturday (!) afternoon, and had it back in the mail same day, so that it arrived back in North Carolina on Monday with a new screen.

Good Work!

We have been importing sets of RPMs into Conary capsule packages, and yesterday we announced why.

Capsules are simple. We wrap existing packages provided in some other format (RPM, in the first instance, but we expect others) in rich Conary metadata (file-based dependencies based on deep file inspection, groups, and so forth), and store the combination of the unmodified package and metadata in the Conary repository. To install the package on a Conary-managed system, Conary calls the native package management code.

This works amazingly well. You can even mix native Conary packages with capsules.

This capsule feature can even help find bugs in RPM packages!

As part of this work, we imported RPMs from the original Red Hat Enterprise Linux 5 ISO images into a repository and tried to build a Conary group containing those packages. Unfortunately, this group was not dependency-complete. It appears that during RHEL 5 development, several packages were built against Firefox 1.5.0.7. Then (I would suspect near the end of RHEL 5 development, though I haven't checked build dates) Firefox was updated to 1.5.0.9. Someone remembered that the yelp package would need to be rebuilt against Firefox 1.5.0.9 to function. No one, apparently, remembered that gnome-python2-extras also needed to be rebuilt against Firefox 1.5.0.9. I don't blame anyone for this; I wouldn't either. But with Conary, all we had to do was try to add all the packages to a group and Conary complained and told us exactly what was wrong. By contrast, RHEL 5 was released with gnome-python2-extras that included an RPATH entry referencing a directory that does not exist: a broken dependency. As far as RPM's more limited view of dependencies is concerned, RHEL 5 was dependency-complete, but the combination of Conary's deep file inspection and group dependency checking caught this bug immediately.

At the post office, I found myself writing a bit of a pastiche of an old classic:

Passport Hours: 10:30-4:30

Nice work hours if you can get 'em

NOTICE: TO SERVE YOU BETTER, PASSPORT SERVICE IS NOW BY APPOINTMENT ONLY

And you can work less, if you try!

1:40 PM:

Applicant has been waiting since around 1:30 PM, occasionally ringing doorbell.

Postal Service Employee (annoyed, poking head around door she is holding mostly closed): When's your appointment?

Applicant: My appointment was at 1:30, Ma'am

Postal Service Employee (even more annoyed): Can't be at this post office. You must be at the wrong post office. I have lunch from 1 to 2.

...

Suddenly, I find myself thinking that privatizing postal service might be a good idea after all. Also, putting the phrase "to serve you better" on a sign or form should be a federal offense, publishable by standing in line at a post office for 10 years.