Adding 24 hour clock to FreeBSD’s hardstatus string for GNU Screen

FreeBSD gives the user an option of installing the file /usr/local/etc/screenrc with some sensible defaults along with GNU Screen, aka sysutils/screen.

Among the defaults are a format string for the hardstatus line. It shows the date using yy/dd/mm notation and the time as a 12 hour clock. That may be fine in the English speaking parts of the world.

hardstatus string '%{gk}[%{G}%H%{g}][%= %{wk}%?%-Lw%?%{=b kR}(%{W}%n*%f %t%?(%u)%?%{=b kR})%{= kw}%?%+Lw%?%?%= %{g}]%{=b C}[%m/%d/%y %C %A]%{W}'

Continue reading Adding 24 hour clock to FreeBSD’s hardstatus string for GNU Screen

Strange spam

Return-Path: <Preston_Charlie30@blueleo.com>
Received: from 204-56-183-213.static.edis.at (204-56-183-213.static.edis.at [213.183.56.204] (may be forged))
    by [WITHHELD] with SMTP id t46IO57r032988
    for [WITHHELD]; Wed, 6 May 2015 20:24:06 +0200 (CEST)
    (envelope-from Preston_Charlie30@blueleo.com)
Date: Wed, 6 May 2015 20:24:05 +0200 (CEST)
From: Preston_Charlie30@blueleo.com
Message-ID: <6[10
To: undisclosed-recipients:;

Apart from what I withheld by choice, the above is all that appears in this spam. Notice the strange Message-ID on line 8. Spam programming gone wrong? Maybe they should have used Erlang.

Ascertaining installed ports for a specific architecture

When upgrading from one major version of FreeBSD to another, in my case from FreeBSD/amd64 stable/9 to FreeBSD/amd64 stable/10, it’s customary to upgrade the installed ports afterwards, beginning with ports-mgmt/pkg.

I forcefully upgraded all installed ports using portupgrade -afpv, but the upgrade of lang/ruby21 failed miserably.

I removed all traces of Ruby 2.1, i.e. ports-mgmt/portupgrade and databases/ruby-bdb, before manually compiling and installing lang/ruby21, databases/ruby-bdb, and ports-mgmt/portupgrade using the ports collection.

Now, I needed to know which remaining ports were still compiled for stable/9. The following snippet allowed me to gather the origins of such ports:

pkg query -a %o:%q | grep freebsd:9: | cut -d : -f 1

Now, I could feed that list to the newly installed portupgrade and upgrade the remaining ports:

portupgrade -fprv `pkg query -a %o:%q | grep freebsd:9: | cut -d : -f 1`

In the end, I should have removed lang/ruby21 completely after upgrading ports-mgmt/pkg, and reinstalled ports-mgmt/portupgrade manually using the ports collection. Only then is it safe to forcefully rebuild and reinstall all the other ports. Don’t forget to add devel/cvs if you used to rely on cvs in base, and adjust all references from /usr/bin/cvs to /usr/local/bin/cvs.

Cloning a ZFS dataset using only zfs snapshot, zfs send, and zfs receive

Creating new BE’s using snapshots and clones can get messy with dependencies all over the place. I had an epiphany the other day, why not create a snapshot on the current dataset, send that snapshot to a new dataset within the same zpool (or elsewhere), and subsequently destroy the (two!) snapshots?

Instant transfer of data, and no strings attached to either dataset once the snapshots have been removed. Continue reading Cloning a ZFS dataset using only zfs snapshot, zfs send, and zfs receive

Upgrading lang/php5 to lang/php56

The 20150220 entry in /usr/ports/UPDATING contains no instructions for upgrading lang/php5 to lang/php56, at least not for us compiling our own ports.

I learned the hard way using portupgrade what needs to be done. I have summarised my steps into the script below. Use the script as a guide, and if you do run my script, then you’re on your own. Continue reading Upgrading lang/php5 to lang/php56

Star Trek Online, Season 10, The Iconian War

A couple of postings ago, I complained a lot about the endless patch cycle when starting and quitting Star Trek Online over the last few weeks. With today’s release, Season 10, The Iconian War, all that hassle is gone, completely.

However, I’m still of the opinion that the continous pre- and post-patching of the game’s files prior to launching a new season is counterproductive and wastes precious user bandwith. Why not add an option to the STO Launcher giving the user the choice between staying ahead of future changes and patching only what’s necessary to play the current game? While you’re at it, why not add to the STO Launcher a brief description of what’s being patched, while it’s being patched, and why?

To much appreciation, the previous Sector Blocks are replaced with Quadrant Blocks. In other words, you can travel directly from Federation space to Klingon space or to Romulan space in one go. The quantum slipstream drive is quite handy. I noticed some new sectors has appeared in “the south” of the galaxy map.

If you’re into Star Trek and haven’t tried Star Trek Online, then you probably should.

Dell Latitude E7240 and Intel Dual Band Wireless-AC 7260

Intel Dual Band Wireless-AC 7260 fails to notify Windows 7 when the SSID changes. The result is that the wireless interface retains the previous and possibly invalid IP addresses and other settings. The latest driver, A11, only a few days old, isn’t helpful at all.

I usually avoid installing Intel’s own utility for managing wireless connections, as I feel this should be left in the capable hands of the operating system and the driver. Maybe I should think twice about that.

The current solution is to manually force Windows into releasing and renewing the IP addresses after switching to a different SSID.

@echo off

ipconfig /release
ipconfig /release6

ipconfig /renew
ipconfig /renew6

Running dns/bind910 within a chroot after r382109

dns/bind910 gained native chroot support in r382109. Those of us who used to store the BIND files in /var/named/etc/namedb and ran BIND with /var/named as the chroot environment, must do five things:

  1. Rename the /var/named directory to something else, like /var/Named. This is to avoid upsetting make -C /usr/src delete-old and still retain the meaning of the directory’s name.
  2. Rename the /var/Named/etc/namedb directory to /var/Named/usr/local/etc/namedb.
  3. Edit /var/Named/usr/local/etc/namedb/named.conf to reflect that the BIND files now resides in /usr/local/etc/namedb, as seen from within the chroot environment.
  4. Change the appropriate line in /etc/rc.conf to read named_chrootdir="/var/Named".
  5. Restart BIND using /usr/local/etc/rc.d/named restart, or start BIND using /usr/local/etc/rc.d/named start if the former fails.

Yet another technical oriented blog, more or less