2:49 p.m.
Simo Sorce wrote:
----- Original Message -----
> From: "Rob Crittenden" <rcritten(a)redhat.com>
> To: "Ipsilon" <ipsilon(a)lists.fedorahosted.org>
> Sent: Tuesday, May 5, 2015 2:13:48 PM
> Subject: Patches pending review
>
> Here is a list of the patches I have pending review:
>
> ticket 35:
>
https://fedorapeople.org/cgit/rcritten/public_git/ipsilon.git/.git/commit...
This one looks good but seem to need a rebase, cherry-pick barfs.
Rebased.
> ticket 90:
>
https://fedorapeople.org/cgit/rcritten/public_git/ipsilon.git/.git/log/?h...
I've had no time to look at this one yet.
> ticket 111:
>
https://fedorapeople.org/cgit/rcritten/public_git/ipsilon.git/.git/commit...
This is reaaaallly ugly, can we rather have a config option we look for and not enable
sssd
if this optoin is not set ?
This way you *can* enable/disable it via the admin UI, which is handy if you are testing
stuff as an admin, you just shouldn't be able to change the configuration. (mark the
module
cnfiguration with a "read-only" property somewhere ?
No argument there about the ugly. I was trying to avoid creating a whole
new mechanism to manage this one plugin, and I think I was looking at
enable/disable differently.
So I was looking at a much lower level, where disabling the plugin would
actually unconfigure it in sssd, apache, etc rather than just having the
info plugin not fire when a user authenticates. Configure is similar. If
the plugin was enabled at install time then one can turn it on/off but
if not, you're stuck.
The other complicating factor is that the same enable/disable code gets
called both by the UI and during startup, so some state information is
needed to know whether one can properly allow it or not.
I can see about setting a config option during install that would
indicate whether the underlying plumbing is configured or not and
perhaps base enable/disable requests on that. I'll take a look.
> ticket 116:
>
https://fedorapeople.org/cgit/rcritten/public_git/ipsilon.git/.git/commit...
I think we shouldn't really allow non-mutual auth, if that check is because
mod_auth_gssapi
fails to reutn the token on a 200 OK, then we just need to require a new enough
mod_auth_gssapi, Ifixed that bug in master a couple of weeks ago, and can make a release
if necessary.
Yeah, that'd be great. In the meantime I'll pull the upstream source and
do some local testing.
Otherwise it looks good, but haven't yet tested it.
> ticket 120:
>
https://fedorapeople.org/cgit/rcritten/public_git/ipsilon.git/.git/commit...
ACK and pushed this one to master.
thanks
rob