Ranting...

Oct. 18th, 2007 02:06 pm
gushi: (Default)

...and I'm sure a good portion of you know what box I'm talking about.

Remember the Lorax? Where any idiot could pull a bunch off some tree, knit something together, and sell it as anything they wanted...a "thneed"...yeah. That's Linux.

Same buggy goddamned kernel, supported by umpty-million arguing hackers. Some gnu base utils. From there, what you get is a crapshoot. A familiar MTA? Nah. A compatible version of libc? Maybe. The ability to install things without hair-pulling dependency nightmares? Possibly.

And yet, to try to make Linux easier, and more accessible to the masses, we've over-complicated the HELL out of our configs.
Instead of a program having one main config file, we now have all our programs reading "anything that's in X directory", so that the various package management systems (for those who don't know how to type "make install" can add their separate files without bumping each others' heads (oh, and don't edit them...you'll be sorry if you try to upgrade).

Case in point, I've been dealing with this Debian box for most of the evening^Wmorning. It came with some mailer I do not understand called Exim.

Fine. I replace it with sendmail, and expect sendmail to behave rationally.

Sendmail's config files STILL look like nothing I've ever seen, and start rewriting headers like "From" and "Reply-To" explicitly when I've turned those masquerading features off. I wrestle with this for the better part of an evening, cursing the OS to hell, and eventually discover obscurities the likes of which I've never seen.

The end result, by the way, is posted to comp.mail.sendmail on google -- it was a stupid, obscure error -- but I CAN'T imagine nobody's had it before.

Ranting...

Oct. 18th, 2007 02:06 pm
gushi: (Default)

...and I'm sure a good portion of you know what box I'm talking about.

Remember the Lorax? Where any idiot could pull a bunch off some tree, knit something together, and sell it as anything they wanted...a "thneed"...yeah. That's Linux.

Same buggy goddamned kernel, supported by umpty-million arguing hackers. Some gnu base utils. From there, what you get is a crapshoot. A familiar MTA? Nah. A compatible version of libc? Maybe. The ability to install things without hair-pulling dependency nightmares? Possibly.

And yet, to try to make Linux easier, and more accessible to the masses, we've over-complicated the HELL out of our configs.
Instead of a program having one main config file, we now have all our programs reading "anything that's in X directory", so that the various package management systems (for those who don't know how to type "make install" can add their separate files without bumping each others' heads (oh, and don't edit them...you'll be sorry if you try to upgrade).

Case in point, I've been dealing with this Debian box for most of the evening^Wmorning. It came with some mailer I do not understand called Exim.

Fine. I replace it with sendmail, and expect sendmail to behave rationally.

Sendmail's config files STILL look like nothing I've ever seen, and start rewriting headers like "From" and "Reply-To" explicitly when I've turned those masquerading features off. I wrestle with this for the better part of an evening, cursing the OS to hell, and eventually discover obscurities the likes of which I've never seen.

The end result, by the way, is posted to comp.mail.sendmail on google -- it was a stupid, obscure error -- but I CAN'T imagine nobody's had it before.

gushi: (Default)

At the colo I wanted to build an "emergency netboot recovery machine", so that any user who had a machine that was crashed could remotely reboot and get onto a network-booted recovery CD.

The colo has only three real major OSes we use:

Redhat/Fedora (mainly on the cobalts)
Debian Linux
FreeBSD

On a whim, I decided to research the Debian option first.

Mostly URL's for my own reference )

Hrmmm, this shows serious promise.

What the world REALLY NEEDS, though...is a system that can just PXE-load ISO images. Or one that can mount an ISO, but also look at the boot blocks and create a similar boot-config file. The PXE loader would have to handle all the network throughput, and would need to handle "Emulating" a cdrom, since we can't assume the OS is smart enough to handle the network code.

Also, the same thing would need to have enough brains to redirect output to the serial ports/listening SSH server.

The problem here is that a lot of "netboot" applications are for different reasons:

1) No bootable media (like my laptop) -- of course, you HAVE a keyboard and mouse in this case.

2) No hard drive (like my HP Envizex) -- in this case you have a console as well.

3) No console hardware. I've used this in cases where the screen was shattered, and in situations where I was "remote", via our terminal server. It actually requires getting SEVERAL things to work right all at once (netboot support in the kernel and install media, serial support at all stages of the bootloader, and in some cases, serial support at the application level.)

It's going to be a bitch to get this working.

gushi: (Default)

At the colo I wanted to build an "emergency netboot recovery machine", so that any user who had a machine that was crashed could remotely reboot and get onto a network-booted recovery CD.

The colo has only three real major OSes we use:

Redhat/Fedora (mainly on the cobalts)
Debian Linux
FreeBSD

On a whim, I decided to research the Debian option first.

Mostly URL's for my own reference )

Hrmmm, this shows serious promise.

What the world REALLY NEEDS, though...is a system that can just PXE-load ISO images. Or one that can mount an ISO, but also look at the boot blocks and create a similar boot-config file. The PXE loader would have to handle all the network throughput, and would need to handle "Emulating" a cdrom, since we can't assume the OS is smart enough to handle the network code.

Also, the same thing would need to have enough brains to redirect output to the serial ports/listening SSH server.

The problem here is that a lot of "netboot" applications are for different reasons:

1) No bootable media (like my laptop) -- of course, you HAVE a keyboard and mouse in this case.

2) No hard drive (like my HP Envizex) -- in this case you have a console as well.

3) No console hardware. I've used this in cases where the screen was shattered, and in situations where I was "remote", via our terminal server. It actually requires getting SEVERAL things to work right all at once (netboot support in the kernel and install media, serial support at all stages of the bootloader, and in some cases, serial support at the application level.)

It's going to be a bitch to get this working.

August 2017

S M T W T F S
  12345
678 9101112
13141516171819
20212223242526
27 28293031  

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Sep. 26th, 2017 07:09 am
Powered by Dreamwidth Studios