Re: [Spice-devel] spice-gtk http connect proxy authentification ?
Open a bug? Send a patch? :) Thanks, I'll try to make a patch. As workaround for now, I'm using host value as ticket, with encoded user,pass,host. (As I'm using custom http proxy, I can decode them) - Mail original - De: Marc-André Lureau mlur...@redhat.com À: Alexandre DERUMIER aderum...@odiso.com Cc: spice-devel spice-devel@lists.freedesktop.org Envoyé: Mercredi 17 Juillet 2013 12:27:09 Objet: Re: [Spice-devel] spice-gtk http connect proxy authentification ? Hi - Mensaje original - Hi, I would like to known if it's planned to add authentification to http spice_proxy soon ? It wasn't planned so far. I think It should be easy, we just need to be able to parse a proxy url like this http://username:password@host:port then replace in spice-session.c address = g_proxy_address_new(G_INET_ADDRESS(it-data), pport, http, + s-host, port, NULL, NULL); by address = g_proxy_address_new(G_INET_ADDRESS(it-data), pport, http, + s-host, port, username, password); Open a bug? Send a patch? :) thanks ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] seamless spice migration : question about password/ticket for target vm
Hi, I'm trying to do migration, and I have a question about password on target vm. If I understand, client try to connect to target vm with same password (temporary ticket) used to connect to source vm. But, we need to configure this password to target vm, as I think that qemu migration process don't copy the password between both spice server right ? So we need to store this password somewhere on the host, which seem to be bad for security. (Seem that libvirt store it in guest config xml) Is it possible to generate a new ticket for target vm, and send it to the client ? (I don't see any option in qmp client_migrate_info ) Best Regards, Alexandre ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] remote-viewer: tls seamless migration : CA option is not keep
Hi - Mensaje original - Hi, I'm trying to do seamless migration of a qemu guest, using only tls for spice client. Client is remote-viewer, and is launched through a config file with the ca certificate embedded like this [virt-viewer] type=spice ca=BEGIN CERTIFICATE--\n\nEND CERTIFICATE\n tls-port= ... This works fine for establish the connection to spice server, but when I'm doing a seamless migration, the ca is not reused and remote-viewer give me (remote-viewer:25533): GSpice-WARNING **: no cert loaded Workaround is to copy the cerficate in .spicec/spice_truststore.pem, But I would like to avoid to do this. Is it a bug ? or does exist some option to force remote-viewer to auto write the ca=... inside the spice_truststore.pem ? It looks like a bug, I think we should copy the ca when creating the migration session. Can you try the attached patch (not tested)? thanks From cf6275a6ef2b450220302ad112157c25a7006402 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= marcandre.lur...@redhat.com Date: Mon, 22 Jul 2013 15:07:55 +0200 Subject: [PATCH spice-gtk] session: copy ca property in copy ctor This should fix the GSpice-WARNING **: no cert loaded, when doing a seamless migration (when using the ca property). --- gtk/spice-session.c | 1 + 1 file changed, 1 insertion(+) diff --git a/gtk/spice-session.c b/gtk/spice-session.c index 8cb2d39..a9435f4 100644 --- a/gtk/spice-session.c +++ b/gtk/spice-session.c @@ -1251,6 +1251,7 @@ SpiceSession *spice_session_new_from_session(SpiceSession *session) enable-smartcard, c-smartcard, enable-audio, c-audio, enable-usbredir, c-usbredir, + ca, c-ca, NULL); c-client_provided_sockets = s-client_provided_sockets; -- 1.8.3.rc1.49.g8d97506 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] seamless spice migration : question about password/ticket for target vm
Hi, On 07/22/2013 08:04 AM, Alexandre DERUMIER wrote: Hi, I'm trying to do migration, and I have a question about password on target vm. If I understand, client try to connect to target vm with same password (temporary ticket) used to connect to source vm. But, we need to configure this password to target vm, as I think that qemu migration process don't copy the password between both spice server right ? So we need to store this password somewhere on the host, which seem to be bad for security. (Seem that libvirt store it in guest config xml) ovirt's vdsm sets to the destination host the same ticket that was set upon the original connection. Is it possible to generate a new ticket for target vm, and send it to the client ? (I don't see any option in qmp client_migrate_info ) I don't think there is a way to do it without changing client_migrate_info and the protocol. Even if we would have a password option in client_migrate_info, I don't know if libvirt can retrieve this information. Regards, Yonit. Best Regards, Alexandre ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] seamless spice migration : question about password/ticket for target vm
Hi - Mensaje original - Hi, On 07/22/2013 08:04 AM, Alexandre DERUMIER wrote: Hi, I'm trying to do migration, and I have a question about password on target vm. If I understand, client try to connect to target vm with same password (temporary ticket) used to connect to source vm. But, we need to configure this password to target vm, as I think that qemu migration process don't copy the password between both spice server right ? So we need to store this password somewhere on the host, which seem to be bad for security. (Seem that libvirt store it in guest config xml) ovirt's vdsm sets to the destination host the same ticket that was set upon the original connection. Is it possible to generate a new ticket for target vm, and send it to the client ? (I don't see any option in qmp client_migrate_info ) I don't think there is a way to do it without changing client_migrate_info and the protocol. Even if we would have a password option in client_migrate_info, I don't know if libvirt can retrieve this information. So upon migration, libvirt/ovirt will set the dest VM with the same old password? That sounds sane to me in general, but looks kinda against an expiry-based ticket. It would be worth asking the ovirt folks. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [(spice) PATCHv2 RFC 2/2] TIOCOUTQ - SIOCOUTQ and portability ifdefs
Ack.
The ping is sent over the display channel to check an upper limit for
the roundtrip time. If the tcp stack is busy, we postpone the ping.
So, without the ioctl, when the tcp stack is busy, the roundtrip
estimation will probably be much bigger than the real one. However, we
currently take the minimum out of all the pings.
Another option is to disable the pings (set monitor_latency to FALSE
when creating the display channel inside red_worker). In this case, the
latency estimation will be fetched from the main channel (derived from
one ping msg that is transmitted upon client connection).
Cheers,
Yonit.
On 07/18/2013 02:07 PM, Nahum Shalman wrote:
The ioctl on sockets is actually named SIOCOUTQ though its value
is identical to TIOCOUTQ which is for terminals.
SIOCOUTQ is linux specific so we add a header check and ifdef based
on the presence of the header
This prevents bogus ioctls on non-Linux platforms
---
configure.ac |1 +
server/red_channel.c | 13 +++--
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index a549ed9..fa1ba31 100644
--- a/configure.ac
+++ b/configure.ac
@@ -51,6 +51,7 @@ PKG_PROG_PKG_CONFIG
AC_CHECK_HEADERS([sys/time.h])
AC_CHECK_HEADERS([execinfo.h])
+AC_CHECK_HEADERS([linux/sockios.h])
AC_FUNC_ALLOCA
AC_DEFINE([__STDC_FORMAT_MACROS],[],[Force definition of format macros for
C++])
diff --git a/server/red_channel.c b/server/red_channel.c
index 85d7ebc..31c991b 100644
--- a/server/red_channel.c
+++ b/server/red_channel.c
@@ -30,6 +30,9 @@
#include unistd.h
#include errno.h
#include sys/ioctl.h
+#ifdef HAVE_LINUX_SOCKIOS_H
+#include linux/sockios.h /* SIOCOUTQ */
+#endif
#include common/generated_server_marshallers.h
#include common/ring.h
@@ -722,9 +725,11 @@ static void red_channel_client_ping_timer(void *opaque)
spice_assert(rcc-latency_monitor.state == PING_STATE_TIMER);
red_channel_client_cancel_ping_timer(rcc);
+
+#ifdef HAVE_LINUX_SOCKIOS_H /* SIOCOUTQ is a Linux only ioctl on sockets. */
/* retrieving the occupied size of the socket's tcp snd buffer (unacked +
unsent) */
-if (ioctl(rcc-stream-socket, TIOCOUTQ, so_unsent_size) == -1) {
-spice_printerr(ioctl(TIOCOUTQ) failed, %s, strerror(errno));
+if (ioctl(rcc-stream-socket, SIOCOUTQ, so_unsent_size) == -1) {
+spice_printerr(ioctl(SIOCOUTQ) failed, %s, strerror(errno));
}
if (so_unsent_size 0) {
/* tcp snd buffer is still occupied. rescheduling ping */
@@ -732,6 +737,10 @@ static void red_channel_client_ping_timer(void *opaque)
} else {
red_channel_client_push_ping(rcc);
}
+#else /* ifdef HAVE_LINUX_SOCKIOS_H */
+/* More portable alternative code path (less accurate but avoids bogus
ioctls)*/
+red_channel_client_push_ping(rcc);
+#endif /* ifdef HAVE_LINUX_SOCKIOS_H */
}
RedChannelClient *red_channel_client_create(int size, RedChannel *channel,
RedClient *client,
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] seamless spice migration : question about password/ticket for target vm
On 07/22/2013 12:50 PM, Marc-André Lureau wrote: Hi - Mensaje original - Hi, On 07/22/2013 08:04 AM, Alexandre DERUMIER wrote: Hi, I'm trying to do migration, and I have a question about password on target vm. If I understand, client try to connect to target vm with same password (temporary ticket) used to connect to source vm. But, we need to configure this password to target vm, as I think that qemu migration process don't copy the password between both spice server right ? So we need to store this password somewhere on the host, which seem to be bad for security. (Seem that libvirt store it in guest config xml) ovirt's vdsm sets to the destination host the same ticket that was set upon the original connection. Is it possible to generate a new ticket for target vm, and send it to the client ? (I don't see any option in qmp client_migrate_info ) I don't think there is a way to do it without changing client_migrate_info and the protocol. Even if we would have a password option in client_migrate_info, I don't know if libvirt can retrieve this information. So upon migration, libvirt/ovirt will set the dest VM with the same old password? That sounds sane to me in general, but looks kinda against an expiry-based ticket. It would be worth asking the ovirt folks. Yes, they reset the same password, with the same expiration time, at the moment the destination is up (the expiration time is one of the reasons why we need to connect to the destination before migration really begins). ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [(spice) PATCH RFC 1/2] configure.ac comment typo nit
Ack On 07/18/2013 11:04 AM, Nahum Shalman wrote: --- configure.ac |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/configure.ac b/configure.ac index edda8e9..a549ed9 100644 --- a/configure.ac +++ b/configure.ac @@ -20,7 +20,7 @@ m4_define([SPICE_AGE], [8]) # Note on the library name on linux (SONAME) produced by libtool (for reference, gleaned # from looking at libtool 2.4.2) # -# libspice-servver.so.current-age.age.revision +# libspice-server.so.current-age.age.revision AC_INIT(spice, [m4_esyscmd(build-aux/git-version-gen .tarball-version)], [spice-devel@lists.freedesktop.org], spice) ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Questions regarding Bug 62033 - Means to detect local-only
Hi everyone,
I've made a bit of progress on this issue - disable wallpaper and
disable animations somewhat work with Gnome3. The code is very simple:
static void disable_animation()
{
GSettings *desktop_settings =
g_settings_new(org.gnome.desktop.interface);
g_settings_set_boolean(desktop_settings, enable-animations, FALSE);
}
static void disable_wallpaper()
{
GSettings *desktop_settings =
g_settings_new(org.gnome.desktop.background);
g_settings_set_boolean(desktop_settings, draw-background, FALSE);
}
But looks like this isn't enough. This implementation of disable_wallpaper
actually freezes current background, it is still displayed just isn't
scaled properly when e.g. resolution changes. I'd love some input from
anyone with Gnome3 knowledge... What's expected behavior for Spice client
in this case?
Disable_animations seems to not changing things much - at least I still see
some animations when opening menu or pressing Action button (top left
corner).
Another question is about --spice-disable-effects=font-smooth. While this
can be changed via GSettings, I think it should be changed at X level,
correct? Leading to subsequent question of supporting Wayland/Weston...
Also I don't really see any use case for disabling anti-aliasing... Maybe
configuring anti-aliasing level makes sense...
Next question is about --spice-color-depth. Right now it supports
Windows-specific values of 16 and 32, for Linux we'd need to support 16 and
24. I think this setting should be adjusted at X level, similarly to
anti-aliasing.
There is another level of complexity: changing these settings takes
permanent effect, and user doesn't have any means to reset them except
dconf-editor (not user friendly at all).
So looks like we'd need an '--spice-enable-effects' option (and by default,
when enable/disable isn't set, use local-only detection - to be
implemented). What do you think?
And finally, I haven't looked into KDE settings counterpart yet, but the
question is already here - how should we bind to KDE settings API. Late
binding via dlopen/dlsym - to be used only if KDE detected? Also,
GSettings/Gnome3 support relies on GIO - and currently vdagent isn't
dependent on this library (only on GLib). Should we not favor Gnome3 over
KDE here and implement this feature symmetrically?
I'm really sorry for so much questions about this tiny feature...
Implementing DE-specifics within a client doesn't seem so easy or proper
way for me now...
On Fri, Jul 5, 2013 at 9:45 PM, Hans de Goede hdego...@redhat.com wrote:
Hi,
On 07/05/2013 06:07 PM, Fedor Lyakhov wrote:
Thanks for your answers!
Looks like the issue is more complicated than I originally thought. But
I'm still excited to continue working on it.
Ok, I'm going to follow Hans' view now.
Good.
One thing I don't understand: why would we want to apply these 'effects'
settings via vdagentd (system level)? For me they belong to session level.
And they do, the suggestion to use the system dbus was related to your
proposal where the agent would advertise
settings and the session(s) settings manager would query them. If you
follow my proposal the agent will be
actively making the changes, and that certainly belongs in the session
part of the agent.
Before the session is started there is no way for us to know will it be
Gnome or KDE or w/e - it is decided upon login...
Correct, but if the session's settings manager will query the agent (the
old design) there is no need to know
the session type.
Also how this will work when Spice supports multiple client connections
to one guest?
A good question, this is something which is best left for later.
I'll investigate current ways of toggling 'effects' in Gnome and KDE - to
understand how far we are from common standard way for doing this. Assuming
there is no common way, what would you prefer:
1. Implement DE-specific code within vdagent/vdagentd
2. Introduce something like 'draft standard dbus interface for
controlling DE effects', and add sample Gnome and KDE implementations
(which would hide DE-specifics from vdagent).
I would prefer 1. You could also do 2 in parallel as a proof of concept,
when starting
a discussion about a unified dbus API for this, it helps to have some
example code, but I
believe that to get results quickly we should do 1 (we can still pursue 2
in parallel to
work to a better solution in the future).
Regards,
Hans
--
Best regards,
Fedor
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
