[Linux-cluster] Samba share resource fails to start after upgrade to Cluster Suite 4U4

[Lon Hohberger]

On Wed, 2006-11-01 at 09:32 +0100, Cosimo Streppone wrote:
> Lon Hohberger wrote:
> 
> > On Fri, 2006-10-27 at 23:16 +0200, Cosimo Streppone wrote:
> > 
> >> <resources>
> >>   <ip address="10.1.1.200" monitor_link="1"/>
> >>   <fs device="/dev/mapper/mpath0p1" force_fsck="0" force_unmount="0" fsid="4275" fstype="ext2" mountpoint="/mnt/san" name="Slim2k disk" options="noatime,nodiratime" self_fence="1"/>
> >>   <smb name="//share/exportdb" workgroup="WORKGROUP"/>
> > 
> > The share name should not contain any slashes.  With a valid name, the
> > <smb> resource agent generates a brain-dead example configuration for
> > use as something for the administrator to build on.
> > 
> > Ok, so, "exportdb" or something would be a better name.  Using that,
> > given the rest your service configuration, the agent will generate an
> > *example* configuration with two properties:
> 
>  > [...]
> 
> I think there's an error on my part, probably.
> By that config, I meant to define:
> 
> - an external filesystem, which is a (Yeah) SAN, that's mounted
>    by the active node only, that contains the core applications;
> - another external smb filesystem, which is accessible as
>    smb://share/exportdb, with "share" being a machine name, and
>    "exportdb" the share name. (What a mess, I know).
> - The /etc/init.d/smb script that starts the samba server
>    on the active node, for other shares that *my* server exposes.

Easiest thing to do is flip things around:

(You can do this by refs if you want).

  <service name="foo"/>
   <ip address="10.1.1.200" monitor_link="1"/>
   <fs device="/dev/mapper/mpath0p1" ... mountpoint="/mnt/san" name="exportdb" .../>
   <smb name="share" workgroup="WORKGROUP"/>
  </service>

That will cause smb.sh to create a samba config
called /etc/samba/smb.conf.share.  It will be accessible only via
10.1.1.200 using netbios name "share" in workgroup "WORKGROUP", and
providing access to /mnt/san as the share name "exportdb", i.e., clients
accessing:

   //share/exportdb

... will see the contents of /mnt/san.

Since you intend to run a machine-specific Samba config (e.g. one not
managed by the cluster, presumably exporting local file systems or
printers, etc.), you should:

* Ensure that your /etc/samba/smb.conf is configured to *not* bind to
the 10.1.1.200 address.  So, you'll have to set "bind interfaces="
yourself in /etc/samba/smb.conf.

* Generally speaking, machine-specific Samba shares should not usually
bind to cluster IP addresses or be started as part of a cluster service.
So, if you have machine-specific Samba shares you want started, you
should probably just chkconfig --add them rather than putting them in as
part of a cluster service.  Otherwise, clients accessing the share will
lose access any time you take down the cluster service (even though they
could operate independently).

The end result should look like:

+---------[ Server1 ]----------+ +--[ Server2 ]--+
|                   "share"    | |               |
|  "share1"      (floating IP) | |   "share2"    |
|  10.1.1.101     10.1.1.200   | |  10.1.1.102   |
|       |              |       | |       |       |
|       |              |       | |       |       |
|       |              |       | |       |       |
|  /mnt/local1      /mnt/san   | |  /mnt/local2  |
+------------------------------+ +---------------+
    (local)      (failover/HA)        (local)

The "share" pseudo-machine (including the "exportdb" export), the IP
address 10.1.1.200, and /mnt/san can be provided by either node, but the
local exports may only be provided by specific machines.  In the above
example, Server1 is providing "share", but you could move it to Server2
using the clusvcadm -r command.

Hope that helps.

-- Lon