Linux General Questions

That should work. Thank you.

For reference, old versions of Ubuntu are available at: http://old-releases.ubuntu.com/relea...

Maybe this is the wrong place to ask, but what can I do with a Mac server? We have one laying around at work and I would like to turn it into something useful.

Edwin wrote:

Maybe this is the wrong place to ask, but what can I do with a Mac server? We have one laying around at work and I would like to turn it into something useful.

If you flash the correct boot loader onto it, you can run Linux.

I'll have to keep looking around. We already have internal email, IM, webhosts, etc. Maybe a music server for everyone?

Edwin wrote:

Maybe this is the wrong place to ask, but what can I do with a Mac server? We have one laying around at work and I would like to turn it into something useful.

You could get a copy of rEFIt and actually install Linux on it natively, without having to go through MacOSX every time the server needs a reboot.

The following are if you intend to use Mac OS X:

You can use it for a file server with the server admin tools - Samba and the usual NFS options are available, though permissions can be a little wacky.

Hmm...that's all I can ally think of. The OpenDirectory that it comes with has some very odd backed crap attached which breaks it for normal use.

The mail server isn't horrible. The Jabber (iChat) server is just ejabberd with a fronted on it.

That's all I can think of. My previous workplace had 2 XServe's and 2 Mac Mini Servers, so I have some experience with them.

Edwin wrote:

I'll have to keep looking around. We already have internal email, IM, webhosts, etc. Maybe a music server for everyone?

I was just throwing out general ideas, not knowing the situation you are in.

Music server can work, turn n a version of iTunes and have it share the library. People can connect to it through iTunes at least, and play anything in it. I don't know the inoperability of other clients since I've never had a reason to connect something other than iTunes to iTunes.

We used one to run an EMACS server on and everyone else had clients to connect to it. It was a really interesting experiment. The other was the actual OpenDirectory server, jabber, mail, and general file host. It was a....joy to administrate. To the point I had a Linux server running all the same services, and I was waiting for the server to die.

Edwin wrote:

Maybe this is the wrong place to ask, but what can I do with a Mac server? We have one laying around at work and I would like to turn it into something useful.

PPC or x86?

It's a new MBP 15" so x86.

You can do almost anything with a Mac that you could do with Linux -- it'll fall over sooner if you really load it down, but you're not likely to load it that much. It'll run just about any kind of Unix program you'd want it to.

The MacPorts project is a command-line suite that will let you download source for a very broad range of Unix tools, compile it, and then install and run it locally. It's probably the easiest and least troublesome way to run open source stuff that's not included in the OS to begin with.

You could put Slimserver on it and serve music files, or run Samba and have a general network share, or put Apache on it and serve web pages of whatever sort you wanted. You could put a master iTunes library on it that other machines running iTunes could play music from. (similar to Slimserver, but only works with iTunes.. in exchange for which, you get a better interface.) You could put mail on it, or make it a light-duty SQL server for other projects, or use it for development work. You could run various sorts of network-monitoring software packages there, like MRTG to monitor your overall net traffic, or some kind of SNMP surveillance setup for more general uses.... or simply What's Up to monitor services you're providing to the outside world.

Heck, you could use it as the office Crawl server, so everyone can share their high scores on the same machine.

Alternatively you could sell it (maybe to me) for a nice price since you've got all the other internal services already accounted for. +) Even at $500 it's just bonus money! Or even cheaper! The ground's the limit!

So here is what I am going to do with the idle MBP.

*Webserver hosting:
-Forum
-Poll software
-Anonymous commenting system

*Source control of some kind.
*Some sort of document editor that allows multiple people to edit documents at the same time. Word processing and spreadsheets are the two we need.
*Whatever other nifty things I can find.

Thinking about going the VM route for this as I don't want to risk the actual host OS since we still need it to test Mac client stuff once in a blue moon. Is Ubuntu still the sh*t or is it Mint/Arch these days?

Edwin wrote:

Is Ubuntu still the sh*t or is it Mint/Arch these days?

For servers, it's pure Debian that's the sh*t.

*Legion* wrote:
Edwin wrote:

Is Ubuntu still the sh*t or is it Mint/Arch these days?

For servers, it's pure Debian that's the sh*t. :)

Heh. I prefer Arch for servers myself, but I can see straight Debian being good too.

Server duty is Debian's central competency. Its only true competitor in that space is RHEL. (and, of course, CentOS, and maybe Oracle Linux, but I haven't used Oracle's offering.) For a long time, Debian was much better, because it was a far easier system to administer remotely. I doubt that much difference exists anymore in terms of capabilities (though I'm sure methods differ sharply), but I haven't used RHEL for a long time. Not sure I ever will again.

Malor wrote:

Server duty is Debian's central competency. Its only true competitor in that space is RHEL. (and, of course, CentOS, and maybe Oracle Linux, but I haven't used Oracle's offering.) For a long time, Debian was much better, because it was a far easier system to administer remotely. I doubt that much difference exists anymore in terms of capabilities (though I'm sure methods differ sharply), but I haven't used RHEL for a long time. Not sure I ever will again.

Oracles offering is RHEL, much like CentOS is, with better integration with Oracle's other products.

I'm too used to the corporate focus of RHEL because of the paid support, stability claims, etc. ;). I'm also far more familiar with RHEL and it's derivatives (Cent, Oracle, Fedora) because of the corporate focus it.

I'm also familiar with Arch, but that's more of a personal thing, and having used it on servers at my last job, I like the fact that you pick exactly what you need, and no more.

Since I've barely used Debian, on servers or otherwise, I'm curious as to why?

Since I've barely used Debian, on servers or otherwise, I'm curious as to why?

Why what, exactly?

Malor wrote:

Why what, exactly?

Sorry. I meant to finish that sentence. Why use Debian on servers? What tools differentate it from RHEL? Can you give a basic comparison of your experience with both?

I'm genuinely curious for myself, not for my job. I couldn't get them off of RHEL for anything at this point.

On my workstations at both home and work, I use Arch. I moved away from Gentoo a few years ago after an *emerge* borked everything. In the office, I tend to deploy Ubuntu LTS for most of our stuff, but we do have a few RHEL and CentOS VMs kicking around. They are all great distributions in my humble opinion.

Believe it or not, our Cylinders Preservation and Digitization Project Site survived a slashdotting back in the day on a POS gentoo box.

So what do you all recommend for doing the things I mentioned earlier? I know GWJ runs on Drupal so that is probably a decent way of getting things done.

Malor wrote:

Server duty is Debian's central competency. Its only true competitor in that space is RHEL. (and, of course, CentOS, and maybe Oracle Linux, but I haven't used Oracle's offering.) For a long time, Debian was much better, because it was a far easier system to administer remotely. I doubt that much difference exists anymore in terms of capabilities (though I'm sure methods differ sharply), but I haven't used RHEL for a long time. Not sure I ever will again.

Or FreeBSD, which manages to be a lore more sane than any of those.

athros wrote:
Malor wrote:

Why what, exactly?

Sorry. I meant to finish that sentence. Why use Debian on servers? What tools differentate it from RHEL? Can you give a basic comparison of your experience with both?

I'm genuinely curious for myself, not for my job. I couldn't get them off of RHEL for anything at this point.

Debian package management beats out RHEL in my book.

absurddoctor wrote:
Malor wrote:

Server duty is Debian's central competency. Its only true competitor in that space is RHEL. (and, of course, CentOS, and maybe Oracle Linux, but I haven't used Oracle's offering.) For a long time, Debian was much better, because it was a far easier system to administer remotely. I doubt that much difference exists anymore in terms of capabilities (though I'm sure methods differ sharply), but I haven't used RHEL for a long time. Not sure I ever will again.

Or FreeBSD, which manages to be a lore more sane than any of those.

As a server, I might agree with you. I tried to set up a FreeBSD workstation recently and deleted the VM when I realized you still had to edit .xinitrc to activate your window manager in this, the Year of Our Lord Two Thousand and Twelve.

I've also had occasion to package software and test recently for RHEL/CentOS, and I have to say I was pleasantly surprised; it's come a long way. However, Debian wasn't standing still during that time; they still have the best thought-out policies of the Linux distributions, with tool support that makes it easy to follow the policy. The only good reason to use RHEL (IMO) is because someone somewhere wants a signed support contract. The only good reason to use CentOS et al. is because someone else you care about (but not enough to stage an intervention) uses RHEL and you want to test your software but keep your gold fillings.

To bring these two topics together in an awesome way: Debian GNU/kFreeBSD

For reference, we're running enterprise grade web services to five nines on ubuntu and rhel here.

Why use Debian on servers? What tools differentate it from RHEL? Can you give a basic comparison of your experience with both?

Well, first realize that I haven't used Red Hat in a long, long time. I got an RHCE at one point; I don't know how much that means now, but at the time, it meant you were a solid problem solver on a single workstation, and had a reasonable grasp of the bigger picture. (I'd thought it would mean more than it actually did, to be honest.) So RedHat was willing to say that I knew what I was doing, once. But it has evolved a great deal since I was last really using it, and my knowledge has not kept up. I can tell you where Debian is strong, but I can only tell you where Redhat was weak eight or ten years ago, as opposed to what they're shipping today.

tl;dr version of that: my opinion will be unfair, ignorant, and biased. I was once very knowledgeable about that platform, but I no longer am.

The thing that I liked best about Debian, after having it introduced to me, was simply that the entire system is designed around being administered from the command line. There are a number of GUI tools and wrappers over the basic dpkg infrastructure, but absolutely everything can be done from a simple text command prompt, over a serial terminal if necessary. If all you've got left is a DB9 serial port, and you were smart enough to put a getty on it, you can get in and do just about anything you could do from a working desktop.

This includes full system upgrades, which also work nicely over SSH. This most emphatically did not work on RHEL, at one time. Heck, you couldn't even do routine patches, much of the time. If you tried to do an SSH upgrade over SSH, your session would be killed mid-upgrade, and then it wouldn't be running anymore to reconnect with. And the problems were MUCH worse when trying to do a full system upgrade. RPM, at the time, really didn't like being interrupted mid-upgrade, and you could easily hose a system into total rebuild status by dropping connection at the wrong time. I'm pretty sure they've at least fixed the can't-upgrade-SSH-remotely problem since, but I don't know if you can safely do a full OS upgrade that way.

Debian's overall package management system is really, really smart. It tracks a network of dependencies and conflicts. If you ask it to install something, it will know exactly what other packages are necessary to get it running, and by default it will just get everything and install it all at once. Better, if you use the more recent 'aptitude' tool (as opposed to the older apt-get), all the automatically-acquired packages are marked as Auto. If the requirement for them to be installed disappears, perhaps from changes in dependencies, or if you removed the original package, they will be removed as well. So your system tends to stay cleaner, discarding unused software as necessary. (It will never, however, remove something you explicitly installed, unless you again explicitly instruct it to do so.)

Red Hat was just appallingly terrible on dependencies, when I was using it -- if you were missing dependencies, you got a series of error messages. The first time, it would tell you it was missing dependency X. You'd find and download dependency X, and install it. Then you'd try to install your package, and it would tell you that you were missing dependency Y. (note that it didn't tell you this at first, only about X.) So you have to go find Y. Then it tells you about Z, and so on, until the dependencies are satisfied. And, at any point, it was easily possible to find packages that flat would not install with your other software, that were marked as conflicting. So you could have a package X that depended on Y, and you were not allowed to install Y on your configuration, so you simply could not use X, period, unless you hacked on the source yourself. It was ugly, ugly, ugly, and super frustrating after you'd manually tracked down and installed six or eight dependencies, only to block on the last one. (This almost HAS to be better by now.) At the time I switched, dependency hell was THE major reason to move to Debian. It was constantly, constantly painful to administer an RPM-based system, and even ten years ago, the DEB-based dpkg engine Just Worked. Again, this was so extremely painful that it almost has to have been improved... it couldn't possibly still be that bad.

In Debian, working with source is almost as easy. If you need to modify a package for local requirements, you can just get the package with 'apt-get source XXXX', and it will go and get all the correct source packages, and all the right patches, and apply them all and give you a nice tree, ready to go. After you've made your adjustments, you use the 'debuild' command to reconstruct the DEBs.

Now, this is an area where Debian is weaker than it probably should be... debuild will tell you about dependencies it's missing (usually -dev versions of libraries you have only the runtimes for), and it will tell you all the dependencies at once, but you have to manually install them, it won't do it for you. That probably oughta get fixed. Usually, it's a matter of cutting and pasting part of the debuild output for 'aptitude install', but that also marks all those packages as manual, instead of auto, which is kind of frustrating. If you're working with source files, Debian does not self-prune nearly as well as it does with object code. There really should be some way of creating a virtual package to indicate that you have a source-code version of something, and need the -dev libraries as Auto dependencies, but I'm not aware of one at the moment. You could manually mark all those packages as Auto, but then they'd get autopruned, because the system wouldn't think they were needed.

Upgrading a Debian system is easy -- aptitude safe-upgrade will install all security fixes for your current release. aptitude dist-upgrade will move to the next release. This is where the auto-pruning comes in extra handy, because dependencies tend to change quite a bit across releases, so older software will be removed. But note that 'removing' a package in Debian still keeps all the configuration files, in case you made changes you wanted to keep. If you want to really and truly expunge all files that were created by a package, you must 'purge' it, either with 'aptitude purge packagename' for stuff you installed, or with the --purge-unused switch added to another aptitude command (probably upgrade or dist-upgrade) to fully erase automatic packages.

Another nifty trick you can do is put packages on 'hold', so that they won't be upgraded. You can get a list of packages installed on the system with 'dpkg --get-selections'. Normally, you grep that for what you're looking for, and dump that into a text file. It'll come back saying something like "apache2 install" and "apache-prefork install" and so on, on separate lines. You change any "installs" you wish to "hold", and then cat your text file back into dpkg --set-selections. Voila, held files. Everything else around it will be upgraded like normal, but those packages will freeze in place until you install a newer version, or mark the existing packages as 'install' again. (which means that if you Hold a package, and upgrade it, you have to Hold it again if you don't want further changes.)

If you know a given upgraded package will break something on your system (python-twisted has a nasty habit of introducing incompatible upgrades, for instance), there's a way to mark a given version as Forbidden, so that it will never be installed during any upgrade. This is done with 'aptitude forbid-version', although the actual syntax is too involved to explain here.

Overall, Debian is probably the only truly trustworthy Linux system going, other than RHEL. They still have the problem of the crappy Linux kernel and its mass of security bugs, but for the parts under their control, the software is extremely well-tested and very, very robust. They only get a release out about once every two years, because they test like crazy to get the system nailed down and into a stable state. And then they support it for several more years afterward. For people who actually make a living off of servers, it's the only distro other than RHEL that's run by people who really care about stability.

Debian tends to be slow about rolling out new stuff, but once it does, it works, and it keeps working. Ubuntu in particular is such a fustercluck in comparison that I wouldn't let it anywhere near one of my servers, even though it's based on Debian. For a long time, I loved Ubuntu on desktops, and Debian on servers, but since all the major desktop teams went insane, I don't like Linux on the desktop nearly as well. My only working Linux 'desktop', at the moment, is an out-of-support Ubuntu 10.10 virtual image, the last one with a decent damn interface.

Anyway, I'm getting off into rantsville, sorry. Hopefully that'll give you a basic idea. Debian is an elegant system, and their devotion to stability is legendary. It's not perfect, but I'd call it as good as the best OSes available. Well, except for the problems in the Linux kernel, but all Linux distros have those problems.

After being intimidated away from Debian and [Net, Free]BSD about a decade ago, I tried out Ubuntu 5.04 (I think). It was a nice, easy introduction into how not to run a Linux box: a focus on easily installing anything that sounded interesting and using GUIs for everything. I found after about six months that I didn't know what I was doing, that everything felt like hidden meat, and that I wasn't disciplined-enough to run a system that so easily allowed me to install so many things.

I left for Slackware 10.2 and never looked back. Slackware has no package-management system per se. There are ways to get pre-compiled packages, and I believe even a third-party system for managing dependencies, but at its core Slackware relies on the administrator to manage all that. This is such a nice fit for me. When I want to install something, I look at its dependencies, make note, and decide if I want to follow that tree. Like a food journal, this keeps me from going nuts.

Reading the account of Debian above, I'm tempted to try it out. I could put it in a VM but 2GB RAM doesn't lend itself to a responsive virtualized OS. Thankfully, because I'd have my harddrive bursting with so much crap.

You can actually run a server Debian pretty well in about 256 megs of RAM. You'd probably want to use the text-mode install, though.

The problem with Slackware is its very strength; the fact that so much of it is simple and manual means that you need to understand what's going on a lot better, so you learn the Unix nuts and bolts.... and they are very much worth learning. But it doesn't scale very well. It's easy to run a cluster of 100+ Debian machines, especially with the advent of stuff like Puppet -- you can script the bejezus out of the admin tools. I wouldn't want to try to keep that many Slackware machines patched and up to date.

You can script slackpkg for official packages and probably can script sbopkg for things not provided in the official distribution, but I would tend to agree that a system that manages dependencies, so long as it does so well, will be easier to administer. I base this on absolutely no experience managing any more than one Linux box at a time, so you know it's true.

Well, I'm even more out of date on Slackware than I am on RHEL... when I was last using it, the packaging technology was .tar.gz files. Seriously! I think Slackware was the second distro I ever used, after SLS Linux, and calling it primitive would have been a tad overoptimistic.

That was kind of the drive to move to Red Hat... the RPM package format, with all its many warts, was much better than .tar.gz files. I thought Slackware was still tooling along the old way -- I had no idea it even had a packager now.

You should definitely get more opinions than just mine, because I'm a crotchety graybeard. There's a lot of new stuff being done that I simply don't know about. I get annoyed with packages like NetworkManager on Ubuntu, because it replaces good old /etc/network/interfaces. A GUI solution is pretty clearly better, especially when you consider that it can support wireless and WPA2 encryption and all that, but being old and crotchety, I don't want to learn it.