On 01/10/2013 05:11 PM, John Dennis wrote:
On 01/10/2013 10:23 AM, Martin Kosek wrote:
AFAIU, the API will not change as we do the CSV processing only on
client side
and send processed entries to the server. CSV processing on old
clients should
still work fine.
Is that really true? I thought
On 01/10/2013 09:34 PM, Rob Crittenden wrote:
We were asserting that the uniqueMember contain DN objects but weren't
actually
making them DN objects.
A sample entry looks like:
dn: cn=Group1,ou=Groups,dc=example,dc=com
gidNumber: 1001
objectClass: top
objectClass: groupOfUniqueNames
On 01/10/2013 10:53 PM, Rob Crittenden wrote:
Martin Kosek wrote:
Target Group parameter was not processed correctly which caused
permission-find to always crash when this search parameter was used.
Fix the crash and create a unit test case to avoid future regression.
On 01/11/2013 12:10 AM, Rob Crittenden wrote:
Martin Kosek wrote:
When CRL files are being migrated to a new directory, the upgrade
log may contain an error message raised during MasterCRL.bin symlink
migration. This is actually being caused by `chown' operation which
tried to chown a
We had a small discussion off-list about how we want IPA's LDAP handling
to look in the future.
To continue the discussion publicly I've summarized the results and
added some of my own ideas to a page.
John gets credit for the overview (the mistakes WTFs are mine).
The text is on
Petr Viktorin wrote:
We had a small discussion off-list about how we want IPA's LDAP handling
to look in the future.
To continue the discussion publicly I've summarized the results and
added some of my own ideas to a page.
John gets credit for the overview (the mistakes WTFs are mine).
The
On 01/11/2013 09:10 AM, Rob Crittenden wrote:
Petr Viktorin wrote:
We had a small discussion off-list about how we want IPA's LDAP handling
to look in the future.
To continue the discussion publicly I've summarized the results and
added some of my own ideas to a page.
John gets credit for the
John Dennis wrote:
On 01/11/2013 09:10 AM, Rob Crittenden wrote:
Petr Viktorin wrote:
We had a small discussion off-list about how we want IPA's LDAP handling
to look in the future.
To continue the discussion publicly I've summarized the results and
added some of my own ideas to a page.
John
Hello list,
This discussion was started in private; I'll continue it here.
On 01/10/2013 05:41 PM, John Dennis wrote:
On 01/10/2013 04:27 AM, Petr Viktorin wrote:
On 01/09/2013 03:55 PM, John Dennis wrote:
And I could work on improving the i18n/translations infrastructure,
starting by
On 01/11/2013 09:55 AM, Rob Crittenden wrote:
John Dennis wrote:
On 01/11/2013 09:10 AM, Rob Crittenden wrote:
Petr Viktorin wrote:
We had a small discussion off-list about how we want IPA's LDAP handling
to look in the future.
To continue the discussion publicly I've summarized the results
On 01/11/2013 03:55 PM, Rob Crittenden wrote:
John Dennis wrote:
On 01/11/2013 09:10 AM, Rob Crittenden wrote:
Petr Viktorin wrote:
We had a small discussion off-list about how we want IPA's LDAP
handling
to look in the future.
To continue the discussion publicly I've summarized the results
John Dennis wrote:
On 01/11/2013 09:55 AM, Rob Crittenden wrote:
John Dennis wrote:
On 01/11/2013 09:10 AM, Rob Crittenden wrote:
Petr Viktorin wrote:
We had a small discussion off-list about how we want IPA's LDAP
handling
to look in the future.
To continue the discussion publicly I've
Give a clear message about what is wrong with current Trust settings
before letting AD to return a confusing error message.
https://fedorahosted.org/freeipa/ticket/3193
From c792dffbc65aba27d18196def91da14c2e98f5f4 Mon Sep 17 00:00:00 2001
From: Martin Kosek mko...@redhat.com
Date: Fri, 11 Jan
On 01/11/2013 10:04 AM, Petr Viktorin wrote:
Hello list,
This discussion was started in private; I'll continue it here.
On 01/10/2013 05:41 PM, John Dennis wrote:
On 01/10/2013 04:27 AM, Petr Viktorin wrote:
On 01/09/2013 03:55 PM, John Dennis wrote:
And I could work on improving the
On Mon 03 Dec 2012 05:20:32 AM PST, Lynn Root wrote:
On 11/30/2012 10:35 PM, Rob Crittenden wrote:
Lynn Root wrote:
Returns a clearer hint when user is running ipa-client-automount with
possible firewall up and blocking need ports.
Not sure if this patch is worded correctly in order to
Hello,
Don't fail if idnsSOAserial attribute is missing in LDAP.
DNS zones created on remote IPA 3.0 server don't have
idnsSOAserial attribute present in LDAP.
https://bugzilla.redhat.com/show_bug.cgi?id=894131
Attached patch contains the minimal set of changes need for
2013/1/11 John Dennis jden...@redhat.com
On 01/11/2013 10:04 AM, Petr Viktorin wrote:
Hello list,
This discussion was started in private; I'll continue it here.
On 01/10/2013 05:41 PM, John Dennis wrote:
On 01/10/2013 04:27 AM, Petr Viktorin wrote:
On 01/09/2013 03:55 PM, John Dennis
On 01/11/2013 02:44 PM, Jérôme Fenal wrote:
2013/1/11 John Dennis jden...@redhat.com mailto:jden...@redhat.com
Thank you Jérôme for your insights as a translator. We have a lop-sided
perspective mostly from the developer point of view. We need to better
understand the translator's
On 01/11/2013 12:47 PM, Lynn Root wrote:
On Mon 03 Dec 2012 05:20:32 AM PST, Lynn Root wrote:
On 11/30/2012 10:35 PM, Rob Crittenden wrote:
Lynn Root wrote:
Returns a clearer hint when user is running ipa-client-automount with
possible firewall up and blocking need ports.
Not sure if this
2013/1/11 John Dennis jden...@redhat.com
On 01/11/2013 02:44 PM, Jérôme Fenal wrote:
2013/1/11 John Dennis jden...@redhat.com mailto:jden...@redhat.com
Thank you Jérôme for your insights as a translator. We have a lop-sided
perspective mostly from the developer point of view. We need to
On 01/11/2013 04:00 PM, Jérôme Fenal wrote:
When you say easy to upload a .po onto another branch I assume you
don't mean branch (TX has no such concept) but rather another TX
resource. Anyway this is good to know, perhaps the way TX handles
versions is not half as bad as it
2013/1/11 John Dennis jden...@redhat.com
On 01/11/2013 04:00 PM, Jérôme Fenal wrote:
When you say easy to upload a .po onto another branch I assume you
don't mean branch (TX has no such concept) but rather another TX
resource. Anyway this is good to know, perhaps the way TX
22 matches
Mail list logo
