...@redhat.com:
Changed subject.
Rob CCed
On 07/11/14 09:52, Martin Basti wrote:
Forward message back to list
Original Message
Subject:Re: [Freeipa-users] dns stops working after upgrade
Date: Thu, 6 Nov 2014 21:42:55 +0100
From
any errors in /var/log/ipaupgrade.log ?
2014-11-07 10:25 GMT+01:00 Martin Basti mba...@redhat.com:
Changed subject.
Rob CCed
On 07/11/14 09:52, Martin Basti wrote:
Forward message back to list
Original Message Subject: Re: [Freeipa-users] dns
stops working after
GMT+01:00 Martin Basti mba...@redhat.com
mailto:mba...@redhat.com:
Changed subject.
Rob CCed
On 07/11/14 09:52, Martin Basti wrote:
Forward message back to list
Original Message
Subject:Re: [Freeipa-users] dns stops
Subject: Re: [Freeipa-users] dns
stops working after upgrade Date: Thu, 6 Nov 2014 21:42:55 +0100 From:
Rob Verduijn rob.verdu...@gmail.com rob.verdu...@gmail.com To: Martin
Basti mba...@redhat.com mba...@redhat.com
Hi again,
I tried the update to 4.1.1
It didn't went well
.
Rob CCed
On 07/11/14 09:52, Martin Basti wrote:
Forward message back to list
Original Message
Subject:Re: [Freeipa-users] dns stops working after upgrade
Date: Thu, 6 Nov 2014 21:42:55 +0100
On 11/05/2014 05:22 PM, Rob Verduijn wrote:
I saw in the upstream foreman-prepare-realm script that the new
permission names should include a prefix System:
That Prefix is not there, what did change was that some permissions
where no longer lower case only.
ie in 3.3.5 the permission is 'write
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
Petr Spacek wrote:
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
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
Hello,
Rob V., you did not answered to my question when DNS worked for you last time.
Did it work right after reverting the snapshot?
Petr^2 Spacek
On 5.11.2014 16:09, Rob Verduijn wrote:
Hello again,
I don't know about foreman upstream, the current version that I am using
included in the
Hello,
I use only a single freeipa server (so no replica to bother)
Internal zones worked before the update
After the update, internal zones no longer worked.
After reverting back the snapshot the internal zones worked again, no
additional actions were needed.
Rob
2014-11-05 16:11 GMT+01:00
On Wed, Nov 05, 2014 at 09:41:59AM -0500, Rob Crittenden wrote:
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'
Stephen Benjamin wrote:
On Wed, Nov 05, 2014 at 09:41:59AM -0500, Rob Crittenden wrote:
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
Hello,
Yes I noticed the name change it took me a while to realise it was a known
ruby bug in katello that caused the real problem.
I also checked after I updated the 'katello integrated' update from 3.3.5
to 4.1 and the permissions were neatly renamed to their new counterparts.
However the
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.
On 5.11.2014 16:20, Rob Verduijn wrote:
Hello,
Yes I noticed the name change it took me a while to realise it was a known
ruby bug in katello that caused the real problem.
I also checked after I updated the 'katello integrated' update from 3.3.5
to 4.1 and the permissions were neatly renamed
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
Hello,
can you send content of these entries (I need mainly member and memberof
attributes)?:
DN: cn=DNS Servers,cn=privileges,cn=pbac,dc=example,dc=com
DN:
krbprincipalname=DNS/example@example.com,cn=services,cn=accounts,dc=example,dc=com
DN: cn=System: Read DNS
On Wed, Nov 05, 2014 at 10:20:36AM -0500, Rob Crittenden wrote:
Stephen Benjamin wrote:
On Wed, Nov 05, 2014 at 09:41:59AM -0500, Rob Crittenden wrote:
Also when I look at the permissions in ipa there are no longer any
permissions that have the 'System: ' prefix.
AFAIK the foreman proxy
I saw in the upstream foreman-prepare-realm script that the new permission
names should include a prefix System:
That Prefix is not there, what did change was that some permissions where
no longer lower case only.
ie in 3.3.5 the permission is 'write dns configuration' and in 4.1 it
becomes
Can you send me DNS related ACI in dc=tjako,dc=thuis
On 05/11/14 17:08, Rob Verduijn wrote:
and here is the 4.1 version
Rob
cat output-4.1.txt
# extended LDIF
#
# LDAPv3
# base cn=DNS Servers,cn=privileges,cn=pbac,dc=tjako,dc=thuis with
scope subtree
# filter: (objectclass=*)
# requesting:
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
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
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
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:
On 28/10/14 16:10, Rob Verduijn wrote:
Hello
Hello,
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 :(
Rob
2014-10-29 13:28 GMT+01:00 Petr Spacek pspa...@redhat.com:
On 28.10.2014 18:42, Rob Verduijn wrote:
before the update its 4.5-1.fc20.x86_64.rpm from
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
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
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
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
On 29/10/14 16:13, Martin Basti wrote:
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
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
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
Hello again,
I jumped to early.
# ipa-ldap-updater /usr/share/ipa/updates/55-pbacmemberof.update didn't work
but ipa-ldap-updater
fixes the problem for me.
Rob
2014-10-29 16:55 GMT+01:00 Martin Basti mba...@redhat.com:
On 29/10/14 16:46, Rob Verduijn wrote:
Hello,
# ipa-ldap-updater
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
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
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
Rob Verduijn wrote:
Ok after some more digging :
I found some warnings (see below)
Is any of these the cause for the error ?
Rob
snip
snip
snip
2014-10-27T13:56:28Z INFO Updating existing entry:
cn=ipaConfig,cn=etc,dc=X,dc=X
snip
2014-10-27T13:56:28Z WARNING remove:
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:
On 28/10/14 16:10, Rob Verduijn wrote:
Hello all,
I've been digging into my problem
Ok after some more digging :
I found some warnings (see below)
Is any of these the cause for the error ?
Rob
snip
2014-10-27T13:56:13Z INFO Updating existing entry: cn=sudoers,cn=Schema
Compatibility,cn=plugins,cn=config
snip
2014-10-27T13:56:13Z WARNING remove:
Hello,
I'm rather at a loss here.
Everything seems to be running
ipactl status
Directory Service: RUNNING
krb5kdc Service: RUNNING
kadmin Service: RUNNING
named Service: RUNNING
ipa_memcached Service: RUNNING
httpd Service: RUNNING
pki-tomcatd Service: RUNNING
ipa-otpd Service: RUNNING
sorry for the xml formatting didn't realize it would mess up some mail
clients
The last bit of the message again
ipa-upgradeconfig gives the following :
[Verifying that root certificate is published]
Failed to backup CS.cfg: no magic attribute 'dogtag'
[Migrate CRL publish directory]
CRL tree
Hello Rob,
Did systemd report any failed services? (systemctl --failed)
-- john
2014-10-25 16:40 GMT+02:00 Rob Verduijn rob.verdu...@gmail.com:
Hello all,
I'm running freeipa 3.3.0 on fedora 20 x86_65 and it is set up as my main
dns server.
I've tried the upgrade to 4.1 using the copr
h
after some more digging (monitoring the upgrade more closely.)
I saw that the upgrade kept waiting for the ca to start, which it did not
do.
and after 5 minutes the upgrade gave up with the following errors in the
ipaupgrade log :
at 85% it says :
2014-10-26T15:04:35Z DEBUG retrieving
Rob Verduijn wrote:
h
after some more digging (monitoring the upgrade more closely.)
I saw that the upgrade kept waiting for the ca to start, which it did
not do.
and after 5 minutes the upgrade gave up with the following errors in the
ipaupgrade log :
at 85% it says :
Hello all,
I'm running freeipa 3.3.0 on fedora 20 x86_65 and it is set up as my main
dns server.
I've tried the upgrade to 4.1 using the copr repositorie.
I performed the following steps:
1 apply latest fedora updates
2 shutdown system
3 create a snapshot from the freeipa vm as a backup (which
46 matches
Mail list logo
