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

[Tomasz Wolniewicz <twoln AT umk.pl>]

Stefan manages the translations so I will leave this to him.

Tomasz Wolniewicz

UCI UMK

On 06 Nov 2015, at 17:20, Jørn Åne <jorn.dejong AT uninett.no> wrote:

I agree that we need translations. Is it possible to get access to the transifex-strings? I would like to use gettext (http://php.net/gettext) as not to add too many library dependencies.

6. nov. 2015 kl. 16.28 skrev Tomasz Wolniewicz <twoln AT umk.pl>:

And we must remember about translations. It would be best if we could maintain them in the same space as the main CAT and even better if we managed avoiding retranslated not of the same strings. Perhaps we could find space for GUIs in the main CAT tree? I was thinking of refactoring it so that we, could generate separate distributions for the from and that back end. The front end repository could have many GUIs or themes, this does sound like quite a piece of work though.

Tomasz

Tomasz Wolniewicz

UCI UMK

On 06 Nov 2015, at 16:15, Jørn Åne <jorn.dejong AT uninett.no> wrote:

Hi Stefan

I agree that a public version of a UI for CAT should have a complete feature set. I will do my best to use the CAT API to it’s full extent.

My idea is to make the repository private at first, so that it’s manageable who has access to the code.

Later on, when at least one of Stefan or Tomasz is convinced that the API is implemented correctly, I want to open the repository.

Maintaining of the code is always a hard problem. However, putting projects up on Github works out quite often, so i’m still optimistic, especially if many people are willing to start using it :-)

6. nov. 2015 kl. 14.18 skrev Stefan Winter <stefan.winter AT restena.lu>:

Hi,

Our intention was certainly not to offend anyone, CAT developers have done a great job!

I for one was never offended :-)

Just worried about feature loss...

We did choose to not display all information during download and installation as we did not see that it was needed. (This is such as Helpdesk info and whatever is added under Installer Fine-Tuning)

That's a bit the problem. The admin who uploaded the information
probably did so because they thought it *does* add value (or else he
wouldn't have bothered to upload it in the first place).

By redacting the info, you are effectively overriding that decision of
the admin.

Also, the web interface has the possibility to set redirects for
specific devices. An example where this is very useful:

For our own IdP, I let CAT serve all installers except MacOS and iOS;
those are redirected to our own support page because we deliver a larger
config file with VPN and E-Mail account settings all in one go.

This happens when I use the "normal" interface. At connect.uninett.no, I
get the mobileconfig file for just eduroam. Again, this is a redaction
which overrides the admin's (my!) decision.

Then there's various smaller things which are a little unpleasant; the
missed new support for ChromeOS is one thing, the lost differences
between iOS 5+6 / iOS 7+ / Mac OS are another (contrary to what was true
a few months ago, these are now NOT necessarily the same files - there
are differences both in supported EAP types and in other areas!).

That's why I'd appreciate a little control, or call it QA if you like,
on the developed front-ends.

In our opinion a model with CAT as the central repository for all profiles is best.
The web design and user interaction does not have to be centralised, just like every institution has its own helpdesk for eduroam problems.

We have registered a couple of requests to make our implementation available and our intention is a version of our «connect» page which uses CAT as a single source of truth.
First we want to adjust it so that one can limit which institutions are shown, NROs and institutions can then host their own, with their own (EV?) TLS-certificate and their own design.
This may improve the current situation in two ways:

- Convince IdPs that do not use CAT today to start using CAT (we have a few using locally stored profiles both CAT and others)
- Users get profiles from a familiar design, familiar hostname and (depending on IdP) familiar EV-certificate

All profile downloads will go through CAT, and CAT will collect statistics.


We are happy make such a “connect" code available on request through github, provided this is OK with the CAT developers.

I for one don't mind these developments. I'd suggest to create a
feature-complete version first though. I would not want to see people
grabbing an incomplete version, forking it, and then we have numerous
frontends out there, all with a number of deficiencies.

That's why my preferred way forward would be inclusion into CAT sources
with a theming framework around... a more structured approach, and
easier QA. But the decision is of course yours.

Speaking of which... if you do put it on GitHub, be prepared that people
start asking for stable versioning, updates, etc. Hopefully, you'll get
merge requests rather than people forking it.

Greetings,

Stefan Winter

Br,
Jørn de Jong and Tom Myren





-----Original Message-----
From: Tomasz Wolniewicz <twoln AT umk.pl>
Date: Friday 6 November 2015 at 10:35
To: Zenon Mousmoulas <zmousm AT noc.grnet.gr>
Cc: "cat-users AT geant.net" <cat-users AT geant.net>
Subject: Re: [cat-users] CAT website design

Hi

Tomasz Wolniewicz
UCI UMK

On 06 Nov 2015, at 10:07, Zenon Mousmoulas <zmousm AT noc.grnet.gr> wrote:

I think it's not unrealistic that an NRO or an institution may want to use/present CAT data without sending the user to the CAT web site, so this should be facilitated. On the other hand, considerable effort has gone into translating the CAT UI in many languages, and that should not go down the drain.

This is what we do at my university. We have our own instructions but for downloads we link directly to CAT installers via the API. We also tell the users that the installers are made by GEANT so no surprises about signature.
Tomasz

--
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
2, avenue de l'Université
L-4365 Esch-sur-Alzette

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
<0x8A39DC66.asc>