On 29/10/14 16:46, Rob Verduijn wrote:
Hello,

# ipa-ldap-updater /usr/share/ipa/updates/55-pbacmemberof.update
 fixes the problem.

I can resolv my internal dns zones again :-)

Many thanx.

Since this problem happened every time I tried to update the freeipa server. I could re-run the update with some debug options if you like so you can pinpoint what goes wrong with the update script if you like.

Rob

We know where the problem is, and we though we fixed it, but obviously some parts of problem persist.

Thank you for your patience :-)

2014-10-29 16:13 GMT+01:00 Martin Basti <mba...@redhat.com <mailto:mba...@redhat.com>>:

    On 29/10/14 15:56, Martin Basti wrote:
    On 29/10/14 15:46, Rob Verduijn wrote:
    You're right
    duh I should read more carefully and not try to do to many
    things at once.

    when using the dns principal and keytab the entries are not found.

    How do i fix the access controll instructions ?
    I can revert back easely and try a different aproach for the
    upgrade if you know one
    (I really started to appreciate snapshots with this upgrade :-)

    Rob

    Please try first this:

    # ipa-ldap-updater /usr/share/ipa/memberof-task.ldif

    It should repair privileges.
    Sorry I wrote you wrong file
    # ipa-ldap-updater /usr/share/ipa/updates/55-pbacmemberof.update


    2014-10-29 14:50 GMT+01:00 Petr Spacek <pspa...@redhat.com
    <mailto:pspa...@redhat.com>>:

        On 29.10.2014 14:32, Rob Verduijn wrote:

            I've checked and I see a lot of objects representing my
            dns entries.
            Still I get no answers if i try to resolve any of them :(


        Are you running ldapsearch with *exactly* same credentials
        as you have in /etc/named.conf?

        Could you post dynamic-db section from your named.conf?

        Petr^2 Spacek


            Rob

            2014-10-29 13:28 GMT+01:00 Petr Spacek
            <pspa...@redhat.com <mailto:pspa...@redhat.com>>:

                On 28.10.2014 18:42, Rob Verduijn wrote:

                    before the update its 4.5-1.fc20.x86_64.rpm from
                    fedora 20 updates repo
                    after the update its 6.0-5.fc20.x86_64.rpm from
                    copr repo

                    Regards
                    Rob


                    2014-10-28 17:58 GMT+01:00 Martin Basti
                    <mba...@redhat.com <mailto:mba...@redhat.com>>:

                        On 28/10/14 16:10, Rob Verduijn wrote:


                           Hello all,

                           I've been digging into my problem of
                        being unable to update from 3.3.5
                        to 4.1

                           First I add the repo from copr

                           Then  I used to update it by issueing
                        'yum update' which resulted in an
                        update in which my local dns zone entries no
                        longer resolved.

                           So i tried the instructions mentioned on
                        the site :
                        yum update freeipa-server
                        And this failed with a conflict in

                         bind-32:9.9.4-18.fc20.1.pkcs11.x86_64 and
                        bind-utils-32:9.9.4-15.P2.fc20.x86_64

                           I noticed the new bind comes from the
                        copr repo and the old bind utils
                        from fedora.

                           So I first run 'yum update bind-utils -y'
                        Then I ran yum update freeipa-server
                        and see it fail with errors about softhsm

                           I remembered reading about package errors
                        with softhsm and installed
                        the
                        softhsm-devel package first.

                           so revert back the freeipa kvm snapshot
                        to 3.3.5  and try again
                        yum update bind-utils -y ;  yum install
                        softhsm-devel -y ; yum update
                        freeipa-server -y

                           However when restarting named-pkcs11 I
                        can see in the system log that
                        it
                        has 0 zones loaded

                           Oct 28 15:28:30 freeipa.x.x
                        named-pkcs11[3029]: managed-keys-zone:
                        loaded serial 0
                        Oct 28 15:28:30 freeipa.x.x
                        named-pkcs11[3029]: zone 0.in-addr.arpa/IN:
                        loaded serial 0
                        Oct 28 15:28:30 freeipa.x.x
                        named-pkcs11[3029]: zone localhost/IN: loaded
                        serial 0
                        Oct 28 15:28:30 freeipa.x.x
                        named-pkcs11[3029]: zone
                        1.0.0.127.in-addr.arpa/IN: loaded serial 0
                        Oct 28 15:28:30 freeipa.x.x
                        named-pkcs11[3029]: zone
                        localhost.localdomain/IN: loaded serial 0
                        Oct 28 15:28:30 freeipa.x.x
                        named-pkcs11[3029]: zone
                        
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.
                        0.0.ip6.arpa/IN:
                        loaded serial 0
                        Oct 28 15:28:30 freeipa.x.x
                        named-pkcs11[3029]: all zones loaded
                        Oct 28 15:28:30 freeipa.x.x
                        named-pkcs11[3029]: running
                        Oct 28 15:28:30 freeipa.x.x
                        named-pkcs11[3029]: 0 zones from LDAP
                        instance
                        'ipa' loaded (0 zones defined, 0 inactive, 0
                        failed to load)

                           It claims 0 zones loaded but I can see my
                        forward and reverse zones in
                        ipa

                           what could cause it not to load the zones
                        that I defined in ipa ?


                This problem is usually caused by broken IPA upgrade
                which destroys ACIs
                in LDAP which allow access to DNS sub-tree.

                Please follow instructions on:

                
https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart#a5.
                NozonesfromLDAPareloaded

                ... and let us know if you are able to see idnsZone
                objects in LDAP or not.



-- Petr^2 Spacek






-- Martin Basti




-- Martin Basti




--
Martin Basti

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project

Reply via email to