shape of the beast

...well, not quite. ...yet.

to wit: 13 sequences. 13. yum. anyway, out of 13 sequences, 4 were on the fedex-ed hard disk. there was nothing else accompanying the hard disk, though there was a bunch of other stuff that we were expecting.

- 0 -

backtrack: today, we discovered that osx server has by default very rigorous security settings. settings that prevent our render management system from writing its important log files (useful for performance monitoring) -- hence, stopping any possibilities of rendering with the new server cold.

- 0 -

yesterday (thursday), it was finally cleared up why the linux render boxes could not mount the new server's shared resources -- instead of server:/storage/data, that osx server's path for the raid was server:/Volumes/data. and this was not known to me when the server was first activated for use the day before. anyway, that wrinkle was resolved by editing the appropriate entries in the linux render boxes' fstab files ("filesystem table", i'd guess).

at this time, with the new server's shared resources online, the question became: where's the old server? luckily, the troubleshooter extraordinaire was in the NOC when i decided to look. short discussion, and the agreement was that since the primary server was named after the capital planet of the star wars' old republic, it would make some sort of sense (though this was not, strictly speaking, really necessary) to name the old server, however temporarily, by another planet name in the star wars pantheon. hmm. nothing else came to mind but the planet that was blowed up good by the first death star in the first star wars film.

the rest of the day was spent (up to 8:30pm, actually -- long since going-home-time) tranferring, oh, maybe, 238GB of files from the old linux server box to the new osx server box. to its credit, the osx box does seem faster than the linux box -- but transferring is a two-way street. even if the osx box can handily run rings around the linux box in terms of hard disk performance and system throughput, the linux box itself is the limiting factor in how fast it can send data over the network.

- 0 -

day before yesterday (wednesday): prez walks in bright and early and inquires about new server. i have no clue. this is not received well. duh. i do some network trolling, and there it is: new server, old name; new workgroup. i wish they would inform me of these things after they had made the decisions so i'm not totally in the dark when the prez decides to ask me how things are going.

so, new server up, none of the proper shares. call up future prez, who says call up troubleshooter; so i bug the PM. after a long while, troubleshooter comes around, discuss, discuss; and share names agreed on. it doesn't take long before server is up with proper resource sharing.

all right! check the linux boxes to see if they mounted...

...did not. by this time, the magic hour has rolled around. so, next day, then.

- 0 -

tuesday.

the shape of the beast... ...is a standard 3.5 inch hdd. in that nice bubble wrap that some people like to pop. wonder how much of the project is on it? time will tell. considering that it took until the end of that day to finally hand it over to the troubleshooter for transfer to the as yet unknown new server.

- 0 -

back to the present.

not fun at all. first thing in the morning, attempt to submit a render through the render management software. there's an error i've never seen before. frenzied email later, troubleshooter arrives, early afternoon. we discuss the matter as best we can (i emailed the programmer of the software, and he had a deceptively simple suggestion) -- and we set out to try to attack the problem from as many angles as possible.

magic hour: no dice on my end. osx is weird enough for me, osx server is of another order of strangeness totally.

update 10:30pm. seems that the troubleshooter called it quits by 8:30 with no solutions in sight.

what's that standard quote from star wars? ah, yes. i have a bad feeling about this...