Outage 25 november

November 25th, 2008

Datum : Dinsdag 25 november 06:15 uur tot 06:25
Tijdsduur : 0:10 uur
Lokatie : GrafiX NOC te Capelle
Van toepassing op : Alle Servers op deze lokatie

Hierbij het officiele antwoord van het GrafiX NOC datacenter:

Hedenochtend omstreeks 06:15u is een groot deel van de stad Capelle a/d IJssel getroffen door een stroomstoring. Hierdoor werd de stroom toevoer naar ons pand onderbroken en is de diesel generator automatisch gestart.

Omstreeks 08:15u heeft Eneco de stroomtoevoer naar het pand hersteld en is het koelvermogen weer naar netspanning overgezet. De apparatuur blijft voorlopig op de generator draaien.

Omdat de herstelde UPS installatie nog niet in gebruik genomen was, heeft alle apparatuur binnen het pand een powercycle ondervonden. Circa 30 seconde na de stroomuitval is de apparatuur opnieuw gestart en werd alles gevoedt via de generator.

Vanmiddag zal de UPS deels ingeschakeld worden zodat de batterijen op spanning gebracht kunnen worden. Vanavond, omstreeks 23:00u, zal de UPS volledig ingeschakeld worden en zal de apparatuur weer gevoedt gaan worden door het trafostation. Als het inschakelen van de UPS goed verloopt, zal er geen nieuwe powercycle ontstaan tijdens het omzetten van de spanning.

Outage 1 oktober

October 1st, 2008

Datum : Woensdag oktober van 13:00 uur tot 15:00
Tijdsduur : 1:50 uur
Lokatie : GrafiX NOC te Capelle
Van toepassing op : Alle Servers op deze lokatie

Zoals eerder gemeld was er vanmiddag een algehele stroomstoring in het GrafiX NOC datacenter te Capelle a/d IJssel. De storing betreft wederom (net als afgelopen zaterdag) de UPS icm met het bypass-paneel. GrafiX heeft daarom besloten aankomende nacht het bypass-paneel direct te vervangen. Dit heeft als gevolg dat uw server(s) de komende nacht wederom uit gaan. Exacte details van deze aktie wordt ons spoedig bekend gemaakt. Hopelijk is hierna deze storing permanent verholpen.

Bij deze vervanging zal een engineer (Sam Terburg) aanwezig zijn om de down en ups van de servers goed te begeleiden. Mocht uw server enige speciale aktie vereisen dan kunt u dit aan ons doorgeven.

Het is aan te bevelen tijdens een storing ons kantoornr te bellen en niet engineers van ons rechtstreeks. Engineers van ons zijn dan meestal met man en macht bezig uw server weer in de lucht te krijgen. Een telefoontje hierbij stoort dan. Personeel op kantoor kan u te woord staan en zijn op de hoogte van de stand van zaken. Als u speciale akties uitgevoerd wilt hebben op lokatie in het datacenter dan kunt u prima de betreffende engineer rechtstreeks bellen.

Met vriendelijke groeten,

Sam Terburg
REDUNIX – Internet Diensten

OS/X & Environment variables

September 19th, 2008

After a bit of a struggle with mysterious PATH entries not working under Eclipse, I decided to do some research into how and when environment variables get set under OS/X.

Under X Windows (Unix, Xorg or X11) the system runs your .xinitrc (or variant) which sources (includes) your .profile file. So putting environment variables in there ensures they’re available to programs not started through a shell also.

Under OS/X, you’ll also be able to use .profile file, but it won’t get read on login. It will only be used by shells, and so any settings in there will only be available to programs started from a Terminal (or iTerm) window. The .bashrc and .bash_profile files suffer from essentially the same problem (but worse, as they’ll only work for programs started from a bash-shell or descendant of a bash-shell).

As it turns out, OS/X does offer a way to set environment variables on a per-user-at-login-basis, by placing them in a property-list file (.plist) in a hidden ‘.MacOSX’ folder in your homedir. .plist files are to OS/X what .ini files are to windows. But .plist files are XML-based and can therefore contain richer structures. They can be both in a binary format and a plain-text-xml (you can use the plutil tool included with OS/X to convert between the two). Manually editing the .plist while in xml format works fine, but you can also use the ‘defaults’ utility.

To read the entire file, in either binary or xml format:

defaults read ~/.MacOSX/environment

To read a single entry:

defaults read ~/.MacOSX/environment PATH

To set a single entry: (will convert the plist to binary)

defaults write ~/.MacOSX/environment PATH yadayada

These changes will only take effect at login, as this is when OS/X parses this file. You can also you the preference pane RCEnvironment for manual editing.

Things to consider:

This file is only read when login in on the machine through the login window. So these settings won’t be available when logging in remotely over ssh. (You could sorta remedy this by having your .profile parse and export defaults’ output when it sees you’re logging in remotely.)

No parameter expansion takes place, so using PATH PATH$:/bla will bork your file.

AFAIK, there is no way to run a shell-script in the login-process itself to dynamically establish environment variables.

It may be possible to start a shell-script using loginitems, LaunchAgents or a LoginHook which modifies the ‘master’ environment, but it may also be impossible to do this. I have yet to research this.

I encountered all this when doing perl-stuff from within Eclipse (which never involved a shell) and noticing it wasn’t finding perl modules that could be found from a Terminal. Turns out the PERL5LIB variable that I was setting in my .profile was not available from within Eclipse (or whatever it ran).

I’ll post a trivial ‘persist-environment’ shell-script which takes the current value of an environment variable and defaults-write’s it. I’ll also post a snippet that parses and exports the .plist for remote logins.

Outage september 1st – 3rd

September 4th, 2008

As you’ve all noticed, we’ve had a major outage starting monday-morning and lasting until last evening. We had to replace the server, and we had to move everything to a new datacenter. Because of that, the old IP’s were no longer reachable, which were also used for the DNS’s themselves. We had to have those modified by SIDN, through a 3rd party. SIDN had a lot of difficulties with the required changes which caused the huge delay.

Some functionality may still be broken; please notify us of those so we can have a look at the issue.