[Freeipa-users] dns stops working after upgrade

Wed Nov 5 15:27:19 UTC 2014

Great news about the script.
I will as soon as I get the upgrade to 4.1 to work with internal dns
support.

yup 12 default permissions + 3 custom permissions in the
smart-host-proxy-management privilege
I guessed I leave those 12 default permissions since I expect it might
break things when I remove those :P

Rob

2014-11-05 16:20 GMT+01:00 Stephen Benjamin <stephen at redhat.com>:

> On Wed, Nov 05, 2014 at 04:09:18PM +0100, Rob Verduijn wrote:
> > Hello again,
> >
> > I don't know about foreman upstream, the current version that I am using
> > included in the katello installation is 1.6
> > And the foreman manpage still requires the configuration of the
> > realm-smart-proxy.
> > http://www.theforeman.org/manuals/1.6/index.html#4.3.9Realm
> >
> > About the snapshot:
> > I removed all the katello entries from my current freeipa installation (
> I
> > peeked in the script to see what it did )
> >   - user (foreman-realm)
> >   - role (Smart Host Proxy Manager)
> >   - privilege (Smart Host Proxy Management)
> >   - 3 custom permissions ( modify host password, write host certificate,
> > modify host userclass )
> > applied the update to freeipa 4.1.
> > my local dns zones did not resolv again
> > running the ipa-ldap-updater did not fix it
>
> It's more like 12 permissions for that privilege, the complaints of
> missing permissions you saw is because they've changed names in FreeIPA
> 4, you can try this script instead:
>
> https://raw.githubusercontent.com/stbenjam/smart-proxy/8278/sbin/foreman-prepare-realm
>
>
> > So I guess that it is not due to the katello integration or the
> > realm-smart-proxy script.
> >
> > Rob
> >
> > 2014-11-05 14:39 GMT+01:00 Petr Spacek <pspacek at redhat.com>:
> >
> > > On 4.11.2014 17:15, Rob Verduijn wrote:
> > >
> > >> The problem with 'foreman-prepare-realm' and freeipa was that it
> claimed
> > >> that a few o thef permissions required did not exist when it tried to
> add
> > >> them to the 'smart proxy host management' privilege.
> > >>
> > >> I think it was because the permissions were all in lower case without
> the
> > >> 'System: ' prefix. This is just an assumption since I did not get to
> work
> > >> even after adding them manually. So I figured to try it again after
> > >> reverting back to 3.3.5.
> > >>
> > >> After downgrading I learned that it did not work due to a bug in a
> ruby
> > >> script. (fixed by commenting out line 505-506
> > >> in /usr/share/ruby/xmlrpc/client.rb on the katello host, see
> > >> https://bugs.ruby-lang.org/issues/8182 and
> > >> https://bugzilla.redhat.com/show_bug.cgi?id=1071187 )
> > >>
> > >> After which I tried the upgrade again.
> > >>
> > >> regarding
> > >> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart
> > >> I did look again using the kredentials as mentioned in step 4. and saw
> > >> only
> > >> 3 objects (1x idnsConfigObject 2x nsContainer)
> > >> When using admin credentials I saw all the dns zone entries.
> > >>
> > >> I can see the zone entries in the ipa gui.
> > >>
> > >> Also when I look at the permissions in ipa there are no longer any
> > >> permissions that have the 'System: ' prefix.
> > >>
> > >
> > > AFAIK the foreman proxy is not necessary (and not supported) with IPA
> 4.x
> > > because it was obsoleted by 'native' proxy delivered by Foreman
> upstream.
> > >
> > > Am I right, Rob (Crittenden)? :-)
> > >
> > > Anyway, back to your DNS problem. Did it worked before you installed
> > > Foreman proxy? Or not? I.e. is it working when you revert the snapshot?
> > >
> > > Do you have other replicas in the replication topology? Please keep in
> > > mind that changes in LDAP (including changes to permissions) are
> replicated
> > > so reverting one VM and not others is not necessarily enough.
> > >
> > > Petr^2 Spacek
> > >
> > >
> > >  2014-11-04 15:52 GMT+01:00 Petr Spacek <pspacek at redhat.com>:
> > >>
> > >>  On 4.11.2014 15:27, Rob Verduijn wrote:
> > >>>
> > >>>  Hello again,
> > >>>>
> > >>>> I've managed to integrate my katello configuration with freeipa.
> > >>>> Now I not only use freeipa authentication in katello but also when a
> > >>>> host
> > >>>> is defined in katello it automagically gets created in the freeipa
> > >>>> realm ,
> > >>>> certs, otp,dns all working great.
> > >>>>
> > >>>> however, to obtain all this integration greatness I had to
> downgrade my
> > >>>> freeipa to 3.3.5 again (revert snapshot) because the katello realm
> > >>>> integration tool (foreman-prepare-realm) is not capable of dealing
> with
> > >>>> 4.X
> > >>>> versions of freeipa.
> > >>>>
> > >>>>  It would be nice if you could get tell us more details about the
> > >>> problem
> > >>> you had with Katello, AFAIK we are not aware of any.
> > >>>
> > >>>   And now the named-pkcs11 again does not see my internal zones.
> > >>>
> > >>>>
> > >>>> This page
> > >>>>
> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart
> > >>>> thinks
> > >>>> I should contact the freeipa-users list
> > >>>>
> > >>>>
> > >>> Do I understand correctly that you did all the steps 0-4
> successfully and
> > >>> then you found out that you can't see DNS objects in LDAP (step 5)
> when
> > >>> using ldapsearch with DNS principal?
> > >>>
> > >>> Can you see the objects in IPA web UI or CLI? If it is the case then
> we
> > >>> will need help from LDAP ACI expert (pviktori? :-).
> > >>>
> > >>> Petr^2 Spacek
> > >>>
> > >>>
> > >>>   The command 'ipa-ldap-updater
> > >>>
> > >>>> /usr/share/ipa/updates/55-pbacmemberof.update' didn't fix it.
> > >>>> and the command 'ipa-ldap-updater' didn't fix it either.
> > >>>>
> > >>>> So I am now stuck at freeipa 3.3.5 again (with a working katello
> > >>>> integration, so I got some mixed emotions about it)
> > >>>> Any ideas anyone ?
> > >>>> Rob
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> 2014-10-29 22:14 GMT+01:00 Rob Verduijn <rob.verduijn at gmail.com>:
> > >>>>
> > >>>>   Hello,
> > >>>>
> > >>>>>
> > >>>>> I've tested the update again.
> > >>>>>
> > >>>>> The bind-utils conflict is still there when I issue "yum update
> > >>>>> freeipa-server" ( as indicated on the freeipa 4.1 download page
> > >>>>> http://www.freeipa.org/page/Downloads#Upgrading )
> > >>>>>
> > >>>>> 'yum update' works fine
> > >>>>>
> > >>>>> My internal zones didn't resolv after the update
> > >>>>> ipa-ldap-updater /usr/share/ipa/updates/55-pbacmemberof.update
> didn't
> > >>>>> fix
> > >>>>> it
> > >>>>> ipa-ldap-updater did fix the 'access control instructions' and my
> > >>>>> internal
> > >>>>> dns zones started to resolv again :-)
> > >>>>>
> > >>>>> Cheers
> > >>>>> Rob
> > >>>>>
> > >>>>>
> > >>>>> 2014-10-29 18:14 GMT+01:00 Petr Spacek <pspacek at redhat.com>:
> > >>>>>
> > >>>>>   On 29.10.2014 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.
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>  I have re-build some packages in mkosek's CORP so now you should
> > >>>>>> not see
> > >>>>>> encounter dependency problems. Simple 'yum upgrade' should give
> you
> > >>>>>> all
> > >>>>>> the
> > >>>>>> required packages.
> > >>>>>>
> > >>>>>> We are looking at other problems in upgrade process right now so
> there
> > >>>>>> is
> > >>>>>> not much to test except package dependencies.
> > >>>>>>
> > >>>>>
>
> > --
> > 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
>
>
> --
> Stephen Benjamin
>
> ______________________________________________________
> Red Hat GmbH | http://de.redhat.com/ | Sitz: Grasbrunn
> Handelsregister: Amtsgericht München, HRB 153243
> Geschäftsführer: Charles Cachera, Michael Cunningham,
> Michael O'Neill, Charles Peters
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141105/c3963bd7/attachment.htm>