On 03/03/15 16:10, Martin Kosek wrote:
On 03/03/2015 04:04 PM, Rob Crittenden wrote:
Martin Basti wrote:
On 03/03/15 15:33, Martin Kosek wrote:
On 03/03/2015 03:16 PM, Simo Sorce wrote:
On Mon, 2015-03-02 at 18:54 +0100, Martin Basti wrote:
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
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
during upgrade.
There is no use case for using the DM password.
+1, so we will only use LDAPI and ditch DM password options and
querying that
we now have with ipa-ldap-updater?

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

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

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
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
This is true, stopping IPA and requiring manual intervention is not ok.
What is the plan then? Keep upgrades done during RPM transaction? Note
that RPM
transaction was already stuck several times because IPA, or rather DS,

We also need to address https://fedorahosted.org/freeipa/ticket/3849. The
original plan was to do the upgrade during ipactl start, this would
fix this
ticket. Alternatively, should we remove the upgrade from RPM scriptlet
and only
call asynchronous "systemctl restart ipa.service" that would trigger the
upgrade in separate process and log results in ipa.service?

The plan is do upgrade during RPM transaction if possible. If not then
ipactl start, will show warning for user to do manual upgrade (Rob
wanted it in this way, not doing auto upgrade by ipactl)
Only if there is a tty which means no asking during package update,
which I thought was the idea. I just think it is rather unexpected to
update a package during a restart.

So the fedup case is: RPM upgrade failed, ipactl start will detect
version mismatch, show error and prompt user to run ipa-server-upgrade
I'm beginning to have my own doubts about version, recognizing that
there isn't exactly another obvious solution. Running the updates every
time ipactl is run isn't great. The updates are not fast by any stretch,
29s on one VM, and we need to log whenever an update is done. My
ipaupgrade log is 48M from 20 updates. How many times does one run
ipactl restart when diagnosing a problem?

My biggest concern with version is who keeps count and where? This is
particularly problematic in packaged servers where changes are made
without rebasing (Fedora and RHEL). Somewhere the version would need to
be bumped with each release? Or only when updates are added? Or only
when someone remembers? It just seems fragile and prone to human error
unless you have some automatic version incrementor that takes this into

If fallible version or slow updates are the only option then I'd have to
go with slow updates if only to avoid a lot of support issues. And I
really hate the idea of updates during service restart.

Storing the version is something we just have to do, we need it for missing
upgrade detection in FedUp case. We also need for container use case, to make
sure that we can check whether we have the right version of bits (container
image) and data (mounted volume in a container) - to avoid running woth old
bits (and support issues).

I see the version generated during RPM/DEB build, maybe even the version we
already fill to VENDOR_VERSION? Then no manual version bump is needed when a
new downstream patch is added.
Yes I plan to use VENDOR_VERSION.


Martin Basti

Freeipa-devel mailing list

Reply via email to