2006-10-03 23:25

Getting in trouble is interesting. Getting out is educational.

I reorganized the partitions in my notebook. Since it has two different Linuxes, and I didn't touch anything in one of those, I thought I was pretty safe.

Well... I wasn't, because I moved my /boot, and forgot to change my GRUB configuration, so I ended with a non-bootable box.

And not just regular non-bootable:

  • GRUB gave error 17 before the menu
  • The DVD reader is broken
  • My external USB HD is on loan on a client
  • My Sony-discman/PCMCIA-SCSI-external-CD-reader needs 110v power (and I have no transformer around)
  • My original Libretto PCMCIA FD works, at least to boot... but I have no other floppy drive to master a diskette.

Yes, I get into this kind of thing more often than most. I buy second hand hardware. I am not a first-worlder, guys.

So... what do you do in such situation? You go with PXE booting.

First I tried the only thing I knew that worked with PXE, LTSP (Linux Terminal Server Project).

So, two hours, a DHCP/TFTP/NFS config later, it's working.

It worked well enough (although it's quite a bit of work) but... I got no way to access the HD, because the only screen is a remote X display!

I am sure with a little elbow grease I could make it give me a local login with decent rescue tools, but it's not really obvious.

Then I googled for "linux PXE distribution" and found RIP. Specifically the RIP-PXE version.

It is meant for recovery, so it's not surprising that it does a better job than LTSP, which isn't.

One nice thing is that it loads its root FS into RAM from TFTP, so no need for NFSROOT (or NFS at all, really). It works with only DHCP and TFTP. Quite trivial to do... but not documented. However, starting with the LTSP docs about PXE booting, it was pretty obvious :-)

This is what you need to put in your DHCP config (in the subnet chunk):

if substring (option vendor-class-identifier, 0, 9) = "PXEClient" {
    filename "/pxelinux.0";
}
else{
    filename "/kernel";
}

And then dump RIP-PXE into your /tftpboot (or /var/tfptboot, or whatever).

As long as you can do this with no errors, you are golden:

bash-3.1$ tftp localhost
tftp> get /pxelinux.0
tftp> get /kernel
tftp>

On some tftp servers, you need to do "get /tfptroot/pxelinux.0" or similar. Adjust paths accordingly.

So, it boots. You login. You fix your menu.lst/grub.conf/fstab/whatever, and you are out.

Beautiful!

2006-10-02 09:52

A different UNIX Part I: Mail in not-mail-servers

I have been procrastinating about creating my own Linux distro for at least three years. Guess what? I will still procrastinate about it for a few more, but that doesn mean I can't write about how it's supposed to work ;-)

So, here is a first piece of the puzzle...

What do I mean by "Main in not-mail-servers"?

If by mail server we mean a box that has the responsability to handle sending mail for users, non-mail-servers are all the rest.

And what is it they do with mail? They generate it. Both the users and the processes of those boxes generate mail. They do it for cron jobs, they do it for maintenance processes, they do it for alerts, whatever.

And what is it they do with that email? They send it somewhere.

Usually, they send it to themselves. Which is a pretty useless thing.

Go now and check the root mailbox in your computers. I bet most of you have a bunch of mails in them you never checked. Either it's important, in which case you should have placed it in a mailbox you actually read, or it's not, in which case it's useless to store.

In any case, it shouldn't be there.

How does your box send those mails? Using either the sendmail binary, or the mail program (probably mailx), which uses the sendmail binary.

Just because it's called sendmail it doesn't mean it is sendmail, of course. Postfix and qmail provide a sendmail wrapper to inject mail into their queues.

But the main problem is that using those means you need to have a well configured mail server in every box, even if they are not mail servers! Yes, your distro gives you a decent configuration by default which makes things usually work... for local mail delivery at least. Which is probably not really what you want.

Enter nullmailer. A sort of heavily sedated, neutered qmail.

Configuration:

  • Default domain name of outgoing mail in /etc/nullmailer/me

  • List of SMTP servers in /etc/nullmailer/remotes:

    mx1.mydomain.com smtp --user=ralsina --pass=notmyrealpass
    

You can put several, it will try them in order.

And that's that. A tiny service, which uses no TCP ports. The whole thing is 59KB (or less if you use diet libc), has one SUID binary (but it is not SUID root), two config files (both one-liners), no need for aliasing the system users.... and you can remove postfix/sendmail/qmail from most of your servers.

Sounds like a good idea to me.

2006-10-01 13:53

Long update

I have not posted in a long time, not because nothing happened, but because too much happened.

So, here is an update...

Baby

The baby is doing great. The first ultrasound was on Sept. 15th, and hree he is:

ecografiaPoroto

Birthday

That was on Sept. 15th because Rosario wanted it to be my 35th birthday present. So happy birthday to me.

Work

The little company I am starting up is doing great

Hobby

I have decided that I have almost enough packaged for Arch that it's starting to make sense to master some ISOs. Basically: a somewhat-DJB-way-oriented linux distro.

  • Boots using runit
  • Maybe someday will use LUA instead of sh for startup scripts
  • All services should be managed
  • Will introduce genetic diversity to the ecosystem

That means: no sendmail, no postfix, no BIND, no Apache (at least for basic stuff), no many other "leading" programs. That is intentional. If everyone uses BIND, a BIND failure is catastrophic.

If I have learned anything from Outlook/IE it's that having everyone use the same thing is comfortable, but troublesome.

2006-09-17 03:38

Going Higher Level, Leaving the Shell (Part I)

What happens if you try not to use a shell in Linux?

And no, I don't mean for interactive use. Many do that.

No... what happens if you try not to use a shell... to boot your system?

Read more to find out.

2006-09-15 02:11

Logging in style

I wrote a short intro to syslog, in order to stop using it.

Learn about socklog, svlogd and other alternative logging mechanisms.

Because logs are your best friends.

2006-09-14 10:52

The bad side of Arch Linux

I posted yesterday that I liked Arch but I called it "not too good". So, Mark Kretschmann posted a comment asking what I didn't like.

It's not too much, but here it goes:

  1. The upgrades sometimes are a bit painful (switching to udev was a bit hard).
  2. The policy of deleting the package documentation is evil. Really.
  3. The startup system is too simplistic. No default order of startup scripts means sometimes it takes trial and error to figure out what goes first. Hal or dbus? hwd?
  4. The package selection (without unsupported) is somewhat skimpy (no perl-net-server? no perl-html-template?) but that's probably my POV because I am a bit server-oriented.
  5. Some basic packages make scary assumptions. For example, if you have a user with UID 89 when you install mysql server, weird things may happen. Same for UID 40 and named.

On the other hand, the good side (at least for an amateur like me) is a bazillion times bigger.

2006-09-14 01:37

Distro musings

I have been on Arch for a while now.

So far, not bad. Not too good, either, but it is a fun distro.

I am thinking of using it as a base for my ever-vaporous personal small server distro.

You can see any progress I make by searching for my packages in AUR (search for submitter ralsina). AUR is really a nice thing to have for a hobbyist. You put your stuff there, people can find it, they can even try it, comment on it, vote on it... really a very nice community site for a very hobbyist distro.

2006-09-12 10:56

SMTP servers are hell

At least in the sense that they are really full of people with bad intentions...

http://lateral.blogsite.org/static/smtp.png
  • The red stripe are connections blocked because the sender is listed in spamcop.
  • The blue stripe is connections blocked because the sender is in NJABL.
  • The darker green stripe is connections that are rate-limited because they look like a DOS or address spam (client connecting too quickly)

The top green line is SMTP connections.

The thin white stripe is real connections that we allow to send email.

Of course when you look at those...

http://lateral.blogsite.org/static/sa.png
  • 42% are spam (yes, the filter is quite efficient).

So, about 1 in 5 connection attempts actually intends to send a real, good, valid email.

I am amazed this email thingamajig still works.

2006-09-08 18:41

Graphing qmail/courier-imap stats using munin

Traditionally, you graphed your system's status using MRTG but nowadays, there are much nicer tools, and I like Munin.

For MRTG+qmail there are many scripts, but I couldn't find one I liked for Munin.

Since munin is modular, it's easy to fix, of course.

First, get the excellent qmrtg which gives you great, quick, awesome multilog-crunching tools.

Then, check the cods, check the munin plugin docs, and it's pretty much a 20-line thingie. In shell.

I would post it, but my blogging tool hates shell code :-)

And you get your graphs. I am probably going to write a collection of these and publish it somewhere.

2006-09-01 22:01

Need a flat DB? Use TDB!

No, do not use gdbm. Probably not bdb either.

TDB allows for concurrent writes. So, if you want to store some data in a file in your application/tool/command/whatever, and there is a chance that you need concurrent writes... TDB is really the only reasonable choice I know.

You can even have distributed TDBs.

I found out about TDB while writing a persistant cache for a little tool (a qmail plugin). Since by its nature it would have concurrent writes all the time, I was aiming for something like memcached, or its disk-based version... but TDB solves the problem nicely and effortlessly.

So, if you need a flat DB (a.k.a anonymous blobs with a single index, a.k.a a hash in a file)...

Contents © 2000-2019 Roberto Alsina