Hi, On Tue, Dec 11, 2007 at 09:16:32AM +0000, Franck Ganachaud wrote: > I include the log from the point where I stop mysql > By the way, the cib.xml I included previously is an extreact of the output > of the cibadmin -Q (I removed the status part) > > Looks like the colocation constraint isn't good : > Dec 11 09:59:57 server_a pengine: [2763]: ERROR: unpack_rsc_colocation: No > resource (con=web_if_mysql, rsc=mysql_orb1) > > In my case I don't know then what resource to link the colocation to: > mysql_orb1:0 or mysql_orb1:1? or maybe the clone_max value shoudn't be 2. > It's not clear.
It is probably not useful to have a colocation/location on the cloned resource. At least not in this case. You should regroup and rethink the strategy. First, why do you have the mysql as a cloned resource? How does it operate? Thanks, Dejan > --------- log start ---------------- > Dec 11 09:59:25 server_a mysql_orb[4559]: [4564]: INFO: database is OK > Dec 11 09:59:29 server_a apache[4591]: [4681]: INFO: 09:59:29 > URL:http://192.168.87.100:80/server-status [1,626/1,626] -> "-" [1] > Dec 11 09:59:42 server_a lsb_log_message: succeeded > Dec 11 09:59:55 server_a mysql_orb[4768]: [4773]: INFO: database is KO > Dec 11 09:59:55 server_a crmd: [2754]: info: process_lrm_event: LRM > operation mysql_orb1:1_monitor_30000 (call=27, rc=7) complete > Dec 11 09:59:55 server_a cib: [2750]: info: cib_diff_notify: Update > (client: 2754, call:66): 0.300.3715 -> 0.300.3716 (ok) > Dec 11 09:59:55 server_a crmd: [2754]: info: do_state_transition: server_a: > State transition S_IDLE -> S_POLICY_ENGINE [ input=I_PE_CALC > cause=C_IPC_MESSAGE origin=route_message ] > Dec 11 09:59:55 server_a tengine: [2762]: info: te_update_diff: Processing > diff (cib_update): 0.300.3715 -> 0.300.3716 > Dec 11 09:59:55 server_a crmd: [2754]: info: do_state_transition: All 2 > cluster nodes are eligable to run resources. > Dec 11 09:59:55 server_a tengine: [2762]: info: process_graph_event: Action > mysql_orb1:1_monitor_30000 arrived after a completed transition > Dec 11 09:59:55 server_a tengine: [2762]: info: update_abort_priority: > Abort priority upgraded to 1000000 > Dec 11 09:59:55 server_a tengine: [2762]: WARN: update_failcount: Updating > failcount for mysql_orb1:1 on 352f29b5-f0ed-4866-a839-71dbdbfd491d after > failed monitor: rc=7 > Dec 11 09:59:55 server_a cib: [2750]: info: cib_diff_notify: Update > (client: 2762, call:3): 0.300.3716 -> 0.300.3717 (ok) > Dec 11 09:59:55 server_a tengine: [2762]: info: te_update_diff: Processing > diff (cib_modify): 0.300.3716 -> 0.300.3717 > Dec 11 09:59:55 server_a tengine: [2762]: info: extract_event: Aborting on > transient_attributes changes for 352f29b5-f0ed-4866-a839-71dbdbfd491d > Dec 11 09:59:55 server_a pengine: [2763]: info: log_data_element: > process_pe_message: [generation] <cib admin_epoch="0" cib-last-written="Tue > Dec 11 09:54:05 2007" cib_feature_revision="1.3" epoch="300" > generated="true" have_quorum="true" ignore_dtd="false" num_peers="2" > num_updates="3716" ccm_transition="2" > dc_uuid="352f29b5-f0ed-4866-a839-71dbdbfd491d"/> > Dec 11 09:59:55 server_a pengine: [2763]: notice: cluster_option: Using > default value 'stop' for cluster option 'no-quorum-policy' > Dec 11 09:59:55 server_a pengine: [2763]: notice: cluster_option: Using > default value '60s' for cluster option 'cluster-delay' > Dec 11 09:59:55 server_a pengine: [2763]: notice: cluster_option: Using > default value '-1' for cluster option 'pe-error-series-max' > Dec 11 09:59:55 server_a pengine: [2763]: notice: cluster_option: Using > default value '-1' for cluster option 'pe-warn-series-max' > Dec 11 09:59:55 server_a pengine: [2763]: notice: cluster_option: Using > default value '-1' for cluster option 'pe-input-series-max' > Dec 11 09:59:55 server_a pengine: [2763]: notice: cluster_option: Using > default value 'true' for cluster option 'startup-fencing' > Dec 11 09:59:55 server_a pengine: [2763]: info: determine_online_status: > Node server_a is online > Dec 11 09:59:55 server_a pengine: [2763]: info: determine_online_status: > Node server_b is online > Dec 11 09:59:56 server_a pengine: [2763]: ERROR: unpack_rsc_colocation: No > resource (con=web_if_mysql, rsc=mysql_orb1) > Dec 11 09:59:56 server_a pengine: [2763]: info: clone_print: Clone Set: > MySQL_ORB > Dec 11 09:59:56 server_a pengine: [2763]: info: native_print: > mysql_orb1:0 (heartbeat::ocf:mysql_orb): Started server_b > Dec 11 09:59:56 server_a pengine: [2763]: info: native_print: > mysql_orb1:1 (heartbeat::ocf:mysql_orb): Started server_a > Dec 11 09:59:56 server_a pengine: [2763]: info: group_print: Resource > Group: group_1 > Dec 11 09:59:56 server_a pengine: [2763]: info: native_print: > IPaddr_Cluster (heartbeat::ocf:IPaddr): Started server_a > Dec 11 09:59:56 server_a pengine: [2763]: info: native_print: apache_2 > (heartbeat::ocf:apache): Started server_a > Dec 11 09:59:56 server_a pengine: [2763]: notice: NoRoleChange: Leave > resource mysql_orb1:0 (server_b) > Dec 11 09:59:56 server_a pengine: [2763]: notice: NoRoleChange: Leave > resource mysql_orb1:1 (server_a) > Dec 11 09:59:56 server_a pengine: [2763]: info: native_color: Combine > scores from apache_2 and IPaddr_Cluster > Dec 11 09:59:56 server_a pengine: [2763]: info: native_assign_node: 2 nodes > with equal score (100) for running the listed resources (chose server_a): > Dec 11 09:59:56 server_a pengine: [2763]: notice: NoRoleChange: Leave > resource IPaddr_Cluster (server_a) > Dec 11 09:59:56 server_a pengine: [2763]: notice: NoRoleChange: Leave > resource apache_2 (server_a) > Dec 11 09:59:56 server_a cib: [4774]: info: write_cib_contents: Wrote > version 0.300.3717 of the CIB to disk (digest: > 484665951aeff3f81f4653ed838910cd) > Dec 11 09:59:56 server_a pengine: [2763]: info: process_pe_message: > Transition 6: PEngine Input stored in: > /var/lib/heartbeat/pengine/pe-input-10.bz2 > Dec 11 09:59:57 server_a pengine: [2763]: info: process_pe_message: > Configuration ERRORs found during PE processing. Please run "crm_verify > -L" to identify issues. > Dec 11 09:59:57 server_a pengine: [2763]: info: log_data_element: > process_pe_message: [generation] <cib admin_epoch="0" cib-last-written="Tue > Dec 11 09:54:05 2007" cib_feature_revision="1.3" epoch="300" > generated="true" have_quorum="true" ignore_dtd="false" num_peers="2" > num_updates="3717" ccm_transition="2" > dc_uuid="352f29b5-f0ed-4866-a839-71dbdbfd491d"/> > Dec 11 09:59:57 server_a pengine: [2763]: notice: cluster_option: Using > default value 'stop' for cluster option 'no-quorum-policy' > Dec 11 09:59:57 server_a pengine: [2763]: notice: cluster_option: Using > default value '60s' for cluster option 'cluster-delay' > Dec 11 09:59:57 server_a pengine: [2763]: notice: cluster_option: Using > default value '-1' for cluster option 'pe-error-series-max' > Dec 11 09:59:57 server_a pengine: [2763]: notice: cluster_option: Using > default value '-1' for cluster option 'pe-warn-series-max' > Dec 11 09:59:57 server_a pengine: [2763]: notice: cluster_option: Using > default value '-1' for cluster option 'pe-input-series-max' > Dec 11 09:59:57 server_a pengine: [2763]: notice: cluster_option: Using > default value 'true' for cluster option 'startup-fencing' > Dec 11 09:59:57 server_a pengine: [2763]: info: determine_online_status: > Node server_a is online > Dec 11 09:59:57 server_a pengine: [2763]: info: determine_online_status: > Node server_b is online > Dec 11 09:59:57 server_a pengine: [2763]: ERROR: unpack_rsc_colocation: No > resource (con=web_if_mysql, rsc=mysql_orb1) > Dec 11 09:59:57 server_a pengine: [2763]: info: clone_print: Clone Set: > MySQL_ORB > Dec 11 09:59:57 server_a pengine: [2763]: info: native_print: > mysql_orb1:0 (heartbeat::ocf:mysql_orb): Started server_b > Dec 11 09:59:57 server_a pengine: [2763]: info: native_print: > mysql_orb1:1 (heartbeat::ocf:mysql_orb): Started server_a > Dec 11 09:59:57 server_a pengine: [2763]: info: group_print: Resource > Group: group_1 > Dec 11 09:59:57 server_a pengine: [2763]: info: native_print: > IPaddr_Cluster (heartbeat::ocf:IPaddr): Started server_a > Dec 11 09:59:57 server_a pengine: [2763]: info: native_print: apache_2 > (heartbeat::ocf:apache): Started server_a > Dec 11 09:59:58 server_a pengine: [2763]: notice: NoRoleChange: Leave > resource mysql_orb1:0 (server_b) > Dec 11 09:59:58 server_a pengine: [2763]: notice: NoRoleChange: Leave > resource mysql_orb1:1 (server_a) > Dec 11 09:59:58 server_a pengine: [2763]: info: native_color: Combine > scores from apache_2 and IPaddr_Cluster > Dec 11 09:59:58 server_a pengine: [2763]: info: native_assign_node: 2 nodes > with equal score (100) for running the listed resources (chose server_a): > Dec 11 09:59:58 server_a pengine: [2763]: notice: NoRoleChange: Leave > resource IPaddr_Cluster (server_a) > Dec 11 09:59:58 server_a crmd: [2754]: info: do_state_transition: server_a: > State transition S_POLICY_ENGINE -> S_TRANSITION_ENGINE [ > input=I_PE_SUCCESS cause=C_IPC_MESSAGE origin=route_message ] > Dec 11 09:59:58 server_a pengine: [2763]: notice: NoRoleChange: Leave > resource apache_2 (server_a) > Dec 11 09:59:58 server_a tengine: [2762]: info: unpack_graph: Unpacked > transition 7: 0 actions in 0 synapses > Dec 11 09:59:58 server_a tengine: [2762]: info: run_graph: Transition 7: > (Complete=0, Pending=0, Fired=0, Skipped=0, Incomplete=0) > Dec 11 09:59:58 server_a tengine: [2762]: info: notify_crmd: Transition 7 > status: te_complete - <null> > Dec 11 09:59:58 server_a crmd: [2754]: info: do_state_transition: server_a: > State transition S_TRANSITION_ENGINE -> S_IDLE [ input=I_TE_SUCCESS > cause=C_IPC_MESSAGE origin=route_message ] > Dec 11 09:59:58 server_a pengine: [2763]: info: process_pe_message: > Transition 7: PEngine Input stored in: > /var/lib/heartbeat/pengine/pe-input-11.bz2 > Dec 11 09:59:58 server_a pengine: [2763]: info: process_pe_message: > Configuration ERRORs found during PE processing. Please run "crm_verify > -L" to identify issues. > Dec 11 09:59:59 server_a apache[4801]: [4890]: INFO: 09:59:59 > URL:http://192.168.87.100:80/server-status [1,628/1,628] -> "-" [1] > Dec 11 10:00:25 server_a mysql_orb[4940]: [4946]: INFO: MATISsE database is > KO > Dec 11 10:00:29 server_a apache[4978]: [5068]: INFO: 10:00:29 > URL:http://192.168.87.100:80/server-status [1,626/1,626] -> "-" [1] > Dec 11 10:00:55 server_a mysql_orb[5112]: [5117]: INFO: MATISsE database is > KO > --------- log stop ---------------- > > Dejan Muhamedagic a ?crit : >> Hi, >> >> On Mon, Dec 10, 2007 at 04:27:37PM +0100, Franck Ganachaud wrote: >> >>> Ok, here is where I am now. >>> >>> I built a clone set and colocated the group1 with the clone. >>> But when I stop mysql, the clone monitor operation (mysql_orb) return >>> that DB is down but group1 isn't relocated to serveur B. >>> >>> Anyone has a clue? >>> >> >> Can you post logs? If you have hb_report you can use that. >> >> >>> I copy the cib : >>> >>> <configuration> >>> <crm_config> >>> <cluster_property_set id="cib-bootstrap-options"> >>> <attributes> >>> <nvpair id="cib-bootstrap-options-symmetric-cluster" >>> name="symmetric-cluster" value="true"/> >>> <nvpair id="cib-bootstrap-options-no_quorum-policy" >>> name="no_quorum-policy" value="stop"/> >>> <nvpair id="cib-bootstrap-options-default-resource-stickiness" >>> name="default-resource-stickiness" value="0"/> >>> <nvpair >>> id="cib-bootstrap-options-default-resource-failure-stickiness" >>> name="default-resource-failure-stickiness" value="0"/> >>> <nvpair id="cib-bootstrap-options-stonith-enabled" >>> name="stonith-enabled" value="false"/> >>> <nvpair id="cib-bootstrap-options-stonith-action" >>> name="stonith-action" value="reboot"/> >>> <nvpair id="cib-bootstrap-options-stop-orphan-resources" >>> name="stop-orphan-resources" value="true"/> >>> <nvpair id="cib-bootstrap-options-stop-orphan-actions" >>> name="stop-orphan-actions" value="true"/> >>> <nvpair id="cib-bootstrap-options-remove-after-stop" >>> name="remove-after-stop" value="false"/> >>> <nvpair id="cib-bootstrap-options-short-resource-names" >>> name="short-resource-names" value="true"/> >>> <nvpair id="cib-bootstrap-options-transition-idle-timeout" >>> name="transition-idle-timeout" value="5min"/> >>> <nvpair id="cib-bootstrap-options-default-action-timeout" >>> name="default-action-timeout" value="5s"/> >>> <nvpair id="cib-bootstrap-options-is-managed-default" >>> name="is-managed-default" value="true"/> >>> </attributes> >>> </cluster_property_set> >>> </crm_config> >>> <nodes> >>> <node id="0e8b2fa4-983b-4e56-a4a5-72dbb2aeaeec" type="normal" >>> uname="server_a"> >>> <instance_attributes >>> id="nodes-0e8b2fa4-983b-4e56-a4a5-72dbb2aeaeec"> >>> <attributes> >>> <nvpair id="standby-0e8b2fa4-983b-4e56-a4a5-72dbb2aeaeec" >>> name="standby" value="off"/> >>> </attributes> >>> </instance_attributes> >>> </node> >>> <node id="5cdd04e8-035a-44cf-ab60-3065840109db" type="normal" >>> uname="server_b"> >>> <instance_attributes >>> id="nodes-5cdd04e8-035a-44cf-ab60-3065840109db"> >>> <attributes> >>> <nvpair id="standby-5cdd04e8-035a-44cf-ab60-3065840109db" >>> name="standby" value="off"/> >>> </attributes> >>> </instance_attributes> >>> </node> >>> <node id="9e05d57a-ae9c-430d-a210-d03b9f37739e" type="normal" >>> uname="server_b"/> >>> <node id="352f29b5-f0ed-4866-a839-71dbdbfd491d" type="normal" >>> uname="server_a"/> >>> </nodes> >>> >> >> Nodes are listed twice. >> >> >>> <resources> >>> <clone id="MySQL_ORB" interleave="false" is_managed="true" >>> notify="false" ordered="false"> >>> <instance_attributes id="MySQL_ORB_inst_attr"> >>> <attributes> >>> <nvpair id="MySQL_ORB_attr_0" name="clone_max" value="2"/> >>> <nvpair id="MySQL_ORB_attr_1" name="clone_node_max" >>> value="1"/> >>> </attributes> >>> </instance_attributes> >>> <primitive class="ocf" id="mysql_orb1" is_managed="false" >>> provider="heartbeat" type="mysql_orb"> >>> <operations> >>> <op id="mysql_orb_mon" interval="30s" name="monitor" >>> on_fail="stop" timeout="30s"/> >>> </operations> >>> </primitive> >>> </clone> >>> <group id="group_1" restart_type="restart"> >>> <primitive class="ocf" id="IPaddr_Cluster" provider="heartbeat" >>> type="IPaddr"> >>> <operations> >>> <op id="IPaddr_Cluster_mon" interval="5s" name="monitor" >>> timeout="5s"/> >>> </operations> >>> <instance_attributes id="IPaddr_Cluster_inst_attr"> >>> <attributes> >>> <nvpair id="IPaddr_Cluster_attr_0" name="ip" >>> value="192.168.87.100"/> >>> </attributes> >>> </instance_attributes> >>> </primitive> >>> <primitive class="ocf" id="apache_2" provider="heartbeat" >>> type="apache"> >>> <operations> >>> <op id="apache_2_mon" interval="30s" name="monitor" >>> timeout="30s"/> >>> </operations> >>> <instance_attributes id="apache_2_inst_attr"> >>> <attributes> >>> <nvpair id="apache_2_attr_0" name="configfile" >>> value="/usr/local/apache/conf/httpd.conf"/> >>> </attributes> >>> </instance_attributes> >>> </primitive> >>> </group> >>> </resources> >>> <constraints> >>> <rsc_location id="rsc_location_group_1" rsc="group_1"> >>> <rule id="prefered_location_group_1" score="100"> >>> <expression attribute="#uname" >>> id="prefered_location_group_1_expr" operation="eq" value="server_a"/> >>> </rule> >>> </rsc_location> >>> <rsc_colocation from="group_1" id="web_if_mysql" score="INFINITY" >>> to="mysql_orb1"/> >>> >> >> This constraint looks strange. Not sure how should the cluster >> behave, because you have two clones and the web group is bound to >> both. >> >> Thanks, >> >> Dejan >> >> >>> </constraints> >>> </configuration> >>> >>> >>> >>> Franck Ganachaud a ?crit : >>> >>>> Thanks for the tips both of you. >>>> >>>> I'm going to work on that the next few days. >>>> >>>> Andrew Beekhof a ?crit : >>>> >>>>> On Dec 5, 2007, at 1:44 PM, Dejan Muhamedagic wrote: >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> On Wed, Dec 05, 2007 at 11:51:20AM +0100, Franck Ganachaud wrote: >>>>>> >>>>>>> Well I don't want hearbeat to stop or start mysql. >>>>>>> >>>>>> You should be better off if you do. Otherwise, you'll probably >>>>>> end up with an unmaintainable and complex configuration. >>>>>> >>>>>> >>>>>>> And if I colocate R1 with mysql, will a R1 move from server A to B >>>>>>> implie mysql move also? >>>>>>> >>>>>> Not necessarily. Colocations don't have to be symmetrical. >>>>>> >>>>> particularly not if its a clone (ie. a resource that has a copy running >>>>> on each node) >>>>> >>>>> if you really object to having heartbeat manage mysql, use >>>>> is_managed=false for just the mysql resource. >>>>> with this setting, the cluster will never ever modify the state of your >>>>> resource (only check it's health and make decisions for R1 based on >>>>> that) >>>>> >>>>> >>>>>> Thanks, >>>>>> >>>>>> Dejan >>>>>> >>>>>> >>>>>>> Franck. >>>>>>> >>>>>>> Andrew Beekhof a ?crit : >>>>>>> >>>>>>>> On Dec 5, 2007, at 9:42 AM, Franck Ganachaud wrote: >>>>>>>> >>>>>>>> >>>>>>>>> I try to be more explicit. >>>>>>>>> I use v2 configuration >>>>>>>>> >>>>>>>>> I got 2 servers A and B. A set (group) of resource R1. >>>>>>>>> R1 is running by default on server A and jump to server B in case >>>>>>>>> of >>>>>>>>> trouble. >>>>>>>>> This is currently setup and working fine. >>>>>>>>> >>>>>>>>> Now, i need to check mysql running on both server A and B. >>>>>>>>> >>>>>>>>> If mysql isn't ok on server running R1, I need to stop >>>>>>>>> whateverdaemond and move R1 to the other server >>>>>>>>> If mysql isn't ok on server not running R1, I just need to stop >>>>>>>>> whateverdaemond. >>>>>>>>> >>>>>>>>> I made a OCF agent that does the "stop whateverdaemond if mysql is >>>>>>>>> down" job >>>>>>>>> >>>>>>>> dont do that >>>>>>>> write a proper agent for whateverdaemond (maybe you can use an >>>>>>>> init-script instead) >>>>>>>> >>>>>>>> add a clone resource for mysql >>>>>>>> add a clone resource for whateverdaemond >>>>>>>> colocate whateverdaemond with mysql >>>>>>>> colocate R1 with mysql >>>>>>>> >>>>>>>> >>>>>>>>> This where I get puzzled, how to translate the relation between the >>>>>>>>> "if running R1" and the agent I wrote it in heartbeat groups and >>>>>>>>> constraints >>>>>>>>> >>>>>>>>> Hope it's clearer. >>>>>>>>> Franck. >>>>>>>>> >>>>>>>>> Dejan Muhamedagic a ?crit : >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> On Tue, Dec 04, 2007 at 05:25:08PM +0100, Franck Ganachaud wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> I have a two 2 node cluster. >>>>>>>>>>> group1 is active/passive set of ressource. >>>>>>>>>>> group1 is currently hop-ing from one node to the other as >>>>>>>>>>> intended >>>>>>>>>>> when one of the group ressource isn't available. >>>>>>>>>>> >>>>>>>>>>> Now I have a second task for heartbeat. >>>>>>>>>>> On each node, I have a mysql server, if it goes wrong, I must >>>>>>>>>>> shutdown a service and migrate the group1 (if it runs on this >>>>>>>>>>> node) >>>>>>>>>>> to the other node. >>>>>>>>>>> And this something I don't know how to do. >>>>>>>>>>> >>>>>>>>>>> I was thinking about creating a group2 in an active/active >>>>>>>>>>> configuration testing mysql and if goes wrong just shutdown the >>>>>>>>>>> service in the stop process of the group2 but I don't know how to >>>>>>>>>>> force in this case the push of the group1 to the other node of >>>>>>>>>>> it's >>>>>>>>>>> running on the group2 failing node. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Sorry, but I can't follow. Can you please rephrase. >>>>>>>>>> >>>>>>>>>> Which configuration do you use: v1 or v2? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Dejan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Any one can help me? >>>>>>>>>>> Hope it's clear. >>>>>>>>>>> >>>>>>>>>>> Franck. >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Linux-HA mailing list >>>>>>>>>>> [email protected] >>>>>>>>>>> http://lists.linux-ha.org/mailman/listinfo/linux-ha >>>>>>>>>>> See also: http://linux-ha.org/ReportingProblems >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Linux-HA mailing list >>>>>>>>>> [email protected] >>>>>>>>>> http://lists.linux-ha.org/mailman/listinfo/linux-ha >>>>>>>>>> See also: http://linux-ha.org/ReportingProblems >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> -- >>>>>>>>> GANACHAUD Franck >>>>>>>>> Consultant >>>>>>>>> Tel. : +33 (0)2 98 05 43 21 >>>>>>>>> http://www.altran.com >>>>>>>>> -- >>>>>>>>> Technop?le Brest Iroise >>>>>>>>> Site du Vernis - CS 23866 >>>>>>>>> 29238 Brest Cedex 3 - France >>>>>>>>> Tel. : +33 (0)2 98 05 43 21 >>>>>>>>> Fax. : +33 (0)2 98 05 20 34 >>>>>>>>> e-mail: [EMAIL PROTECTED] >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Linux-HA mailing list >>>>>>>>> [email protected] >>>>>>>>> http://lists.linux-ha.org/mailman/listinfo/linux-ha >>>>>>>>> See also: http://linux-ha.org/ReportingProblems >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Linux-HA mailing list >>>>>>>> [email protected] >>>>>>>> http://lists.linux-ha.org/mailman/listinfo/linux-ha >>>>>>>> See also: http://linux-ha.org/ReportingProblems >>>>>>>> >>>>>>>> >>>>>>> -- >>>>>>> GANACHAUD Franck >>>>>>> Consultant >>>>>>> Tel. : +33 (0)2 98 05 43 21 >>>>>>> http://www.altran.com >>>>>>> -- >>>>>>> Technop?le Brest Iroise >>>>>>> Site du Vernis - CS 23866 >>>>>>> 29238 Brest Cedex 3 - France >>>>>>> Tel. : +33 (0)2 98 05 43 21 >>>>>>> Fax. : +33 (0)2 98 05 20 34 >>>>>>> e-mail: [EMAIL PROTECTED] >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Linux-HA mailing list >>>>>>> [email protected] >>>>>>> http://lists.linux-ha.org/mailman/listinfo/linux-ha >>>>>>> See also: http://linux-ha.org/ReportingProblems >>>>>>> >>>>>> _______________________________________________ >>>>>> Linux-HA mailing list >>>>>> [email protected] >>>>>> http://lists.linux-ha.org/mailman/listinfo/linux-ha >>>>>> See also: http://linux-ha.org/ReportingProblems >>>>>> >>>>> _______________________________________________ >>>>> Linux-HA mailing list >>>>> [email protected] >>>>> http://lists.linux-ha.org/mailman/listinfo/linux-ha >>>>> See also: http://linux-ha.org/ReportingProblems >>>>> >>>>> >>> -- >>> GANACHAUD Franck >>> Consultant >>> Tel. : +33 (0)2 98 05 43 21 >>> http://www.altran.com >>> -- >>> Technop?le Brest Iroise >>> Site du Vernis - CS 23866 >>> 29238 Brest Cedex 3 - France >>> Tel. : +33 (0)2 98 05 43 21 >>> Fax. : +33 (0)2 98 05 20 34 >>> e-mail: [EMAIL PROTECTED] >>> >>> _______________________________________________ >>> Linux-HA mailing list >>> [email protected] >>> http://lists.linux-ha.org/mailman/listinfo/linux-ha >>> See also: http://linux-ha.org/ReportingProblems >>> >> _______________________________________________ >> Linux-HA mailing list >> [email protected] >> http://lists.linux-ha.org/mailman/listinfo/linux-ha >> See also: http://linux-ha.org/ReportingProblems >> >> > > -- > GANACHAUD Franck > Consultant > Tel. : +33 (0)2 98 05 43 21 > http://www.altran.com > -- > Technop?le Brest Iroise > Site du Vernis - CS 23866 > 29238 Brest Cedex 3 - France > Tel. : +33 (0)2 98 05 43 21 > Fax. : +33 (0)2 98 05 20 34 > e-mail: [EMAIL PROTECTED] > > _______________________________________________ > Linux-HA mailing list > [email protected] > http://lists.linux-ha.org/mailman/listinfo/linux-ha > See also: http://linux-ha.org/ReportingProblems _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
