* mailRoutingAddress
* mailHost
* inetLocalMailRecipient
* kerberosSecurityObject
* krbName
Is not having these in my schema common/normal?
I'm sure there's plenty of directories out there that don't maintain
these attributes on account objects.
If all you want to do is import the UNIX /etc/passwd attributes, you
definitely don't need these.
Mont Rothstein wrote:
Thank you for your reply.
I grabbed the migration scripts from http://www.padl.com/download/
because I wanted to avoid installing openldap when all I needed was
the scripts.
Looking at the source the kerberosSecurityObject is inserted as long
as there is a default realm, though the extended schema does cause a
problem with mail related values (see below).
It sounds like what I was missing is the fact that editing the
migration scripts is expected. I was under the impression that if my
migration didn't work it was a mistake I had made.
After commenting out the following items in the password_migration
script my admin user finally added:
* mailRoutingAddress
* mailHost
* inetLocalMailRecipient
* kerberosSecurityObject
* krbName
Is not having these in my schema common/normal?
Thanks,
-Mont/
/
On 3/24/06, *Craig White* < craigwhite@xxxxxxxxxxx
<mailto:craigwhite@xxxxxxxxxxx>> wrote:
On Fri, 2006-03-24 at 10:26 -0800, Mont Rothstein wrote:
> A suggestion was made that I should add the contents of my
> sambaAdmin.ldif file to this post. They are below.
>
> The kerberosSecurityObject isn't in my schema, so thus the
error. But
> why did migrate_password.pl put that in my ldif? Is there a config
> option somewhere that should be switched to disable Kerberos or do I
> just need to manually edit the ldif and delete the offending line?
>
> Thanks,
> -Mont
>
>
> dn: uid=Administrator,ou=People,dc=forayadams,dc=foray,dc=com
> uid: Administrator
> cn: Samba Admin
> givenName: Samba
> sn: Admin
> mail: Administrator@xxxxxxxxxxxxxxxxxxxx
<mailto:Administrator@xxxxxxxxxxxxxxxxxxxx>
> mailRoutingAddress: Administrator@xxxxxxxxxxxxxxxxxxxxxxxxx
<mailto:Administrator@xxxxxxxxxxxxxxxxxxxxxxxxx>
> mailHost: mail.forayadams.foray.com
<http://mail.forayadams.foray.com>
> objectClass: inetLocalMailRecipient
> objectClass: person
> objectClass: organizationalPerson
> objectClass: inetOrgPerson
> objectClass: posixAccount
> objectClass: top
> objectClass: kerberosSecurityObject
> userPassword: {crypt}x
> krbName: Administrator@xxxxxxxxxxxxxxxxxxxx
<mailto:Administrator@xxxxxxxxxxxxxxxxxxxx>
> loginShell: /bin/bash
> uidNumber: 0
> gidNumber: 0
> homeDirectory: /root
> gecos: Samba Admin
----
the option of course is yours.
If you read through the source within the padl migration scripts (I'm
assuming that you used the ones installed by openldap-server package
from the distribution, you will probably notice how and why it is put
there...presumably because you have chosen to use an extended schema.
I think the object is to test, tune, test, tune until you get what you
want from the migration scripts.
I suspect the reasons no one else answered this question was that the
source isn't part of FDS, the DSA setup will be as you design it to be
and the source is lightweight and should be simple enough to
comprehend
and adjust as needed.
Craig
--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
<mailto:Fedora-directory-users@xxxxxxxxxx>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
<https://www.redhat.com/mailman/listinfo/fedora-directory-users>
------------------------------------------------------------------------
--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users
--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users
