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.
Recent comments