Atempo Time Navigator 4.2 Archive Media Selection Tunable

Just a quick post here to share a non-obvious tunable for Atempo’s Time Navigator 4.2 regarding archiving and media selection.

Before upgrading from 4.1 to 4.2 Time Navigator’s media selection for archive jobs with standalone drives behaved as expected: If existing partly filled and open cartridges in the associated media pool existed, Time Navigator would request those media be placed in the drives upon the start a new archive operation, effectively only asking for new, unlabeled media to be inserted once the existing media was full.

However, with the upgrade to 4.2 we found that Time Navigator was no longer requesting the existing, partly filled, open cartridges and was instead requesting new, unlabeled media to be inserted into the drives instead! The result of this new behavior was that Time Navigator would use new tapes for every new archive operation, no matter if existing, partly filled and open media was available in the media pool. Basically 4.2’s default behavior was preventing us from filling any archive media unless the particular archive job would happen to be larger than a single tape.

While I don’t know why the functionality changed, I do know what tunable to modify in order to make 4.2 behave like 4.1. The tunable is “check_external_cart_when_recycling“. Setting this tunable to “Yes” has restored the 4.1 behavior, allowing us to make full use of all archive media capacity by only requesting new media when all the existing media in the media pool has been filled.

I believe we only faced this problem because we use standalone archive tape drives that do not have an autoloader or robot nor an “inventory” of online tape. Each tape must be manually loaded. I suspect that if we had an autoloader for our tape drives, that 4.2 would have made the correct/expected selection of media.

I doubt that anyone else is going to face this problem but it took about 3 weeks with Atempo’s R&D department to figure out the problem so I figure if posting here can save anyone that amount of time, then I’ll have done my part!

Microsoft Campus Agreement Double Dipping

I’m not a lawyer nor a business analyst nor a licensing expert but I’m annoyed at Microsoft’s double dipping on Windows licenses under their Campus Agreements. Apparently, Windows and Windows only, under the Campus Agreement is an upgrade license and not a full (albeit leased) license like every other product falling under the Campus Agreement.

What this practically means is that for a PC to qualify for a Windows license under the Campus Agreement one must have purchased that PC with an OEM version of Windows installed. How is that not double dipping, Microsoft? Is it simply because you call the CA license an upgrade? Why not apply the same rules to Office or would that be too obvious of a rape for your customer base to handle? I also find it humorous that if you buy a Mac from Apple, apparently the upgrade clause doesn’t apply! I wonder why that is? Perhaps it’s because Microsoft would like keep Mac users dependent on their software by offering it under the CA without the big “gotcha” you’ve snuck in for other manufacturers PCs because it’s impossible without Apple selling OEM copies of Windows? Why wouldn’t Microsoft want to “convert” some Linux geeks with whitebox or custom built PCs back to their platform the same way as Mac users? Not a big enough install base to care?

Am I the only person that thinks this is double dipping? Am I missing something here?

POSIX Default ACLs, umask and Project Directories

I’ve recently come across a situation where the inherent design of POSIX ACLs has left me scratching my head for a solution to the problem of setting up a “project” or “group share” directory on Linux. The problem is as follows: We have several different projects or groups that desire a directory where any and every file created, copied or moved to said directory will become owned by a particular group and have group read/write permissions set automatically.

Most of the problem is solved through age-old UNIX techniques. For group ownership, all we need to do is setup the top-level directory to be owned by the “project” or “group share” group and setgid the directory:

$ mkdir project1
$ chown .projgroup project1
$ chmod g+s project1

This effectively forces every file created, moved or copied into the “project1” directory to be owned by group “projgroup”. So far, so good. The difficulties begin when we attempt to use default ACLs to enforce the permissions of any files created, moved or copied into the directory.

The POSIX ACL standard defines “default” ACLs which can be applied to a directory, which are in turn inherited by newly created/copied/moved child files and directories. While the default ACLs are inherited properly, the ACL mask when applied to files copied into the group share directory WITHOUT previous group write set prevents the files from being group writable!

$ getfacl project1
# file: project1
# owner: root
# group: projgroup
user::rwx
group::rwx
other::r--
default:user::rw-
default:group::rw-
default:group:projgroup:rw-
default:mask::rwx
default:other::r--

So far so good, right?

$ ls -alh test
-rw-r--r--  1 user1 user 0 Apr 23 15:10 test
$ cp test project1
$ ls -alh project1/test
-rw-r--r--+ 1 user1 projgroup 0 Apr 23 15:10 project1/test

What the… ?!?! No group write? Noooooo!

$ getfacl project1
# file: project1/test
# owner: user1
# group: projgroup
user::rw-
group::rw-			#effective:r--
group:projgroup:rw-		#effective:r--
mask::r--
other::r--

And so we have the great POSIX ACL mask problem, which is by design in fact. Still looking for a complete solution that doesn’t involve global trying to force a specific umask on every account… It would be nice if I could ensure that every file had group write set before it was copied into the group share directory but alas, I cannot. Telling users to manually check and change permissions is also a pain. Cron jobs to change group write recursively is also ugly. Please, someone provide me with the solution.