Re: [Freeipa-devel] [PATCH] 993 disable UPG for migration
On Wed, 2012-03-28 at 17:28 -0400, Rob Crittenden wrote:
Martin Kosek wrote:
On Thu, 2012-03-22 at 15:21 -0400, Rob Crittenden wrote:
We don't want to create private groups automatically for migrated users,
there could be namespace overlap (and race conditions prevent us from
trying to check in advance).
Check the sanity of groups in general, warn if the group for the
gidnumber doesn't exist at least on the remote server.
Fill in the user's shell as well.
This will migrate users that are non-POSIX on the remote server.
rob
This patch fixes the problem of creating UPGs for migrated users, but
there are several parts which confused me.
1) Confusing defaults
+if 'def_group_gid' in ctx:
+entry_attrs.setdefault('gidnumber', ctx['def_group_gid'])
This statement seems redundant, because the account either is posix and
has both uidnumber and gidnumber or it is non-posix and does not have
any.
Now, we don't touch gidNumber for posix user, and non-posix users are
made posix with this statement:
+# migrated user is not already POSIX, make it so
+if 'uidnumber' not in entry_attrs:
+entry_attrs['uidnumber'] = entry_attrs['gidnumber'] = [999]
2) Missing UPG
When UPG is disabled, the following statement will result in a user with
a GID pointing to non-existent group.
+# migrated user is not already POSIX, make it so
+if 'uidnumber' not in entry_attrs:
+entry_attrs['uidnumber'] = entry_attrs['gidnumber'] = [999]
We may want to run ldap.has_upg() and report a add this user to failed
users with appropriate error.
3) Check for GID
The patch implements a check if a group with the gidNumber exists on a
remote LDAP server and the result is a warning:
-(g_dn, g_attrs) = ldap.get_entry(ctx['def_group_dn'],
['gidnumber'])
+(remote_dn, remote_entry) = ds_ldap.find_entry_by_attr(
+'gidnumber', entry_attrs['gidnumber'][0], 'posixgroup',
[''],
+ search_bases['group']
+)
I have few (minor-ish) questions there:
a) Is the warning in a apache log enough? Maybe it should be included in
migrate-ds output.
b) This will be a one more remote LDAP call for every user, we may want
to optimize it with something like that:
valid_gids = []
if user.gidnumber not in valid_gids:
run the check in remote LDAP
valid_gids.append(user.gidnumber)
That would save us 999 LDAP queries for 1000 migrated with the same
primary group.
4) Extraneous Warning:
When non-posix user is migrated and thus we make it a posix user, we
still produce a warning for non-existent group:
[Fri Mar 23 04:21:36 2012] [error] ipa: WARNING: Migrated user's GID
number 999 does not point to a known group.
5) Extraneous LDAP call
Isn't the following call to LDAP to get a description redundant? We
already have the description in entry_attrs.
+(dn, desc_attr) = ldap.get_entry(dn, ['description'])
+entry_attrs.update(desc_attr)
+if 'description' in entry_attrs and NO_UPG_MAGIC in
entry_attrs['description']:
Martin
I think this covers your concerns.
I can't do anything but log warnings at this point in order to maintain
backwards compatibility. I looked into returning a warning entry and it
blew up in validate_output() on older clients.
rob
This patch is much better and covers my previous concerns. I just find
an issue with UPG. It is not created for non-posix users when UPGs are
enabled:
# echo Secret123 | ipa migrate-ds ldap://ldap.example.com
--with-compat --base-dn=dc=greyoak,dc=com
---
migrate-ds:
---
Migrated:
user: darcee_leeson, ayaz_kreiger, mnonposix, mollee_weisenberg
group: ipagroup
Failed user:
Failed group:
--
Passwords have been migrated in pre-hashed format.
IPA is unable to generate Kerberos keys unless provided
with clear text passwords. All migrated users need to
login at https://your.domain/ipa/migration/ before they
can use their Kerberos accounts.
# ipa user-show mnonposix
User login: mnonposix
First name: Mister
Last name: Nonposix
Home directory: /home/mnonposix
Login shell: /bin/sh
UID: 328000195
GID: 328000195
Org. Unit: Product Testing
Job Title: Test User
Account disabled: False
Password: True
Member of groups: ipausers
Kerberos keys available: False
# ipa group-show mnonposix
ipa: ERROR: mnonposix: group not found
I am also thinking if we need to ask if UPG is enabled for every
migrated user - every ldap.has_upg() call means one query to host LDAP.
Maybe we should ask just in the beginning and store the setting in
ctx['upg_enabled']. I don't think that anyone needs to switch UPG
status during migration process.
Martin
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 971 detect binary LDAP data
On 03/29/2012 12:20 AM, Rob Crittenden wrote:
I'm using a much narrower scope. I'm not trying to make it easy to
manage non-printable characters, just not blow things up if they exist.
Limiting to the XML-RPC supported set is for convenience, these are
unprintable characters in any context. This is just a two-fer.
Right. The XML set is a nice compromise when you want to define
“unprintable characters”.
Petr was right, I need to encode to unicode before doing this comparison
in order to compare invalid unicode characters so I moved that first.
I added a very basic unit test.
I suggest the attached additions to the test, to ensure the encoder uses
contains_non_printable as it should. (PEP8 nitpicks included)
If you're wondering where this data might come from, two ways are via AD
sync and migration.
Yes, the user will be left in a situation where they'll need to use
--setattr or ldapmodify to manage the data in the field. The UI doesn't
show the value at all but instead shows [object Object] (no errors in
console, not sure where this is coming from). It is possible to
highlight this and insert a new value though.
So basically, we don't allow non-printable characters in text fields.
When they're already there, we display weird data but don't blow up.
I believe that's fine, as long as it's documented.
--setattr won't work: the data won't make it through XML-RPC. (I get
Internal Server Error currently)
rob
--
Petr³
diff --git a/tests/test_ipalib/test_encoder.py b/tests/test_ipalib/test_encoder.py
index 78e4131..e37fb36 100644
--- a/tests/test_ipalib/test_encoder.py
+++ b/tests/test_ipalib/test_encoder.py
@@ -154,7 +154,9 @@ def test_non_printable(self):
o = self.cls()
for bad in [u'\x00', u'\x00 post', u'pre\x0b', u'pre \x00 post',
u'pre \x0e post', u'pre \uFFFE post', u'pre \x1b post']:
-assert(o.contains_non_printable(bad))
+assert o.contains_non_printable(bad)
+assert type(o.decode(bad.encode('utf-8'))) is str
for good in [u'\x32 post', u'pre\x0a', u'plain', u'pre \uFFFD post']:
-assert(o.contains_non_printable(good)) is False
+assert not o.contains_non_printable(good)
+assert type(o.decode(good.encode('utf-8'))) is unicode
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 971 detect binary LDAP data
On 29.3.2012 00:20, Rob Crittenden wrote: Jan Cholasta wrote: On 29.2.2012 15:45, Rob Crittenden wrote: Jan Cholasta wrote: On 28.2.2012 18:58, Rob Crittenden wrote: Jan Cholasta wrote: On 28.2.2012 18:02, Petr Viktorin wrote: On 02/28/2012 04:45 PM, Rob Crittenden wrote: Petr Viktorin wrote: On 02/28/2012 04:02 AM, Rob Crittenden wrote: Petr Viktorin wrote: On 02/27/2012 05:10 PM, Rob Crittenden wrote: Rob Crittenden wrote: Simo Sorce wrote: On Mon, 2012-02-27 at 09:44 -0500, Rob Crittenden wrote: We are pretty trusting that the data coming out of LDAP matches its schema but it is possible to stuff non-printable characters into most attributes. I've added a sanity checker to keep a value as a python str type (treated as binary internally). This will result in a base64 encoded blob be returned to the client. I don't like the idea of having arbitrary binary data where unicode strings are expected. It might cause some unexpected errors (I have a feeling that --addattr and/or --delattr and possibly some plugins might not handle this very well). Wouldn't it be better to just throw away the value if it's invalid and warn the user? This isn't for user input, it is for data stored in LDAP. User's are going to have no way to provide binary data to us unless they use the API themselves in which case they have to follow our rules. Well my point was that --addattr and --delattr cause an LDAP search for the given attribute and plugins might get the result of a LDAP search in their post_callback and I'm not sure if they can cope with binary data. It wouldn't be any different than if we had the value as a unicode. Let's see what happens if the mail attribute of a user contains invalid UTF-8 (ff 62 30 72 6b 65 64): $ ipa user-find jdoe -- 1 user matched -- User login: jdoe First name: John Last name: Doe Home directory: /home/jdoe Login shell: /bin/sh Email address: /2IwcmtlZA== UID: 526 GID: 526 Account disabled: False Password: False Kerberos keys available: False Number of entries returned 1 $ ipa user-mod jdoe --addattr mail=j...@example.com ipa: ERROR: an internal error has occurred The internal error is: Traceback (most recent call last): File /usr/lib/python2.7/site-packages/ipaserver/rpcserver.py, line 302, in wsgi_execute result = self.Command[name](*args, **options) File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 438, in __call__ ret = self.run(*args, **options) File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 696, in run return self.execute(*args, **options) File /usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py, line 1217, in execute ldap, dn, entry_attrs, attrs_list, *keys, **options File /usr/lib/python2.7/site-packages/ipalib/plugins/user.py, line 532, in pre_callback entry_attrs['mail'] = self.obj._normalize_email(entry_attrs['mail']) File /usr/lib/python2.7/site-packages/ipalib/plugins/user.py, line 338, in _normalize_email norm_email.append(m + u'@' + config['ipadefaultemaildomain'][0]) UnicodeDecodeError: 'utf8' codec can't decode byte 0xff in position 0: invalid start byte $ ipa user-mod jdoe --delattr mail=/2IwcmtlZA== ipa: ERROR: mail does not contain '/2IwcmtlZA==' $ ipa user-mod jdoe --delattr mail=`echo 'ff 62 30 72 6b 65 64' | xxd -p -r` ipa: ERROR: UnicodeDecodeError: 'utf8' codec can't decode byte 0xff in position 5: invalid start byte Traceback (most recent call last): File /usr/lib/python2.7/site-packages/ipalib/cli.py, line 1242, in run sys.exit(api.Backend.cli.run(argv)) File /usr/lib/python2.7/site-packages/ipalib/cli.py, line 1024, in run kw = self.parse(cmd, argv) File /usr/lib/python2.7/site-packages/ipalib/cli.py, line 1049, in parse return dict(self.parse_iter(cmd, kw)) File /usr/lib/python2.7/site-packages/ipalib/cli.py, line 1058, in parse_iter yield (key, self.Backend.textui.decode(value)) File /usr/lib/python2.7/site-packages/ipalib/cli.py, line 136, in decode return value.decode(encoding) File /usr/lib64/python2.7/encodings/utf_8.py, line 16, in decode return codecs.utf_8_decode(input, errors, True) UnicodeDecodeError: 'utf8' codec can't decode byte 0xff in position 5: invalid start byte ipa: ERROR: an internal error has occurred I'm sure there is a lot more places in the code where things will break when you feed them arbitrary data. We treat the python type str as binary data. Anything that is a str gets based64 encoded before json or xml-rpc transmission. The type unicode is considered a string and goes in the clear. We determine what this type should be not from the data but from the schema. This is a big assumption. Hopefully this answer's Petr's point as well. We decided long ago that str means Binary and unicode means String. It is a bit clumsy perhaps python handles it well. It will be more clear when we switch to Python 3.0 and we'll have bytes and str instead as types. Well, this is all super-obvious and I'm
Re: [Freeipa-devel] [PATCHES] 113-114 Facet expiration flag
On 03/27/2012 05:36 PM, Endi Sukma Dewata wrote: On 3/22/2012 12:50 PM, Petr Vobornik wrote: The effort was split to two patches. See patch descriptions. ACK on both. Nice job. See comments below. Pushed to master, ipa-2-2. See comment below. Notes: Case #7 (automatic: an open facet should automatically refresh itself when it expires) I don't want to implement because I think it can cause havoc ie: refresh when user is editing. For details page, automatically refreshing the page still makes sense to avoid overriding newer data with older information. For example you open a user details page to add an email address, but at the same time somebody else added another email address to same user. When you finally save your changes the other email address will be gone. I think there are several options: 1. Don't refresh if the page is dirty (i.e. user is editing the page). 2. Refresh unedited fields only. 3. Load the data even though it's being edited, compare with the cached data. If something's changed alert the user. The user can either revert the changes or continue editing. 4. Use addattr/delattr to modify multi-valued attributes. The chance of this happening is probably small, and the solution won't completely eliminate the risk either, so this is probably lower priority. For search page, there are 2 things that the page keeps in cache: the primary keys and the visible entry details. Currently when you change page it will refresh both, so periodically refreshing the page may not be that important. However ideally we shouldn't need to refresh the primary keys in all page changes because it could be long and most likely unchanged. In this case it makes sense to refresh the primary keys periodically. Probably separate ticket. I think options #1 and #2 doesn't solve the problem when user edits something for a very long time (went for a lunch...). #3 seems as a best solution because it covers single valued attrs too, compare to #4. Which is nice, because user can see what other user entered and may find it better :). Ideal would be to check if data changed before each update, but I think it isn't worth the effort. I closed the original ticket and moved this to separate ticket. I used your comment as a description. https://fedorahosted.org/freeipa/ticket/2591 Also I was thinking about splitting needs_update to two methods: needs_update and state_changed. State changed would compare current state with old state. It would be called from needs_update. This way we don't have to override needs_update and just define various state_changed for different facets. Feel free to refactor the methods if you think it's necessary. But before that try to rearrange the current implementations of needs_update() and minimize the amount of code that needs to be moved into state_changed(). Also I'm thinking about adding paging state comparison to search facet (the page should recognize the change itself ie when other facet redirects to certain page (bad example?)). What do you think? Yes, this would be needed if we decided to keep the primary keys for a longer time like described above. Changing the page should refresh the visible entry details only. -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 115 Reworked netgroup Web UI to allow setting user/host category
This patch is changing netgroup web ui to look more like hbac or sudo
rule UI. This change allows to define and display user category, host
category and external host.
The core of the change is changing member attributes (user, group, host,
hostgroup) to use rule_details_widget instead of separate association
facets. In host case it also allows to display and add external hosts.
https://fedorahosted.org/freeipa/ticket/2578
Note: compare to other plugins (HBAC, Sudo) netgroup plugins doesn't
have member attrs in takes_param therefore labels for columns have to be
explicitly set.
--
Petr Vobornik
From 2cfc983b882f7b86d82142f583ec3dca27617e34 Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Wed, 28 Mar 2012 17:53:17 +0200
Subject: [PATCH] Reworked netgroup Web UI to allow setting user/host category
This patch is changing netgroup web ui to look more like hbac or sudo rule UI. This change allows to define and display user category, host category and external host.
The core of the change is changing member attributes (user, group, host, hostgroup) to use rule_details_widget instead of separate association facets. In host case it allows to display and add external hosts.
https://fedorahosted.org/freeipa/ticket/2578
---
install/ui/netgroup.js | 273
install/ui/test/data/ipa_init.json | 13 ++-
ipalib/plugins/internal.py | 11 ++
3 files changed, 265 insertions(+), 32 deletions(-)
diff --git a/install/ui/netgroup.js b/install/ui/netgroup.js
index d54fdfd52eb943c3f35f65fd3e75ab994836ee12..05f9d0ddc9c6a35b3b63275d6137fd6bff74f3d3 100644
--- a/install/ui/netgroup.js
+++ b/install/ui/netgroup.js
@@ -22,7 +22,10 @@
/* REQUIRES: ipa.js, details.js, search.js, add.js, facet.js, entity.js */
-IPA.netgroup = {};
+IPA.netgroup = {
+remove_method_priority: IPA.config.default_priority - 1,
+enable_priority: IPA.config.default_priority + 1
+};
IPA.netgroup.entity = function(spec) {
@@ -31,42 +34,17 @@ IPA.netgroup.entity = function(spec) {
that.init = function() {
that.entity_init();
-that.builder.search_facet({
+that.builder.facet_groups(['settings', 'member', 'memberof']).
+search_facet({
columns: [
'cn',
'description'
]
}).
details_facet({
-sections: [
-{
-name: 'identity',
-fields: [
-'cn',
-{
-type: 'textarea',
-name: 'description'
-},
-'nisdomainname'
-]
-}
-]
-}).
-association_facet({
-name: 'memberhost_host',
-facet_group: 'member'
-}).
-association_facet({
-name: 'memberhost_hostgroup',
-facet_group: 'member'
-}).
-association_facet({
-name: 'memberuser_user',
-facet_group: 'member'
-}).
-association_facet({
-name: 'memberuser_group',
-facet_group: 'member'
+factory: IPA.netgroup.details_facet,
+entity: that,
+command_mode: 'info'
}).
association_facet({
name: 'memberof_netgroup',
@@ -87,4 +65,237 @@ IPA.netgroup.entity = function(spec) {
return that;
};
+IPA.netgroup.details_facet = function(spec) {
+
+var entity_name = spec.entity.name;
+
+//
+// Identity
+//
+
+spec.fields = [
+{
+name: 'cn',
+widget: 'identity.cn'
+},
+{
+type: 'textarea',
+name: 'description',
+widget: 'identity.description'
+},
+{
+name: 'nisdomainname',
+widget: 'identity.nisdomainname'
+}
+];
+
+spec.widgets = [
+{
+type: 'details_table_section',
+name: 'identity',
+label: IPA.messages.details.general,
+widgets: [
+{
+name: 'cn'
+},
+{
+type: 'textarea',
+name: 'description'
+},
+{
+name: 'nisdomainname',
+widget: 'general.nisdomainname'
+}
+]
+}
+];
+
+//
+// Users
+//
+
+spec.fields.push(
+{
+type: 'radio',
+name: 'usercategory',
+widget: 'user.rule.usercategory'
+},
+{
+type: 'rule_association_table',
+name: 'memberuser_user',
+widget: 'user.rule.memberuser_user',
+priority: IPA.netgroup.remove_method_priority
+},
+{
+type:
[Freeipa-devel] [PATCH] (master) Support case-insensitive searches for principals during TGS request processing
Hi,
Attached patch implements solution for
https://fedorahosted.org/freeipa/ticket/1577.
With the patch applied to master, FreeIPA will be more forgiving for service
principals requested with wrong character case. This is something
supported by Active Directory where principals for services are
case-insensitive and therefore HTTP/ or http/ point to the same service.
In Kerberos LDAP schema, unfortunately, both krbPrincipalName and
krbCanonicalName attributes are defined with exact match strategy,
therefore, making impossible case-insensitive filtering. The patch
solves this problem by introducing an attribute with case-insensitive
matching strategy. Since there are several ways to create principals, we
hook up at both FreeIPA management framework and KDC database plugin
levels to intercept and maintain principal changes.
We have decided only support case-insensitive searches for services
where this is important and required feature. Services always have
krbPrincipalName defined, and ipaKrbPrincipal object class will now be
applied in addition to existing ones, to provide ipaKrbPrincipalAlias
attribute (which is case-insensitive). Users will not get
case-insensitive searches by default, though it is possible to introduce
such feature to them as well by adding ipaKrbPrincipal class to the user
and taking care of creating/maintaining the alias attribute synchronized
with krbPrincipalName. Simo was originally against making
case-insensitive aliases for users, though.
Here is how it will look and act for services:
--
[root@m17 ~]# kvno cifs/M17.ipa.Local@IPA.LOCAL
cifs/M17.ipa.Local@IPA.LOCAL: kvno = 1
[root@m17 ~]# kvno CIFS/M17.ipa.Local@IPA.LOCAL
CIFS/M17.ipa.Local@IPA.LOCAL: kvno = 1
[root@m17 ~]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: admin@IPA.LOCAL
Valid starting ExpiresService principal
03/29/12 14:38:57 03/30/12 14:38:55 krbtgt/IPA.LOCAL@IPA.LOCAL
03/29/12 14:39:05 03/30/12 14:38:55 HTTP/m17.ipa.local@IPA.LOCAL
03/29/12 15:00:51 03/30/12 14:38:55 ldap/m17.ipa.local@IPA.LOCAL
03/29/12 15:08:02 03/30/12 14:38:55 krbtgt/IPA.LocAl@IPA.LOCAL
03/29/12 15:08:19 03/30/12 14:38:55 cifs/M17.ipa.Local@IPA.LOCAL
03/29/12 15:08:48 03/30/12 14:38:55 CIFS/M17.ipa.Local@IPA.LOCAL
--
Please note that case-insensitive realm search is still not supported,
even if you enable DNS resolution of realms and KDCs:
[root@m17 ~]# kvno cIfS/m17.ipa.local@ipa.LoCaL
kvno: Cannot find KDC for requested realm while getting credentials for
cIfS/m17.ipa.local@ipa.LoCaL
This is due to some krbtgt/realm@REALM searches performed in KDC without
allowing for principal aliases and therefore no chance to our
case-insensitive searches to kick in. Additional discussion is needed, I
think, if we want to support case-insensitive realms.
--
/ Alexander Bokovoy
From 7d0c8669df0da44c9056581bd29af3f0abec58d4 Mon Sep 17 00:00:00 2001
From: Alexander Bokovoy aboko...@redhat.com
Date: Mon, 26 Mar 2012 14:23:42 +0300
Subject: [PATCH 6/9] Perform case-insensitive searches for principals on TGS
requests
We want to always resolve TGS requests even if the user mistakenly sends a
request for a service ticket where the fqdn part contain upper case letters.
The actual implementation follows hints set by KDC. When AP_REQ is done, KDC
sets KRB5_FLAG_ALIAS_OK and we obey it when looking for principals on TGS
requests.
https://fedorahosted.org/freeipa/ticket/1577
---
daemons/ipa-kdb/ipa_kdb_principals.c | 73 --
install/share/61kerberos-ipav3.ldif |3 ++
install/share/Makefile.am|1 +
install/updates/10-60basev3.update |2 +
ipalib/plugins/service.py|7 +++-
ipaserver/install/dsinstance.py |1 +
6 files changed, 65 insertions(+), 22 deletions(-)
create mode 100644 install/share/61kerberos-ipav3.ldif
diff --git a/daemons/ipa-kdb/ipa_kdb_principals.c
b/daemons/ipa-kdb/ipa_kdb_principals.c
index 1432619..2e190a1 100644
--- a/daemons/ipa-kdb/ipa_kdb_principals.c
+++ b/daemons/ipa-kdb/ipa_kdb_principals.c
@@ -22,6 +22,16 @@
#include ipa_kdb.h
+/*
+ * During TGS request search by ipaKrbPrincipalName (case-insensitive)
+ * and krbPrincipalName (case-sensitive)
+ */
+#define PRINC_TGS_SEARCH_FILTER ((|(objectclass=krbprincipalaux) \
+(objectclass=krbprincipal) \
+(objectclass=ipakrbprincipal)) \
+(|(ipakrbprincipalalias=%s) \
+ (krbprincipalname=%s)))
+
#define PRINC_SEARCH_FILTER ((|(objectclass=krbprincipalaux) \
(objectclass=krbprincipal)) \
(krbprincipalname=%s))
@@ -29,6 +39,7 @@
static char *std_principal_attrs[] = {
krbPrincipalName,
krbCanonicalName,
+
Re: [Freeipa-devel] [PATCH] 0030 Allow multi-line CSV parameters
On 03/22/2012 09:40 AM, Petr Viktorin wrote: Feed individual lines of input into the CSV parser, and include all lines in the output. https://fedorahosted.org/freeipa/ticket/2402 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ACK -- Regards, Ondrej Hamada FreeIPA team jabber: oh...@jabbim.cz IRC: ohamada ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 971 detect binary LDAP data
On 03/29/2012 12:20 AM, Rob Crittenden wrote: Jan Cholasta wrote: On 29.2.2012 15:45, Rob Crittenden wrote: Jan Cholasta wrote: On 28.2.2012 18:58, Rob Crittenden wrote: Jan Cholasta wrote: On 28.2.2012 18:02, Petr Viktorin wrote: On 02/28/2012 04:45 PM, Rob Crittenden wrote: Petr Viktorin wrote: On 02/28/2012 04:02 AM, Rob Crittenden wrote: Petr Viktorin wrote: On 02/27/2012 05:10 PM, Rob Crittenden wrote: Rob Crittenden wrote: Simo Sorce wrote: On Mon, 2012-02-27 at 09:44 -0500, Rob Crittenden wrote: We are pretty trusting that the data coming out of LDAP matches its schema but it is possible to stuff non-printable characters into most attributes. I've added a sanity checker to keep a value as a python str type (treated as binary internally). This will result in a base64 encoded blob be returned to the client. I don't like the idea of having arbitrary binary data where unicode strings are expected. It might cause some unexpected errors (I have a feeling that --addattr and/or --delattr and possibly some plugins might not handle this very well). Wouldn't it be better to just throw away the value if it's invalid and warn the user? This isn't for user input, it is for data stored in LDAP. User's are going to have no way to provide binary data to us unless they use the API themselves in which case they have to follow our rules. Well my point was that --addattr and --delattr cause an LDAP search for the given attribute and plugins might get the result of a LDAP search in their post_callback and I'm not sure if they can cope with binary data. It wouldn't be any different than if we had the value as a unicode. Let's see what happens if the mail attribute of a user contains invalid UTF-8 (ff 62 30 72 6b 65 64): $ ipa user-find jdoe -- 1 user matched -- User login: jdoe First name: John Last name: Doe Home directory: /home/jdoe Login shell: /bin/sh Email address: /2IwcmtlZA== UID: 526 GID: 526 Account disabled: False Password: False Kerberos keys available: False Number of entries returned 1 $ ipa user-mod jdoe --addattr mail=j...@example.com ipa: ERROR: an internal error has occurred The internal error is: Traceback (most recent call last): File /usr/lib/python2.7/site-packages/ipaserver/rpcserver.py, line 302, in wsgi_execute result = self.Command[name](*args, **options) File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 438, in __call__ ret = self.run(*args, **options) File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 696, in run return self.execute(*args, **options) File /usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py, line 1217, in execute ldap, dn, entry_attrs, attrs_list, *keys, **options File /usr/lib/python2.7/site-packages/ipalib/plugins/user.py, line 532, in pre_callback entry_attrs['mail'] = self.obj._normalize_email(entry_attrs['mail']) File /usr/lib/python2.7/site-packages/ipalib/plugins/user.py, line 338, in _normalize_email norm_email.append(m + u'@' + config['ipadefaultemaildomain'][0]) UnicodeDecodeError: 'utf8' codec can't decode byte 0xff in position 0: invalid start byte $ ipa user-mod jdoe --delattr mail=/2IwcmtlZA== ipa: ERROR: mail does not contain '/2IwcmtlZA==' $ ipa user-mod jdoe --delattr mail=`echo 'ff 62 30 72 6b 65 64' | xxd -p -r` ipa: ERROR: UnicodeDecodeError: 'utf8' codec can't decode byte 0xff in position 5: invalid start byte Traceback (most recent call last): File /usr/lib/python2.7/site-packages/ipalib/cli.py, line 1242, in run sys.exit(api.Backend.cli.run(argv)) File /usr/lib/python2.7/site-packages/ipalib/cli.py, line 1024, in run kw = self.parse(cmd, argv) File /usr/lib/python2.7/site-packages/ipalib/cli.py, line 1049, in parse return dict(self.parse_iter(cmd, kw)) File /usr/lib/python2.7/site-packages/ipalib/cli.py, line 1058, in parse_iter yield (key, self.Backend.textui.decode(value)) File /usr/lib/python2.7/site-packages/ipalib/cli.py, line 136, in decode return value.decode(encoding) File /usr/lib64/python2.7/encodings/utf_8.py, line 16, in decode return codecs.utf_8_decode(input, errors, True) UnicodeDecodeError: 'utf8' codec can't decode byte 0xff in position 5: invalid start byte ipa: ERROR: an internal error has occurred I'm sure there is a lot more places in the code where things will break when you feed them arbitrary data. We treat the python type str as binary data. Anything that is a str gets based64 encoded before json or xml-rpc transmission. The type unicode is considered a string and goes in the clear. We determine what this type should be not from the data but from the schema. This is a big assumption. Hopefully this answer's Petr's point as well. We decided long ago that str means Binary and unicode means String. It is a bit clumsy perhaps python handles it well. It will be more clear when we switch to Python 3.0 and we'll have bytes and str instead as types. Well, this is all super-obvious and
Re: [Freeipa-devel] [PATCH] 993 disable UPG for migration
On Thu, 2012-03-29 at 11:27 -0400, Rob Crittenden wrote: This patch is much better and covers my previous concerns. I just find an issue with UPG. It is not created for non-posix users when UPGs are enabled: # echo Secret123 | ipa migrate-ds ldap://ldap.example.com --with-compat --base-dn=dc=greyoak,dc=com --- migrate-ds: --- Migrated: user: darcee_leeson, ayaz_kreiger, mnonposix, mollee_weisenberg group: ipagroup Failed user: Failed group: -- Passwords have been migrated in pre-hashed format. IPA is unable to generate Kerberos keys unless provided with clear text passwords. All migrated users need to login at https://your.domain/ipa/migration/ before they can use their Kerberos accounts. # ipa user-show mnonposix User login: mnonposix First name: Mister Last name: Nonposix Home directory: /home/mnonposix Login shell: /bin/sh UID: 328000195 GID: 328000195 Org. Unit: Product Testing Job Title: Test User Account disabled: False Password: True Member of groups: ipausers Kerberos keys available: False # ipa group-show mnonposix ipa: ERROR: mnonposix: group not found Yes, I was always disabling UPG. I now allow it when migrating a non-POSIX user. by this you mean you are now transforming a non-POSIX user into a POSIX user ? What happen if someone has both POSIX and non-POSIX users on a server, do you mix them ? I have the feeling we need an explicit flag to convert a non-POSIX user - POSIX user, because that doesn't look to me like something people want to do by default. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0030 Allow multi-line CSV parameters
Ondrej Hamada wrote: On 03/22/2012 09:40 AM, Petr Viktorin wrote: Feed individual lines of input into the CSV parser, and include all lines in the output. https://fedorahosted.org/freeipa/ticket/2402 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ACK pushed to master and ipa-2-2 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 993 disable UPG for migration
Simo Sorce wrote: On Thu, 2012-03-29 at 11:27 -0400, Rob Crittenden wrote: This patch is much better and covers my previous concerns. I just find an issue with UPG. It is not created for non-posix users when UPGs are enabled: # echo Secret123 | ipa migrate-ds ldap://ldap.example.com --with-compat --base-dn=dc=greyoak,dc=com --- migrate-ds: --- Migrated: user: darcee_leeson, ayaz_kreiger, mnonposix, mollee_weisenberg group: ipagroup Failed user: Failed group: -- Passwords have been migrated in pre-hashed format. IPA is unable to generate Kerberos keys unless provided with clear text passwords. All migrated users need to login at https://your.domain/ipa/migration/ before they can use their Kerberos accounts. # ipa user-show mnonposix User login: mnonposix First name: Mister Last name: Nonposix Home directory: /home/mnonposix Login shell: /bin/sh UID: 328000195 GID: 328000195 Org. Unit: Product Testing Job Title: Test User Account disabled: False Password: True Member of groups: ipausers Kerberos keys available: False # ipa group-show mnonposix ipa: ERROR: mnonposix: group not found Yes, I was always disabling UPG. I now allow it when migrating a non-POSIX user. by this you mean you are now transforming a non-POSIX user into a POSIX user ? What happen if someone has both POSIX and non-POSIX users on a server, do you mix them ? The existing POSIX users are migrated as-is, non-POSIX users become full IPA users with UPG. I have the feeling we need an explicit flag to convert a non-POSIX user - POSIX user, because that doesn't look to me like something people want to do by default. What makes you say that? rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 993 disable UPG for migration
On Thu, 2012-03-29 at 15:25 -0400, Rob Crittenden wrote: Simo Sorce wrote: On Thu, 2012-03-29 at 11:27 -0400, Rob Crittenden wrote: This patch is much better and covers my previous concerns. I just find an issue with UPG. It is not created for non-posix users when UPGs are enabled: # echo Secret123 | ipa migrate-ds ldap://ldap.example.com --with-compat --base-dn=dc=greyoak,dc=com --- migrate-ds: --- Migrated: user: darcee_leeson, ayaz_kreiger, mnonposix, mollee_weisenberg group: ipagroup Failed user: Failed group: -- Passwords have been migrated in pre-hashed format. IPA is unable to generate Kerberos keys unless provided with clear text passwords. All migrated users need to login at https://your.domain/ipa/migration/ before they can use their Kerberos accounts. # ipa user-show mnonposix User login: mnonposix First name: Mister Last name: Nonposix Home directory: /home/mnonposix Login shell: /bin/sh UID: 328000195 GID: 328000195 Org. Unit: Product Testing Job Title: Test User Account disabled: False Password: True Member of groups: ipausers Kerberos keys available: False # ipa group-show mnonposix ipa: ERROR: mnonposix: group not found Yes, I was always disabling UPG. I now allow it when migrating a non-POSIX user. by this you mean you are now transforming a non-POSIX user into a POSIX user ? What happen if someone has both POSIX and non-POSIX users on a server, do you mix them ? The existing POSIX users are migrated as-is, non-POSIX users become full IPA users with UPG. I have the feeling we need an explicit flag to convert a non-POSIX user - POSIX user, because that doesn't look to me like something people want to do by default. What makes you say that? Well if I had non-POSIX users in my directory they would be some sort of addressbook, and I certainly wouldn't want them converted into posix users in freeipa. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 238 Improve automount indirect map error message
Martin Kosek wrote: When user does not pass a name of parent map in automountmap-add-indirect command, auto.master is used as a default. However, when auto.master does not exist in a given location, we raise NotFound error with a name of a location instead of a name of the missing automount map. https://fedorahosted.org/freeipa/ticket/2387 ACK, pushed to master and ipa-2-2 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0032 Move DNS test skipping to class setup
Petr Viktorin wrote: Currently, each DNS test case first checks if DNS is configured by creating and deleting a test zone. This takes quite a lot of time. This patch moves the check to the setUpClass method, so the check is only done once for all the tests. On my VM, this makes the DNS plugin tests 50% faster, saving about half a minute for each test run. This fails if the test XML-RPC server is not running. While working on that issue I found a few other places that weren't handling this as well. Here is my working patch on top of yours. rob diff --git a/tests/test_cmdline/test_cli.py b/tests/test_cmdline/test_cli.py index 889aae4..7e40cf0 100644 --- a/tests/test_cmdline/test_cli.py +++ b/tests/test_cmdline/test_cli.py @@ -26,7 +26,11 @@ class TestCLIParsing(object): Run a command on the server if not api.Backend.xmlclient.isconnected(): api.Backend.xmlclient.connect(fallback=False) -api.Command[command_name](**kw) +try: +api.Command[command_name](**kw) +except errors.NetworkError: +raise nose.SkipTest( +'%r: Server not available: %r' % (self.__module__, api.env.xmlr pc_uri)) @contextlib.contextmanager def fake_stdin(self, string_in): diff --git a/tests/test_xmlrpc/test_dns_plugin.py b/tests/test_xmlrpc/test_dns_p lugin.py index 911c773..2d7a6ea 100644 --- a/tests/test_xmlrpc/test_dns_plugin.py +++ b/tests/test_xmlrpc/test_dns_plugin.py @@ -49,6 +49,10 @@ class test_dns(Declarative): @classmethod def setUpClass(cls): +if not api.Backend.xmlclient.isconnected(): +raise nose.SkipTest( +'%r: Server not available: %r' % (cls.__module__, api.env.xmlrp c_uri)) + try: api.Command['dnszone_add'](dnszone1, idnssoamname = dnszone1_mname, diff --git a/tests/test_xmlrpc/xmlrpc_test.py b/tests/test_xmlrpc/xmlrpc_test.py index a7cfb11..c0a43ff 100644 --- a/tests/test_xmlrpc/xmlrpc_test.py +++ b/tests/test_xmlrpc/xmlrpc_test.py @@ -130,6 +130,13 @@ class XMLRPC_test(object): if not api.Backend.xmlclient.isconnected(): api.Backend.xmlclient.connect(fallback=False) +@classmethod +def setUpClass(cls): +if not server_available: +raise nose.SkipTest( +'%r: Server not available: %r' % (cls.__module__, api.env.xmlrp c_uri) +) + def tearDown(self): nose tear-down fixture. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] (master) Support case-insensitive searches for principals during TGS request processing
On Thu, 2012-03-29 at 16:30 +0300, Alexander Bokovoy wrote: This is due to some krbtgt/realm@REALM searches performed in KDC without allowing for principal aliases and therefore no chance to our case-insensitive searches to kick in. Additional discussion is needed, I think, if we want to support case-insensitive realms. I do not think we want to support case-insensitive realm lookups just yet. So what you have now seem sufficient to me. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0029 Check expected error messages in tests
Petr Viktorin wrote: On 03/26/2012 09:49 PM, Rob Crittenden wrote: Petr Viktorin wrote: On 03/20/2012 01:39 PM, Petr Viktorin wrote: This patch adds checking error messages, not just types, to the XML-RPC tests. The checking is still somewhat hackish, since XML-RPC doesn't give us structured error info, but it should protect against regressions on issues like whether we put name or cli_name in a ValidationError. https://fedorahosted.org/freeipa/ticket/2549 Updated and rebased to current master. NACK automember wrongly was testing for non-existent users rather than automember rules but those should still be tested IMHO, perhaps with both types. There is also some inconsistency. In host you use substitution to set the hostname in the error: '%s: host not found' % fqdn1 but in others (group, hostgroup for example) the name is hardcoded. I also noticed that some reasons are unicode and others are not. rob Added tests for automember, made all the reasons unicode, using substitutions when variables are involved. The patch still only updates tests that didn't pass the error message check. I'm seeing three failures that I think are due to recently pushed patches. Otherwise it looks good. rob == FAIL: test_netgroup[1]: netgroup_mod: Try to update non-existent u'netgroup1' -- Traceback (most recent call last): File /usr/lib/python2.7/site-packages/nose/case.py, line 187, in runTest self.test(*self.arg) File /home/rcrit/redhat/freeipa-beta1/tests/test_xmlrpc/xmlrpc_test.py, line 247, in lambda func = lambda: self.check(nice, **test) File /home/rcrit/redhat/freeipa-beta1/tests/test_xmlrpc/xmlrpc_test.py, line 260, in check self.check_exception(nice, cmd, args, options, expected) File /home/rcrit/redhat/freeipa-beta1/tests/test_xmlrpc/xmlrpc_test.py, line 284, in check_exception assert_deepequal(expected.strerror, e.strerror) File /home/rcrit/redhat/freeipa-beta1/tests/util.py, line 328, in assert_deepequal VALUE % (doc, expected, got, stack) AssertionError: assert_deepequal: expected != got. expected = u'netgroup1: netgroup not found' got = u'no such entry' path = () == FAIL: test_netgroup[4]: netgroup_add: Test an invalid nisdomain1 name u'domain1,domain2' -- Traceback (most recent call last): File /usr/lib/python2.7/site-packages/nose/case.py, line 187, in runTest self.test(*self.arg) File /home/rcrit/redhat/freeipa-beta1/tests/test_xmlrpc/xmlrpc_test.py, line 247, in lambda func = lambda: self.check(nice, **test) File /home/rcrit/redhat/freeipa-beta1/tests/test_xmlrpc/xmlrpc_test.py, line 260, in check self.check_exception(nice, cmd, args, options, expected) File /home/rcrit/redhat/freeipa-beta1/tests/test_xmlrpc/xmlrpc_test.py, line 284, in check_exception assert_deepequal(expected.strerror, e.strerror) File /home/rcrit/redhat/freeipa-beta1/tests/util.py, line 328, in assert_deepequal VALUE % (doc, expected, got, stack) AssertionError: assert_deepequal: expected != got. expected = uinvalid 'nisdomainname': may only include letters, numbers, _, - and . got = uinvalid 'nisdomain': may only include letters, numbers, _, -, and . path = () == FAIL: test_netgroup[5]: netgroup_add: Test an invalid nisdomain2 name u'+invalidnisdomain' -- Traceback (most recent call last): File /usr/lib/python2.7/site-packages/nose/case.py, line 187, in runTest self.test(*self.arg) File /home/rcrit/redhat/freeipa-beta1/tests/test_xmlrpc/xmlrpc_test.py, line 247, in lambda func = lambda: self.check(nice, **test) File /home/rcrit/redhat/freeipa-beta1/tests/test_xmlrpc/xmlrpc_test.py, line 260, in check self.check_exception(nice, cmd, args, options, expected) File /home/rcrit/redhat/freeipa-beta1/tests/test_xmlrpc/xmlrpc_test.py, line 284, in check_exception assert_deepequal(expected.strerror, e.strerror) File /home/rcrit/redhat/freeipa-beta1/tests/util.py, line 328, in assert_deepequal VALUE % (doc, expected, got, stack) AssertionError: assert_deepequal: expected != got. expected = uinvalid 'nisdomainname': may only include letters, numbers, _, - and . got = uinvalid 'nisdomain': may only include letters, numbers, _, -, and . path = () ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 999 fix failure count interval in kdb backend
The wrong attribute name was being requested for the failure count
interval so it was never being applied. This caused the failure count to
never be reset with time.
rob
From d6595ab23c2ed861076e00036408f1926f5ee842 Mon Sep 17 00:00:00 2001
From: Rob Crittenden rcrit...@redhat.com
Date: Thu, 29 Mar 2012 17:40:11 -0400
Subject: [PATCH] Fix failure count interval attribute name in query for
password policy.
This was causing the failure count interval to not be applied so
the failure count was never reset to 0.
https://fedorahosted.org/freeipa/ticket/2540
---
daemons/ipa-kdb/ipa_kdb_pwdpolicy.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/daemons/ipa-kdb/ipa_kdb_pwdpolicy.c b/daemons/ipa-kdb/ipa_kdb_pwdpolicy.c
index a54380815bc91df6856d1a62fc61b54471b5ce5b..6f3992be69ccec565079315c0a2c7259a8c3ffa3 100644
--- a/daemons/ipa-kdb/ipa_kdb_pwdpolicy.c
+++ b/daemons/ipa-kdb/ipa_kdb_pwdpolicy.c
@@ -32,7 +32,7 @@ char *std_pwdpolicy_attrs[] = {
krbpwdminlength,
krbpwdhistorylength,
krbpwdmaxfailure,
-krbpwdmaxfailurecountinterval,
+krbpwdfailurecountinterval,
krbpwdlockoutduration,
NULL
--
1.7.6
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH 69] Use indexed format specifiers in i18n strings
Translators need to reorder messages to suit the needs of the target
language. The conventional positional format specifiers (e.g. %s %d)
do not permit reordering because their order is tied to the ordering
of the arguments to the printf function. The fix is to use indexed
format specifiers.
--
John Dennis jden...@redhat.com
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
From 02fbab6602c545f0eb3dc4a455955f904d5b53fc Mon Sep 17 00:00:00 2001
From: John Dennis jden...@redhat.com
Date: Thu, 29 Mar 2012 21:34:19 -0400
Subject: [PATCH 69] Use indexed format specifiers in i18n strings
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Translators need to reorder messages to suit the needs of the target
language. The conventional positional format specifiers (e.g. %s %d)
do not permit reordering because their order is tied to the ordering
of the arguments to the printf function. The fix is to use indexed
format specifiers.
---
ipa-client/ipa-getkeytab.c | 12 ++--
ipa-client/ipa-join.c |6 +++---
ipa-client/ipa-rmkeytab.c | 14 +++---
3 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/ipa-client/ipa-getkeytab.c b/ipa-client/ipa-getkeytab.c
index 05e57bb..7d7b971 100644
--- a/ipa-client/ipa-getkeytab.c
+++ b/ipa-client/ipa-getkeytab.c
@@ -82,7 +82,7 @@ static int ldap_sasl_interact(LDAP *ld, unsigned flags, void *priv_data, void *s
krberr = krb5_init_context(krbctx);
if (krberr) {
-fprintf(stderr, _(Kerberos context initialization failed: %s (%d)\n),
+fprintf(stderr, _(Kerberos context initialization failed: %1$s (%2$d)\n),
error_message(krberr), krberr);
in-result = NULL;
in-len = 0;
@@ -93,7 +93,7 @@ static int ldap_sasl_interact(LDAP *ld, unsigned flags, void *priv_data, void *s
krberr = krb5_unparse_name(krbctx, princ, outname);
if (krberr) {
-fprintf(stderr, _(Unable to parse principal: %s (%d)\n),
+fprintf(stderr, _(Unable to parse principal: %1$s (%2$d)\n),
error_message(krberr), krberr);
in-result = NULL;
in-len = 0;
@@ -511,7 +511,7 @@ static int ipa_ldap_init(LDAP ** ld, const char * scheme, const char * servernam
{
char* url = NULL;
int url_len = snprintf(url,0,%s://%s:%d,scheme,servername,port) +1;
-
+
url = (char *)malloc (url_len);
if (!url){
fprintf(stderr, _(Out of memory \n));
@@ -570,7 +570,7 @@ static int ldap_set_keytab(krb5_context krbctx,
if (ldap_set_option(NULL, LDAP_OPT_X_TLS_CACERTFILE, /etc/ipa/ca.crt) != LDAP_OPT_SUCCESS) {
goto error_out;
}
-
+
if ( ipa_ldap_init(ld, ldaps,servername, 636) != LDAP_SUCCESS){
goto error_out;
}
@@ -579,7 +579,7 @@ static int ldap_set_keytab(krb5_context krbctx,
}
} else {
if (ipa_ldap_init(ld, ldap,servername, 389) != LDAP_SUCCESS){
- goto error_out;
+ goto error_out;
}
}
@@ -731,7 +731,7 @@ static int ldap_set_keytab(krb5_context krbctx,
keys-ksdata[i].enctype);
} else {
fprintf(stderr, _(Failed to retrieve
- encryption type %s (#%d)\n),
+ encryption type %1$s (#%2$d)\n),
enc, keys-ksdata[i].enctype);
}
} else {
diff --git a/ipa-client/ipa-join.c b/ipa-client/ipa-join.c
index bc46e93..4c37113 100644
--- a/ipa-client/ipa-join.c
+++ b/ipa-client/ipa-join.c
@@ -108,7 +108,7 @@ static int check_perms(const char *keytab)
break;
default:
fprintf(stderr,
-_(access() on %s failed: errno = %d\n),
+_(access() on %1$s failed: errno = %2$d\n),
keytab, errno);
break;
}
@@ -334,7 +334,7 @@ get_root_dn(const char *ipaserver, char **ldap_base)
NULL, NULL, NULL, 0, res);
if (ret != LDAP_SUCCESS) {
-fprintf(stderr, _(Search for %s on rootdse failed with error %d),
+fprintf(stderr, _(Search for %1$s on rootdse failed with error %2$d\n),
root_attrs[0], ret);
rval = 14;
goto done;
@@ -801,7 +801,7 @@ unenroll_host(const char *server, const char *hostname, const char *ktname, int
krberr = krb5_parse_name(krbctx, principal, princ);
if (krberr != 0) {
if (!quiet)
-fprintf(stderr, _(Error parsing \%s\: %s.\n),
+fprintf(stderr, _(Error parsing \%1$s\: %2$s.\n),
principal, error_message(krberr));
return krberr;
}
diff --git a/ipa-client/ipa-rmkeytab.c b/ipa-client/ipa-rmkeytab.c
index a6a68ea..a2a292e 100644
--- a/ipa-client/ipa-rmkeytab.c
+++ b/ipa-client/ipa-rmkeytab.c
@@ -42,7 +42,7 @@ remove_principal(krb5_context context, krb5_keytab ktid, const char *principal,
if (krberr) {
fprintf(stderr, _(Unable to parse principal name\n));
if (debug)
-fprintf(stderr, _(krb5_parse_name %d: %s\n),
+
