Re: [Freeipa-users] Doubt on FreeIPA LDAP extensibility
On Sun, 2012-03-18 at 13:59 +0100, Marco Pizzoli wrote: Hi Simo, On Sat, Mar 17, 2012 at 7:16 PM, Simo Sorce s...@redhat.com wrote: On Sat, 2012-03-17 at 11:12 +0100, Marco Pizzoli wrote: Hi guys, I extended my set of LDAP objectClasses associated to users by adding my new objectClass to my cn=ipaConfig LDAP entry, the ipaUserObjectClasses attribute. Then, I created a new user with the web ui and I see the new objectClass associated with that user, but as structural instead of auxiliary. I don't know why, could you help me? Same thing happened for my groups. I added 3 objectClasses and now I see all of them as structural. I would understand an answer: all objectClasses eventually result as structural, but so why, for example, the ipaObject is still an auxiliary objectClass? The objectClass type depends on the schema. It is not something that changes after you assign it to an object. Yes, your answer surely does make sense. My question was triggered by the fact that, AFAICS, not all objectClasses are structural as well. In fact I can see that, for my group object, the objectClass ipaobject has been defined as auxiliary, while others structural. For users, I see that *only my objectClass* is defined as structural. All others as auxiliary. In attachment you can see 2 images that immediately represent what I'm trying to explain. If this was the intended behaviour, I would be really interested in knowing what is the rationale behind this. Only curiousity, as usual :-) Objectclasses have no structureal/auxiliary attribute in an object, it's your ldap browser that is returning the labeling by (I guess ) searching the schema. I guess your object is getting it wrong, or the schema you defined in 389ds has these classes marked structural. search the schema with your browser and see how it identify these classes ? I see you also opened a bug, but it makes little sense to me. I will close it as invalid for now, unless there is evidence 389ds returns the wrong type from the schema tree. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Problem in ipa migrate-ds procedure
On Sun, 2012-03-18 at 18:33 +0100, Marco Pizzoli wrote: On Sun, Mar 18, 2012 at 5:49 PM, Dmitri Pal d...@redhat.com wrote: On 03/17/2012 07:36 AM, Marco Pizzoli wrote: Hi guys, I'm trying to migrate my ldap user base to freeipa. I'm using the last Release Candidate. I already changed ipa config-mod --enable-migration=TRUE This is what I have: ipa -v migrate-ds --bind-dn=cn=manager,dc=mydc1,dc=mydc2.it --user-container=ou=people,dc=mydc1,dc=mydc2.it --user-objectclass=inetOrgPerson --group-container=ou=groups,dc=mydc1,dc=mydc2.it --group-objectclass=posixGroup --base-dn=dc=mydc1,dc=mydc2.it --with-compat ldap://ldap01 ipa: INFO: trying https://freeipa01.unix.mydomain.it/ipa/xml Password: ipa: INFO: Forwarding 'migrate_ds' to server u'http://freeipa01.unix.mydomain.it/ipa/xml' ipa: ERROR: Container for group not found at ou=groups,dc=mydc1,dc=mydc2.it I looked at my ldap server logs and I found out that the search executed has scope=1. Actually both for users and groups. This is a problem for me, in having a lot of subtrees (ou) in which my users and groups are. Is there a way to manage this? Thanks in advance Marco P.s. As a side note, I suppose there's a typo in the verbose message I obtain in my output: ipa: INFO: Forwarding 'migrate_ds' to server u'http://freeipa01.unix.mydomain.it/ipa/xml' Please open tickets for both issues. Done: https://fedorahosted.org/freeipa/ticket/2547 https://fedorahosted.org/freeipa/ticket/2546 Do you have a hint on how to manage to do this import in the meantime? Every manual step is ok for me. Maybe you can try performing a new migration for each of the subtrees you have in your source tree, assuming it is a reasonable number, by reconfiguring the migrate-ds bases between each run. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Doubt on FreeIPA LDAP extensibility
On Mon, Mar 19, 2012 at 1:15 PM, Simo Sorce s...@redhat.com wrote: On Sun, 2012-03-18 at 13:59 +0100, Marco Pizzoli wrote: Hi Simo, On Sat, Mar 17, 2012 at 7:16 PM, Simo Sorce s...@redhat.com wrote: On Sat, 2012-03-17 at 11:12 +0100, Marco Pizzoli wrote: Hi guys, I extended my set of LDAP objectClasses associated to users by adding my new objectClass to my cn=ipaConfig LDAP entry, the ipaUserObjectClasses attribute. Then, I created a new user with the web ui and I see the new objectClass associated with that user, but as structural instead of auxiliary. I don't know why, could you help me? Same thing happened for my groups. I added 3 objectClasses and now I see all of them as structural. I would understand an answer: all objectClasses eventually result as structural, but so why, for example, the ipaObject is still an auxiliary objectClass? The objectClass type depends on the schema. It is not something that changes after you assign it to an object. Yes, your answer surely does make sense. My question was triggered by the fact that, AFAICS, not all objectClasses are structural as well. In fact I can see that, for my group object, the objectClass ipaobject has been defined as auxiliary, while others structural. For users, I see that *only my objectClass* is defined as structural. All others as auxiliary. In attachment you can see 2 images that immediately represent what I'm trying to explain. If this was the intended behaviour, I would be really interested in knowing what is the rationale behind this. Only curiousity, as usual :-) Objectclasses have no structureal/auxiliary attribute in an object, it's your ldap browser that is returning the labeling by (I guess ) searching the schema. Exact. I admit I have not been so clear in my explanation. I guess your object is getting it wrong, or the schema you defined in 389ds has these classes marked structural. search the schema with your browser and see how it identify these classes ? In attachment. You can find only one, but all of them are equivalent from this point. They are indeed seen as structural, even if my added schema file declare them as auxiliary. I see you also opened a bug, but it makes little sense to me. I will close it as invalid for now, unless there is evidence 389ds returns the wrong type from the schema tree. Ok, I agree. Thanks as usual Marco Simo. -- Simo Sorce * Red Hat, Inc * New York attachment: GroupsAttribute_ObjectClass.PNG___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Problem in ipa migrate-ds procedure
On Mon, Mar 19, 2012 at 1:43 PM, Simo Sorce s...@redhat.com wrote: On Sun, 2012-03-18 at 18:33 +0100, Marco Pizzoli wrote: On Sun, Mar 18, 2012 at 5:49 PM, Dmitri Pal d...@redhat.com wrote: On 03/17/2012 07:36 AM, Marco Pizzoli wrote: Hi guys, I'm trying to migrate my ldap user base to freeipa. I'm using the last Release Candidate. I already changed ipa config-mod --enable-migration=TRUE This is what I have: ipa -v migrate-ds --bind-dn=cn=manager,dc=mydc1,dc=mydc2.it --user-container=ou=people,dc=mydc1,dc=mydc2.it --user-objectclass=inetOrgPerson --group-container=ou=groups,dc=mydc1,dc=mydc2.it --group-objectclass=posixGroup --base-dn=dc=mydc1,dc=mydc2.it --with-compat ldap://ldap01 ipa: INFO: trying https://freeipa01.unix.mydomain.it/ipa/xml Password: ipa: INFO: Forwarding 'migrate_ds' to server u'http://freeipa01.unix.mydomain.it/ipa/xml' ipa: ERROR: Container for group not found at ou=groups,dc=mydc1,dc=mydc2.it I looked at my ldap server logs and I found out that the search executed has scope=1. Actually both for users and groups. This is a problem for me, in having a lot of subtrees (ou) in which my users and groups are. Is there a way to manage this? Thanks in advance Marco P.s. As a side note, I suppose there's a typo in the verbose message I obtain in my output: ipa: INFO: Forwarding 'migrate_ds' to server u'http://freeipa01.unix.mydomain.it/ipa/xml' Please open tickets for both issues. Done: https://fedorahosted.org/freeipa/ticket/2547 https://fedorahosted.org/freeipa/ticket/2546 Do you have a hint on how to manage to do this import in the meantime? Every manual step is ok for me. Maybe you can try performing a new migration for each of the subtrees you have in your source tree, assuming it is a reasonable number, by reconfiguring the migrate-ds bases between each run. Yes, I was thinking the same... :-) To be able to script ipa migrate-ds, I would need a parameter for setting the password on the CLI. I suppose it isn't there by design, right? Thanks again Marco ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Doubt on FreeIPA LDAP extensibility
On Mon, 2012-03-19 at 13:51 +0100, Marco Pizzoli wrote: In attachment. You can find only one, but all of them are equivalent from this point. They are indeed seen as structural, even if my added schema file declare them as auxiliary. Can you attach the (sanitized) schema file you added to 389ds ? Also can you run a ldapsearch command and search in the 'cn=schema' base ? This will give you back what 389ds sends to a client. This command searches for everything but uses an attribute filter to show only the objectclasses: ldapsearch -x -h server -b 'cn=schema' 'objectClasses' No need to attach everything return, just edit the result and attach only the results for your calsses. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Problem in ipa migrate-ds procedure
On 03/19/2012 08:56 AM, Marco Pizzoli wrote: On Mon, Mar 19, 2012 at 1:43 PM, Simo Sorce s...@redhat.com mailto:s...@redhat.com wrote: On Sun, 2012-03-18 at 18:33 +0100, Marco Pizzoli wrote: On Sun, Mar 18, 2012 at 5:49 PM, Dmitri Pal d...@redhat.com mailto:d...@redhat.com wrote: On 03/17/2012 07:36 AM, Marco Pizzoli wrote: Hi guys, I'm trying to migrate my ldap user base to freeipa. I'm using the last Release Candidate. I already changed ipa config-mod --enable-migration=TRUE This is what I have: ipa -v migrate-ds --bind-dn=cn=manager,dc=mydc1,dc=mydc2.it http://mydc2.it --user-container=ou=people,dc=mydc1,dc=mydc2.it http://mydc2.it --user-objectclass=inetOrgPerson --group-container=ou=groups,dc=mydc1,dc=mydc2.it http://mydc2.it --group-objectclass=posixGroup --base-dn=dc=mydc1,dc=mydc2.it http://mydc2.it --with-compat ldap://ldap01 ipa: INFO: trying https://freeipa01.unix.mydomain.it/ipa/xml Password: ipa: INFO: Forwarding 'migrate_ds' to server u'http://freeipa01.unix.mydomain.it/ipa/xml' ipa: ERROR: Container for group not found at ou=groups,dc=mydc1,dc=mydc2.it http://mydc2.it I looked at my ldap server logs and I found out that the search executed has scope=1. Actually both for users and groups. This is a problem for me, in having a lot of subtrees (ou) in which my users and groups are. Is there a way to manage this? Thanks in advance Marco P.s. As a side note, I suppose there's a typo in the verbose message I obtain in my output: ipa: INFO: Forwarding 'migrate_ds' to server u'http://freeipa01.unix.mydomain.it/ipa/xml' Please open tickets for both issues. Done: https://fedorahosted.org/freeipa/ticket/2547 https://fedorahosted.org/freeipa/ticket/2546 Do you have a hint on how to manage to do this import in the meantime? Every manual step is ok for me. Maybe you can try performing a new migration for each of the subtrees you have in your source tree, assuming it is a reasonable number, by reconfiguring the migrate-ds bases between each run. Yes, I was thinking the same... :-) To be able to script ipa migrate-ds, I would need a parameter for setting the password on the CLI. I suppose it isn't there by design, right? Will it handle the case when the group has members from different levels and some of the users are not picked by the search? In this case I suspect the user group membership might be lost. I am not sure that this is the case. Just something to pay attention. Thanks again Marco ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Problem in ipa migrate-ds procedure
Dmitri Pal wrote: On 03/17/2012 07:36 AM, Marco Pizzoli wrote: Hi guys, I'm trying to migrate my ldap user base to freeipa. I'm using the last Release Candidate. I already changed ipa config-mod --enable-migration=TRUE This is what I have: ipa -v migrate-ds --bind-dn=cn=manager,dc=mydc1,dc=mydc2.it http://mydc2.it --user-container=ou=people,dc=mydc1,dc=mydc2.it http://mydc2.it --user-objectclass=inetOrgPerson --group-container=ou=groups,dc=mydc1,dc=mydc2.it http://mydc2.it --group-objectclass=posixGroup --base-dn=dc=mydc1,dc=mydc2.it http://mydc2.it --with-compat ldap://ldap01 ipa: INFO: trying https://freeipa01.unix.mydomain.it/ipa/xml Password: ipa: INFO: Forwarding 'migrate_ds' to server u'http://freeipa01.unix.mydomain.it/ipa/xml' ipa: ERROR: Container for group not found at ou=groups,dc=mydc1,dc=mydc2.it http://mydc2.it I looked at my ldap server logs and I found out that the search executed has scope=1. Actually both for users and groups. This is a problem for me, in having a lot of subtrees (ou) in which my users and groups are. Is there a way to manage this? Thanks in advance Marco P.s. As a side note, I suppose there's a typo in the verbose message I obtain in my output: ipa: INFO: Forwarding 'migrate_ds' to server *u*'http://freeipa01.unix.mydomain.it/ipa/xml' Please open tickets for both issues. Well, I don't think either is a bug. If you have users/groups in multiple places you'll need to migrate them individually for now. It is safe to run migrate-ds multiple times, existing users are not migrated. The u is a python-ism for unicode. This is not a bug. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Problem in ipa migrate-ds procedure
Dmitri Pal wrote: On 03/19/2012 08:56 AM, Marco Pizzoli wrote: On Mon, Mar 19, 2012 at 1:43 PM, Simo Sorce s...@redhat.com mailto:s...@redhat.com wrote: On Sun, 2012-03-18 at 18:33 +0100, Marco Pizzoli wrote: On Sun, Mar 18, 2012 at 5:49 PM, Dmitri Pal d...@redhat.com mailto:d...@redhat.com wrote: On 03/17/2012 07:36 AM, Marco Pizzoli wrote: Hi guys, I'm trying to migrate my ldap user base to freeipa. I'm using the last Release Candidate. I already changed ipa config-mod --enable-migration=TRUE This is what I have: ipa -v migrate-ds --bind-dn=cn=manager,dc=mydc1,dc=mydc2.it http://mydc2.it --user-container=ou=people,dc=mydc1,dc=mydc2.it http://mydc2.it --user-objectclass=inetOrgPerson --group-container=ou=groups,dc=mydc1,dc=mydc2.it http://mydc2.it --group-objectclass=posixGroup --base-dn=dc=mydc1,dc=mydc2.it http://mydc2.it --with-compat ldap://ldap01 ipa: INFO: trying https://freeipa01.unix.mydomain.it/ipa/xml Password: ipa: INFO: Forwarding 'migrate_ds' to server u'http://freeipa01.unix.mydomain.it/ipa/xml' ipa: ERROR: Container for group not found at ou=groups,dc=mydc1,dc=mydc2.it http://mydc2.it I looked at my ldap server logs and I found out that the search executed has scope=1. Actually both for users and groups. This is a problem for me, in having a lot of subtrees (ou) in which my users and groups are. Is there a way to manage this? Thanks in advance Marco P.s. As a side note, I suppose there's a typo in the verbose message I obtain in my output: ipa: INFO: Forwarding 'migrate_ds' to server u'http://freeipa01.unix.mydomain.it/ipa/xml' Please open tickets for both issues. Done: https://fedorahosted.org/freeipa/ticket/2547 https://fedorahosted.org/freeipa/ticket/2546 Do you have a hint on how to manage to do this import in the meantime? Every manual step is ok for me. Maybe you can try performing a new migration for each of the subtrees you have in your source tree, assuming it is a reasonable number, by reconfiguring the migrate-ds bases between each run. Yes, I was thinking the same... :-) To be able to script ipa migrate-ds, I would need a parameter for setting the password on the CLI. I suppose it isn't there by design, right? Will it handle the case when the group has members from different levels and some of the users are not picked by the search? In this case I suspect the user group membership might be lost. I am not sure that this is the case. Just something to pay attention. It doesn't look like we verify the membership so I think it will work just fine. It is not invalid in LDAP to have a group with a member that doesn't exist, so this shouldn't cause any errors. You can do something like echo password | ipa migrate-ds ldap://myserver.example.com:389 --user-container=... rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Extending IPA schema for Federation services.
Steven Jones wrote: Hi, Is it possible to expand IPA's schema to do this? Adding the schema is easy, doing something with it is where things get interesting. What do you want to do with these attributes/objectclasses? rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Problem in ipa migrate-ds procedure
On Mon, Mar 19, 2012 at 2:42 PM, Rob Crittenden rcrit...@redhat.com wrote: Dmitri Pal wrote: On 03/17/2012 07:36 AM, Marco Pizzoli wrote: Hi guys, I'm trying to migrate my ldap user base to freeipa. I'm using the last Release Candidate. I already changed ipa config-mod --enable-migration=TRUE This is what I have: ipa -v migrate-ds --bind-dn=cn=manager,dc=**mydc1,dc=mydc2.it http://mydc2.it --user-container=ou=people,**dc=mydc1,dc=mydc2.it http://mydc2.it --user-objectclass=**inetOrgPerson --group-container=ou=groups,**dc=mydc1,dc=mydc2.it http://mydc2.it --group-objectclass=posixGroup --base-dn=dc=mydc1,dc=mydc2.**ithttp://mydc2.it http://mydc2.it --with-compat ldap://ldap01 ipa: INFO: trying https://freeipa01.unix.**mydomain.it/ipa/xmlhttps://freeipa01.unix.mydomain.it/ipa/xml Password: ipa: INFO: Forwarding 'migrate_ds' to server u'http://freeipa01.unix.**mydomain.it/ipa/xmlhttp://freeipa01.unix.mydomain.it/ipa/xml ' ipa: ERROR: Container for group not found at ou=groups,dc=mydc1,dc=mydc2.it http://mydc2.it I looked at my ldap server logs and I found out that the search executed has scope=1. Actually both for users and groups. This is a problem for me, in having a lot of subtrees (ou) in which my users and groups are. Is there a way to manage this? Thanks in advance Marco P.s. As a side note, I suppose there's a typo in the verbose message I obtain in my output: ipa: INFO: Forwarding 'migrate_ds' to server *u*'http://freeipa01.unix.**mydomain.it/ipa/xmlhttp://freeipa01.unix.mydomain.it/ipa/xml ' Please open tickets for both issues. Well, I don't think either is a bug. If you have users/groups in multiple places you'll need to migrate them individually for now. It is safe to run migrate-ds multiple times, existing users are not migrated. I just re-executed by specifing a nested ou for my groups. This is what I got: ipa: INFO: trying https://freeipa01.unix.csebo.it/ipa/xml ipa: INFO: Forwarding 'migrate_ds' to server u' http://freeipa01.unix.csebo.it/ipa/xml' --- migrate-ds: --- Migrated: Failed user: fw03075_no: Type or value exists: [other users listed] Failed group: pdbac32: Type or value exists: [other groups listed] -- 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. I don't understand what it's trying to telling me. On my FreeIPA ldap server I don't see any imported user. What's my fault here? The u is a python-ism for unicode. This is not a bug. Please, could you give a little more detail on this? It's only a hint on what that data represents in a Python variable? Thanks again Marco rob __**_ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/**mailman/listinfo/freeipa-usershttps://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Firefox on OS X 10.6 problem
Hi,
Today I setup free ipa on CentOS release 6.2. I configured my client
machine, that is:
1. I edited my /Library/Preferences/edu.mit.Kerberos file so it has
following content:
[domain_realm]
polidea.pl = POLIDEA.PL
.polidea.pl = .POLIDEA.PL
[libdefaults]
default_realm = POLIDEA.PL
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24h
forwardable = yes
[realms]
POLIDEA.PL = {
admin_server = free-ipa.polidea.pl:749
default_domain = polidea.pl
kdc = free-ipa.polidea.pl:88
}
[logging]
kdc = FILE:/var/log/krb5kdc/kdc.log
admin_server = FILE:/var/log/krb5kdc/kadmin.log
I
I run open /System/Library/Coreservices/Ticket\ Viewer.app and added
ad...@polidea.pl identity (i get ticket so password is valid)
also i configured my firefox like in this link:
http://freeipa.org/page/InstallAndDeploy#Configuring_your_Browser
Unfortunately when I try to login I get following error:
Your kerberos ticket is no longer valid. Please run kinit and then
click 'Retry'. If this is your first time running the IPA Web UI
follow these directions to configure your browser.
my /var/log/krb5kdc/kadmin.log has only few old entries (0 today's
entries from today).
I will appreciate any help.
regards,
Maciek
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Doubt on FreeIPA LDAP extensibility
On Mon, 2012-03-19 at 14:46 +0100, Marco Pizzoli wrote: On Mon, Mar 19, 2012 at 2:32 PM, Simo Sorce s...@redhat.com wrote: On Mon, 2012-03-19 at 13:51 +0100, Marco Pizzoli wrote: In attachment. You can find only one, but all of them are equivalent from this point. They are indeed seen as structural, even if my added schema file declare them as auxiliary. Can you attach the (sanitized) schema file you added to 389ds ? Already done on this thread. See my previous mail to Dmitri. Also can you run a ldapsearch command and search in the 'cn=schema' base ? This will give you back what 389ds sends to a client. This command searches for everything but uses an attribute filter to show only the objectclasses: ldapsearch -x -h server -b 'cn=schema' 'objectClasses' No need to attach everything return, just edit the result and attach only the results for your calsses. Ok, here it is: [root@freeipa01 ~]# ldapsearch -h 127.0.0.1 -x -Dcn=Directory Manager -s base -W -b cn=schema objectClasses|perl -0pe 's/\n //g' objectClasses: ( 1.3.6.1.4.1.36005.0.2.6.2 NAME 'xxxPeopleAttributes' DESC 'Definizione di attributi specifici per gli utenti XXX' STRUCTURAL MAY xxxUfficio ) objectClasses: ( 1.3.6.1.4.1.36005.0.2.6.3 NAME 'xxxGroupsAttributes' DESC 'Definizione di attributi specifici per i gruppi XXX' STRUCTURAL MAY ( xxxProgetto $ xxxAmbiente $ xxxTipoGruppo ) ) objectClasses: ( 1.3.6.1.4.1.36005.0.2.6.4 NAME 'xxxWebminAttributes' DESC 'Definizione di attributi specifici per gli oggetti Webmin' STRUCTURAL MAY xxxWebminAmbiente ) objectClasses: ( 1.3.6.1.4.1.36005.0.2.6.5 NAME 'xxxDB2GroupsAttributes' DESC 'Definizione di attributi specifici per i gruppi DB2' STRUCTURAL MAY xxxDB2GruppiPrivilegi ) objectClasses: ( 1.3.6.1.4.1.36005.0.2.6.1 NAME 'xxxAttributes' DESC 'Definizione di attributi specifici per utilizzo interno' STRUCTURAL MAY ( xxxProgetto $ xxxAmbiente $ xxxTipoGruppo $ xxxDB2GruppiPrivilegi ) ) By seeing this output, I just checked again and I confirm that in my file /etc/dirsrv/slapd-UNIX-MYDOMAIN-IT/schema/98myfile.ldif they are still AUXILIARY. This is odd, indeed, I will resurrect the bug you opened with a better description, thanks. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Firefox on OS X 10.6 problem
On 03/19/2012 12:31 PM, Maciej Sawicki wrote:
Hi,
Today I setup free ipa on CentOS release 6.2. I configured my client
machine, that is:
1. I edited my /Library/Preferences/edu.mit.Kerberos file so it has
following content:
[domain_realm]
polidea.pl = POLIDEA.PL
.polidea.pl = .POLIDEA.PL
[libdefaults]
default_realm = POLIDEA.PL
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24h
forwardable = yes
[realms]
POLIDEA.PL = {
admin_server = free-ipa.polidea.pl:749
default_domain = polidea.pl
kdc = free-ipa.polidea.pl:88
}
[logging]
kdc = FILE:/var/log/krb5kdc/kdc.log
admin_server = FILE:/var/log/krb5kdc/kadmin.log
I
I run open /System/Library/Coreservices/Ticket\ Viewer.app and added
ad...@polidea.pl identity (i get ticket so password is valid)
also i configured my firefox like in this link:
http://freeipa.org/page/InstallAndDeploy#Configuring_your_Browser
Unfortunately when I try to login I get following error:
Your kerberos ticket is no longer valid. Please run kinit and then
click 'Retry'. If this is your first time running the IPA Web UI
follow these directions to configure your browser.
my /var/log/krb5kdc/kadmin.log has only few old entries (0 today's
entries from today).
I will appreciate any help.
regards,
Maciek
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Have you done everything covered in the section 4.3.3 of the document?
http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/using-the-ui.html#Using_a_Browser_on_Another_System
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IPA project,
Red Hat Inc.
---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Firefox on OS X 10.6 problem
On Mon, Mar 19, 2012 at 5:38 PM, Dmitri Pal d...@redhat.com wrote: Have you done everything covered in the section 4.3.3 of the document? http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/using-the-ui.html#Using_a_Browser_on_Another_System Hi Dmitri, Thanks for quick answer. I did this, but still have the same problem :(. regards, Maciek Sawicki ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Firefox on OS X 10.6 problem
Sorry for double post, but I would like to provide firefox log: 1886907584[10031d220]: using REQ_DELEGATE 1886907584[10031d220]: service = free-ipa.polidea.pl 1886907584[10031d220]: using negotiate-gss 1886907584[10031d220]: entering nsAuthGSSAPI::nsAuthGSSAPI() 1886907584[10031d220]: Attempting to load gss functions 1886907584[10031d220]: entering nsAuthGSSAPI::Init() 1886907584[10031d220]: nsHttpNegotiateAuth::GenerateCredentials() [challenge=Negotiate] 1886907584[10031d220]: entering nsAuthGSSAPI::GetNextToken() 1886907584[10031d220]: gss_init_sec_context() failed: Unspecified GSS failure. Minor code may provide more information 1886907584[10031d220]: leaving nsAuthGSSAPI::GetNextToken [rv=80004005] 1886907584[10031d220]: using REQ_DELEGATE 1886907584[10031d220]: service = free-ipa.polidea.pl 1886907584[10031d220]: using negotiate-gss 1886907584[10031d220]: entering nsAuthGSSAPI::nsAuthGSSAPI() 1886907584[10031d220]: entering nsAuthGSSAPI::Init() 1886907584[10031d220]: nsHttpNegotiateAuth::GenerateCredentials() [challenge=Negotiate] 1886907584[10031d220]: entering nsAuthGSSAPI::GetNextToken() 1886907584[10031d220]: gss_init_sec_context() failed: Unspecified GSS failure. Minor code may provide more information 1886907584[10031d220]: leaving nsAuthGSSAPI::GetNextToken [rv=80004005] best regards, Maciek Sawicki On Mon, Mar 19, 2012 at 5:58 PM, Maciej Sawicki maciej.sawi...@polidea.pl wrote: On Mon, Mar 19, 2012 at 5:38 PM, Dmitri Pal d...@redhat.com wrote: Have you done everything covered in the section 4.3.3 of the document? http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/using-the-ui.html#Using_a_Browser_on_Another_System Hi Dmitri, Thanks for quick answer. I did this, but still have the same problem :(. regards, Maciek Sawicki ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Firefox on OS X 10.6 problem
On Mon, Mar 19, 2012 at 9:31 AM, Maciej Sawicki
maciej.sawi...@polidea.pl wrote:
Hi,
Today I setup free ipa on CentOS release 6.2. I configured my client
machine, that is:
1. I edited my /Library/Preferences/edu.mit.Kerberos file so it has
following content:
[domain_realm]
polidea.pl = POLIDEA.PL
.polidea.pl = .POLIDEA.PL
[libdefaults]
default_realm = POLIDEA.PL
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24h
forwardable = yes
[realms]
POLIDEA.PL = {
admin_server = free-ipa.polidea.pl:749
default_domain = polidea.pl
kdc = free-ipa.polidea.pl:88
}
[logging]
kdc = FILE:/var/log/krb5kdc/kdc.log
admin_server = FILE:/var/log/krb5kdc/kadmin.log
I
I run open /System/Library/Coreservices/Ticket\ Viewer.app and added
ad...@polidea.pl identity (i get ticket so password is valid)
also i configured my firefox like in this link:
http://freeipa.org/page/InstallAndDeploy#Configuring_your_Browser
Unfortunately when I try to login I get following error:
Your kerberos ticket is no longer valid. Please run kinit and then
click 'Retry'. If this is your first time running the IPA Web UI
follow these directions to configure your browser.
my /var/log/krb5kdc/kadmin.log has only few old entries (0 today's
entries from today).
I will appreciate any help.
I just edited /etc/krb5.conf on my mac and then kinit from command
line and you should see ticket in the Ticket Viewer app. From there,
you should be able to renew the ticket inside the app or from command
line. I did not touch the /Library/Preferences/edu.mit.Kerberos file
at all.
Steve
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Firefox on OS X 10.6 problem
On Mon, Mar 19, 2012 at 6:10 PM, Stephen Ingram sbing...@gmail.com wrote: I just edited /etc/krb5.conf on my mac and then kinit from command line and you should see ticket in the Ticket Viewer app. From there, you should be able to renew the ticket inside the app or from command line. I did not touch the /Library/Preferences/edu.mit.Kerberos file at all. Steve Thanks from answer. I manage to solve this issue (I'm not sure if it best way but it works). In link from Dmitri I saw that I have to copy /etc/krb5.conf file from free-ipa server so I copied it to /Library/Preferences/edu.mit.Kerberos It's a little different then in http://freeipa.com/page/ConfiguringMacintoshClients. best regards, Maciek Sawicki ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Fedora 15 IPA Server Upgrade Broke LDAP
On Mon, 2012-03-19 at 11:47 -0500, David wrote:
After upgrading the IPA server on a Fedora 15 host to
freeipa-server-2.1.4-3.fc15.x86_64 along with the LDAP dependency of
389-ds-base-1.2.10.2-1.fc15.x86_64, the IPA server fails to start due to
the following error:
Failed to read data from Directory Service: Failed to get list of
services to probe status!
Configured hostname 'ipa01.ourdomain.net' does not match any master
server in LDAP:
No master found because of error: {'matched': 'dc=ourdomain,dc=net',
'desc': 'No such object'}
and IPA shuts down.
Using dbscan to view
/var/lib/dirsrv/slapd-OURDOMAIN-NET/db/userRoot/id2entry.db4 I can see
the data is still there.
Has anyone run into this issue and if so what needs to be done to
correct it?
What 389ds version did you upgrad from (yum history can tell you).
We have just had another thread with a user that upgraded from a alpha
release of 389ds that should have not been used in production.
Se the thread named: [Freeipa-users] (no subject)
(yeah not a great subject :-)
Simo.
--
Simo Sorce * Red Hat, Inc * New York
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Fedora 15 IPA Server Upgrade Broke LDAP
Simo Sorce wrote:
On Mon, 2012-03-19 at 11:47 -0500, David wrote:
After upgrading the IPA server on a Fedora 15 host to
freeipa-server-2.1.4-3.fc15.x86_64 along with the LDAP dependency of
389-ds-base-1.2.10.2-1.fc15.x86_64, the IPA server fails to start due to
the following error:
Failed to read data from Directory Service: Failed to get list of
services to probe status!
Configured hostname 'ipa01.ourdomain.net' does not match any master
server in LDAP:
No master found because of error: {'matched': 'dc=ourdomain,dc=net',
'desc': 'No such object'}
and IPA shuts down.
Using dbscan to view
/var/lib/dirsrv/slapd-OURDOMAIN-NET/db/userRoot/id2entry.db4 I can see
the data is still there.
Has anyone run into this issue and if so what needs to be done to
correct it?
What 389ds version did you upgrad from (yum history can tell you).
We have just had another thread with a user that upgraded from a alpha
release of 389ds that should have not been used in production.
Se the thread named: [Freeipa-users] (no subject)
(yeah not a great subject :-)
Simo.
Someone reported this in IRC as well today. The fix was to change
DBVERSION to rdn-format-1 and run setup-ds.pl -u -s
General.UpdateMode=offline
rob
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Fedora 15 IPA Server Upgrade Broke LDAP
On Mon, 2012-03-19 at 14:57 -0400, Rob Crittenden wrote:
Simo Sorce wrote:
On Mon, 2012-03-19 at 11:47 -0500, David wrote:
After upgrading the IPA server on a Fedora 15 host to
freeipa-server-2.1.4-3.fc15.x86_64 along with the LDAP dependency of
389-ds-base-1.2.10.2-1.fc15.x86_64, the IPA server fails to start due to
the following error:
Failed to read data from Directory Service: Failed to get list of
services to probe status!
Configured hostname 'ipa01.ourdomain.net' does not match any master
server in LDAP:
No master found because of error: {'matched': 'dc=ourdomain,dc=net',
'desc': 'No such object'}
and IPA shuts down.
Using dbscan to view
/var/lib/dirsrv/slapd-OURDOMAIN-NET/db/userRoot/id2entry.db4 I can see
the data is still there.
Has anyone run into this issue and if so what needs to be done to
correct it?
What 389ds version did you upgrad from (yum history can tell you).
We have just had another thread with a user that upgraded from a alpha
release of 389ds that should have not been used in production.
Se the thread named: [Freeipa-users] (no subject)
(yeah not a great subject :-)
Simo.
Someone reported this in IRC as well today. The fix was to change
DBVERSION to rdn-format-1 and run setup-ds.pl -u -s
General.UpdateMode=offline
Rob is this a general issue we need to address, or is it a one off from
some non-released versions of 389ds to 1.2.10.2 ?
Simo.
--
Simo Sorce * Red Hat, Inc * New York
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Problem in ipa migrate-ds procedure
Marco Pizzoli wrote: On Mon, Mar 19, 2012 at 2:42 PM, Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com wrote: Dmitri Pal wrote: On 03/17/2012 07:36 AM, Marco Pizzoli wrote: Hi guys, I'm trying to migrate my ldap user base to freeipa. I'm using the last Release Candidate. I already changed ipa config-mod --enable-migration=TRUE This is what I have: ipa -v migrate-ds --bind-dn=cn=manager,dc=__mydc1,dc=mydc2.it http://mydc2.it http://mydc2.it --user-container=ou=people,__dc=mydc1,dc=mydc2.it http://mydc2.it http://mydc2.it --user-objectclass=__inetOrgPerson --group-container=ou=groups,__dc=mydc1,dc=mydc2.it http://mydc2.it http://mydc2.it --group-objectclass=posixGroup --base-dn=dc=mydc1,dc=mydc2.__it http://mydc2.it http://mydc2.it --with-compat ldap://ldap01 ipa: INFO: trying https://freeipa01.unix.__mydomain.it/ipa/xml https://freeipa01.unix.mydomain.it/ipa/xml Password: ipa: INFO: Forwarding 'migrate_ds' to server u'http://freeipa01.unix.__mydomain.it/ipa/xml http://freeipa01.unix.mydomain.it/ipa/xml' ipa: ERROR: Container for group not found at ou=groups,dc=mydc1,dc=mydc2.it http://mydc2.it http://mydc2.it I looked at my ldap server logs and I found out that the search executed has scope=1. Actually both for users and groups. This is a problem for me, in having a lot of subtrees (ou) in which my users and groups are. Is there a way to manage this? Thanks in advance Marco P.s. As a side note, I suppose there's a typo in the verbose message I obtain in my output: ipa: INFO: Forwarding 'migrate_ds' to server *u*'http://freeipa01.unix.__mydomain.it/ipa/xml http://freeipa01.unix.mydomain.it/ipa/xml' Please open tickets for both issues. Well, I don't think either is a bug. If you have users/groups in multiple places you'll need to migrate them individually for now. It is safe to run migrate-ds multiple times, existing users are not migrated. I just re-executed by specifing a nested ou for my groups. This is what I got: ipa: INFO: trying https://freeipa01.unix.csebo.it/ipa/xml ipa: INFO: Forwarding 'migrate_ds' to server u'http://freeipa01.unix.csebo.it/ipa/xml' --- migrate-ds: --- Migrated: Failed user: fw03075_no: Type or value exists: [other users listed] Failed group: pdbac32: Type or value exists: [other groups listed] -- 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. I don't understand what it's trying to telling me. On my FreeIPA ldap server I don't see any imported user. What's my fault here? The u is a python-ism for unicode. This is not a bug. Please, could you give a little more detail on this? It's only a hint on what that data represents in a Python variable? Thanks again Marco Type or value exists occurs when one tries to add an attribute value to an entry that already exists. I suspect that the underlying problem is different between users and groups. For groups it is likely adding a duplicate member. For users I'm not really sure. It could be one of the POSIX attributes. What does a failed entry look like? rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Extending IPA schema for Federation services.
Hi, Im starting from scratch here so bear with me..ie I dont know a lot of thiswhich should be obvious Extending Easy? oh because it doesnt strike me as easy.. :/ Initially I am about to build our production IPA servers. These attributes are a requirement of the Federation system New Zealand wants to use and is probably the same for Australia. So I think the schema has to be done/extended for IPA to be viable in tertiary institutions in NZ, without it not many if anyone will use IPA they will stay with openldap. So each person should have these I think.they may not be used initially but once extended initially then I dont have to extend the schema later. What connects to these is an apache/tomcat front end. There are two aspects/functions to this, the IdP and the SdP. The Idp allows remote tertiary organisations to query us and say our user is we legitthey then use their LDAP to provide resources via the SdP. So the Idp provides an identity to remote ppl and the SdP provides access to a resource at our end. later I expect we will have to to the SdP bit got our high performance cluster and storage... It maybe a year or more before we actually use this, but it strikes me as sensible that these are done on initial build.I will put ina RH support case for this. We will probably also pull the actual fields/contents out of AD.not sure yet. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 From: Rob Crittenden [rcrit...@redhat.com] Sent: Tuesday, 20 March 2012 2:55 a.m. To: Steven Jones Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] Extending IPA schema for Federation services. Steven Jones wrote: Hi, Is it possible to expand IPA's schema to do this? Adding the schema is easy, doing something with it is where things get interesting. What do you want to do with these attributes/objectclasses? rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Extending IPA schema for Federation services.
On 03/19/2012 03:58 PM, Steven Jones wrote: Hi, Im starting from scratch here so bear with me..ie I dont know a lot of thiswhich should be obvious Extending Easy? oh because it doesnt strike me as easy.. :/ Initially I am about to build our production IPA servers. These attributes are a requirement of the Federation system New Zealand wants to use and is probably the same for Australia. So I think the schema has to be done/extended for IPA to be viable in tertiary institutions in NZ, without it not many if anyone will use IPA they will stay with openldap. So each person should have these I think.they may not be used initially but once extended initially then I dont have to extend the schema later. What connects to these is an apache/tomcat front end. There are two aspects/functions to this, the IdP and the SdP. The Idp allows remote tertiary organisations to query us and say our user is we legitthey then use their LDAP to provide resources via the SdP. So the Idp provides an identity to remote ppl and the SdP provides access to a resource at our end. later I expect we will have to to the SdP bit got our high performance cluster and storage... It maybe a year or more before we actually use this, but it strikes me as sensible that these are done on initial build.I will put ina RH support case for this. We will probably also pull the actual fields/contents out of AD.not sure yet. The question is simple: how you plan to manage these attributes in IPA? Do you expect them to be a part of the UI/CLI or they should be hidden there and be managed via ldapmodify and other data sync tools? This make the whole difference especially the UI part. Depending upon these expectations the scope would be different. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 From: Rob Crittenden [rcrit...@redhat.com] Sent: Tuesday, 20 March 2012 2:55 a.m. To: Steven Jones Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] Extending IPA schema for Federation services. Steven Jones wrote: Hi, Is it possible to expand IPA's schema to do this? Adding the schema is easy, doing something with it is where things get interesting. What do you want to do with these attributes/objectclasses? rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] (no subject)
This is all I see in the /var/log/httpd/error_log file. This issue has become critical. The server has been down a week and I have no idea why certmonger broke and don't seem to have any indication of how to fix it. What would be the best route besides chasing down this certmonger issue? Could I export all of my configuration/users/etc, install a completely new IPA and import my config? [Sat Mar 03 00:05:27 2012] [error] ipa: INFO: sslget 'https://csp-idm.pdh.csp:443/ca/agent/ca/displayBySerial' [Sat Mar 03 00:05:28 2012] [error] ipa: INFO: host/csp-idm.pdh@pdh.csp: cert_request(u'MIIDQzCCAisCAQAwLDEQMA4GA1UEChMHUERILkNTUDEYMBYGA1 UEAxMPY3NwLWlkbS5wZGguY3NwMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr0EHCdyTuteryFZ2bdEl+V4OATR/xk8ELthmvlwT/5qubZKwlCWS6yLawgdyCg9Yw737A7q Ge0BPxHv6E+as10NxppEPsn9BOi+TPRIMYNMNNYmO2sce2pvkMkVBqsF7Gn7mF7e5+Bpc7ApnDGP7WLsAjbso8EvLUrqVMTNyiziCSHiNk+/Fi1Om6K5GKzKkqfEDex0RK+kpMswgcaZH hmW3i+y3UxFZsJjOg3R4fJAfC0+My2d1Vx4052+EgWAbSNpSj7zmLGM2+dkmgMo5Li7jjgJe8VsrqOV4L5IgqtGVJ0EOb7EP7gynbVoa74m4XrVwEP8rd/M5RxAnD1JPuwIDAQABoIHRM BoGCSqGSIb3DQEJFDENEwtTZXJ2ZXItQ2VydDCBsgYJKoZIhvcNAQkOMYGkMIGhMA4GA1UdDwEBAAQEAwIE8DB3BgNVHREBAQAEbTBroCwGCisGAQQBgjcUAgOgHgwcbGRhcC9jc3AtaW RtLnBkaC5jc3BAUERILkNTUKA7BgYrBgEFAgKgMTAvoAkbB1BESC5DU1ChIjAgoAMCAQGhGTAXGwRsZGFwGw9jc3AtaWRtLnBkaC5jc3AwFgYDVR0lAQEABAwwCgYIKwYBBQUHAwEwDQY JKoZIhvcNAQELBQADggEBABD/Hwbgf5NJNUYt0+ntMDHiilMFkSaO6ryQ36/pCH1oR+vI+PCeClHewPo0v99h4Z8W8L7CQtDdNBUMl/JVHH5Lz7cBF8A/jXZQ+naV17EEuXncacM8AvYh 5dL2yih+8RpPalEmSgz5rijtbSigfNGrZn0Mh3qOW1kbsz+GDaaT9wLFxvdJyqgdKds2tsp0KzHIMcJuw3cwOfH8zrBRV28XYhMLm0OOhj92uxgax5UPY2VyHP5UOtOnfuduU1ZXa+o8Q IXqX7/HyDSCLGwiPJscAsp9cRzjn4KvqzZDOcdGEjXmCGfrmUiMcuzVyTDR2SdAWrHdbRmXeyVxmiBPzdk=', principal=u'ldap/csp-idm.pdh@pdh.csp', add=True): C ertificateOperationError On Fri, Mar 16, 2012 at 5:30 PM, Rob Crittenden rcrit...@redhat.com wrote: Jimmy wrote: I actually shut down IPA to do the export and restarted after I imported. certutil -L -d /etc/httpd/alias Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Server-Cert u,u,u ABC.XYZIPA CA CT,C,C ipaCert u,u,u Signing-Cert u,u,u certutil -V -u V -n Server-Cert -d /etc/httpd/alias -e -f /etc/httpd/alias/pwdfile.txt certutil: certificate is valid How's that look? That's what it's supposed to look like. Is Apache logging a failure or maybe that is coming from dogtag through Apache... rob On Fri, Mar 16, 2012 at 4:34 PM, Rob Crittendenrcrit...@redhat.com wrote: Jimmy wrote: ipa-getcert list shows some ugly output - http://fpaste.org/bV2v/ Looks pretty similar to what we've been seeing. The invalid credentials means that dogtag can't validate RA agent cert. This was due to the corrupted database. You'll need to restart the pki-cad process once the LDAP backend is fixed. The trust issues are stranger. To show the certs in those databases: # certutil -L -d /etc/httpd/alias To verify that the cert in there now has all the CA certs it needs: # certutil -V -u V -n Server-Cert -d /etc/httpd/alias -e -f /etc/httpd/alias/pwdfile.txt rob On Fri, Mar 16, 2012 at 4:05 PM, Jimmyg17ji...@gmail.com wrote: I exported/imported the /var/lib/dirsrv/slapd-PKI-IPA/db/userRoot and that went smoothly but now I see this in /var/log/pki-ca/system: 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] Operation Error - netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] Null response control 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] Operation Error - netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] Null response control 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] Operation Error - netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] Null response control 10358.CRLIssuingPoint-MasterCRL - [08/Mar/2012:04:36:29 UTC] [3] [3] CRLIssuingPoint MasterCRL - Cannot create or store the first CRL in the internaldb. The internaldb could be down. Error LDAP operation failure - cn=MasterCRL,ou=crlIssuingPoints, ou=ca, o=ipaca netscape.ldap.LDAPE xception: error result (32); matchedDN = o=ipaca catalina.out -- http://fpaste.org/oRQd/ ca-debug -- http://fpaste.org/zzFL/ Any ideas? On Fri, Mar 16, 2012 at 2:39 PM, Rob Crittendenrcrit...@redhat.com wrote: Jimmy wrote: The ca_audit problem was caused by me accidentally moving the directory to a backup location. I was cleaning up the logs to make reading easier. When I moved the directory back
Re: [Freeipa-users] Extending IPA schema for Federation services.
Hi, Is it sensible/better to extend the scheme before I start adding users? or doesnt it matter? From my perspective extending a system in use carries risk and impact to users, so its seems safer to extend it before I have any users, even if its un-used for now/? Apart from that I dont knowfor now I would live with the extended schema for the userpopulating the fields would be something I would look at when its decided what we will be doingno one yet knows or at least have not told me what they will be doing. I suspect in the end we will draw the contents from AD with winsync? or populate/inject it directly via our Oracle identity system..so I'm not sure we will need the ui / guiI dont expect to add content via it, I suspect I might need to fault find to make sure the data is there but I assume ldap search tools will return this anyway? However for other sites they may well not have an AD or user provisioning system... regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 From: freeipa-users-boun...@redhat.com [freeipa-users-boun...@redhat.com] on behalf of Dmitri Pal [d...@redhat.com] Sent: Tuesday, 20 March 2012 9:19 a.m. To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] Extending IPA schema for Federation services. On 03/19/2012 03:58 PM, Steven Jones wrote: Hi, Im starting from scratch here so bear with me..ie I dont know a lot of thiswhich should be obvious Extending Easy? oh because it doesnt strike me as easy.. :/ Initially I am about to build our production IPA servers. These attributes are a requirement of the Federation system New Zealand wants to use and is probably the same for Australia. So I think the schema has to be done/extended for IPA to be viable in tertiary institutions in NZ, without it not many if anyone will use IPA they will stay with openldap. So each person should have these I think.they may not be used initially but once extended initially then I dont have to extend the schema later. What connects to these is an apache/tomcat front end. There are two aspects/functions to this, the IdP and the SdP. The Idp allows remote tertiary organisations to query us and say our user is we legitthey then use their LDAP to provide resources via the SdP. So the Idp provides an identity to remote ppl and the SdP provides access to a resource at our end. later I expect we will have to to the SdP bit got our high performance cluster and storage... It maybe a year or more before we actually use this, but it strikes me as sensible that these are done on initial build.I will put ina RH support case for this. We will probably also pull the actual fields/contents out of AD.not sure yet. The question is simple: how you plan to manage these attributes in IPA? Do you expect them to be a part of the UI/CLI or they should be hidden there and be managed via ldapmodify and other data sync tools? This make the whole difference especially the UI part. Depending upon these expectations the scope would be different. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 From: Rob Crittenden [rcrit...@redhat.com] Sent: Tuesday, 20 March 2012 2:55 a.m. To: Steven Jones Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] Extending IPA schema for Federation services. Steven Jones wrote: Hi, Is it possible to expand IPA's schema to do this? Adding the schema is easy, doing something with it is where things get interesting. What do you want to do with these attributes/objectclasses? rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] (no subject)
Jimmy wrote: This is all I see in the /var/log/httpd/error_log file. This issue has become critical. The server has been down a week and I have no idea why certmonger broke and don't seem to have any indication of how to fix it. What would be the best route besides chasing down this certmonger issue? Could I export all of my configuration/users/etc, install a completely new IPA and import my config? [Sat Mar 03 00:05:27 2012] [error] ipa: INFO: sslget 'https://csp-idm.pdh.csp:443/ca/agent/ca/displayBySerial' [Sat Mar 03 00:05:28 2012] [error] ipa: INFO: host/csp-idm.pdh@pdh.csp: cert_request(u'MIIDQzCCAisCAQAwLDEQMA4GA1UEChMHUERILkNTUDEYMBYGA1 UEAxMPY3NwLWlkbS5wZGguY3NwMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr0EHCdyTuteryFZ2bdEl+V4OATR/xk8ELthmvlwT/5qubZKwlCWS6yLawgdyCg9Yw737A7q Ge0BPxHv6E+as10NxppEPsn9BOi+TPRIMYNMNNYmO2sce2pvkMkVBqsF7Gn7mF7e5+Bpc7ApnDGP7WLsAjbso8EvLUrqVMTNyiziCSHiNk+/Fi1Om6K5GKzKkqfEDex0RK+kpMswgcaZH hmW3i+y3UxFZsJjOg3R4fJAfC0+My2d1Vx4052+EgWAbSNpSj7zmLGM2+dkmgMo5Li7jjgJe8VsrqOV4L5IgqtGVJ0EOb7EP7gynbVoa74m4XrVwEP8rd/M5RxAnD1JPuwIDAQABoIHRM BoGCSqGSIb3DQEJFDENEwtTZXJ2ZXItQ2VydDCBsgYJKoZIhvcNAQkOMYGkMIGhMA4GA1UdDwEBAAQEAwIE8DB3BgNVHREBAQAEbTBroCwGCisGAQQBgjcUAgOgHgwcbGRhcC9jc3AtaW RtLnBkaC5jc3BAUERILkNTUKA7BgYrBgEFAgKgMTAvoAkbB1BESC5DU1ChIjAgoAMCAQGhGTAXGwRsZGFwGw9jc3AtaWRtLnBkaC5jc3AwFgYDVR0lAQEABAwwCgYIKwYBBQUHAwEwDQY JKoZIhvcNAQELBQADggEBABD/Hwbgf5NJNUYt0+ntMDHiilMFkSaO6ryQ36/pCH1oR+vI+PCeClHewPo0v99h4Z8W8L7CQtDdNBUMl/JVHH5Lz7cBF8A/jXZQ+naV17EEuXncacM8AvYh 5dL2yih+8RpPalEmSgz5rijtbSigfNGrZn0Mh3qOW1kbsz+GDaaT9wLFxvdJyqgdKds2tsp0KzHIMcJuw3cwOfH8zrBRV28XYhMLm0OOhj92uxgax5UPY2VyHP5UOtOnfuduU1ZXa+o8Q IXqX7/HyDSCLGwiPJscAsp9cRzjn4KvqzZDOcdGEjXmCGfrmUiMcuzVyTDR2SdAWrHdbRmXeyVxmiBPzdk=', principal=u'ldap/csp-idm.pdh@pdh.csp', add=True): C ertificateOperationError I think your CA is still not up and running. Things to check: /var/log/pki-ca/catalina.out to be see if there are start up errors. The debug log in the same directory may contain information as well. If you are seeing a bunch of error 32's it means your db is still corrupted. The output of ipa-getcert list. This will tell you what certmonger thinks is wrong. Did you repair the ipaca backend in PKI-IPA? It is different than userRoot. rob On Fri, Mar 16, 2012 at 5:30 PM, Rob Crittendenrcrit...@redhat.com wrote: Jimmy wrote: I actually shut down IPA to do the export and restarted after I imported. certutil -L -d /etc/httpd/alias Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Server-Cert u,u,u ABC.XYZIPA CA CT,C,C ipaCert u,u,u Signing-Cert u,u,u certutil -V -u V -n Server-Cert -d /etc/httpd/alias -e -f /etc/httpd/alias/pwdfile.txt certutil: certificate is valid How's that look? That's what it's supposed to look like. Is Apache logging a failure or maybe that is coming from dogtag through Apache... rob On Fri, Mar 16, 2012 at 4:34 PM, Rob Crittendenrcrit...@redhat.com wrote: Jimmy wrote: ipa-getcert list shows some ugly output - http://fpaste.org/bV2v/ Looks pretty similar to what we've been seeing. The invalid credentials means that dogtag can't validate RA agent cert. This was due to the corrupted database. You'll need to restart the pki-cad process once the LDAP backend is fixed. The trust issues are stranger. To show the certs in those databases: # certutil -L -d /etc/httpd/alias To verify that the cert in there now has all the CA certs it needs: # certutil -V -u V -n Server-Cert -d /etc/httpd/alias -e -f /etc/httpd/alias/pwdfile.txt rob On Fri, Mar 16, 2012 at 4:05 PM, Jimmyg17ji...@gmail.com wrote: I exported/imported the /var/lib/dirsrv/slapd-PKI-IPA/db/userRoot and that went smoothly but now I see this in /var/log/pki-ca/system: 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] Operation Error - netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] Null response control 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] Operation Error - netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] Null response control 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] Operation Error - netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] Null response control 10358.CRLIssuingPoint-MasterCRL - [08/Mar/2012:04:36:29 UTC] [3] [3] CRLIssuingPoint MasterCRL - Cannot create or store the first CRL in the internaldb. The internaldb could be down. Error LDAP operation failure - cn=MasterCRL,ou=crlIssuingPoints, ou=ca, o=ipaca
Re: [Freeipa-users] Extending IPA schema for Federation services.
Steven Jones wrote: Hi, Is it sensible/better to extend the scheme before I start adding users? or doesnt it matter? From my perspective extending a system in use carries risk and impact to users, so its seems safer to extend it before I have any users, even if its un-used for now/? If you do it later you may need to write a script to update all existing users with the missing objectclasses. Apart from that I dont knowfor now I would live with the extended schema for the userpopulating the fields would be something I would look at when its decided what we will be doingno one yet knows or at least have not told me what they will be doing. It matters depending on whether the attributes in those objectclasses are required or not. I suspect in the end we will draw the contents from AD with winsync? The list of attributes for winsync is currently hardcoded. or populate/inject it directly via our Oracle identity system..so I'm not sure we will need the ui / guiI dont expect to add content via it, I suspect I might need to fault find to make sure the data is there but I assume ldap search tools will return this anyway? Right, it is possible to use the IPA LDAP server as a data store, the framework need not know about these extra attributes. However for other sites they may well not have an AD or user provisioning system... regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 From: freeipa-users-boun...@redhat.com [freeipa-users-boun...@redhat.com] on behalf of Dmitri Pal [d...@redhat.com] Sent: Tuesday, 20 March 2012 9:19 a.m. To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] Extending IPA schema for Federation services. On 03/19/2012 03:58 PM, Steven Jones wrote: Hi, Im starting from scratch here so bear with me..ie I dont know a lot of thiswhich should be obvious Extending Easy? oh because it doesnt strike me as easy.. :/ Initially I am about to build our production IPA servers. These attributes are a requirement of the Federation system New Zealand wants to use and is probably the same for Australia. So I think the schema has to be done/extended for IPA to be viable in tertiary institutions in NZ, without it not many if anyone will use IPA they will stay with openldap. So each person should have these I think.they may not be used initially but once extended initially then I dont have to extend the schema later. What connects to these is an apache/tomcat front end. There are two aspects/functions to this, the IdP and the SdP. The Idp allows remote tertiary organisations to query us and say our user is we legitthey then use their LDAP to provide resources via the SdP. So the Idp provides an identity to remote ppl and the SdP provides access to a resource at our end. later I expect we will have to to the SdP bit got our high performance cluster and storage... It maybe a year or more before we actually use this, but it strikes me as sensible that these are done on initial build.I will put ina RH support case for this. We will probably also pull the actual fields/contents out of AD.not sure yet. The question is simple: how you plan to manage these attributes in IPA? Do you expect them to be a part of the UI/CLI or they should be hidden there and be managed via ldapmodify and other data sync tools? This make the whole difference especially the UI part. Depending upon these expectations the scope would be different. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 From: Rob Crittenden [rcrit...@redhat.com] Sent: Tuesday, 20 March 2012 2:55 a.m. To: Steven Jones Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] Extending IPA schema for Federation services. Steven Jones wrote: Hi, Is it possible to expand IPA's schema to do this? Adding the schema is easy, doing something with it is where things get interesting. What do you want to do with these attributes/objectclasses? rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Doubt on FreeIPA LDAP extensibility
Hi On Mon, Mar 19, 2012 at 6:44 PM, Simo Sorce s...@redhat.com wrote: On Mon, 2012-03-19 at 12:36 -0400, Simo Sorce wrote: On Mon, 2012-03-19 at 14:46 +0100, Marco Pizzoli wrote: On Mon, Mar 19, 2012 at 2:32 PM, Simo Sorce s...@redhat.com wrote: On Mon, 2012-03-19 at 13:51 +0100, Marco Pizzoli wrote: In attachment. You can find only one, but all of them are equivalent from this point. They are indeed seen as structural, even if my added schema file declare them as auxiliary. Can you attach the (sanitized) schema file you added to 389ds ? Already done on this thread. See my previous mail to Dmitri. Also can you run a ldapsearch command and search in the 'cn=schema' base ? This will give you back what 389ds sends to a client. This command searches for everything but uses an attribute filter to show only the objectclasses: ldapsearch -x -h server -b 'cn=schema' 'objectClasses' No need to attach everything return, just edit the result and attach only the results for your calsses. Ok, here it is: [root@freeipa01 ~]# ldapsearch -h 127.0.0.1 -x -Dcn=Directory Manager -s base -W -b cn=schema objectClasses|perl -0pe 's/\n //g' objectClasses: ( 1.3.6.1.4.1.36005.0.2.6.2 NAME 'xxxPeopleAttributes' DESC 'Definizione di attributi specifici per gli utenti XXX' STRUCTURAL MAY xxxUfficio ) objectClasses: ( 1.3.6.1.4.1.36005.0.2.6.3 NAME 'xxxGroupsAttributes' DESC 'Definizione di attributi specifici per i gruppi XXX' STRUCTURAL MAY ( xxxProgetto $ xxxAmbiente $ xxxTipoGruppo ) ) objectClasses: ( 1.3.6.1.4.1.36005.0.2.6.4 NAME 'xxxWebminAttributes' DESC 'Definizione di attributi specifici per gli oggetti Webmin' STRUCTURAL MAY xxxWebminAmbiente ) objectClasses: ( 1.3.6.1.4.1.36005.0.2.6.5 NAME 'xxxDB2GroupsAttributes' DESC 'Definizione di attributi specifici per i gruppi DB2' STRUCTURAL MAY xxxDB2GruppiPrivilegi ) objectClasses: ( 1.3.6.1.4.1.36005.0.2.6.1 NAME 'xxxAttributes' DESC 'Definizione di attributi specifici per utilizzo interno' STRUCTURAL MAY ( xxxProgetto $ xxxAmbiente $ xxxTipoGruppo $ xxxDB2GruppiPrivilegi ) ) By seeing this output, I just checked again and I confirm that in my file /etc/dirsrv/slapd-UNIX-MYDOMAIN-IT/schema/98myfile.ldif they are still AUXILIARY. This is odd, indeed, I will resurrect the bug you opened with a better description, thanks. Marco, I discussed this briefly with Nathan and it seem that it may be a parser error. 389DS parser is quite strict and wants the various definitions in the precise order they are defined in the RFCs. I guess that means that if you reorder where you define the type (AUXILIARY/STRUCTURAL) in the string you'll get the right behavior. As Is I think AUXILIARY is simply ignored because it is int eh wrong position and the default STRUCTURAL is used. If you can change your schema file to define AUS/STR in the right order (see other IPA ldif file for hints) and can confirm it is ano ordering problem we can open a documentation bug to explain this behavior until the underlying parser is improved to better handle random ordered definitions. Yes, I modified the position of the SUP top AUXILIARY part and now it's ok!! My use case was in converting a working OpenLDAP schema file with the script published on the 389-ds wiki[1]. I would ask/suggest/like/appreciate it being improved for dealing with this thing too... I'm not a programmer, in that case I would offer to do it... :-/ [1] http://directory.fedoraproject.org/download/ol-macro-expand.pl Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Problem in ipa migrate-ds procedure
On 03/19/2012 06:54 PM, Marco Pizzoli wrote: On Mon, Mar 19, 2012 at 8:31 PM, Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com wrote: Marco Pizzoli wrote: On Mon, Mar 19, 2012 at 2:42 PM, Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com wrote: Dmitri Pal wrote: On 03/17/2012 07:36 AM, Marco Pizzoli wrote: Hi guys, I'm trying to migrate my ldap user base to freeipa. I'm using the last Release Candidate. I already changed ipa config-mod --enable-migration=TRUE This is what I have: ipa -v migrate-ds --bind-dn=cn=manager,dc=__mydc1,dc=mydc2.it http://mydc2.it http://mydc2.it http://mydc2.it --user-container=ou=people,__dc=mydc1,dc=mydc2.it http://mydc2.it http://mydc2.it http://mydc2.it --user-objectclass=__inetOrgPerson --group-container=ou=groups,__dc=mydc1,dc=mydc2.it http://mydc2.it http://mydc2.it http://mydc2.it --group-objectclass=posixGroup --base-dn=dc=mydc1,dc=mydc2.__it http://mydc2.it http://mydc2.it --with-compat ldap://ldap01 ipa: INFO: trying https://freeipa01.unix.__mydomain.it/ipa/xml http://mydomain.it/ipa/xml https://freeipa01.unix.mydomain.it/ipa/xml Password: ipa: INFO: Forwarding 'migrate_ds' to server u'http://freeipa01.unix.__mydomain.it/ipa/xml http://mydomain.it/ipa/xml http://freeipa01.unix.mydomain.it/ipa/xml' ipa: ERROR: Container for group not found at ou=groups,dc=mydc1,dc=mydc2.it http://mydc2.it http://mydc2.it http://mydc2.it I looked at my ldap server logs and I found out that the search executed has scope=1. Actually both for users and groups. This is a problem for me, in having a lot of subtrees (ou) in which my users and groups are. Is there a way to manage this? Thanks in advance Marco P.s. As a side note, I suppose there's a typo in the verbose message I obtain in my output: ipa: INFO: Forwarding 'migrate_ds' to server *u*'http://freeipa01.unix.__mydomain.it/ipa/xml http://mydomain.it/ipa/xml http://freeipa01.unix.mydomain.it/ipa/xml' Please open tickets for both issues. Well, I don't think either is a bug. If you have users/groups in multiple places you'll need to migrate them individually for now. It is safe to run migrate-ds multiple times, existing users are not migrated. I just re-executed by specifing a nested ou for my groups. This is what I got: ipa: INFO: trying https://freeipa01.unix.csebo.it/ipa/xml ipa: INFO: Forwarding 'migrate_ds' to server u'http://freeipa01.unix.csebo.it/ipa/xml' --- migrate-ds: --- Migrated: Failed user: fw03075_no: Type or value exists: [other users listed] Failed group: pdbac32: Type or value exists: [other groups listed] -- 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. I don't understand what it's trying to telling me. On my FreeIPA ldap server I don't see any imported user. What's my fault here? The u is a python-ism for unicode. This is not a bug. Please, could you give a little more detail on this? It's only a hint on what that data represents in a Python variable? Thanks again Marco Type or value exists occurs when one tries to add an attribute value to an entry that already exists. I suspect that the underlying problem is different between users and groups. For groups it is likely adding a duplicate member. For users I'm not really sure. It could be one of the POSIX attributes. What does a failed entry look like? rob
