I’m in the process (this is the first step) of writing up a white paper on this, so this is very much the DIY version. I make no guarantees: don’t be stupid. Take a catalog backup before you start on any of this, don’t permit any backups to run until you’re sure the system is functional again (bppllist -allpolicies | awk [details elided, as I'm not on an active NBU system at the moment] to note the active policies, then deactivate them all before you start), so forth.

This is tested, through some serious trial and error, in the migration of a 6.0MP7 environment, running on Windows 2003sp2 ia32, to a replacement master server, on Windows 2003sp2 x64, subsequently upgraded to 6.5.6. This is a process, not a magical bullet script that you can go run. Do not even dream of doing this if you don’t understand what all the commands listed here do without my explanation.

I’m also going to go ahead and just post a transcription of my notes, which I do intend to come back and wrap words around later (since I plan to write this up, at least for internal consumption at my employer), but at least this’ll be something if it takes me a while to come back to it.

• dump to files bppllist for all policies, bpstulist for all STUs, nbstl for all SLPs, so forth on the old master before you start; it’ll make rebuilding shorter (and you will need to rebuild; policies go across, but STUs will need to be rebuilt, and if you do the wrong thing at the wrong time, you’ll cause a policy to forget what STU / SLP it used to use)
• fresh 6.0MP7 on new master (nbmaster) and migration media server (nbmedia4)
• add nbmedia4 to old env
• configure DSU
• catalog backup to DSU
• nbemmcmd -deletehost -machinetype media -machinename nbmedia4
• remove nbmedia4 from SERVERs
• shut down svcs on nbmedia4
• add new master and swap in as master in BAR
• regedit to remove old master and replace new master in EMMSERVER
  • HKLM\SOFTWARE\VERITAS\NetBackup\CurrentVersion\Config
• start svcs on nbmedia4
• add nbmedia4 as a media server on nbmaster
• add DSU STU for nbmedia4 on nbmaster referencing same directory
• copy catalog BU file across to nbmaster (either straight from netbackup/db/images/<old master>/<date spec>/… or because you had the common sense to configure the DR tab in the catalog backup policy config)
• run the catalog backup recovery wizard (GUI or bprecover -wizard), referencing that file
• push nbmaster as a server to all media servers and clients through the old master while that’s running
• after catalog restore completes, on each media server:
  • stop svcs (netbackup stop / bpdown -f -v)
  • swap nbmaster in as the master and EMMSERVER (either bp.conf or regedit; remember to double-check vm.conf, regardless of OS, for stray references to the old master)
  • start svcs (netbackup start / bpup -f -v)
• at this point, master will start, but be inconsistent
  • nbemmcmd -listhosts will show all media servers
  • nbemmcmd -getemmserver will only show nbmaster and nbmedia4 as being “in domain”
• preferably, upgrade nbmaster to 6.5.3 or later here (or the second substep in the next step is way more time-intensive/scripted)
• for each media server, running commands on nbmaster:
  • bpmedialist -mlist -l -h <media server>
  • bpmedia -movedb -allvolumes -newserver nbmaster -oldserver <media server>
    • (-allvolumes is a 6.5.x addition; you can just loop around the output from the bpmedialist, and you’ll have to do that to put the media DB entries back on the media server where they came from, but…)
  • nbemmcmd -deletehost -machinetype media -machinename <media server>
  • nbemmcmd -addhost -machinetype media -masterserver nbmaster -netbackupversion 6 [or 6.5, or whatever; untested below 6.0MP5] -operatingsystem <whatever> -machinename <media server>
• at this point, the media servers should be back, but their devices won’t show up and their STUs, while still present, won’t work (and if you start poking at them, you’ll break them entirely)
• redo device config (through the GUI wizard or through tpconfig, whatever grabs ya)
• bpstulist at this point should claim that there are no STUs configured, but the GUI should still show them (because it’s picking them up from the policy config, but it doesn’t know what goes in them)
• for each STU configured on the old master:
  • bpstudel
  • bpstuadd (with the appropriate config)
• go back and loop bpmedia -movedb around your output from bpmedialist to put the various media DB entries back to referencing the media servers that created them, rather than nbmaster
• TEST!!! with new policies
• activate your old polices, strategically testing as you go
• if you run into 23/24/25 errors, then you’ve got your new master in a different DNS zone than your old one, or DNS was broken on some of your old media servers and clients, and you either weren’t noticing or had forgotten /etc/hosts entries you’d made… this is an excellent time to atone for that sin, for which proper use of bpclntcmd -pn is your friend

This update adds several new print product options to iPhoto ’09:

• Hardcover books can now be ordered in a new extra-large (13ʺx10ʺ) size
• Includes three new book themes with travel-oriented designs: Tropical, Asian, Old World
• A variety of new holiday greeting cards themes are now available

The update is recommended for all users of iPhoto ’09.

Really guys? You’re pushing a software update that will store extra binary data (161 MBs!) on my computer for a feature I will personally never use that includes content that you could have delivered by way of HTTP request within the app (especially given that it’s not possible to use those ordering features without an Internet connection to complete the purchase). Are you really sure you want to do that?

Just look:

% ping -c 5 google.com
PING google.com (74.125.67.100): 56 data bytes
64 bytes from 74.125.67.100: icmp_seq=0 ttl=55 time=1218.912 ms
64 bytes from 74.125.67.100: icmp_seq=3 ttl=55 time=731.904 ms
64 bytes from 74.125.67.100: icmp_seq=4 ttl=55 time=968.861 ms

— google.com ping statistics —
5 packets transmitted, 3 packets received, 40% packet loss
round-trip min/avg/max/stddev = 731.904/973.226/1218.912/198.844 ms

(See also.)

Btw, I wouldn’t mind doing a speed comparison if one of you out there picks up a 3G S. Given that the 3G is only barely noticeably faster than the original in most real world use cases, I’m rather dubious of this “faster than ever” claim they’re making. There’s a limited number of things one can do with the handset to change that: the network’s throughput is much more important.

Now I come back to the basic problem: “Present images in an easily viewable way with as little hassle as possible to the viewer”, and I find that, actually, JWZ’s gallery.pl is exactly the right thing, a fact I was pretty sure was true at the time but remained, then, obstinate about dicking around with PHP a bit. Jamie’s script is simple, clear, conscious of the fact that storing binary blobs in a database on top of a file system (that is, itself, a database) is stupid, and, for bonus points, it FUCKING WORKS.

It took me sixty minutes with gallery.pl to satisfy its shell-out requirements (hint: pnmscale lives in the netpbm package), customize it to my style preferences, run it across a few recent directories full of images, and make this post. I spent a plurality of the time folding laundry while FreeBSD ports took care of rebuilding and reinstalling ImageMagick, maybe 30% of it in Wordpress’s post editor (writing this), and maybe 15% of it in vi(1) making a few localization changes. That’s a testament to JWZ’s well-honed and beautiful coding style and to his creating a simple tool that just does one thing and does it well, a concept so grossly lacking in Gallery.

Yeah, sure, it’ll take a couple more steps to upload images directly from the iPhone, and I still need to hack in a two-stage resize (down from camera size to sensible web size), but the former was a hack on top of You anyway and you actually suck at the latter. It’d probably have taken me longer to get this working under Gallery than it’ll take me to write an iPhone-friendly photo uploading app in PHP that automatically reruns gallery.pl and add an extra stage of djpeg | pnmscale | cjpeg by an order of magnitude I’d prefer not to consider.

And, regardless of any of those real issues, who could possibly resist using a chunk of code that includes:

use bytes;    # Larry can take Unicode and stick it up his ass sideways

So long, don’t let the door hit your ass on the way out, and good riddance.

PS, an example of Shit Just Working.

1. This is irritating, get out of my way.
2. Actually, I like this because it was, previously, a glaring security hole.
3. Oh, it’s still a glaring security hole exploitable by anybody clever enough to keep an old version of iTunes about and it gets in my way now.

That’s about as far as my thought process on this goes and I’ve concluded the whole thing is both silly and irritating. Maybe I’ve missed something?

<Dave> noc - rebooting [REDACTED]
<Phil_R_> ok thank you
<KBU> 10-4 good buddy
<Phil> Tac0Danz05
<jon> we got ourselves a convoy
<gr> Nice password, Phil.
<Phil> thanks…it used to be nice and secure.
<gr> At least yours are longer than jon’s.
<Dave> so… many… comments…
<gr> Down boy.

(Previously.)

When there are fewer than 10 icons on my desktop, I probably do not want your “assistance” to tidy up, no matter how long it’s been since I saw fit to open (for example) that phonetic alphabet PDF. It really won’t be necessary for you to keep asking EVERY FUCKING ASS WEEK.

Thanks!

Recently, my employer has gone forward with a hardware refresh of our backup infrastructure. The portions of this hardware refresh that were more or less up for grabs were the tape library that held LTO-4 drives and how we would do encryption key management for those drives. The tape library considerations were the HP MSL series (4048s already in the building, 8096s required for this usage), Sun StorageTek SL500s, or SpectraLogic T120s (or, at the outside T200s, but that’s overkill for this environment). I won’t go into which we selected or why here, because that’s not the point (feel free to drop me a line if you’re curious, but my take is: any of these options is acceptably serviceable, so it comes down to what fits best in your environment and cost from your relevant VAR). Each of these options locks one into that vendor’s key management (unless you choose to do it in your backup software, but I have a reason not to do so that is spelled VMS), which is an irritation that will be addressed at a later date.

My confessed discomfort should be painfully more clear by the dawdling length of the introduction. The point here is that one of those vendor’s sales representative (not the VAR, I take care to note) broached the borders of acceptable behavior on his part to an inexcusable extent: he got angry, at me, via email, for politely informing him that I planned to choose another vendor’s product. And he clicked “send” (or, probably, hit Alt-S; whatever). He should be ashamed, and I expect that he is, at this point, given that I intimated to the VAR salesperson that, regardless of whatever decision we’d already made, that would have sunk the sale.

I’d asked the VAR the same question that I asked the other two: is it feasible for us to buy your schlock and switch our backups to it, but stick an LTO-4 into our existing STK L180 library, duplicate from 9940 to LTO-4 media there, with encryption, and expect to be able to read those tapes for recovery. The answer, in all cases, was, “No, that shit don’t work because none of the vendors want to play nice with each other on key management.” This VAR slightly misunderstood the question (or was misinformed), so I wrote:

[REDACTED], your answer to number 1 is actually “No” [His answer had been a qualified "Yes", but the qualifications meant it wasn't useful for me]. That is, I can’t use [REDACTED]’s product in order to write an encrypted tape outside of a [REDACTED] library (which I could then read, later, inside a [REDACTED] library).

Thanks for the responses!

I wasn’t more irritated by this than by other VAR/vendor responses to the same question: you just can’t do that with the current state of affairs unless you do all of the key management yourself, and I’m uninterested in writing and supporting (potentially past my current employment) software to do that, so my thanks were genuine.

But he Cc’ed his sales rep from the vendor, and that’s where things got messy with just one email. He (the vendor now, not that VAR) wrote:

Please tell me a secure solution that can and we will point out more then one issue to dispute that claim. We have always talked about process not just glitzy marketing claims.

Now, that’s just unprofessional, without regard to context (of which a minute detail: he addressed me, outside of the quoted material, by my given name’s nickname without ever having been encouraged to do so; my co-workers call me that, but I never said he could and I sign emails with my full name… at least he spelled it correctly), but for bonus points it’s both technically and factually incorrect.

First, technically: I can write (it’s a three weekend hack; bet me three cases of Bols Genever and I’ll prove it, but check the price on that first, because it approaches half my hourly for the same work, and I’d be releasing it under either a CC or BSD license with my name on it) a secure solution to manage keys for LTO-4 tape drives across various disparate libraries and even backup products, restricting the latter to POSIX-(mostly-)compliant operating systems. (Making it also work for our VMS systems would require some consultation with the relevantly skilled parties at my employer and another weekend or two. And another case of Genever at the bare minimum, because I’ll be fucked if I’m writing code for OpenVMS for my goddamn health.)

Second, factually: this particular vendor’s presentation is nothing but “glitzy marketing”. I have, on my desk at work, no fewer than three spiral-bound, high-gloss, heavy-stock brochures about their products, in three different form factors, only two of which even pertain to tape libraries. This is, in fact, the second time (across disparate employers) I’ve been pitched by them, and they remain the most gut-wrenchingly, plasticly cheerful saleslime I’ve ever had the misfortune to encounter.

Curiously, that wasn’t the tape library I chose to buy. Twice now. They should consider just a dab of tact, I think.