Re: [Fwd: Re: AKLUG server]

From: Adam Bultman <adamb@glaven.org>
Date: Sun Dec 31 2006 - 10:29:22 AKST

(Forgive me if the sentiments here have been spoken already. My mail
hasn't been reliable lately.)

While this entire discussion is very interesting, are we sure that the
AKLUG web server is the server we want to be using for educational
purposes?

If the site should be up all the time, then it should be built as such,
with the maintainer's distro of choice being used (Mike chose Nevaeh, and
that's fine.) There's no point in me arguing for Ubuntu or Fedora or
Plan9 for that matter if I'm not going to be maintaining it. Let the
server be the boon or albatross of the maintainer.

If we want to be teaching users about linux, we should use other
computers. Let it be the mirror server (maybe as a test sandbox), or a
test box, or systems that people drag in week to week. I know people
around here have spare systems that could be 'lent' for this type of
thing. I come across a lot of parts, and have a lot of parts lying around
my house - goodness knows I've been giving them away - they might as well
go to a good cause.

Anyway. I like the discussion, I just think the server should be the
maintainer's baby. Goodness knows I hate being told to admin a box I
didn't build and/or want.

Adam

On Sat, 30 Dec 2006, Arthur Corliss wrote:

> Damien:
>
>> You make some good points. However, compiling from source is not always
>> possible. I don't think anyone will find it easy to setup a workstation
>> from source. Compiling X, Gnome and what ever else one might need is
>> crazy. Sure one might learn something but at some point I need to get
>> work done. I only mention this because I've tried.
>
> Compiling all that can be time consuming, and certainly not something you
> want to do every time. However, with Nevaeh, the package management creates
> a package manifest after install. So, you can compile once on your target
> architecture, then use the manifest to create a binary tarball to
> distribute to all the extra machines. Not far from what Gentoo does with
> their binary install option.
>
> That doesn't help you for that first workstation install, but, hey, that's
> not what I made it for. I'm just as comfortable with a dumb terminal on a
> serial tty. Nevaeh is primarily intended for servers.
>
>> We could all run LFS.
>>
>> As a business owner and network/system engineer I have to evaluate
>> everything I do. Lets use my current clients as an example.
>>
>> 1. New server
>> 2. about 2 tarabytes of data at the moment
>> 3. Website, data storage, email are all on this server
>>
>> Lets say I decided to use Slackware. It's stable and secure so why not.
>> What happens if Patrick Volkerding ( the Slackware founder ) decides not
>> to do Slackware any more. Or worse he dies. It almost happened. He got
>> sick from brushing his teeth a few years back. It almost killed him.
>> Back then he was the only guy maintaining Slackware. Lets say for
>> argument sake there is no more Slackware. What do I do?
>>
>> 1. I've got an OS that can't be updated
>> 1. No security patches
>> 2. No upgrading to a new version
>
> Damien, even when I ran Slack (years ago) this was still false. Slack has
> always had a spotty record with timely security updates, so many admins
> treat Slack just like a source-based system. Easy to do since on Slack's
> FTP servers they have all the package build scripts. Update the rev in the
> script, build a new package, and distribute as needed.
>
> The only time this will cause a problem are for *some* major rev upgrades of
> packages that dramatically increased their dependency list and complexity.
> For most servers this isn't an issue from a maintenance perspective. And if
> the Slack maintainers leap-frog you this typically doesn't prevent you from
> going back to their packages, either.
>
>> 2. I've got 2 tarabytes of data that need to go somewhere
>> 1. Maybe I don't want the data on the server because it can't
>> be updated (security)
>> 2. Maybe the client doesn't want his/her data on the server
>> because it can't be updated
>
> As mentioned above, you're tossing out a red herring. These are bogus
> arguments for any competent admin.
>
>> 3. Who pays for the cost of the reinstall and data transfer
>> 1. I was the one who recommended the Slackware OS
>> 2. Who pays for the down time the business will experience
>> while the server is down
>
> Once again, this is just silly. You know, I've had to work on client
> systems running RH EL whatever, and they *couldn't* upgrade because some
> commercial package wasn't support on anything else. But we still needed
> another package to be newer than what RH would publish for that distro rev.
> What do you do? From that point on you become your own package maintainer
> or become a source-based distribution for those packages. Working from
> source should be second nature for any real UNIX admin.
>
> As for 3.2., any consultant worth his salt should be able to figure out how
> to manage that with minimal (read: minutes) downtime. That's a trivial
> exercise.
>
>> In this little scenario Linux didn't go away but Slackware did.
>
> I fail to see the problem.
>
>> Lets say I decide to compile all my applications from source to keep
>> them updated. That will work for a while. However, the libraries in
>> Slack will become old. At some point I will no longer be able to use
>> them. One of my applications will look for a new library and I will be
>> SOL. I could try and update the Libraries but then I'm maintaining my
>> own distribution. I don't want to do that.
>
> You sound like a Windows guy. That's the whole point of the open source
> world -- you're not held hostage when one person/org/distro goes away. You
> do have an option to keep yourself current and safe. If you're not willing
> to use that option if it happens, then what's the point of using Linux? Why
> not use Solaris? These days it's about as cheap, runs most of the same
> software, and you're still dependent on one org for your updates. For that
> matter, Sun probably has a much more viable and forecastable future than
> Ubuntu...
>
>> I should have used Novell for the above scenario. Think of all the
>> servers out there running SUSE. What will they do when Novell is gone.
>
> And Ubuntu will be gone at some point, too. Nothing you've mentioned to
> date makes any sense as to why you would pick Slackware, Ubuntu, or Nevaeh
> over any other. Support & updates are irrelevant when *all* of them are 99%
> collections of pure open source from *third* parties.
>
>> The above is the business side of me. The geek in me wants to compile.
>> Maybe it's time I do LFS.
>
> I highly recommend LFS as an educational project. It still has some fluff
> in it, but it gives you a very good idea of just what a minimal Linux is: a
> kernel and a small collection of utilities.
>
> And maybe, perhaps, it will give you the skills and knowledge to start your
> own distribution that makes sense to *you*, instead of having to live with
> or compensate for the stupid design decisions of your distro of choice. Can
> you honestly say you like *everything* about Ubuntu?
>
>> Oh, hope those Slackware packages are working out for you. I could be
>> wrong but aren't those just tar files? Also RTFM before you upgrade to a
>> new version. You have to do it the "Slackware way". I guess they didn't
>> like the "standard" method of upgrading Linux. If you do it wrong you
>> could end up with a broken system. ;-)
>
> Slackware packages are a tarball that contains binary files and an
> installation script. As to RTFM, when wouldn't you? When you start
> tinkering with critical packages like glibc, module-init, kernel, etc.,
> you'd best know what you're doing. If you're trusting any distro to
> completely idiot-proof something, you're asking for trouble. At one point
> or another, they've all failed. And at some point, we've all done something
> idiot-worthy.
>
> And, BTW, what's the "standard" method of upgrading Linux?! RPMs? Debs?
> Slack's the oldest surviving distro out there, it all started with tarballs
> and cpio archives.
>
> Discussions like this make one thing very clear: we're not educating admins
> in the Linux community like we should. If anyone here really wants to
> understand the nuts and bolts of *all* the distros, here's a self-study
> track to try:
>
> 1) Install and run Slack for some basic Internet services: it's not
> as bare metal as Nevaeh, but it'll definitely teach you more about
> what's really happening on your box
> 2) Read /etc/inittab and Slack's /etc/init.d/rc.* scripts to see
> what happens as the system is bootstrapped and run. Then, for more
> entertainment, try reading the equivalent on a standard SysV-styled
> distro.
> 3) Walk through building LFS and read *all* the documentation. It'll
> give a lot more detail on the minimum requirements for a working
> networked OS, and some rationale for certain configuration options.
>
> And never, ever use Nevaeh Linux. You know the UNIX saying about UNIX being
> user-friendly, just really picky about who its friends are? Nevaeh is the
> manifestation of that phrase. It makes me look like a warm & fuzzy
> free-lovin' hippy humanitarian extrovert in comparison.
>
> And yet, it makes me all tingly inside. ;-> But don't use it. Ever.
>
> --Arthur Corliss
> Bolverk's Lair -- http://arthur.corlissfamily.org/
> Digital Mages -- http://www.digitalmages.com/
> "Live Free or Die, the Only Way to Live" -- NH State Motto
> ---------
> To unsubscribe, send email to <aklug-request@aklug.org>
> with 'unsubscribe' in the message body.
>
>
---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Sun Dec 31 10:36:42 2006

This archive was generated by hypermail 2.1.8 : Sun Dec 31 2006 - 10:36:43 AKST