Re: [libvirt] [PATCH v5 4/4] qemu/rbd: improve rbd device specification
On Tue, Nov 15, 2011 at 05:05:27PM -0700, Eric Blake wrote:
On 10/31/2011 07:29 PM, Josh Durgin wrote:
From: Sage Weil s...@newdream.net
+if (sec) {
+char *base64 = NULL;
+
+secret = (char *)conn-secretDriver-getValue(sec,
secret_size, 0,
+
VIR_SECRET_GET_VALUE_INTERNAL_CALL);
+if (secret == NULL) {
+qemuReportError(VIR_ERR_INTERNAL_ERROR,
+_(could not get the value of the secret
for username %s),
+disk-auth.username);
+goto error;
+}
+/* qemu/librbd wants it base64 encoded */
+base64_encode_alloc(secret, secret_size, base64);
+if (!base64) {
+virReportOOMError();
+goto error;
+}
+virBufferEscape(opt, :, :key=%s:auth_supported=cephx none,
+base64);
+VIR_FREE(base64);
The command line that we pass to qemu gets logged. But what happens if
the secret was marked as ephemeral - could we be violating the premise
of not exposing passwords to too broad an audience? Or are we already
safe in that the log entries created by virCommand can only be exposed
to users that already can get at the secret information by other means?
Maybe this means we should we be adding capabilities into virCommand to
prevent the logging of the actual secret (whether base64-encoded or
otherwise), and instead log an alternate string? That is, should
virCommand be tracking parallel argv arrays; the real array passed to
exec() but never logged, and the alternate array (normally matching the
real one, but which can differ in this particular case of passing an
argument that contains a password)?
The passing of secrets on the command line is just a temporary hack
we're doing to prove the overall handling of passwords for Ceph. The
real plan is to set them via monitor command in QEMU, but we're just
waiting for some QEMU work before changing libvirt todo that.
Daniel
--
|: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
--
To unsubscribe from this list: send the line unsubscribe ceph-devel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Assert in OSDMap::Incremental::decode with recent git
Gregory Farnum wrote: On Tue, Nov 15, 2011 at 3:55 AM, Christoph Hellwig h...@infradead.org wrote: I hit the same when trying to bring up a test cluster on a single physical machine. As soon as moved to vstart.sh I couldn't reproduce it anymore. Hmm, interesting that it doesn't happen on vstart, since that's supposed to use the new mon bootstrapping pieces as well. Josh, can you turn up monitor debugging and send me the log/post it somewhere? Presumably the big refactor Sage referred to broke something here. http://joshp.no-ip.com:8080/2016-ceph-mon.2.log I've inlined a snippet from the end. -Josh 2011-11-16 06:07:13.828322 7fce87736700 -- 192.168.122.74:6789/0 == mon.0 192.168.122.95:6789/0 30 paxos(osdmap lease lc 144 fc 142 pn 0 opn 0) v1 84+0+0 (3125715891 0 0) 0x17f2900 con 0x1735780 2011-11-16 06:07:13.828329 7fce87736700 mon.2@2(peon) e1 have connection 2011-11-16 06:07:13.828336 7fce87736700 mon.2@2(peon) e1 ms_dispatch existing session MonSession: mon.0 192.168.122.95:6789/0 is openallow * for mon.0 192.168.122.95:6789/0 2011-11-16 06:07:13.828340 7fce87736700 mon.2@2(peon) e1 caps allow * 2011-11-16 06:07:13.828347 7fce87736700 mon.2@2(peon).paxos(osdmap active c 141..144) handle_lease on 144 now 2011-11-16 06:07:17.183529 2011-11-16 06:07:13.828356 7fce87736700 -- 192.168.122.74:6789/0 -- mon.0 192.168.122.95:6789/0 -- paxos(osdmap lease_ack lc 144 fc 141 pn 0 opn 0) v1 -- ?+0 0x17f2b40 2011-11-16 06:07:13.828471 7fce87736700 mon.2@2(peon).paxos(osdmap active c 141..144) trim_to 142 (was 141), latest_stashed 141 2011-11-16 06:07:13.828485 7fce87736700 store(/data/mon2) set_int osdmap/first_committed = 141 2011-11-16 06:07:14.126377 7fce86431700 mon.2@2(peon) e1 ms_verify_authorizer 192.168.122.1:0/1024415 client protocol 0 2011-11-16 06:07:18.370639 7fce87736700 mon.2@2(peon).paxosservice(osdmap) _active 2011-11-16 06:07:18.370657 7fce87736700 mon.2@2(peon).osd e130 update_from_paxos paxos e 144, my e 130 2011-11-16 06:07:18.370691 7fce87736700 store(/data/mon2) get_bl osdmap/131 No such file or directory 2011-11-16 06:07:18.370698 7fce87736700 mon.2@2(peon).osd e130 update_from_paxos applying incremental 131 *** Caught signal (Aborted) ** in thread 7fce87736700 ceph version 0.38-181-g2e19550 (commit:2e195500b5d3a8ab8512bcf2a219a6b7ff922c97) 1: /usr/bin/ceph-mon() [0x5c2fa6] 2: (()+0x10060) [0x7fce8b209060] 3: (gsignal()+0x35) [0x7fce8998a3a5] 4: (abort()+0x17b) [0x7fce8998db0b] 5: (__gnu_cxx::__verbose_terminate_handler()+0x11d) [0x7fce8a248d7d] 6: (()+0xb9f26) [0x7fce8a246f26] 7: (()+0xb9f53) [0x7fce8a246f53] 8: (()+0xba04e) [0x7fce8a24704e] 9: (ceph::buffer::list::iterator::copy(unsigned int, char*)+0x127) [0x596237] 10: (OSDMap::Incremental::decode(ceph::buffer::list::iterator)+0x3f) [0x573b6f] 11: (OSDMonitor::update_from_paxos()+0x7b0) [0x49a9c0] 12: (PaxosService::_active()+0x39) [0x4933f9] 13: (Context::complete(int)+0xa) [0x47c12a] 14: (finish_contexts(CephContext*, std::listContext*, std::allocatorContext* , int)+0xca) [0x47da8a] 15: (Paxos::handle_lease(MMonPaxos*)+0x36d) [0x48aafd] 16: (Paxos::dispatch(PaxosServiceMessage*)+0x21b) [0x48f4db] 17: (Monitor::_ms_dispatch(Message*)+0xcbf) [0x47b66f] 18: (Monitor::ms_dispatch(Message*)+0x35) [0x486425] 19: (SimpleMessenger::dispatch_entry()+0x84b) [0x583e8b] 20: (SimpleMessenger::DispatchThread::entry()+0x1c) [0x46612c] 21: (()+0x7efc) [0x7fce8b200efc] 22: (clone()+0x6d) [0x7fce89a3589d] -- To unsubscribe from this list: send the line unsubscribe ceph-devel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/4] qemu/rbd: improve rbd device specification
On 11/15/2011 06:37 PM, Josh Durgin wrote: The command line that we pass to qemu gets logged. But what happens if the secret was marked as ephemeral - could we be violating the premise of not exposing passwords to too broad an audience? Or are we already safe in that the log entries created by virCommand can only be exposed to users that already can get at the secret information by other means? The secret can be read from the command line of the running process, which is even less secure than the log. I'm working on passing the secret via the qemu monitor instead of the command line, which will avoid both issues. Maybe this means we should we be adding capabilities into virCommand to prevent the logging of the actual secret (whether base64-encoded or otherwise), and instead log an alternate string? That is, should virCommand be tracking parallel argv arrays; the real array passed to exec() but never logged, and the alternate array (normally matching the real one, but which can differ in this particular case of passing an argument that contains a password)? Given your arguments (that ps can read argv of qemu, even if we hid it from libvirt logs, and that we will be moving to a monitor command as soon as qemu supports one), I see no reason to hack up virCommand to support alternate log output. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: rbd format check
On Tue, 15 Nov 2011, Josh Durgin wrote: I added a simple check for the old version in the wip-rbd-layering branch of ceph and ceph-client.git. If that looks good and you want to push it upstream, maybe grab the rollback removal from wip-rollback as well. On the librbd side, let's add a dout(0 or 1) so that we can figure out why things are failing. Ideally we could use a distinct error code too so that the tools can report an appropriate error message, altho looking at errno-base.h nothing looks like an obvious choice. For the kernel code, a pr_info or pr_warn would be good so that something useful up on the console. And again, a distinct error code would be nice so that 'rbd map ...' can print something helpful to stderr... sage -- To unsubscribe from this list: send the line unsubscribe ceph-devel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rbd format check
On 11/16/2011 10:40 AM, Sage Weil wrote: On Tue, 15 Nov 2011, Josh Durgin wrote: I added a simple check for the old version in the wip-rbd-layering branch of ceph and ceph-client.git. If that looks good and you want to push it upstream, maybe grab the rollback removal from wip-rollback as well. On the librbd side, let's add a dout(0 or 1) so that we can figure out why things are failing. Ideally we could use a distinct error code too so that the tools can report an appropriate error message, altho looking at errno-base.h nothing looks like an obvious choice. I looked through errno.h as well and didn't see anything that fit very well. Anyone have a suggestion? The ones that seem closest are EBADMSG or EMEDIUMTYPE. Also, the dout(0) errors don't seem to be printed unless you add the --err-to-stderr (or stronger) flags. Shouldn't printing errors be the default? For the kernel code, a pr_info or pr_warn would be good so that something useful up on the console. And again, a distinct error code would be nice so that 'rbd map ...' can print something helpful to stderr... sage -- To unsubscribe from this list: send the line unsubscribe ceph-devel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rbd format check
On Wed, 16 Nov 2011, Josh Durgin wrote: On 11/16/2011 10:40 AM, Sage Weil wrote: On Tue, 15 Nov 2011, Josh Durgin wrote: I added a simple check for the old version in the wip-rbd-layering branch of ceph and ceph-client.git. If that looks good and you want to push it upstream, maybe grab the rollback removal from wip-rollback as well. On the librbd side, let's add a dout(0 or 1) so that we can figure out why things are failing. Ideally we could use a distinct error code too so that the tools can report an appropriate error message, altho looking at errno-base.h nothing looks like an obvious choice. I looked through errno.h as well and didn't see anything that fit very well. Anyone have a suggestion? The ones that seem closest are EBADMSG or EMEDIUMTYPE. Also, the dout(0) errors don't seem to be printed unless you add the --err-to-stderr (or stronger) flags. Shouldn't printing errors be the default? Hmm, err_to_stderr should default to true... although that is probably a bad thing for librbd! Maybe #define ENOEXEC 8 /* Exec format error */ ? sage -- To unsubscribe from this list: send the line unsubscribe ceph-devel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
When upgrading or installing we do not want to stop or start the init scripts. This could break upgrades but also do harmfull stuff we don't want. Let the sysadmin decide when to (re)start the daemons -- To unsubscribe from this list: send the line unsubscribe ceph-devel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] debian init: Do not stop or start daemons when installing or upgrading
Signed-off-by: Wido den Hollander w...@widodh.nl --- debian/rules |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/debian/rules b/debian/rules index a20258d..4f3fe62 100755 --- a/debian/rules +++ b/debian/rules @@ -98,7 +98,7 @@ binary-arch: build install dh_installexamples dh_install --sourcedir=$(DESTDIR) --list-missing dh_installlogrotate - dh_installinit + dh_installinit --no-start dh_installman dh_lintian dh_link -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe ceph-devel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] debian init: Do not stop or start daemons when installing or upgrading
Ooh, that would certainly make things less annoying for me as well. Unless that's contrary to some debian policy/best practice, Laszlo? sage On Wed, 16 Nov 2011, Wido den Hollander wrote: Signed-off-by: Wido den Hollander w...@widodh.nl --- debian/rules |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/debian/rules b/debian/rules index a20258d..4f3fe62 100755 --- a/debian/rules +++ b/debian/rules @@ -98,7 +98,7 @@ binary-arch: build install dh_installexamples dh_install --sourcedir=$(DESTDIR) --list-missing dh_installlogrotate - dh_installinit + dh_installinit --no-start dh_installman dh_lintian dh_link -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe ceph-devel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe ceph-devel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] debian init: Do not stop or start daemons when installing or upgrading
On 11/16/2011 08:53 PM, Sage Weil wrote: Ooh, that would certainly make things less annoying for me as well. Unless that's contrary to some debian policy/best practice, Laszlo? We could also go for --no-restart-on-upgrade. I ran into this when upgrading the debs on my machines. The init script would try to stop any running radosgw processes, that failed (none were running), exited non-zero and that broke the prerm script. But since we are dealing with potentially very important daemons I don't want any init scripts restarting my daemons, I want to do that myself. Wido sage On Wed, 16 Nov 2011, Wido den Hollander wrote: Signed-off-by: Wido den Hollanderw...@widodh.nl --- debian/rules |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/debian/rules b/debian/rules index a20258d..4f3fe62 100755 --- a/debian/rules +++ b/debian/rules @@ -98,7 +98,7 @@ binary-arch: build install dh_installexamples dh_install --sourcedir=$(DESTDIR) --list-missing dh_installlogrotate - dh_installinit + dh_installinit --no-start dh_installman dh_lintian dh_link -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe ceph-devel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe ceph-devel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
phprados update
Hi, Some time ago the API of librados changed thus breaking phprados. I tried implementing the C++ API of librados in PHP but I got pretty stuck there with the new IoCTX stuff. So I went to the C API and started implementing a C-only phprados with just using the C functions. I just finished with implementing most of the librados functionality, this includes: * Connecting * Creating and removing pools * Object handling like write and read * Xattr handling * Snapshot handling I stayed away from the rados tmap's, exec and async writes for now, since I don't think a lot of PHP users will be using that functionality (yet). My next steps are to hunt down some bugs and start writing a Object based version in PHP, but I'll be using the internal object methods of PHP for this while calling the C functions of librados in the background. This way I can create a RADOS object in PHP which meets the standard of what PHP users are used to. For example: It is not common in PHP to define the number of bytes you want to read when retrieving the value of a xattr, PHP should figure that out for you. Any comments or suggestions on this? phprados can be found at: http://www.widodh.nl/git/phprados.git Further down the road I'll upload some tar archives as well. Wido -- To unsubscribe from this list: send the line unsubscribe ceph-devel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rbd format check
On 11/16/2011 11:10 AM, Sage Weil wrote: On Wed, 16 Nov 2011, Josh Durgin wrote: On 11/16/2011 10:40 AM, Sage Weil wrote: On Tue, 15 Nov 2011, Josh Durgin wrote: I added a simple check for the old version in the wip-rbd-layering branch of ceph and ceph-client.git. If that looks good and you want to push it upstream, maybe grab the rollback removal from wip-rollback as well. On the librbd side, let's add a dout(0 or 1) so that we can figure out why things are failing. Ideally we could use a distinct error code too so that the tools can report an appropriate error message, altho looking at errno-base.h nothing looks like an obvious choice. I looked through errno.h as well and didn't see anything that fit very well. Anyone have a suggestion? The ones that seem closest are EBADMSG or EMEDIUMTYPE. Also, the dout(0) errors don't seem to be printed unless you add the --err-to-stderr (or stronger) flags. Shouldn't printing errors be the default? Hmm, err_to_stderr should default to true... although that is probably a bad thing for librbd! Maybe #define ENOEXEC 8 /* Exec format error */ ? I went with ENXIO - from POSIX.1: No such device or address. Input or output on a special file refers to a device that does not exist, or makes a request beyond the capabilities of the device. It may also occur when, for example, a tape drive is not on-line. -- To unsubscribe from this list: send the line unsubscribe ceph-devel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
