Updated: Due to much feedback, I now know of three ways to do this . . .

1) On BSD systems, you can use jot(1):
sleep `jot -r 1 1 900`

2) If you are scripting with bash, you can use $RANDOM:
sleep `echo $RANDOM%900 | bc`

3) For portability, you can resort to my first solution:
# Sleep up to fifteen minutes
sleep `echo $$%900 | bc`

$$ is the process ID (PID), or “random seed” which on most systems is a value between 1 and 65,535. Fifteen minutes is 900 seconds. % is modulo, which is like division but it gives you the remainder. Thus, $$ % 900 will give you a result between 0 and 899. With bash, $RANDOM provides the same utility, except it is a different value whenever you reference it.

Updated yet again . . . says a friend:
nah it’s using `echo .. | bc` that bugs me, 2 fork+execs, let your shell do the math, it knows how
so $(( $$ % 900 )) should work in bsd sh

For efficiency, you could rewrite the latter two solutions:
2.1) sleep $(( $RANDOM % 900 ))
3.1) sleep $(( $$ % 900 ))

The revised solution will work in sh-derived shells: sh, bash, ksh. My original “portable” solution will also work if you’re scripting in csh or tcsh.

0-20:57 djh@noneedto ~$ env TZ=UTC date
Tue May  6 03:57:07 UTC 2008

The env bit is not needed in bash, but it makes tcsh happy.

Update: Mark points out an easier solution:
date -u

Knowing you can set TZ= is still useful in case you ever need to contemplate an alternate timezone.

(Thanks, Saul and Dave for improving my knowledge.)

I got started graphing various Linux distributions against each other, XP versus Vista, and trying to figure out the best keyword for OS X. Then, I wondered about FreeBSD. Against Ubuntu, it was a flatline. So, I asked myself: what is the threshold for a dead or dying Operating System?

Amiga vs FreeBSD:

Ouch! Can we get deader?

Amiga vs FreeBSD vs BeOS:

To be fair, the cult of Amiga is still strong . . . BeOS is well and truly dead. But how do the BSDs fare?

Amiga vs FreeBSD vs BeOS vs NetBSD vs OpenBSD:

NetBSD has been sleeping with the BeOS fishes for a while, and OpenBSD is on its way. And that’s a league below Amiga!

In Red Hat land, only Fedora beats “the Amiga Line”. For Unix in general, nothing stops the Ubuntu juggernaut. But there’s a long way to go to catch up with Uncle Bill.

(Yes, it is a rainy night and the girlfriend is out of town.)

Postscript: Ubuntu versus Obama

I’d say, any reasonable SysAdmin should default to /etc/crontab because every other reasonable SysAdmin already knows where it is. If anything is used in addition to /etc/crontab, leave a note in /etc/crontab advising the new guy who just got paged at 3:45am where else to look for crons.

For production systems, I strongly object to the use of per-user crontabs. I’m glad to hear I’m not alone. One thing I have to do in a new environment tends to be to write a script that will sniff out all the cron entries.

And then there was the shop that used /etc/crontab, user crons, and fcron to keep crons from running over each other. This frustrated me enough that I did a poor job of explaining that job concurrency could easily be ensured by executing a command through (something like) the lockf utility, instead of adding a new layer of system complexity.

Yes, I am a cranky old SysAdmin.

Today, I am patching–a few weeks too late–a FreeBSD system to reflect recent legislative changes to Daylight Saving Time. The procedure is very simple, and covered in FreeBSD Security Advisory FreeBSD-EN-07:04.zoneinfo. It starts:

a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility.

# fetch http://security.FreeBSD.org/patches/EN-07:04/zoneinfo.patch
# fetch http://security.FreeBSD.org/patches/EN-07:04/zoneinfo.patch.asc

Alas, here is a quick-and-dirty crib sheet for the “verify the detached PGP signature using your PGP utility” part:

If you don’t already have GPG installed, install it right quick: pkg_add -r gnupg

First, generate a key for yourself: gpg --gen-key
(Accept the reasonable defaults, and give it a decent passphrase.)

Next, visit The PGP Keys appendix to the FreeBSD Handbook and copy the key data for the Security Officer Team into your text buffer. (The stuff from pub 1024D/CA6CDFB2 to -----END PGP PUBLIC KEY BLOCK-----) Invoke gpg --import and paste the key data into your terminal. Press control-D.

Alternatively, you could just suck in all the FreeBSD PGP keys, but that can take a little while:
fetch http://www.freebsd.org/doc/pgpkeyring.txt && gpg --import pgpkeyking.txt

Now, sign the Security Officer Team key with your own key. This means that you trust that the FreeBSD Security Officer Team is who you think it is, and not someone who has compromised the FreeBSD web site. This is the dirtiest part of not being a PGP expert, in which case you might have someone in your key ring who could vouch for the FreeBSD Security Officer Team on your behalf. Anyway: gpg --sign-key security-officer@FreeBSD.org

Now, you’re all set up to verify the zoneinfo signature, and other FreeBSD security patch signatures in the future:

> gpg --verify zoneinfo.patch.asc zoneinfo.patch
gpg: WARNING: using insecure memory!
gpg: please see http://www.gnupg.org/faq.html for more information
gpg: Signature made Wed Feb 28 10:36:32 2007 PST using DSA key ID CA6CDFB2
gpg: Good signature from "FreeBSD Security Officer <security-officer@FreeBSD.org>"

Yay! Don’t forget to learn more about PGP . . . until you do, the drill goes:

gpg --gen-key (Only need to do this once …)
gpg --import
gpg --sign-key
gpg --verify (All you’ll need to remember once you’re set up.)

cd /usr/src/share/zoneinfo && make clean && make install

Though, you may have a valid reason for not doing all that. You could instead do this:

~> ls /usr/share/zoneinfo/America/Indiana
Indianapolis    Knox            Marengo         Vevay
~> fetch ftp://elsie.nci.nih.gov/pub/tzdata2006b.tar.gz
Receiving tzdata2006b.tar.gz (149555 bytes): 100%
149555 bytes transferred in 2.6 seconds (55.68 kBps)
~> tar xfz tzdata2006b.tar.gz
~> sudo zic northamerica
~> ls /usr/share/zoneinfo/America/Indiana
Indianapolis    Marengo         Vevay
Knox            Petersburg      Vincennes

A tip-of-the-hat to William Computer Blog and participants on the FreeBSD-questions mailing list.

On FreeBSD:

0-17:16 djh@web3 ~> find /var/db/pkg -name +CONTENTS | xargs grep -l pdftex
/var/db/pkg/teTeX-1.0.7_1/+CONTENTS

Ugly, eh? Which, I think the portinstall stuff has a pkgwhich command.

Linux?

[root@novadb0 pdftex-1.30.5]# rpm -qf /usr/bin/pdftex
tetex-2.0.2-22.EL4.4

Schweet!

I recently learned a painful lesson from Fedora: not all unices are as protective of the root user. Sure, I knew that in Linux any local user can run su, but OpenSSH isn’t going to allow people to log in as root, right? Wrong!

I had a test box from ASA that shipped with FC3. I made it accessible over the Internet. I added a user for myself, gave him sudo access, and removed the vendor-supplied non-root user. By default, Fedora Core has a firewall that denies inbound SSH access. I took that as evidence that Fedora was operating on the principle of least privilege, and reconfigured the firewall to allow inbound SSH, and let the machine be. A week later I logged in, and kept getting out of memory errors. Before long, I figured out that the box was owned by hackers, and shut it down.

In discussing the event with colleagues, I learned that Fedora defaults to allowing root to log in via SSH. And root’s password had been left, by me, to the default vendor password, which is well-known. This seems bass ackwards to me — by default you firewall off SSH, but you allow root to login? Okay, harsh lesson. Fedora is stupid. And I am stupid for not always setting a hard root password.

But it turns out, Fedora isn’t inventing the stupidity, the stupidity apperently ships with OpenSSH. Let us RTFM:

FreeBSD

     PermitRootLogin
             Specifies whether root can login using ssh(1).  The argument must
             be "yes", "without-password", "forced-commands-only" or
             "no".  The default is "no".  Note that if
             ChallengeResponseAuthentication is "yes", the root user may be
             allowed in with its password even if PermitRootLogin is set to
             "without-password".

Fedora

     PermitRootLogin
             Specifies whether root can log in using ssh(1).  The argument
             must be "yes", "without-password", "forced-commands-only", or
             "no".  The default is "yes".

OpenSSH

http://www.openssh.com/manual.html links to http://www.openbsd.org/cgi-bin/man.cgi?query=sshd_config:

     PermitRootLogin
             Specifies whether root can log in using ssh(1).  The argument
             must be "yes", "without-password", "forced-commands-only"
             or "no".  The default is "yes".

Best Practices

• Always set the root password to something hard. Sure, this will make it harder for you to hop on the console, but it beats getting hacked. If you have a valid local user and sudo is available, you can usually derive your console from that.
• Store your root password in an extremely secure location. Your head is a great default, but this has limited, faulty memory, that is not easily shared with your other admins. A GPG-encrypted file works well . . .
• Always audit a new system before putting it on the Internet. Especially if this is your first time with the OS. I was lazy because this was a non-production system, but doing an audit would have been a lot more convenient than cleaning this mess.
• Verify your assumptions. If you think that root should not be allowed to log in via SSH, then test and make sure that this is the case. Ditto with failover procedures . . . arrange to test them before you assume that you can complete a failover at 3AM.

So, that is a good checkpoint for my morning’s work. Time to eat . . .

I just saw this solution posted to FreeBSD-questions:

1) Go to the URL: about:config
2) Search for: browser.shell.checkDefaultBrowser
3) Right-click on that monkey and toggle it to false.
4) Restart your web browser a few times and smile.

Thanks, “nawcom” !!

Cheers,
-danny


# Two quick helper functions: CtoF and FtoC
sub CtoF { my $c = shift; $c =~ s/[^\d\.]//g; return (9/5)*($c+32); }
sub FtoC { my $f = shift; $f =~ s/[^\d\.]//g; return (5/9)*($f-32); }


The regex is to untaint the input datum, and could be eliminated if you know that your variable is clean. This code has been incorporated into a systems health and data trend monitoring script for FreeBSD. For the vaguely interested, here’s today’s perldoc:

check_temp($result, $command, $red, $yellow)
        Requires $results -- hashref to %results array.
        Requires $command -- unix command that prints a text representation
                             of system temperature in degree Celsius.
        Optional $red -- threshhold temperature for red alert in degrees
                         Fahrenheit.  (Default: 100)
        Optional $yellow -- threshhold temperature for yellow alert in
                            degrees Fahrenheit.  (Default: 90)

        Will populate:
                temp.C
                temp.F

        Note that input is expected in Celsius, but thresholds are
        calibrated in Fahrenheit.  This is because I am an American, and
        because I personally feel that Fahrenheit is a more inuitive
        temperature metric for humans.

        I have found that the following may work for $command:

                /sbin/sysctl -n hw.acpi.thermal.tz0.temperature
                /usr/local/bin/mbmon -T 1 -c 1

        As there is no consistent, reliable way to measure temperature, and
        because mbmon can cause your system to crash, and because different
        systems have different temperature tolerances, this check must be
        configured explicitly in lilsis.conf.

As you can guess, mbmon can be had from ports. And yes, while I love the metric system, I prefer Fahrenheit because its 0-100 metric is roughly calibrated from “colder than it gets in Denmark” to “the temperature of human blood” which is easier for my monkey brain to grasp than the freezing and boiling points of water.

A: If you are writing a C program, check kvm_getswapinfo(3) and maybe take a gander at the bottom of /usr/src/usr.bin/top/machine.c.

A: If you are writing a Perl script:

Measure swap activity:
sysctl vm.stats.vm.v_swapin vm.stats.vm.v_swapout vm.stats.vm.v_swappgsin vm.stats.vm.v_swappgsout
(I believe these results are COUNTER type values, like you get from netstat -inb. You could establish “swap activity” by plotting changes in this value.)

Measure swap size:

0-13:38 djh@mito ~> swapinfo
Device          1K-blocks     Used    Avail Capacity
/dev/ad0s1b       1022224        0  1022224     0%
0-13:38 djh@mito ~> swapctl -l
Device:       1024-blocks     Used:
/dev/ad0s1b     1022224         0

If you are trying to accomodate n+1 swap devices, try this:

0-13:44 djh@mito ~> swapctl -lsk
Device:       1024-blocks      Used:
/dev/ad0s1b      1022224          0
Total:           1022224          0

I have rigged up a simple system to schedule rips of programs broadcast on the KQED audio stream in to easily manageable .mp3 files. If I had one of them iPod thingies I could even listen to the radio programs on the bus. I might even get around to warezing this to interested friends via BitTorrent and CSS, which would leave us another technical explanation.

Ingredients used:

• FreeBSD running on an old laptop, for automatic, hands-free operation.
• mplayer, to rip the Windows Media stream off KQED’s web site.
• lame, to convert the audio in to mp3.
• Two shell scripts, cron, and at, to automate everything.

Where is the Audio Stream?

Mplayer is mighty and awesome, but unfortunately, you can not just click on a web page and feed it to mplayer. (Well, maybe you can and I am just dumb.) So, the first task is to find something for mplayer to chew on. In my case, this means going to http://www.kqed.org/ and clicking on the “Listen” link and selecting Windows Media and copying the URL to listen manually. You can then fetch that URL and examine the contents, and find a URL that starts with mms://. If you can play this URL in mplayer, then you are doing well.

I would share an example, but this part of KQED’s web site is throwing errors at the moment.

Ripping

I set up a simple script that launches lame and mplayer, then sits and waits for a specified time, and kills these programs off. Crude, but effective.

Scheduling

Ah, the potentially trickier part comes with scheduling. I thought this over for a couple days, and figured that a slightly clever shell script should do the trick. I wrote a script called “today” which defines a few functions, such as everday() and weekday() and runs through what the schedule should be, depending on the day of the week. It then schedules rips of the appropriate programs via at at command. You could also do a comparison with the date command to schedule special one-off recordings.

Anyway, the today script is run out of cron at midnight:

0-21:33 djh@yomama ~> crontab -l
0 0 * * * $HOME/bin/today

One other trick, on FreeBSD you have to give yourself permission to use at:

0-21:35 djh@yomama ~> cat /var/at/at.allow
djh

Making it Better

Do check out the comments that follow for tips and tricks, especially Shawn Dowler who has gone and wrote a page about his revised versions of the scripts.

mplayer mms://wmbcast.kqed.speedera.net/wmbcast.kqed/wmbcast_kqed_jan032006_0957_103495

UPDATE: I just discovered the -playlist feature. So, this works even better:

mplayer -playlist http://www.kqed.org/w/streamingfiles/kqed_wmp.asx

I have also figured out how to convert the Windows Media Player stream in to mp3 files, and may set up a system to “record” programs on a regular schedule, at which point I can listen to public radio as I would watch TV on a DVR. (Radio TiVo!)

If anyone might be interested in getting in on a non-RealAudio “NPR audio archive” via a bittorrent setup, I’d love to hear from you.

Even nicer, you can dial out on Skype, for exceedingly low rates. It costs us about 3c a minute to call Japan, though we’re going to get Noriko-san on Skype soon enough, and then the calls will be free.

If anyone wants to try it out, you can ring me at dannymanTM.

To answer a question you may have on your mind, Skype is not a telephone, so it is different from a VOIP service, where they send you a telephone that you hook up to your broadband. Instead, Skype is a way of making telephone calls from your computer. Unfortunately, people can not yet dial in to someone using Skype.

For me, though, it is as if the Internet has come full-circle: we used to have to find a cheap local number to dial in to the Internet on our existing telephone. Now, we are finding cheap services to make telephone calls on our existing Internet connection. Yow!