The mailing list for users of the eduroam Configuration Assistant Tool (CAT)

[Alberto Martínez <alberto_martinez AT deusto.es>]

Hi Stefan.

2013/11/11 Stefan Winter <stefan.winter AT restena.lu>

Hi,

>     - a logo
>     - profiles
>     - statistics
>     - CA certs
>
>     and all of that continued to exist after your attempt to upload the SVG?
>
>
>     So, what was *deleted* really?
>
>
> Yes. Maybe "wiped" is not the word. In my defense, I was still in shock :S
>
> What was missing:
> - Geolocalization
> - Help Desk settings
> - Server cert CN
> - Inst names
>
> Profiles were of no use since server CN name was missing.

Okay... things start to make sense now.

The update to your inst settings happens in several phases - and your
SVG seems to have crashed the PHP script in the middle of those.

In a first phase, all attributes which are based on simple strings are
deleted from the DB. The "meaty" attributes (everything file-based) are
only marked for deletion in case they didn't change (an efficiency
optimisation).

In stage 2, new file-based attributes are added.

Ins stage three, file handles which weren't re-submitted (i.e. were
slated for deletion with the "-" sign) actually get deleted from the DB.

In the last phase, all re-submitted string-based attributes get re-added
again.

The situation as you described it makes it rather clear that PHP crashed
during stage 2 - all string based attributes were already deleted, the
file-based ones (incl. old logo) were still there, but the *new*
file-based one didn't get in. Nor did the string-based ones in
re-submission.

Now it makes sense, yes.

 

I can only conclude that the image processing library failed so horribly
that our usual failsafes couldn't catch the error condition, and the PHP
script aborted.

There's really little we can do here - the function in question uses
ImageMagick, and executes the entire loading in a try/catch block - so
we usually detect bogus file data and just ignore the file if it fails
to load. ( if you are really curious, it's
web/admin/inc/common.inc.php:check_upload_sanity() )

I saw it. It's just a load() using the imagemagick wrapper in PHP. I have tried to reproduce the error using the commandline interface of imagemagick but works nicely. It just failed for some unknown reason.

 

Maybe the specific version if ImageMagick / PHP IMagick that we use on
the production box had an issue with the SVG? I can only speculate...
the SVG loaded just fine on first attempt on both my dev box and on the
cat-test.eduroam.org site.

I suggest we file this as "spooky one-time issue" with no real
resolution. Is that okay for you?

I'm fine with that. If this issue happens agains at least it will not be totally unheard of.

Thank you!

 

--

Alberto Martínez Setién
Servicio Informático
Universidad de Deusto
Avda. de las Universidades, 24
48007 - Bilbao (SPAIN)
Phone:  +34 - 94 413 90 00 Ext 2684
Fax:    +34 - 94 413 91 01