Try htop
Ever needed a process monitor that runs in a terminal? Have you been using top? Use Htop instead. Much, much, much nicer!
Ever needed a process monitor that runs in a terminal? Have you been using top? Use Htop instead. Much, much, much nicer!
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!
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.
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:
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.
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.