On 02/03/15 18:28, Martin Kosek wrote:
On 03/02/2015 06:12 PM, Martin Basti wrote:
On 02/03/15 15:43, Rob Crittenden wrote:
Martin Basti wrote:
...
But you haven't explained any case why LDAPI would fail. If LDAPI fails
then you've got more serious problems that I'm not sure binding as DM is
going to solve.

The only case where DM would be handy IMHO is either some worst case
scenario upgrade where 389-ds is up but not binding to LDAPI or if you
want to allow running LDAP updates as non-root.
I don't know cases when LDAPI would failed, except the case LDAPI is
misconfigured by user, or disabled by user.
Wasn't LDAPI needed for the DM password less upgrade so that upgrader could
simply bind as root with EXTERNAL auth?
We can do upgrade in both way, using LDAPI or using DM password, preferred is LDAPI. Question is, what is the use case for using DM password instead of LDAPI during upgrade.

It is not big effort to keep both DM binding and LDAPI in code.  A user can
always found som unexpected use case for LDAP update with DM password.

On ipactl, would it be overkill if there is a tty to prompt the user to
upgrade? In a non-container world it might be surprising to have an
upgrade happen esp since upgrades take a while.
In non-container enviroment, we can still use upgrade during RPM
transaction.

So you suggest  not to do update automaticaly, just write Error the IPA
upgrade is required?
People do all sorts of strange things. Installing the packages with
--no-script isn't in the range of impossible. A prompt, and I'm not
saying it's a great idea, is 2 lines of code.

I guess it just makes me nervous.
So lets summarize this:
* DO upgrade if possible during RPM transaction
Umm, I thought we want to get rid of running upgrade during RPM transaction. It
is extremely difficult to debug upgrade stuck during RPM transaction, it also
makes RPM upgrade run longer than needed. It also makes admins nervous when
their rpm upgrade is suddenly waiting right before the end. I even see the
fingers slowly reaching to CTRL+C combo... (You can see the consequences)
People are used to have IPA upgraded and ready after RPM upgrade.
They may be shocked if IPA services will be in shutdown state after RPM transaction.

I have no more objections.


* ipactl will NOT run upgrade, just print Error: 'please upgrade ....'
* User has to run ipa-server-upgrade manually

Does I understand it correctly?
With --skip-version-check what sorts of problems can we foresee? I
assume a big warning will be added to at least the man page, if not
the cli?
For this big warning everywhere.
The main problem is try to run older IPA with newer data. In containers
the problem is to run different platform specific versions which differ
in functionality/bugfixes etc..
Ok, pretty much the things I was thinking as well. A scary warning
definitely seems warranted.

Where does platform come from? I'm wondering how Debian will handle this.
platform is derived from ipaplatform file which is used with the
particular build. Debian should have own platform file.
Ok, I'd add that detail to the design.

rob



--
Martin Basti

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to