[Freeipa-users] FreeIPA and Samba4
Sumit Bose
sbose at redhat.com
Wed Nov 4 15:03:46 UTC 2015
On Wed, Nov 04, 2015 at 03:34:49PM +0100, Troels Hansen wrote:
> OK, i have gotten my SID generation to run.
> However, on the migrated users I'm unable to do a pdbedit -L
> I get:
>
> pdbedit -Lv th
do you see any more details if you run pdbedit with '-d 255' ?
> doing parameter max log size = 50
> doing parameter add machine script = /usr/sbin/smbldap-useradd -w "%u"
> doing parameter socket options = TCP_NODELAY IPTOS_LOWDELAY SO_SNDBUF=8192 SO_RCVBUF=8192
> doing parameter printing = cups
> doing parameter printcap name = /etc/printcap
> doing parameter load printers = no
> pm_process() returned Yes
> No builtin backend found, trying to load plugin
> Module 'ipasam' loaded
> smbldap_open_connection: connection opened
> ldap_connect_system: successful connection to the LDAP server
> The LDAP server is successfully connected
> pdb_init_ipasam: support for pdb_enum_upn_suffixes enabled for domain casalogic.lan
> init_sam_from_ldap: Entry found for user: th
> Segmentation fault
Can you send me a full backtrace of the core or the whole core file with
the version of the samba.common package?
>
> on the users generated directly in IPA it works.
>
> [root at tinkerbell ~]# pdbedit -Lv kk
>
> I get the same error when calling pdbedit on IPA or differnet Samba server connected with ipasam.
>
> Only difference I can see is that the users causing segfault have a RID from primary range, and the users working have from secondary range, so I suspect that something have gone wrong in my shifting round in the ranges and this somehow causes ipasam to segfault.
>
> Could I just delete the ipaNTSecurityIdentifier directly in LDAP and let the SID generation run again, or do someone have a good idea to have the SID's reset?
You can try but I doubt that it will help.
ipasam was written primarily with the IPA use-case in mind, so chance
are that we run into some unexpected behaviour when it is used in other
context. Nevertheless it should be fixed if there is an issue in ipasam.
bye,
Sumit
>
> ----- On Nov 3, 2015, at 8:06 PM, Troels Hansen th at casalogic.dk wrote:
>
> > Hi, I got a bit further.
> > I fount the error, being that I had some groups from the old LDAP with gid aroud
> > 500, and current ID range i IPA sat to start at 2000, which was my start UID on
> > the old LDAP.
> >
> > Is it possible to "reset" the base UID/GID that IPA assigns to the next user? I
> > can't find it saved in the LDAP anywhere?
> >
> > ----- On Nov 3, 2015, at 1:36 PM, Sumit Bose sbose at redhat.com wrote:
> >
> >> On Tue, Nov 03, 2015 at 01:09:53PM +0100, Troels Hansen wrote:
> >>> Hi again, so I finally got time to look further into this.
> >>>
> >>> This task works:
> >>>
> >>> dn: cn=$TIME-$FQDN-$LIBARCH,cn=ipa-sidgen-task,cn=tasks,cn=config
> >>> add:objectclass:top,extensibleObject
> >>> add:cn:$TIME-$FQDN-$LIBARCH
> >>> add:nsslapd-basedn:"$SUFFIX"
> >>> add:delay:0
> >>> add:ttl:3600
> >>>
> >>> However, the task gets generated, but no output can be pulled from the task:
> >>>
> >>> ldapsearch -D "cn=Directory Manager" -W -b
> >>> 'cn=1446551851-kenai.casalogic.lan-64,cn=ipa-sidgen-task,cn=tasks,cn=config'
> >>> Enter LDAP Password:
> >>> # extended LDIF
> >>> #
> >>> # LDAPv3
> >>> # base
> >>> <cn=1446551851-kenai.casalogic.lan-64,cn=ipa-sidgen-task,cn=tasks,cn=config>
> >>> with scope subtree
> >>> # filter: (objectclass=*)
> >>> # requesting: ALL
> >>> #
> >>>
> >>> # 1446551851-kenai.casalogic.lan-64, ipa-sidgen-task, tasks, config
> >>> dn: cn=1446551851-kenai.casalogic.lan-64,cn=ipa-sidgen-task,cn=tasks,cn=config
> >>> objectClass: top
> >>> objectClass: extensibleObject
> >>> nsslapd-basedn: dc=casalogic,dc=lan
> >>> delay: 0
> >>> cn: 1446551851-kenai.casalogic.lan-64
> >>> ttl: 3600
> >>> nstaskcurrentitem: 1
> >>> nstasktotalitems: 1
> >>> nstaskexitcode: 32
> >>>
> >>> # search result
> >>> search: 2
> >>> result: 0 Success
> >>>
> >>> # numResponses: 2
> >>> # numEntries:
> >>>
> >>> Only a exitcode 32
> >>> The nstaskcurrentitem and nstasktotalitems remains the same till the task
> >>> disappeares.
> >>> Any way do debug these taske further to find out which user it stops at, as it
> >>> looks like it detects an error at one user and stops the task?
> >>
> >> You can activate 'Plug-in debugging' by setting the
> >> nsslapd-errorlog-level attribute of cn=config to 65536, see
> >> http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting for
> >> details. Make sure to switch it back to 0 after running the sidgen task
> >> because the logging is quite expensive.
> >>
> >> HTH
> >>
> >> bye,
> >> Sumit
> >>
> >>>
> >>> ----- On Oct 30, 2015, at 3:19 PM, Alexander Bokovoy abokovoy at redhat.com wrote:
> >>>
> >>> > On Fri, 30 Oct 2015, Troels Hansen wrote:
> >>> >>
> >>> >>
> >>> >>
> >>> >>> I think it should be
> >>> >>> add:nsslapd-basedn: cn=accounts,$SUFFIX
> >>> >>> not
> >>> >>> add:basedn:"cn=accounts,$SUFFIX"
> >>> >>>
> >>> >>> this is what sidgen task expects and it returns constraint violation
> >>> >>> error if parameters are wrong:
> >>> >>>
> >>> >>> str = fetch_attr(e, "nsslapd-basedn", NULL);
> >>> >>> if (str == NULL) {
> >>> >>> LOG_FATAL("Missing nsslapd-basedn!\n");
> >>> >>> *returncode = LDAP_CONSTRAINT_VIOLATION;
> >>> >>> ret = SLAPI_DSE_CALLBACK_ERROR;
> >>> >>> goto done;
> >>> >>> }
> >>> >>>
> >>> >>
> >>> >>I think you are right.
> >>> >>Don't know what I have tested, but it brings me a different error, that I didn't
> >>> >>see before:
> >>> >>
> >>> >>ipa.ipapython.ipaldap.IPAdmin: DEBUG: Unhandled LDAPError: OPERATIONS_ERROR:
> >>> >>{'desc': 'Operations error'}
> >>> >>ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR: Add failure Operations
> >>> >>error:
> >>> >>ipa.ipaserver.install.ipa_ldap_updater.LDAPUpdater_NonUpgrade: INFO: The
> >>> >>ipa-ldap-updater command was successful
> >>> >>
> >>> >>Where did you find the source for the sidgen task? I could try looking at at it
> >>> >>myself, but can't find it.
> >>> > You can check it here:
> >>> > https://git.fedorahosted.org/cgit/freeipa.git/tree/daemons/ipa-slapi-plugins/ipa-sidgen/ipa_sidgen_task.c#n221
> >>> >
> >>> > --
> >>> > / Alexander Bokovoy
> >>>
> >>> --
> >>> Med venlig hilsen
> >>>
> >>> Troels Hansen
> >>>
> >>> Systemkonsulent
> >>>
> >>> Casalogic A/S
> >>>
> >>>
> >>> T (+45) 70 20 10 63
> >>>
> >>> M (+45) 22 43 71 57
> >>>
> >>> Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og
> >>> meget mere.
> >>>
> >>> --
> >>> Manage your subscription for the Freeipa-users mailing list:
> >>> https://www.redhat.com/mailman/listinfo/freeipa-users
> >> > Go to http://freeipa.org for more info on the project
> >
> > --
> > Med venlig hilsen
> >
> > Troels Hansen
> >
> > Systemkonsulent
> >
> > Casalogic A/S
> >
> >
> > T (+45) 70 20 10 63
> >
> > M (+45) 22 43 71 57
> >
> > Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og
> > meget mere.
> >
> > --
> > Manage your subscription for the Freeipa-users mailing list:
> > https://www.redhat.com/mailman/listinfo/freeipa-users
> > Go to http://freeipa.org for more info on the project
>
> --
> Med venlig hilsen
>
> Troels Hansen
>
> Systemkonsulent
>
> Casalogic A/S
>
>
> T (+45) 70 20 10 63
>
> M (+45) 22 43 71 57
>
> Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og meget mere.
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
More information about the Freeipa-users
mailing list