There are a few points to consider here: CES uses Samba in cluster mode with ctdb. That means that the tdb database is shared through ctdb on all protocol nodes, and the internal format is slightly different since it contains additional information for tracking the cross-node status of the individual records.
Spectrum Scale officially supports the autorid module for internal id mapping. That approach is different than the older idmap_tdb since it basically only has one record per AD domain, and not one record per user or group. This is known to scale better in environments where many users and groups require id mappings. The downside is that data from idmap_tdb cannot be directly imported. While not officially supported Spectrum Scale also ships the idmap_tdb module. You could configure authentication and internal id mapping on Spectrum Scale, and then overwrite the config manually to use the old idmap module (the idmap-range-size is required, but not relevant later on): mmuserauth service create ... --idmap-range 1000000-9000000 --idmap-range-size 100000 /usr/lpp/mmfs/bin/net conf setparm global 'idmap config * : backend' tdb mmdsh -N CesNodes systemctl restart gpfs-winbind mmdsh -N CesNodes /usr/lpp/mmfs/bin/net cache flush With the old Samba, export the idmap data to a file: net idmap dump > idmap-dump.txt And on a node running CES Samba import that data, and remove any old cached entries: /usr/lpp/mmfs/bin/net idmap restore idmap-dump.txt mmdsh -N CesNodes /usr/lpp/mmfs/bin/net cache flush Just to be clear: This is untested and if there is a problem with the id mapping in that configuration, it will likely be pointed to the unsupported configuration. The way to request this as an official feature would be through a RFE, although i cannot say whether that would be picked up by product management. Another option would be creating the id mappings in the Active Directory records or in a external LDAP server based on the old mappings, and point the CES Samba to that data. That would again be a supported configuration. Regards, Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZ christof.schm...@us.ibm.com || +1-520-799-2469 (T/L: 321-2469) From: Shaun Anderson <sander...@convergeone.com> To: Christof Schmitt/Tucson/IBM@IBMUS Cc: gpfsug main discussion list <gpfsug-discuss@spectrumscale.org> Date: 08/18/2016 11:11 AM Subject: RE: [gpfsug-discuss] Migrate 3.5 to 4.2 and LTFSEE toSpectrumArchive Correct. We are upgrading their existing configuration and want to switch to CES provided Samba. They are using Samba 3.6.24 currently on RHEL 6.6. Here is the head of the smb.conf file: =================================================== [global] workgroup = SL1 netbios name = SLTLTFSEE server string = LTFSEE Server realm = removed.ORG security = ads encrypt passwords = yes default = global browseable = no socket options = TCP_NODELAY SO_KEEPALIVE TCP_KEEPCNT=4 TCP_KEEPIDLE=240 TCP_KEEPINTVL=15 idmap config * : backend = tdb idmap config * : range = 1000000-9000000 template shell = /bash/bin writable = yes allow trusted domains = yes client ntlmv2 auth = yes auth methods = guest sam winbind passdb backend = tdbsam groupdb:backend = tdb interfaces = eth1 lo username map = /etc/samba/smbusers map to guest = bad uid guest account = nobody ===================================================== Does that make sense? Regards, SHAUN ANDERSON STORAGE ARCHITECT O 208.577.2112 M 214.263.7014 -----Original Message----- From: gpfsug-discuss-boun...@spectrumscale.org [ mailto:gpfsug-discuss-boun...@spectrumscale.org] On Behalf Of Christof Schmitt Sent: Thursday, August 18, 2016 11:50 AM To: gpfsug main discussion list <gpfsug-discuss@spectrumscale.org> Subject: Re: [gpfsug-discuss] Migrate 3.5 to 4.2 and LTFSEE toSpectrumArchive Samba as supported in Spectrum Scale uses the "autorid" module for creating internal id mappings (see man idmap_autorid for some details). Officially supported are also methods to retrieve id mappings from an external server: https://www.ibm.com/support/knowledgecenter/en/STXKQY_4.2.1/com.ibm.spectrum.scale.v4r21.doc/bl1adm_adfofile.htm The earlier email states that they have a " .tdb backend for id mapping on their current server. ". How exactly is that configured in Samba? Which Samba version is used here? So the plan is to upgrade the cluster, and then switch to the Samba version provided with CES? Should the same id mappings be used? Regards, Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZ christof.schm...@us.ibm.com || +1-520-799-2469 (T/L: 321-2469) From: Shaun Anderson <sander...@convergeone.com> To: gpfsug main discussion list <gpfsug-discuss@spectrumscale.org> Date: 08/17/2016 06:52 PM Subject: Re: [gpfsug-discuss] Migrate 3.5 to 4.2 and LTFSEE to Spectrum Archive Sent by: gpfsug-discuss-boun...@spectrumscale.org We are currently running samba on the 3.5 node, but wanting to migrate everything into using CES once we get everything up to 4.2. SHAUN ANDERSON STORAGE ARCHITECT O 208.577.2112 M 214.263.7014 From: gpfsug-discuss-boun...@spectrumscale.org <gpfsug-discuss-boun...@spectrumscale.org> on behalf of Yaron Daniel <y...@il.ibm.com> Sent: Wednesday, August 17, 2016 5:11 PM To: gpfsug main discussion list Subject: Re: [gpfsug-discuss] Migrate 3.5 to 4.2 and LTFSEE to Spectrum Archive Hi Do u use CES protocols nodes ? Or Samba on each of the Server ? Regards Yaron Daniel 94 Em Ha'Moshavot Rd Server, Storage and Data Services- Team Leader Petach Tiqva, 49527 Global Technology Services Israel Phone: +972-3-916-5672 Fax: +972-3-916-5672 Mobile: +972-52-8395593 e-mail: y...@il.ibm.com IBM Israel From: Shaun Anderson <sander...@convergeone.com> To: "gpfsug-discuss@spectrumscale.org" <gpfsug-discuss@spectrumscale.org> Date: 08/18/2016 12:11 AM Subject: [gpfsug-discuss] Migrate 3.5 to 4.2 and LTFSEE to Spectrum Archive Sent by: gpfsug-discuss-boun...@spectrumscale.org I am in process of migrating from 3.5 to 4.2 and LTFSEE to Spectrum Archive. 1 node cluster (currently) connected to V3700 storage and TS4500 backend. We have upgraded their 2nd node to 4.2 and have successfully tested joining the domain, created smb shares, and validated their ability to access and control permissions on those shares. They are using .tdb backend for id mapping on their current server. I'm looking to discuss with someone the best method of migrating those tdb databases to the second server, or understand how Spectrum Scale does id mapping and where it stores that information. Any hints would be greatly appreciated. Regards, SHAUN ANDERSON STORAGE ARCHITECT O208.577.2112 M214.263.7014 NOTICE: This email message and any attachments here to may contain confidential information. Any unauthorized review, use, disclosure, or distribution of such information is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy the original message and all copies of it._______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss NOTICE: This email message and any attachments here to may contain confidential information. Any unauthorized review, use, disclosure, or distribution of such information is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy the original message and all copies of it._______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss _______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss NOTICE: This email message and any attachments here to may contain confidential information. Any unauthorized review, use, disclosure, or distribution of such information is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy the original message and all copies of it. _______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss