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

[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.

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() )

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?

Greetings,

Stefan Winter

> 
> 
>     > I retried to upload the SVG logo in order to check if that was the
>     > problem, but just got uploaded with no further issue. After that, a
>     > spanish NREN administrator reportedly changed the institution name and
>     > somehow, geolocation (but not the correct one) and some other
>     attributes
>     > were back.
>     >
>     > Should I configure again the institution? Is it possible to
>     restore the
>     > configuration?
> 
>     So, during that first attempt, the inst names got lost (you can BTW
>     re-set them yourself, you do not need federation operator assistance for
>     that)
> 
> 
> He just did that on his own. I wanted to leave the inst as it became for
> you to witness.
>  
> 
> 
>     Could you send me a copy of the SVG in private mail?
> 
> 
> It is not a secret logo :)
> https://cat.eduroam.org/user/cat_back.php?action=sendLogo&id=28
>  
> 
> 
>     I will have to find a way to reproduce this; which sounds difficult as
>     you write a second attempt worked as expected?
> 
>     This is a strange incident...
> 
> 
> Indeed. I didn't have much hope about this bug being resolved soon so I
> did setup the inst again for our users' sake.
> 
> -- 
> 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


-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66

Attachment: 0x8A39DC66.asc
Description: application/pgp-keys

Attachment: signature.asc
Description: OpenPGP digital signature