I just got the information that there is a debugging switch for the "net" commands (-d10).
Looks like the issue with setting the ranges is caused by my lab setup (complains that the ranges are still present). I will try again with a scratched config and report back. Mit freundlichen Grüßen / Best Regards Christian Fey SVA System Vertrieb Alexander GmbH Borsigstraße 14 65205 Wiesbaden Tel.: +49 6122 536-0 Fax: +49 6122 536-399 Mobil: +49 151 180 251 39 E-Mail: [email protected]<mailto:[email protected]> http://www.sva.de Geschäftsführung: Philipp Alexander, Sven Eichelbaum Sitz der Gesellschaft: Wiesbaden Registergericht: Amtsgericht Wiesbaden, HRB 10315 Von: Fey, Christian Gesendet: Mittwoch, 17. Mai 2017 21:10 An: gpfsug main discussion list <[email protected]> Betreff: AW: [gpfsug-discuss] Samba (rid) -> CES (autorid) migration Hi, we have an existing filesystem and want to move from homebrew Samba/CTDB to CES. Since there is a lot of data in it, relabeling / migrating is not an option. FS stays the same, only nodes that share the FS change. There is an option to change the range (delete the existing ranges, set the new ones) with "net idmap set range" but in my Lab setup I was not successful in changing it. --cut-- [root@gpfs4n1 src]# /usr/lpp/mmfs/bin/net idmap set range 0 S-1-5-21-123456789-... Failed to save domain mapping: NT_STATUS_INVALID_PARAMETER --cut-- Mit freundlichen Grüßen / Best Regards Christian Fey SVA System Vertrieb Alexander GmbH Borsigstraße 14 65205 Wiesbaden Tel.: +49 6122 536-0 Fax: +49 6122 536-399 Mobil: +49 151 180 251 39 E-Mail: [email protected]<mailto:[email protected]> http://www.sva.de Geschäftsführung: Philipp Alexander, Sven Eichelbaum Sitz der Gesellschaft: Wiesbaden Registergericht: Amtsgericht Wiesbaden, HRB 10315 Von: [email protected]<mailto:[email protected]> [mailto:[email protected]] Im Auftrag von Varun Mittal3 Gesendet: Montag, 15. Mai 2017 20:39 An: gpfsug main discussion list <[email protected]<mailto:[email protected]>> Betreff: Re: [gpfsug-discuss] Samba (rid) -> CES (autorid) migration Hi Christian Is the data on existing cluster being accesses only through SMB or is it shared with NFS users having same UID/GIDs ? What mechanism would you be using to migrate the data ? I mean, if it's pure smb and the data migration would also be over smb share only (using tool like robocopy), you need not have the same IDs on both the source and the target system. Best regards, Varun Mittal Cloud/Object Scrum @ Spectrum Scale ETZ, Pune [Inactive hide details for "Fey, Christian" ---11/05/2017 09:07:57 PM---Hi all, I'm just doing a migration from a gpfs cluster w]"Fey, Christian" ---11/05/2017 09:07:57 PM---Hi all, I'm just doing a migration from a gpfs cluster with samba/ctdb to CES protocol nodes. The ol From: "Fey, Christian" <[email protected]<mailto:[email protected]>> To: gpfsug main discussion list <[email protected]<mailto:[email protected]>> Date: 11/05/2017 09:07 PM Subject: [gpfsug-discuss] Samba (rid) -> CES (autorid) migration Sent by: [email protected]<mailto:[email protected]> ________________________________ Hi all, I'm just doing a migration from a gpfs cluster with samba/ctdb to CES protocol nodes. The old ctdb cluster uses rid as idmap backend. Since CES officially supports only autorid, I tried to choose the right values for the idmap ranges / sizes to get the same IDs but was not successful with this. The old samba has a range assigned for their Active directory (idmap config XYZ : range = 1000000-1999999) My idea was to set autorid to the following during mmuserauth create: idmap config * : backend = autorid idmap config * : range = 200000-2999999 idmap config * : rangesize = 800000 With that it should use the first range for the builtin range and the second should then start with 1000000 like in the old rid config. Sadly, the range of the domain is the third one: /usr/lpp/mmfs/bin/net idmap get ranges RANGE 0: ALLOC RANGE 1: S-1-5-32 RANGE 2: S-1-5-21-123456789-123456789-123456789 Does anyone have an idea how to fix this, maybe in a supported way and without storing the IDs in the domain? Further on, does anyone use rid as backend, even if not officially supported? Maybe we could file a RPQ or sth. Like this. Mit freundlichen Grüßen / Best Regards Christian Fey SVA System Vertrieb Alexander GmbH Borsigstraße 14 65205 Wiesbaden Tel.: +49 6122 536-0 Fax: +49 6122 536-399 E-Mail: [email protected]<mailto:[email protected]> http://www.sva.de<http://www.sva.de/> Geschäftsführung: Philipp Alexander, Sven Eichelbaum Sitz der Gesellschaft: Wiesbaden Registergericht: Amtsgericht Wiesbaden, HRB 10315 [attachment "smime.p7s" deleted by Varun Mittal3/India/IBM] _______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
