Re: [gpfsug-discuss] 'force user' samba parameter not implemented
Hi Paul, > We are moving from our v4 SCALE install to a 5.0.5 SCALE install.> We make extensive use of the ‘force user’ parameter in our cross> protocol shares.> I have just been informed, that although we can set the parameter> using ‘net conf’ it isn’t implemented in the current version of> Samba in v5.0.5 of SCALE. This config option is not tested and not supported as part of SpectrumScale. Only SMB/Samba config parameters that are accessible throughthe GUI or mmsmb CLI are officially supported. If you have a usecaserequiring support for additional Samba parameters, the proper way torequest support is through a RFE. That said, i do not see why the Samba behavior would change here fromv4 to v5. If you want to debug this, i would suggest to recreate theproblem with this parameter in place while capturing a SMB trace(mmprotocoltrace start smb). The SMB trace should then have sufficientinformation to determine why the owner of the file is not as expected. Regards, Christof Schmitt Software Engineer IBM Systems, Spectrum Scale Development +1 520 799 2469 christof.schm...@us.ibm.com @chsc Twitter IBM - Original message -From: "Paul Ward" Sent by: gpfsug-discuss-boun...@spectrumscale.orgTo: "gpfsug-discuss@spectrumscale.org" Cc:Subject: [EXTERNAL] [gpfsug-discuss] 'force user' samba parameter not implementedDate: Tue, Aug 24, 2021 3:04 AM Hi, We are moving from our v4 SCALE install to a 5.0.5 SCALE install. We make extensive use of the ‘force user’ parameter in our cross protocol shares. I have just been informed, that although we can set the parameter using ‘net conf’ it isn’t implemented in the current version of Samba in v5.0.5 of SCALE. Has anyone else faced this issue, and what has been your workaround. Kindest regards, Paul Paul Ward TS Infrastructure Architect Natural History Museum T: 02079426450 E: p.w...@nhm.ac.uk ___gpfsug-discuss mailing listgpfsug-discuss at spectrumscale.orghttp://gpfsug.org/mailman/listinfo/gpfsug-discuss ___ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
Re: [gpfsug-discuss] Limiting CES SMB shares to specific subnets
> Project SMB shares have export ACLs (as in "mmsmb exportacl ..")> limiting share access to the project's member group, in addition to the> NFSv4 ACLs.>> We also want to limit access to SMB shares to project subnets.> There is no way to specify that with "mmsmb", but we have found>> /usr/lpp/mmfs/bin/net conf setparm "hosts allow" >> to be working, at least with some limited testing: share access is> actually limited to the specified subnets. The additional settings> seems to be stored in CTDB under /var/lib/ctdb/persistent.>> We assume that the "net conf setparm" method is not officially supported> by IBM. Although it seems to be working, we wonder if it is a good idea> to implement it. For instance, we are wondering if the additional> settings will survive later ESS code upgrades, and if it will scale to> thousands of SMB shares. Officially Scale only supports Samba options that can be set throughthe GUI or the mmsmb CLI. Everything else set through 'net conf' hasnot been tested and is not supported. In this specific case, this islikely to work, and it should also be preserved across code upgrades,but again, this is not an official support statement. This is also not a new request, there is also a pending RFE to makethis an official Scale feature:https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=141534 Regards, Christof Schmitt Software Engineer IBM Systems, Spectrum Scale Development +1 520 799 2469 christof.schm...@us.ibm.com @chsc Twitter IBM - Original message -From: Helge Hauglin Sent by: gpfsug-discuss-boun...@spectrumscale.orgTo: gpfsug-discuss@spectrumscale.orgCc:Subject: [EXTERNAL] [gpfsug-discuss] Limiting CES SMB shares to specific subnetsDate: Tue, Feb 9, 2021 9:10 AM Hi.We have an ESS 5.0.4.3 cluster with a CES cluster serving files withNFSv4 ACLs to NFS and SMB clients. This system is used forsensitive research data, and will the next years house thousands ofresearch projects, which will have to be strictly separated. Eachproject has its own subnet for the project linux and windows hosts.Project directories are independent filesets in file systems, eachproject directory has NFSv4 ACLs giving acces to only the project group.Project NFS shares are limited to each project's subnet.Project SMB shares have export ACLs (as in "mmsmb exportacl ..")limiting share access to the project's member group, in addition to theNFSv4 ACLs.We also want to limit access to SMB shares to project subnets.There is no way to specify that with "mmsmb", but we have found /usr/lpp/mmfs/bin/net conf setparm "hosts allow" to be working, at least with some limited testing: share access isactually limited to the specified subnets. The additional settingsseems to be stored in CTDB under /var/lib/ctdb/persistent.We assume that the "net conf setparm" method is not officially supportedby IBM. Although it seems to be working, we wonder if it is a good ideato implement it. For instance, we are wondering if the additionalsettings will survive later ESS code upgrades, and if it will scale tothousands of SMB shares.We are considering doing the SMB subnet limiting outside CES, but that wouldadd complexity and overhead, so we are not very keen on that.What do other IBM ESS customers do, do you have any advice for us?Yea or nay?Regards,Helge HauglinMr. Helge Hauglin, Senior EngineerSystem administratorCenter for Information Technology, University of Oslo, Norway___gpfsug-discuss mailing listgpfsug-discuss at spectrumscale.orghttp://gpfsug.org/mailman/listinfo/gpfsug-discuss ___ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
Re: [gpfsug-discuss] Change uidNumber and gidNumber for billions of files
If there are ACLs, then you also need to update all ACLs (gpfs_getacl(), update uids and gids in all entries, gpfs_putacl()), in addition to the chown() call. Regards, Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZchristof.schm...@us.ibm.com || +1-520-799-2469 (T/L: 321-2469) - Original message -From: Jim Doherty Sent by: gpfsug-discuss-boun...@spectrumscale.orgTo: gpfsug main discussion list Cc:Subject: [EXTERNAL] Re: [gpfsug-discuss] Change uidNumber and gidNumber for billions of filesDate: Mon, Jun 8, 2020 5:57 PM You will need to do this with chown from the c library functions (could do this from perl or python). If you try to change this from a shell script you will hit the Linux command which will have a lot more overhead. I had a customer attempt this using the shell and it ended up taking forever due to a brain damaged NIS service :-). Jim On Monday, June 8, 2020, 2:01:39 PM EDT, Lohit Valleru wrote: Hello Everyone, We are planning to migrate from LDAP to AD, and one of the best solution was to change the uidNumber and gidNumber to what SSSD or Centrify would resolve. May I know, if anyone has come across a tool/tools that can change the uidNumbers and gidNumbers of billions of files efficiently and in a reliable manner? We could spend some time to write a custom script, but wanted to know if a tool already exists. Please do let me know, if any one else has come across a similar situation, and the steps/tools used to resolve the same. Regards, Lohit___gpfsug-discuss mailing listgpfsug-discuss at spectrumscale.orghttp://gpfsug.org/mailman/listinfo/gpfsug-discuss ___gpfsug-discuss mailing listgpfsug-discuss at spectrumscale.orghttp://gpfsug.org/mailman/listinfo/gpfsug-discuss ___ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
Re: [gpfsug-discuss] CIFS protocol access does not honor secondary groups
The first guess here would be missing id mappings. The id mapping forthe user and the user's primary group is a hard requirement, withoutthem the user cannot even logon to the SMB server. Missing id mappingsfor secondary groups are simply ignored. A few things to check would be: How are authentication and id mapping configured (mmuserauth)? Which groups are affected? Is it possible to manually query id mappings for these? If that does not point to the problem, i would suggest to recreate theaccess problem while capturing a SMB and a winbind trace (throughmmprotocoltrace). Upload these traces together with a snap to asupport ticket and we use that as a starting point for debugging. Regards, Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZchristof.schm...@us.ibm.com || +1-520-799-2469 (T/L: 321-2469) - Original message -From: David Johnson Sent by: gpfsug-discuss-boun...@spectrumscale.orgTo: gpfsug main discussion list Cc:Subject: [EXTERNAL] [gpfsug-discuss] CIFS protocol access does not honor secondary groupsDate: Wed, Oct 2, 2019 10:02 AM After converting from clustered CIFS to CES protocols, we’ve noticed that SMBusers can’t access files owned by groups that they are members of, unless thatgroup happens to be their primary group. Have read the smb.conf man page,and don’t see anything obvious that would control this… What might we be missing?Thanks, — ddjDave JohnsonBrown University CCV/CIS___gpfsug-discuss mailing listgpfsug-discuss at spectrumscale.orghttp://gpfsug.org/mailman/listinfo/gpfsug-discuss ___ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
Re: [gpfsug-discuss] Question concerning integration of CES with AD authentication system
Mark, to answer your questions: > I see this is refering to UNIX attributes within AD, but I'm curious about mapping to attributes in LDAP.>> => This gets mapped to 'idmap config ... : unix_primary_group' in the> => internal config.>> Does that correspond to setting the smb.conf parameter>> unix_primary_group = yes This corresponds to the smb.conf parameter 'idmap config DOMAIN :unix_primary_group' = yes. This refers to the id mapping configurationfor the specified domain. See the idmap_ad man page for the Sambadocumentation of this parameter. > Specifically, under Spectrum Scale 5.0.2, if I run:>> mmuserauth service create --data-access-method file --ldapmap-domains "DOMAIN(type=stand-alone:ldap_srv=ldapserver:range=1001-65535:usr_dn=ou=People,dc=DC,dc=TLD:grp_dn=ou=Group,dc=DC,dc=TLD)" --type ad>> (some args removed in this example), will that map the user's primary group to>> the primaryGroupID supplied by AD> or> the primaryGroupID LDAP field> or> the gidNumber LDAP field This primary group in this configuration is the primary group inActive Directory. This is stored in Active Directory in theprimaryGroupID field that refers to the RID of the primary group (thelast part of the SID of the group). This id mapping method currentlydoes not read the gidNumber of the user. In theory it would bepossible to add this similar to the 'unix_primary_group' from above,but that should be treated as a new feature and requsting that througha RFE would be appropriate. Regards, Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZchristof.schm...@us.ibm.com || +1-520-799-2469 (T/L: 321-2469) - Original message -From: mark.berg...@uphs.upenn.eduTo: gpfsug main discussion list Cc: christof.schm...@us.ibm.comSubject: [EXTERNAL] Re: [gpfsug-discuss] Question concerning integration of CES with AD authentication systemDate: Thu, Jul 25, 2019 4:31 PM In the message dated: Thu, 24 May 2018 17:07:02 -,The pithy ruminations from Christof Schmitt on[Re: [gpfsug-discuss] Question concerning integration of CES with AD authentication system] were:=>Following up on an old, old post...=> > Basically Samba ignores the separate GID field in RFC2307bis, so one=> > imagines the options for changing the LDAP attributes are none=> > existent.=> => mmuserauth now has an option to use either the gid from the actual primary=> group or the gid defined for the user. See:=> => https://www.ibm.com/support/knowledgecenter/en/STXKQY_5.0.0/=> com.ibm.spectrum.scale.v5r00.doc/bl1adm_mmuserauth.htm=> => --unixmap-domains unixDomainMap=> [...]=> win: Specifies the system to read the primary group set as Windows=> primary group of a user on the Active Directory.=> unix: Specifies the system to read the primary group as set in "UNIX=> attributes" of a user on the Active Directory. => For example,=> --unixmap-domains "MYDOMAIN1(2-5:unix);MYDOMAIN2=> (10-20:win)"I see this is refering to UNIX attributes within AD, but I'm curious about mapping to attributes in LDAP.=> This gets mapped to 'idmap config ... : unix_primary_group' in the=> internal config.Does that correspond to setting the smb.conf parameterunix_primary_group = yesSpecifically, under Spectrum Scale 5.0.2, if I run:mmuserauth service create --data-access-method file --ldapmap-domains "DOMAIN(type=stand-alone:ldap_srv=ldapserver:range=1001-65535:usr_dn=ou=People,dc=DC,dc=TLD:grp_dn=ou=Group,dc=DC,dc=TLD)" --type ad(some args removed in this example), will that map the user's primary group tothe primaryGroupID supplied by AD orthe primaryGroupID LDAP field orthe gidNumber LDAP fieldor something else?Thanks,Mark=>=> Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZ=> christof.schm...@us.ibm.com || +1-520-799-2469 (T/L: 321-2469)=> ___ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
Re: [gpfsug-discuss] SMB share size on disk Windows
The parameter 'allocation roundup size' was introduced in Samba backin 2005. Since then the world has moved on to SMB2 and SMB3. It is notclear whether this has any performance benefits these days. Also withSamba in Scale, the only effect is that the reported allocation sizeis rounded up, but the space is not actually allocated. See also https://lists.samba.org/archive/samba-technical/2016-July/115172.htmlfor an additional comment: |Allocation roundup size actually was a performance win back|in the day (SMB1). Reporting it as larger (1MB) caused the|SMB1 client to issue larger read requests against Samba than|it did against a Windows server which reported the NTFS|allocation extent.||In the world of SMB2, not sure how much it's needed anymore. You can change this parameter for a test to get consistent reportingof used space: /usr/lpp/mmfs/bin/net conf setparm global 'allocation roundup size' 0 In case there is a problem, remove it again to revert back to thedefault: /usr/lpp/mmfs/bin/net conf delparm global 'allocation roundup size' Regards, Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZchristof.schm...@us.ibm.com || +1-520-799-2469 (T/L: 321-2469) - Original message -From: "L.walid (PowerM)" Sent by: gpfsug-discuss-boun...@spectrumscale.orgTo: "gpfsug-discuss@spectrumscale.org" Cc:Subject: [EXTERNAL] Re: [gpfsug-discuss] SMB share size on disk WindowsDate: Wed, May 22, 2019 6:01 PM Hi Everyone, Through some research, i found it's a normal behavior related to Samba "allocation roundup size" , since CES SMB is based on Samba that explains the behavior. (Windows assumes that the default size for a block is 1M). As such, i found somewhere else that changing this parameter can decrease performance, so if possible to advise on this. For the block size on the filesystem i would still go with 256k since it's the recommended for File Serving use cases. Thank you References : https://lists.samba.org/archive/samba-technical/2016-July/115166.html On Wed, May 22, 2019 at 11:59 PM L.walid (PowerM) <l.wa...@powerm.ma> wrote: Hi, We are contacting you regarding a behavior observed for our customer gpfs smb shares. When we try to view the file/folder properties, the values reported are significantly different from the folder/size and the folder/file size on disk. We tried to reproduce with creating a simple text file of 1ko and when we check the properties of the file it was a 1Mo on disk! I tried changing the block size of the fs from 4M to 256k , but still the same results Thank you -- Best regards, Walid Largou Senior IT Specialist Power Maroc Mobile : +212 621 31 98 71 Email: l.wa...@powerm.ma 320 Bd Zertouni 6th Floor, Casablanca, Morocco https://www.powerm.maThis message is confidential .Its contents do not constitute a commitment by Power Maroc S.A.R.L except where provided for in a written agreement between you and Power Maroc S.A.R.L. Any authorized disclosure, use or dissemination, either whole or partial, is prohibited. If you are not the intended recipient of the message, please notify the sender immediately. -- Best regards, Walid Largou Senior IT Specialist Power Maroc Mobile : +212 621 31 98 71 Email: l.wa...@powerm.ma 320 Bd Zertouni 6th Floor, Casablanca, Morocco https://www.powerm.maThis message is confidential .Its contents do not constitute a commitment by Power Maroc S.A.R.L except where provided for in a written agreement between you and Power Maroc S.A.R.L. Any authorized disclosure, use or dissemination, either whole or partial, is prohibited. If you are not the intended recipient of the message, please notify the sender immediately. ___gpfsug-discuss mailing listgpfsug-discuss at spectrumscale.orghttp://gpfsug.org/mailman/listinfo/gpfsug-discuss ___ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
Re: [gpfsug-discuss] Intro, and Spectrum Archive self-service recall interface question
> In the interim would it be possible for the SMB server to detect the> client OS and only allow recalls from say Windows. At least this would> be in "our" control unlike getting Apple to change the finder.app> behaviour. Then tell MacOS users to use Windows if they want to recall> files and pin the blame squarely on Apple to your users. Detecting the client OS is the difficult part. There is code in Sambato guess the client OS from a SMB1 negotiate request. This is notreliable in the first place, as a client can directly negotiate SMB2/3which would omit the client OS guessing. There is a protocol extensions MacOS clients try to negotiate, somaybe that could be used as indicator for a MacOS client that should beprevented from recalling files. This would still be a crude hack, butat least the required pieces of information are available. If that is an important piece, maybe this should be tracked as RFEinstead of an email thread. > I note that Linux is no better at honouring the offline bit in the SMB> protocol than MacOS. Oh the irony of Windows being the only main stream> IS handling HSM'ed files properly! Linux probably suffers from the distributed development here. TheLinux kernel SMB/CIFS client allows applications to query the offlineflag, but it would be up to the applications (e.g. file browsers) toquery that flag before reading data for generating previews. Regards, Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZchristof.schm...@us.ibm.com || +1-520-799-2469 (T/L: 321-2469) - Original message -From: Jonathan Buzzard Sent by: gpfsug-discuss-boun...@spectrumscale.orgTo: gpfsug main discussion list Cc:Subject: [EXTERNAL] Re: [gpfsug-discuss] Intro, and Spectrum Archive self-service recall interface questionDate: Tue, May 21, 2019 3:30 AM On Mon, 2019-05-20 at 20:33 +, Christof Schmitt wrote:> SMB clients know the state of the files through a OFFLINE bit that is> part of the metadata that is available through the SMB protocol. The> Windows Explorer in particular honors this bit and avoids reading> file data for previews, but the MacOS Finder seems to ignore it and> read file data for previews anyway, triggering recalls.> > The best way would be fixing this on the Mac clients to simply not> read file data for previews for OFFLINE files. So far requests to> Apple support to implement this behavior were unsuccessful, but it> might still be worthwhile to keep pushing this request.> In the interim would it be possible for the SMB server to detect theclient OS and only allow recalls from say Windows. At least this wouldbe in "our" control unlike getting Apple to change the finder.appbehaviour. Then tell MacOS users to use Windows if they want to recallfiles and pin the blame squarely on Apple to your users.I note that Linux is no better at honouring the offline bit in the SMBprotocol than MacOS. Oh the irony of Windows being the only main streamIS handling HSM'ed files properly!JAB.--Jonathan A. Buzzard Tel: +44141-5483420HPC System Administrator, ARCHIE-WeSt.University of Strathclyde, John Anderson Building, Glasgow. G4 0NG___gpfsug-discuss mailing listgpfsug-discuss at spectrumscale.orghttp://gpfsug.org/mailman/listinfo/gpfsug-discuss ___ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
Re: [gpfsug-discuss] Intro, and Spectrum Archive self-service recall interface question
SMB clients know the state of the files through a OFFLINE bit that ispart of the metadata that is available through the SMB protocol. TheWindows Explorer in particular honors this bit and avoids reading filedata for previews, but the MacOS Finder seems to ignore it and readfile data for previews anyway, triggering recalls. The best way would be fixing this on the Mac clients to simply notread file data for previews for OFFLINE files. So far requests toApple support to implement this behavior were unsuccessful, but itmight still be worthwhile to keep pushing this request. From a Scale perspective, you can always create two SMB exports on thesame path, one with gpfs:recalls=yes and the other withgpfs:recalls=no. Direct users to the one that disallows recalls bydefault and the other one can be accessed to recall a certainfile. Probably still risky, but it would be easy to implement. Regards, Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZchristof.schm...@us.ibm.com || +1-520-799-2469 (T/L: 321-2469) - Original message -From: Todd Ruston Sent by: gpfsug-discuss-boun...@spectrumscale.orgTo: gpfsug-discuss@spectrumscale.orgCc:Subject: [EXTERNAL] [gpfsug-discuss] Intro, and Spectrum Archive self-service recall interface questionDate: Mon, May 20, 2019 1:12 PM Greetings all,First post here, so by way of introduction we are a fairly new Spectrum Scale and Archive customer (installed last year and live in production Q1 this year). We have a four node (plus EMS) ESS system with ~520TB of mixed spinning disk and SSD. Client access to the system is via CES (NFS and SMB, running on two protocol nodes), integrated with Active Directory, for a mixed population of Windows, Mac, and Linux clients. A separate pair of nodes run Spectrum Archive, with a TS4500 LTO-8 library behind them.We use the system for general institute data, with the largest data types being HD video, multibeam sonar, and hydrophone data. Video is the currently active data type in production; we will be migrating the rest over time. So far things are running pretty well.Our archive approach is to premigrate data, particularly the large, unchanging data like the above mentioned data types, almost immediately upon landing in the system. Then we migrate those that have not been accessed in a period of time (or manually if space demands require it). We do wish to allow users to recall archived data on demand as needed.Because we have a large contingent of Mac clients (accessing the system via SMB), one issue we want to get ahead of is inadvertent recalls triggered by Mac preview generation, Quick Look, Cover Flow/Gallery view, and the like. Going in we knew this was going to be something we'd need to address, and we anticipated being able to configure Finder to disable preview generation and train users to avoid Quick Look unless they intended to trigger a recall. In our testing however, even with those features disabled/avoided, we have seen Mac clients trigger inadvertent recalls just from CLI 'ls -lshrt' interactions with the system.While brainstorming ways to prevent these inadvertent recalls while still allowing users to initiate recalls on their own when needed, one thought that came to us is we might be able to turn off recalls via SMB (setgpfs:recalls = no via mmsmb), and create a simple self-service web portal that would allow users to browse the Scale file system with a web browser, select files for recall, and initiate the recall from there. The web interface could run on one of the Archive nodes, and the back end of it would simply send a list of selected file paths to ltfsee recall.Before possibly reinventing the wheel, I thought I'd check to see if something like this may already exist, either from IBM, the Scale user community, or a third-party/open source tool that could be leveraged for the purpose. I searched the list archive and didn't find anything, but please let me know if I missed something. And please let me know if you know of something that would fit this need, or other ideas as well.Cheers,--Todd E. RustonInformation Systems ManagerMonterey Bay Aquarium Research Institute (MBARI)7700 Sandholdt Road, Moss Landing, CA, 95039Phone 831-775-1997 Fax 831-775-1652 http://www.mbari.org___gpfsug-discuss mailing listgpfsug-discuss at spectrumscale.orghttp://gpfsug.org/mailman/listinfo/gpfsug-discuss ___ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
Re: [gpfsug-discuss] gpfsug-discuss Digest, Vol 88, Issue 21
Hi, the most likely case here is that an id mapping for the user or theuser's primary group is missing (we require both). One possible way totroubleshoot would be issuing the queries manually: This is from a test system, but can be easily adapted to otherenvironments. Everything needs to be run from a protocol node: 1) Query the user record (here: cschmit): # /usr/lpp/mmfs/bin/net ads search -P sAMAccountName=cschmit uidNumber gidNumber objectSid primaryGroupIdGot 1 replies primaryGroupID: 513objectSid: S-1-5-21-2745666129-1984454212-2075974874-1120uidNumber: 1 Does the user have uidNumber defined? Does it fall into the specifiedrange? (1-999 from the previous email). 2) Query the user's primary group. The SID of the group can be constructed from the user's SID and the primaryGroupID. Replace the last part of the user's SID with the primaryGroupID. [root@sandrattler-vm1 ~]# /usr/lpp/mmfs/bin/net ads search -P objectSid=S-1-5-21-2745666129-1984454212-2075974874-513 gidNumberGot 1 replies gidNumber: 10001 Does the group have a gidNumber defined? Does it fall into the configured range? A special case that is also supported is having the gidNumber definedin the user's record. If that is the case, then the configuration canbe changed to --unixmap-domains with the :unix flag. See 'man mmuserauth' --unixmap-domains unixDomainMap... unix: Specifies the system to read the primary group as set in "UNIX attributes" of a user on the Active Directory. For example, --unixmap-domains "MYDOMAIN1(2-5:unix);MYDOMAIN2(10-20:win)" Regards, Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZchristof.schm...@us.ibm.com || +1-520-799-2469 (T/L: 321-2469) - Original message -From: "L.walid (PowerM)" Sent by: gpfsug-discuss-boun...@spectrumscale.orgTo: gpfsug-discuss@spectrumscale.orgCc:Subject: [EXTERNAL] Re: [gpfsug-discuss] gpfsug-discuss Digest, Vol 88, Issue 21Date: Mon, May 20, 2019 8:36 AM Hi, I manage to make the command work (basically checking /etc/resolv.conf, /etc/hosts, /etc/nsswitch.conf) : root@scale1 committed]# mmuserauth service create --data-access-method file --type ad --servers X.X.X.X --user-name MYUSER --idmap-role master --netbios-name CESSCALE --unixmap-domains "MYDOMAIN(1-999)" Enter Active Directory User 'spectrum_scale' password: File authentication configuration completed successfully. [root@scale1 committed]# mmuserauth service check Userauth file check on node: scale1 Checking nsswitch file: OK Checking Pre-requisite Packages: OK Checking SRV Records lookup: OK Service 'gpfs-winbind' status: OK Object not configured [root@scale1 committed]# mmuserauth service check --server-reachability Userauth file check on node: scale1 Checking nsswitch file: OK Checking Pre-requisite Packages: OK Checking SRV Records lookup: OK Domain Controller status NETLOGON connection: OK, connection to DC: Domain join status: OK Machine password status: OK Service 'gpfs-winbind' status: OK Object not configured But unfortunately, even if all the commands seems good, i cannot use user from active directory as owner or to setup ACL on SMB shares (it doesn't recognise AD users), plus the command 'id DOMAIN\USER' gives error cannot find user. Any ideas ? On Mon, 20 May 2019 at 01:46, <gpfsug-discuss-requ...@spectrumscale.org> wrote: Send gpfsug-discuss mailing list submissions to gpfsug-discuss@spectrumscale.orgTo subscribe or unsubscribe via the World Wide Web, visit http://gpfsug.org/mailman/listinfo/gpfsug-discussor, via email, send a message with subject or body 'help' to gpfsug-discuss-requ...@spectrumscale.orgYou can reach the person managing the list at gpfsug-discuss-ow...@spectrumscale.orgWhen replying, please edit your Subject line so it is more specificthan "Re: Contents of gpfsug-discuss digest..."Today's Topics: 1. Re: gpfsug-discuss Digest, Vol 88, Issue 19 (Schmied, Will)--Message: 1Date: Mon, 20 May 2019 01:45:57 +From: "Schmied, Will" <will.schm...@stjude.org>To: gpfsug main discussion list <gpfsug-discuss@spectrumscale.org>Subject: Re: [gpfsug-discuss] gpfsug-discuss Digest, Vol 88, Issue 19Message-ID: <fe9a82f8-d21f-4ba2-9cf6-68c649e65...@stjude.org>Content-Type: text/plain; charset="utf-8"?Well not seeing anything odd about the second try (just the username only) except that your NETBIOS domain name needs to be put in place of the placeholder (DOMAIN_NETBIOS_NAME).You can copy from a text file and then paste into the stdin when the command asks for your password. Just a way to be sure no typos are in the password entry.Thanks,WillFrom: <gpfsug-discuss-boun...@spectrumsc
Re: [gpfsug-discuss] Adding to an existing GPFS ACL
Hi, to answer the two questions: > 1. What's the purpose of a special flag to indicate that it is smbd> setting the ACL? Does this tie in with the undocumented "mmchfs -k> samba" feature? Windows expects ACL entries in a canonical order, first deny entries,then allow. Seee.g. https://docs.microsoft.com/en-us/windows/desktop/secauthz/order-of-aces-in-a-dacl From a brief look, using the the GPFS_ACL_SAMBA flag has the filesystem skip allow entries after deny entries when reading the ACL anddoes not store allow entries after deny entries. Maybe this is notstricly necessary and we could let SMB (Windows) clients deal withordering problems, but that would require some research and testing. > 2. There is a whole bunch of stuff in the documentation about v4.1> ACL's. How does one trigger that. All I seem to be able to do is> get POSIX and v4 ACL's. Do you get v4.1 ACL's if you set the file> system to "Samba" ACL's or am I missing something. This is likely the extension made to NFSv4 ACLs to allow storingadditional flags (the ACL4_FLAG_* defines in gpfs.h). These flags areused by Windows SMB clients to determine whether ACLs have beeninherited. As far as i know, the file system only stores these flags,but does not act upon them. You can get this format by initializingthe gpfs_acl struct with acl_type = GPFS_ACL_VERSION_NFS4 andacl_level = GPFS_ACL_LEVEL_V4FLAGS before calling gpfs_setacl. TheSamba code in vfs_gpfs.c does that if you want to see an example. Regards, Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZchristof.schm...@us.ibm.com || +1-520-799-2469 (T/L: 321-2469) - Original message -From: Jonathan Buzzard Sent by: gpfsug-discuss-boun...@spectrumscale.orgTo: gpfsug-discuss@spectrumscale.orgCc:Subject: Re: [gpfsug-discuss] Adding to an existing GPFS ACLDate: Wed, Mar 27, 2019 3:58 PM On 27/03/2019 15:59, Buterbaugh, Kevin L wrote:[SNIP]> So am I missing something?Nope you are not missing anything. Setting NFSv4 ACL's on GPFS on*LINUX* has always been a steaming pile of Brontosaurus droppings.I have been on about since 2011... Search the mailing list archives.> Is there an easier solution than writing a> script which recurses over the fileset, gets the existing ACL with> mmgetacl and outputs that to a file, edits that file to add in the new> group, and passes that as input to mmputacl? That seems very cumbersome> and error prone, especially if I’m the one writing the script!>The best option is to get yourself a pSeries machine, install AIX andGPFS and use the native AIX ACL command to set the ACL's. This worksbecause AIX has a mechanism for passing NFSv4 ACL's through it's VFSinterface. The RichACL kernel patches for Linux to give it the samefunctionality went nowhere. Noting that the XFS and JFS file systems,internally have NFSv4 ACL support.The next best option is to export it as an NSFv4 file system and use aLinux/FreeBSD machine to set the ACL's (a Mac might even work). Expectperformance to not be great.The next best option is to do an SMB export, mount it on Linux and usesetcifsacl or map it on Windows and use cacls command. Someexperimentation on working out exactly how NFSv4 ACLS get mapped toWindows ACLS would be advisable before a mass apply though. I don'tthink it is possible to set all NFSv4 ACL options using this method.Probably the best option, but which is not publicly available is to usemy modified version of the Linux nfs4_setacl command :-)You just modify nfs4_acl_for_path.c and nfs4_set_acl.c so theyread/write the GPFS ACL struct and convert between the GPFSrepresentation and the internal data structure used by thenfs4-acl-tools to hold NFSv4 ACL's.However I have not put it any where public because the GPFS APIdocumentation is incomplete when it comes to ACL's. Consequently I can'tbe sure it is safe so I am not releasing it. I have two questions that Iwould like answering before I make it public. I will ask them for thethird time, in hopes someone at IBM is actually listening. 1. What's the purpose of a special flag to indicate that it is smbd setting the ACL? Does this tie in with the undocumented "mmchfs -k samba" feature? 2. There is a whole bunch of stuff in the documentation about v4.1 ACL's. How does one trigger that. All I seem to be able to do is get POSIX and v4 ACL's. Do you get v4.1 ACL's if you set the file system to "Samba" ACL's or am I missing something.The other option is to write a script. Personally I would usePerl/Python rather than a shell script as it would be easier to read theresult of mmgetacl into a buffer, append the extra bits and write it outagain with mmputacl. It is horribly slow however if you have millions offiles to iterate over. Trust me back in 2011 I had Perl scripts forsetting ACL's.The final option though not quick would be for IBM to actually implementa mmsetfacl com
Re: [gpfsug-discuss] Exporting remote GPFS mounts on a non-ces SMB share
Hi, a few comments from my side: The Samba build that we ship with CES basically has the same capabilities as another Samba. The authentication options exposed through the CLI are limited as those as the configurations we explicitly test and support and that cover the usual usecases. The main advantages of using the CES Samba is that it is cluster enabled, integrated with the CES stack, integrates non-POSIX file system features and is supported through the normal Scale support. Can you provide more details on the authentication requirements? Specifically how would you configure the non-CES Samba? It should be possible to adapt those changes to the CES Samba. While we discourage large changes to the config, we do have customers that add small changes on top of the normal config to accomodate their environment. This is not necessarily ideal, but sometimes the best way forward. If there is a wider demand for a specific authentication option, that could always become a RFE to discuss possible extensions of the CLI. Regards, Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZchristof.schm...@us.ibm.com || +1-520-799-2469 (T/L: 321-2469) - Original message -From: vall...@cbio.mskcc.orgSent by: gpfsug-discuss-boun...@spectrumscale.orgTo: gpfsug main discussion list , Simon Thompson Cc:Subject: Re: [gpfsug-discuss] Exporting remote GPFS mounts on a non-ces SMB shareDate: Fri, Mar 8, 2019 9:43 AM Thank you Simon. I do remember reading your page about few years back, when i was researching this issue. When you mentioned Custom Auth. I assumed it to be user-defined authentication from CES. However, looks like i need to hack it a bit to get SMB working with AD? I did not feel comfortable hacking the SMB from the CES cluster, and thus i was trying to bring up SMB outside the CES cluster. I almost hack with everything in the cluster but i leave GPFS and any of its configuration in the supported config, because if things break - i felt it might mess up things real bad. I wish we do not have to hack our way out of this, and IBM supported this config out of the box. I do not understand the current requirements from CES with respect to AD or user defined authentication where either both SMB and NFS should be AD/LDAP authenticated or both of them user defined. I believe many places do use just ssh-key as authentication for linux machines including the cloud instances, while SMB obviously cannot be used with ssh-key authentication and has to be used either with LDAP or AD authentication. Did anyone try to raise this as a feature request? Even if i do figure to hack this thing and make sure that updating CES won’t mess it up badly. I think i will have to do few things to get the SIDs to Uids match as you mentioned. We do not use passwords to authenticate to LDAP and I do not want to be creating another set of passwords apart from AD which is already existing, and users authenticate to it when they login to machines. I was thinking to bring up something like Redhat IDM that could sync with AD and get all the usernames/sids and password hashes. I could then enter my current LDAP uids/gids in the Redhat IDM. IDM will automatically create uids/gids for usernames that do not have them i believe. In this way, when SMB authenticates with Redhat IDM - users can use there current AD kerberos tickets or the same passwords and i do not have to change the passwords. It will also automatically sync with AD and create UIDs/GIDs and thus i don’t have to manually script something to create one for every person in AD. I however need to see if i could get to make this work with institutional AD and it might not be as smooth. So which of the below cases will IBM most probably support? :) 1. Run SMB outside the CES cluster with the above configuration. 2. Hack SMB inside the CES cluster Is it that running SMB outside the CES cluster with R/W has a possibility of corrupting the GPFS filesystem? We do not necessarily need HA with SMB and so apart from HA - What does IBM SMB do that would prevent such corruption from happening? The reason i was expecting the usernames to be same in LDAP and AD is because - if they are, then SMB will do uid mapping by default. i.e SMB will automatically map windows sids to ldap uids. I will not have to bring up Redhat IDM if this was the case. But unfortunately we have many users who have different ldap usernames from AD usernames - so i guess the practical way would be to use Redhat IDM to map windows sids to ldap uids. I have read about mmname2uid and mmuid2name that Andrew mentioned but looks like it is made to work between 2 gpfs clusters with different uids. Not exactly to make SMB map windows SIDs to ldap uids. Regards,Lohit On Mar 8, 2019, 2:41 AM -0600, Simon Thompson , wrote: Hi Lohit, Custom auth sounds like it would work. NFS uses the “system” ldap, SMB can use LDAP or AD, or you can fudge it and actually use both. We came
Re: [gpfsug-discuss] User Login Active Directory authentication on CES nodes with SMB protocol
There is the PAM module that would forward authentication requests to winbindd: /usr/lpp/mmfs/lib64/security/pam_gpfs-winbind.so In theory that can be added to the PAM configuration in /etc/pam.d/. On the other hand, we have never tested this nor claimed support, so there might be reasons why this won't work. Other customers have configured sssd manually in addition to the Scale authentication to allow user logon and authentication for sudo. If the request here is to configure AD authentication through mmuserauth and that should also provide user logon, that should probably be treated as a feature request through RFE. Regards, Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZchristof.schm...@us.ibm.com || +1-520-799-2469 (T/L: 321-2469) - Original message -From: "Lyle Gayne" Sent by: gpfsug-discuss-boun...@spectrumscale.orgTo: gpfsug main discussion list Cc: Ingo Meents Subject: Re: [gpfsug-discuss] User Login Active Directory authentication on CES nodes with SMB protocolDate: Tue, Jan 8, 2019 2:54 PM Adding Ingo Meents for response"Rob Logie" ---01/08/2019 04:50:22 PM---Hi All Is there a way to enable User Login Active Directory authentication on CESFrom: "Rob Logie" To: gpfsug-discuss@spectrumscale.orgDate: 01/08/2019 04:50 PMSubject: [gpfsug-discuss] User Login Active Directory authentication on CES nodes with SMB protocolSent by: gpfsug-discuss-boun...@spectrumscale.org Hi AllIs there a way to enable User Login Active Directory authentication on CES nodes with SMB protocol that are joined to an AD domain. ? The AD authentication is working for access to the SMB shares, but not for user login authentication on the CES nodes.Thanks ! Regards,Rob LogieIT Specialist ___gpfsug-discuss mailing listgpfsug-discuss at spectrumscale.orghttp://gpfsug.org/mailman/listinfo/gpfsug-discuss ___gpfsug-discuss mailing listgpfsug-discuss at spectrumscale.orghttp://gpfsug.org/mailman/listinfo/gpfsug-discuss ___ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
Re: [gpfsug-discuss] Spectrum Scale protocol node service separation
> Whilst we're on protocols, are there any restrictions on using mixed architectures? I don't recall seeing this but... > E.g. my new shiny boxes are ppc64le systems and my old legacy nodes are x86. It's all ctdb locking right .. > (ok maybe mixing be and le hosts would be bad) If you are using SMB, all CES nodes have to be the same architecture: https://www.ibm.com/support/knowledgecenter/en/STXKQY_5.0.2/com.ibm.spectrum.scale.v5r02.doc/bl1ins_smbclients.htm All CES nodes need to be the same hardware architecture (x86 versus Power®) and the same endianness (little endian versus big endian). Regards, Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZchristof.schm...@us.ibm.com || +1-520-799-2469 (T/L: 321-2469) - Original message -From: Simon Thompson Sent by: gpfsug-discuss-boun...@spectrumscale.orgTo: gpfsug main discussion list Cc:Subject: Re: [gpfsug-discuss] Spectrum Scale protocol node service separationDate: Wed, Jan 9, 2019 11:05 AM Can you use node affinity within CES groups?For example I have some shiny new servers I want to normally use. If I plan maintenance, I move the IP to another shiny box. But I also have some old off support legacy hardware that I'm happy to use in a DR situation (e.g. they are in another site). So I want a group for my SMB boxes and NFS boxes, but have affinity normally, and then have old hardware in case of failure.Whilst we're on protocols, are there any restrictions on using mixed architectures? I don't recall seeing this but... E.g. my new shiny boxes are ppc64le systems and my old legacy nodes are x86. It's all ctdb locking right .. (ok maybe mixing be and le hosts would be bad)(Sure I'll take a performance hit when I fail to the old nodes, but that is better than no service).SimonFrom: gpfsug-discuss-boun...@spectrumscale.org [gpfsug-discuss-boun...@spectrumscale.org] on behalf of aspal...@us.ibm.com [aspal...@us.ibm.com]Sent: 09 January 2019 17:21To: gpfsug-discuss@spectrumscale.orgCc: gpfsug-discuss@spectrumscale.orgSubject: Re: [gpfsug-discuss] Spectrum Scale protocol node service separationHey guys - I wanted to reply from the Scale development side.First off, consider CES as a stack and the implications of such:- all protocols are installed on all nodes- if a specific protocol is enabled (SMB, NFS, OBJ, Block), it's enabled for all protocol nodes- if a specific protocol is started (SMB, NFS, OBJ, Block), it's started on all nodes by default, unless manually specified.As was indicated in the e-mail chain, you don't want to be removing rpms to create a subset of nodes serving various protocols as this will cause overall issues. You also don't want to manually be disabling protocols on some nodes/not others in order to achieve nodes that are 'only serving' SMB, for instance. Doing this manual stopping/starting of protocols isn't something that will adhere to failover.===A few possible solutions if you want to segregate protocols to specific nodes are:===1) CES-Groups in combination with specific IPs / DNS hostnames that correspond to each protocol.- As mentioned, this can still be bypassed if someone attempts a mount using an IP/DNS name not set for their protocol. However, you could probably prevent some of this with an external firewall rule.- Using CES-Groups confines the IPs/DNS hostnames to very specific nodes2) Firewall rules- This is best if done external to the cluster, and at a level that can restrict specific protocol traffic to specific IPs/hostnames- combine this with #1 for the best results.- Although it may work, try to stay away from crazy firewall rules on each protocol node itself as this can get confusing very quickly. It's easier if you can set this up external to the nodes.3) Similar to above but using Node Affinity CES-IP policy - but no CES groups.- Upside is node-affinity will attempt to keep your CES-IPs associated with specific nodes. So if you restrict specific protocol traffic to specific IPs, then they'll stay on nodes you designate- Watch out for failovers. In error cases (or upgrades) where an IP needs to move to another node, it obviously can't remain on the node that's having issues. This means you may have protocol trafffic crossover when this occurs.4) A separate remote cluster for each CES protocol- In this example, you could make fairly small remote clusters (although we recommend 2->3nodes at least for failover purposes). The local cluster would provide the storage. The remote clusters would mount it. One remote cluster could have only SMB enabled. Another remote cluster could have only OBJ enabled. etc...--I hope this helps a bitRegards,Aaron PalazzoloIBM Spectrum Scale Deployment, Infrastructure, Virtualization9042 S Rita Road, Tucson AZ 85744Phone: 520-799-5161, T/L: 321-5161E
Re: [gpfsug-discuss] preventing HSM tape recall storms
> we had left out "gpfs" from the> vfs objects => line in smb.conf>> so setting> vfs objects = gpfs (etc)> gpfs:hsm = yes> gpfs:recalls = yes (not "no" as I had originally, and is implied by the manual) Thank you for the update. gpfs:recalls=yes is the default, allowingrecalls of files. If you set that to 'no', Samba will deny access to"OFFLINE" files in GPFS through SMB. > and setting the offline flag on the file by migrating it, so that> # mmlsattr -L filename.jpg> ...> Misc attributes: ARCHIVE OFFLINE>> now Explorer on Windows 7 and 10 do not recall the file while viewing the folder with "Large icons">> and a standard icon with an X is displayed.>> But after the file is then opened and recalled, the icon displays the thumbnail image and the OFFLINE flag is lost. Yes, that is working as intended. While the file is only in the"external pool" (e.g. HSM tape), the OFFLINE flag is reported. Onceyou read/write data, that triggers a recall to the disk pool and theflag is cleared. > Also as you observed, Finder on MacOSX 10.13 ignores the file's offline flag,>> so we still risk a recall storm caused by them. The question here would be how to handle the Mac clients. You couldconfigured two SMB shares on the same path: One with gpfs:recalls=yesand tell the Windows users to access that share; the other one withgpfs:recalls=no and tell the Mac users to use that share. That wouldavoid the recall storms, but runs the risk of Mac users connecting tothe wrong share and avoiding this workaround... Regards, Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZchristof.schm...@us.ibm.com || +1-520-799-2469 (T/L: 321-2469) - Original message -From: Cameron Dunn Sent by: gpfsug-discuss-boun...@spectrumscale.orgTo: "gpfsug-discuss@spectrumscale.org" Cc:Subject: Re: [gpfsug-discuss] preventing HSM tape recall stormsDate: Sat, Jul 7, 2018 2:30 PM Thanks Christof, we had left out "gpfs" from the vfs objects = line in smb.conf so setting vfs objects = gpfs (etc) gpfs:hsm = yes gpfs:recalls = yes (not "no" as I had originally, and is implied by the manual) and setting the offline flag on the file by migrating it, so that # mmlsattr -L filename.jpg ... Misc attributes: ARCHIVE OFFLINE now Explorer on Windows 7 and 10 do not recall the file while viewing the folder with "Large icons" and a standard icon with an X is displayed. But after the file is then opened and recalled, the icon displays the thumbnail image and the OFFLINE flag is lost. Also as you observed, Finder on MacOSX 10.13 ignores the file's offline flag, so we still risk a recall storm caused by them. All the best, Cameron From: gpfsug-discuss-boun...@spectrumscale.org on behalf of Christof Schmitt Sent: 03 July 2018 20:37:08To: gpfsug-discuss@spectrumscale.orgCc: gpfsug-discuss@spectrumscale.orgSubject: Re: [gpfsug-discuss] preventing HSM tape recall storms > HSM over LTFS-EE runs the risk of a recall storm if files which have been migrated to tape> are then shared by Samba to Macs and PCs.> MacOS Finder and Windows Explorer will want to display all the thumbnail images of a> folder's contents, which will recall lots of files from tape. SMB clients can query file information, including the OFFLINEflag. With Spectrum Scale and the "gpfs" module loaded in Samba thatis mapped from the the OFFLINE flag that is visible in "mmlsattr-L". In those systems, the SMB client can determine that a file isoffline. In our experience this is handled correctly in Windows Explorer; whenan "offline" file is encountered, no preview is generated from thefile data. The Finder on Mac clients does not seem to honor theOFFLINE flag, thus the main problems are typically recall stormscaused by Mac clients. > According to the Samba documentation this is preventable by setting the following> --> https://www.samba.org/samba/docs/current/man-html/vfs_gpfs.8.html>> gpfs:recalls = [ yes | no ]> When this option is set to no, an attempt to open an offline file> will be rejected with access denied.> This helps preventing recall storms triggered by careless applications like Finder and Explorer.>> yes(default) - Open files that are offline. This will recall the files from HSM.> no - Reject access to offline files with access denied. This will prevent recalls of files from HSM.> Using this setting also requires gpfs:hsm to be set to yes.>> gpfs:hsm = [ yes | no ]> Enable/Disable announcing if this FS has HSM enabled.> no(default) - Do not announce HSM.> yes - Announce HSM.> -->> However we could not get this to work.>> On Centos7/Samba4.5, smb.conf contained> gpfs:hsm
Re: [gpfsug-discuss] preventing HSM tape recall storms
> HSM over LTFS-EE runs the risk of a recall storm if files which have been migrated to tape> are then shared by Samba to Macs and PCs.> MacOS Finder and Windows Explorer will want to display all the thumbnail images of a> folder's contents, which will recall lots of files from tape. SMB clients can query file information, including the OFFLINEflag. With Spectrum Scale and the "gpfs" module loaded in Samba thatis mapped from the the OFFLINE flag that is visible in "mmlsattr-L". In those systems, the SMB client can determine that a file isoffline. In our experience this is handled correctly in Windows Explorer; whenan "offline" file is encountered, no preview is generated from thefile data. The Finder on Mac clients does not seem to honor theOFFLINE flag, thus the main problems are typically recall stormscaused by Mac clients. > According to the Samba documentation this is preventable by setting the following> --> https://www.samba.org/samba/docs/current/man-html/vfs_gpfs.8.html>> gpfs:recalls = [ yes | no ]> When this option is set to no, an attempt to open an offline file> will be rejected with access denied.> This helps preventing recall storms triggered by careless applications like Finder and Explorer.>> yes(default) - Open files that are offline. This will recall the files from HSM.> no - Reject access to offline files with access denied. This will prevent recalls of files from HSM.> Using this setting also requires gpfs:hsm to be set to yes.>> gpfs:hsm = [ yes | no ]> Enable/Disable announcing if this FS has HSM enabled.> no(default) - Do not announce HSM.> yes - Announce HSM.> -->> However we could not get this to work.>> On Centos7/Samba4.5, smb.conf contained> gpfs:hsm = yes> gpfs:recalls = no> (also tried setting gpfs:offline = yes, though this is not documented) These options apply to the "gpfs" module in Samba. The Samba versionyou are using needs to be built with GPFS support and the "gpfs"module needs to be loaded through the "vfs objects" configuration. AsCentos7/Samba4.5 is mentioned, would guess that the CentOS providedSamba version is used, which is probably not compiled with GPFSsupport. From IBM we would recommend to use CES for protocol services, whichalso provides Samba for SMB. The Samba provided through CES isconfigured so that the gpfs:recalls option can be used: https://www.ibm.com/support/knowledgecenter/en/STXKQY_4.2.3/com.ibm.spectrum.scale.v4r23.doc/bl1adm_mmsmb.htm gpfs:recalls If the value is set as yes files that have been migrated from disk will be recalled on access. By default, this is enabled. If recalls = no files will not be recalled on access and the client will receive ACCESS_DENIED message. > We made a share containing image files that were then migrated to tape by LTFS-EE,> to see if these flags were respected by OS X Finder or Windows Explorer.>> Neither Mac OS X (using SMB3) or Windows 7 (using SMB2) respected the settings,> so that when browsing the stubs in the share, the files were recalled from tape> and the thumbnails displayed.>> Has anyone seen these flags working as they are supposed to ? Yes, they are working, as we use them in our Samba build. Debuggingthis would require looking at the Samba configuration and possiblycollecting a trace. If my above assumption was wrong and this problemoccurs with the CES Samba (gpfs.smb), please open a PMR for debuggingthis issue. If this is not the CES Samba, please contact the providerof the Samba package for additional support. Regards, Christof Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZchristof.schm...@us.ibm.com || +1-520-799-2469 (T/L: 321-2469) - Original message -From: Cameron Dunn Sent by: gpfsug-discuss-boun...@spectrumscale.orgTo: "gpfsug-discuss@spectrumscale.org" Cc:Subject: [gpfsug-discuss] preventing HSM tape recall stormsDate: Tue, Jul 3, 2018 6:22 AM HSM over LTFS-EE runs the risk of a recall storm if files which have been migrated to tape are then shared by Samba to Macs and PCs. MacOS Finder and Windows Explorer will want to display all the thumbnail images of a folder's contents, which will recall lots of files from tape. According to the Samba documentation this is preventable by setting the following -- https://www.samba.org/samba/docs/current/man-html/vfs_gpfs.8.html gpfs:recalls = [ yes | no ] When this option is set to no, an attempt to open an offline file will be rejected with access denied. This helps preventing recall storms triggered by careless applications like Finder and Explorer. yes(default) - Open files that are offline. This will recall the files from HSM. no - Reject access to
Re: [gpfsug-discuss] Snapshot handling in mixed Windows/MacOSenvironments
Hi, we currently support the SMB protocol method of quering snapshots, which is used by the Windows "Previous versions" dialog. Mac clients unfortunately do not implement these explicit queries. Browsing the snapshot directories with the @GMT names through SMB currently is not supported. Could you open a RFE to request snapshot browsing from Mac clients? An official request would be helpful in prioritizing the development and test work required to support this. Regards, Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZchristof.schm...@us.ibm.com || +1-520-799-2469 (T/L: 321-2469) - Original message -From: "Altenburger Ingo (ID SD)" Sent by: gpfsug-discuss-boun...@spectrumscale.orgTo: "gpfsug-discuss@spectrumscale.org" Cc:Subject: [gpfsug-discuss] Snapshot handling in mixed Windows/MacOS environmentsDate: Wed, Jun 27, 2018 4:52 AM Hi all, our (Windows) users are familiared with the ‘previous versions’ self-recover feature. We honor this by creating regular snapshots with the default @GMT prefix (non-@-heading prefixes are not visible in ‘previous versions’). Unfortunately, MacOS clients having the same share mounted via smb or cifs cannot benefit from such configured snapshots, i.e. they are not visible in Finder window. Any non-@-heading prefix is visible in Finder as long as hidden .snapshots directory can be seen. Using a Terminal command line is also not feasible for end user purposes. Since the two case seem to be mutually exclusive, has anybody found a solution other than creating two snapshots, one with and one without the @-heading prefix? Thanks for any hint, Ingo Altenburger ___gpfsug-discuss mailing listgpfsug-discuss at spectrumscale.orghttp://gpfsug.org/mailman/listinfo/gpfsug-discuss ___ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
Re: [gpfsug-discuss] Question concerning integration of CES with AD authentication system
> My understanding, after talking to expert people here, is that I should use the RFC2307 model for ID mapping (described here: https://goo.gl/XvqHDH). The problem is > that our ID schema is slightly different than that one described in RFC2307. In the RFC the relevant user identification fields are named "uidNumber" and "gidNumber". > But in our AD database schema we have:>> # egrep 'uid_number|gid_number' /etc/sssd/sssd.conf> ldap_user_uid_number = msSFU30UidNumber> ldap_user_gid_number = msSFU30GidNumber> ldap_group_gid_number = msSFU30GidNumber>> My question is: is it possible to configure CES to look for the custom field labels (those ones listed above) instead the default ones officially described in rfc2307 ? mmuserauth only supports the rfc2307 attributes for Active Directory. That is the tested and supported configuration. The attribute names from the sssd configuration look like the "old" SFU attributes are used. You could try going through "mmuserauth service create --type ad ..." and then switching the internal configuration to use the SFU attributes: /usr/lpp/mmfs/bin/net conf setparm global 'idmap config DOMAINNAME : schema_mode' sfu Then restart gpfs-winbind on all protocol nodes or use "mmces service" to stop and start SMB on all protocol nodes. Note that we have not tested this configuration, so if that should be supported in a possible future release, please open a RFE. Regards, Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZchristof.schm...@us.ibm.com || +1-520-799-2469 (T/L: 321-2469) - Original message -From: "Dorigo Alvise (PSI)" <alvise.dor...@psi.ch>Sent by: gpfsug-discuss-boun...@spectrumscale.orgTo: "gpfsug-discuss@spectrumscale.org" <gpfsug-discuss@spectrumscale.org>Cc:Subject: [gpfsug-discuss] Question concerning integration of CES with AD authentication systemDate: Thu, May 24, 2018 1:45 AM Dear members,at PSI I'm trying to integrate the CES service with our AD authentication system.My understanding, after talking to expert people here, is that I should use the RFC2307 model for ID mapping (described here: https://goo.gl/XvqHDH). The problem is that our ID schema is slightly different than that one described in RFC2307. In the RFC the relevant user identification fields are named "uidNumber" and "gidNumber". But in our AD database schema we have:# egrep 'uid_number|gid_number' /etc/sssd/sssd.confldap_user_uid_number = msSFU30UidNumberldap_user_gid_number = msSFU30GidNumberldap_group_gid_number = msSFU30GidNumberMy question is: is it possible to configure CES to look for the custom field labels (those ones listed above) instead the default ones officially described in rfc2307 ?many thanks.Regards, Alvise Dorigo ___gpfsug-discuss mailing listgpfsug-discuss at spectrumscale.orghttp://gpfsug.org/mailman/listinfo/gpfsug-discuss ___ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
Re: [gpfsug-discuss] Question concerning integration of CES with AD authentication system
> Basically Samba ignores the separate GID field in RFC2307bis, so one> imagines the options for changing the LDAP attributes are none> existent. mmuserauth now has an option to use either the gid from the actual primarygroup or the gid defined for the user. See: https://www.ibm.com/support/knowledgecenter/en/STXKQY_5.0.0/com.ibm.spectrum.scale.v5r00.doc/bl1adm_mmuserauth.htm --unixmap-domains unixDomainMap[...] win: Specifies the system to read the primary group set as Windows primary group of a user on the Active Directory. unix: Specifies the system to read the primary group as set in "UNIX attributes" of a user on the Active Directory. For example, --unixmap-domains "MYDOMAIN1(2-5:unix);MYDOMAIN2(10-20:win)" This gets mapped to 'idmap config ... : unix_primary_group' in theinternal config. Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZchristof.schm...@us.ibm.com || +1-520-799-2469 (T/L: 321-2469) - Original message -From: Jonathan Buzzard <jonathan.buzz...@strath.ac.uk>Sent by: gpfsug-discuss-boun...@spectrumscale.orgTo: gpfsug main discussion list <gpfsug-discuss@spectrumscale.org>Cc:Subject: Re: [gpfsug-discuss] Question concerning integration of CES with AD authentication systemDate: Thu, May 24, 2018 7:50 AM On Thu, 2018-05-24 at 14:16 +, Skylar Thompson wrote:> I haven't needed to change the LDAP attributes that CES uses, but I> do see --user-id-attrib in the mmuserauth documentation.> Unfortunately, I don't see an equivalent one for gidNumber.>Is it not doing the "Samba thing" where your GID is the GID of yourprimary Active Directory group? This is usually "Domain Users" but notalways.Basically Samba ignores the separate GID field in RFC2307bis, so oneimagines the options for changing the LDAP attributes are noneexistent.I know back in the day this had me stumped for a while because unlessyou assign a GID number to the users primary group then Winbind doesnot return anything, aka a "getent passwd" on the user fails.JAB.--Jonathan A. Buzzard Tel: +44141-5483420HPC System Administrator, ARCHIE-WeSt.University of Strathclyde, John Anderson Building, Glasgow. G4 0NG___gpfsug-discuss mailing listgpfsug-discuss at spectrumscale.orghttp://gpfsug.org/mailman/listinfo/gpfsug-discuss ___ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
Re: [gpfsug-discuss] Spectrum Scale CES , SAMBA, LDAP kerberos authentication issue
The Samba config below has: security = ADS which would be the result from configuring mmuserauth with --type ad mmuserauth service create --type ldap --data-access-method file --servers ssipa.example.com --base-dn dc=example,dc=com --user-name 'cn=Directory Manager' --netbios-name labs1 --enable-server-tls --enable-kerberos --kerberos-server ssipa.example.com --kerberos-realm example.com on the other hand would configure 'security = user'. I cannot say whether that is the only problem, but something does not seem to match here. If that does not explain the problem, i would suggest to capture the problem in a SMB trace and report the problem through a PMR. Regards, Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZchristof.schm...@us.ibm.com || +1-520-799-2469 (T/L: 321-2469) - Original message -From: ho...@interia.plSent by: gpfsug-discuss-boun...@spectrumscale.orgTo: gpfsug-discuss@spectrumscale.orgCc:Subject: [gpfsug-discuss] Spectrum Scale CES , SAMBA, LDAP kerberos authentication issueDate: Fri, May 18, 2018 12:01 PM Hi there,I'm just learning, trying to configure Spectrum Scale: SMB File Authentication using LDAP (IPA) with kerberos, and been struggling with it for a couple of days, without success.Users on spectrum cluster and client machine are authenticated properly, so ldap should be fine.NFS mount with keberos works with no issues as well.But I ran out of ideas how to configure SMB using LDAP with kerberos.I could messed up with netbios names, as am not sure which one to use, from cluster node, from protocol node, exactly which one.But error message seems to point to keytab file, which is present on both, server and client nodes.I ran into simillar post, dated few days ago, so I'm not the only one.https://www.mail-archive.com/gpfsug-discuss@spectrumscale.org/msg03919.htmlBelow is my configuration and error message, and I'd appreciate any hints or help.Thank you,d.Error message from /var/adm/ras/log.smbd[2018/05/18 13:51:58.853681, 3] ../auth/gensec/gensec_start.c:918(gensec_register) GENSEC backend 'ntlmssp_resume_ccache' registered[2018/05/18 13:51:58.859984, 0] ../source3/librpc/crypto/gse.c:586(gse_init_server) smb_gss_krb5_import_cred failed with [Unspecified GSS failure. Minor code may provide more information: Keytab MEMORY:cifs_srv_keytab is nonexistent or empty][2018/05/18 13:51:58.860151, 1] ../auth/gensec/gensec_start.c:698(gensec_start_mech) Failed to start GENSEC server mech gse_krb5: NT_STATUS_INTERNAL_ERRORCluster nodesspectrum1.example.com RedHat 7.4spectrum2.example.com RedHat 7.4spectrum3.example.com RedHat 7.4Protocols nodes:labs1.example.comlasb2.example.comlabs3.example.comssipa.example.com Centos 7.5 spectrum scale server:[root@spectrum1 security]# klist -kKeytab name: FILE:/etc/krb5.keytabKVNO Principal -- 1 host/labs1.example@example.com 1 host/labs1.example@example.com 1 host/labs2.example@example.com 1 host/labs2.example@example.com 1 host/labs3.example@example.com 1 host/labs3.example@example.com 1 nfs/labs1.example@example.com 1 nfs/labs1.example@example.com 1 nfs/labs2.example@example.com 1 nfs/labs2.example@example.com 1 nfs/labs3.example@example.com 1 nfs/labs3.example@example.com 1 cifs/labs1.example@example.com 1 cifs/labs1.example@example.com 1 cifs/labs2.example@example.com 1 cifs/labs2.example@example.com 1 cifs/labs3.example@example.com 1 cifs/labs3.example@example.com[root@spectrum1 security]# net conf list[global]disable netbios = yesdisable spoolss = yesprintcap cache time = 0fileid:algorithm = fsnamefileid:fstype allow = gpfssyncops:_onmeta_ = nopreferred master = noclient NTLMv2 auth = yeskernel oplocks = nolevel2 oplocks = yesdebug hires timestamp = yesmax log size = 10host msdfs = yesnotify:inotify = yeswide links = nolog writeable files on exit = yesctdb locktime warn threshold = 5000auth methods = guest sam winbindsmbd:backgroundqueue = Falseread _only_ = nouse sendfile = nostrict locking = autoposix locking = nolarge readwrite = yesaio read size = 1aio write size = 1force unknown acl user = yesstore dos attributes = yesmap readonly = yesmap archive = yesmap system = yesmap hidden = yesea support = yesgroupdb:backend = tdbwinbind:online check timeout = 30winbind max domain connections = 5winbind max clients = 1dmapi support = nounix extensions = nosocket options = TCP_NODELAY SO_KEEPALIVE TCP_KEEPCNT=4 TCP_KEEPIDLE=240 TCP_KEEPINTVL=15strict allocate = yestdbsam:map builtin = noaio_pthread:aio open = yesdfree cache time = 100change notify = yesmax open files = 2time_audit:timeout = 5000gencache:stabilize_count = 1server min protocol = SMB2_02server max protocol = SMB3_02vfs objects = shadow_copy2 syncops gpfs fileid time_auditsmbd profiling level = onlog level = 1logging = syslog@0 filesmbd exit on ip drop
Re: [gpfsug-discuss] SMB quotas query
> I am really not sure what the issue with the code path for this as it> is 35 lines of C including comments to get the fileset if one exists> for a given path on a GPFS file system. You open a random file on the> path, call gpfs_fcntl and then gpfs_getfilesetid. It's then a simple> call to gpfs_quotactl. The main problem is that the API requires opening a file to query the fileset id, which in turn conflicts with sharemodes and can break oplocks. It also incurs the additional overhead of four calls. Due to another limitation, this is done for every I/O call in the worst case. The workaround for not opening the file would be to determine the directory holding the file and opening that. This is complicated, but still has the overhead of the additional calls. The short-answer to all of that is that from a Samba perspective, --filesetdf is the better option to determine the fileset quota. The API calls to query for user and group quota simply take a path, so they don't have the same complications as the query for the fileset quota. Regards, Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZchristof.schm...@us.ibm.com || +1-520-799-2469 (T/L: 321-2469) - Original message -From: Jonathan Buzzard <jonathan.buzz...@strath.ac.uk>Sent by: gpfsug-discuss-boun...@spectrumscale.orgTo: gpfsug main discussion list <gpfsug-discuss@spectrumscale.org>Cc:Subject: Re: [gpfsug-discuss] SMB quotas queryDate: Wed, May 16, 2018 2:02 AM On Wed, 2018-05-16 at 08:51 +, Sobey, Richard A wrote:> For us the only one that matters is the fileset quota. With or> without –perfileset-quota set, we simply see a quota value for one of> the filesets that is mapped to a drive, and every other mapped drives> inherits the same value. whether it’s true or not.> > Just about to do some SMB tracing for my PMR.> I have a fully working solution that uses the dfree option in Samba ifyou want.I am with you here in that a lot of places will be carving a GPFS filesystem up with file sets with a quota that are then shared to a groupof users and you want the disk size, and amount free to show up on theclients based on the quota for the fileset not the whole file system.I am really not sure what the issue with the code path for this as itis 35 lines of C including comments to get the fileset if one existsfor a given path on a GPFS file system. You open a random file on thepath, call gpfs_fcntl and then gpfs_getfilesetid. It's then a simplecall to gpfs_quotactl.JAB.--Jonathan A. Buzzard Tel: +44141-5483420HPC System Administrator, ARCHIE-WeSt.University of Strathclyde, John Anderson Building, Glasgow. G4 0NG___gpfsug-discuss mailing listgpfsug-discuss at spectrumscale.orghttp://gpfsug.org/mailman/listinfo/gpfsug-discuss ___ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
Re: [gpfsug-discuss] SMB server on GPFS clients and Followsymlinks
> I could use CES, but CES does not support follow-symlinks outside respective SMB export. Samba has the 'wide links' option, that we currently do not test and support as part of the mmsmb integration. You can always open a RFE and ask that we support this option in a future release. > Follow-symlinks is a however a hard-requirement for to follow links outside GPFS filesystems. I might be reading this wrong, but do you actually want symlinks that point to a file or directory outside of the GPFS file system? Could you outline a usecase for that? Regards, Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZchristof.schm...@us.ibm.com || +1-520-799-2469 (T/L: 321-2469) - Original message -From: vall...@cbio.mskcc.orgSent by: gpfsug-discuss-boun...@spectrumscale.orgTo: gpfsug main discussion list <gpfsug-discuss@spectrumscale.org>Cc:Subject: [gpfsug-discuss] SMB server on GPFS clients and FollowsymlinksDate: Tue, May 15, 2018 3:04 PM Hello All, Has anyone tried serving SMB export of GPFS mounts from a SMB server on GPFS client? Is it supported and does it lead to any issues? I understand that i will not need a redundant SMB server configuration. I could use CES, but CES does not support follow-symlinks outside respective SMB export. Follow-symlinks is a however a hard-requirement for to follow links outside GPFS filesystems. Thanks, Lohit ___gpfsug-discuss mailing listgpfsug-discuss at spectrumscale.orghttp://gpfsug.org/mailman/listinfo/gpfsug-discuss ___ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
Re: [gpfsug-discuss] SMB quotas query
To maybe clarify a few points: There are three quotas: user, group and fileset. User and group quota can be applied on the fileset level or the file system level. Samba with the vfs_gpfs module, only queries the user and group quotas on the requested path. If the fileset quota should also be applied to the reported free space, that has to be done through the --filesetdf parameter. We had the fileset quota query from Samba in the past, but that was a very problematic codepath, and it was removed as --filesetdf is the more reliabel way to achieve the same result. So another part of the question is which quotas should be applied to the reported free space. Regards, Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZchristof.schm...@us.ibm.com || +1-520-799-2469 (T/L: 321-2469) - Original message -From: Jonathan Buzzard <jonathan.buzz...@strath.ac.uk>Sent by: gpfsug-discuss-boun...@spectrumscale.orgTo: gpfsug main discussion list <gpfsug-discuss@spectrumscale.org>Cc:Subject: Re: [gpfsug-discuss] SMB quotas queryDate: Tue, May 15, 2018 3:24 AM On Tue, 2018-05-15 at 13:10 +0300, Yaron Daniel wrote:> Hi>> So - u want to get quota report per fileset quota - right ?> We use this param when we want to monitor the NFS exports with df , i> think this should also affect the SMB filesets.>> Can u try to enable it and see if it works ?>It is irrelevant to Samba, this is or should be handled in vfs_gpfs asChristof said earlier.JAB.--Jonathan A. Buzzard Tel: +44141-5483420HPC System Administrator, ARCHIE-WeSt.University of Strathclyde, John Anderson Building, Glasgow. G4 0NG___gpfsug-discuss mailing listgpfsug-discuss at spectrumscale.orghttp://gpfsug.org/mailman/listinfo/gpfsug-discuss ___ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
Re: [gpfsug-discuss] SMB quotas query
That is an interesting point. On the protocol level, the client opens a directory and then issues a QUERY_INFO to ask for the available space. In Samba, we then check the available space and applicable quotas on that path and return the requested information. The main question is probably on which directory the client asks for the available space. That can be seen in a network or smb trace. Regards, Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZchristof.schm...@us.ibm.com || +1-520-799-2469 (T/L: 321-2469) - Original message -From: "Sobey, Richard A" <r.so...@imperial.ac.uk>Sent by: gpfsug-discuss-boun...@spectrumscale.orgTo: gpfsug main discussion list <gpfsug-discuss@spectrumscale.org>Cc:Subject: Re: [gpfsug-discuss] SMB quotas queryDate: Mon, May 14, 2018 4:54 AM Thanks Jonathan. What I failed to mention in my OP was that MacOS clients DO report the correct size of each mounted folder. Not sure how that changes anything except to reinforce the idea that it's Windows at fault.Richard-Original Message-From: gpfsug-discuss-boun...@spectrumscale.org <gpfsug-discuss-boun...@spectrumscale.org> On Behalf Of Jonathan BuzzardSent: 14 May 2018 11:45To: gpfsug main discussion list <gpfsug-discuss@spectrumscale.org>Subject: Re: [gpfsug-discuss] SMB quotas queryOn Mon, 2018-05-14 at 10:09 +, Sobey, Richard A wrote:[SNIP]> > I am worried that IBM may tell us we’re doing it wrong (humm) and to> create individual exports for each fileset but this will quickly> become tiresome!>Worst case scenario you could fall back to using the dfree option in smb.conf and then use a program to get the file quota. I have the ~100 lines of C that you need it. Though it has been ~5 years since I last used it.In fact the whole reporting the fileset quota as the disk size is my idea, and the dfree config option is how I implemented it prior to IBM adding it to the vfs_gpfs module.A quick check shows a commit from Jeremy Allison on June 18th last year to use const stuct smb_filename, the comment on the commit is…instead of const char *.We need to migrate all pathname based VFS calls to use a struct to finish modernising the VFS with extra timestamp and flags parameters.I suspect this change has broken the behaviour.JAB.--Jonathan A. Buzzard Tel: +44141-5483420 HPC System Administrator, ARCHIE-WeSt.University of Strathclyde, John Anderson Building, Glasgow. G4 0NG___gpfsug-discuss mailing listgpfsug-discuss at spectrumscale.orghttp://gpfsug.org/mailman/listinfo/gpfsug-discuss___gpfsug-discuss mailing listgpfsug-discuss at spectrumscale.orghttp://gpfsug.org/mailman/listinfo/gpfsug-discuss ___ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
Re: [gpfsug-discuss] Not recommended, but why not?
> In fact, one of the things that’s kinda surprising to me is that upgrading the SMB portion of CES requires a downtime. Let’s just say that I know for a fact that sernet-samba can be done rolling / live. I am referring to the open source version of Samba here. That is likely close to "sernet-samba", but i have not seen the details on the code they use for the package build: Clustered Samba with ctdb never supported rolling code upgrades. The reason for this is that SMB-level records are shared across the protocol nodes through ctdb. These records are not versioned and Samba on each node expects to only see matching records. As the details of the internal data shared across the nodes can change through versions, the only safe way to handle this is to not allow rolling code upgrades. It might have appeared that Samba supports rolling code upgrades. Past versions did not check for version compatibility across the nodes, so there was no warning. If the ctdb records shared between the nodes did not change, then this would be no problem (for this particular upgrade path, it is likely different for different Samba versions). Also, if there are no open files or active sessions during the upgrade, the risk is lower, as in that case there are fewer records that could cause problems. The important change is that Samba 4.7.0 introduced checks to enforce compatible versions across the nodes. This just makes the limitation visible, but it was always there. See: https://www.samba.org/samba/history/samba-4.7.0.html * CTDB no longer allows mixed minor versions in a cluster See the AllowMixedVersions tunable option in ctdb-tunables(7) and also https://wiki.samba.org/index.php/Upgrading_a_CTDB_cluster#Policy and also https://wiki.samba.org/index.php/Upgrading_a_CTDB_cluster "Rolling Upgrades" and "Problems with Rolling Code Upgrades" Note that this page refers to two different layers. "ctdb" itself maintains compatibility among a X.Y. code stream, but this is not guaranteed for the file server records stored in ctdb databases. We have the same limitation and enforcement in the Samba version shipped with Spectrum Scale. I expect the same to be true for all clustered Samba versions today. Regards, Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZchristof.schm...@us.ibm.com || +1-520-799-2469 (T/L: 321-2469) - Original message -From: "Buterbaugh, Kevin L" <kevin.buterba...@vanderbilt.edu>Sent by: gpfsug-discuss-boun...@spectrumscale.orgTo: gpfsug main discussion list <gpfsug-discuss@spectrumscale.org>Cc:Subject: Re: [gpfsug-discuss] Not recommended, but why not?Date: Fri, May 4, 2018 12:12 PM Hi Anderson, Thanks for the response … however, the scenario you describe below wouldn’t impact us. We have 8 NSD servers and they can easily provide the needed performance to native GPFS clients. We could also take a downtime if we ever did need to expand in the manner described below. In fact, one of the things that’s kinda surprising to me is that upgrading the SMB portion of CES requires a downtime. Let’s just say that I know for a fact that sernet-samba can be done rolling / live. Kevin On May 4, 2018, at 10:52 AM, Anderson Ferreira Nobre <ano...@br.ibm.com> wrote: Hi Kevin, I think one of the reasons is if you need to add or remove nodes from cluster you will start to face the constrains of this kind of solution. Let's say you have a cluster with two nodes and share the same set of LUNs through SAN. And for some reason you need to add more two nodes that are NSD Servers and Protocol nodes. For the new nodes become NSD Servers, you will have to redistribute the NSD disks among four nodes. But for you do that you will have to umount the filesystems. And for you umount the filesystems you would need to stop protocol services. At the end you will realize that a simple task like that is disrruptive. You won't be able to do online. Abraços / Regards / Saludos, Anderson NobreAIX & Power ConsultantMaster Certified IT SpecialistIBM Systems Hardware Client Technical Team – IBM Systems Lab Services Phone: 55-19-2132-4317E-mail: ano...@br.ibm.com - Original message -From: "Buterbaugh, Kevin L" <kevin.buterba...@vanderbilt.edu>Sent by: gpfsug-discuss-boun...@spectrumscale.orgTo: gpfsug main discussion list <gpfsug-discuss@spectrumscale.org>Cc:Subject: [gpf
Re: [gpfsug-discuss] Experiences with Export Node Transition from 3.5-> 4.x
> We were wondering what the group's experiences have been with upgrading> export nodes from 3.5, especially those upgrades that involved a> transition from home-grown ADS domain integration to the new CES> integration piece.>> Specifcially, we're interested in:>> 1) What changes were necessary to make in your domain to get it to> interoperate with CES? I assume that this question relates to authentication with ActiveDirectory domains. Could you share details about the current setup?That would be helpful in determining the options going forward. > 2) Any good tips for CES workarounds in the case of domain> configuration that cannot be changed? Can you explain in more details what you mean with "cannot bechanged"? > 3) Experience with CES user-defined auth mode in particular? Has> anyone got this mode to work successfullly? "userdefined" authentication means that the CES stack does not managethe authentication related configuration options in the protocolservices. It is then up to the administrator to manually manage theconfigurations. The downside is that this is also stepping outside ofthe normal support, as we cannot test and validate all possibleconfiguration settings. We recommend to use one of the available CESconfiguration methods, as those are fully tested and supported. My recommendation would be first to understand the existing setup,then try to map that to a supported CES configuration method. If apiece is missing, then it would still make sense to make use of theexisting CES methods as much as possible, to stay as close as possiblewith a supported configuration. Regards, Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZchristof.schm...@us.ibm.com || +1-520-799-2469 (T/L: 321-2469) - Original message -From: "Howard, Stewart Jameson" <sjhow...@iu.edu>Sent by: gpfsug-discuss-boun...@spectrumscale.orgTo: "gpfsug-discuss@spectrumscale.org" <gpfsug-discuss@spectrumscale.org>Cc:Subject: [gpfsug-discuss] Experiences with Export Node Transition from 3.5 -> 4.xDate: Fri, Apr 6, 2018 8:21 AM Hi All,We were wondering what the group's experiences have been with upgradingexport nodes from 3.5, especially those upgrades that involved atransition from home-grown ADS domain integration to the new CESintegration piece.Specifcially, we're interested in:1) What changes were necessary to make in your domain to get it tointeroperate with CES?2) Any good tips for CES workarounds in the case of domainconfiguration that cannot be changed?3) Experience with CES user-defined auth mode in particular? Hasanyone got this mode to work successfullly?Let us know. Thanks!Stewart HowardIndiana University___gpfsug-discuss mailing listgpfsug-discuss at spectrumscale.orghttps://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=5Nn7eUPeYe291x8f39jKybESLKv_W_XtkTkS8fTR-NI=gK8gMShOTfCp6HLaAO-JwzR5kl9xGbuaSzIIvJgDARA=8MoJ8aFltv_Quyv-cbZXWVpHeDE7OOJcWqjz-ufARY8= ___ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
Re: [gpfsug-discuss] wondering about outage free protocols upgrades
> Back in the day when one had to roll your own Samba for this stuff,> rolling Samba upgrades worked. What changed or was it never supported? It was never supported for clustered Samba. As the problem is with incompatibilities in Samba internal database records: If nothing changed in the record and communication format for a specific upgrade, then it works for that specific case. As this requires a thorough code review that also can easily miss subtle changes, the safe assumption is that the rolling upgrade won't work. Regards, Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZchristof.schm...@us.ibm.com || +1-520-799-2469 (T/L: 321-2469) - Original message -From: Jonathan Buzzard <jonathan.buzz...@strath.ac.uk>Sent by: gpfsug-discuss-boun...@spectrumscale.orgTo: gpfsug main discussion list <gpfsug-discuss@spectrumscale.org>Cc:Subject: Re: [gpfsug-discuss] wondering about outage free protocols upgradesDate: Fri, Mar 9, 2018 5:37 AM On Thu, 2018-03-08 at 09:41 +, Sobey, Richard A wrote:> Whether or not you meant it your words “that is not available today.”> Implies that something is coming in the future? Would you be reliant> on the Samba/CTDB development team or would you roll your own..> supposing it’s possible in the first place.> Back in the day when one had to roll your own Samba for this stuff,rolling Samba upgrades worked. What changed or was it never supported?JAB.--Jonathan A. Buzzard Tel: +44141-5483420HPC System Administrator, ARCHIE-WeSt.University of Strathclyde, John Anderson Building, Glasgow. G4 0NG___gpfsug-discuss mailing listgpfsug-discuss at spectrumscale.orghttps://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=5Nn7eUPeYe291x8f39jKybESLKv_W_XtkTkS8fTR-NI=LtsZs7PVYIrBoo7XGdyFheoabDxWNtNco7dWhZb3k90=b0x2HL7Yq8DqFdEV2UtGGIEIYLqIKmPcQVv1-e4GoY0= ___ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
Re: [gpfsug-discuss] wondering about outage free protocols upgrades
Apologies if that was misleading. As stated before there are no plans to support rolling code upgrade for SMB in Spectrum Scale. To answer your question with some speculation, which is no commitment: If there was ever an effort to make rolling upgrade available in clustered Samba, that would be core changes to the Samba internal databases. In my opinion that would only make sense in collaboration with the Samba open source team. Technically it would be possible, and also as mentioned before, it is the effort to design, implement and test these changes that make this a huge task. Regards, Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZchristof.schm...@us.ibm.com || +1-520-799-2469 (T/L: 321-2469) - Original message -From: "Sobey, Richard A" <r.so...@imperial.ac.uk>Sent by: gpfsug-discuss-boun...@spectrumscale.orgTo: gpfsug main discussion list <gpfsug-discuss@spectrumscale.org>Cc:Subject: Re: [gpfsug-discuss] wondering about outage free protocols upgradesDate: Thu, Mar 8, 2018 2:42 AM Whether or not you meant it your words “that is not available today.” Implies that something is coming in the future? Would you be reliant on the Samba/CTDB development team or would you roll your own.. supposing it’s possible in the first place. Thanks Richard From: gpfsug-discuss-boun...@spectrumscale.org [mailto:gpfsug-discuss-boun...@spectrumscale.org] On Behalf Of Christof SchmittSent: 07 March 2018 21:54To: gpfsug-discuss@spectrumscale.orgSubject: Re: [gpfsug-discuss] wondering about outage free protocols upgrades The problem with the SMB upgrade is with the data shared between the protocol nodes. It is not tied to the protocol version used between SMB clients and the protocol nodes. Samba stores internal data (e.g. for the SMB state of open files) in tdb database files. ctdb then makes these tdb databases available across all protocol nodes. A concurrent upgrade for SMB would require correct handling of ctdb communications and the tdb records across multiple versions; that is not available today. Regards, Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZchristof.schm...@us.ibm.com || +1-520-799-2469 (T/L: 321-2469) - Original message -From: <greg.lehm...@csiro.au>Sent by: gpfsug-discuss-boun...@spectrumscale.orgTo: <gpfsug-discuss@spectrumscale.org>Cc:Subject: Re: [gpfsug-discuss] wondering about outage free protocols upgradesDate: Wed, Mar 7, 2018 4:35 AM In theory it only affects SMB, but in practice if NFS depends on winbind for authorisation then it is affected too. I can understand the need for changes to happen every so often and that maybe outages will be required then. But, I would like to see some effort to avoid doing this unnecessarily. IBM, please consider my suggestion. The message I get from the ctdb service implies it is the sticking point. Can some consideration be given to keeping the ctdb version compatible between releases? Christof, you are saying something about the SMB service version compatibility. I am unclear as to whether you are talking about the Spectrum Scale Protocols SMB service or the default samba SMB over the wire protocol version being used to communicate between client and server. If the latter, is it possible to peg the version to the older version manually while doing the upgrade so that all nodes can be updated? You can then take an outage at a later time to update the over the wire version. From: gpfsug-discuss-boun...@spectrumscale.org [mailto:gpfsug-discuss-boun...@spectrumscale.org] On Behalf Of Christof SchmittSent: Wednesday, 7 March 2018 4:50 AMTo: gpfsug-discuss@spectrumscale.orgCc: gpfsug-discuss@spectrumscale.orgSubject: Re: [gpfsug-discuss] wondering about outage free protocols upgrades Hi, at this point there are no plans to support "node by node" upgrade for SMB. Some background: The technical reason for this restriction is that the records shared between protocol nodes for the SMB service (ctdb and Samba) are not versioned and no mechanism is in place to handle different versions. Changing this would be a large development task that has not been included in any current plans. Note that this only affects the SMB service and that the knowledge center outlines a procedure to minimize the outage, by getting half of the protocol nodes ready with the new Samba version and then only taking a brief outage when switching from the "old" to the "new" Samba version: https://www.ibm.com/support/knowledgecenter/en/STXKQY_4.2.2/com.ibm.spectrum.scale.v4r22.doc/bl1ins_updatingsmb.htm The toolkit follows the same approach during an upgrade to minimize the outage. We know that this is not ideal, but as mentioned above this is limited by the large effort that would be required which has to be weighed against other requirements and priorities. Regards, Christof Schmitt || IBM || Spectrum Scale Development || Tucson,
Re: [gpfsug-discuss] wondering about outage free protocols upgrades
The problem with the SMB upgrade is with the data shared between the protocol nodes. It is not tied to the protocol version used between SMB clients and the protocol nodes. Samba stores internal data (e.g. for the SMB state of open files) in tdb database files. ctdb then makes these tdb databases available across all protocol nodes. A concurrent upgrade for SMB would require correct handling of ctdb communications and the tdb records across multiple versions; that is not available today. Regards, Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZchristof.schm...@us.ibm.com || +1-520-799-2469 (T/L: 321-2469) - Original message -From: <greg.lehm...@csiro.au>Sent by: gpfsug-discuss-boun...@spectrumscale.orgTo: <gpfsug-discuss@spectrumscale.org>Cc:Subject: Re: [gpfsug-discuss] wondering about outage free protocols upgradesDate: Wed, Mar 7, 2018 4:35 AM In theory it only affects SMB, but in practice if NFS depends on winbind for authorisation then it is affected too. I can understand the need for changes to happen every so often and that maybe outages will be required then. But, I would like to see some effort to avoid doing this unnecessarily. IBM, please consider my suggestion. The message I get from the ctdb service implies it is the sticking point. Can some consideration be given to keeping the ctdb version compatible between releases? Christof, you are saying something about the SMB service version compatibility. I am unclear as to whether you are talking about the Spectrum Scale Protocols SMB service or the default samba SMB over the wire protocol version being used to communicate between client and server. If the latter, is it possible to peg the version to the older version manually while doing the upgrade so that all nodes can be updated? You can then take an outage at a later time to update the over the wire version. From: gpfsug-discuss-boun...@spectrumscale.org [mailto:gpfsug-discuss-boun...@spectrumscale.org] On Behalf Of Christof SchmittSent: Wednesday, 7 March 2018 4:50 AMTo: gpfsug-discuss@spectrumscale.orgCc: gpfsug-discuss@spectrumscale.orgSubject: Re: [gpfsug-discuss] wondering about outage free protocols upgrades Hi, at this point there are no plans to support "node by node" upgrade for SMB. Some background: The technical reason for this restriction is that the records shared between protocol nodes for the SMB service (ctdb and Samba) are not versioned and no mechanism is in place to handle different versions. Changing this would be a large development task that has not been included in any current plans. Note that this only affects the SMB service and that the knowledge center outlines a procedure to minimize the outage, by getting half of the protocol nodes ready with the new Samba version and then only taking a brief outage when switching from the "old" to the "new" Samba version: https://www.ibm.com/support/knowledgecenter/en/STXKQY_4.2.2/com.ibm.spectrum.scale.v4r22.doc/bl1ins_updatingsmb.htm The toolkit follows the same approach during an upgrade to minimize the outage. We know that this is not ideal, but as mentioned above this is limited by the large effort that would be required which has to be weighed against other requirements and priorities. Regards, Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZchristof.schm...@us.ibm.com || +1-520-799-2469 (T/L: 321-2469) - Original message -From: <greg.lehm...@csiro.au>Sent by: gpfsug-discuss-boun...@spectrumscale.orgTo: <gpfsug-discuss@spectrumscale.org>Cc:Subject: [gpfsug-discuss] wondering about outage free protocols upgradesDate: Tue, Mar 6, 2018 10:19 AM Hi All, It appears a rolling node by node upgrade of a protocols cluster is not possible. Ctdb is the sticking point as it won’t run with 2 different versions at the same time. Are there any plans to address this and make it a real Enterprise product? Cheers, Greg ___gpfsug-discuss mailing listgpfsug-discuss at spectrumscale.orghttps://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss=DwICAg=jf_iaSHvJObTbx-siA1ZOg=5Nn7eUPeYe291x8f39jKybESLKv_W_XtkTkS8fTR-NI=p5fg7X1tKGwi1BsYiw-wHTxmaG-PLihwHV0yTBQNaUs=3ZHS5vAoxeC6ikuOpTRLWNTpvgKEC3thI-qUgyU_hYo= ___gpfsug-discuss mailing listgpfsug-discuss at spectrumscale.orghttps://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss=DwICAg=jf_iaSHvJObTbx-siA1ZOg=5Nn7eUPeYe291x8f39jKybESLKv_W_XtkTkS8fTR-NI=7bQRypv0JL7swEYobmepaynWFvV8HYtBa2_S1kAyirk=2bUeeDk-8VbtwU8KtV4RlENEcbpOr_GQJQvR_8gt-ug= ___ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
Re: [gpfsug-discuss] wondering about outage free protocols upgrades
Rolling code upgrade was never support for SMB for the reasons mention in my other email. The change in 5.0 is to enforce this restriction on a code level. The SMB service will refuse to start on a protocol node, if an incompatible version is already running on another node. Regards, Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZchristof.schm...@us.ibm.com || +1-520-799-2469 (T/L: 321-2469) - Original message -From: "Sobey, Richard A" <r.so...@imperial.ac.uk>Sent by: gpfsug-discuss-boun...@spectrumscale.orgTo: "gpfsug-discuss@spectrumscale.org" <gpfsug-discuss@spectrumscale.org>, gpfsug main discussion list <gpfsug-discuss@spectrumscale.org>Cc:Subject: Re: [gpfsug-discuss] wondering about outage free protocols upgradesDate: Tue, Mar 6, 2018 11:49 AM Thanks for raising this, I was going to ask. The last I heard it was baked into the 5.0 release of Scale but the release notes are eerily quiet on the matter. Would be good to get some input from IBM on this. Richard Get Outlook for Android From: gpfsug-discuss-boun...@spectrumscale.org <gpfsug-discuss-boun...@spectrumscale.org> on behalf of greg.lehm...@csiro.au <greg.lehm...@csiro.au>Sent: Friday, March 2, 2018 3:48:44 AMTo: gpfsug-discuss@spectrumscale.orgSubject: [gpfsug-discuss] wondering about outage free protocols upgrades Hi All, It appears a rolling node by node upgrade of a protocols cluster is not possible. Ctdb is the sticking point as it won’t run with 2 different versions at the same time. Are there any plans to address this and make it a real Enterprise product? Cheers, Greg ___gpfsug-discuss mailing listgpfsug-discuss at spectrumscale.orghttps://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss=DwICAg=jf_iaSHvJObTbx-siA1ZOg=5Nn7eUPeYe291x8f39jKybESLKv_W_XtkTkS8fTR-NI=bPllsWtGZ9ZmxVPYCKZnzIbVPvZEo3IevykEm3tqRR0=SNPiJbSYXpLQ1hfQyPt5FH671N464RBobumx5zX3Ios= ___ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
Re: [gpfsug-discuss] wondering about outage free protocols upgrades
Hi, at this point there are no plans to support "node by node" upgrade for SMB. Some background: The technical reason for this restriction is that the records shared between protocol nodes for the SMB service (ctdb and Samba) are not versioned and no mechanism is in place to handle different versions. Changing this would be a large development task that has not been included in any current plans. Note that this only affects the SMB service and that the knowledge center outlines a procedure to minimize the outage, by getting half of the protocol nodes ready with the new Samba version and then only taking a brief outage when switching from the "old" to the "new" Samba version: https://www.ibm.com/support/knowledgecenter/en/STXKQY_4.2.2/com.ibm.spectrum.scale.v4r22.doc/bl1ins_updatingsmb.htm The toolkit follows the same approach during an upgrade to minimize the outage. We know that this is not ideal, but as mentioned above this is limited by the large effort that would be required which has to be weighed against other requirements and priorities. Regards, Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZchristof.schm...@us.ibm.com || +1-520-799-2469 (T/L: 321-2469) - Original message -From: <greg.lehm...@csiro.au>Sent by: gpfsug-discuss-boun...@spectrumscale.orgTo: <gpfsug-discuss@spectrumscale.org>Cc:Subject: [gpfsug-discuss] wondering about outage free protocols upgradesDate: Tue, Mar 6, 2018 10:19 AM Hi All, It appears a rolling node by node upgrade of a protocols cluster is not possible. Ctdb is the sticking point as it won’t run with 2 different versions at the same time. Are there any plans to address this and make it a real Enterprise product? Cheers, Greg ___gpfsug-discuss mailing listgpfsug-discuss at spectrumscale.orghttps://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss=DwICAg=jf_iaSHvJObTbx-siA1ZOg=5Nn7eUPeYe291x8f39jKybESLKv_W_XtkTkS8fTR-NI=p5fg7X1tKGwi1BsYiw-wHTxmaG-PLihwHV0yTBQNaUs=3ZHS5vAoxeC6ikuOpTRLWNTpvgKEC3thI-qUgyU_hYo= ___ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
Re: [gpfsug-discuss] SMB with LDAP
To answer the questions from below: > I’m assuming smbpasswd -a is still required for all users? No, the passwords are stored as hashes in the sambaNTPasswordattribute on the LDAP server. > What keeps the LDAP/SMB passwords in sync? See above, the SMB passwords are only stored in the LDAP server. > What access does the bind user need in LDAP? Either read or read/write access. With write access, Samba willautomatically write the sambaDomain object. Without write access, thatobject has to be created manually. > What special requirements are required for Windows 10 clients to connect? I am not aware of any special requirements. The overall requirementfor SMB and LDAP is that the Samba schema is installed on the LDAPserver, and the attributes are set correctly. Regards, Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZchristof.schm...@us.ibm.com || +1-520-799-2469 (T/L: 321-2469) - Original message -From: Jeno Cram <jc...@ddn.com>Sent by: gpfsug-discuss-boun...@spectrumscale.orgTo: "gpfsug-discuss@spectrumscale.org" <gpfsug-discuss@spectrumscale.org>Cc:Subject: [gpfsug-discuss] SMB with LDAPDate: Tue, Jan 9, 2018 8:38 AM Has anyone had any luck implementing CES with SMB using LDAP? This link doesn’t seem to have all of the information required to getting it working properly. https://www.ibm.com/support/knowledgecenter/en/STXKQY_4.2.3/com.ibm.spectrum.scale.v4r23.doc/bl1adm_updateldapsmb.htm I’m assuming smbpasswd -a is still required for all users?What keeps the LDAP/SMB passwords in sync? What access does the bind user need in LDAP?What special requirements are required for Windows 10 clients to connect? Jeno Cram | Lead Application Support Engineer jc...@ddn.com ___gpfsug-discuss mailing listgpfsug-discuss at spectrumscale.orghttps://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss=DwICAg=jf_iaSHvJObTbx-siA1ZOg=5Nn7eUPeYe291x8f39jKybESLKv_W_XtkTkS8fTR-NI=sU5XKUck2iWsGZGkPkldCLrw26oU4BN7VbomgyuYmqk=IL7UzuObhDPnUekuvZ9YGMCBXU4PkNwZvCDY2-h0jls= ___ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
Re: [gpfsug-discuss] Antwort: [Newsletter] Re: gpfs.so vfs samba module is missing ***CAUTION_Invalid_Signature***
Whether the gpfs.so module is included depends on each Samba build. Samba provided by Linux distributions typically does not include the gpfs.so module. Sernet package include it. The gpfs.smb Samba build we use in Spectrum Scale also obviously includes the gpfs.so module: # rpm -ql gpfs.smb | grep gpfs.so/usr/lpp/mmfs/lib64/samba/vfs/gpfs.so The main point from a Spectrum Scale point of view: Spectrum Scale only supports the Samba from the gpfs.smb package that was provided with the product. Using any other Samba version is outside of the scope of Spectrum Scale support. Regards, Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZchristof.schm...@us.ibm.com || +1-520-799-2469 (T/L: 321-2469) - Original message -From: matthias.kni...@rohde-schwarz.comSent by: gpfsug-discuss-boun...@spectrumscale.orgTo: gpfsug main discussion list <gpfsug-discuss@spectrumscale.org>Cc:Subject: [gpfsug-discuss] Antwort: [Newsletter] Re: gpfs.so vfs samba module is missing ***CAUTION_Invalid_Signature***Date: Fri, Nov 17, 2017 12:04 PM https://manpages.debian.org/testing/samba-vfs-modules/vfs_gpfs.8.en.htmlI do not think so, the module is a part of samba. I installed the package gpfs.smb too but with the same result. Before I use the normal version of samba I used the version of sernet. There was the module available. Now I am working with CentOS 7.3 and samba of the offical repository of CentOS.Thanks,MatthiasVon: valdis.kletni...@vt.eduAn: gpfsug main discussion list <gpfsug-discuss@spectrumscale.org>Datum: 17.11.2017 17:51Betreff: [Newsletter] Re: [gpfsug-discuss] gpfs.so vfs samba module is missing ***CAUTION_Invalid_Signature***Gesendet von: gpfsug-discuss-boun...@spectrumscale.org On Fri, 17 Nov 2017 14:39:47 +0100, matthias.kni...@rohde-schwarz.com said:> anyone know in which package I can find the gpfs vfs module? Currently I> am working with gpfs 4.2.3.0 and Samba 4.4.4. Normally the samba package> provides the vfs module. I updated Samba to 4.6.2 but the gpfs-vfs-module> is still missing.If you're running the IBM-supported protocols server config, you want the rpm 'gpfs.smb'.If you're trying to build your own, your best bet is to punt and install the IBM code. ;)___gpfsug-discuss mailing listgpfsug-discuss at spectrumscale.orghttp://gpfsug.org/mailman/listinfo/gpfsug-discuss[Anhang "RohdeSchwarzSecure_E-Mail.html" gelöscht von Matthias Knigge/DVS] ___gpfsug-discuss mailing listgpfsug-discuss at spectrumscale.orghttps://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss=DwICAg=jf_iaSHvJObTbx-siA1ZOg=5Nn7eUPeYe291x8f39jKybESLKv_W_XtkTkS8fTR-NI=M1Ebd4GVVmaCFs3t0xgGUpgZUM9CzrxWR9I6cvzUqns=ONPhff8MP60AoglpZvh9xBAPlV98nW-SmuWoN4EVzUk= ___ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
Re: [gpfsug-discuss] Snapshots / previous versions issues in Windows10 1709
Richard, in a quick test with Windows 10 Pro 1709 connecting to gpfs.smb 4.5.10_gpfs_21 i do not see the problem from the screenshot. All files reported in "Previous Versions" have a date associated. For debugging the problem on your system, i would suggest to enable traces and recreate the problem. Replace the x.x.x.x with the IP address of the Windows 10 client: mmprotocoltrace start network -c x.x.x.x mmprotocoltrace start smb -c x.x.x.x (open the "Previous Versions" dialog) mmprotocoltrace stop smb mmprotocoltrace stop network The best way to track the analysis would be through a PMR. Regards, Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZ christof.schm...@us.ibm.com || +1-520-799-2469 (T/L: 321-2469) - Original message - From: "Sobey, Richard A" <r.so...@imperial.ac.uk> Sent by: gpfsug-discuss-boun...@spectrumscale.org To: "'gpfsug-discuss@spectrumscale.org'" <gpfsug-discuss@spectrumscale.org> Cc: Subject: [gpfsug-discuss] Snapshots / previous versions issues in Windows10 1709 Date: Mon, Oct 30, 2017 8:32 AM All, Since upgrading to Windows 10 build 1709 aka Autumn Creator’s Update our Previous Versions is wonky… as in you just get a flat list of previous versions^^snapshots with no date associated with them. I am not able to test this on a server with the latest Samba release so at the moment I’m stuck reporting that GPFS 4.2.3-4 with smb 4.5.10 doesn’t play nicely with Windows 10 1709. Screenshot is attached for an example. Can anyone corroborate my findings? Thanks Richard ___ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org https://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss=DwICAg=jf_iaSHvJObTbx-siA1ZOg=5Nn7eUPeYe291x8f39jKybESLKv_W_XtkTkS8fTR-NI=Bfd_a1yscUVzXzIRuwarah8UedH7U1Uln5AFFPQayR4=URMLuAJbrlEOj4xt3_7_Cm0Rj9DfFovuEUOGc4zQUUY= ___ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
Re: [gpfsug-discuss] how to deal with custom samba options in ces
Hi, in current Scale releases, the Samba option 'strict locking' is set to 'auto'. This is a reasonable optimization as documented in 'man smb.conf': strict locking (S) This is an enumerated type that controls the handling of file locking in the server. When this is set to yes, the server will check every read and write access for file locks, and deny access if locks exist. This can be slow on some systems. When strict locking is set to Auto (the default), the server performs file lock checks only on non-oplocked files. As most Windows redirectors perform file locking checks locally on oplocked files this is a good trade off for improved performance. When strict locking is disabled, the server performs file lock checks only when the client explicitly asks for them. Well-behaved clients always ask for lock checks when it is important. So in the vast majority of cases, strict locking = Auto or strict locking = no is acceptable. Default: strict locking = Auto You can change the underlying Samba configuration, but running with a different setting of 'strict locking' has not been tested and is outside of the normal support. Do you have a usecase where the default setting does not work and 'strict locking = yes' is required? Regards, Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZchristof.schm...@us.ibm.com || +1-520-799-2469 (T/L: 321-2469) - Original message -From: "Fey, Christian" <christian@sva.de>Sent by: gpfsug-discuss-boun...@spectrumscale.orgTo: gpfsug main discussion list <gpfsug-discuss@spectrumscale.org>Cc:Subject: [gpfsug-discuss] how to deal with custom samba options in cesDate: Thu, Oct 26, 2017 11:31 PM Hi all, I'm just in the process of migration different samba clusters to ces and I recognized, that some clusters have options set like "strict locking = yes" and I'm not sure how to deal with this. From what I know, there is no "CES way" to set every samba option. It would be possible to set with "net" commands I think but probably this will lead to an unsupported state. Anyone came through this? Mit freundlichen Grüßen / Best RegardsChristian FeySVA System Vertrieb Alexander GmbHBorsigstraße 1465205 WiesbadenTel.: +49 6122 536-0Fax: +49 6122 536-399E-Mail: christian@sva.dehttp://www.sva.deGeschäftsführung: Philipp Alexander, Sven EichelbaumSitz der Gesellschaft: WiesbadenRegistergericht: Amtsgericht Wiesbaden, HRB 10315 ___gpfsug-discuss mailing listgpfsug-discuss at spectrumscale.orghttp://gpfsug.org/mailman/listinfo/gpfsug-discuss ___ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
Re: [gpfsug-discuss] number of SMBD processes
Hello, the short answer is that the "deadtime" parameter is not a supported parameter in Spectrum Scale. The longer answer is that setting "deadtime" likely does not solve any issue. "deadtime" was introduced in Samba mainly for older protocol versions. While it is implemented independent of protocol versions, not the statement about "no open files" for a connection to be closed. Spectrum Scale only supports SMB versions 2 and 3. Basically everything there is based on an open file handle. Most SMB 2/3 clients open at least the root directory of the export and register for change notifications there and the client then can wait for any time for changes. That is a valid case, and the open directory handle prevents the connection from being affected by any setting of the "deadtime" parameter. Clients that are no longer active and have not properly closed the connection are detected on the TCP level: # mmsmb config list | grep socksocket options TCP_NODELAY SO_KEEPALIVE TCP_KEEPCNT=4 TCP_KEEPIDLE=240 TCP_KEEPINTVL=15 Every client that no longer responds for 5 minutes will have the connection dropped (240s + 4x15s). On the other hand, if the SMB clients are still responding to TCP keep-alive packets, then the connection is considered valid. It might be interesting to look into the unwanted connections and possibly capture a network trace or look into the client systems to better understand the situation. Regards, Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZchristof.schm...@us.ibm.com || +1-520-799-2469 (T/L: 321-2469) - Original message -From: "Ouwehand, JJ" <j.ouweh...@vumc.nl>Sent by: gpfsug-discuss-boun...@spectrumscale.orgTo: "gpfsug-discuss@spectrumscale.org" <gpfsug-discuss@spectrumscale.org>Cc:Subject: [gpfsug-discuss] number of SMBD processesDate: Mon, Oct 2, 2017 6:35 AM Hello, Since we use new “IBM Spectrum Scale SMB CES” nodes, we see that that the number of SMBD processes has increased significantly from ~ 4,000 to ~ 7,500. We also see that the SMBD processes are not closed. This is likely because the Samba global-parameter “deadtime” is missing. https://www.samba.org/samba/docs/using_samba/ch11.html This global option sets the number of minutes that Samba will wait for an inactive client before closing its session with the Samba server. A client is considered inactive when it has no open files and no data is being sent from it. The default value for this option is 0, which means that Samba never closes any connection, regardless of how long they have been inactive. This can lead to unnecessary consumption of the server's resources by inactive clients. We recommend that you override the default as follows: [global] deadtime = 10 Is this Samba parameter “deadtime” supported by IBM? Kindly regards, Jaap Jan OuwehandICT Specialist (Storage & Linux) VUmc - ICT ___gpfsug-discuss mailing listgpfsug-discuss at spectrumscale.orghttps://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss=DwICAg=jf_iaSHvJObTbx-siA1ZOg=5Nn7eUPeYe291x8f39jKybESLKv_W_XtkTkS8fTR-NI=LCAKWPxQj5PMUf5YKTH3Z0zW9cDW--1AO_mljWE3ni8=y0FjQ5P-9Q7YjxyvuNNa4kdzHZKfrsjW81pGDLMNuig= ___ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
Re: [gpfsug-discuss] mmsmb exportacl remove - syntax changed?
The default for the "export ACL" is always to allow access to "Everyone", so that the the "export ACL" does not limit access by default, but only the file system ACL. I do not have systems with these code levels at hand, could you show the difference you see between PTF2 and PTF4?
Regards,
Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZchristof.schm...@us.ibm.com || +1-520-799-2469 (T/L: 321-2469)
- Original message -From: "Sobey, Richard A" <r.so...@imperial.ac.uk>Sent by: gpfsug-discuss-boun...@spectrumscale.orgTo: gpfsug main discussion list <gpfsug-discuss@spectrumscale.org>Cc: "gpfsug-disc...@gpfsug.org" <gpfsug-disc...@gpfsug.org>Subject: Re: [gpfsug-discuss] mmsmb exportacl remove - syntax changed?Date: Tue, Sep 26, 2017 2:59 AM
There isn’t a default ACL being applied to the export at all now, which is fine, but it differs from the behaviour in 4.2.3 PTF2.
Thanks
Richard
From: gpfsug-discuss-boun...@spectrumscale.org [mailto:gpfsug-discuss-boun...@spectrumscale.org] On Behalf Of Sobey, Richard ASent: 26 September 2017 09:22To: gpfsug main discussion list <gpfsug-discuss@spectrumscale.org>Cc: gpfsug-disc...@gpfsug.orgSubject: Re: [gpfsug-discuss] mmsmb exportacl remove - syntax changed?
Hi Christof, thanks I’ll try it on a test cluster.
Richard
From: gpfsug-discuss-boun...@spectrumscale.org [mailto:gpfsug-discuss-boun...@spectrumscale.org] On Behalf Of Christof SchmittSent: 25 September 2017 22:41To: gpfsug-discuss@spectrumscale.orgCc: gpfsug-disc...@gpfsug.orgSubject: Re: [gpfsug-discuss] mmsmb exportacl remove - syntax changed?
4.2.3 PTF4 seems to have a fix for this area. Can you try again with that PTF installed?
Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZchristof.schm...@us.ibm.com || +1-520-799-2469 (T/L: 321-2469)
- Original message -From: "Sobey, Richard A" <r.so...@imperial.ac.uk>Sent by: gpfsug-discuss-boun...@spectrumscale.orgTo: "gpfsug-disc...@gpfsug.org" <gpfsug-disc...@gpfsug.org>Cc:Subject: [gpfsug-discuss] mmsmb exportacl remove - syntax changed?Date: Mon, Sep 25, 2017 7:35 AM
Hi all,
This used to work (removing a SID from an ACL), but doesn't any more. Looks like a bug unless I'm being stupid.
[root@cesnode~]# mmsmb exportacl list neuroscience2 --viewsids
[neuroscience2]
REVISION:1
ACL:S-1-1-0:ALLOWED/FULL
[root@cesnode ~] mmsmb exportacl remove neuroscience2 --SID S-1-1-0
mmsmb exportacl remove: Incorrect option: --sid
Usage:
mmsmb exportacl remove ExportName {Name | --user UserName | --group GroupName | --system SystemName | --SID SID} [--access Access] [--permissions Permissions] [--viewsddl] [--viewsids] [-h|--help]
where:
Access is one of ALLOWED, DENIED
Permissions is one of FULL, CHANGE, READ or any combination of RWXDPO
I've tried lower case SID i.e --sid, and specifying --access ALLOWED and --permissions FULL.
Omitting the --SID argument entirely simply results in GPFS telling me I must specify a Name or an SID.
[root@cesnode~]# mmsmb exportacl remove neuroscience2 --access ALLOWED --permissions FULL
[E] The mmsmb exportacl remove command requires a Name or SID.
Can anyone see my mistake?
Richard
___gpfsug-discuss mailing listgpfsug-discuss at spectrumscale.orghttps://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss=DwICAg=jf_iaSHvJObTbx-siA1ZOg=5Nn7eUPeYe291x8f39jKybESLKv_W_XtkTkS8fTR-NI=c3uTUNFbPTWWcTNUNVVejlQ0xdnhBAfQdouTBlVgnjc=hsWeRhH-BhTEaAlrTPbJGlwCV-5Ui7t03Zcec9kywOA=
___gpfsug-discuss mailing listgpfsug-discuss at spectrumscale.orghttps://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss=DwICAg=jf_iaSHvJObTbx-siA1ZOg=5Nn7eUPeYe291x8f39jKybESLKv_W_XtkTkS8fTR-NI=B-AqKIRCmLBzoWAhGn7NY-ZASOX25NuP_c_ndE8gy4A=S06OD3mbRedYjfwETO8tUnlOjnWT7pOX8nsYX5ebIdA=
___
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss
Re: [gpfsug-discuss] mmsmb exportacl remove - syntax changed?
4.2.3 PTF4 seems to have a fix for this area. Can you try again with that PTF installed?
Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZchristof.schm...@us.ibm.com || +1-520-799-2469 (T/L: 321-2469)
- Original message -From: "Sobey, Richard A" <r.so...@imperial.ac.uk>Sent by: gpfsug-discuss-boun...@spectrumscale.orgTo: "gpfsug-disc...@gpfsug.org" <gpfsug-disc...@gpfsug.org>Cc:Subject: [gpfsug-discuss] mmsmb exportacl remove - syntax changed?Date: Mon, Sep 25, 2017 7:35 AM
Hi all,
This used to work (removing a SID from an ACL), but doesn't any more. Looks like a bug unless I'm being stupid.
[root@cesnode~]# mmsmb exportacl list neuroscience2 --viewsids
[neuroscience2]
REVISION:1
ACL:S-1-1-0:ALLOWED/FULL
[root@cesnode ~] mmsmb exportacl remove neuroscience2 --SID S-1-1-0
mmsmb exportacl remove: Incorrect option: --sid
Usage:
mmsmb exportacl remove ExportName {Name | --user UserName | --group GroupName | --system SystemName | --SID SID} [--access Access] [--permissions Permissions] [--viewsddl] [--viewsids] [-h|--help]
where:
Access is one of ALLOWED, DENIED
Permissions is one of FULL, CHANGE, READ or any combination of RWXDPO
I've tried lower case SID i.e --sid, and specifying --access ALLOWED and --permissions FULL.
Omitting the --SID argument entirely simply results in GPFS telling me I must specify a Name or an SID.
[root@cesnode~]# mmsmb exportacl remove neuroscience2 --access ALLOWED --permissions FULL
[E] The mmsmb exportacl remove command requires a Name or SID.
Can anyone see my mistake?
Richard
___gpfsug-discuss mailing listgpfsug-discuss at spectrumscale.orghttps://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss=DwICAg=jf_iaSHvJObTbx-siA1ZOg=5Nn7eUPeYe291x8f39jKybESLKv_W_XtkTkS8fTR-NI=c3uTUNFbPTWWcTNUNVVejlQ0xdnhBAfQdouTBlVgnjc=hsWeRhH-BhTEaAlrTPbJGlwCV-5Ui7t03Zcec9kywOA=
___
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss
Re: [gpfsug-discuss] Strange timestamp behaviour on NFS via CES
Apologies, point 2) should read: POSIX user and group names on the other hand are case-sensitive and case-preserving Regards, Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZchristof.schm...@us.ibm.com || +1-520-799-2469 (T/L: 321-2469) - Original message -From: "Christof Schmitt" <christof.schm...@us.ibm.com>Sent by: gpfsug-discuss-boun...@spectrumscale.orgTo: gpfsug-discuss@spectrumscale.orgCc: gpfsug-discuss@spectrumscale.orgSubject: Re: [gpfsug-discuss] Strange timestamp behaviour on NFS via CESDate: Fri, Sep 22, 2017 3:09 PM The problem here is a combination of a few things: 1) As mentioned below, user and group names in Active Directory are case-insensitive and case-preserving. 2) POSIX user and group names on the other hand are case-insensitive and case-preserving. winbindd handles this case by always converting names to lower-case, which also provides a consistent view through the POSIX interfaces. Otherwise there could be side-effects when different versions are used to access the same group (e.g. group1 and Group1). 3) NFSv4 uses user and group names over the wire. I might be missing details, and there are also setups where uids and gids are used. The basic problem is the mismatch beween Active Directory and POSIX. If the names are treated differently on NFS client and server, then NFS client and server cannot refer to the same user or group. The workarounds are all valid. If we should look into improving this for Scale, the best approach would be filing a RFE to request better handling of the usecase of using NFS with AD. Regards, Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZchristof.schm...@us.ibm.com || +1-520-799-2469 (T/L: 321-2469) - Original message -From: Andreas Mattsson <andreas.matts...@maxiv.lu.se>Sent by: gpfsug-discuss-boun...@spectrumscale.orgTo: gpfsug main discussion list <gpfsug-discuss@spectrumscale.org>Cc:Subject: Re: [gpfsug-discuss] Strange timestamp behaviour on NFS via CESDate: Thu, Sep 21, 2017 5:09 AM Since I solved this old issue a long time ago, I'd thought I'd come back and report the solution in case someone else encounters similar problems in the future. Original problem reported by users: Copying files between folders on NFS exports from a CES server gave random timestamps on the files. Also, apart from the initial reported problem, there where issues where users sometimes couldn't change or delete files that they where owners of. Background: We have a Active Directory with RFC2307 posix attributes populated, and use the built in Winbind-based AD authentication with RFC2307 ID mapping of our Spectrum Scale CES protocol servers. All our Linux clients and servers are also AD integrated, using Nslcd and nss-pam-ldapd. Trigger: If a user was part of a AD group with a mixed case name, and this group gave access to a folder, and the NFS mount was done using NFSv4, the behavior in my original post occurred when copying or changing files in that folder. Cause: Active Directory handle LDAP-requests case insensitive, but results are returned with case retained. Winbind and SSSD-AD converts groups and usernames to lower case. Nslcd retains case. We run NFS with managed GIDs. Managed GIDs in NFSv3 seems to be handled case insensitive, or to ignore the actual group name after it has resolved the GID-number of the group, while NFSv4 seems to handle group names case sensitive and check the actual group name for certain operations even if the GID-number matches. Don't fully understand the mechanism behind why certain file operations would work but others not, but in essence a user would be part of a group called "UserGroup" with GID-number 1234 in AD and on the client, but would be part of a group called "usergroup" with GID-number 1234 on the CES server. Any operation that's authorized on the GID-number, or a case insensitive lookup of the group name, would work. Any operation authorized by a case sensitive group lookup would fail. Three different workarounds where found to work: 1. Rename groups and users to lower case in AD 2. Change from Nslcd to either SSSD or Winbind on the clients 3. Change from NFSv4 to NFSv3 when mounting NFS Remember to clear ID-mapping caches. Regards, Andreas ___Andreas MattssonSystem EngineerMAX IV LaboratoryLund UniversityTel: +46-706-649544E-mail: andreas.matts...@maxlab.lu.se Från: gpfsug-discuss-boun...@spectrumscale.org <gpfsug-discuss-boun...@spectrumscale.org> för Stephen Ulmer <ul...@ulmer.org>Skickat: den 3 februari 2017 14:35:21Till: gpfsug main discussion listÄmne: Re: [gpfsug-discuss] Strange timestamp behaviour on NFS via CES Does the cp actually complete? As in, does it copy all of the blocks? What’s the exit code? A cp’d file should have “new” metadata. That is, it should have it’s own dates, owners, etc. (not necessaril
Re: [gpfsug-discuss] Strange timestamp behaviour on NFS via CES
The problem here is a combination of a few things: 1) As mentioned below, user and group names in Active Directory are case-insensitive and case-preserving. 2) POSIX user and group names on the other hand are case-insensitive and case-preserving. winbindd handles this case by always converting names to lower-case, which also provides a consistent view through the POSIX interfaces. Otherwise there could be side-effects when different versions are used to access the same group (e.g. group1 and Group1). 3) NFSv4 uses user and group names over the wire. I might be missing details, and there are also setups where uids and gids are used. The basic problem is the mismatch beween Active Directory and POSIX. If the names are treated differently on NFS client and server, then NFS client and server cannot refer to the same user or group. The workarounds are all valid. If we should look into improving this for Scale, the best approach would be filing a RFE to request better handling of the usecase of using NFS with AD. Regards, Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZchristof.schm...@us.ibm.com || +1-520-799-2469 (T/L: 321-2469) - Original message -From: Andreas Mattsson <andreas.matts...@maxiv.lu.se>Sent by: gpfsug-discuss-boun...@spectrumscale.orgTo: gpfsug main discussion list <gpfsug-discuss@spectrumscale.org>Cc:Subject: Re: [gpfsug-discuss] Strange timestamp behaviour on NFS via CESDate: Thu, Sep 21, 2017 5:09 AM Since I solved this old issue a long time ago, I'd thought I'd come back and report the solution in case someone else encounters similar problems in the future. Original problem reported by users: Copying files between folders on NFS exports from a CES server gave random timestamps on the files. Also, apart from the initial reported problem, there where issues where users sometimes couldn't change or delete files that they where owners of. Background: We have a Active Directory with RFC2307 posix attributes populated, and use the built in Winbind-based AD authentication with RFC2307 ID mapping of our Spectrum Scale CES protocol servers. All our Linux clients and servers are also AD integrated, using Nslcd and nss-pam-ldapd. Trigger: If a user was part of a AD group with a mixed case name, and this group gave access to a folder, and the NFS mount was done using NFSv4, the behavior in my original post occurred when copying or changing files in that folder. Cause: Active Directory handle LDAP-requests case insensitive, but results are returned with case retained. Winbind and SSSD-AD converts groups and usernames to lower case. Nslcd retains case. We run NFS with managed GIDs. Managed GIDs in NFSv3 seems to be handled case insensitive, or to ignore the actual group name after it has resolved the GID-number of the group, while NFSv4 seems to handle group names case sensitive and check the actual group name for certain operations even if the GID-number matches. Don't fully understand the mechanism behind why certain file operations would work but others not, but in essence a user would be part of a group called "UserGroup" with GID-number 1234 in AD and on the client, but would be part of a group called "usergroup" with GID-number 1234 on the CES server. Any operation that's authorized on the GID-number, or a case insensitive lookup of the group name, would work. Any operation authorized by a case sensitive group lookup would fail. Three different workarounds where found to work: 1. Rename groups and users to lower case in AD 2. Change from Nslcd to either SSSD or Winbind on the clients 3. Change from NFSv4 to NFSv3 when mounting NFS Remember to clear ID-mapping caches. Regards, Andreas ___Andreas MattssonSystem EngineerMAX IV LaboratoryLund UniversityTel: +46-706-649544E-mail: andreas.matts...@maxlab.lu.se Från: gpfsug-discuss-boun...@spectrumscale.org <gpfsug-discuss-boun...@spectrumscale.org> för Stephen Ulmer <ul...@ulmer.org>Skickat: den 3 februari 2017 14:35:21Till: gpfsug main discussion listÄmne: Re: [gpfsug-discuss] Strange timestamp behaviour on NFS via CES Does the cp actually complete? As in, does it copy all of the blocks? What’s the exit code? A cp’d file should have “new” metadata. That is, it should have it’s own dates, owners, etc. (not necessarily copied from the source file). I ran ‘strace cp foo1 foo2’, and it was pretty instructive, maybe that would get you more info. On CentOS strace is in it’s own package, YMMV. -- Stephen On Feb 3, 2017, at 8:19 AM, Andreas Mattsson <andreas.matts...@maxiv.lu.se> wrote: That works. ’touch test100’ Feb 3 14:16 test100 ‘cp test100 test101’ Feb 3 14:16 test100 Apr 21 2027 test101 ‘touch –r test100 test101’ Feb 3 14:16 test100 Feb 3 14:16 test101 /Andreas That’s a cool one. :) What if you use the "random date" file as a time reference to touch another fi
Re: [gpfsug-discuss] SMB2 leases - oplocks - growing files
From the quoted config file, i would assume that this is a Samba version that has been installed from another source. I have not seen this exact problem. If it can be recreated, then it might be useful to collect a trace and contact the supplier of the installed Samba for support. Note that Spectrum Scale since 4.1.1 includes protocols support which includes Samba. If that is used, then any problems with the Spectrum Scale provided Samba can be addressed through Spectrum Scale support. (As a sidenote to the noted problem, SMB2 leases are currently not supported with Samba in Spectrum Scale). Regards, Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZchristof.schm...@us.ibm.com || +1-520-799-2469 (T/L: 321-2469) - Original message -From: Bart Van Damme <bart.vanda...@sdnsquare.com>Sent by: gpfsug-discuss-boun...@spectrumscale.orgTo: gpfsug-discuss@spectrumscale.orgCc:Subject: [gpfsug-discuss] SMB2 leases - oplocks - growing filesDate: Fri, Sep 1, 2017 2:31 AM We are a company located in Belgium that mainly implements spectrum scale clusters in the Media and broadcasting industry. Currently we have a customer who wants to export the scale file system over samba 4.5 and 4.6. In these versions the SMB2 leases are activated by default for enhancing the oplocks system. The problem is when this option is not disabled Adobe (and probably Windows) is not notified the size of the file have changed, resulting that reading growing file in Adobe is not working, the timeline is not updated. Does anybody had this issues before and know how to solve it. This is the smb.conf file: # Global options smb2 leases = yes client use spnego = yes clustering = yes unix extensions = no mangled names = no ea support = yes store dos attributes = yes map readonly = no map archive = yes map system = no force unknown acl user = yes obey pam restrictions = no deadtime = 480 disable netbios = yes server signing = disabled server min protocol = SMB2 smb encrypt = off # We do not allow guest usage. guest ok = no guest account = nobody map to guest = bad user # disable printing load printers = no printing = bsd printcap name = /dev/null disable spoolss = yes # log settings log file = /var/log/samba/log.%m # max 500KB per log file, then rotate max log size = 500 log level = 1 passdb:1 auth:1 winbind:1 idmap:1 # Share Definitions [pfs] comment = GPFS path = /gpfs/pfs valid users = @ug_numpr writeable = yes inherit permissions = yes create mask = 664 force create mode = 664 nfs4:chown = yes nfs4:acedup = merge nfs4:mode = special fileid:algorithm = fsname vfs objects = shadow_copy2 gpfs fileid full_audit full_audit:prefix = %u|%I|%m|%S full_audit:success = rename unlink rmdir full_audit:failure = none full_audit:facility = local6 full_audit:priority = NOTICE shadow:fixinodes = yes gpfs:sharemodes = yes gpfs:winattr = yes gpfs:leases = no locking = yes posix locking = yes oplocks = yes kernel oplocks = no Grtz, Bart Bart Van Damme Customer Project ManagerSDNsquare Technologiepark 3, 9052 Zwijnaarde, Belgium www.sdnsquare.com T: + 32 9 241 56 01 M: + 32 496 59 23 09 This email is confidential in that it is intended for the exclusive attention of the addressee(s) indicated. If you are not the intended recipient, this email should not be read or disclosed
Re: [gpfsug-discuss] Spectrum Scale CES adds only Domain Admin tolocal
willi.eng...@id.ethz.ch wrote on 03/31/2017 04:46:02 AM: > Hi Christoph, > This solved my issues in most areas. > Now I will probably add our Storage Management Group to local > Administrators group, this way we are able to use all strong > utilities like subinacl etc, and will be able to migrate to Spectrum > Scale using robocopy with /ZB option working properly. > For our Share-responsible Administrator we probably will add their > Management user to the 'admin Users' option of the specific share > allowing them to do wat ever they need to do, knowing that some > tools may work with limitations. > > Do you know if we may also add a builtin group named BackupOperators? Privileges are not supported in Spectrum Scale: https://www.ibm.com/support/knowledgecenter/en/STXKQY_4.2.2/com.ibm.spectrum.scale.v4r22.doc/bl1adm_fileauthlimitations.htm "Access privileges defined in Windows are not honored. Those privileges are tied to administrator groups and allow access, where the ACL alone does not grant it." You can create a group and assign the BackupOperator privilege: /usr/lpp/mmfs/bin/net sam createbuiltingroup 'Backup Operators' /usr/lpp/mmfs/bin/net sam rights grant 'Backup Operators' SeBackupPrivilege Without looking at all the details, i would suspect that this does not work. Access for a member of this group would overwrite the internal access check in Samba, but i would expect that it would fail as the file system also enforces the permissions defined in the ACL, and these are not overwritten by the additional privilege. The current workaround is the 'admin users' option. You might want to raise a RFE to request better support of the Backup privilege and the "Backup Operators" group. Regards, Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZ christof.schm...@us.ibm.com || +1-520-799-2469(T/L: 321-2469) ___ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
Re: [gpfsug-discuss] Spectrum Scale CES adds only Domain Admin to local Administrators group
willi.eng...@id.ethz.ch wrote on 03/30/2017 07:23:40 AM: > >-Last time I checked simply adding a normal computer object to the domain > didn't add the account of the adding user to the local administrators group > and CES is no exception. > > We have been using before a competitor Product as a NAS system. With that > system, we were able to define virtual NAS Servers, each one joined as an > independent object to AD. When joined, we found the 'Domain Admin' group and > the joining user as member of local administrators group of that virtual > server. > Since out AD is quite big, it is structured into many OU. We as the Storage > OU have OU admin rights, but we are not member of "Domain Admin" group. > Looking Back, we were able by ourselves to add the required groups as needed > to the local Administrators group of the NAS server. > Why is this important? Since we have quit a mix of OS accessing our shares, > some of the create exclusive access rights at the time they create profiles > etc. At the end of the lifecycle, one needs to delete those files via the > SMB / NFSV4 protocol, which is difficult if not having access rights. On the > other hand, we have seen situations, where one OS corrupted the ACL and > could not access anymore. Also this needs to be handled by us, giving us a > hard time not being member of the administrators group. I.e. the MS tool > subinacl does check the privileges before trying to modify ACLs, and if not > being member of the Administrators group, not all required privileges are > granted. There is two parts to that in Spectrum Scale: 1) There is an option to declare a user as 'admin users'. The notion there is that this user is mapped to root on access, thus this user can always access files and fix access issues. The user defined here should not be used for normal usage, this is only recommended for data migrations and to fix access issues. 2) When joining Spectrum Scale to an Active Directory domain, the Domain Admins groups is added to the internal Administrators group (sometimes referred to as BUILTIN\Administrators). One way to change the membership in that group would be through the MMC on a Windows client. Initially only Domain Admins are allowed, a member of this group would be required to add other users or groups. Alternatively, the "net sam" interface can be used to modify the group from root access on the protocol nodes: /usr/lpp/mmfs/bin/net sam listmem Administrators to list the members of the Administrators groups. /usr/lpp/mmfs/bin/net sam addmem Administrators DOMAIN\user to add a member. /usr/lpp/mmfs/bin/net sam delmem Administrators DOMAIN\user to remove a member This is currently an untested feature and not exposed through the CLI. If there is a need to have this exposed through the CLI or GUI, that should be requested through a RFE so that it can feed into the planning and prioritization for future releases. Regards, Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZ christof.schm...@us.ibm.com || +1-520-799-2469(T/L: 321-2469) ___ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
Re: [gpfsug-discuss] Configuration spectrum scale to use SFU schema
gpfsug-discuss-boun...@spectrumscale.org wrote on 03/21/2017 03:56:41 AM: > Is it possible to configure authentication services to bind to AD using > the older SFU schema for ID mappings? We have standard samba and nfs > servers that use this ID mapping scheme with "idmap config > DS:schema_mode = sfu" in the samba configuration files, but if its > possible using the mmuserauth command it doesn't seem to be documented. This falls into the category that we use Samba to provide these services, but cannot test and support every possible configuration. The feature to read the old MS style id attributes has not been tested with Spectrum Scale and is not supported. That said, it can still be set in the internal config: /usr/lpp/mmfs/bin/net conf setparm global 'idmap config DS:schema_mode' sfu Activating this change probably would require a restart of the process using this config: /usr/lpp/mmfs/bin/mmdsh -N CesNodes systemctl restart gpfs-winbind Opening a PMR on this will likely result in the answer that this is unsupported. The best way to request official support would be opening a RFE, let others vote and then product management can decide on the priority of the request. Regards, Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZ christof.schm...@us.ibm.com || +1-520-799-2469(T/L: 321-2469) ___ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
Re: [gpfsug-discuss] SMB and AD authentication
--unixmap-domains 'sirius(1-2)' specifies that for the domain SIRIUS, all uid and gids are stored as rfc2307 attributes in the user and group objects in AD. If "id Sirius\\administrator" does not work, that might already point to missing data in AD. The requirement is that the user has a uidNumber defined, and the user's primary group in AD has to have a gidNumber defined. Note that a gidNumber defined for the user is not read by Spectrum Scale at this point. All uidNumber and gidNumber attributes have to fall in the defined range (1-2). If verifying the above points does not help, then a winbindd trace might help to point to the missing step: /usr/lpp/mmfs/bin/smbcontrol winbindd debug 10 id Sirius\\administrator /usr/lpp/mmfs/bin/smbcontrol winbindd debug 1 /var/adm/ras/log.winbindd-idmap is the log file for the idmap queries; it might show a failing ldap query in this case. Regards, Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZ christof.schm...@us.ibm.com || +1-520-799-2469(T/L: 321-2469) From: "mark.b...@siriuscom.com" <mark.b...@siriuscom.com> To: gpfsug main discussion list <gpfsug-discuss@spectrumscale.org> Date: 02/27/2017 12:41 PM Subject:[gpfsug-discuss] SMB and AD authentication Sent by:gpfsug-discuss-boun...@spectrumscale.org For some reason, I just can’t seem to get this to work. I have configured my protocol nodes to authenticate to AD using the following mmuserauth service create --type ad --data-access-method file --servers 192.168.88.3 --user-name administrator --netbios-name scale --idmap-role master --password * --idmap-range-size 100 --idmap-range 1000-2 --enable-nfs-kerberos --unixmap-domains 'sirius(1-2)' All goes well, I see the nodes in AD and all of the wbinfo commands show good (id Sirius\\administrator doesn’t work though), but when I try to mount an SMB share (after doing all the necessary mmsmb export stuff) I get permission denied. I’m curious if I missed a step (followed the docs pretty much to the letter). I’m trying Administrator, mark.bush, and a dummy aduser I created. None seem to gain access to the share. Protocol gurus help! Any ideas are appreciated. Mark R. Bush| Storage Architect Mobile: 210-237-8415 Twitter: @bushmr | LinkedIn: /markreedbush 10100 Reunion Place, Suite 500, San Antonio, TX 78216 www.siriuscom.com |mark.b...@siriuscom.com This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, privileged, confidential, and exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. This message may be viewed by parties at Sirius Computer Solutions other than those named in the message header. This message does not contain an official representation of Sirius Computer Solutions. If you have received this communication in error, notify Sirius Computer Solutions immediately and (i) destroy this message if a facsimile or (ii) delete this message immediately if this is an electronic communication. Thank you. Sirius Computer Solutions ___ 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
Re: [gpfsug-discuss] CES log files
A winbindd process taking up 100% could be caused by the problem documented in https://bugzilla.samba.org/show_bug.cgi?id=12105 Capturing a brief strace of the affected process and reporting that through a PMR would be helpful to debug this problem and provide a fix. To answer the wider question: Log files are kept in /var/adm/ras/. In case more detailed traces are required, use the mmprotocoltrace command. Regards, Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZ christof.schm...@us.ibm.com || +1-520-799-2469(T/L: 321-2469) From: "Sobey, Richard A" <r.so...@imperial.ac.uk> To: gpfsug main discussion list <gpfsug-discuss@spectrumscale.org> Date: 01/11/2017 07:00 AM Subject:Re: [gpfsug-discuss] CES log files Sent by:gpfsug-discuss-boun...@spectrumscale.org Thanks. Some of the node would just say “failed” or “degraded” with the DCs offline. Of those that thought they were happy to host a CES IP address, they did not respond and winbindd process would take up 100% CPU as seen through top with no users on it. Interesting that even though all CES nodes had the same configuration, three of them never had a problem at all. JF – I’ll look at the protocol tracing next time this happens. It’s a rare thing that three DCs go offline at once but even so there should have been enough resiliency to cope. Thanks Richard From: gpfsug-discuss-boun...@spectrumscale.org [ mailto:gpfsug-discuss-boun...@spectrumscale.org] On Behalf Of Andrew Beattie Sent: 11 January 2017 09:55 To: gpfsug-discuss@spectrumscale.org Cc: gpfsug-discuss@spectrumscale.org Subject: Re: [gpfsug-discuss] CES log files mmhealth might be a good place to start CES should probably throw a message along the lines of the following: mmhealth shows something is wrong with AD server: ... CES DEGRADED ads_down ... Andrew Beattie Software Defined Storage - IT Specialist Phone: 614-2133-7927 E-mail: abeat...@au1.ibm.com - Original message - From: "Sobey, Richard A" <r.so...@imperial.ac.uk> Sent by: gpfsug-discuss-boun...@spectrumscale.org To: "'gpfsug-discuss@spectrumscale.org'" <gpfsug-discuss@spectrumscale.org > Cc: Subject: [gpfsug-discuss] CES log files Date: Wed, Jan 11, 2017 7:27 PM Which files do I need to look in to determine what’s happening with CES… supposing for example a load of domain controllers were shut down and CES had no clue how to handle this and stopped working until the DCs were switched back on again. Mmfs.log.latest said everything was fine btw. Thanks Richard ___ 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 ___ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
Re: [gpfsug-discuss] Samba via CES
The client has to reconnect, open the file again and reissue request that have not been completed. Without persistent handles, the main risk is that another client can step in and access the same file in the meantime. With persistent handles, access from other clients would be prevented for a defined amount of time. Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZ christof.schm...@us.ibm.com || +1-520-799-2469(T/L: 321-2469) From: Lukas Hejtmanek <xhejt...@ics.muni.cz> To: gpfsug main discussion list <gpfsug-discuss@spectrumscale.org> Date: 09/27/2016 02:43 PM Subject:Re: [gpfsug-discuss] Samba via CES Sent by:gpfsug-discuss-boun...@spectrumscale.org On Tue, Sep 27, 2016 at 02:36:37PM -0700, Christof Schmitt wrote: > When a CES node fails, protocol clients have to reconnect to one of the > remaining nodes. > > Samba in CES does not support persistent handles. This is indicated in the > documentation: > > http://www.ibm.com/support/knowledgecenter/en/STXKQY_4.2.1/com.ibm.spectrum.scale.v4r21.doc/bl1adm_smbexportlimits.htm#bl1adm_smbexportlimits > > "Only mandatory SMB3 protocol features are supported. " well, but in this case, HA feature is a bit pointless as node fail results in a client failure as well as reconnect does not seem to be automatic if there is on going traffic.. more precisely reconnect is automatic but without persistent handles, the client receives write protect error immediately. -- Lukáš Hejtmánek ___ 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
Re: [gpfsug-discuss] Samba via CES
When a CES node fails, protocol clients have to reconnect to one of the remaining nodes. Samba in CES does not support persistent handles. This is indicated in the documentation: http://www.ibm.com/support/knowledgecenter/en/STXKQY_4.2.1/com.ibm.spectrum.scale.v4r21.doc/bl1adm_smbexportlimits.htm#bl1adm_smbexportlimits "Only mandatory SMB3 protocol features are supported. " Regards, Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZ christof.schm...@us.ibm.com || +1-520-799-2469(T/L: 321-2469) From: Lukas Hejtmanek <xhejt...@ics.muni.cz> To: gpfsug-discuss@spectrumscale.org Date: 09/27/2016 12:38 PM Subject:[gpfsug-discuss] Samba via CES Sent by:gpfsug-discuss-boun...@spectrumscale.org Hello, does CES offer high availability of SMB? I.e., does used samba server provide cluster wide persistent handles? Or failover from node to node is currently not supported without the client disruption? -- Lukáš Hejtmánek ___ 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
Re: [gpfsug-discuss] CES and mmuserauth command
After looking into this again, the source of confusion is probably from the fact that there are three different authentication schemes present here: When configuring a LDAP server for file or object authentication, then the specified server, user and password are used during normal operations for querying user data. The same applies for configuring object authentication with AD; AD is here treated as a LDAP server. Configuring AD for file authentication is different in that during the "mmuserauth service create", the machine account is created, and then that account is used to connect to a DC that is chosen from the DCs discovered through DNS and not necessarily the one used for the initial configuration. I submitted an internal request to explain this better in the mmuserauth manpage. Regards, Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZ christof.schm...@us.ibm.com || +1-520-799-2469(T/L: 321-2469) From: Christof Schmitt/Tucson/IBM@IBMUS To: gpfsug main discussion list <gpfsug-discuss@spectrumscale.org> Date: 08/26/2016 09:30 AM Subject:Re: [gpfsug-discuss] CES and mmuserauth command Sent by:gpfsug-discuss-boun...@spectrumscale.org The --user-name option applies to both, AD and LDAP authentication. In the LDAP case, this information is correct. I will try to get some clarification added for the AD case. The same applies to the information shown in "service list". There is a common field that holds the information and the parameter from the initial "service create" is stored there. The meaning is different for AD and LDAP: For LDAP it is the username being used to access the LDAP server, while in the AD case it was only the user initially used until the machine account was created. Regards, Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZ christof.schm...@us.ibm.com || +1-520-799-2469(T/L: 321-2469) From: Jan-Frode Myklebust <janfr...@tanso.net> To: gpfsug main discussion list <gpfsug-discuss@spectrumscale.org> Date: 08/26/2016 05:59 AM Subject:Re: [gpfsug-discuss] CES and mmuserauth command Sent by:gpfsug-discuss-boun...@spectrumscale.org On Fri, Aug 26, 2016 at 1:49 AM, Christof Schmitt < christof.schm...@us.ibm.com> wrote: When joinging the AD domain, --user-name, --password and --server are only used to initially identify and logon to the AD and to create the machine account for the cluster. Once that is done, that information is no longer used, and e.g. the account from --user-name could be deleted, the password changed or the specified DC could be removed from the domain (as long as other DCs are remaining). That was my initial understanding of the --user-name, but when reading the man-page I get the impression that it's also used to do connect to AD to do user and group lookups: -- ‐‐user‐name userName Specifies the user name to be used to perform operations against the authentication server. The specified user name must have sufficient permissions to read user and group attributes from the authentication server. --- Also it's strange that "mmuserauth service list" would list the USER_NAME if it was only somthing that was used at configuration time..? -jf___ 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 ___ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
Re: [gpfsug-discuss] Cannot stop SMB... stop NFS first?
That would be the case when Active Directory is configured for authentication. In that case the SMB service includes two aspects: One is the actual SMB file server, and the second one is the service for the Active Directory integration. Since NFS depends on authentication and id mapping services, it requires SMB to be running. Regards, Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZ christof.schm...@us.ibm.com || +1-520-799-2469(T/L: 321-2469) From: "Sobey, Richard A" <r.so...@imperial.ac.uk> To: "'gpfsug-discuss@spectrumscale.org'" <gpfsug-discuss@spectrumscale.org> Date: 08/26/2016 04:48 AM Subject:[gpfsug-discuss] Cannot stop SMB... stop NFS first? Sent by:gpfsug-discuss-boun...@spectrumscale.org Sorry all, prepare for a deluge of emails like this, hopefully it’ll help other people implementing CES in the future. I’m trying to stop SMB on a node, but getting the following output: [root@cesnode ~]# mmces service stop smb smb: Request denied. Please stop NFS first [root@cesnode ~]# mmces service list Enabled services: SMB SMB is running As you can see there is no way to stop NFS when it’s not running but it seems to be blocking me. It’s happening on all the nodes in the cluster. SS version is 4.2.0 running on a fully up to date RHEL 7.1 server. Richard___ 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
Re: [gpfsug-discuss] CES mmsmb options
The options listed in " mmsmb config change --key-info supported" are supported to be changed by administrator of the cluster. "mmsmb config list" lists the whole Samba config, including the options that are set internally. We do not want to support any random Samba configuration, hence the line between "supported" option and everything else. If there is a usecase that requires other Samba options than the ones listed as "supported", one way forward would be opening a RFE that describes the usecase and the Samba option to support it. Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZ christof.schm...@us.ibm.com || +1-520-799-2469(T/L: 321-2469) From: "Sobey, Richard A" <r.so...@imperial.ac.uk> To: "'gpfsug-discuss@spectrumscale.org'" <gpfsug-discuss@spectrumscale.org> Date: 08/22/2016 09:28 AM Subject:[gpfsug-discuss] CES mmsmb options Sent by:gpfsug-discuss-boun...@spectrumscale.org Related to my previous question in so far as it’s to do with CES, what’s this all about: [root@ces]# mmsmb config change --key-info supported Supported smb options with allowed values: gpfs:dfreequota= yes, no restrict anonymous = 0, 2 server string = any mmsmb config list shows many more options. Are they static… for example log size / location / dmapi support? I’m surely missing something obvious. It’s SS 4.2.0 btw. Thanks Richard___ 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
Re: [gpfsug-discuss] CES and mmuserauth command
To clarify and expand on some of these: --servers takes the AD Domain Controller that is contacted first during configuration. Later and during normal operations the list of DCs is retrieved from DNS and the fastest (or closest one according to the AD sites) is used. The initially one used does not have a special role. --idmap-role allows dedicating one cluster as a master, and a second cluster (e.g. a AFM replication target) as "subordinate". Only the master will allocate idmap ranges which can then be imported to the subordiate to have consistent id mappings. --idmap-range-size and --idmap-range are used for the internal idmap allocation which is used for every domain that is not explicitly using another domain. "man idmap_autorid" explains the approach taken. As long as the default does not overlap with any other ids, that can be used. The "netbios" name is used to create the machine account for the cluster when joining the AD domain. That is how the AD administrator will identify the CES cluster. It is also important in SMB deployments when Kerberos should be used with SMB: The same names as the netbios name has to be defined in DNS for the public CES IP addresses. When the name matches, then SMB clients can acquire a Kerberos ticket from AD to establish a SMB connection. When joinging the AD domain, --user-name, --password and --server are only used to initially identify and logon to the AD and to create the machine account for the cluster. Once that is done, that information is no longer used, and e.g. the account from --user-name could be deleted, the password changed or the specified DC could be removed from the domain (as long as other DCs are remaining). Regards, Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZ christof.schm...@us.ibm.com || +1-520-799-2469(T/L: 321-2469) From: Jan-Frode Myklebust <janfr...@tanso.net> To: gpfsug main discussion list <gpfsug-discuss@spectrumscale.org> Date: 08/23/2016 08:15 AM Subject:Re: [gpfsug-discuss] CES and mmuserauth command Sent by:gpfsug-discuss-boun...@spectrumscale.org Sorry to see no authoritative answers yet.. I'm doing lots of CES installations, but have not quite yet gotten the full understanding of this.. Simple stuff first: --servers You can only have one with AD. --enable-kerberos shouldn't be used, as that's only for LDAP according to the documentation. Guess kerberos is implied with AD. --idmap-role -- I've been using "master". Man-page says ID map role of a stand‐alone or singular system deployment must be selected "master" What the idmap options seems to be doing is configure the idmap options for Samba. Maybe best explained by: https://wiki.samba.org/index.php/Idmap_config_ad Your suggested options will then give you the samba idmap configuration: idmap config * : rangesize = 100 idmap config * : range = 300-350 idmap config * : read only = no idmap:cache = no idmap config * : backend = autorid idmap config DOMAIN : schema_mode = rfc2307 idmap config DOMAIN : range = 500-200 idmap config DOMAIN : backend = ad Most likely you want to replace DOMAIN by your AD domain name.. So the --idmap options sets some defaults, that you probably won't care about, since all your users are likely covered by the specific "idmap config DOMAIN" config. Hope this helps somewhat, now I'll follow up with something I'm wondering myself...: Is the netbios name just a name, without any connection to anything in AD? Is the --user-name/--password a one-time used account that's only necessary when executing the mmuserauth command, or will it also be for communication between CES and AD while the services are running? -jf On Mon, Aug 22, 2016 at 1:59 PM, Sobey, Richard A <r.so...@imperial.ac.uk> wrote: Hi all, We’re just about to start testing a new CES 4.2.0 cluster and at the stage of “joining” the cluster to our AD. What’s the bare minimum we need to get going with this? My Windows guy (who is more Linux but whatever) has suggested the following: mmuserauth service create --type ad --data-access-method file --netbios-name store --user-name USERNAME --password --enable-nfs-kerberos --enable-kerberos --servers list,of,servers --idmap-range-size 100 --idmap-range 300 - 350 --unixmap-domains 'DOMAIN(500 - 200)' He has also asked what the following is: --idmap-role ??? --idmap-range-size ?? All our LDAP GID/UIDs are coming from a system outside of GPFS so do we leave this blank, or say master Or, now I’ve re-read and mmuserauth page, is this purely for when you have AFM relationships and one GPFS cluster (the subordinate / the second cluster) gets its UIDs and GIDs from another GPFS cluster (the master / the first one)? For idmap-range-size is this essentially the highest number of users
Re: [gpfsug-discuss] Migrate 3.5 to 4.2 and LTFSEE toSpectrumArchive
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 100-900 --idmap-range-size 10 /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 = 100-900 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
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 SpectrumArchive 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
Re: [gpfsug-discuss] Snapshots / Windows previous versions
The first patch is at least in Samba 4.2 and newer. The patch to the
vfs_gpfs module is only in Samba 4.3 and newer. So any of these should fix
your problem:
- Add the vfs_gpfs patch to the source code of Samba 4.2.9 and recompile
the code.
- Upgrade to Sernet Samba 4.3.x or newer
- Change the Samba services to the ones provided through CES
Regards,
Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZ
christof.schm...@us.ibm.com || +1-520-799-2469(T/L: 321-2469)
From: "Sobey, Richard A" <r.so...@imperial.ac.uk>
To: gpfsug main discussion list <gpfsug-discuss@spectrumscale.org>
Date: 07/06/2016 07:54 AM
Subject:Re: [gpfsug-discuss] Snapshots / Windows previous versions
Sent by:gpfsug-discuss-boun...@spectrumscale.org
Cheers Christof. We're using Sernet Samba [4.2.9] so limited by what they
release. How can I identify which version of Samba is a) affect by the the
first link and b) which version has got the patch incorporated?
I'm not a developer as you can guess :)
-Original Message-
From: gpfsug-discuss-boun...@spectrumscale.org [
mailto:gpfsug-discuss-boun...@spectrumscale.org] On Behalf Of Christof
Schmitt
Sent: 06 July 2016 15:46
To: gpfsug main discussion list <gpfsug-discuss@spectrumscale.org>
Subject: Re: [gpfsug-discuss] Snapshots / Windows previous versions
The message in the trace confirms that this is triggered by:
https://git.samba.org/?p=samba.git;a=commitdiff;h=acbb4ddb6876c15543c5370e6d27faacebc8a231
I suspect that the Samba version used misses the patch
https://git.samba.org/?p=samba.git;a=commitdiff;h=fdbca5e13a0375d7f18639679a627e67c3df647a
The CES build of Samba shippied in Spectrum Scale includes the mentioned
patch, and that should avoid the problem seen. Would it be possible to
build Samba again with the mentioned patch to test whether that fixes the
issue seen here?
Regards,
Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZ
christof.schm...@us.ibm.com || +1-520-799-2469(T/L: 321-2469)
From: "Sobey, Richard A" <r.so...@imperial.ac.uk>
To: gpfsug main discussion list <gpfsug-discuss@spectrumscale.org>
Date: 07/06/2016 05:23 AM
Subject:Re: [gpfsug-discuss] Snapshots / Windows previous versions
Sent by:gpfsug-discuss-boun...@spectrumscale.org
Thanks Daniel – sorry to be dense, but does this indicate working as
intended, or a bug? I assume the former. So, the question still remains
how has this suddenly broken, when:
[root@server ict]# mmgetacl -k nfs4 .snapshots/
.snapshots/: Operation not permitted
…appears to be the correct output and is consistent with someone else’s
GPFS cluster where it is working.
Cheers
Richard
From: gpfsug-discuss-boun...@spectrumscale.org [
mailto:gpfsug-discuss-boun...@spectrumscale.org] On Behalf Of Daniel
Kidger
Sent: 06 July 2016 12:51
To: gpfsug-discuss@spectrumscale.org
Cc: gpfsug-discuss@spectrumscale.org
Subject: Re: [gpfsug-discuss] Snapshots / Windows previous versions
Looking at recent patches to SAMBA I see from December 2015:
https://download.samba.org/pub/samba/patches/security/samba-4.1.21-security-2015-12-16.patch
,
(link found at https://bugzilla.samba.org/show_bug.cgi?id=11658 which
includes the comment:
Failing that, smbd_check_access_rights should check Unix perms at that
point.
)
diff --git a/source3/modules/vfs_shadow_copy2.c
b/source3/modules/vfs_shadow_copy2.c
index fca05cf..07e2f8a 100644
--- a/source3/modules/vfs_shadow_copy2.c
+++ b/source3/modules/vfs_shadow_copy2.c
@@ -30,6 +30,7 @@
*/
#include "includes.h"
+#include "smbd/smbd.h"
#include "system/filesys.h"
#include "include/ntioctl.h"
#include
@@ -1138,6 +1139,42 @@ static char *have_snapdir(struct vfs_handle_struct
*handle,
return NULL;
}
+static bool check_access_snapdir(struct vfs_handle_struct *handle,
+const char *path)
+{
+struct smb_filename smb_fname;
+int ret;
+NTSTATUS status;
+
+ZERO_STRUCT(smb_fname);
+smb_fname.base_name = talloc_asprintf(talloc_tos(),
+"%s",
+path);
+if (smb_fname.base_name == NULL) {
+return false;
+}
+
+ret = SMB_VFS_NEXT_STAT(handle, _fname);
+if (ret != 0 || !S_ISDIR(smb_fname.st.st_ex_mode)) {
+TALLOC_FREE(smb_fname.base_name);
+return false;
+}
+
+status = smbd_check_access_rights(handle->conn,
+_fname,
+false,
+SEC_DIR_LIST);
+if (!NT_STATUS_IS_OK(status)) {
+DEBUG(0,("user does not have list permission "
+"on snapdir %s\n",
+smb_fname.base_name));
+TALLOC_FREE(smb_fname.base_name);
+return false;
+}
+TALLOC_FREE(smb_fname.base_name);
+return true;
+}
+
Daniel
Re: [gpfsug-discuss] Snapshots / Windows previous versions
The message in the trace confirms that this is triggered by:
https://git.samba.org/?p=samba.git;a=commitdiff;h=acbb4ddb6876c15543c5370e6d27faacebc8a231
I suspect that the Samba version used misses the patch
https://git.samba.org/?p=samba.git;a=commitdiff;h=fdbca5e13a0375d7f18639679a627e67c3df647a
The CES build of Samba shippied in Spectrum Scale includes the mentioned
patch, and that should avoid the problem seen. Would it be possible to
build Samba again with the mentioned patch to test whether that fixes the
issue seen here?
Regards,
Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZ
christof.schm...@us.ibm.com || +1-520-799-2469(T/L: 321-2469)
From: "Sobey, Richard A" <r.so...@imperial.ac.uk>
To: gpfsug main discussion list <gpfsug-discuss@spectrumscale.org>
Date: 07/06/2016 05:23 AM
Subject:Re: [gpfsug-discuss] Snapshots / Windows previous versions
Sent by:gpfsug-discuss-boun...@spectrumscale.org
Thanks Daniel – sorry to be dense, but does this indicate working as
intended, or a bug? I assume the former. So, the question still remains
how has this suddenly broken, when:
[root@server ict]# mmgetacl -k nfs4 .snapshots/
.snapshots/: Operation not permitted
…appears to be the correct output and is consistent with someone else’s
GPFS cluster where it is working.
Cheers
Richard
From: gpfsug-discuss-boun...@spectrumscale.org [
mailto:gpfsug-discuss-boun...@spectrumscale.org] On Behalf Of Daniel
Kidger
Sent: 06 July 2016 12:51
To: gpfsug-discuss@spectrumscale.org
Cc: gpfsug-discuss@spectrumscale.org
Subject: Re: [gpfsug-discuss] Snapshots / Windows previous versions
Looking at recent patches to SAMBA I see from December 2015:
https://download.samba.org/pub/samba/patches/security/samba-4.1.21-security-2015-12-16.patch
,
(link found at https://bugzilla.samba.org/show_bug.cgi?id=11658 which
includes the comment:
Failing that, smbd_check_access_rights should check Unix perms at that
point.
)
diff --git a/source3/modules/vfs_shadow_copy2.c
b/source3/modules/vfs_shadow_copy2.c
index fca05cf..07e2f8a 100644
--- a/source3/modules/vfs_shadow_copy2.c
+++ b/source3/modules/vfs_shadow_copy2.c
@@ -30,6 +30,7 @@
*/
#include "includes.h"
+#include "smbd/smbd.h"
#include "system/filesys.h"
#include "include/ntioctl.h"
#include
@@ -1138,6 +1139,42 @@ static char *have_snapdir(struct vfs_handle_struct
*handle,
return NULL;
}
+static bool check_access_snapdir(struct vfs_handle_struct *handle,
+const char *path)
+{
+struct smb_filename smb_fname;
+int ret;
+NTSTATUS status;
+
+ZERO_STRUCT(smb_fname);
+smb_fname.base_name = talloc_asprintf(talloc_tos(),
+"%s",
+path);
+if (smb_fname.base_name == NULL) {
+return false;
+}
+
+ret = SMB_VFS_NEXT_STAT(handle, _fname);
+if (ret != 0 || !S_ISDIR(smb_fname.st.st_ex_mode)) {
+TALLOC_FREE(smb_fname.base_name);
+return false;
+}
+
+status = smbd_check_access_rights(handle->conn,
+_fname,
+false,
+SEC_DIR_LIST);
+if (!NT_STATUS_IS_OK(status)) {
+DEBUG(0,("user does not have list permission "
+"on snapdir %s\n",
+smb_fname.base_name));
+TALLOC_FREE(smb_fname.base_name);
+return false;
+}
+TALLOC_FREE(smb_fname.base_name);
+return true;
+}
+
Daniel
Dr Daniel Kidger
IBM Technical Sales Specialist
Software Defined Solution Sales
+44-07818 522 266
daniel.kid...@uk.ibm.com
- Original message -
From: "Sobey, Richard A" <r.so...@imperial.ac.uk>
Sent by: gpfsug-discuss-boun...@spectrumscale.org
To: gpfsug main discussion list <gpfsug-discuss@spectrumscale.org>
Cc:
Subject: Re: [gpfsug-discuss] Snapshots / Windows previous versions
Date: Wed, Jul 6, 2016 10:55 AM
Sure. It might be easier if I just post the entire smb.conf:
[global]
netbios name = store
workgroup = IC
security = ads
realm = IC.AC.UK
kerberos method = secrets and keytab
vfs objects = shadow_copy2 syncops gpfs fileid
ea support = yes
store dos attributes = yes
map readonly = no
map archive = no
map system = no
map hidden = no
unix extensions = no
allocation roundup size = 1048576
disable netbios = yes
smb ports = 445
# server signing = mandatory
template shell = /bin/bash
interfaces = bond2 lo bond0
allow trusted domains = no
printing = bsd
printcap name = /dev/null
load printers = no
disable spoolss = yes
idmap config IC : default = yes
idmap config IC : cache time = 180
idmap config IC : backend = ad
idmap config IC : schema_mode = rfc2307
idmap config IC : range = 500 - 200
idmap config * : range = 300 - 350
idmap c
Re: [gpfsug-discuss] Integration with Active Directory
Generally, i would advise against changing the global logging config. That change is easily picked up by other related processes, and then causes unwanted overhead. Today, the best way to change the logging for the AD integration would be to enable it in the running winbindd processes without changing the config:mmdsh -N CesNodes /usr/lpp/mmfs/bin/smbcontrol winbindd debug 3mmdsh -N CesNodes /usr/lpp/mmfs/bin/smbcontrol winbindd debug 1For DNS servers, the requirement would be that all configured DNS servers on the protocol nodes, return the additional information required to locate the AD Domain Controllers. If the AD DCs are also running the DNS server, then only the AD DCs should be configured as DNS servers on the protocol nodes. One thing to check: After the configuring the AD authentication through mmuserauth, this command should return the list of AD DCs (check on all protocol nodes):dig -t SRV _kerberos._tcp.$(/usr/lpp/mmfs/bin/net conf getparm global realm)Regards,Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZchristof.schm...@us.ibm.com || +1-520-799-2469 (T/L: 321-2469)-gpfsug-discuss-boun...@spectrumscale.org wrote: -To: gpfsug main discussion list <gpfsug-discuss@spectrumscale.org>From: Monty Poppe/Austin/IBM@IBMUSSent by: gpfsug-discuss-boun...@spectrumscale.orgDate: 02/25/2016 10:02AMSubject: Re: [gpfsug-discuss] Integration with Active DirectoryAll CES nodes should operate consistently across the cluster. Here are a few tips on debugging:/usr/lpp/mmfs/bin/wbinfo-p to ensure winbind is running properly/usr/lpp/mmfs/bin/wbinfo-P (capital P), to ensure winbind can communicate with AD serverensure the first nameserver in /etc/resolv.conf points to your AD server (check all nodes)mmuserauth service check --server-reachability for a more thorough validation that all nodes can communicate to the authentication serverIf you need to look at samba logs (/var/adm/ras/log.smbd & log.wb-) to see what's going on, change samba log levels issue: /usr/lpp/mmfs/bin/net conf setparm global 'log level' 3. Don't forget to set back to 0 or 1 when you are done!If you're willing to go with a later release, AD authentication with LDAP ID mapping has been added as a feature in the 4.2 release. (https://www-01.ibm.com/support/knowledgecenter/STXKQY_4.2.0/com.ibm.spectrum.scale.v4r2.adm.doc/bl1adm_adwithldap.htm?lang=en)Monty PoppeSpectrum Scale Testpo...@us.ibm.com512-286-8047 T/L 363-8047From: "Simon Thompson (Research Computing - IT Services)" <s.j.thomp...@bham.ac.uk>To: gpfsug main discussion list <gpfsug-discuss@spectrumscale.org>Date: 02/25/2016 07:19 AMSubject: Re: [gpfsug-discuss] Integration with Active DirectorySent by: gpfsug-discuss-boun...@spectrumscale.orgHi Gethyn,From what I recall, CTDB used underneath is used to share the secret and only the primary named machine is joined, but CTDB and CES should work this backend part out for you.I do have a question though, do you want to have consistent UIDs across other systems? For example if you plan to use NFS to other *nix systems, then you probably want to think about LDAP mapping and using custom auth (we do this as out AD doesn't contain UIDs either).SimonFrom: <gpfsug-discuss-boun...@spectrumscale.org> on behalf of "Longworth, Gethyn" <gethyn.longwo...@rolls-royce.com>Reply-To: "gpfsug-discuss@spectrumscale.org" <gpfsug-discuss@spectrumscale.org>Date: Thursday, 25 February 2016 at 10:42To: "gpfsug-discuss@spectrumscale.org" <gpfsug-discuss@spectrumscale.org>Subject: [gpfsug-discuss] Integration with Active DirectoryHi all, I’m new to both GPFS and to this mailing list, so I thought I’d introduce myself and one of the issues I am having. I am a consultant to Rolls-Royce Aerospace currently working on a large facilities project, part of my remit is to deliver a data system. We selected GPFS (sorry Spectrum Scale…) for this three clusters, with two of the clusters using storage provided by Spectrum Accelerate, and the other by a pair of IBM SANs and a tape library back up. My current issue is to do with integration into Active Directory. I’ve configured my three node test cluster with two protocol nodes and a quorum (version 4.2.0.1 on RHEL 7.1) as the master for an automated id mapping system (we can’t use RFC2307, as our IT department don’t understand what this is), but the problem I’m having is to do with domain joins. The documentation suggests that using the CES cluster hostname to register in the domain will allow all nodes in the cluster to share the identity mapping, but only one of my protocol nodes will authenticate – I can run “id” on that node with a domain account and it provides the correct answer – whereas the other will not and denies any knowledge of the domain or user. From a GPFS point of view, this results in a degraded CES, SMB, NFS and AUTH state. My small amount of AD knowl
