* upgrade from 0.39 to 0.40 failed...
@ 2012-01-21 13:27 Smart Weblications GmbH - Florian Wiessner
2012-01-21 16:25 ` Wido den Hollander
0 siblings, 1 reply; 9+ messages in thread
From: Smart Weblications GmbH - Florian Wiessner @ 2012-01-21 13:27 UTC (permalink / raw)
To: ceph-devel
Hi List,
i today upgraded from 0.39 to 0.40 and also from linux 3.1.5 to 3.2.1 and now
have the following problems:
first of all, i have a 4 node ceph cluster running.
after the kernel upgrade, 2 of 4 osds failed starting because of btrfs-bugs so i
now only have two osds available ( i set replication level to 3 so the data
should be save)
i upgraded to
ceph version 0.40-1-g7ce8b7a (commit:7ce8b7ae3bbad70fe257db00b6fc566f57f17132)
my ceph.conf looks like this:
node03:/etc/ceph# cat ceph.conf
[global]
pid file = /var/run/ceph/$name.pid
debug ms = 1
# auth supported = cephx
osd journal = /data/ceph.journal
osd_journal_size = 512
# filestore journal writeahead = true
# filestore journal parallel = true
mds max = 4
[mon]
mon data = /data/ceph/mon
[mon.0]
host = node01
mon addr = 192.168.0.4:6789
[mon.1]
host = node02
mon addr = 192.168.0.5:6789
[mon.2]
host = node03
mon addr = 192.168.0.6:6789
[mon.3]
host = node04
mon addr = 192.168.0.7:6789
[mds]
# keyring = /etc/ceph/keyring.$name
# mds dir max commit size 32
[mds.0]
host = node01
[mds.1]
host = node02
[mds.2]
host = node03
[mds.3]
host = node04
[osd]
sudo = true
osd data = /data/ceph/osd
# keyring = /etc/ceph/keyring.$name
[osd.0]
host = node01
[osd.1]
host = node02
[osd.2]
host = node03
[osd.3]
host = node04
i did set up ceph without cephx
so now i upgraded to 0.40 and i have this problem:
node03:/etc/ceph# ceph -w
2012-01-21 14:24:16.177441 7f7c45cc0760 -- :/0 messenger.start
2012-01-21 14:24:16.177628 7f7c45cc0760 -- :/11220 --> 192.168.0.5:6789/0 --
auth(proto 0 30 bytes epoch 0) v1 -- ?+0 0x22f3f60 con 0x22f3ce0
2012-01-21 14:24:16.177926 7f7c45cbf700 -- 192.168.0.6:0/11220 learned my addr
192.168.0.6:0/11220
2012-01-21 14:24:19.177703 7f7c42244700 -- 192.168.0.6:0/11220 mark_down
0x22f3ce0 -- 0x22f3a70
2012-01-21 14:24:19.177798 7f7c42244700 -- 192.168.0.6:0/11220 -->
192.168.0.6:6789/0 -- auth(proto 0 30 bytes epoch 0) v1 -- ?+0 0x22f3f60 con
0x22f51d0
2012-01-21 14:24:22.177921 7f7c42244700 -- 192.168.0.6:0/11220 mark_down
0x22f51d0 -- 0x22f4f60
2012-01-21 14:24:22.177999 7f7c42244700 -- 192.168.0.6:0/11220 -->
192.168.0.7:6789/0 -- auth(proto 0 30 bytes epoch 0) v1 -- ?+0 0x22f3f60 con
0x22f3ce0
2012-01-21 14:24:25.178187 7f7c42244700 -- 192.168.0.6:0/11220 mark_down
0x22f3ce0 -- 0x22f3a70
2012-01-21 14:24:25.178268 7f7c42244700 -- 192.168.0.6:0/11220 -->
192.168.0.6:6789/0 -- auth(proto 0 30 bytes epoch 0) v1 -- ?+0 0x22f3f60 con
0x22f4a50
2012-01-21 14:24:28.178358 7f7c42244700 -- 192.168.0.6:0/11220 mark_down
0x22f4a50 -- 0x22f47e0
2012-01-21 14:24:28.178431 7f7c42244700 -- 192.168.0.6:0/11220 -->
192.168.0.7:6789/0 -- auth(proto 0 30 bytes epoch 0) v1 -- ?+0 0x22f4310 con
0x22f41d0
2012-01-21 14:24:31.178511 7f7c42244700 -- 192.168.0.6:0/11220 mark_down
0x22f41d0 -- 0x22f3f60
2012-01-21 14:24:31.178582 7f7c42244700 -- 192.168.0.6:0/11220 -->
192.168.0.6:6789/0 -- auth(proto 0 30 bytes epoch 0) v1 -- ?+0 0x22f4310 con
0x22f4a50
2012-01-21 14:24:34.178661 7f7c42244700 -- 192.168.0.6:0/11220 mark_down
0x22f4a50 -- 0x22f47e0
2012-01-21 14:24:34.178729 7f7c42244700 -- 192.168.0.6:0/11220 -->
192.168.0.7:6789/0 -- auth(proto 0 30 bytes epoch 0) v1 -- ?+0 0x22f4310 con
0x22f41d0
2012-01-21 14:24:37.178863 7f7c42244700 -- 192.168.0.6:0/11220 mark_down
0x22f41d0 -- 0x22f3f60
2012-01-21 14:24:37.178928 7f7c42244700 -- 192.168.0.6:0/11220 -->
192.168.0.6:6789/0 -- auth(proto 0 30 bytes epoch 0) v1 -- ?+0 0x22f4310 con
0x22f4a50
2012-01-21 14:24:40.179067 7f7c42244700 -- 192.168.0.6:0/11220 mark_down
0x22f4a50 -- 0x22f47e0
2012-01-21 14:24:40.179156 7f7c42244700 -- 192.168.0.6:0/11220 -->
192.168.0.4:6789/0 -- auth(proto 0 30 bytes epoch 0) v1 -- ?+0 0x22f4b90 con
0x22f4320
2012-01-21 14:24:43.179312 7f7c42244700 -- 192.168.0.6:0/11220 mark_down
0x22f4320 -- 0x22f40b0
2012-01-21 14:24:43.179380 7f7c42244700 -- 192.168.0.6:0/11220 -->
192.168.0.7:6789/0 -- auth(proto 0 30 bytes epoch 0) v1 -- ?+0 0x22f4b90 con
0x22f4a50
2012-01-21 14:24:46.179464 7f7c42244700 -- 192.168.0.6:0/11220 mark_down
0x22f4a50 -- 0x22f47e0
2012-01-21 14:24:46.179533 7f7c42244700 -- 192.168.0.6:0/11220 -->
192.168.0.6:6789/0 -- auth(proto 0 30 bytes epoch 0) v1 -- ?+0 0x22f4b90 con
0x22f41d0
2012-01-21 14:24:49.179671 7f7c42244700 -- 192.168.0.6:0/11220 mark_down
0x22f41d0 -- 0x22f3f60
2012-01-21 14:24:49.179746 7f7c42244700 -- 192.168.0.6:0/11220 -->
192.168.0.5:6789/0 -- auth(proto 0 30 bytes epoch 0) v1 -- ?+0 0x22f4310 con
0x22f4a50
^C*** Caught signal (Interrupt) **
in thread 7f7c45cc0760. Shutting down.
node03:/etc/ceph# rbd ls
2012-01-21 14:25:27.876338 7f80bcf9e760 -- :/0 messenger.start
2012-01-21 14:25:27.876499 7f80bcf9e760 -- :/1011679 --> 192.168.0.4:6789/0 --
auth(proto 0 30 bytes epoch 0) v1 -- ?+0 0xa3c020 con 0xa3bda0
2012-01-21 14:25:27.876787 7f80bcf9d700 -- 192.168.0.6:0/1011679 learned my addr
192.168.0.6:0/1011679
2012-01-21 14:25:30.876586 7f80b9569700 -- 192.168.0.6:0/1011679 mark_down
0xa3bda0 -- 0xa3bb30
2012-01-21 14:25:30.876675 7f80b9569700 -- 192.168.0.6:0/1011679 -->
192.168.0.6:6789/0 -- auth(proto 0 30 bytes epoch 0) v1 -- ?+0 0xa3c020 con 0xa402c0
2012-01-21 14:25:33.876794 7f80b9569700 -- 192.168.0.6:0/1011679 mark_down
0xa402c0 -- 0xa40050
2012-01-21 14:25:33.876871 7f80b9569700 -- 192.168.0.6:0/1011679 -->
192.168.0.7:6789/0 -- auth(proto 0 30 bytes epoch 0) v1 -- ?+0 0xa3bc80 con 0xa3c9f0
2012-01-21 14:25:36.876987 7f80b9569700 -- 192.168.0.6:0/1011679 mark_down
0xa3c9f0 -- 0xa3c780
2012-01-21 14:25:36.877068 7f80b9569700 -- 192.168.0.6:0/1011679 -->
192.168.0.4:6789/0 -- auth(proto 0 30 bytes epoch 0) v1 -- ?+0 0x7f80b40008d0
con 0xa3c290
2012-01-21 14:25:39.877248 7f80b9569700 -- 192.168.0.6:0/1011679 mark_down
0xa3c290 -- 0xa3c020
2012-01-21 14:25:39.877324 7f80b9569700 -- 192.168.0.6:0/1011679 -->
192.168.0.7:6789/0 -- auth(proto 0 30 bytes epoch 0) v1 -- ?+0 0x7f80b4000af0
con 0x7f80b40008b0
2012-01-21 14:25:42.877424 7f80b9569700 -- 192.168.0.6:0/1011679 mark_down
0x7f80b40008b0 -- 0x7f80b4000e00
2012-01-21 14:25:42.877496 7f80b9569700 -- 192.168.0.6:0/1011679 -->
192.168.0.5:6789/0 -- auth(proto 0 30 bytes epoch 0) v1 -- ?+0 0x7f80b4001450
con 0x7f80b4001310
2012-01-21 14:25:45.877624 7f80b9569700 -- 192.168.0.6:0/1011679 mark_down
0x7f80b4001310 -- 0x7f80b4000af0
2012-01-21 14:25:45.877706 7f80b9569700 -- 192.168.0.6:0/1011679 -->
192.168.0.7:6789/0 -- auth(proto 0 30 bytes epoch 0) v1 -- ?+0 0x7f80b40010c0
con 0x7f80b40008b0
2012-01-21 14:25:48.877815 7f80b9569700 -- 192.168.0.6:0/1011679 mark_down
0x7f80b40008b0 -- 0x7f80b4001450
2012-01-21 14:25:48.877889 7f80b9569700 -- 192.168.0.6:0/1011679 -->
192.168.0.5:6789/0 -- auth(proto 0 30 bytes epoch 0) v1 -- ?+0 0x7f80b40010c0
con 0x7f80b40012e0
2012-01-21 14:25:51.877988 7f80b9569700 -- 192.168.0.6:0/1011679 mark_down
0x7f80b40012e0 -- 0x7f80b4000d70
2012-01-21 14:25:51.878060 7f80b9569700 -- 192.168.0.6:0/1011679 -->
192.168.0.7:6789/0 -- auth(proto 0 30 bytes epoch 0) v1 -- ?+0 0x7f80b4000a90
con 0x7f80b4000950
2012-01-21 14:25:54.878187 7f80b9569700 -- 192.168.0.6:0/1011679 mark_down
0x7f80b4000950 -- 0x7f80b4000fe0
2012-01-21 14:25:54.878260 7f80b9569700 -- 192.168.0.6:0/1011679 -->
192.168.0.6:6789/0 -- auth(proto 0 30 bytes epoch 0) v1 -- ?+0 0x7f80b4000a90
con 0x7f80b4000e90
2012-01-21 14:25:57.876601 7f80bcf9e760 monclient(hunting): authenticate timed
out after 30
2012-01-21 14:25:57.876648 7f80bcf9e760 librados: client.admin authentication
error (110) Connection timed out
2012-01-21 14:25:57.876768 7f80bcf9e760 -- 192.168.0.6:0/1011679 shutdown complete.
error: couldn't connect to the cluster!
i am now unable to mount ceph directly as fs, nor access my rbd images.
reverting to 0.39 also does not work, the osds then fail starting claiming that
the filestore does not belong to the osd
Please advise!
--
Mit freundlichen Grüßen,
Florian Wiessner
Smart Weblications GmbH
Martinsberger Str. 1
D-95119 Naila
fon.: +49 9282 9638 200
fax.: +49 9282 9638 205
24/7: +49 900 144 000 00 - 0,99 EUR/Min*
http://www.smart-weblications.de
--
Sitz der Gesellschaft: Naila
Geschäftsführer: Florian Wiessner
HRB-Nr.: HRB 3840 Amtsgericht Hof
*aus dem dt. Festnetz, ggf. abweichende Preise aus dem Mobilfunknetz
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: upgrade from 0.39 to 0.40 failed...
2012-01-21 13:27 upgrade from 0.39 to 0.40 failed Smart Weblications GmbH - Florian Wiessner
@ 2012-01-21 16:25 ` Wido den Hollander
2012-01-21 16:30 ` Smart Weblications GmbH - Florian Wiessner
0 siblings, 1 reply; 9+ messages in thread
From: Wido den Hollander @ 2012-01-21 16:25 UTC (permalink / raw)
To: f.wiessner; +Cc: ceph-devel
Hi,
On 01/21/2012 02:27 PM, Smart Weblications GmbH - Florian Wiessner wrote:
> Hi List,
>
>
> i today upgraded from 0.39 to 0.40 and also from linux 3.1.5 to 3.2.1 and now
> have the following problems:
>
> first of all, i have a 4 node ceph cluster running.
>
> after the kernel upgrade, 2 of 4 osds failed starting because of btrfs-bugs so i
> now only have two osds available ( i set replication level to 3 so the data
> should be save)
>
> i upgraded to
> ceph version 0.40-1-g7ce8b7a (commit:7ce8b7ae3bbad70fe257db00b6fc566f57f17132)
>
> my ceph.conf looks like this:
>
> node03:/etc/ceph# cat ceph.conf
> [global]
> pid file = /var/run/ceph/$name.pid
> debug ms = 1
> # auth supported = cephx
> osd journal = /data/ceph.journal
> osd_journal_size = 512
> # filestore journal writeahead = true
> # filestore journal parallel = true
> mds max = 4
>
> [mon]
> mon data = /data/ceph/mon
> [mon.0]
> host = node01
> mon addr = 192.168.0.4:6789
> [mon.1]
> host = node02
> mon addr = 192.168.0.5:6789
> [mon.2]
> host = node03
> mon addr = 192.168.0.6:6789
> [mon.3]
> host = node04
> mon addr = 192.168.0.7:6789
Although I don't think it is related I'd advise you to switch from
numeric monitor names to alphanumeric names:
mon.alpha
mon.beta
mon.charlie
mon.delta
A while ago this changed, I also think the configuration doesn't even
allow numeric monitors anymore? (correct me if I'm wrong!)
>
> [mds]
> # keyring = /etc/ceph/keyring.$name
> # mds dir max commit size 32
>
> [mds.0]
> host = node01
> [mds.1]
> host = node02
> [mds.2]
> host = node03
> [mds.3]
> host = node04
>
>
> [osd]
> sudo = true
> osd data = /data/ceph/osd
> # keyring = /etc/ceph/keyring.$name
> [osd.0]
> host = node01
> [osd.1]
> host = node02
> [osd.2]
> host = node03
> [osd.3]
> host = node04
>
> i did set up ceph without cephx
When did you enable cephx? Did you do so from the upgrade to 0.39 to
0.40 or earlier?
>
> so now i upgraded to 0.40 and i have this problem:
>
> node03:/etc/ceph# ceph -w
> 2012-01-21 14:24:16.177441 7f7c45cc0760 -- :/0 messenger.start
> 2012-01-21 14:24:16.177628 7f7c45cc0760 -- :/11220 --> 192.168.0.5:6789/0 --
> auth(proto 0 30 bytes epoch 0) v1 -- ?+0 0x22f3f60 con 0x22f3ce0
> 2012-01-21 14:24:16.177926 7f7c45cbf700 -- 192.168.0.6:0/11220 learned my addr
> 192.168.0.6:0/11220
> 2012-01-21 14:24:19.177703 7f7c42244700 -- 192.168.0.6:0/11220 mark_down
> 0x22f3ce0 -- 0x22f3a70
> 2012-01-21 14:24:19.177798 7f7c42244700 -- 192.168.0.6:0/11220 -->
> 192.168.0.6:6789/0 -- auth(proto 0 30 bytes epoch 0) v1 -- ?+0 0x22f3f60 con
> 0x22f51d0
> 2012-01-21 14:24:22.177921 7f7c42244700 -- 192.168.0.6:0/11220 mark_down
> 0x22f51d0 -- 0x22f4f60
> 2012-01-21 14:24:22.177999 7f7c42244700 -- 192.168.0.6:0/11220 -->
> 192.168.0.7:6789/0 -- auth(proto 0 30 bytes epoch 0) v1 -- ?+0 0x22f3f60 con
> 0x22f3ce0
> 2012-01-21 14:24:25.178187 7f7c42244700 -- 192.168.0.6:0/11220 mark_down
> 0x22f3ce0 -- 0x22f3a70
> 2012-01-21 14:24:25.178268 7f7c42244700 -- 192.168.0.6:0/11220 -->
> 192.168.0.6:6789/0 -- auth(proto 0 30 bytes epoch 0) v1 -- ?+0 0x22f3f60 con
> 0x22f4a50
> 2012-01-21 14:24:28.178358 7f7c42244700 -- 192.168.0.6:0/11220 mark_down
> 0x22f4a50 -- 0x22f47e0
> 2012-01-21 14:24:28.178431 7f7c42244700 -- 192.168.0.6:0/11220 -->
> 192.168.0.7:6789/0 -- auth(proto 0 30 bytes epoch 0) v1 -- ?+0 0x22f4310 con
> 0x22f41d0
> 2012-01-21 14:24:31.178511 7f7c42244700 -- 192.168.0.6:0/11220 mark_down
> 0x22f41d0 -- 0x22f3f60
> 2012-01-21 14:24:31.178582 7f7c42244700 -- 192.168.0.6:0/11220 -->
> 192.168.0.6:6789/0 -- auth(proto 0 30 bytes epoch 0) v1 -- ?+0 0x22f4310 con
> 0x22f4a50
> 2012-01-21 14:24:34.178661 7f7c42244700 -- 192.168.0.6:0/11220 mark_down
> 0x22f4a50 -- 0x22f47e0
> 2012-01-21 14:24:34.178729 7f7c42244700 -- 192.168.0.6:0/11220 -->
> 192.168.0.7:6789/0 -- auth(proto 0 30 bytes epoch 0) v1 -- ?+0 0x22f4310 con
> 0x22f41d0
> 2012-01-21 14:24:37.178863 7f7c42244700 -- 192.168.0.6:0/11220 mark_down
> 0x22f41d0 -- 0x22f3f60
> 2012-01-21 14:24:37.178928 7f7c42244700 -- 192.168.0.6:0/11220 -->
> 192.168.0.6:6789/0 -- auth(proto 0 30 bytes epoch 0) v1 -- ?+0 0x22f4310 con
> 0x22f4a50
> 2012-01-21 14:24:40.179067 7f7c42244700 -- 192.168.0.6:0/11220 mark_down
> 0x22f4a50 -- 0x22f47e0
> 2012-01-21 14:24:40.179156 7f7c42244700 -- 192.168.0.6:0/11220 -->
> 192.168.0.4:6789/0 -- auth(proto 0 30 bytes epoch 0) v1 -- ?+0 0x22f4b90 con
> 0x22f4320
> 2012-01-21 14:24:43.179312 7f7c42244700 -- 192.168.0.6:0/11220 mark_down
> 0x22f4320 -- 0x22f40b0
> 2012-01-21 14:24:43.179380 7f7c42244700 -- 192.168.0.6:0/11220 -->
> 192.168.0.7:6789/0 -- auth(proto 0 30 bytes epoch 0) v1 -- ?+0 0x22f4b90 con
> 0x22f4a50
> 2012-01-21 14:24:46.179464 7f7c42244700 -- 192.168.0.6:0/11220 mark_down
> 0x22f4a50 -- 0x22f47e0
> 2012-01-21 14:24:46.179533 7f7c42244700 -- 192.168.0.6:0/11220 -->
> 192.168.0.6:6789/0 -- auth(proto 0 30 bytes epoch 0) v1 -- ?+0 0x22f4b90 con
> 0x22f41d0
> 2012-01-21 14:24:49.179671 7f7c42244700 -- 192.168.0.6:0/11220 mark_down
> 0x22f41d0 -- 0x22f3f60
> 2012-01-21 14:24:49.179746 7f7c42244700 -- 192.168.0.6:0/11220 -->
> 192.168.0.5:6789/0 -- auth(proto 0 30 bytes epoch 0) v1 -- ?+0 0x22f4310 con
> 0x22f4a50
> ^C*** Caught signal (Interrupt) **
> in thread 7f7c45cc0760. Shutting down.
>
>
> node03:/etc/ceph# rbd ls
> 2012-01-21 14:25:27.876338 7f80bcf9e760 -- :/0 messenger.start
> 2012-01-21 14:25:27.876499 7f80bcf9e760 -- :/1011679 --> 192.168.0.4:6789/0 --
> auth(proto 0 30 bytes epoch 0) v1 -- ?+0 0xa3c020 con 0xa3bda0
> 2012-01-21 14:25:27.876787 7f80bcf9d700 -- 192.168.0.6:0/1011679 learned my addr
> 192.168.0.6:0/1011679
> 2012-01-21 14:25:30.876586 7f80b9569700 -- 192.168.0.6:0/1011679 mark_down
> 0xa3bda0 -- 0xa3bb30
> 2012-01-21 14:25:30.876675 7f80b9569700 -- 192.168.0.6:0/1011679 -->
> 192.168.0.6:6789/0 -- auth(proto 0 30 bytes epoch 0) v1 -- ?+0 0xa3c020 con 0xa402c0
> 2012-01-21 14:25:33.876794 7f80b9569700 -- 192.168.0.6:0/1011679 mark_down
> 0xa402c0 -- 0xa40050
> 2012-01-21 14:25:33.876871 7f80b9569700 -- 192.168.0.6:0/1011679 -->
> 192.168.0.7:6789/0 -- auth(proto 0 30 bytes epoch 0) v1 -- ?+0 0xa3bc80 con 0xa3c9f0
> 2012-01-21 14:25:36.876987 7f80b9569700 -- 192.168.0.6:0/1011679 mark_down
> 0xa3c9f0 -- 0xa3c780
> 2012-01-21 14:25:36.877068 7f80b9569700 -- 192.168.0.6:0/1011679 -->
> 192.168.0.4:6789/0 -- auth(proto 0 30 bytes epoch 0) v1 -- ?+0 0x7f80b40008d0
> con 0xa3c290
> 2012-01-21 14:25:39.877248 7f80b9569700 -- 192.168.0.6:0/1011679 mark_down
> 0xa3c290 -- 0xa3c020
> 2012-01-21 14:25:39.877324 7f80b9569700 -- 192.168.0.6:0/1011679 -->
> 192.168.0.7:6789/0 -- auth(proto 0 30 bytes epoch 0) v1 -- ?+0 0x7f80b4000af0
> con 0x7f80b40008b0
> 2012-01-21 14:25:42.877424 7f80b9569700 -- 192.168.0.6:0/1011679 mark_down
> 0x7f80b40008b0 -- 0x7f80b4000e00
> 2012-01-21 14:25:42.877496 7f80b9569700 -- 192.168.0.6:0/1011679 -->
> 192.168.0.5:6789/0 -- auth(proto 0 30 bytes epoch 0) v1 -- ?+0 0x7f80b4001450
> con 0x7f80b4001310
> 2012-01-21 14:25:45.877624 7f80b9569700 -- 192.168.0.6:0/1011679 mark_down
> 0x7f80b4001310 -- 0x7f80b4000af0
> 2012-01-21 14:25:45.877706 7f80b9569700 -- 192.168.0.6:0/1011679 -->
> 192.168.0.7:6789/0 -- auth(proto 0 30 bytes epoch 0) v1 -- ?+0 0x7f80b40010c0
> con 0x7f80b40008b0
> 2012-01-21 14:25:48.877815 7f80b9569700 -- 192.168.0.6:0/1011679 mark_down
> 0x7f80b40008b0 -- 0x7f80b4001450
> 2012-01-21 14:25:48.877889 7f80b9569700 -- 192.168.0.6:0/1011679 -->
> 192.168.0.5:6789/0 -- auth(proto 0 30 bytes epoch 0) v1 -- ?+0 0x7f80b40010c0
> con 0x7f80b40012e0
> 2012-01-21 14:25:51.877988 7f80b9569700 -- 192.168.0.6:0/1011679 mark_down
> 0x7f80b40012e0 -- 0x7f80b4000d70
> 2012-01-21 14:25:51.878060 7f80b9569700 -- 192.168.0.6:0/1011679 -->
> 192.168.0.7:6789/0 -- auth(proto 0 30 bytes epoch 0) v1 -- ?+0 0x7f80b4000a90
> con 0x7f80b4000950
> 2012-01-21 14:25:54.878187 7f80b9569700 -- 192.168.0.6:0/1011679 mark_down
> 0x7f80b4000950 -- 0x7f80b4000fe0
> 2012-01-21 14:25:54.878260 7f80b9569700 -- 192.168.0.6:0/1011679 -->
> 192.168.0.6:6789/0 -- auth(proto 0 30 bytes epoch 0) v1 -- ?+0 0x7f80b4000a90
> con 0x7f80b4000e90
> 2012-01-21 14:25:57.876601 7f80bcf9e760 monclient(hunting): authenticate timed
> out after 30
> 2012-01-21 14:25:57.876648 7f80bcf9e760 librados: client.admin authentication
> error (110) Connection timed out
> 2012-01-21 14:25:57.876768 7f80bcf9e760 -- 192.168.0.6:0/1011679 shutdown complete.
> error: couldn't connect to the cluster!
>
> i am now unable to mount ceph directly as fs, nor access my rbd images.
>
> reverting to 0.39 also does not work, the osds then fail starting claiming that
> the filestore does not belong to the osd
>
> Please advise!
>
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: upgrade from 0.39 to 0.40 failed...
2012-01-21 16:25 ` Wido den Hollander
@ 2012-01-21 16:30 ` Smart Weblications GmbH - Florian Wiessner
2012-01-21 17:01 ` Gregory Farnum
0 siblings, 1 reply; 9+ messages in thread
From: Smart Weblications GmbH - Florian Wiessner @ 2012-01-21 16:30 UTC (permalink / raw)
To: Wido den Hollander; +Cc: ceph-devel
Am 21.01.2012 17:25, schrieb Wido den Hollander:
> Hi,
>
>
> Although I don't think it is related I'd advise you to switch from numeric
> monitor names to alphanumeric names:
>
> A while ago this changed, I also think the configuration doesn't even allow
> numeric monitors anymore? (correct me if I'm wrong!)
>
Well, this config used to work with 0.39 - i did not see any hint in the relase
mail that i have to change something in the config - 0.40 should be mostly a
stabilization release...
I can change the config etc and setup again when i am able to get my data out of
the current installation.
>>
>> i did set up ceph without cephx
>
> When did you enable cephx? Did you do so from the upgrade to 0.39 to 0.40 or
> earlier?
As stated above, i did not set up ceph with authentication. so there was no
authentication used in 0.39 nor in 0.40
But now somehow authentication seems to be enforced - at least that's what i
read from the output that ceph -w gives me...
--
Mit freundlichen Grüßen,
Florian Wiessner
Smart Weblications GmbH
Martinsberger Str. 1
D-95119 Naila
fon.: +49 9282 9638 200
fax.: +49 9282 9638 205
24/7: +49 900 144 000 00 - 0,99 EUR/Min*
http://www.smart-weblications.de
--
Sitz der Gesellschaft: Naila
Geschäftsführer: Florian Wiessner
HRB-Nr.: HRB 3840 Amtsgericht Hof
*aus dem dt. Festnetz, ggf. abweichende Preise aus dem Mobilfunknetz
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: upgrade from 0.39 to 0.40 failed...
2012-01-21 16:30 ` Smart Weblications GmbH - Florian Wiessner
@ 2012-01-21 17:01 ` Gregory Farnum
2012-01-21 17:34 ` Smart Weblications GmbH - Florian Wiessner
2012-01-21 17:43 ` Smart Weblications GmbH - Florian Wiessner
0 siblings, 2 replies; 9+ messages in thread
From: Gregory Farnum @ 2012-01-21 17:01 UTC (permalink / raw)
To: f.wiessner; +Cc: Wido den Hollander, ceph-devel
On Sat, Jan 21, 2012 at 8:30 AM, Smart Weblications GmbH - Florian
Wiessner <f.wiessner@smart-weblications.de> wrote:
> Am 21.01.2012 17:25, schrieb Wido den Hollander:
>> Hi,
>>
>>
>> Although I don't think it is related I'd advise you to switch from numeric
>> monitor names to alphanumeric names:
>>
>> A while ago this changed, I also think the configuration doesn't even allow
>> numeric monitors anymore? (correct me if I'm wrong!)
>>
>
> Well, this config used to work with 0.39 - i did not see any hint in the relase
> mail that i have to change something in the config - 0.40 should be mostly a
> stabilization release...
>
> I can change the config etc and setup again when i am able to get my data out of
> the current installation.
>
>>>
>>> i did set up ceph without cephx
>>
>> When did you enable cephx? Did you do so from the upgrade to 0.39 to 0.40 or
>> earlier?
>
> As stated above, i did not set up ceph with authentication. so there was no
> authentication used in 0.39 nor in 0.40
>
> But now somehow authentication seems to be enforced - at least that's what i
> read from the output that ceph -w gives me...
Actually that might just be a red herring — check the monitor log that
your ceph -w client tried to connect to and see what it says about the
connection attempt. :)
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: upgrade from 0.39 to 0.40 failed...
2012-01-21 17:01 ` Gregory Farnum
@ 2012-01-21 17:34 ` Smart Weblications GmbH - Florian Wiessner
2012-01-21 17:43 ` Smart Weblications GmbH - Florian Wiessner
1 sibling, 0 replies; 9+ messages in thread
From: Smart Weblications GmbH - Florian Wiessner @ 2012-01-21 17:34 UTC (permalink / raw)
To: Gregory Farnum; +Cc: Wido den Hollander, ceph-devel
Hi,
Am 21.01.2012 18:01, schrieb Gregory Farnum:
>>
>> Well, this config used to work with 0.39 - i did not see any hint in the relase
>> mail that i have to change something in the config - 0.40 should be mostly a
>> stabilization release...
>>
>> I can change the config etc and setup again when i am able to get my data out of
>> the current installation.
>>
>>>>
>>>> i did set up ceph without cephx
>>>
>>> When did you enable cephx? Did you do so from the upgrade to 0.39 to 0.40 or
>>> earlier?
>>
>> As stated above, i did not set up ceph with authentication. so there was no
>> authentication used in 0.39 nor in 0.40
>>
>> But now somehow authentication seems to be enforced - at least that's what i
>> read from the output that ceph -w gives me...
>
> Actually that might just be a red herring — check the monitor log that
> your ceph -w client tried to connect to and see what it says about the
> connection attempt. :)
2012-01-21 18:31:04.073997 7f5fb6d08700 -- 192.168.0.4:6789/0 >>
192.168.0.6:6789/0 pipe(0xcf3280 sd=10 pgs=0 cs=0 l=0).connect got BADAUTHORIZER
2012-01-21 18:31:04.074472 7f5fb6d08700 -- 192.168.0.4:6789/0 >>
192.168.0.6:6789/0 pipe(0xcf3280 sd=10 pgs=0 cs=0 l=0).connect got BADAUTHORIZER
2012-01-21 18:31:04.074610 7f5fb6d08700 -- 192.168.0.4:6789/0 >>
192.168.0.6:6789/0 pipe(0xcf3280 sd=10 pgs=0 cs=0 l=0).connect got BADAUTHORIZER
2012-01-21 18:31:04.075132 7f5fb6d08700 -- 192.168.0.4:6789/0 >>
192.168.0.6:6789/0 pipe(0xcf3280 sd=10 pgs=0 cs=0 l=0).connect got BADAUTHORIZER
2012-01-21 18:31:04.075299 7f5fb6d08700 -- 192.168.0.4:6789/0 >>
192.168.0.6:6789/0 pipe(0xcf3280 sd=10 pgs=0 cs=0 l=0).connect got BADAUTHORIZER
2012-01-21 18:31:04.075960 7f5fb6d08700 -- 192.168.0.4:6789/0 >>
192.168.0.6:6789/0 pipe(0xcf3280 sd=10 pgs=0 cs=0 l=0).connect got BADAUTHORIZER
2012-01-21 18:31:04.076097 7f5fb6d08700 -- 192.168.0.4:6789/0 >>
192.168.0.6:6789/0 pipe(0xcf3280 sd=10 pgs=0 cs=0 l=0).connect got BADAUTHORIZER
2012-01-21 18:31:04.076494 7f5fb6d08700 -- 192.168.0.4:6789/0 >>
192.168.0.6:6789/0 pipe(0xcf3280 sd=10 pgs=0 cs=0 l=0).connect got BADAUTHORIZER
2012-01-21 18:31:04.076643 7f5fb6d08700 -- 192.168.0.4:6789/0 >>
192.168.0.6:6789/0 pipe(0xcf3280 sd=10 pgs=0 cs=0 l=0).connect got BADAUTHORIZER
2012-01-21 18:31:04.547643 7f5fb7509700 -- 192.168.0.4:6789/0 --> mon.1
192.168.0.5:6789/0 -- mon_probe(probe 6bac7900-17c9-47c4-8b8e-f3dd7c22c73d name
0) v1 -- ?+0 0xd27000
2012-01-21 18:31:04.547670 7f5fb7509700 -- 192.168.0.4:6789/0 --> mon.2
192.168.0.6:6789/0 -- mon_probe(probe 6bac7900-17c9-47c4-8b8e-f3dd7c22c73d name
0) v1 -- ?+0 0xd26c00
2012-01-21 18:31:04.547682 7f5fb7509700 -- 192.168.0.4:6789/0 --> mon.3
192.168.0.7:6789/0 -- mon_probe(probe 6bac7900-17c9-47c4-8b8e-f3dd7c22c73d name
0) v1 -- ?+0 0xd26900
2012-01-21 18:31:04.737547 7f5fb6601700 -- 192.168.0.4:6789/0 >> :/0
pipe(0xd03a00 sd=13 pgs=0 cs=0 l=0).accept sd=13
2012-01-21 18:31:04.737772 7f5fb6601700 -- 192.168.0.4:6789/0 >>
192.168.0.6:6789/0 pipe(0xd03a00 sd=13 pgs=0 cs=0 l=0).accept connect_seq 0 vs
existing 0 state 1
2012-01-21 18:31:06.547711 7f5fb7509700 -- 192.168.0.4:6789/0 --> mon.1
192.168.0.5:6789/0 -- mon_probe(probe 6bac7900-17c9-47c4-8b8e-f3dd7c22c73d name
0) v1 -- ?+0 0xd26600
2012-01-21 18:31:06.547743 7f5fb7509700 -- 192.168.0.4:6789/0 --> mon.2
192.168.0.6:6789/0 -- mon_probe(probe 6bac7900-17c9-47c4-8b8e-f3dd7c22c73d name
0) v1 -- ?+0 0xd26300
2012-01-21 18:31:06.547755 7f5fb7509700 -- 192.168.0.4:6789/0 --> mon.3
192.168.0.7:6789/0 -- mon_probe(probe 6bac7900-17c9-47c4-8b8e-f3dd7c22c73d name
0) v1 -- ?+0 0xd26000
2012-01-21 18:31:06.737632 7f5fb62fe700 -- 192.168.0.4:6789/0 >> :/0
pipe(0xd03c80 sd=12 pgs=0 cs=0 l=0).accept sd=12
2012-01-21 18:31:06.737863 7f5fb62fe700 -- 192.168.0.4:6789/0 >>
192.168.0.6:6789/0 pipe(0xd03c80 sd=12 pgs=0 cs=0 l=0).accept connect_seq 0 vs
existing 0 state 1
2012-01-21 18:31:08.547765 7f5fb7509700 -- 192.168.0.4:6789/0 --> mon.1
192.168.0.5:6789/0 -- mon_probe(probe 6bac7900-17c9-47c4-8b8e-f3dd7c22c73d name
0) v1 -- ?+0 0xd28c00
2012-01-21 18:31:08.547787 7f5fb7509700 -- 192.168.0.4:6789/0 --> mon.2
192.168.0.6:6789/0 -- mon_probe(probe 6bac7900-17c9-47c4-8b8e-f3dd7c22c73d name
0) v1 -- ?+0 0xd28900
2012-01-21 18:31:08.547799 7f5fb7509700 -- 192.168.0.4:6789/0 --> mon.3
192.168.0.7:6789/0 -- mon_probe(probe 6bac7900-17c9-47c4-8b8e-f3dd7c22c73d name
0) v1 -- ?+0 0xd28600
2012-01-21 18:31:08.737640 7f5fb62fe700 -- 192.168.0.4:6789/0 >> :/0
pipe(0xd03a00 sd=12 pgs=0 cs=0 l=0).accept sd=12
2012-01-21 18:31:08.737872 7f5fb62fe700 -- 192.168.0.4:6789/0 >>
192.168.0.6:6789/0 pipe(0xd03a00 sd=12 pgs=0 cs=0 l=0).accept connect_seq 0 vs
existing 0 state 1
But still no clue what to do...
--
Mit freundlichen Grüßen,
Florian Wiessner
Smart Weblications GmbH
Martinsberger Str. 1
D-95119 Naila
fon.: +49 9282 9638 200
fax.: +49 9282 9638 205
24/7: +49 900 144 000 00 - 0,99 EUR/Min*
http://www.smart-weblications.de
--
Sitz der Gesellschaft: Naila
Geschäftsführer: Florian Wiessner
HRB-Nr.: HRB 3840 Amtsgericht Hof
*aus dem dt. Festnetz, ggf. abweichende Preise aus dem Mobilfunknetz
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: upgrade from 0.39 to 0.40 failed...
2012-01-21 17:01 ` Gregory Farnum
2012-01-21 17:34 ` Smart Weblications GmbH - Florian Wiessner
@ 2012-01-21 17:43 ` Smart Weblications GmbH - Florian Wiessner
2012-01-22 1:19 ` Yehuda Sadeh Weinraub
1 sibling, 1 reply; 9+ messages in thread
From: Smart Weblications GmbH - Florian Wiessner @ 2012-01-21 17:43 UTC (permalink / raw)
To: Gregory Farnum; +Cc: Wido den Hollander, ceph-devel
Am 21.01.2012 18:01, schrieb Gregory Farnum:
>>
>> As stated above, i did not set up ceph with authentication. so there was no
>> authentication used in 0.39 nor in 0.40
>>
>> But now somehow authentication seems to be enforced - at least that's what i
>> read from the output that ceph -w gives me...
>
> Actually that might just be a red herring — check the monitor log that
> your ceph -w client tried to connect to and see what it says about the
> connection attempt. :)
this is what i get on the second running ceph node:
2012-01-21 18:42:34.759225 7f60e6d62700 cephx: verify_authorizer_reply exception
in decode_decrypt with AQAK+RpPWKY9LRAASh86sPjNxkbAa7lZLuPFfQ==
2012-01-21 18:42:34.759245 7f60e6d62700 -- 192.168.0.6:6789/0 >>
192.168.0.4:6789/0 pipe(0xc91500 sd=9 pgs=0 cs=0 l=0).failed verifying authorize
reply
2012-01-21 18:42:36.753924 7f60e11d2700 -- 192.168.0.6:6789/0 >> :/0
pipe(0x1853c80 sd=12 pgs=0 cs=0 l=0).accept sd=12
2012-01-21 18:42:36.754035 7f60e2ee1700 -- 192.168.0.6:6789/0 <== mds.?
192.168.0.6:6800/3222 1 ==== auth(proto 0 26 bytes epoch 0) v1 ==== 56+0+0
(2774746219 0 0) 0x1842e00 con 0x184b280
2012-01-21 18:42:36.758634 7f60e26e0700 -- 192.168.0.6:6789/0 --> mon.0
192.168.0.4:6789/0 -- mon_probe(probe 6bac7900-17c9-47c4-8b8e-f3dd7c22c73d name
2) v1 -- ?+0 0x1850000
2012-01-21 18:42:36.758654 7f60e26e0700 -- 192.168.0.6:6789/0 --> mon.1
192.168.0.5:6789/0 -- mon_probe(probe 6bac7900-17c9-47c4-8b8e-f3dd7c22c73d name
2) v1 -- ?+0 0x184dc00
2012-01-21 18:42:36.758683 7f60e26e0700 -- 192.168.0.6:6789/0 --> mon.3
192.168.0.7:6789/0 -- mon_probe(probe 6bac7900-17c9-47c4-8b8e-f3dd7c22c73d name
2) v1 -- ?+0 0x184d900
2012-01-21 18:42:36.759270 7f60e6d62700 cephx: verify_authorizer_reply exception
in decode_decrypt with AQAM+RpP0JI9LRAAWyy1Flf5X6RUVxEjhAEFtg==
2012-01-21 18:42:36.759287 7f60e6d62700 -- 192.168.0.6:6789/0 >>
192.168.0.4:6789/0 pipe(0xc91500 sd=9 pgs=0 cs=0 l=0).failed verifying authorize
reply
^C
--
Mit freundlichen Grüßen,
Florian Wiessner
Smart Weblications GmbH
Martinsberger Str. 1
D-95119 Naila
fon.: +49 9282 9638 200
fax.: +49 9282 9638 205
24/7: +49 900 144 000 00 - 0,99 EUR/Min*
http://www.smart-weblications.de
--
Sitz der Gesellschaft: Naila
Geschäftsführer: Florian Wiessner
HRB-Nr.: HRB 3840 Amtsgericht Hof
*aus dem dt. Festnetz, ggf. abweichende Preise aus dem Mobilfunknetz
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: upgrade from 0.39 to 0.40 failed...
2012-01-21 17:43 ` Smart Weblications GmbH - Florian Wiessner
@ 2012-01-22 1:19 ` Yehuda Sadeh Weinraub
2012-01-22 12:25 ` Smart Weblications GmbH - Florian Wiessner
0 siblings, 1 reply; 9+ messages in thread
From: Yehuda Sadeh Weinraub @ 2012-01-22 1:19 UTC (permalink / raw)
To: f.wiessner; +Cc: Gregory Farnum, Wido den Hollander, ceph-devel
On Sat, Jan 21, 2012 at 9:43 AM, Smart Weblications GmbH - Florian
Wiessner <f.wiessner@smart-weblications.de> wrote:
>
> Am 21.01.2012 18:01, schrieb Gregory Farnum:
> >>
> >> As stated above, i did not set up ceph with authentication. so there was no
> >> authentication used in 0.39 nor in 0.40
> >>
> >> But now somehow authentication seems to be enforced - at least that's what i
> >> read from the output that ceph -w gives me...
> >
> > Actually that might just be a red herring — check the monitor log that
> > your ceph -w client tried to connect to and see what it says about the
> > connection attempt. :)
>
> this is what i get on the second running ceph node:
>
> 2012-01-21 18:42:34.759225 7f60e6d62700 cephx: verify_authorizer_reply exception
> in decode_decrypt with AQAK+RpPWKY9LRAASh86sPjNxkbAa7lZLuPFfQ==
> 2012-01-21 18:42:34.759245 7f60e6d62700 -- 192.168.0.6:6789/0 >>
> 192.168.0.4:6789/0 pipe(0xc91500 sd=9 pgs=0 cs=0 l=0).failed verifying authorize
> reply
> 2012-01-21 18:42:36.753924 7f60e11d2700 -- 192.168.0.6:6789/0 >> :/0
> pipe(0x1853c80 sd=12 pgs=0 cs=0 l=0).accept sd=12
> 2012-01-21 18:42:36.754035 7f60e2ee1700 -- 192.168.0.6:6789/0 <== mds.?
> 192.168.0.6:6800/3222 1 ==== auth(proto 0 26 bytes epoch 0) v1 ==== 56+0+0
> (2774746219 0 0) 0x1842e00 con 0x184b280
> 2012-01-21 18:42:36.758634 7f60e26e0700 -- 192.168.0.6:6789/0 --> mon.0
> 192.168.0.4:6789/0 -- mon_probe(probe 6bac7900-17c9-47c4-8b8e-f3dd7c22c73d name
> 2) v1 -- ?+0 0x1850000
> 2012-01-21 18:42:36.758654 7f60e26e0700 -- 192.168.0.6:6789/0 --> mon.1
> 192.168.0.5:6789/0 -- mon_probe(probe 6bac7900-17c9-47c4-8b8e-f3dd7c22c73d name
> 2) v1 -- ?+0 0x184dc00
> 2012-01-21 18:42:36.758683 7f60e26e0700 -- 192.168.0.6:6789/0 --> mon.3
> 192.168.0.7:6789/0 -- mon_probe(probe 6bac7900-17c9-47c4-8b8e-f3dd7c22c73d name
> 2) v1 -- ?+0 0x184d900
> 2012-01-21 18:42:36.759270 7f60e6d62700 cephx: verify_authorizer_reply exception
> in decode_decrypt with AQAM+RpP0JI9LRAAWyy1Flf5X6RUVxEjhAEFtg==
> 2012-01-21 18:42:36.759287 7f60e6d62700 -- 192.168.0.6:6789/0 >>
> 192.168.0.4:6789/0 pipe(0xc91500 sd=9 pgs=0 cs=0 l=0).failed verifying authorize
> reply
> ^C
>
>
Can you verify that there's no 'auth supported' line in your mon ceph.conf?
Also, try running (with correct <ceph.conf>):
# ceph-conf --lookup -c <ceph.conf> 'auth supported' --name mon.2
or just:
# ceph-conf --lookup -c <ceph.conf> 'auth supported'
and you can also try adding 'auth supported = none' in your ceph.conf.
Yehuda
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: upgrade from 0.39 to 0.40 failed...
2012-01-22 1:19 ` Yehuda Sadeh Weinraub
@ 2012-01-22 12:25 ` Smart Weblications GmbH - Florian Wiessner
2012-01-23 18:44 ` Gregory Farnum
0 siblings, 1 reply; 9+ messages in thread
From: Smart Weblications GmbH - Florian Wiessner @ 2012-01-22 12:25 UTC (permalink / raw)
To: Yehuda Sadeh Weinraub; +Cc: Gregory Farnum, Wido den Hollander, ceph-devel
Am 22.01.2012 02:19, schrieb Yehuda Sadeh Weinraub:
> On Sat, Jan 21, 2012 at 9:43 AM, Smart Weblications GmbH - Florian
> Wiessner <f.wiessner@smart-weblications.de> wrote:
>>
>> 2) v1 -- ?+0 0x184dc00
>> 2012-01-21 18:42:36.758683 7f60e26e0700 -- 192.168.0.6:6789/0 --> mon.3
>> 192.168.0.7:6789/0 -- mon_probe(probe 6bac7900-17c9-47c4-8b8e-f3dd7c22c73d name
>> 2) v1 -- ?+0 0x184d900
>> 2012-01-21 18:42:36.759270 7f60e6d62700 cephx: verify_authorizer_reply exception
>> in decode_decrypt with AQAM+RpP0JI9LRAAWyy1Flf5X6RUVxEjhAEFtg==
>> 2012-01-21 18:42:36.759287 7f60e6d62700 -- 192.168.0.6:6789/0 >>
>> 192.168.0.4:6789/0 pipe(0xc91500 sd=9 pgs=0 cs=0 l=0).failed verifying authorize
>> reply
>> ^C
>>
>>
> Can you verify that there's no 'auth supported' line in your mon ceph.conf?
>
> Also, try running (with correct <ceph.conf>):
>
> # ceph-conf --lookup -c <ceph.conf> 'auth supported' --name mon.2
>
> or just:
>
> # ceph-conf --lookup -c <ceph.conf> 'auth supported'
node04:/tmp# ceph-conf --lookup -c /etc/ceph/ceph.conf 'auth supported' --name mon.2
none
node04:/tmp# ceph-conf --lookup -c /etc/ceph/ceph.conf 'auth supported' --name mon.0
none
i now explicitly set auth supported = none, but still it is not working :(
--
Mit freundlichen Grüßen,
Florian Wiessner
Smart Weblications GmbH
Martinsberger Str. 1
D-95119 Naila
fon.: +49 9282 9638 200
fax.: +49 9282 9638 205
24/7: +49 900 144 000 00 - 0,99 EUR/Min*
http://www.smart-weblications.de
--
Sitz der Gesellschaft: Naila
Geschäftsführer: Florian Wiessner
HRB-Nr.: HRB 3840 Amtsgericht Hof
*aus dem dt. Festnetz, ggf. abweichende Preise aus dem Mobilfunknetz
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: upgrade from 0.39 to 0.40 failed...
2012-01-22 12:25 ` Smart Weblications GmbH - Florian Wiessner
@ 2012-01-23 18:44 ` Gregory Farnum
0 siblings, 0 replies; 9+ messages in thread
From: Gregory Farnum @ 2012-01-23 18:44 UTC (permalink / raw)
To: f.wiessner; +Cc: Yehuda Sadeh Weinraub, Wido den Hollander, ceph-devel
On Sun, Jan 22, 2012 at 4:25 AM, Smart Weblications GmbH - Florian
Wiessner <f.wiessner@smart-weblications.de> wrote:
> Am 22.01.2012 02:19, schrieb Yehuda Sadeh Weinraub:
>> On Sat, Jan 21, 2012 at 9:43 AM, Smart Weblications GmbH - Florian
>> Wiessner <f.wiessner@smart-weblications.de> wrote:
>>>
>>> 2) v1 -- ?+0 0x184dc00
>>> 2012-01-21 18:42:36.758683 7f60e26e0700 -- 192.168.0.6:6789/0 --> mon.3
>>> 192.168.0.7:6789/0 -- mon_probe(probe 6bac7900-17c9-47c4-8b8e-f3dd7c22c73d name
>>> 2) v1 -- ?+0 0x184d900
>>> 2012-01-21 18:42:36.759270 7f60e6d62700 cephx: verify_authorizer_reply exception
>>> in decode_decrypt with AQAM+RpP0JI9LRAAWyy1Flf5X6RUVxEjhAEFtg==
>>> 2012-01-21 18:42:36.759287 7f60e6d62700 -- 192.168.0.6:6789/0 >>
>>> 192.168.0.4:6789/0 pipe(0xc91500 sd=9 pgs=0 cs=0 l=0).failed verifying authorize
>>> reply
>>> ^C
>>>
>>>
>> Can you verify that there's no 'auth supported' line in your mon ceph.conf?
>>
>> Also, try running (with correct <ceph.conf>):
>>
>> # ceph-conf --lookup -c <ceph.conf> 'auth supported' --name mon.2
>>
>> or just:
>>
>> # ceph-conf --lookup -c <ceph.conf> 'auth supported'
> node04:/tmp# ceph-conf --lookup -c /etc/ceph/ceph.conf 'auth supported' --name mon.2
> none
> node04:/tmp# ceph-conf --lookup -c /etc/ceph/ceph.conf 'auth supported' --name mon.0
> none
>
>
> i now explicitly set auth supported = none, but still it is not working :(
Have you previously used cephx? I notice that it was a commented-out
line in your initial conf. :) I tried to reproduce quickly by creating
a v0.39 system and upgrading to v0.40 and didn't see any trouble.
Otherwise we'll need to start generating very explicit logs and stuff.
-Greg
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2012-01-23 18:44 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-01-21 13:27 upgrade from 0.39 to 0.40 failed Smart Weblications GmbH - Florian Wiessner
2012-01-21 16:25 ` Wido den Hollander
2012-01-21 16:30 ` Smart Weblications GmbH - Florian Wiessner
2012-01-21 17:01 ` Gregory Farnum
2012-01-21 17:34 ` Smart Weblications GmbH - Florian Wiessner
2012-01-21 17:43 ` Smart Weblications GmbH - Florian Wiessner
2012-01-22 1:19 ` Yehuda Sadeh Weinraub
2012-01-22 12:25 ` Smart Weblications GmbH - Florian Wiessner
2012-01-23 18:44 ` Gregory Farnum
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.