The branch, master has been updated
       via  919af5aadb797cfdd10473b6a1269f4ae2a9dbda (commit)
      from  d94e76bfb3e464c0540331caf282efc13ff60e42 (commit)

http://gitweb.samba.org/?p=sahlberg/ctdb.git;a=shortlog;h=master


- Log -----------------------------------------------------------------
commit 919af5aadb797cfdd10473b6a1269f4ae2a9dbda
Author: Ronnie Sahlberg <[EMAIL PROTECTED]>
Date:   Thu Jul 10 13:40:00 2008 +1000

    explain why you have to have a real ip address as well as the "virtual"
    ip address for lvs

-----------------------------------------------------------------------

Summary of changes:
 doc/ctdbd.1      |    4 ++++
 doc/ctdbd.1.html |   18 +++++++++++++++---
 doc/ctdbd.1.xml  |   15 +++++++++++++++
 3 files changed, 34 insertions(+), 3 deletions(-)


Changeset truncated at 500 lines:

diff --git a/doc/ctdbd.1 b/doc/ctdbd.1
index 858806b..9d62821 100644
--- a/doc/ctdbd.1
+++ b/doc/ctdbd.1
@@ -395,6 +395,10 @@ Example:
 .fi
 .RE
 .sp
+.PP
+If you use LVS, you must still have a real/permanent address configured for 
the public interface on each node. This address must be routable and the 
cluster nodes must be configured so that all traffic back to client hosts are 
routed through this interface. This is also required in order to allow 
samba/winbind on the node to talk to the domain controller. (we can not use the 
lvs ip address to initiate outgoing traffic)
+.PP
+I.e. make sure that you can "ping" both the domain controller and also all of 
the clients from the node BEFORE you enable LVS. Also make sure that when you 
ping these hosts that the traffic is routed out through the eth0 interface.
 .SH "REMOTE CLUSTER NODES"
 .PP
 It is possible to have a CTDB cluster that spans across a WAN link. For 
example where you have a CTDB cluster in your datacentre but you also want to 
have one additional CTDB node located at a remote branch site. This is similar 
to how a WAN accelerator works but with the difference that while a 
WAN\-accelerator often acts as a Proxy or a MitM, in the ctdb remote cluster 
node configuration the Samba instance at the remote site IS the genuine server, 
not a proxy and not a MitM, and thus provides 100% correct CIFS semantics to 
clients.
diff --git a/doc/ctdbd.1.html b/doc/ctdbd.1.html
index f800ba4..873b025 100644
--- a/doc/ctdbd.1.html
+++ b/doc/ctdbd.1.html
@@ -374,7 +374,19 @@ You must also specify the "--lvs" command line argument to 
ctdbd to activete LVS
        CTDB_PUBLIC_INTERFACE=eth0
        CTDB_LVS_PUBLIC_IP=10.0.0.237
        </pre><p>
-       </p></div></div><div class="refsect1" lang="en"><a 
name="id2529319"></a><h2>REMOTE CLUSTER NODES</h2><p>
+       </p></div><p>
+    If you use LVS, you must still have a real/permanent address configured
+    for the public interface on each node. This address must be routable
+    and the cluster nodes must be configured so that all traffic back to client
+    hosts are routed through this interface. This is also required in order
+    to allow samba/winbind on the node to talk to the domain controller.
+    (we can not use the lvs ip address to initiate outgoing traffic)
+    </p><p>
+    I.e. make sure that you can "ping" both the domain controller and also
+    all of the clients from the node BEFORE you enable LVS. Also make sure
+    that when you ping these hosts that the traffic is routed out through the
+    eth0 interface.
+    </p></div><div class="refsect1" lang="en"><a 
name="id2529338"></a><h2>REMOTE CLUSTER NODES</h2><p>
 It is possible to have a CTDB cluster that spans across a WAN link. 
 For example where you have a CTDB cluster in your datacentre but you also
 want to have one additional CTDB node located at a remote branch site.
@@ -403,10 +415,10 @@ CTDB_CAPABILITY_RECMASTER=no
     </p><p>
        Verify with the command "ctdb getcapabilities" that that node no longer
        has the recmaster or the lmaster capabilities.
-    </p></div><div class="refsect1" lang="en"><a name="id2529370"></a><h2>SEE 
ALSO</h2><p>
+    </p></div><div class="refsect1" lang="en"><a name="id2529389"></a><h2>SEE 
ALSO</h2><p>
       ctdb(1), onnode(1)
       <a href="http://ctdb.samba.org/"; target="_top">http://ctdb.samba.org/</a>
-    </p></div><div class="refsect1" lang="en"><a 
name="id2529383"></a><h2>COPYRIGHT/LICENSE</h2><div 
class="literallayout"><p><br>
+    </p></div><div class="refsect1" lang="en"><a 
name="id2529402"></a><h2>COPYRIGHT/LICENSE</h2><div 
class="literallayout"><p><br>
 Copyright (C) Andrew Tridgell 2007<br>
 Copyright (C) Ronnie sahlberg 2007<br>
 <br>
diff --git a/doc/ctdbd.1.xml b/doc/ctdbd.1.xml
index cb82ad2..937fec3 100644
--- a/doc/ctdbd.1.xml
+++ b/doc/ctdbd.1.xml
@@ -719,6 +719,21 @@ You must also specify the "--lvs" command line argument to 
ctdbd to activete LVS
        </para>
 
     </refsect2>
+
+    <para>
+    If you use LVS, you must still have a real/permanent address configured
+    for the public interface on each node. This address must be routable
+    and the cluster nodes must be configured so that all traffic back to client
+    hosts are routed through this interface. This is also required in order
+    to allow samba/winbind on the node to talk to the domain controller.
+    (we can not use the lvs ip address to initiate outgoing traffic)
+    </para>
+    <para>
+    I.e. make sure that you can "ping" both the domain controller and also
+    all of the clients from the node BEFORE you enable LVS. Also make sure
+    that when you ping these hosts that the traffic is routed out through the
+    eth0 interface.
+    </para>
   </refsect1>
     
 


-- 
CTDB repository

Reply via email to