sgsax at ksu
May 1, 2012, 9:55 AM
On 04/27/2012 01:29 AM, Ulrich Windl wrote:
>>>> Andrew Beekhof<andrew [at] beekhof> schrieb am 27.04.2012 um 03:37 in Nachricht
> <CAEDLWG0eas2g9nnOYbLuszNHNq7TCYvX4vfrFT0op485qV4WdA [at] mail>:
>> On Thu, Apr 26, 2012 at 8:38 AM, Serge Dubrouski<sergeyfd [at] gmail> wrote:
>>> On Wed, Apr 25, 2012 at 4:28 PM, Seth Galitzer<sgsax [at] ksu> wrote:
>>>> On 04/25/2012 05:12 PM, Dimitri Maziuk wrote:
>>>>> On 04/25/2012 03:53 PM, Seth Galitzer wrote:
>>>>>> Can anybody point me to recent docs on how to go about setting this up?
>>>>>> I've found several much older posts, but not much current with any
>>>>>> kind of helpful detail.
>>>>> If you're running active/passive DRBD, it's what the wiki page calls
>>>>> "mounted on one node at a time". That one's simple: use drbdlinks to
>>>>> keep everything incl. /etc/samba on the drbd filesystem and fire up smbd
>>>>> and nmbd after drbdlinks -- pretty much like any other daemon backed by
>>>>> drbd storage.
>>>> I see how that will get all the locking and user data and that should be
>>>> easy enough to configure. But I'm also doing ADS integration instead of
>>>> winbind, and that also seems to be a problem as only one node can be
>>>> joined to the AD at a time, even with a shared IP. Any suggestions for
>>> Currently there is no official RA for smbd and nmbd daemons.
>> Really? I thought tim had one. He was heavily into samba at one point.
> I guess the problem is with the Samba configuration (and "database") files: The LSB scripts use the usual paths. You could use symlinks to redirect those files, but that's not nice to manage. You could write a modified LSB script, or you could use CTDB. I preferred that last solution. Did I miss something important?
I would much rather not add CTDB if I can help it. It seems that would
add another layer of complexity to an already complex situation. If
it's not absolutely necessary, I'd like to avoid it. I've got the db
files on shared storage, so I'm hoping I can make that route work.
Computing and Information Sciences
Kansas State University
sgsax [at] ksu
Linux-HA mailing list
Linux-HA [at] lists
See also: http://linux-ha.org/ReportingProblems