sawyl | Entries tagged with voodoo

In honour of Halloween, we're breaking out the chicken feet, drawing a pentagram on the floor and invoking the obscure powers necessary to upgrade Super-UX. Let's hope it all goes to plan.

Updated: Everthing went more or less to plan although, under the assumption we were starting at 8am, we accidentally chopped things an hour earlier than scheduled instead of waiting for everything to stoprun. Oops. Then, when the system came back up there were a few minor, irritating problems because the rat's nests of symbolic links weren't quite right, but once that was sorted, everything basically just worked.

One of our applications, a vast, Frankensteinian beast, needs to be able to fail from one physical location to another. It achieves this via a set of symlinks which allow it to indirectly address its discs:

  /app/op -> /h1/op

or in the case of a fail over:

  /app/op -> /h2/op

where /h1 and /h2 are different file systems on different discs in different locations. So far, so simple. But the application needs to be upgraded from time to time and this means that a shadow copy must be run in parallel to the operational version, tracking it in real time. That means that it too needs it's own set of links:

  /app/par -> /h2/par

But, how to upgrade from shadow to operational without copying everything from one location to another? Why not use four file systems, two per physical location, and switch the links round on upgrade day? But what are we going to call the links and file systems? How about:

  /app/op   -> /h1/op
  /app/op2  -> /h2/op
  /app/par  -> /h2/opA
  /app/par2 -> /h1/opA

So, the first link points the operational copy, the second to the operational backup, the third to the shadow copy and the fourth to the shadow backup. Easy. But what happens when the software is upgraded?

  /app/op   -> /h1/opA
  /app/op2  -> /h2/opA
  /app/par  -> /h2/op
  /app/pars -> /h1/op

Well, I suppose that sort of makes sense, but what happens if a fail over event occurs? Well, the links go to:

  /app/op   -> /h2/op
  /app/op2  -> /h1/op
  /app/par  -> /h2/opA
  /app/par2 -> /h1/opA

or:

  /app/op   -> /h2/opA
  /app/op2  -> /h1/opA
  /app/par  -> /h2/op
  /app/par2 -> /h1/op

depending on the upgrade situation. Which means that in some situations, the op2 link is pointing to location 2, but sometimes it's pointing to location 1, whereas the par2 link is always pointing to location 1.

Confused? I was. Totally. So I dug my heels in and demanded that the names be of op2 and par2 be changed to op_backup and par_backup to preserve my sanity. And guess what? I won my case and the names were changed. Hurrah for me!

Everytime we fiddle with Super-UX, we end up breaking wtmp in some way or other. The problem at its simplest boils down to the following:

During shutdown, a record is written to wtmp on the partition /var/sx/adm indicating that the run level has changed to 6 — reboot level.
During the first part of the book, the system mounts /, /usr and /var. It does not mount /var/sx/adm.
The boot scripts write a record to wtmp, this time on the /var partition, indicating that the system is in multiuser mode.
The /var/sx/adm partition, along with its wtmp claiming that the system is at about to reboot, is mounted on top of the wtmp with the multiuser record.
The rest of the boot scripts check the run level, decide that the system is about to shutdown, and crap out.

There are a couple of ways to work around the problem. The simplest way is not to use a separate partition for /var/sx/adm.

The second way is silvershooter's R12.2 special: delete symbolic links from /etc/wtmp to /var/sx/adm/wtmp, move the real file to /etc and create some symbolic links from the adm directory (both on /var and /var/sx/adm) pointing to the real version in /etc.

The third method involves adding an entry to the undocumented, but nonetheless extremely potent, /etc/checkfile. This lists any additional file systems that need to be mounted along with / etc as early as possible in the boot sequence. If /var/sx/adm is listed here, it gets mounted before the boot scripts attempt to write out the run level records, which ensures that wtmp correctly describes the current run level of the system.

As I said, we seem to get caught by this every time we attempt to upgrade. How do I know this? Well, last time we upgraded — October 2005, for the curious — I added checkfile to our set of local mods. Somewhat embarrassingly, I then failed to add it to the configuration files, so it wasn't actually copied out with the rest of our localisations. Oops.

Current Music: Grieg - Solveigs Sang

Despite promising to tell me everything I ever needed to know about the weather, today's Guardian still didn't explain Gaussian grid resolutions — something I've been vague on for years. Thus, when people talk knowledgeably to me about N540 or whatever, I just nod and smile and try to hide the fact that I don't even have the first clue how any of it maps to real world resolutions.

Current Music: JS Bach - Prelude and Fugue BWV 853

In order to maximise the impact of my minty fresh Spider Jerusalem effigy, I am attempting to use Feng Shui to locate my bitter angry cynical bastard corner. So far, my efforts have been rather less than successful.

Current Music: The PM Programme

S	M	T	W	T	F	S
			1	2	3	4
5	6	7	8	9	10	11
12	13	14	15	16	17	18
19	20	21	22	23	24	25
26	27	28	29	30	31

Tales of a Fourth Grade Nothing

Entries tagged with voodoo

Halloween Upgrade

A maze of twisty symbolic links

Problems with wtmp and Super-UX

All weather explained

Maximising the cynicism

Profile

August 2018

Syndicate

Most Popular Tags

Page Summary

Style Credit

Expand Cut Tags