ifdown: Interface eth0 not configured – the solution

ifdown: Interface eth0 not configured – the solution

After I imaged the disks from a failing Debian server to newer hardware, I got the error message ifdown: Interface eth0 not configured after issuing the command ifdown eth0. There’s not a lot of documentation out there about this so hopefully this writeup will help you if you’re getting this puzzling message.

This should be the same in Ubuntu, for what it’s worth.

Read more

More about Pfsense, the alternative to the crappy consumer router

I spent some time over the weekend playing with Pfsense, and I can’t say much about it other than it does what it says. I didn’t throw a ton of hardware at it–the best motherboard I have laying around is a late P4-era Celeron board, and the best network card I could find was, believe it or not, an ancient Netgear 10/100 card with the late, lamented DEC Tulip chipset on it. Great card for its time, but, yeah, nice 100-megabit throughput, hipster.

If you actually configure your routers rather than just plugging them in, you can do this. Plug in a couple of network cards, plug in a hard drive that you don’t mind getting overwritten, download Pfsense, write the image file to a USB stick, boot off the USB stick, and follow the prompts. Then, to add wireless, plug in a well-supported card like a TP-Link and follow the howto. Read more

Something strange is going on

I’ve been noticing a lot of slowness that I’ve traced to DNS issues lately, typically with the caching DNS in routers. It happened to me, and it happened to my mom. We have different routers from different manufacturers, and they probably even use different embedded operating systems. Hers almost assuredly runs Linux; I have an oddball one that runs FreeBSD.

But the caching nameservers aren’t working well lately. I haven’t investigated why just yet. The solution I found was to hard-code the DNS settings on all my computers rather than letting them pull it from DHCP (my oddball router won’t let me specify external DNSs to use–lovely). Be sure to pick the best ones for your network.

Making that simple change fixed my mom’s dog-slow computer, and fixed my unreliable one.

 

VMWare’s P2V is mildly disappointing but can still save the day

The order came from higher up: Migrate these seven servers to VMWare. That would be easy if you were running Linux, FreeBSD, OS/2, or basically any operating system not made by Microsoft. Give me an OS/2 hard drive out of a 386 with Microchannel, and I can have it booting on a P4 in a matter of minutes and probably have it operational in half an hour.

But Windows ties itself to the hardware too tightly. So you need a $10,000 software package to migrate it. That package is P2V, which stands for "PC to VMWare." I assume.Actually it’s a $2,000 software package with $8,000 worth of training. Whether you need that training, well, that’s another story.

P2V advertises that it’ll take an image of a server, replace all of its hardware drivers with drivers for the hardware VMWare emulates, and off you go.

It does the most critical part of it just fine. It doesn’t matter if the original server was SCSI, IDE, or something nasty like RLL or ESDI–unlikely, but I’ve seen what desperate times sometimes cause to be put into a production server–and it’ll get it booting on VMWare’s emulated LSI Logic SCSI card.

The biggest thing it doesn’t do is migrate your TCP/IP settings to the new network card. If you happen to have an AMD PCNet-based NIC in the server you’re migrating, you’ll have no problems, but the chances of that are slightly better than my chances of finding an 1897 Carlisle & Finch train set at that estate sale on Itaska Street this weekend. More likely, you’ll have a 3Com or an Intel card in your source server.

That may not be a problem for you. But if you’re migrating a web server that’s hosting twelve dozen sites, each with its own IP address, you’ll be stringing together some curses after paying that kind of money.

Worth it? It is in the sense that a telephone saves you thousands of dollars in travel costs, so you could justify paying $600 for it. If you’ve got a fleet of aging NT4 servers and an expensive maintenance contract to match, and it’s over someone’s dead body that the applications they host will go away, you can save that 10 grand in a fiscal year, get those servers moved to newer, better hardware that’s cheaper and easier to maintain, and get them moved in less than a week. It could take you nearly that long to get NT4 running on brand-new hardware. Once.

So, yes, you can justify it to your accounting department.

As far as the time involved, there’s the time it takes to image and re-image the server. That depends on how fast your network is. There’s the time it takes to build a helper VM that P2V runs on. It’ll take you about 5 minutes per server to set up the VMWare instance. If you’ve got new hardware, it’ll only take a few minutes for P2V to run. Then you have to boot the VM, reconfigure anything that needs reconfiguring, boot it again, and repeat until you fix everything that’s broken. Sometimes that’ll be nothing, and sometimes it might be a lot.

I budgeted 4 hours per server. A couple of them took less than an hour. A couple took 8.

Do I wish it were a better product? You bet your boots I do. Was I glad to have it at my disposal this week? You bet that Carlisle & Finch train set I’m not gonna find this weekend I am.

Thanks to P2V, I get to do something fun this weekend instead of building servers.

Open sourcing code doesn’t necessarily mean people will rush to it

Open sourcing code doesn’t necessarily mean people will rush to it

John C. Dvorak wrote a nice layman’s introduction to open source this week on PCMag.com. But he makes at least one big false assumption.

Dvorak says he’d love to see old code open sourced. Some examples he sought, such as CP/M, CP/M-86, and GEM, have already been open source for years. Caldera, after buying the intellectual property of the former Digital Research from Novell, released just about everything that wasn’t directly related to DR-DOS, some of it as GPL, and some under other licenses. The results have hardly been earth shattering.

Read more

A text-mode download manager for Linux/Unix

Way back when, I used to use a program in Windows called Gozilla to speed up my downloads. The problem with it was that Gozilla was invasive and contained a spyware payload. Competing programs emerged, but it seemed like the biggest added feature was always more spyware. So I gave up on HTTP download accelerators.
Downloading Linux distributions got me thinking about them again. When I went to download Knoppix, Links was estimating the download would take a day and a half. On DSL.

Forget that. So I went looking for download managers for Linux. I found a couple. Most of them are console (text) based, but since I don’t have X on the machine I wanted to download to, I wanted a console-based tool. I found one called aget. Even if you have X, you may prefer the light weight of a console tool.

Aget is in the FreeBSD ports, and Red Hat RPMs are available. Since there was nothing for Debian, I just downloaded it and compiled it. It compiled in about a minute on my pokey K5-100, so just about anyone ought to be able to download it and compile it quickly.

It works like wget. You type aget [fully qualified URL] and you get your file, just like wget, only faster.

There’s just one thing missing. I remember when you told Gozilla you wanted a file, it would do a comprehensive search and try to find the file elsewhere, and grab from multiple servers if it could, or at the very least from the server with the lowest latency. Aget doesn’t do that. But it’s still an improvement.

[later] It wasn’t 20 minutes later that I came across axel, which does it all, including searching. Precompiled packages are available for a larger number of platforms. And it’s in Debian, so apt-get install axel gets you going if you run the One True Linux Distribution. ๐Ÿ™‚

If I had my own Linux distribution

I found an interesting editorial called If I had my own Linux Distro. He’s got some good ideas but I wish he’d known what he was talking about on some others.
He says it should be based on FreeBSD because it boots faster than Linux. I thought everyone knew that Unix boot time has very little to do with the kernel? A kernel will boot more slowly if it’s trying to detect too much hardware, but the big factor in boot time is init, not the kernel. BSD’s init is much faster than SysV-style init. Linux distros that use BSD-style inits (Slackware, and optionally, Debian, and, as far as I understand, Gentoo) boot much faster than systems that use a traditional System V-style init. I recently converted a Debian box to use runit, and the decrease in boot time and increase in available memory at boot was noticeable. Unfortunately now the system doesn’t shut down properly. But it proves the concept.

He talks about installing every possible library to eliminate dependency problems. Better idea: Scrap RPM and use apt (like Debian and its derivatives) or a ports-style system like Gentoo. The only time I’ve seen dependency issues crop up in Debian was on a system that had an out of date glibc installed, in which case you solve the issue by either keeping the distribution up to date, or updating glibc prior to installing the package that fails. These problems are exceedingly rare, by the way. In systems like Gentoo, they don’t happen because the installation script downloads and compiles everything necessary.

Debian’s and Gentoo’s solution is far more elegant than his proposal: Installing everything possible isn’t going to solve your issue when glibc is the problem. Blindly replacing glibc was a problem in the past. The problems that caused that are hopefully solved now, but they’re beyond the control of any single distribution, and given the choice between having a new install stomp on glibc and break something old or an error message, I’ll take the error message. Especially since I can clear the issue with an apt-get install glibc. (Then when an old application breaks, it’s my fault, not the operating system’s.)

In all fairness, dependency issues crop up in Windows all the time: When people talk about DLL Hell, they’re talking about dependency problems. It’s a different name for the same problem. On Macintoshes, the equivalent problem was extensions conflicts. For some reason, people don’t hold Linux to the same standard they hold Windows and Macs to. People complain, but when was the last time you heard someone say Windows or Mac OS wasn’t ready for the desktop, or the server room, or the enterprise, or your widowed great aunt?

He also talks about not worrying about bloat. I take issue with that. When it’s possible to make a graphical Linux distribution that fits on a handful of floppies, there’s no reason not to make a system smooth and fast. That means you do a lot of things. Compile for an advanced architecture and use the -O3 options. Use an advanced compiler like CGG 3.2 or Intel’s ICC 7.0 while you’re at it. Prelink the binaries. Use a fast-booting init and a high-performance system logger. Mount filesystems with the highest-performing options by default. Partition off /var and /tmp so those directories don’t fragment the rest of your filesystem. Linux can outperform other operating systems on like hardware, so it should.

But when you do those things, then it necessarily follows that people are going to want to run your distribution on marginal hardware, and you can’t count on marginal hardware having a 20-gig hard drive. It’s possible to give people the basic utilities, XFree86, a reasonably slick window manager or environment, and the apps everyone wants (word processing, e-mail, personal finance, a web browser, instant messaging, a media player, a graphics viewer, a few card games, and–I’ll say it–file sharing) in a few hundred megabytes. So why not give it to them?

I guess all of this brings up the nicest thing about Linux. All the source code to anything desirable and all the tools are out there, so a person with vision can take them and build the ultimate distribution with it.

Yes, the idea is tempting.

Possibly the first Apache worm

I just found this article describing a worm that attempts to infect vulnerable Apache servers running on FreeBSD.
This doesn’t have much effect on Linux or other Unix variants (other than probably crashing lots of Apache sessions, which the machine may or may not recover gracefully from) but chances are this is just a harbinger of things to come.

You should upgrade to Apache 1.3.26 or Apache 2.0.39 immediately to avoid any problems, especially if you use FreeBSD. I’ve been running version 1.3.26 on Debian here for about a week without any issues, as I’ve come to expect from Apache.

Analysis of the Apple Mac Xserver

Given my positive reaction to the Compaq Proliant DL320, Svenson e-mailed and asked me what I thought of Apple’s Xserver.
In truest Slashdot fashion, I’m going to present strong opinions about something I’ve never seen. Well, not necessarily the strong opinions compared to some of what you’re used to seeing from my direction. But still…

Short answer: I like the idea. The PPC is a fine chip, and I’ve got a couple of old Macs at work (a 7300 and a 7500) running Debian. One of them keeps an eye on the DHCP servers and mails out daily reports (DHCP on Windows NT is really awful; I didn’t think it was possible to mess it up but Microsoft found a way) and acts as a backup listserver (we make changes on it and see if it breaks before we break the production server). The other one is currently acting as an IMAP/Webmail server that served as an outstanding proof of concept for our next big project. I don’t know that the machines are really any faster than a comparable Pentium-class CPU would be, but they’re robust and solid machines. I wouldn’t hesitate to press them into mission-critical duty if the need arose. For example, if the door opened, I’d be falling all over myself to make those two machines handle DHCP, WINS, and caching DNS for our two remote sites.

So… Apples running Linux are a fine thing. A 1U rack-mount unit with a pair of fast PPC chips in it and capable of running Linux is certainly a fine thing. It’ll suck down less CPU power than an equivalent Intel-based system would, which is an important consideration for densely-packed data centers. I wouldn’t run Mac OS X Server on it because I’d want all of its CPU power to go towards real work, rather than putting pretty pictures on a non-existent screen. Real servers are administered via telnet or dumb terminal.

What I don’t like about the Xserver is the price. As usual, you get more bang for the buck from an x86-based product. The entry-level Xserver has a single 1 GHz PowerPC, 256 megs of RAM, and a 60-gig IDE disk. It’ll set you back a cool 3 grand. We just paid just over $1300 for a Proliant DL320 with a 1.13 GHz P3 CPU, 128 megs of RAM, and a 40-gig IDE disk. Adding 256 megs of RAM is a hundred bucks, and the price difference between a 40- and a 60-gig drive is trivial. Now, granted, Apple’s price includes a server license, and I’m assuming you’ll run Linux or FreeBSD or OpenBSD on the Intel-based system. But Linux and BSD are hardly unproven; you can easily expect them to give you the same reliability as OS X Server and possibly better performance.

But the other thing that makes me uncomfortable is Apple’s experience making and selling and supporting servers, or rather its lack thereof. Compaq is used to making servers that sit in the datacenter and run 24/7. Big businesses have been running their businesses on Compaq servers for more than a decade. Compaq knows how to give businesses what they need. (So does HP, which is a good thing considering HP now owns Compaq.) If anything ever goes wrong with an Apple product, don’t bother calling Apple customer service. If you want to hear a more pleasant, helpful, and unsuspicious voice on the other end, call the IRS. You might even get better advice on how to fix your Mac from the IRS. (Apple will just tell you to remove the third-party memory in the machine. You’ll respond that you have no third-party memory, and they’ll repeat the demand. There. I just saved you a phone call. You don’t have to thank me.)

I know Apple makes good iron that’s capable of running a long time, assuming it has a quality OS on it. I’ve also been around long enough to know that hardware failures happen, regardless of how good the iron is, so you want someone to stand behind it. Compaq knows that IBM and Dell are constantly sitting on the fence like vultures, wanting to grab its business if it messes up, and it acts accordingly. That’s the beauty of competition.

So, what of the Xserver? It’ll be very interesting to see how much less electricity it uses than a comparable Intel-based system. It’ll be very interesting to see whether Apple’s experiment with IDE disks in the enterprise works out. It’ll be even more interesting to see how Apple adjusts to meeting the demands of the enterprise.

It sounds like a great job for Somebody Else.

I’ll be watching that guy’s experience closely.

WordPress Appliance - Powered by TurnKey Linux