>> Why make them fail?
> True, it isn't ideal but all users fail the first time in the browser
> as it is. There isn't a stable way to pre-configure the browser
> currently. It either involves directly modifying files in the firefox
> rpm which will both cause rpm verification issues and be lost when an
> upgrade is done. Or we have to run something on the client to fix
> their browser profile when we run ipa-client-install and this will
> only affect existing profiles (and won't take effect until any running
> browser is restarted).
This should be filed as an RFE with FF.
> There is a browser bug filed so one can configure a directory of
> additional settings to be read as sort of a global configuration
> cache. Once this is available we can write to one spot and
> pre-configure kerberos settings.
Can you point me to it?
> Similarly once the global NSS database is in place we can put the IPA
> CA cert there and be trusted by all browsers on the system.
>> I assume that things like cfengine or puppet can be used to already
>> precofigure browsers to know about IPA.
> Probably but again it's a client-side issue and the browser profile
> needs to be updated. Definitely a possibility.
>> So failing them and forcing them to use kinit manually sounds like a bad
>> user experience approach to me.
> Yup. But this is close to what happens with new users now. They kinit
> (or not), try to hit the UI and in FF 3.5 fail with a nasty error
> message about untrusted CA's. If they decide to continue they get a
> configure the browser. This little program causes a hair-on-fire
> warning to pop up. Then they need to restart the browser to work.
They need to accept the cert first time right? Ok I understand why.
Do we provide it or it is a part of something standard?
Why it causes hair-on-fire?
Engineering Manager IPA project,
Red Hat Inc.
Looking to carve out IT costs?
Freeipa-devel mailing list