On 10/09/12 21:54 +, Chip Burke wrote:
Well, after a few days of testing it seems luci/ricci is still flakey.
At first, there seems to be more than XML entities problem involved.
This is because luci, unlike ccs and ccs_sync (cman_tool version uses
ccs_sync under the hood) should not suffer
On 12/09/12 14:00 +0200, Jan Pokorný wrote:
cat EOF | patch --fuzz=3 -b .std
Sorry, this line should read:
cat EOF | patch --fuzz=3 -b -z.std -p1
--
Jan
--
Linux-cluster mailing list
Linux-cluster@redhat.com
https://www.redhat.com/mailman/listinfo/linux-cluster
Well, after a few days of testing it seems luci/ricci is still flakey. If
I update things via luci, the cluster.conf on the local machine with luci
updates, but nothing pushes out to other nodes. If I then manually run
ccs_sync on the node with the new configuration, things push out to the
other
On 06/09/12 18:44 +, Chip Burke wrote:
I only eliminated the second and that was all it took. My guess is this
is some edge case where the two s in the string made it break where as a
single did not cause things to escape or what have you.
Oh, I now see what is going on. Once you were
On 05/09/12 16:21 +, Chip Burke wrote:
This gives me the same behavior.
Sorry, I can now see it was a bad workaround guess from the beginning.
I think the strace logs you provided contain good-enough information
about the issue and still scratching my head.
Part of it is that there are two
Well that was an easy enough fix finally. I thought perhaps the password
for the VMWare fence account was the issue and updated cluster.conf with a
place holder password of 'password'. Ricci would not work. So I updated
the actual ricci user account to use a password of 'password' and
restarted
On 06/09/12 15:11 +, Chip Burke wrote:
Well that was an easy enough fix finally. I thought perhaps the password
for the VMWare fence account was the issue and updated cluster.conf with a
place holder password of 'password'. Ricci would not work. So I updated
the actual ricci user account
I only eliminated the second and that was all it took. My guess is this
is some edge case where the two s in the string made it break where as a
single did not cause things to escape or what have you.
All that said, thanks again!
Chip Burke
On
On 20/08/12 14:51 +, Chip Burke wrote:
Thanks for sticking with me on this.
Sorry for delay.
The traceback from your initial email, which ended with:
TypeError: No object (name: translator) has been registered for this
thread
I overlooked this one, but independently hit it too [1].
But
This gives me the same behavior. On each node I ran:
#rm -f /var/lib/ricci/certs/clients/*
#service ricci restart
Then from one node I simply incremented the version in cluster.conf and ran
# cman_tool version -r
You have not authenticated to the ricci daemon on xanadunode1
Password:
You
Hello Chip,
On 17/08/12 15:14 +, Chip Burke wrote:
Libvirt is not installed on any of the hosts.
could you please provide a strace log (best as gzipped attachment sent
off-list, or, you can use e.g. fpaste.org and provide a link if the
log is not so huge).
Something like (untested):
#
Thanks for sticking with me on this. Here's the log:
https://dl.dropbox.com/u/8137282/strace.ricci.tgz
Chip Burke
On 8/20/12 10:28 AM, Jan Pokorný jpoko...@redhat.com wrote:
Hello Chip,
On 17/08/12 15:14 +, Chip Burke wrote:
Libvirt is not
Libvirt is not installed on any of the hosts.
Chip Burke
On 8/16/12 6:22 PM, Chris Feist cfe...@redhat.com wrote:
Can you try removing libvirt (rpm -e libvirt) and restarting ricci
(/etc/init.d/ricci restart).
And run that command again?
--
Maybe a stupid question..
from node1:
telnet node2 1
do you get anything? are the iptables set correctly? (and check also
from node2 to node1 and from the luci machine to both nodes)
Fabio
On 8/15/2012 11:49 PM, Chip Burke wrote:
There is nothing in messages or secure on either node1 or
On 08/15/12 16:49, Chip Burke wrote:
There is nothing in messages or secure on either node1 or 2 at that time.
Ok, there's something going on with the ricci authentication on that node. Can
you give me the output of 'rpm -q ricci' as well as do a '/etc/init.d/ricci
restart'.
Then on the
Here we goŠ
node1:
ricci-0.16.2-55.el6.x86_64
node2:
ricci-0.16.2-55.el6.x86_64
[root@xanadunode2 ~]# service ricci stop
Shutting down ricci: [ OK ]
[root@xanadunode2 ~]# service ricci start
Starting ricci:[
Indeed. I get in via telnet between machines and get dumped out for not
using SSL, but that is to be expected.
Ps -A/top also show ricci happily sitting there listening.
Additionally
#netstat -lnptu | grep 1
tcp0 0 :::1:::*
LISTEN 3210/ricci
So
On 08/16/12 13:52, Chip Burke wrote:
Here we goŠ
node1:
ricci-0.16.2-55.el6.x86_64
node2:
ricci-0.16.2-55.el6.x86_64
[root@xanadunode2 ~]# service ricci stop
Shutting down ricci: [ OK ]
[root@xanadunode2 ~]# service ricci start
Starting ricci:
time ccs -d -h xanadunode2 --getconf
Gives me
real2m7.027s
user0m0.053s
sys 0m0.013s
So it sits for quite a while.
Chip Burke
On 8/16/12 3:52 PM, Chris Feist cfe...@redhat.com wrote:
On 08/16/12 13:52, Chip Burke wrote:
Here we goŠ
On 08/16/12 15:09, Chip Burke wrote:
time ccs -d -h xanadunode2 --getconf
Gives me
real2m7.027s
user0m0.053s
sys 0m0.013s
Can you try removing libvirt (rpm -e libvirt) and restarting ricci
(/etc/init.d/ricci restart).
And run that command again?
So it sits for quite a
On 08/14/12 20:34, Chip Burke wrote:
[root@xanadunode1 ~]# ccs -h xanadunode2 --getconf
This gives me similar results. It sits and spins for a few minutes and
then fails with:
Error: no ricci tag in ricci response
ccs -f /etc/cluster/cluster.conf -h xanadunode2 --setconf
Can you send me the
modcluster-0.16.2-18.el6.x86_64
And
[root@xanadunode1 ~]# ccs -d -h xanadunode2 --getconf
***Sending to ricci server:
ricci function=process_batch async=false version=1.0batchmodule
name=clusterrequest API_version=1.0function_call
name=get_cluster.conf/function_call/request/module/batch/ricci
On 08/15/12 15:08, Chip Burke wrote:
modcluster-0.16.2-18.el6.x86_64
And
[root@xanadunode1 ~]# ccs -d -h xanadunode2 --getconf
***Sending to ricci server:
ricci function=process_batch async=false version=1.0batchmodule
name=clusterrequest API_version=1.0function_call
There is nothing in messages or secure on either node1 or 2 at that time.
Chip Burke
On 8/15/12 4:50 PM, Chris Feist cfe...@redhat.com wrote:
On 08/15/12 15:08, Chip Burke wrote:
modcluster-0.16.2-18.el6.x86_64
And
[root@xanadunode1 ~]# ccs -d
CentOS 6.2, cman version 3.0.12.1
As for the syslog, I have nothing on other the node sending or the nodes
receiving. There is no output at all. And after troubleshooting further,
#cman_tool version -r -S
Works if I do a manual push via scp, so it must be getting hung up on the
file transfer.
On 08/13/12 16:38, Chip Burke wrote:
Ricci is seemingly not working through either Luci nor cman_tool. There does't
seem to be a lot of logging to go off of (at least I haven't found it) but what
I did find in the Luci log is as follows:
15:51:06,793 ERROR [luci.lib.ricci_communicator] Error
Ricci is seemingly not working through either Luci nor cman_tool. There does't
seem to be a lot of logging to go off of (at least I haven't found it) but what
I did find in the Luci log is as follows:
15:51:06,793 ERROR [luci.lib.ricci_communicator] Error receiving header from
On 08/13/2012 05:38 PM, Chip Burke wrote:
Ricci is seemingly not working through either Luci nor cman_tool. There
does't seem to be a lot of logging to go off of (at least I haven't
found it) but what I did find in the Luci log is as follows:
15:51:06,793 ERROR [luci.lib.ricci_communicator]
28 matches
Mail list logo
