Questy.org

Tech musings and other things...

My Review of Roku HD Player

| Comments

Originally submitted at Roku

The best-selling HD Player (as known as Netflix Player by Roku) plays High Definition video and connects to surround sound audio.

Roku HD Player

Roku Outstanding, Content Scarce

By cvquesty from Atlanta, GA on 12/29/2009

4out of 5

Pros: High quality picture, Reliability, Great value, Easy to use, Easy to set up

Cons: Want more video choices

Best Uses: Primary TV

Describe Yourself: Movie buff, Netflix fan, Technophile, Early adopter, Power User

We are on the verge of eliminating Cable TV, thanks to Roku. The only problem left is the dearth of programming choices. There are MANY more online video and audio networks out there all primed and ready to be carried by the likes of a Roku. Give me more programming, and I’ll go with you all the way.

I might even pay a monthly subscription if you can get Hulu or Boxee or some other content market deal.

(legalese)

*[12/29/2009]: 20091229T1200-0800

LDAP Administration III – ‘Odds ‘n Ends’

| Comments

By now you should have a functional LDAP server, a properly configured client, and the ability to authenticate against your server.  However, the last couple “cogs in the wheel” are left to manage.

Generally speaking, when you add a user in UNIX-land, part of the process of the adduser command also sets their shell, creates a home directory for them and so forth.  As you may notice, there is no particular method to make this happen in Linux-LDAP.  You just have a store and a tool to manage the store.

Have no fear, it’s PAM to the rescue.

As we said in our first installment, the following packages are all that is necessary to have the basic plumbing of LDAP to work:

openldap

openldap-servers

openldap-clients

openldap-devel

While that is true, there are a couple more packages that put the finishing touches on this to make it sing.  Those are:

nss nss_ldap nscd

NSS is a glibc mechanism or interface allowing access to the common UNIX databases such as the password or hosts database.  It is most commonly used to provide an interface to both local /etc/passd and /etc/shadow files and usually for the purposes of interfacing with LDAP or NIS.

NSS_LDAP is a set of C library extensions which allows X.500 and LDAP directory servers to be used as a primary source of name service information such as users, hosts, groups, and other such data historically managed via local flat files or a NIS infrastructure.

NSCD is a name services caching daemon that provides a cache for the most common name requests.  While useful in speeding up response to queries, nscd has it’s own set of problems.  I’ll cover only some of it’s usefulness, and you should circumspectly determine whether you will need caching at all based on your organization’s size and the size of your serving infrastructure.

Home Directories

First and foremost, to make the login process as pleasurable/smooth an experience as possible, there are some things that we generally do in standard administration practices that ease the user’s experience.  Namely, we setup a standard set of configuration and environment files to provide a consistent user experience of the shell.  These are usually their home directory files such as:

.bashrc .bash_profile .bash_logout .vimrc .mozilla

Usually these are handled in the usual way via the useradd command, which also copies one of everything from the /etc/skel directory to your user’s home.

As you can see, simply adding a user to the LDAP store would not give occasion for this to happen.  PAM to the rescue!  PAM contains a module that is their “mkhomedir” module.  Depending on your architecture, this lives in the /lib or the /lib64 directories under “security”:

/lib/security/pam_mkhomedir.so /lib64/security/pam_mkhomedir.so

What these modules do when properly invoked is on the first connection of a user that is validated as a proper user/password combination via LDAP, PAM sees that they have no home directory, and creates the home directory for them just as if you, the administrator had created it with the adduser script.

This, by far, is one of the handiest modules provided by PAM.

Turning on the PAM

To turn on the mkhomedir facility for your servers and clients, simply do the following:

In /etc/pam.d there are a number of configuration files for handling login defs for varying circumstances.  What we are interested in is system-auth.  System-auth is also sourced by the sshd option, so this will work for both console logins and ssh/remote logins.

The last stanza of the system-auth configuration file is the “session” section.  On the second-to-last line between the pam_unix and pam_ldap designations, add the following:

session     required     pam_mkhomedir.so

This is a keyword set that tells Linux to load up and perform the functions offered by the pam_mkhomedir module.  Now, whenever you connect to a system configured in this way, it will automatically create the user’s skel information and change ownerships to the proper settings so the user can login.

Security

You may note that I also referred to using group-based security.  In LDAP/PAM-land, this is just as simple as the above PAM setup.  Look into the individual system’s /etc/security directory for a file called access.conf.  This file allows you to grant/deny access to individual users, groups, and also where they can connect to this machine from.  The syntax is clearly explained in the file itself, but here’s an example.

Let’s say I only want root, wheel, and the admins group to be able to access a certain system.  let’s say they can access this system from anywhere.  Now let’s say I also want the backup group to access the same system, but only from one host.  The setup is quite simple.  First, let’s allow complete access to the people we wish to be able to connect from everywhere.  At the end of the /etc/security/access.conf file, add the following line:

+: root wheel admins : ALL

This tells the system to add access for root, wheel, and admins from ALL hosts.  Now, let’s put in those backup admins, but only allow them to connect from the host we want them to come from:

+: backup : 10.1.10.10

This means the backup group can access this host, but only from the host 10.1.10.10.  There are many other methods of allowing and denying access in this file.  The documentation is contained within the file, so feel free to look through it for more information.

The MOST important line is the last line, however.  After you’ve setup all the people you WANT to access the system, that does no good if all access is still left on for everyone, everywhere.  The final line in the file should be to deny all access to anyone else not specified above, and would look like this:

  • : ALL : ALL

Simply stated, this removes (or subtracts) all access for ALL other users from ALL other hosts.  This line is evaluated last after the preceding lines are, and will take the preceding lines into account when setting up it’s rules in memory.

At the very worst, if you mis-order the lines here, you may not be able to login to the system and will need to boot to single-user mode and then use the article here on this site entitled “A Neat Trick” to make /etc read/write so you can change the configuration and then reboot back into your system’s default runlevel, but if you’re careful, this will be quite easy to configure and manage.

Closing Thoughts

I’m sure there’s a few things I left out, and I will be revising this series at some point in time to allow for any omissions I’ve made.  I will also be adding in feature suggestions and will be following this up with a sudo article so you can overlay the “on-box” security set you’d like to see happen in your environment after your LDAP infrastructure is in place.

Feel free to drop me a note if you see anything amiss, and I’ll be sure to correct it and give you props.

LDAP Administration – Part II

| Comments

Ok, so in our previous installment, we got LDAP all configured up from the client perspective.  I’ll cover some other client-based niceties such as extra PAM modules and security in our third installment.  For now, back to the show!

The Server

The lightweight Directory Access Protocol (LDAP) gives us tons of things to use to help make the system login/logout process easy to manage and maintain.  The LDAP server runs over the Berkeley Database (BDB) as a data backend, and has a long history as a protocol/standard.

As we said last time, the server configuration consists of the contents of the /etc/openldap directory with the primary file of interest being the /etc/openldap/slapd.conf file.  The secondary file of interest will be the /etc/ldap.conf file, another server configuration file.

/etc/openldap/slapd.conf

First, we will cover the ldap daemon (slapd) configuration file, /etc/openldap/slapd.conf.  This file is responsible for specifying information regarding what schemas to use, loggin parametwes, database specifications and locations, security, replication, and security grants.

Let’s start with a very simple slapd.conf file:

# OpenLDAP Server Configuration # Primary Server Schemas include         /etc/openldap/schema/core.schema include         /etc/openldap/schema/cosine.schema include         /etc/openldap/schema/inetorgperson.schema include         /etc/openldap/schema/nis.schema include         /etc/openldap/schema/redhat/autofs.schema # Logging loglevel 0 pidfile      /var/run/openldap/slapd.pid argsfile    /var/run/openldap/slapd.args # bdb database definitions database             bdb suffix                   "dc=bob,dc=com" rootdn                 "cn=admin,dc=bob,dc=com" rootpw                secret schemacheck    off # location of the data files directory              /var/lib/ldap # Indexes to help speed up queries index objectClass,uid,uidNumber,gidNumber,memberUid     eq index cn,mail,surname,givenname                                                eq,subinitial # Grant users rights to change their own password access to attrs=userPassword by self write by anonymous auth by dn.base="cn=admin,dc=bob,dc=com" write by * noneaccess to * by self write by dn.base="cn=admin,dc=bob,dc=com" write by * read

This is a very basic slapd.conf file without TLS security information, without replication information, and without any frills at all.  Recall that our primary goal here is to get a basic LDAP server running and working without any frills.  We want the ting to work, and then we’ll add features and security as time goes on.

/etc/ldap.conf

The /etc/ldap.conf file bills itself as the “configuration file for the LDAP nameservice switch library and the LDAP PAM module”.  While we just configured the operation of the server, we must now put the “glue” in place so that PAM knows how to ask questions of the LDAP system to know if a user is allowed to login or not.  Again, a very simple /etc/ldap.conf file:

# ldap.conf -- simple configuration # Distinguished name of the search base base dc=bob,dc=com # The distinguished name to bind to the server with binddn cn=admin,dc=bob,dc=com # Password to bind to the directory with bindpw secretpassword # Search TimeLimit timelimit 120 # bind/connection timelimit bind_timelimit 120 # idle timelimit idle_timelimit 3600 # PAM password format pam_password md5 # Assume no supplemental groups for these named users nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman # Main LDAP configuration piece uri ldap://ldap.bob.com ssl no tls_cacertdir /etc/openldap/cacerts

A couple of notes here.  First, the nss_initgroups_ignoreusers portion can most likely be left out.  This is an artifact (as far as I am aware) of being on a RedHat system as several of these users are defaults on RedHat.  Next:  The timelimits are just sane numbers, nothing special.  Should there be any need for tweaking this, it will be in your own experience across your own environment.

Much like the earlier client configuration file, this serves somewhat the same purpose, but for the PAM system as a client rather than a system itself as a client.

Crank it Up!

At this point, you should be able to start up your server to begin configuring it for use.  In RedHat-land, as many of you already know, this is typically a two-part process.  First, you set the service to start at boot and then you start it up.  First, run the command to set the runlevels in which you want ldap to start:

chkconfig --level 2345 ldap on

And then use the RedHat tools to start the service up:

/sbin/service ldap start

At this point, you should have a fully functional LDAP server running with no particular schema or setup, ready to take data (in our case, POSIX compliant login information) and serve it out to your infrastructure.

Populating the Database

With the RedHat packages come a myriad of important tools you need to help migrate your current authentication information into the LDAP store.  The location of these helpful perl scripts is: /usr/share/openldap/migration.  Before you use these tools, make sure you edit the migrate_common.ph file in this location to match your environment like so:

$DEFAULT_MAIL_DOMAIN = "bob.com" $DEFAULT_BASE = "dc=bob,dc=com"

This file is sourced by all the migration scripts resident in this directory, and will automagically insert these values where necessary.

Next, let’s do a trial-run of converting our passwd file in “LDAP-ese”.  Since you’ve already edited the migrate_common.ph, you can directly migrate your /etc/passwd and /etc/group files like so:

_From the /usr/share/openldap/migration directory:_ ./migrate_passwd.pl /etc/passwd ./passwd.ldif _Similarly, convert your groups file as well:_ ./migrate_group.pl /etc/group ./group.ldif

What these commands will do is convert your standard /etc/passwd and /etc/group file to ldif-formatted files for import into your LDAP store.  Let’s look at a record for an example:

> > dn: uid=bin,ou=People,dc=best,dc=turner,dc=com > > > > uid: bin > > > > cn: bin > > > > objectClass: account > > > > objectClass: posixAccount > > > > objectClass: top > > > > objectClass: shadowAccount > > > > userPassword: {crypt}* > > > > shadowLastChange: 14251 > > > > shadowMax: 99999 > > > > shadowWarning: 7 > > > > loginShell: /sbin/nologin > > > > uidNumber: 1 > > > > gidNumber: 1 > > > > homeDirectory: /bin > > > > gecos: bin > > dn: uid=bin,ou=People,dc=best,dc=turner,dc=comuid: bincn: binobjectClass: accountobjectClass: posixAccountobjectClass: topobjectClass: shadowAccountuserPassword: {crypt}*shadowLastChange: 14251shadowMax: 99999shadowWarning: 7loginShell: /sbin/nologinuidNumber: 1gidNumber: 1homeDirectory: /bingecos: bin

The LDIF format has a number of self-explanatory fields that you can see correlate to your /etc/passwd file.  There are other fields here that LDAP needs, but are beyond our concern at this point.  We’ll come back to these later.

I picked a system-default user just to illustrate the format of the ldif.  This user generally has no password, and thus you cannot login using his credentials.  In the userPassword line above, for a regular login user, you would normally see {crypt} followed by a rather large SHA encrypted string representing the user’s hash.

This brings about the question of how you wish to manage your users.  Generally speaking, I allow the local /etc/passwd file manage root and all system-default users (bin, spool, lp, etc.) and all users I add post-installation get placed into LDAP.  In that way, I manage the user centrally from the outset.  I’ll be covering how I limit what users are allowed to access what systems in a later article.

Importing the LDIF

Once you have your LDIF, you have some decisions/edits to make.  look through your dumped ldif file.  Remove each stanza relating to the users you do not wish to manage via LDAP.  The resulting LDIF file will be the one we import.  Generally speaking, in a RedHat system I delete everything before UID 500 (which is usually me) and import everything else.

Once your LDIF file is how you want it to look, it’s time to import.  Import it using the following command, modifying the search base and admin user to suit your configuration:

_ldapadd -W -x -D "cn=admin,dc=bob,dc=com" -W -f passwd.lif_

When you run this command, the LDAP server will churn for a moment (depending on how large your passwd file is) and then will return a clean shell with no errors.

Time to “Get your GUI On”

At this point, I usually point people toward the excellent Apache Directory Studio available at the Apache Directory Project.  This is a gui directory administration tool that can browse and edit your entire store.  The Apache Foundation describes it like so:

Apache Directory Studio is a complete directory tooling platform intended to be used with any LDAP server however it is particularly designed for use with the ApacheDS. It is an Eclipse RCP application, composed of several Eclipse (OSGi) plugins, that can be easily upgraded with additional ones. These plugins can even run within Eclipse itself.

Apache Directory Studio is available for Windows, Linux, and Mac OSX and is a freely-available Apache 2.0 licensed product.

Once you download and configure the Apache Directory Studio, you should be able to view, browse, edit, and manage all aspects of your LDAP store.

Next time, we will tie PAM into LDAP, work with security and group-based access as well as cover a few “odds & ends” to help you use your LDAP store in a variety of different ways.

LDAP Administration – Part I

| Comments

One of the things I’ve worked on over the last year is setting up a centralized LDAP server for authentication in a UNIX environment.  My clients range from early RedHat to our current distro of RH5.2 or CentOS5.2.

A huge issue I’ve run across while doing this work is that I had to piecemeal the information together from all over the Internet because the grand majority of what I could find out there was either for Windows clients or non-POSIX login authorization.

I plan to tell this story mostly in the context of a RedHat-ish rpm-based distro, and the setup of both the server and a Linux client to tell both sides of the story.  I will use my own terminology to begin, making it very simple to explain precisely the setup we’re looking for without getting into a lot of LDAP-ese.  As we go through the setup, I will slowly start to relate my description back to LDAP-ese so you can, once your setup is working, go back to the documentation and determine “just what happened here”

At the end of the story, I’m going to have a LOT of keywords so Google gets a good sampling of this to help someone who may be like I was, looking for a very specific UNIX auth implementation.

Server

One of the big things I needed first was to have the server packages installed.  When I did the original installation, I went a little overboard and downloaded and installed everything from the patch level I used, but the essentials are:

openldap openldap-servers openldap-clients openldap-devel

After getting these installed (via either yum or rpm -i…whichever is your preference) then you should have a subset of important files and tools lying about around your system.  These will be (in no particular order):

/etc/openldap /etc/openldap/slapd.conf /etc/ldap.conf

The /etc/openldap directory houses all the files pertaining to your server piece.  From your certs to the appropriate schemas to an example DB_CONFIG for the LDAP backend (Berkeley DB…more about these later…)  The primary file of interest in /etc/openldap will be slapd.conf.  In /etc/ldap.conf, you have the server configuration file.

In my setup, the purposes and configuration of these particular files seemed to be the biggest hinderance to getting everything running as I would expect.  At one moment, there was a config element in /etc/ldap.conf and in another there was one in /etc/openldap/slapd.conf.  It appears there has been some overlap from version to version, and even now you have to take all files together, viewing it all as a single configuration.  That’s where we will start.

/etc/ldap.conf

I’d say that my first confusing issue was that this file serves different functions depending on whether you are looking at a server or a client.  For the client, it is a simple, short file specifying the server and the ldap URI to use for searches.  In the server context, it is for the LDAP nameservice switch configuration and the LDAP module for PAM.

/etc/openldap/ldap.conf

Let’s start with the client config.  I know this is putting the cart before the horse, but it is the simplest part of this procedure.  If we configure it now and utilize it in it’s easiest configuration, we know that once resolution and searches are functioning, the server is setup correctly.

First, let’s talk about your organization a bit before launching into this configuration.  Recall that our entire purpose at this point is POSIX-compliant user/pass functionality and everything that implies.  I’m not looking for a phonebook (what seems to be a large portion of the tutorials out there on the ‘net and in the O'Reilly LDAP book) and I’m not looking to find where employee X sits.  I want user/pass/GECOS, etc. of a POSIX-compliant login.

Most organizations are on the Internet these days.  Let’s take my mythical company “Bob.com”.  Bob’s company, Bob.com has a website and all the standard DNS resolution and email and the like for Bob.com is already working perfectly.  It already has a nifty website driving tons of customers to Bob’s company.  As for the infrastructure of UNIX logins and passwords, the ONLY THING that Bob.com and LDAP have in common is that their bits and bytes are traveling over the same wires as Bob.com’s Internet traffic.  That’s where the connection ends.  When we start talking about the naming in the LDAP space, even though Bob.com is valid in the Internet as well as the LDAP world, they have absolutely nothing to do with one another from a technical perspective.

In LDAP-land, Bob.com is the name of the company we will be serving.  So, think of this as the top of your tree from which all the other branches will grow.  Bob.com is your organization.  It is also the top of your tree.  This is a conceptual designation.

We will be installing the LDAP server on a piece of server hardware hanging in a rack.  This server will have a DNS hostname, and will be called ldap.bob.com.  This has absolutely nothing to do with LDAP-land.  This is simply the every day server naming and numbering like you would do for a new name/app/web server and the like.

The top of our conceptual tree in our organization is the bob.com base name.  In LDAP-land, we refer to this as your “search base”.  This is the name root from which all things flow.  Like an OU in active directory or a root filesystem in UNIX, everything happens under this.  So, for our LDAP-land based conceptual idea of our organization, we will have a base distinguished name of Bob.com.  In LDAP-ese, we refer to a base by it’s separate parts.  In the case of the base name (for our purposes) these separate parts are known as “domain components”.  This, should you choose an LDAP name space to match your Internet name space, is the sole point where these two worlds converge.  Bob.com is an Internet domain name while the LDAP-ese separations of the search base are called “domain components”.

Let’s see what this looks like:

Internet domain name:                   bob.com hostname of the server:                   ldap.bob.com LDAP Search base:                          dc=bob,dc=com

If you remember some of your DNS-fu, you’ll recall that the host/domain portions of the Internet name have significance in IP-Address land, but that is outside the scope of our little discussion here.  The important thing for you to know is that bob.com is an Internet-based domain name that can be resolved in your browser of choice to a location on the Internet for your viewing pleasure.  The LDAP name space of dc=bob,dc=com is an LDAP-formatted representation of the search base of your organization conceptually referred to as Bob.com.

I know that was painful, but the distinction is paramount to proper understanding of this process, how it is named, and how it is used.

So, let’s take our client configuration and give it a whirl…

Configuring a Client

Simply stated, the client only needs to know three things.  First, it needs to know our base conceptual name (or search base), an Internet-formatted URI to know how to get to the host that has this storehouse of information, and the OS itself needs to know to look at LDAP for this information rather than local files.  Let’s look at a client machine’s local file:

File:  /etc/openldap/ldap.conf

#

LDAP Defaults

#

BASE dc=bob,dc=com URI ldap://ldap.bob.com TLS_CACERTDIR /etc/openldap/cacerts

That’s really all there is.  The search base and the URI to find the server.  You already know about the file that tells UNIX where to look for information.  It is the file /etc/nsswitch.conf

This file contains mappings regarding what the system should look at for which services.  The file is in the format:

service:     location1 location2 location3…

You can have as many locations as you need for UNIX to search, but we’re only going to worry about two.  local files and the LDAP store.  In the /etc/nsswitch.conf file, you will have three lines for authentication we are concerned with.  They will look like so:

passwd:     files shadow:    files group:        files

This essentially tells the system  that for passwords, password hashes, and groups that you should look at the local files.  Pretty straightforward.  However, to point us at the LDAP server for this information, you need only change this file in the following way:

passwd:     files ldap shadow:    files ldap group:        files ldap

What this will do is check the local files for a user and then the LDAP store for that user.  If they do not exist locally, they will resolve from LDAP.  The caveat here is that the user you’re trying to login with for testing LDAP should not already exist on the client system.  If it already does, you have a possible issue in that things will work, and you’ll never know if you’re resolving from local files or LDAP.  I’ll show you how to handle this later.

That’s it for the client.  Now we have a client configured to shout at ldap.bob.com using the search base of dc=bob,dc=com looking for password, shadow, and group information for POSIX compliant logins on your client host.

Next time, we’ll start setting up the server.

A Neat Trick…

| Comments

When you have a large environment that can and does have a number of fingers into things, there is always the possibility that something could go awry on bootup such that you cannot boot fully into the OS.  When you do this, it’s common practice to use Grub options or a CD to boot into single-user mode and then do whatever it is you need to do.

Sometimes, however, you get booted into single and go to edit a file, say… /etc/fstab for example, and when you open it shows as “readonly”.

Here’s a simple trick to do once you’re logged in as root at a single-user prompt to do the work you need to do.  run:

mount / -o remount,rw

This will remount the root filesystem as read-wwrite during maintenance so you can edit whatever you like in the /etc directory (or anything else residing on the root filesystem.

I’ve had to use this a number of times for varying reasons, and thought it might help you a bit.

Linux and the "Mainstream"

| Comments

It’s not terribly often I have a “get real” moment with Linux in general and the community in particular (the latter more often than the former to be sure), but I am at that point again.

My thought exercise deals primarily with desktop computing, not the server-space.  Why, you may ask?

In the server space, you rarely have the OS wars, zealotry, flame-fests, and all-out fanboy-ism.  Server admins do their jobs, install, deploy, commission, decommission, and serve the user space quite happily from their distro of choice, oftentimes with the users blissfully unaware of the underlying technology.  All they know is that their application is up, available, and it just works.

No, my thoughts are on the user space…the desktop.  The wild west.

If you look around, there is a large base of desktop Linux and UNIX users out there.  From RedHat to Ubuntu or straight Debian, to Slack, SuSE, or Gentoo (to name but a few) there is every shape and color of environment to choose from sporting an innumerable selection of implementations of X, Windowing environments, and associated “enabling” technologies.

It often seems that here is where the largest OS wars are waged.  The Desktop Space.  It even appears that more and more the server side is firmly entrenched in business at all levels, yet the advance and hold of the desktop space is tenuous as ever.  Why?

The Apps

There was a time that it was believed it was all about the apps and the platform didn’t really matter.  As long as the user could get their email and browse YouTube, it didn’t really matter how they got there, as long as they did and piano-playing cats satiated their need for video novelty.

Problem is, that turned out to be far from the case.

No one can deny that with the appropriate gyrations, anyone can use an installation of Linux.  There’s apps there, web browsers with all the lovely plugins we’re used to and with analogues to just about everything we could need in a 21st century computing world.

Still, Linux makes no advance.

The Community

The Linux community is somewhat of a double-edged sword.  On the one hand, you have the largest user community (and by implication, support community) ever to come together for any technology.  It is lauded as the best operating system because of this community in particular.  All this is true.  You can find as many people as you can computers in this world, all with their own take on Linux and it’s place in the world.  From the anti-“other guy” fanatics to the “it’s just the best” aficionados, there is more than you could ever want in the way of free (not $1.00/minute) support you could ever want.

Still, Linux makes no advance.

The Administrators

In the admin’s world, everything is very easy.  You use kickstart to clone machines to a similar (or identical) base installation upon which to work your techno-sorcery for your employer.  You may use puppet, opsware, or other tools to unify configuration management across the enterprise.  You manage your ticket tracking on open-source products running on Linux systems providing sometimes millions of pageviews to the public.  But sitting on your desk, usually mandated by the selfsame company, is a Windows laptop or desktop issued to you by your overlords to use as your primary desktop.

Still Linux makes no advance.

Jobs

You are looking for work.  From your Linux laptop you surf the sea of recruiting sites looking for that perfect Linux gig.  Suddenly, you find it.  All the pieces are there for you to really help make a difference and make this environment just sing.  The money’s good, and the hours and dress code are outstanding.  Best yet, they have a clue and allow you to have a Linux desktop and you even manage the mail,  and calendaring  servers that all fully support Linux!  You click the link, are redirected to the recruiting website, and are greeted with a “Sorry, but this is an Internet Explorer Only Website.  We are sorry for any inconvenience.”

Internet Explorer Only.  For a Linux only job.  At a Linux shop.  Serving a Linux infrastructure.  Let’s say you manage to wrangle an email address of a recruiter and get through… He asks for a resume.  You provide your normal PDF, TXT, or HTML resume for his convenience only to be told “We require Word 2007 format.  It’s all our system understands, and we cannot get you into our system without it”.

Still Linux makes no advance.

Inertia

All these things happen in myriads of ways to different people in different enterprise situations every day.  Either one piece of the puzzle isn’t there, or some part of the communications chain departs from Linux compatibility, or some other vital piece of the puzzle has gone missing, leaving Linux professionals adrift on a desolate, isolated (albeit huge) island that the rest of the world has no problems visiting, but they don’t want to own land there.

The server space could transform into a world where Linux held 75% of the server space, and I still don’t think you would see any more serious penetration into the end-user world than you do today.  Why?

Integration & Documentation

One thing Microsoft has done correctly is build an end-to-end playground for it’s users.  Sure, some of the swings are broken and if you don’t use that merry-go-round quite right it could kill you, but it is a complete playground, and it is the prettiest one on the block.  You don’t need to have directions, you just know how to use all the toys, and you can get around without any training or supervision.

On the other hand, out there in the Linux playground there isn’t the same set of toys, and some of the slides don’t go all the way down. You have to be careful on those monkey-bars since the rough edges haven’t been sanded and painted like you’d expect and nothing really works like anything you’ve seen and there’s none of those cool little signs along the playground showing you how to navigate around and get from game to game.

This can be frustrating enough to make you want to walk back across the street to the lesser sized, lesser featured, lesser capable playground where everything is neatly painted and clearly marked.  All the slidesgo all the way down, and little to no work is necessary on your part other than to just play and have fun.

What?

Ok, what did my putrid attempt at metaphor say?

Simple.  Given enough time, research, and effort, you can do ANYTHING with Linux you set your mind to do.  From browsers to flash to office suites to just about anything you can think of. (even including running many Windows games and tools through amazing products like Crossover)

But there’s one thing there that we forget (especially in America) regarding that whole experience…  It requires work, forethought, research, inference, a little ingenuity and a lot of  what no Windows or Mac box ever requires of you…  effort.  (stick with me for a moment)

The effort in Windows/Mac-land has been moved.  It’s on the “have problems” end.  The second or third experience set you have with your system.  In Linux-land, it’s all been front-loaded.  You have to climb all those hills and overcome all those obstacles first before you get anywhere.

The Way Forward

The only way that Linux will start to proceed and ultimately overcome on the desktop is when the effort bubble moves further away from the initial experience.  The user will have to be able to sit down and do absolutely everything they’ve ever done before with a limited amount of effort just to get going, and while most anyone is willing to learn new things, it’ll take them being mostly trivial learning events (not ever amounting to a learning curve) before users will flock en-masse to Linux desktops.

As much of a Linux fanboy as I am, I’m also sort of realistic.  Until the whole experience from start to finish is at least as smooth as a Windows or Mac world (not the same, but as smooth), lazy users will still tend toward the entropy of “easy to use” most every time.

What Can We Do

This is rather simple, actually.

Get on board with a project or two.  You don’t have to know how to code, just help write documentation.  Learn how the product you’re supporting works inside and out.  Hang out on the chat rooms and support boards, and any and all questions you can answer, do so.  Help out with local Linux install-fests, and don’t be afraid to help a local rookie personally.

The easier adoption becomes, the better for obtaining new “lookers”.  But the easier the entire process becomes, the more long-term converts you’ll have.

The Linux Community can indeed grow and the products we use can, with time, become dominant.  But it starts with each of us doing everything we can to make the adoption and retention process as smooth as, or dare I say it smoother than that of the Windows and Mac world.

Until we reach this level of smoothness and excellence, we are destined to ride that third-place wave.

RedHat Drops the Desktop

| Comments

I read today at Yahoo News that RedHat corporation will be dropping their support of consumer desktop Linux  as we’ve known it for all these many years.  While maintaining support for a corporate desktop, RedHat plans on keeping at what it does best, which is provide a server distribution which holds the majority in corporate implementations.

People Are Funny….

| Comments

Man…  people are funny.  You tell them things many, many times and for some reason, you’re a moron.  They come to you for help, you give them an answer and because it’s either not convenient enough or the answer they wish to hear, you become a moron.

AND THEY CAME TO YOU!  Better yet, They will KEEP coming to you because deep down they know you have the right answer even though they don’t necessarily want to hear it.

I learned a long time ago that System Administration is better than 70% politics.

That brings up a conundrum.

As a sysadmin, my highest priority is my machines.  If they don’t stay up, reliable, and serving, we don’t serve ads, and then we don’t get paid.  As a coworker, the users are my customer.  They deserve the highest priority.  Balancing the needs of the machines (who don’t have feelings, but have very real needs nonetheless) against the needs & desires of the user community can be quite the chore sometimes.