I have a good working samba.sh, which uses a modified /etc/rc.d/init.d/smb
script to allow for different concurrent instances. I'll try to shape it up and
submit it.

There should also be a way to have nmbd-only instances for setting up WINS. WINS
instances are the only kind of objects that don't come in smbd/nmbd pairs.

We'll take whatever you have so far, and worry about expanding it later.  :) 
Jim's already starting on the canned-config-generator piece of the GUI.

Created attachment 121718 [details]
Implementation of samba resource agent

This steals a bunch of configuration information from the parent service, such
as the IP and file system resources.  This does not work on top of GFS, which
doesn't work under Samba anyway.  Not tested with ipv6 yet.

The start/stop guts were taken from Red Hat Cluster Suite 3.

The only parameters to this resource agent (which are user-serviceable) are the
name and the workgroup name; everything else is dynamically created during the
start phase.

As per RHCS3, proper documentation is necessary (most can be taken from RHCS3
documentation).  Certain things are not complete yet, such as placing the
per-instance private files (e.g. smbpasswd) in the .clumanager directory (which
is hidden per default).

Manual editing to create ACLs is absolutely necessary.

This RA brings us up to the RHCS3 level of Samba support (and perhaps a bit
past!).  We can add more features to the agent later as customers and community
require.

Please advise on what needs to be changed in documentation.

Documentation-wise:

- Does not work with GFS; only traditional file systems.

- Place at the top level of the service.  Will not run if not at the top level
of the service (and the service will fail to start!).  This is because it needs
to know the service it is running under - it grabs configuration data about that
service.

- Requires /etc/samba/smb.conf.NAME, where NAME is the name you gave to the
Samba instance.  An example basic configuration will be generated for you the
first time you start the service.  This template will need to be modified to add
ACLs, printers, etc., but will contain all of the top-level file system mount
points and IP addresses.

- Only works with SMB + NMB services for file serving currently.

Here is an example NFS + samba service XML:

        <rm>
                <resources>
                        <ip address="192.168.79.21/22" monitor_link="yes"/>
                        <nfsclient name="world-rw" options="rw,no_root_squash"
target="*"/>
                        <fs active_monitor="1" device="/dev/sdb8"
force_unmount="1" fstype="ext3" mountpoint="/mnt/cluster" name="NFS Mount"
self_fence="1"/>
                </resources>
                <service name="nfsservice">
                        <fs ref="NFS Mount">
                                <nfsexport name="nfs exports" type="nfs">
                                        <nfsclient ref="world-rw"/>
                                </nfsexport>
                        </fs>
                        <fs device="/dev/sdb7" force_unmount="1" fstype="ext3"
mountpoint="/mnt/tmp" name="Foo"/>
                        <ip ref="192.168.79.21/22"/>
                        <ip address="192.168.79.20/22" monitor_link="yes"/>
                        <smb name="foooo" workgroup="samba"/>
                </service>
        </rm>

I will attach the resultant smb.conf.foooo

Created attachment 121769 [details]
Example smb.conf.foooo created when the above service is started.

The SHA1 hash at the bottom is to detect user changes to the file.  If the hash
does not line up, the resource agent will *never* regenerate the configuration file.

If the hash matches or the file does not exist, the file will be regenerated. 
This is for a few reasons:

(a) Users might want to add/change IPs or file system mounts during the course
of configuring the service for production.  If this is done before the
smb.conf.NAME has been tweaked, the agent will create a shiny new one with all
of the new data!

(b) We must have the smb.conf.NAME in order to start.

Fixes in CVS ready for QA.

Branches: head, STABLE, RHEL4

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2006-0173.html