[gpfsug-discuss] Samba (rid) -> CES (autorid) migration

[Fey, Christian]

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: christian.fey at sva.de<mailto:christian.fey at sva.de>
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 <gpfsug-discuss at spectrumscale.org>
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 at 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: christian.fey at sva.de<mailto:christian.fey at sva.de>
http://www.sva.de


Geschäftsführung: Philipp Alexander, Sven Eichelbaum
Sitz der Gesellschaft: Wiesbaden
Registergericht: Amtsgericht Wiesbaden, HRB 10315

Von: gpfsug-discuss-bounces at spectrumscale.org<mailto:gpfsug-discuss-bounces at spectrumscale.org> [mailto:gpfsug-discuss-bounces at spectrumscale.org] Im Auftrag von Varun Mittal3
Gesendet: Montag, 15. Mai 2017 20:39
An: gpfsug main discussion list <gpfsug-discuss at spectrumscale.org<mailto:gpfsug-discuss at spectrumscale.org>>
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" <Christian.Fey at sva.de<mailto:Christian.Fey at sva.de>>
To: gpfsug main discussion list <gpfsug-discuss at spectrumscale.org<mailto:gpfsug-discuss at spectrumscale.org>>
Date: 11/05/2017 09:07 PM
Subject: [gpfsug-discuss] Samba (rid) -> CES (autorid) migration
Sent by: gpfsug-discuss-bounces at spectrumscale.org<mailto:gpfsug-discuss-bounces at spectrumscale.org>

________________________________



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: christian.fey at sva.de<mailto:christian.fey at sva.de>
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20170517/69ec0188/attachment-0002.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 105 bytes
Desc: image001.gif
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20170517/69ec0188/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5467 bytes
Desc: not available
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20170517/69ec0188/attachment-0002.bin>