Bug 1261211 - ipa automount importer fails to import indirect maps having same key and different mount point.
ipa automount importer fails to import indirect maps having same key and diff...
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ipa (Show other bugs)
7.1
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: IPA Maintainers
Namita Soman
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-08 19:07 EDT by German Parente
Modified: 2015-09-11 06:51 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-09-11 06:51:29 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description German Parente 2015-09-08 19:07:49 EDT
Description of problem:

Customer is trying to import maps using the automountlocation-import command and it fails with duplicate keys.

Version-Release number of selected component (if applicable): ipa on 7.1

How reproducible: always.


Steps to Reproduce:

Define these two different maps:

[root@idm-replica ~]# cat auto.test1 
test    ipa.example.com:/test
[root@idm-replica ~]# 

[root@idm-replica ~]# cat auto.test2 
test     idm-replica.example.org:/test

import them by doing:

ipa automountlocation-import default ./auto.test1 --continue
Imported maps:
Added ipa.example.com:/test

Imported keys:
Added test to auto.master

-------------------------

ipa automountlocation-import default ./auto.test2 --continue
Imported maps:
Added idm-replica.example.org:/test

Imported keys:


Duplicate keys skipped:
Skipped test

------------------------

The second import fails to import key. Because it's also added to auto.master.

If we see the objects created in audit logs, the dn is not including the map name (auto.testX)  not the mount point. So, we have this entry:

----------------------------------------------------
time: 20150908175129
dn: description=test,automountmapname=auto.master,cn=default,cn=automount,dc=example,dc=org
changetype: add
objectClass: automount
objectClass: top
automountKey: test
automountInformation: ipa.example.com:/test
description: test
creatorsName: uid=admin,cn=users,cn=accounts,dc=example,dc=org
modifiersName: uid=admin,cn=users,cn=accounts,dc=example,dc=org
createTimestamp: 20150908155129Z
modifyTimestamp: 20150908155129Z
----------------------------------------------------

At importing the second map, the dn will be exactly the same and that's why it fails. 

Probably importer should not use by default auto.master as automountmapname.


Actual results:

map is not imported.

Expected results:

Should be imported.

Additional info:
Comment 2 Petr Vobornik 2015-09-09 13:34:39 EDT
In the output of second command is stated that the map was imported:

Added idm-replica.example.org:/test

A failure of adding of a duplicate key to a auto.master map didn't prevent that (because --continue was used).

But I don't see any attempt to add keys from a map file defined in the master file.
Comment 3 Rob Crittenden 2015-09-09 13:44:55 EDT
I think the problem is that this expects that the import be done from an auto.master which utilizes these two maps, auto.test and auto.test1, and not a discrete map file containing a single map.
Comment 4 German Parente 2015-09-09 15:00:26 EDT
At the end, the result is that what customer wants to describe is not possible by importing the automount maps.

The map is created but as the second key is not imported, the specification of the map will not be exactly what customer has currently in its maps.
Comment 5 Rob Crittenden 2015-09-09 15:04:26 EDT
If they use their file-based auto.master it should work better. It might look something like:

/test    /etc/auto.test
/test1   /etc/auto.test1

I don't dispute that the import is quite a bit misleading and possibly broken when used with a leaf map.
Comment 6 Petr Vobornik 2015-09-10 11:08:48 EDT
Is there anything to fix? Should we close this bz?
Comment 7 German Parente 2015-09-10 12:47:14 EDT
I would have said the importer. But if you consider this is not a bug, feel free to close it.

Regarding comment 5, the customer issue is different. He has same key, indirect, that is mounted differently depending the site.

Example is

test      server1:/space/test

and 

test      server2:/space/test

If you try to specify this in ipa if fails because ipa is building the DN using indirect key + auto,master. So the dn will be duplicate and the import will fail. But the customer specification is valid one, though.
Comment 8 Rob Crittenden 2015-09-10 13:38:33 EDT
In this case site == location which means they cannot live within the same auto.master. They need to have a separate location for each "site" where keys would be duplicated.
Comment 9 German Parente 2015-09-10 13:49:04 EDT
Thanks and sorry for my ignorance. I guess I should specify it like this ?


[root@idm-replica ~]# ipa automountlocation-add site1
--------------------------------
Added automount location "site1"
--------------------------------
  Location: site1
[root@idm-replica ~]# ipa automountlocation-add site2
--------------------------------
Added automount location "site2"
--------------------------------

ipa automountlocation-import site1 auto.test1 
Imported maps:
Added ipa.example.com:/test

Imported keys:
Added test to auto.master

[root@idm-replica ~]# ipa automountlocation-import site2 auto.test2
Imported maps:
Added idm-replica.example.org:/test

Imported keys:
Added test to auto.master

I think we can close this bug, then. Sorry for the noise.
Comment 10 Petr Vobornik 2015-09-11 06:51:29 EDT
closing according to comment 9

Note You need to log in before you can comment on or make changes to this bug.