What Ubuntu Server *could* be

I’m glad Thierry started this discussion. About six months ago when we were first beginning to talk about what to do in Jaunty, I sat down and wrote a bunch of notes that I meant to turn into a blog post, but it never made it farther than an e-mail to a few people, but now that we’re sharing visions, I thought I’d post it.

Disclaimer: These are simply notes I wrote for myself. They’re not the outcome of a discussion, it’s not a blessed strategy.. They’re just my notes.

What is our profile? What offsets us from the others?

If I’m brutally honest, I must admit that when I explain Ubuntu server
to people, it very often ends up something like: “Debian with a sane,
predictable release schedule. We take a snapshot of Debian at some
point, and apply some polish and tender loving, and we ship it.” (Note:
I wrote these notes 6 months ago, and this part is not quite true anymore,
but let’s just forget that for a little bit.)

Sure, we also add a few gadgets, gizmos, and widgets, but the type of
user who gets won over by that sort of thing alone is probably not the
kind of user we’re really interested in (in part because they’re
transient… If another distro comes up with another gizmo they suddenly
can’t live without, they’ll be out of here in no time).

We need some kind of profile. We need to do something differently from
others. Offer a different concept. Right now, we’re trying to the others
at their game. I’m not saying it can’t be done, but it’s a veritable
David vs. Goliath.

Debian provides us with a technically strong, dependable base, but
Debian is a solution to a problem we’re not trying to solve.

Ubuntu on the desktop took off with a bang with the Warty Warthog
release.. It was an almost instant success. Why? Because it solved the
problems everyone was facing:

  • Easy to install
    • The install process was boiled down to as few questions as we
      could possibly get away with, in part by leaving out a lot of
      advanced options.
  • Lots of common hardware supported
    • Even restricted drivers. The idea was that a software stack
      consisting of all free software with a single binary blob to
      enable a wifi card or a graphics adapter is better than a software
      stack of all non-free software. For most users, these were (and
      are still) the only two viable choices.
  • A wide selection of software was pre-installed and ready to go.
    • All you needed to do was look around in the menus and you found
      the software you needed to get most of your work done. No need to
      look on the internet for “what software do you use instead of
      Word/Internet Explorer/MSN Messenger/Outlook on Linux?”

Essentially, it was all about “making the best of free software
available”.

Now, is “making it available” still a problem on servers? Yes! Sure,
there’s lots of stuff we can’t do with an Ubuntu Server, but what if we
focus on what you *can* do, and make that very, very available in a way
that’s true to our UNIX heritage?

What would that require?

  • Easy to install
    • What are the common stumbling points for the installation process?
      • Example: Partitioning is difficult. You usually only get the one
        chance to get it right, and if it’s your first linux system, you
        won’t have a clue.
  • How can we fix them?
    • Example: Do their partitioning for them?
      • In ways that don’t limit our choices later on?
        • Example: Always make the disk a raid member where the raid set only
          has that one member. That way, it’s easier to add another
          member later.
        • Example: Always do LVM. Provide tools to easily move parts of the
          filesystem to a newly created logical volume (creating the lv
          and mkfs it in the process).
  • Lots of common hardware supported.
    • What server class hardware out there is unsupported?
    • Do we need to create a restricted driver set for servers?
  • A wide selection of software pre-installed and ready to go.
    • Perhaps not actually pre-installing them, but making sure that
      people are using “the right selection” of software some other way,
      perhas by means of:

      • Better documentation
        • I’ve never read a book about Linux system administration and not
          thought that they were doing it all wrong. This is symptomatic:
          IMO, we’re quite good at pointing out when people are doing things
          wrong, but we fail to go out and define the One True Way[tm] to do
          things. Personally, I’m afraid I’ll make a mistake and people will
          wind up at a dead end, because there’s something, I’ve
          overlooked.
  • Much better integration
    • Again, this stems from our failure to go out and define the One
      True Way[tm] of setting up our services and integrate them. This
      is something we inherited from Debian. I believe it needs to stop
      right now. Take dovecot, for instance.. I don’t expect any half
      serious deployment of dovecot to use the userdb and passdb
      backends that its configured to use by default, yet we leave the
      defaults that way. Why? Because Debian does it. Why do they do it?
      Because they’re trying to solve a different problem than we are.
      They want to provide a platform that unbiased does everything for
      the relatively few people who know how to drive it. This is noble enough, but
      to dovecot, it means that it’s only as enterprise ready as the
      sysadmin can manage to set it up. We need to define what an
      Ubuntu based enterprise environment looks like and offer that in a
      packaged form for easy deployment. The benefits are numerous:

      • Knowing that a company uses an Ubuntu based network
        infrastructure currently tells you nothing. Defining these best
        practices will provide a baseline, that’s recognisable by Ubuntu
        admins everywhere.
      • Hiring is easier (for companies looking for Ubuntu sysadmins).
        If an admin has Ubuntu experience there’s now a chance that
        he’ll actually be able to apply his knowledge directly.
      • Support is much easier when you can actually make assumptions
        about what people are using as their directory server, and how
        everything speaks together, because *we* defined it.
      • It paves the way for an Ubuntu System Administration
        certification.
    • Etc.

What we should offer is:

  • Enterprise readiness out of the box.
    • Well defined interfaces (contracts, if you will) between components.
      • Example: If we were to decide that Ubuntu Server uses an ldap
        backend for storing mail aliases, we’d clearly document the exact
        query that would be run to fetch that info. If a user for
        whatever reason needed to extend the ldap schema, he’s allowed to do
        so and can expect everything to keep working as long as that query
        gives the same result. Likewise, the LDAP DIT will also be
        clearly documented, so that the user is allowed to add custom
        frontends.
      • These contracts follow our freeze process. I think beta freeze
        would be an appropriate time to lock these down.
    • Simple tools (akin to the ones we already have) to manage these
      things. Home users or small businesses shouldn’t suffer because we
      decided to change the way things work.

      • E.g. if we decide to install an LDAP server and use that from nss
        and pam instead of passwd/shadow on each and every Ubuntu Server
        installation, adduser and such should keep working as it always
        has).

Sorry if it’s a bit of a mess, but as you know, perfect is the enemy of good enough.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>