[gpfsug-discuss] Cannot stop SMB... stop NFS first?
Laurence Horrors-Barlow
laurence at qsplace.co.uk
Fri Sep 2 18:54:02 BST 2016
I believe the services auto restart on a crash (or kill), a change I noticed between 4.1.1 and 4.2 hence no IP fail over.
Suspending a node to force a fail over is possible the most sensible approach.
-- Lauz
Sent from my iPad
> On 2 Sep 2016, at 18:02, Stephen Ulmer <ulmer at ulmer.org> wrote:
>
> I think that stopping SMB is an explicitly different assertion than suspending the node, et cetera. When you ask the service to stop, it should stop -- not start a game of whack-a-mole.
>
> If you wanted to move the service there are other other ways. If it fails, clearly it the IP address should move.
>
> Liberty,
>
> --
> Stephen
>
>
>
>> On Sep 2, 2016, at 11:23 AM, Sobey, Richard A <r.sobey at imperial.ac.uk> wrote:
>>
>> A fair point, but since we're not running NFS, a failure of the only other service [SMB], whether it stops through user input or some other means, should cause the node to go unhealthy (in CTDB parlance) and trigger a failover. That would be my preference.
>>
>> Otoh if you were running NFS and SMB and one of those services crashed, do you still want a node in the cluster that could potentially respond and fails to do so? I guess it's a question for each organisation to answer themselves.
>>
>> -----Original Message-----
>> From: gpfsug-discuss-bounces at spectrumscale.org [mailto:gpfsug-discuss-bounces at spectrumscale.org] On Behalf Of Simon Thompson (Research Computing - IT Services)
>> Sent: 02 September 2016 16:16
>> To: gpfsug main discussion list <gpfsug-discuss at spectrumscale.org>
>> Subject: Re: [gpfsug-discuss] Cannot stop SMB... stop NFS first?
>>
>>
>> Should it?
>>
>> If you were running nfs and smb, would you necessarily want to fail the ip over?
>>
>> Simon
>> ________________________________________
>> From: gpfsug-discuss-bounces at spectrumscale.org [gpfsug-discuss-bounces at spectrumscale.org] on behalf of Sobey, Richard A [r.sobey at imperial.ac.uk]
>> Sent: 02 September 2016 16:10
>> To: gpfsug main discussion list
>> Subject: Re: [gpfsug-discuss] Cannot stop SMB... stop NFS first?
>>
>> I've verified the upgrade has fixed this issue so thanks again.
>>
>> However I've noticed that stopping SMB doesn't trigger an IP address failover. I think it should. mmces node suspend (or rebooting, or mmces address move, or etc..) seems to trigger the failover.
>>
>> Richard
>>
>> From: gpfsug-discuss-bounces at spectrumscale.org [mailto:gpfsug-discuss-bounces at spectrumscale.org] On Behalf Of Danny Alexander Calderon Rodriguez
>> Sent: 27 August 2016 13:53
>> To: gpfsug-discuss at spectrumscale.org
>> Subject: Re: [gpfsug-discuss] Cannot stop SMB... stop NFS first?
>>
>> Hi Richard
>>
>> This is fixed in release 4.2.1, if you cant upgrade now, you can fix this manuallly
>>
>>
>> Just do this.
>>
>> edit file /usr/lpp/mmfs/lib/mmcesmon/SMBService.py
>>
>>
>>
>> Change
>>
>> if authType == 'ad' and not nodeState.nfsStopped:
>>
>> to
>>
>>
>>
>> nfsEnabled = utils.isProtocolEnabled("NFS", self.logger)
>> if authType == 'ad' and not nodeState.nfsStopped and nfsEnabled:
>>
>>
>> You need to stop the gpfs service in each node where you apply the change
>>
>>
>> " after change the lines please use tap key"
>>
>>
>>
>> Enviado desde mi iPhone
>>
>> El 27/08/2016, a las 6:00 a.m., gpfsug-discuss-request at spectrumscale.org<mailto:gpfsug-discuss-request at spectrumscale.org> escribió:
>> Send gpfsug-discuss mailing list submissions to
>> gpfsug-discuss at spectrumscale.org<mailto:gpfsug-discuss at spectrumscale.org>
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> http://gpfsug.org/mailman/listinfo/gpfsug-discuss
>> or, via email, send a message with subject or body 'help' to
>> gpfsug-discuss-request at spectrumscale.org<mailto:gpfsug-discuss-request at spectrumscale.org>
>>
>> You can reach the person managing the list at
>> gpfsug-discuss-owner at spectrumscale.org<mailto:gpfsug-discuss-owner at spectrumscale.org>
>>
>> When replying, please edit your Subject line so it is more specific than "Re: Contents of gpfsug-discuss digest..."
>>
>>
>> Today's Topics:
>>
>> 1. Re: Cannot stop SMB... stop NFS first?(Christof Schmitt)
>> 2. Re: CES and mmuserauth command (Christof Schmitt)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Fri, 26 Aug 2016 12:29:31 -0400
>> From: "Christof Schmitt" <christof.schmitt at us.ibm.com<mailto:christof.schmitt at us.ibm.com>>
>> To: gpfsug main discussion list <gpfsug-discuss at spectrumscale.org<mailto:gpfsug-discuss at spectrumscale.org>>
>> Subject: Re: [gpfsug-discuss] Cannot stop SMB... stop NFS first?
>> Message-ID:
>> <OF5D32DCFD.74622168-ON8525801B.0057526F-8525801B.005A97BD at notes.na.collabserv.com<mailto:OF5D32DCFD.74622168-ON8525801B.0057526F-8525801B.005A97BD at notes.na.collabserv.com>>
>>
>> Content-Type: text/plain; charset="UTF-8"
>>
>> 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.schmitt at us.ibm.com<mailto:christof.schmitt at us.ibm.com> || +1-520-799-2469 (T/L: 321-2469)
>>
>>
>>
>> From: "Sobey, Richard A" <r.sobey at imperial.ac.uk<mailto:r.sobey at imperial.ac.uk>>
>> To: "'gpfsug-discuss at spectrumscale.org<mailto:gpfsug-discuss at spectrumscale.org>'"
>> <gpfsug-discuss at spectrumscale.org<mailto:gpfsug-discuss at spectrumscale.org>>
>> Date: 08/26/2016 04:48 AM
>> Subject: [gpfsug-discuss] Cannot stop SMB... stop NFS first?
>> Sent by: gpfsug-discuss-bounces at spectrumscale.org<mailto:gpfsug-discuss-bounces at 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 at cesnode ~]# mmces service stop smb
>> smb: Request denied. Please stop NFS first
>>
>> [root at 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://spectrumscale.org>
>> http://gpfsug.org/mailman/listinfo/gpfsug-discuss
>>
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Fri, 26 Aug 2016 12:29:31 -0400
>> From: "Christof Schmitt" <christof.schmitt at us.ibm.com<mailto:christof.schmitt at us.ibm.com>>
>> To: gpfsug main discussion list <gpfsug-discuss at spectrumscale.org<mailto:gpfsug-discuss at spectrumscale.org>>
>> Subject: Re: [gpfsug-discuss] CES and mmuserauth command
>> Message-ID:
>> <OF96C5E3D5.D7802E36-ON8525801B.0057FD62-8525801B.005A980C at notes.na.collabserv.com<mailto:OF96C5E3D5.D7802E36-ON8525801B.0057FD62-8525801B.005A980C at notes.na.collabserv.com>>
>>
>> Content-Type: text/plain; charset="ISO-2022-JP"
>>
>> 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.schmitt at us.ibm.com<mailto:christof.schmitt at us.ibm.com> || +1-520-799-2469 (T/L: 321-2469)
>>
>>
>>
>> From: Jan-Frode Myklebust <janfrode at tanso.net<mailto:janfrode at tanso.net>>
>> To: gpfsug main discussion list <gpfsug-discuss at spectrumscale.org<mailto:gpfsug-discuss at spectrumscale.org>>
>> Date: 08/26/2016 05:59 AM
>> Subject: Re: [gpfsug-discuss] CES and mmuserauth command
>> Sent by: gpfsug-discuss-bounces at spectrumscale.org<mailto:gpfsug-discuss-bounces at spectrumscale.org>
>>
>>
>>
>>
>> On Fri, Aug 26, 2016 at 1:49 AM, Christof Schmitt < christof.schmitt at us.ibm.com<mailto:christof.schmitt at 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://spectrumscale.org>
>> http://gpfsug.org/mailman/listinfo/gpfsug-discuss
>>
>>
>>
>>
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> gpfsug-discuss mailing list
>> gpfsug-discuss at spectrumscale.org<http://spectrumscale.org>
>> http://gpfsug.org/mailman/listinfo/gpfsug-discuss
>>
>>
>> End of gpfsug-discuss Digest, Vol 55, Issue 44
>> **********************************************
>>
>> _______________________________________________
>> 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
>
More information about the gpfsug-discuss
mailing list