Re: [Freeipa-devel] [PATCH] Password vault
Dne 16.6.2015 v 01:02 Endi Sukma Dewata napsal(a):
On 6/15/2015 2:22 AM, Jan Cholasta wrote:
I think it would be better to use a new attribute type which inherits
from ipaPublicKey (ipaVaultPublicKey?) rather than ipaPublicKey directly
for assymetric vault public keys, so that assymetric public key and
escrow public key are on the same level and you can still use
ipaPublicKey to refer to either one:
ipaPublicKey
ipaVaultPublicKey
ipaEscrowPublicKey
( 2.16.840.1.113730.3.8.18.2.? NAME 'ipaVaultPublicKey' DESC
'Assymetric vault public key as DER-encoded SubjectPublicKeyInfo (RFC
5280)' SUP ipaPublicKey EQUALITY octetStringMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.40 X-ORIGIN 'IPA v4.2' )
( 2.16.840.1.113730.3.8.18.2.3 NAME 'ipaEscrowPublicKey' DESC 'IPA
escrow public key as DER-encoded SubjectPublicKeyInfo (RFC 5280)' SUP
ipaPublicKey EQUALITY octetStringMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.40 X-ORIGIN 'IPA v4.2' )
OK. To be consistent the parameters need to be renamed too:
--vault-public-key and --vault-public-key-file.
It doesn't need to, there is no requirement for CLI names to always
match attribute names. (Also I don't insist on the name
"ipaVaultPublicKey", feel free to change it if you want.)
1. The vault_add was split into a client-side vault_add and server-side
vault_add_internal since the parameters are different (i.e. public
key file and
future escrow-related params). Since vault_add inherits from Local all
non-primary-key attributes have to be added explicitly.
The split is not really necessary, since the only difference is the
public_key_file option, which exists only because of the lack of proper
file support in the framework. This is a different situation from
vault_{archive,retrieve}, which has two different sets of options on
client and server side. Escrow adds only ipaescrowpublickey and
escrow_public_key_file, right? If yes, we can safely keep the command in
a single piece.
We know the vault-add will have at least two client-only parameters:
vault_public_key_file and escrow_public_key_file. Keeping these
parameters on the server API would be wrong and confusing. If the API is
called on the server side with vault_public_key_file the operation will
fail. In the previous discussion you considered this as broken API:
Server API is used not only by the server itself, but also by installers
for example. Anyway the point is that there *can't* be a broken API like
this, you should at least raise an error if the command is called from
server API, although actually separating it into client and server parts
would be preferable.
You are comparing apples and oranges:
a) When the non-split vault_{archive,retrieve} was called from a
server API with client-only options, it crashed. This is the broken API
I was talking about.
b) The non-split vault_{archive,retrieve} had server-only options,
which were also accepted on client, but setting them had no effect.
c) The CLI options to read param values from files should be generated
by the framework without having to specify dummy params. Once this is
implemented, the dummy params will go away. However, this will still
leave some client-only options in vault_{archive,retrieve}.
None of the above applies to vault_add - it does not have any
server-only options and the only client-only options it has are the
dummy options for file input, which are ignored on the server.
Also, originally the vault was designed like this: when you create a
symmetric vault you're supposed to specify the password as well, similar
to adding a public key when creating an asymmetric vault. When you
archive, you're supposed to enter the same password for verification,
not a new password. So it would look like this:
$ ipa vault-add test --type symmetric
New password:
Verify password:
$ ipa vault-archive test --in secret1.txt
Password: (same password)
$ ipa vault-archive test --in secret2.txt
Password: (same password)
In the original design the vault-add would also archive a blank data,
which later could be used to verify the password during vault-archive by
decrypting the existing data first. There's also a plan to add a
mechanism to change the password after the ACL patch.
In the current design the vault-add doesn't archive anything, so during
vault-archive it cannot verify the password because there is nothing to
decrypt. In other words you can specify different passwords on each
archival, regardless of previous archivals:
$ ipa vault-add test --type symmetric
$ ipa vault-archive test --in secret1.txt
New password:
Verify password:
$ ipa vault-archive test --in secret2.txt
New password:
Verify password:
So basically here are the options:
1. Specify the crypto parameters once during vault creation, then
reuse/verify the parameters on each archival & retrieval. You can change
the parameters only with a special command.
2. Don't
Re: [Freeipa-devel] FreeIPA 4.2 Alpha preparations
On 06/16/2015 05:29 PM, Fraser Tweedale wrote: On Tue, Jun 16, 2015 at 05:10:00PM +0200, Martin Kosek wrote: On 06/12/2015 11:34 AM, Martin Kosek wrote: Hello all, As discussed in the last 2 weeks, we are getting close to the 4.2 finish line and releasing FreeIPA 4.2 Alpha 1. We already have most of the major RFEs complete, some still miss some partial functionality, but most are testable and in Alpha state already. We need to now find out what is blocking us from releasing the Alpha. I know only about 2 issues: - ipa-replica-manage del does not work well with the Topology plugin yet - Petr Vobornik and Ludwig are working on it - ipa-replica-prepare had some issues after upgrade from 4.1.x to 4.2.0 due to inaccesible certificate profiles - Jan, Martin2, Fraser was investigating Is that correct? Feature owners, please let me know if any of the major feature regressed and is not working properly, maybe by other patch sets being merged. When the blockers are resolved or documented, we should release the beast. Any volunteer for the release process? Finally, I put together a release note draft for the Alpha, please help me completing and updating it: http://www.freeipa.org/page/Releases/4.2.0.alpha1 Thanks everyone! I saw many fixes in Topology, that's good. I heard that pki-core 10.2.4 broke us, but I could not reproduce it today with fully updated F22 machine and I was able to install FreeIPA 4.2.git If this is the case, can we just release the Alpha? There are still some big brokens for upgrades. The fixes for pki are merged but there is no release yet. What is the ETA? It would be nice to have the fix for Alpha, the package can be built in the freeipa-4.2 COPR repo, together with the 4.2 Alpha release. If the ETA is too far, we may need to release Alpha regardless as there are some Test Days planned next week and upgrade is not required for such test days. I am only aware of one reported issue for new installations: ipa-replica-prepare failing when run on a replica (I haven't gotten to investigating this one yet). Right. This must be fixed before GA, but Alpha can live without it IMO. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] update on freeipa 4.2 pki issues
On 06/16/2015 06:39 PM, Fraser Tweedale wrote: I fixed several issues which broke Dogtag upgrades involving particular versions; these will be in the next release. I haven't yet gotten to to the reported failure running ipa-replica-upgrade on a replica (but I haven't forgotten about it either.) This is the only issue affecting *fresh installs* that I am aware of. If you know of others please let me know! The remaining Dogtag-related upgrade problem is caused by new DS schema on the Dogtag side, which is used for LDAP-based profiles. There is not yet an automatic schema upgrade facility for Dogtag, so the new schema was missing. The planned approach is: - Either Dogtag or FreeIPA will add the new CS schema on upgrade. (Eventually Dogtag will need to manage its own schema updates but right now there is no facility, and the new schema is only used by IPA.) If possible, I would prefer Dogtag to update the schema the best it can, otherwise there is a risk of collisions or upgrade breakages if FreeIPA starts updating Dogtag internals. - Migrate file-based profiles into LDAP during IPA upgrade. But for this to work, I need to make sure that if new schema is added, then entries that use the new schema, replication to instances that did not yet have the new schema will not break. Anyone who knows LDAP better than me, please share your knowledge! Shouldn't schema just replicate, when the first FreeIPA+CS is upgraded? CCing Thierry for reference, he had a lot of fun with schema upgrades. - If my assumptions about replication are wrong, the best approach will probably be to have the administrator perform profile migration (via a script) as a later task, after all replicas have been upgraded. Not a fan of this, FreeIPA upgrades should be ideally automatic and straightforward. So far we did not have problems with automatic upgrades (well, except Dogtag9->Dogtag10 upgrade - I would prefer not to have such situation again). Thanks for updates! Martin -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] IPA Python API
Dne 16.6.2015 v 20:29 Drew Erny napsal(a): Hi, All, I'm using the IPA Python API to write the Community Portal. Most of the documentation for using the IPA Python API is targeted a plugin authors, and this isn't a plugin for (what I think are) good reasons. I'm doing # in the main program import api from ipalib api.bootstrap(context="client") api.finalize() api.Backend.rpcclient.connect() Call api.Backend.rpcclient.connect(ccache=krbV.default_context().default_ccache()) to make the problem go away. # and then, inside of a separate class api.Command.stageuser_add(...) Which is how doc/examples/python-api.py shows it. However, calling api.Command.stageuser_add(...) causes AttributeError: No context.rpcclient_... in thread 'Thread-1' I think this is probably related to the fact that I haven't configured my program to connect to any particular IPA server, because before the program errors out, it prints: ipa: INFO: Forwarding 'stageuser_add' to json server 'None' If the problem is the lack of a target server, as I suspect, how would I configure the program to connect to a particular IPA server? If this isn't caused by that, what could the causes be? -- Jan Cholasta -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] IPA Python API
On 06/16/2015 04:17 PM, Rob Crittenden wrote:
Drew Erny wrote:
On 06/16/2015 02:29 PM, Drew Erny wrote:
Hi, All,
I'm using the IPA Python API to write the Community Portal. Most of
the documentation for using the IPA Python API is targeted a plugin
authors, and this isn't a plugin for (what I think are) good reasons.
I'm doing
# in the main program
import api from ipalib
api.bootstrap(context="client")
api.finalize()
api.Backend.rpcclient.connect()
# and then, inside of a separate class
api.Command.stageuser_add(...)
Which is how doc/examples/python-api.py shows it.
However, calling api.Command.stageuser_add(...) causes
AttributeError: No context.rpcclient_... in thread 'Thread-1'
I think this is probably related to the fact that I haven't configured
my program to connect to any particular IPA server, because before the
program errors out, it prints:
ipa: INFO: Forwarding 'stageuser_add' to json server 'None'
If the problem is the lack of a target server, as I suspect, how would
I configure the program to connect to a particular IPA server? If this
isn't caused by that, what could the causes be?
I think this may be a bug. Even after doing ipa-client-install and
following exactly the guide outlined in this email
(https://www.redhat.com/archives/freeipa-users/2012-June/msg00334.html)
I still get the same error. I've poked around in the code around this,
though, and if it is a bug then I might need help because it's WAY deep
in the FreeIPA internals.
Also, forgot to mention, all of the ellipses (...) in the code in the
first email are elided code, not literal ellipses.
I wonder if it's detecting that you are in-tree so trying to use
~/.ipa/default.conf.
This code:
from ipalib import api
api.bootstrap(context="client")
api.finalize()
api.Backend.rpcclient.connect()
# and then, inside of a separate class
print api.Command.user_show(u'admin')
produces this:
$ python derny.py
ipa: INFO: trying https://ipadev.greyoak.com/ipa/session/json
ipa: INFO: Forwarding 'user_show' to json server
'https://ipadev.greyoak.com/ipa/session/json'
{u'result': {u'dn':
u'uid=admin,cn=users,cn=accounts,dc=greyoak,dc=com', u'has_keytab':
True, u'uid': (u'admin',), u'loginshell': (u'/bin/bash',),
u'uidnumber': (u'59000',), u'gidnumber': (u'59000',),
u'memberof_group': (u'admins', u'trust admins'), u'has_password':
True, u'sn': (u'Administrator',), u'homedirectory': (u'/home/admin',),
u'nsaccountlock': False}, u'value': u'admin', u'summary': None}
rob
I've sort of figured out the problem. I uninstalled the master-branch
rpms I had, and then installed the latest FreeIPA from the fedora repos.
Then, I was able to run the commands from the interpreter but the
program still threw the same error. However, after some knob-twiddling,
I've narrowed it down: running a Flask app with debug = True causes the
error, but removing the debug line makes the code work. This doesn't
explain why with the master build, the code throws errors in the python
interpreter for me, which means something else is probably afoot (and
probably our fault instead of Flask's), but I don't have any clue what
it is.
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] IPA Python API
Drew Erny wrote:
On 06/16/2015 02:29 PM, Drew Erny wrote:
Hi, All,
I'm using the IPA Python API to write the Community Portal. Most of
the documentation for using the IPA Python API is targeted a plugin
authors, and this isn't a plugin for (what I think are) good reasons.
I'm doing
# in the main program
import api from ipalib
api.bootstrap(context="client")
api.finalize()
api.Backend.rpcclient.connect()
# and then, inside of a separate class
api.Command.stageuser_add(...)
Which is how doc/examples/python-api.py shows it.
However, calling api.Command.stageuser_add(...) causes
AttributeError: No context.rpcclient_... in thread 'Thread-1'
I think this is probably related to the fact that I haven't configured
my program to connect to any particular IPA server, because before the
program errors out, it prints:
ipa: INFO: Forwarding 'stageuser_add' to json server 'None'
If the problem is the lack of a target server, as I suspect, how would
I configure the program to connect to a particular IPA server? If this
isn't caused by that, what could the causes be?
I think this may be a bug. Even after doing ipa-client-install and
following exactly the guide outlined in this email
(https://www.redhat.com/archives/freeipa-users/2012-June/msg00334.html)
I still get the same error. I've poked around in the code around this,
though, and if it is a bug then I might need help because it's WAY deep
in the FreeIPA internals.
Also, forgot to mention, all of the ellipses (...) in the code in the
first email are elided code, not literal ellipses.
I wonder if it's detecting that you are in-tree so trying to use
~/.ipa/default.conf.
This code:
from ipalib import api
api.bootstrap(context="client")
api.finalize()
api.Backend.rpcclient.connect()
# and then, inside of a separate class
print api.Command.user_show(u'admin')
produces this:
$ python derny.py
ipa: INFO: trying https://ipadev.greyoak.com/ipa/session/json
ipa: INFO: Forwarding 'user_show' to json server
'https://ipadev.greyoak.com/ipa/session/json'
{u'result': {u'dn': u'uid=admin,cn=users,cn=accounts,dc=greyoak,dc=com',
u'has_keytab': True, u'uid': (u'admin',), u'loginshell':
(u'/bin/bash',), u'uidnumber': (u'59000',), u'gidnumber':
(u'59000',), u'memberof_group': (u'admins', u'trust admins'),
u'has_password': True, u'sn': (u'Administrator',), u'homedirectory':
(u'/home/admin',), u'nsaccountlock': False}, u'value': u'admin',
u'summary': None}
rob
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] IPA Python API
On 06/16/2015 02:29 PM, Drew Erny wrote: Hi, All, I'm using the IPA Python API to write the Community Portal. Most of the documentation for using the IPA Python API is targeted a plugin authors, and this isn't a plugin for (what I think are) good reasons. I'm doing # in the main program import api from ipalib api.bootstrap(context="client") api.finalize() api.Backend.rpcclient.connect() # and then, inside of a separate class api.Command.stageuser_add(...) Which is how doc/examples/python-api.py shows it. However, calling api.Command.stageuser_add(...) causes AttributeError: No context.rpcclient_... in thread 'Thread-1' I think this is probably related to the fact that I haven't configured my program to connect to any particular IPA server, because before the program errors out, it prints: ipa: INFO: Forwarding 'stageuser_add' to json server 'None' If the problem is the lack of a target server, as I suspect, how would I configure the program to connect to a particular IPA server? If this isn't caused by that, what could the causes be? I think this may be a bug. Even after doing ipa-client-install and following exactly the guide outlined in this email (https://www.redhat.com/archives/freeipa-users/2012-June/msg00334.html) I still get the same error. I've poked around in the code around this, though, and if it is a bug then I might need help because it's WAY deep in the FreeIPA internals. Also, forgot to mention, all of the ellipses (...) in the code in the first email are elided code, not literal ellipses. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] IPA Python API
Hi, All, I'm using the IPA Python API to write the Community Portal. Most of the documentation for using the IPA Python API is targeted a plugin authors, and this isn't a plugin for (what I think are) good reasons. I'm doing # in the main program import api from ipalib api.bootstrap(context="client") api.finalize() api.Backend.rpcclient.connect() # and then, inside of a separate class api.Command.stageuser_add(...) Which is how doc/examples/python-api.py shows it. However, calling api.Command.stageuser_add(...) causes AttributeError: No context.rpcclient_... in thread 'Thread-1' I think this is probably related to the fact that I haven't configured my program to connect to any particular IPA server, because before the program errors out, it prints: ipa: INFO: Forwarding 'stageuser_add' to json server 'None' If the problem is the lack of a target server, as I suspect, how would I configure the program to connect to a particular IPA server? If this isn't caused by that, what could the causes be? -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] user deletion in offline mode does not get replicated after node recovery
Hello On Master: User 'onmaster' was deleted [16/Jun/2015:10:16:45 -0400] conn=402 op=19 SRCH base="cn=otp,dc=bagam,dc=net" scope=1 filter="(&(objectClass=ipatoken)(ipatokenOwner=uid=onmaster,cn=users,cn=accounts,dc=bagam,dc=net))" attrs="ipatokenNotAfter description ipatokenOwner objectClass ipatokenDisabled ipatokenVendor managedBy ipatokenModel ipatokenNotBefore ipatokenUniqueID ipatokenSerial" [16/Jun/2015:10:16:45 -0400] conn=402 op=19 RESULT err=0 tag=101 nentries=0 etime=0 [16/Jun/2015:10:16:45 -0400] conn=402 op=20 DEL dn="uid=onmaster,cn=users,cn=accounts,dc=bagam,dc=net" [16/Jun/2015:10:16:45 -0400] conn=402 op=21 UNBIND [16/Jun/2015:10:16:45 -0400] conn=402 op=21 fd=120 closed - U1 [16/Jun/2015:10:16:45 -0400] conn=402 op=20 RESULT err=0 tag=107 nentries=0 etime=0 csn=55802fcf00030004 Replication agreement failed to replicate it to the replica2 [16/Jun/2015:10:18:36 -0400] NSMMReplicationPlugin - agmt="cn=f22master.bagam.net-to-f22replica2.bagam.net" (f22replica2:389): Consumer failed to replay change (uniqueid b8242e18-143111e5-b1d0d0c3-ae5854ff, CSN 55802fcf00030004): Operations error (1). Will retry later. On replica2: The replicated operation failed [16/Jun/2015:10:18:27 -0400] conn=8 op=4 RESULT err=0 tag=101 nentries=1 etime=0 [16/Jun/2015:10:18:27 -0400] conn=8 op=5 EXT oid="2.16.840.1.113730.3.5.12" name="replication-multimaster-extop" [16/Jun/2015:10:18:27 -0400] conn=8 op=5 RESULT err=0 tag=120 nentries=0 etime=0 [16/Jun/2015:10:18:27 -0400] conn=8 op=6 DEL dn="uid=onmaster,cn=users,cn=accounts,dc=bagam,dc=net" [16/Jun/2015:10:18:35 -0400] conn=8 op=6 RESULT err=1 tag=107 nentries=0 etime=8 csn=55802fcf00030004 because of DB failures to update. The failures were E_AGAIN or E_DB_DEADLOCK. In such situation, DS retries after a small delay. The problem is that it retried 50 times without success. [16/Jun/2015:10:18:34 -0400] NSMMReplicationPlugin - changelog program - _cl5WriteOperationTxn: retry (49) the transaction (csn=55802fcf00030004) failed (rc=-30993 (BDB0068 DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock)) [16/Jun/2015:10:18:34 -0400] NSMMReplicationPlugin - changelog program - _cl5WriteOperationTxn: failed to write entry with csn (55802fcf00030004); db error - -30993 BDB0068 DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock [16/Jun/2015:10:18:34 -0400] NSMMReplicationPlugin - write_changelog_and_ruv: can't add a change for uid=onmaster,cn=users,cn=accounts,dc=bagam,dc=net (uniqid: b8242e18-143111e5-b1d0d0c3-ae5854ff, optype: 32) to changelog csn 55802fcf00030004 [16/Jun/2015:10:18:34 -0400] - SLAPI_PLUGIN_BE_TXN_POST_DELETE_FN plugin returned error code but did not set SLAPI_RESULT_CODE The MAIN issue here is that replica2 successfully applied others updates after 55802fcf00030004 from the same replica (e.g csn=55802fcf00040004) I do not know if master was able to detect this failure and to replay this update. but I am afraid it did not !! It is looking like you hit https://fedorahosted.org/389/ticket/47788 Is it possible to access your VM ? [16/Jun/2015:10:18:27 -0400] conn=8 op=6 DEL dn="uid=onmaster,cn=users,cn=accounts,dc=bagam,dc=net" [16/Jun/2015:10:18:35 -0400] conn=8 op=6 RESULT err=1 tag=107 nentries=0 etime=8 csn=55802fcf00030004 [16/Jun/2015:10:18:35 -0400] conn=8 op=7 MOD dn="cn=ipausers,cn=groups,cn=accounts,dc=bagam,dc=net" [16/Jun/2015:10:18:36 -0400] conn=8 op=7 RESULT err=0 tag=103 nentries=0 etime=1 csn=55802fcf00040004 [16/Jun/2015:10:18:36 -0400] conn=8 op=8 DEL dn="cn=onmaster,cn=groups,cn=accounts,dc=bagam,dc=net" [16/Jun/2015:10:18:37 -0400] conn=8 op=8 RESULT err=0 tag=107 nentries=0 etime=1 csn=55802fcf00070004 [16/Jun/2015:10:18:37 -0400] conn=8 op=9 MOD dn="cn=ipausers,cn=groups,cn=accounts,dc=bagam,dc=net" [16/Jun/2015:10:18:37 -0400] conn=8 op=9 RESULT err=0 tag=103 nentries=0 etime=0 csn=55802fd6 On 06/16/2015 04:49 PM, Oleg Fayans wrote: Hi all, I've bumped into a strange problem with only a part of changes implemented on master during replica outage get replicated after replica recovery. Namely: when I delete an existing user on the master while the node is offline, these changes do not get to the node when it's back online. User creation, however, gets replicated as expected. Steps to reproduce: 1. Create the following tolopogy: replica1 <-> master <-> replica2 <-> replica3 2. Create user1 on master, make sure it appears on all replicas 3. Turn off replica2 4. On master delete user1 and create user2, make sure the changes get replicated to replica1 5. Turn on replica2 Expected results: A minute or so after repica2 is back up, 1. user1 does not exist neither on replica2 nor on replica3 2. user2 exists both on replica2 and replica3 Actual results: 1. user1 coexist with user2 on replica2 and replica3 2. master and replica1 have only user2 In my case, though, the topology was as
[Freeipa-devel] update on freeipa 4.2 pki issues
I fixed several issues which broke Dogtag upgrades involving particular versions; these will be in the next release. I haven't yet gotten to to the reported failure running ipa-replica-upgrade on a replica (but I haven't forgotten about it either.) This is the only issue affecting *fresh installs* that I am aware of. If you know of others please let me know! The remaining Dogtag-related upgrade problem is caused by new DS schema on the Dogtag side, which is used for LDAP-based profiles. There is not yet an automatic schema upgrade facility for Dogtag, so the new schema was missing. The planned approach is: - Either Dogtag or FreeIPA will add the new CS schema on upgrade. (Eventually Dogtag will need to manage its own schema updates but right now there is no facility, and the new schema is only used by IPA.) - Migrate file-based profiles into LDAP during IPA upgrade. But for this to work, I need to make sure that if new schema is added, then entries that use the new schema, replication to instances that did not yet have the new schema will not break. Anyone who knows LDAP better than me, please share your knowledge! - If my assumptions about replication are wrong, the best approach will probably be to have the administrator perform profile migration (via a script) as a later task, after all replicas have been upgraded. Thanks, Fraser -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [PATCH 0041] add DS index for userCertificate attribute
Related to http://www.freeipa.org/page/V4/User_Certificates and https://fedorahosted.org/freeipa/ticket/4238 -- Martin^3 Babinsky From 2c5a37557d0d5e19bfe3119f71e3010e4b4454dc Mon Sep 17 00:00:00 2001 From: Martin Babinsky Date: Tue, 16 Jun 2015 13:20:15 +0200 Subject: [PATCH] add DS index for userCertificate attribute 'eq' and 'pres' indices for userCertificate attribute allow for more efficient lookup and matching of binary certificates assigned to users, hosts, and services. Part of http://www.freeipa.org/page/V4/User_Certificates --- install/share/indices.ldif| 9 + install/updates/20-indices.update | 8 2 files changed, 17 insertions(+) diff --git a/install/share/indices.ldif b/install/share/indices.ldif index 70a587d7a2c3d29955f4f95f6b475c4f90fb73a7..448875dead0486c3fd12b144df96b5d27ee55dfe 100644 --- a/install/share/indices.ldif +++ b/install/share/indices.ldif @@ -247,3 +247,12 @@ nsSystemIndex: false nsIndexType: eq nsIndexType: pres nsIndexType: sub + +dn: cn=userCertificate,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config +changetype: add +cn: userCertificate +ObjectClass: top +ObjectClass: nsIndex +nsSystemIndex: false +nsIndexType: eq +nsIndexType: pres diff --git a/install/updates/20-indices.update b/install/updates/20-indices.update index ed855b295ee2f9a02effc72bc2ffe52b4c5730df..d65905e184587e375ab22757b984524650ba3c21 100644 --- a/install/updates/20-indices.update +++ b/install/updates/20-indices.update @@ -209,3 +209,11 @@ default:nsSystemIndex: false only:nsIndexType: eq only:nsIndexType: pres only:nsIndexType: sub + +dn: cn=userCertificate,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config +default:cn: userCertificate +default:ObjectClass: top +default:ObjectClass: nsIndex +only:nsSystemIndex: false +only:nsIndexType: eq +only:nsIndexType: pres -- 2.1.0 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] user deletion in offline mode does not get replicated after node recovery
Hi Oleg, the problem seems to be on replica2, when it logs this error: [16/Jun/2015:10:18:34 -0400] NSMMReplicationPlugin - changelog program - _cl5WriteOperationTxn: retry (49) the transaction (csn=55802fcf00030004) failed (rc=-30993 (BDB0068 DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock)) [16/Jun/2015:10:18:34 -0400] NSMMReplicationPlugin - changelog program - _cl5WriteOperationTxn: failed to write entry with csn (55802fcf00030004); db error - -30993 BDB0068 DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock [16/Jun/2015:10:18:34 -0400] NSMMReplicationPlugin - write_changelog_and_ruv: can't add a change for uid=onmaster,cn=users,cn=accounts,dc=bagam,dc=net (uniqid: b8242e18-143111e5-b1d0d0c3-ae5854ff, optype: 32) to changelog csn 55802fcf00030004 [16/Jun/2015:10:18:34 -0400] - SLAPI_PLUGIN_BE_TXN_POST_DELETE_FN plugin returned error code but did not set SLAPI_RESULT_CODE but replication seems to continue and not to repeat this: [16/Jun/2015:10:18:27 -0400] conn=8 op=6 DEL dn="uid=onmaster,cn=users,cn=accounts,dc=bagam,dc=net" [16/Jun/2015:10:18:35 -0400] conn=8 op=6 RESULT err=1 tag=107 nentries=0 etime=8 csn=55802fcf00030004 [16/Jun/2015:10:18:35 -0400] conn=8 op=7 MOD dn="cn=ipausers,cn=groups,cn=accounts,dc=bagam,dc=net" [16/Jun/2015:10:18:36 -0400] conn=8 op=7 RESULT err=0 tag=103 nentries=0 etime=1 csn=55802fcf00040004 [16/Jun/2015:10:18:36 -0400] conn=8 op=8 DEL dn="cn=onmaster,cn=groups,cn=accounts,dc=bagam,dc=net" [16/Jun/2015:10:18:37 -0400] conn=8 op=8 RESULT err=0 tag=107 nentries=0 etime=1 csn=55802fcf00070004 [16/Jun/2015:10:18:37 -0400] conn=8 op=9 MOD dn="cn=ipausers,cn=groups,cn=accounts,dc=bagam,dc=net" [16/Jun/2015:10:18:37 -0400] conn=8 op=9 RESULT err=0 tag=103 nentries=0 etime=0 csn=55802fd6 I don't see why there is a deadlock ? Is it reproducable every time ? On 06/16/2015 04:49 PM, Oleg Fayans wrote: Hi all, I've bumped into a strange problem with only a part of changes implemented on master during replica outage get replicated after replica recovery. Namely: when I delete an existing user on the master while the node is offline, these changes do not get to the node when it's back online. User creation, however, gets replicated as expected. Steps to reproduce: 1. Create the following tolopogy: replica1 <-> master <-> replica2 <-> replica3 2. Create user1 on master, make sure it appears on all replicas 3. Turn off replica2 4. On master delete user1 and create user2, make sure the changes get replicated to replica1 5. Turn on replica2 Expected results: A minute or so after repica2 is back up, 1. user1 does not exist neither on replica2 nor on replica3 2. user2 exists both on replica2 and replica3 Actual results: 1. user1 coexist with user2 on replica2 and replica3 2. master and replica1 have only user2 In my case, though, the topology was as follows: $ ipa topologysegment-find realm -- 3 segments matched -- Segment name: f22master.bagam.net-to-f22replica3.bagam.net Left node: f22master.bagam.net Right node: f22replica3.bagam.net Connectivity: both Segment name: replica1-to-replica2 Left node: f22replica1.bagam.net Right node: f22replica2.bagam.net Connectivity: both Segment name: replica2-to-master Left node: f22replica2.bagam.net Right node: f22master.bagam.net Connectivity: both Number of entries returned 3 And I was turning off replica2, leaving replica1 offline, but that does not really matter. The dirsrv error message, most likely to be relevant is: - Consumer failed to replay change (uniqueid b8242e18-143111e5-b1d0d0c3-ae5854ff, CSN 55802fcf00030004): Operations error (1). Will retry later - I attach dirsrv error and access logs from all nodes, in case they could be useful -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] FreeIPA 4.2 Alpha preparations
On Tue, Jun 16, 2015 at 05:10:00PM +0200, Martin Kosek wrote: > On 06/12/2015 11:34 AM, Martin Kosek wrote: > > Hello all, > > > > As discussed in the last 2 weeks, we are getting close to the 4.2 finish > > line > > and releasing FreeIPA 4.2 Alpha 1. We already have most of the major RFEs > > complete, some still miss some partial functionality, but most are testable > > and > > in Alpha state already. > > > > We need to now find out what is blocking us from releasing the Alpha. I know > > only about 2 issues: > > > > - ipa-replica-manage del does not work well with the Topology plugin yet - > > Petr > > Vobornik and Ludwig are working on it > > - ipa-replica-prepare had some issues after upgrade from 4.1.x to 4.2.0 due > > to > > inaccesible certificate profiles - Jan, Martin2, Fraser was investigating > > > > Is that correct? Feature owners, please let me know if any of the major > > feature > > regressed and is not working properly, maybe by other patch sets being > > merged. > > > > When the blockers are resolved or documented, we should release the beast. > > Any > > volunteer for the release process? > > > > Finally, I put together a release note draft for the Alpha, please help me > > completing and updating it: > > > > http://www.freeipa.org/page/Releases/4.2.0.alpha1 > > > > Thanks everyone! > > > > I saw many fixes in Topology, that's good. I heard that pki-core 10.2.4 broke > us, but I could not reproduce it today with fully updated F22 machine and I > was > able to install FreeIPA 4.2.git > > If this is the case, can we just release the Alpha? There are still some big brokens for upgrades. The fixes for pki are merged but there is no release yet. I am only aware of one reported issue for new installations: ipa-replica-prepare failing when run on a replica (I haven't gotten to investigating this one yet). -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0014] correct handling of one directional segments
On 06/16/2015 11:41 AM, Ludwig Krispenz wrote: this patch adresses issues in checking existing segments for one directional segments and correctly handles the merging of segments, so that all agreements will be removed when the merged segment is deleted This is looking good to me with few comments * in ipa_topo_cfg_replica_segment_find, if 'dir=0' or 'dir=bidirectionnal' the reverse direction is bidirectionnal. Is it the expected result ? * in ipa_topo_check_segment_is_valid and ipa_topo_util_find_segment, may be hardening leftnode,rightnode,dir if they are NULL. (if the entry violate schema). * ipa_topo_util_segm_dir if direction does not match any of the strings, it returns -1. 0 would be better if we decide to test bit mask. * in ipa_topo_util_segment_update:810, ex_segm is a rigth_left segment. Why trying to call ipa_topo_cfg_agmt_dup with ex_segm->left in priority. Why not ex_segm->right first ? * in ipa_topo_util_delete_segments_for_host, If segment localhost->delhost is bidirectional, how can it exists a reverse segment delhost->localhost ? I thought those segments have been merged ? Thanks thierry -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] FreeIPA 4.2 Alpha preparations
On 06/12/2015 11:34 AM, Martin Kosek wrote: > Hello all, > > As discussed in the last 2 weeks, we are getting close to the 4.2 finish line > and releasing FreeIPA 4.2 Alpha 1. We already have most of the major RFEs > complete, some still miss some partial functionality, but most are testable > and > in Alpha state already. > > We need to now find out what is blocking us from releasing the Alpha. I know > only about 2 issues: > > - ipa-replica-manage del does not work well with the Topology plugin yet - > Petr > Vobornik and Ludwig are working on it > - ipa-replica-prepare had some issues after upgrade from 4.1.x to 4.2.0 due to > inaccesible certificate profiles - Jan, Martin2, Fraser was investigating > > Is that correct? Feature owners, please let me know if any of the major > feature > regressed and is not working properly, maybe by other patch sets being merged. > > When the blockers are resolved or documented, we should release the beast. Any > volunteer for the release process? > > Finally, I put together a release note draft for the Alpha, please help me > completing and updating it: > > http://www.freeipa.org/page/Releases/4.2.0.alpha1 > > Thanks everyone! > I saw many fixes in Topology, that's good. I heard that pki-core 10.2.4 broke us, but I could not reproduce it today with fully updated F22 machine and I was able to install FreeIPA 4.2.git If this is the case, can we just release the Alpha? -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0050] Fix client ca.crt to match the server's cert
I know you guys are busy. Bump for review. Thanks, Gabe On Tue, May 26, 2015 at 8:16 AM, Gabe Alford wrote: > Hello, > > Fix for https://fedorahosted.org/freeipa/ticket/3809 > > Thanks, > > Gabe > -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0264] Server Upgrade: disconnect ldap2 connection before DS restart
On Wed, 2015-06-10 at 13:47 +0200, Martin Basti wrote: > Without this patch, upgrade may failed when api.Backend.ldap2 was > connected before DS restart. > > Patch attached. > although this patch is fine as is, I wonder why it is needed. I would argue that ldap2 should be able to reconnect on its own if the connection is broken, where am I wrong ? Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCHES 0252-0253] DNSSEC: allow to move DNSSEC key master to another IPA server
On 05/06/15 12:54, Petr Spacek wrote:
On 20.5.2015 18:00, Martin Basti wrote:
This patch allows to disable DNSSEC key master on IPA server, or replace
current DNSSEC key master with another IPA server.
Only for master branch.
https://fedorahosted.org/freeipa/ticket/4657
Patches attached.
NACK. This happens on DNSSEC key master:
$ ipa-dns-install --disable-dnssec-master
Do you want to disable current DNSSEC key master? [no]: yes
Unexpected error - see /var/log/ipaserver-install.log for details:
TypeError: sequence item 0: expected string, DNSName found
2015-06-05T10:52:35Z DEBUG File
"/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line
733, in run_script
return_value = main_function()
File "/sbin/ipa-dns-install", line 128, in main
dns_installer.disable_dnssec_master(options.unattended)
File "/usr/lib/python2.7/site-packages/ipaserver/install/dns.py", line 112,
in disable_dnssec_master
", ".join(dnssec_zones))
2015-06-05T10:52:35Z DEBUG The ipa-dns-install command failed, exception:
TypeError: sequence item 0: expected string, DNSName found
Updated patches attached.
Due new installers, more changes were required.
--
Martin Basti
From 6a9488489786215500af1d0a706380f296999ea0 Mon Sep 17 00:00:00 2001
From: Martin Basti
Date: Wed, 13 May 2015 14:45:32 +0200
Subject: [PATCH 1/2] DNSSEC: allow to disable/replace DNSSEC key master
This commit allows to replace or disable DNSSEC key master
Replacing DNSSEC master requires to copy kasp.db file manually by user
ipa-dns-install:
--disable-dnssec-master DNSSEC master will be disabled
--replace-dnssec-master=IPA_SERVER DNSSEC master will be replaced, by
IPA_SERVER (required to rerun ipa-dns-install wit appropriate options).
--dnssec-master --kasp-db=FILE This configure new DNSSEC master server, kasp.db from old server is required
https://fedorahosted.org/freeipa/ticket/4657
---
install/tools/ipa-dns-install | 18 +++
ipaplatform/base/paths.py | 1 +
ipaserver/install/dns.py | 240 -
ipaserver/install/odsexporterinstance.py | 12 +-
ipaserver/install/opendnssecinstance.py| 69 +++--
ipaserver/install/server/install.py| 23 +++
ipaserver/install/server/replicainstall.py | 31 +++-
7 files changed, 373 insertions(+), 21 deletions(-)
diff --git a/install/tools/ipa-dns-install b/install/tools/ipa-dns-install
index fd9311657e813988310db2be604ca68d26936af5..0f640c3e85b1a5eb717be5082c2fdf030ec4eec5 100755
--- a/install/tools/ipa-dns-install
+++ b/install/tools/ipa-dns-install
@@ -61,6 +61,17 @@ def parse_options():
help="DNS zone manager e-mail address. Defaults to hostmaster@DOMAIN")
parser.add_option("-U", "--unattended", dest="unattended", action="store_true",
default=False, help="unattended installation never prompts the user")
+parser.add_option("--disable-dnssec-master", dest="disable_dnssec_master",
+ action="store_true", default=False, help="Disable the "
+ "DNSSEC master on this server")
+parser.add_option("--replace-dnssec-master", dest="replace_dnssec_master",
+ type="string", metavar="IPA_DNS_SERVER_HOSTNAME",
+ action="store", help="Replace the current DNSSEC master "
+ "with the specified IPA server")
+parser.add_option("--kasp-db", dest="kasp_db_file", type="string",
+ metavar="FILE", action="store", help="Copy OpenDNSSEC "
+ "metadata from the specified file (will not create a new "
+ "kasp.db file)")
options, args = parser.parse_args()
safe_options = parser.get_safe_opts(options)
@@ -70,10 +81,17 @@ def parse_options():
elif options.reverse_zones and options.no_reverse:
parser.error("You cannot specify a --reverse-zone option together with --no-reverse")
+if options.disable_dnssec_master and options.replace_dnssec_master:
+parser.error("You cannot specify a --disable-dnssec-master option "
+ "together with --replace-dnssec-master")
+
if options.unattended:
if not options.forwarders and not options.no_forwarders:
parser.error("You must specify at least one --forwarder option or --no-forwarders option")
+if options.kasp_db_file and not ipautil.file_exists(options.kasp_db_file):
+parser.error("File %s does not exist" % options.kasp_db_file)
+
if options.dm_password:
print ("WARNING: Option -p/--ds-password is deprecated "
"and should not be used anymore.")
diff --git a/ipaplatform/base/paths.py b/ipaplatform/base/paths.py
index e6b19181929b54f6d83701a0fdbc3c4a54364082..b8c27f09d6812982a38d26ef596c0539cb1b8a8b 100644
--- a/ipaplatform/base/paths.py
+++ b/ipaplatform/base/paths.py
@@ -143,6 +143,7 @@ class BasePathNamespace(object)
Re: [Freeipa-devel] [PATCHES 306-316] Automated migration tool from Winsync
Dne 16.6.2015 v 10:14 Martin Babinsky napsal(a): On 05/06/2015 10:12 AM, Tomas Babej wrote: On 05/05/2015 02:02 PM, Tomas Babej wrote: On 04/29/2015 12:28 PM, Tomas Babej wrote: On 03/11/2015 04:20 PM, Jan Cholasta wrote: Hi, Dne 10.3.2015 v 16:35 Tomas Babej napsal(a): On 03/09/2015 12:26 PM, Tomas Babej wrote: Hi, this couple of patches provides a initial implementation of the winsync migration tool: https://fedorahosted.org/freeipa/ticket/4524 Some parts could use some polishing, but this is a sound foundation. Tomas Attaching one more patch to the bundle. This one should make the winsync tool readily available after install. Tomas Nitpicks: The winsync_migrate module should be in ipaserver.install. Also I don't see why it has to be a package when there is just one short file in it. By convention, the AdminTool subclass should be named WinsyncMigrate, or the tool should be named ipa-migrate-winsync. Honza Updated patches attached. Tomas Rebased patches with cleaned membership bits. Tomas I did some self-review, updated patches attached. Hi Tomas, patches look good and seem to work as expected. I have some comments: 1.) When running the tool I get a number of warnings about users not found (https://paste.fedoraproject.org/232251/43884831/), but in the end everything seems to be fine and users are migrated in the external groups just fine. Is this behavior normal? 2.) Since both "--realm" and "--server" options are mandatory, I was thinking if it would be better to use positional arguments, since you always have to specify them. What are your thought on this? I would rather stay consistent with ipa-server-install and friends and keep them as options. 3.) Patches 317-318 seem to just just rename/move things and could be squashed in the previous ones. But that is just a minor thing and I leave that to your discretion. 4.) After all the renaming and moving around the WinsyncMigrate class (see previous point) there is an unused file "ipaserver/winsync_migrate/__init__.py" left. You should remove it in some patch (e.g. in patch 318 if you decide to keep it). Also please rename the class to "MigrateWinsync", for consistency. 5.) Option "--log-file" seems to be broken. When specified on CLI the log is created but empty, the program prints out nothing and then exits without doing anything. However, I suspect that this is AdminTool's problem, not yours. -- Jan Cholasta -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [PATCH 0015] fix coverity issues
This patch addresses coverity issues 13290 and 13291
>From 830f1f5af9695e35cb0843f8919c8fc555d13308 Mon Sep 17 00:00:00 2001
From: Ludwig Krispenz
Date: Tue, 16 Jun 2015 11:14:37 +0200
Subject: [PATCH] fix coverity issues
---
daemons/ipa-slapi-plugins/topology/topology_util.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/daemons/ipa-slapi-plugins/topology/topology_util.c b/daemons/ipa-slapi-plugins/topology/topology_util.c
index 9851df059dc3e79ea0ae48d094de79b84ecfb086..a56704f51a282ebaa6dd86b80c1602689550f40f 100644
--- a/daemons/ipa-slapi-plugins/topology/topology_util.c
+++ b/daemons/ipa-slapi-plugins/topology/topology_util.c
@@ -192,7 +192,11 @@ ipa_topo_util_get_replica_conf(char *repl_root)
slapi_free_search_results_internal(pb);
slapi_pblock_destroy(pb);
-if (0 != ipa_topo_cfg_replica_add(topoRepl)) {
+if (0 == topoRepl) {
+slapi_log_error(SLAPI_LOG_FATAL, IPA_TOPO_PLUGIN_SUBSYSTEM,
+"ipa_topo_util_get_replica_conf: "
+"cannot create replica\n");
+} else if (0 != ipa_topo_cfg_replica_add(topoRepl)) {
slapi_log_error(SLAPI_LOG_FATAL, IPA_TOPO_PLUGIN_SUBSYSTEM,
"ipa_topo_util_get_replica_conf: "
"replica already exists\n");
@@ -1325,6 +1329,14 @@ ipa_topo_util_delete_segments_for_host(char *repl_root, char *delhost)
TopoReplica *tconf = ipa_topo_cfg_replica_find(repl_root, 1);
int check_reverse = 1;
+if (NULL == tconf) {
+slapi_log_error(SLAPI_LOG_PLUGIN, IPA_TOPO_PLUGIN_SUBSYSTEM,
+"ipa_topo_util_delete_segments_for_host: "
+"failed to get replica object for suffix: %s \n",
+ repl_root);
+return;
+}
+
/* first check if a segment originating at localhost exists */
segm = ipa_topo_cfg_segment_find(repl_root, ipa_topo_get_plugin_hostname(),
delhost, SEGMENT_LEFT_RIGHT);
--
2.1.0
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [PATCH 0014] correct handling of one directional segments
this patch adresses issues in checking existing segments for one
directional segments and correctly handles the merging of segments, so
that all agreements will be removed when the merged segment is deleted
>From ad9850b00f369be67c0240b084afaf2ce1c97a9f Mon Sep 17 00:00:00 2001
From: Ludwig Krispenz
Date: Tue, 16 Jun 2015 10:25:22 +0200
Subject: [PATCH] correct management of one directional segments
this patch contains the following improvements:
check for existing segments works for all combinations of one directional and bidirectional segments
rdns of replication agreements generated from one directional segments are preserves after
merging of segments, so that deletion of the segment deletes the corresponding replication
agreements
---
daemons/ipa-slapi-plugins/topology/topology.h | 5 +-
daemons/ipa-slapi-plugins/topology/topology_cfg.c | 18 ++-
daemons/ipa-slapi-plugins/topology/topology_post.c | 8 +-
daemons/ipa-slapi-plugins/topology/topology_pre.c | 9 +-
daemons/ipa-slapi-plugins/topology/topology_util.c | 159 +
5 files changed, 160 insertions(+), 39 deletions(-)
diff --git a/daemons/ipa-slapi-plugins/topology/topology.h b/daemons/ipa-slapi-plugins/topology/topology.h
index 4135a8ff71b9160919a089fde63a95a989830de8..9c680e7cfd636bb783b51ed904c74f34c4e4cf20 100644
--- a/daemons/ipa-slapi-plugins/topology/topology.h
+++ b/daemons/ipa-slapi-plugins/topology/topology.h
@@ -177,11 +177,12 @@ void ipa_topo_cfg_host_add(Slapi_Entry *hostentry);
void ipa_topo_cfg_host_del(Slapi_Entry *hostentry);
TopoReplicaHost *ipa_topo_cfg_host_find(TopoReplica *tconf, char *host, int lock);
TopoReplicaHost *ipa_topo_cfg_host_new(char *newhost);
+int ipa_topo_util_segm_dir(char *direction);
TopoReplicaSegment *
-ipa_topo_cfg_segment_find(char *repl_root, char *leftHost, char *rightHost);
+ipa_topo_cfg_segment_find(char *repl_root, char *leftHost, char *rightHosti, int dir);
TopoReplicaSegment *
ipa_topo_cfg_replica_segment_find(TopoReplica *tconf, char *leftHost,
- char *rightHost, int lock);
+ char *rightHost, int dir, int lock);
void ipa_topo_cfg_segment_set_visited(TopoReplica *tconf, TopoReplicaSegment *tsegm);
void ipa_topo_cfg_segment_add(TopoReplica *tconf, TopoReplicaSegment *tsegm);
void ipa_topo_cfg_segment_del(TopoReplica *tconf, TopoReplicaSegment *tsegm);
diff --git a/daemons/ipa-slapi-plugins/topology/topology_cfg.c b/daemons/ipa-slapi-plugins/topology/topology_cfg.c
index 982ad647db9737c1aa0fc7f68c7d9b20de895fb6..19b6947a76d2264367e05a89c9c24487816d078a 100644
--- a/daemons/ipa-slapi-plugins/topology/topology_cfg.c
+++ b/daemons/ipa-slapi-plugins/topology/topology_cfg.c
@@ -545,19 +545,25 @@ ipa_topo_cfg_host_del(Slapi_Entry *hostentry)
}
TopoReplicaSegment *
-ipa_topo_cfg_replica_segment_find(TopoReplica *replica, char *leftHost, char *rightHost, int lock)
+ipa_topo_cfg_replica_segment_find(TopoReplica *replica, char *leftHost, char *rightHost, int dir, int lock)
{
TopoReplicaSegment *tsegm = NULL;
TopoReplicaSegmentList *segments = NULL;
+int reverse_dir = SEGMENT_BIDIRECTIONAL;
+
+if (dir == SEGMENT_LEFT_RIGHT) reverse_dir = SEGMENT_RIGHT_LEFT;
+else if (dir == SEGMENT_RIGHT_LEFT) reverse_dir = SEGMENT_LEFT_RIGHT;
+else reverse_dir = SEGMENT_BIDIRECTIONAL;
if (lock) slapi_lock_mutex(replica->repl_lock);
segments = replica->repl_segments;
while (segments) {
+
tsegm = segments->segm;
if ( (!strcasecmp(leftHost,tsegm->from) && !strcasecmp(rightHost,tsegm->to) &&
- (tsegm->direct == SEGMENT_BIDIRECTIONAL || tsegm->direct == SEGMENT_LEFT_RIGHT)) ||
+ (tsegm->direct & dir)) ||
(!strcasecmp(leftHost,tsegm->to) && !strcasecmp(rightHost,tsegm->from) &&
- (tsegm->direct == SEGMENT_BIDIRECTIONAL || tsegm->direct == SEGMENT_RIGHT_LEFT))) {
+ (tsegm->direct & reverse_dir))) {
break;
}
tsegm = NULL;
@@ -680,7 +686,7 @@ ipa_topo_cfg_segment_dup(TopoReplicaSegment *orig)
}
TopoReplicaSegment *
-ipa_topo_cfg_segment_find(char *repl_root, char *leftHost, char *rightHost)
+ipa_topo_cfg_segment_find(char *repl_root, char *leftHost, char *rightHost, int dir)
{
TopoReplicaSegment *tsegm = NULL;
TopoReplica *replica = NULL;
@@ -689,7 +695,7 @@ ipa_topo_cfg_segment_find(char *repl_root, char *leftHost, char *rightHost)
replica = ipa_topo_cfg_replica_find(repl_root, 0);
if (replica) {
-tsegm = ipa_topo_cfg_replica_segment_find(replica,leftHost,rightHost, 1);
+tsegm = ipa_topo_cfg_replica_segment_find(replica,leftHost,rightHost, dir, 1);
}
slapi_unlock_mutex(topo_shared_conf.conf_lock);
return tsegm;
@@ -731,7 +737,7 @@ ipa_topo_cfg_segment_add(TopoReplica *replica, TopoReplicaSegment *tsegm)
slapi_lock_mutex(replica->repl_lock);
if (ipa_topo_cfg_replica_segment_
Re: [Freeipa-devel] [PATCH 0040] generalize certificate creation during testing
On 06/09/2015 01:14 PM, Martin Babinsky wrote: A slight hack to ipatests/test_xmlrpc/testcert.py module in order to enable generation of multiple host/service/user certificates. It should make writing tests for new CA profile/sub-CA/user certificate functionality easier. Hi, looks good to me, ACK. Milan -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCHES 306-316] Automated migration tool from Winsync
On 05/06/2015 10:12 AM, Tomas Babej wrote: On 05/05/2015 02:02 PM, Tomas Babej wrote: On 04/29/2015 12:28 PM, Tomas Babej wrote: On 03/11/2015 04:20 PM, Jan Cholasta wrote: Hi, Dne 10.3.2015 v 16:35 Tomas Babej napsal(a): On 03/09/2015 12:26 PM, Tomas Babej wrote: Hi, this couple of patches provides a initial implementation of the winsync migration tool: https://fedorahosted.org/freeipa/ticket/4524 Some parts could use some polishing, but this is a sound foundation. Tomas Attaching one more patch to the bundle. This one should make the winsync tool readily available after install. Tomas Nitpicks: The winsync_migrate module should be in ipaserver.install. Also I don't see why it has to be a package when there is just one short file in it. By convention, the AdminTool subclass should be named WinsyncMigrate, or the tool should be named ipa-migrate-winsync. Honza Updated patches attached. Tomas Rebased patches with cleaned membership bits. Tomas I did some self-review, updated patches attached. Hi Tomas, patches look good and seem to work as expected. I have some comments: 1.) When running the tool I get a number of warnings about users not found (https://paste.fedoraproject.org/232251/43884831/), but in the end everything seems to be fine and users are migrated in the external groups just fine. Is this behavior normal? 2.) Since both "--realm" and "--server" options are mandatory, I was thinking if it would be better to use positional arguments, since you always have to specify them. What are your thought on this? 3.) Patches 317-318 seem to just just rename/move things and could be squashed in the previous ones. But that is just a minor thing and I leave that to your discretion. 4.) After all the renaming and moving around the WinsyncMigrate class (see previous point) there is an unused file "ipaserver/winsync_migrate/__init__.py" left. You should remove it in some patch (e.g. in patch 318 if you decide to keep it). 5.) Option "--log-file" seems to be broken. When specified on CLI the log is created but empty, the program prints out nothing and then exits without doing anything. However, I suspect that this is AdminTool's problem, not yours. -- Martin^3 Babinsky -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
