[ale] Question

[Michael B. Trausch]

On 12/28/2011 02:01 PM, Jim Kinney wrote:
> On Wed, Dec 28, 2011 at 12:57 PM, Michael B. Trausch <mike at trausch.us
> <mailto:mike at trausch.us>> wrote:
>      * GCC works the same on every Linux distribution, and its configuration
>       files follow the same format on every Linux distribution.
> 
> true
> 
>      * Python works the same on every Linux distribution.
> 
> true (mostly)

Not sure I understand what you mean, there.  They are all built from the
same upstream source code, and AFAIK all the standard Python ways of
obtaining Python packages work across all systems.  Sometimes, OS
distributors also package what they deem to be "stable" versions of
Python libraries, but it is possible to instead use whatever is declared
stable in the usual Python distribution channels.

PHP works the same way, with its PEAR system.

>      * ISC software (e.g., BIND and DHCP client/server) use the same
>       configuration files and such on all Linux distributions.
> 
> very true
> 
>     The same is true for most packages that are available on multiple
>     distributions.  Some of the core distribution's processes are likely to
>     be different, in that they are specific to the distribution (e.g., rpm
>     to Red Hat and derivatives), but IMHO it is most important to learn
>     about the underlying software, because that is what you're *really*
>     supporting and administering.
> 
> Um. not quite so true. Each distro has "it's way" of admin'ing the
> system. If a Slackware guy gets on a Gentoo box, guess what, they are
> not very effective. sure they know _what_ to do, but where?!

Having used both Gentoo and Slackware, I'm lost yet again.  Both use
/etc for housing configuration of installed packages.  Probably the most
major difference between those systems is the fact that Slackware
doesn't provide any more default configuration than does the upstream
vendors.  Slackware also doesn't (usually) supply patches such as what
Gentoo uses.  After all, Slackware's goal is to have a system that
follows upstream's directions as closely as possible.  Gentoo's goal is
to have a system that is as flexible and useful as possible.

> LSB not withstanding, all distro's put their configs in different
> locations and with different formats. In some cases, the major package
> has been compiled with extra patches so that the configs fit into the
> distro locations automagically.

Debian, Gentoo, Slackware, and (if I understand correctly) Red Hat all
use /etc for global configuration.  The names of configuration files for
software that has an upstream is the same, though sometimes in a
subdirectory of /etc (for example, /etc/apache or /etc/apache2 might be
the Apache configuration directories used by two different systems).
But that's something that can _easily_ be worked around, either manually
or by using "find /etc -name ..." to find configuration files.

It is true that some packages go through more than others, too.  For
example, Samba upstream puts its config file in ${PREFIX}/lib/smb.conf,
while most OS distros put it in /etc/smb.conf or /etc/samba/smb.conf.
Likewise, MySQL upstream uses /etc/my.conf, while some distributions
move it to /etc/mysql/my.conf (such as Debian and relatives).

> A good _modern_ admin doesn't just pull down the source tarball, make
> configure, make, make install anymore.

I don't disagree---at least in the usual case.  I've encountered many
situations where it is desirable to use fresher upstream code for one or
another reason (usually it is features that drive that, not security
fixes).  For example, I have one Ubuntu server box in production that
has an upstream Samba, because the one that was packaged didn't support
Windows 7 clients (and it still doesn't since they won't backport features).

>     It matters not whether we're talking about Gentoo or Red Hat.  The
>     biggest major difference between the two is the package management
>     system, and probably the second biggest major difference between them is
>     the init system and its configuration.
> 
> EXACTLY! And all of those bits converge in different locations and
> formats for every distro. 

However, none of the init systems are all that difficult to figure out.

I firmly believe that the difference between a good administrator and an
outstanding one is one that is capable of identifying the difference
between the distribution and the software contained within it.  There
are many who I think would disagree with me on this point, but it seems
silly to me to use ISC's DHCP or BIND dæmons without knowing anything
about how they work.

Packaging systems are something that a good administrator can learn in a
few days' time, if they are familiar with any other.  Most of them have
features that are comparable from the point of view of the system
administrator (though they are, of course, very different from the point
of view of the software packager).  And some administrators have more
tolerance for deficient package managers than others, but that's beside
the point.  :^)

>     It is true that sometimes there are "major" differences that aren't in
>     the package or init systems, however those differences are usually
>     attributable to things like customizations in the building of
>     configuration files.  Some distributions may use a macro system of some
>     sort to create the configuration files from a set of files maintained by
>     the distribution.
> 
> In fact, RHEL uses the same kernel number (for the bean-counters) but
> backports all bug-fix and security patches for the life of the product.
> That makes for a non-standard process of administration. The admin has
> to know what was done and where and how to deal with it.

I thought that RHEL had a Red Hat-specific patchlevel for the kernel
packages.

>     Personally, what I would like to see (and don't yet, and don't expect
>     to, honestly) is excellent "ad-hoc" configuration support for systems
>     that doesn't require in-depth knowledge of each program's configuration
>     formats and such, and likewise isn't purposely tied to a single
>     distribution.
> 
> Once ubunutu falls off the market flavor of the month, then RHEL can
> finish the World Domination Tour :-)

Hahaha!  Over my cold, rotting corpse!  :)

> Seriously, it can't ever happen. Linux-land is diverse because people
> perceive different needs and roll their own. RHEL/Fedora/Debian/Ubuntu
> are the generic, one size fits all platforms (I can't see SuSe rising
> from the grave it dug itself). Each serves a need.

Indeed.  Though the one thing in common between them all is the fact
that they use upstream software from multiple projects and bring them
together.

No distribution that I know of makes substantial modifications to the
upstream software (e.g., they don't go about eliminating or
restructuring the configuration files), and in most cases, the biggest
difference from upstream's process is that they override things like
bindir, sysconfdir, prefix and so forth in whatever the package's build
system is.  They also save you some time in that they will usually have
scripts that are run by the package manager which help to mitigate any
changes in what upstream (or even the distributor) has done since the
previous package version.

> From an admin standpoint, employment has a greater likelihood if you are
> skilled in RHEL over all else combined. Does this mean the beancounters
> are running the show? Yep. Doe this make the RHEL process bad? Nope.

The biggest key to RH's success in the enterprise market is that it
started focusing hard on the enterprise early on; it recognized that it
couldn't do both consumer desktops and enterprise servers and desktops
without being detrimental to both.

The only real bitch I have with RH (or any distribution that uses the
RPM package format) is that the package manager is far too easy to
break.  I managed to find breakage in RPM no less than 1 week after the
last time I installed such a distribution, F15.  Any system that suffers
from the same limitations it had more than a decade ago is a system that
I cannot put my trust in.

But, I've gone on at length about RPM in the past, there really isn't
any need to duplicate it in-depth.  I would just like to see them fix
the core format instead of stacking layers on for the purpose of trying
to gloss over legacy bugs that never were fixed.  Then they could fix
the user-interface layers (such as yum and its friends) to be able to
behave more sanely than they do now when they encounter strange
situations, because many of those strange situations would disappear.

> It does mean that the RHEL way is more exacting as it's designed for the
> enterprise.

But it still uses the upstream stuff.

I think the big deal with Red Hat is that they do try to abstract away
some of the underlying things.  But I don't believe that is reason to
not be fully cognizant of what's going on "under the hood", so to speak.
 This is one reason that I dislike (and distrust), for example,
certification programs.  They focus on learning a single thing (the
distribution) and high-level tasks that take place on it, usually using
the distributor's tools.

I personally think that's all bass-ackwards.  Learn the underlying
software, its configuration files and other "plumbing" first; then learn
about the distribution's "porcelain" for working
with/configuring/maintaining/managing it.

> It has tools and capabilities for a single admin to manage effectively
> hundreds of different servers and thousands of similar workstations. And
> it's the only bunch out there that's really poised to take over as
> Redmond declines and Sun/Oracle becomes a one trick pony. And they play
> nicely with the open source process. They buy closed products to bolster
> their business and then spend more cash to open those products up and
> eventually they become fully community-supported products with an
> enterprise supported back-end.

You won't see me argue against the (well-known) fact that Red Hat's
existence and ongoing efforts are beneficial to the world of free
software in general and GNU/Linux distributions in particular.  That
said, it isn't the system for me.  Then again, I keep finding that no
system really is, there are just systems that fit me "better" than
others.  I still want to make a system that fits me, someday, when I
have the time.  I think one of the big problems that we see today is
that our systems are too monolithic, despite the fact that they need not
be.  Package managers could be far better than they are, all the way
around, and I think that a truly great package manager would encourage
modularity and make it possible to give the SA exactly as much control
as they need, not only as much control as the packager or distributor
assigns or delegates.

In fact, I think that the perfect package manager would naturally be
extensible into something that could be used for wide-scale management
of enterprise or even larger environments.

	--- Mike

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 729 bytes
Desc: OpenPGP digital signature
Url : http://mail.ale.org/pipermail/ale/attachments/20111228/37f5a723/attachment.bin