> Also, do you account for intermediate CA in your setup? You have basically
> two options how to handle it:
>
> 1) "standard": server-cert.pem should contain the whole chain of certificates
> under root CA, e.g:
> * Int. CA 1
> * Int. CA 2
> * server cert
> you just cat them to the fi
> To make sure I understand, you start with a Root CA which I assume you
> generated yourself and is self-signed?
We use official certs from "StartCom Certification Authority" using
" StartCom Class 2 Primary Intermediate Server CA" intermediate CA.
But we just observed that the same setup wor
> I think you must be able to "openssl verify" your file without specifying the
> CAfile, if you want Spice ssl checks to pass.
Sorry, but how should that work? For example:
# cat server.pem intermediate_certificate.pem ca.pem >mix.pem
So the file contains all needed certificates, but:
# openss
I use the following certificate files:
# openssl verify -CAfile /etc/pve/pve-root-ca.pem /etc/pve/local/pve-ssl.pem
/etc/pve/local/pve-ssl.pem: OK
I pass the content of /etc/pve/pve-root-ca.pem to virt-viewer:
[virt-viewer]
ca=-BEGIN CERTIFICATE-\nXX/Q=\n-END CERTIFICATE-\
>support for unencrypted tickets, the server can
> instruct it it should send one. For now, this is restricted to encrypted
> channels as
> we don't want to expose an unencrypted password over a non-TLS channel.
> Clients with unencrypted password support won't send these just yet as the
> server
> Now, let's say the user connects from their Android device to the same VM
> while
> on the road. If the VM is set to use QWERTZ, but I am using the "common"
> layout file that is under discussion
I think you are confused. Nobody used the 'common' layout. Instead, that file is
used as default ma
> We're discussing (for example) a German user who has picked QWERTZ inside
> their VM so that when they're connecting from their laptop which also has
> QWERTZ, everything is sane.
> Now, let's say the user connects from their Android device to the same VM
> while
> on the road. If the VM is set
> So it certainly doesn't cover all the cases (QWERTZ, AZERTY, etc) that
> Opaque/aSPICE need to cover!
I am not sure why you want to depend on the andriod keyboard layout?
Simply set the VM to use a QWERTZ keyboard, and use the same layout
with oqaque?
Or do you want to emulate android devices
> Case in point. Let's consider:
> /usr/share/qemu/keymaps/de
> The user wants to input the letter "q" from their Android device. Since this
> is
> QWERZ, I need a mapping of unicode 0x71 to scancode 0x10.
> All I can find in /usr/share/qemu/keymaps/de that mentions 0x10 is the "at"
> symbol with
Not sure if I understand your question. Those files have mappings for letters
and numbers.
You can look up the used names in /usr/include/X11/keysymdef.h file.
I use a small script to extract those name->unicode mappings:
https://git.proxmox.com/?p=spiceterm.git;a=blob;f=genkeysym.pl;h=cdccf3cf
> I really didn't like the idea of releasing Opaque (the oVirt/RHEV VM console
> Android client) into production supporting only English (QWERTY), so I decided
> to implement a workaround for the existing inability to send Unicode directly
> to
> the OS of the VMs. It's not perfect, because it req
> On Fri, Oct 25, 2013 at 10:43:13AM +0200, Christophe Fergeau wrote:
> > On Tue, Oct 22, 2013 at 11:07:56AM +0200, diet...@proxmox.com wrote:
> > > Current code works with DIGEST-MD5, but not with PLAIN.
> >
> > After spending quite some time on this, this seems right, we need to
> > handle
> > sa
> This seems to be asking for a username both in the SASL case when it makes
> sense, but also in the usual 'ticket' case (spice-server -spice password=foo
> command line option). In the latter case, we should not be asking for a
> username as it is meaningless.
OK, sent a fix for that.
> I think you could add a SPICE_CHANNEL_ERROR_AUTH_USER_AND_PASS (and a
> property "username" on the session)
This does not work because auth is expected to signal different error, for
example
SPICE_CHANNEL_ERROR_LINK.
___
Spice-devel mailing list
Spic
> All you need is:
>
> auth_method: plain
>
> And set a password with 'saslpassword2 root@your.domainname'
Sorry, you need to use the FQDM as realm (root@)
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/ma
> This bit makes me much more uncomfortable, especially this is touching
> security-
> sensitive code. Things are not working without it?
> If you have a working sasl plain config for spice, I'd be interested in it as
> I could
> not get that to work for testing :((
All you need is:
auth_method
> I don't think mandating that the username we use for SASL is the unix user
> name
> the client runs as makes a lot of sense. Imo it would be better if we always
> asked
> for username/password when SASL asks for it, and prefill the username field
> with the local unix user name.
Exactly. I can
Seems that ticket auth does not work as soon as SASL is enabled on client and
server.
Is that expected behaviour?
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
> > While this is not perfect, it would be far better than what we have now.
>
>
> "Far better", in what way? Wouldn't it have the same limitations, using a us
> layout -> scancode table? I know it's configurable at qemu side, but that's
> not
> per client, so it would be US anyway.
We (and man
> Current SASL implementation in Spice doesn't support username.
>
> > And you can still use tickets if you check for strlen(username) == 0 ?
>
> There is noneed to ask the user a username for the current methods. He
> wouldn't do what to put there.
Sure. That is why I asked if you would accept
> > Would you accept a patch for that, or do you think above code is all we
> > need?
>
> We shouldn't ask username for the current auth methods.
Why? Using SASL without username is a bit limited - or do I miss something?
And you can still use tickets if you check for strlen(username) == 0 ?
_
Current remote viewer only ask for a password when connecting to a spice session
which requires auth:
from virt-viewer-session-spice.c:
case SPICE_CHANNEL_ERROR_AUTH:
DEBUG_LOG("main channel: auth failure (wrong password?)");
int ret = virt_viewer_auth_collect_credentials(self
> I understand. you are sending keysym, and avoid the layout and hw scancode...
> But Spice, in general, is talking to a VM, and currently only via scancodes.
>
> Quite clearly, I understand that using the agent and XTest, input-methdod or
> accessible-technology will avoid the hw layer altogether
> > Besides, I still not understand how that should work. You (Marc) told
> > me that it is easy to get the correct scancodes, but the sources
> > contain the following comment:
>
> Did I? I don't remember the context.
Again, my keysym patches provides a workaround for that problem.
> >
> > "**
> > well that s weird, im using firefox too and add the mapping there, but
> > wouldnt work. the following change solves the problem for me though
> > /firefox_scanmap[173] = 0x4a;/
>
> Ah, then it was fixed some time ago:
> http://cgit.freedesktop.org/spice/spice-
> html5/commit/
> > And AFAIK SASL does not even compile with mingw, so it is quite useless.
>
> Marc-Andre did some work to make it build
>
> http://fedorapeople.org/cgit/elmarco/public_git/mingw32-cyrus-sasl.git/
>
> though I do not know what the current status of it is, whether his fixes were
> ever
> app
> > And AFAIK SASL does not even compile with mingw, so it is quite useless.
>
> Marc-Andre did some work to make it build
>
> http://fedorapeople.org/cgit/elmarco/public_git/mingw32-cyrus-sasl.git/
>
> though I do not know what the current status of it is, whether his fixes were
> ever
> app
> Which is just re-inventing the wheel. IMHO re-inventing wheels is bad,
> particularly when security is involved.
Maybe. But using complex code instead of easy code is also bad.
Using the whole SASL layer to callback the PVE auth layer adds a
lot of useless code, without any gain!
> Marc-Andre did some work to make it build
>
> http://fedorapeople.org/cgit/elmarco/public_git/mingw32-cyrus-sasl.git/
>
> though I do not know what the current status of it is, whether his fixes were
> ever
> applied by upstream or not.
Please do not force me to use such complex framework.
> SASL has a "plain" plugin for straing (username,password) auth, so this
> offers no
> new functionality.
But it offers that functionality without the requirement of SASL.
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.free
> > The password is not encryped, so this method is only safe if you use TLS.
>
> Can you describe what you are trying to achieve exactly through this
> auth_plain_verify_credentials callback? I assume you want to check the
> (username, password) against 'something' once you got them from the clie
> Can you describe what you are trying to achieve exactly through this
> auth_plain_verify_credentials callback?
> I assume you want to check the
> (username, password) against 'something' once you got them from the client?
yes
> Can the SASL support already do what you are looking for?
SASL is
> > Why is that wrong?
> You are right. And yet thunderbird won't show me the contents on reply, and I
> saw there was an attachment, so I assumed. My bad. Still I don't know why
> thunderbird fails to quote the message on reply and instead gives me an empty
> message.
I also noticed that the mail
> On 10/16/2013 02:04 PM, diet...@proxmox.com wrote:
> For next time: can you send the patches inline? it is easier to respond to
> then to
> mails with attachments.
I guess I have already done that. I use 'quilt mail' to send the patches, and
the
raw email contains:
Content-Disposition: inlin
> > I just send this to the list to archive the work I have done so far.
> > Marc already expressed that he do like the current patches, so I will
> > rewrite them and post v3 soon.
Oh sorry - I want to write "Marc already expressed that he do NOT like the
current patches"
> Yes, but I have conc
> > > If you really want to send scancode, do it the same way as "Data
> > key_scancode"
> > > for arbitrary sequence.
>
> Just want to mention that you have the following definitions in the default
> protocol:
>
> message {
> uint32 code;
> } @ctype(SpiceMsgcKeyDown) key_down = 101
> > If you really want to send scancode, do it the same way as "Data
> key_scancode"
> > for arbitrary sequence.
Just want to mention that you have the following definitions in the default
protocol:
message {
uint32 code;
} @ctype(SpiceMsgcKeyDown) key_down = 101;
message {
> > Did the spice-html5 people already found a way to generate scancodes?
>
> I don't see the relation. For example, in case of html5 client to spiceterm,
> you
> don't need (and don't have) hw scancode.
I talk about html client with qemu. The suggested protocol extension provides
a clean soluti
> > The point is that we already have the code in qemu, and there is not
> > really an other solutions for the javascript client (or is there a
> > better way to do it?).
>
> I don't follow you.
Did the spice-html5 people already found a way to generate scancodes?
> If you really want to send scancode, do it the same way as "Data key_scancode"
> for arbitrary sequence.
will try.
> Why did you drop the flags in the end?
The information can be generated on the server side, so there is no real need
to send it over the wire.
> > Another advantage is that a
r=proxmox@lists.freedesktop.org] On
> Behalf Of Dietmar Maurer
> Sent: Donnerstag, 10. Oktober 2013 16:42
> To: Christophe Fergeau; Marc-André Lureau
> Cc: spice-devel@lists.freedesktop.org; Marc-André Lureau
> Subject: Re: [Spice-devel] [patch 0/2] vdagent KEYVAL extension
>
> > The Paus
> The Pause key seems to be sending 4 bytes scancodes if I read the docs I
> looked
> at recently correctly. Didn't get around to test it to see what happens
> though ;)
current code in spice-gtk only use 2 bytes:
guint16 spice_make_scancode(guint scancode, gboolean release)
___
> > So the following message could in fact replace all existing messages for
> keyboard input:
> >
> > message {
> >uint32 keyval;
> >uint32 scancode;
> >keyboard_keyval_flags flags;
> > } @ctype(SpiceMsgcKeyKeyval) key_keyval;
> >
>
> Let's keep the messages seper
> Ok, so I will add more space for scancodes. I have further optimized my patch,
> and I currently use:
>
> message {
> uint32 keysym;
> uint32 scancode_down;
> uint32 scancode_up;
> } @ctype(SpiceMsgcKeyX11Keysym) key_x11_keysym;
Another advantage is that a clie
> > I want to get key repetition message here!
>
> Can you be more precise? As you can read in spice-gtk code, send_key() is
> still
> doing some filtering of gtk key events, not directly sending them as Spice
> events:
I miss-understood that code, but now I can see how it works.
> send_key()
> > So what happens if you connect to a VM from client with different
> > keyboard layout than specified inside the VM?
>
> Just like with a guest, Spice sends hw scancode, and it's converted by the
> server/application side.
Ok, I will try to explain the problem again.
Spice/qemu currently assu
> You didn't explain why you needed to add a new message, and a new DOWN/UP
> flag. How to interpret scancode with the flag? You can't stick 2 3-bytes
> scancodes for DOWN/UP, so is the server supposed to generate the UP
> scancode? (that would be different from existing scancode events)
I read th
> > switch (key->type) {
> > case GDK_KEY_PRESS:
> > +flags |= VD_AGENT_KEYVAL_FLAG_DOWN;
> > +spice_main_send_keyval(d->main, key->keyval, flags);
>
> This is the wrong place if you want to avoid the key repeatition issue solved
> by
> "send_key" (synthesize press_and_r
> I think you should keep the UP flag there you had in your previous proposal
> (to
> avoid problems of network latency, generating spurious key repeatition events
> on application/guest side)
OK
> Why not have SUPER (win key), HYPER and META?
Sure, I can add them
>
> > +typedef struct SPICE
> > Not everything is a VM (there is no server side keymap in spiceterm).
>
> But even *userspace* x11 or weston spice server handle keymaps. You could
> too, using xkb common.
I am not sure what you want to tell here. The problem is that you do not know
the
keymap of the client side.
So even i
> > Oh, I get you wrong. So you really think we can modify existing message
> formats based on caps?
> > That looks a bit confusing to me, and it is not clear how that should
> > work because message marshallers are auto-generated?
>
> I don't remember. In the case of clipboard selection, it was
> > That is clumsy, and also requires a protocol extension - so what is
> > the advantage?
>
> "sync client and guest with the keymap" & avoid the need for new key event.
I guess you over-simplify that. There are many different keymaps on the client
side!
So you do you correctly translate the sc
> An alternative approach is to monitor the actual size that is currently
> occupied
> by drawables that are referenced by the display channel, and to limit *this*
> size,
> instead of the number of drawables
Another alternative is to draw always (see DRAW_ALL in the code).
My tests with spicet
> I think the hardcoded limit was intended for limiting the occupancy of the dev
> ram with drawables that are referenced by the display channel.
> If the limit is reasonable it should help with keeping allocations in the
> driver
> fluent, and avoiding IO_OOM.
> An alternative approach is to moni
> > Note: you cannot translate a scancode to utf8 (because you do not know
> > the keymap of the client).
>
> Or perhaps you could, that would allow to sync client and guest with the same
> keymap.
That is clumsy, and also requires a protocol extension - so what is the
advantage?
> > Hope that
> > No. There is no need to draw anything at the server side (for spiceterm).
>
> Ok, that would be interesting. I wonder if you are not better off
> implementing a
> new display channel for your use case, if you just need to send off your own
> rendering commands without any change.
why is that
> > I just detected that my simple spiceterm generates more than
> >
> > 1000 drawables, so alloc_drawable() always fail.
> >
> >
> >
> > The effect is that I always draw twice (on server and at client)!
>
> This is an area I am newbie ;)
>
> Isn't the server always drawing anyway at some point?
> I still have to answer myself the question "why is the current XT scancode
> input
> not enough"? Although I think I have guessed, it would be good to explain
> that,
> to motivate the reason for this change.
Some SPICE applications want to use the keymap from the client side, and
works direc
I just detected that my simple spiceterm generates more than
1000 drawables, so alloc_drawable() always fail.
The effect is that I always draw twice (on server and at client)!
I guess one would see the same effect when running a xterm inside a VM, because
a terminal has a size of 80x25 character
> Well, you were not really explaining your particular case, or were you?
Yes, I tried at least, and I even provided a complete, working example code
(spiceterm).
> bypassing all of server, x & qemu & kernel etc...
>
> Arbitrary utf8 input can only be handled at user space / agent level (no way
> You said it yourself, unicode doesn't have representation for all keyboard
> keys.
> As you have seen in my previous reply, I am looking at the problem from an
> "input-method" level. And I don't know if it's a good idea to depend on
> X11/gdk
> keysyms in general for Spice.
VNC use that for 2
> Keys that don't have utf8 equivalent should be sent with the current input, I
> don't
> see a benefit changing that.
>
> Having a utf8 input is mainly useful for utf8 input from client (input method,
> browser) and to bypass guest keymaps.
>
> It shouldn't be used for all inputs.
I need that
> Yes, although I think we should be able to send arbitrary utf8 input in the
> protocol. If I read your proposal right, you are sending UCS-4 codes, no utf8?
>
> I think you should use gdk_keyval_to_unicode() then g_ucs4_to_utf8() for key
> input and efficiency (in your spice-gtk patch).
Unfortu
> > And I don't see any connection to http connect proxy .
> >
> > Is it a bug ?
>
> What are guest OS, agent & driver, and client versions?
>
> Can you provide SPICE_DEBUG=1 log of spice client?
> (G_MESSAGES_DEBUG=all SPICE_DEBUG=1 ./remote-viewer...)
I am not sure if the following is related,
> > I guess that should be renamed to remote-viewer.com?
>
> Yes, do you have needs for it? (it's not as useful as I wished it would,
> unfortunately)
no, I do not need it - I was just curios.
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.o
Seems the msi files for virt-viewer contains the file:
windows-cmdline-wrapper.exe
I guess that should be renamed to remote-viewer.com?
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-d
> > remote-viewer prints:
> >
> > JPEG parameter struct mismatch: library thinks size is 464, caller
> > expects
> > 432
> >
> > Any ideas?
>
> That looks like a compilation issue to me. libjpeg and jpeg-turbo might have
> slightly different ABI. I don't think you can just drop and replace the dll
> I try to cross compile virt-viewer to win32 using Debian Jessie. So far it
> works,
Ok, using gtk2 seems to be more stable.
I get another strange error if I use libjpeg-turbo-1.2.90 instead of
libjpeg8_8d:
remote-viewer prints:
JPEG parameter struct mismatch: library thinks size is 464, cal
> It should only be called in enter or focus events, which I assume shouldn't
> happen when the widget is not realized.
it receives a focus event.
> > So this results is a call to GDK_WINDOW_HWND(NULL), which simply crash
> > remote-viewer.exe
>
> Ok that macro isn't safe. Why do you check (!di
I try to cross compile virt-viewer to win32 using Debian Jessie. So far it
works,
but only if I apply the following patch to spice-widget.c:
Index: new/gtk/spice-widget.c
===
--- new.orig/gtk/spice-widget.c 2013-06-26 15:55:08.00
> > I have No idea what this opaque is for, but I prefer the information to be
> explicit.
>
> I just read this: http://spice-space.org/page/Whiteboard/AgentProtocol
>
> According to that, this field is exactly for that use case.
>
> > What if you consider it as a different message with a diffe
> > This makes it really hard to write nice code.
>
> I don't think I would have done it if it was "really" hard. But I understand
> in your
> code it might be difficult for some reason.
It is not 'really' hard (but a bit 'ugly')
> > I wonder why it does not simply use the ‘opaque’ field of
> >
The clipboard message currently include an optional 4bytes enty for 'selection':
typedef struct SPICE_ATTR_PACKED VDAgentClipboardGrab {
#if 0 /* VD_AGENT_CAP_CLIPBOARD_SELECTION */
uint8_t selection;
uint8_t __reserved[sizeof(uint32_t) - 1 * sizeof(uint8_t)];
#endif
uint32_t types[0];
> Who handles the keyval, do you have corresponding qemu or agent patch?
> Or are you using this only with XSpice somehow? It would be nice if we could
> get
> the full picture before amending this.
I just finished a first prototype:
# git clone git://git.proxmox.com/git/spiceterm.git
You need
> > Who handles the keyval, do you have corresponding qemu or agent patch?
> > Or are you using this only with XSpice somehow? It would be nice if we
> > could get the full picture before amending this.
>
> I am writing a spice based terminal server. But I need a few more days until
> that code is
> Who handles the keyval, do you have corresponding qemu or agent patch?
> Or are you using this only with XSpice somehow? It would be nice if we could
> get the full picture before amending this.
I am writing a spice based terminal server. But I need a few more days until
that code is ready for r
Signed-off-by: Dietmar Maurer
---
gtk/channel-inputs.c| 33 -
gtk/channel-inputs.h|6 +++---
gtk/spice-widget-priv.h |1 +
gtk/spice-widget.c | 24 ++--
4 files changed, 46 insertions(+), 18 deletions(-)
diff --git a
Some SPICE applications want to use the keymap from the client side, and
works directly with UTF input characters (for examply a terminal emulator).
The current scancode values cannot be used for those applications.
Unfortunately, UTF character set miss all special keyboard keys like
function-ke
Signed-off-by: Dietmar Maurer
---
common/client_marshallers.h |1 +
common/messages.h |5 +
spice.proto | 10 ++
3 files changed, 16 insertions(+)
diff --git a/common/client_marshallers.h b/common/client_marshallers.h
index 85051a0..bbd114d
Signed-off-by: Dietmar Maurer
---
server/inputs_channel.c | 20
server/spice.h |1 +
2 files changed, 21 insertions(+)
diff --git a/server/inputs_channel.c b/server/inputs_channel.c
index 931dac1..248ecae 100644
--- a/server/inputs_channel.c
+++ b/server
Signed-off-by: Dietmar Maurer
---
spice/enums.h|8
spice/protocol.h |1 +
2 files changed, 9 insertions(+)
diff --git a/spice/enums.h b/spice/enums.h
index 8c731e9..e6adb5a 100644
--- a/spice/enums.h
+++ b/spice/enums.h
@@ -301,6 +301,13 @@ typedef enum
> Perhaps this brokenness is unavoidable with spice android/html5 clients, but
> you
> should be aware that if you go down that route, you are picking a solution
> which
> is unfixably broken.
It is also broken if you implement it on the client side ;-) And we already
have that code,
so it woul
> > Having utf8 input was discussed a few weeks ago, it is needed for html
> > and android clients for ex.
>
> Note that this is a completely different problem.
>
> When running a virtual machine you need the scancodes, so you can feed the
> guest with the correct virtual keystrokes. Translating
> So you want to have a terminal emulator using spice-server directly?
Yes. We have that for VNC, and it is quite convenient. For example, we can open
a login shell to the host, or run maintenance command requiring user input
like 'apt-get upgrade'. Or simply open a container console by running
> Having utf8 input was discussed a few weeks ago, it is needed for html and
> android clients for ex.
>
> Feel free to propose a solution.
Just extend the protocol to send both things (scancode and utf8)?
Or add another channel for utf8 input?
___
Sp
> > Scancodes are great for use in qemu/X11, but other applications needs utf8.
>
> Which?
I want to write a terminal emulator, exporting the vt100 display over spice.
Example:
# spiceterm -c /bin/bash
That way you can run any terminal based command over spice.
We already have that for VNC.
Seems the keyboard interface only return scancodes? Is there a way to get the
corresponding utf8 character (using client side keyboard mapping)?
Scancodes are great for use in qemu/X11, but other applications needs utf8.
___
Spice-devel mailing list
Sp
Hi all,
is there some example code for QXL_DRAW_TEXT.
A simple command for spice-0.12.4/server/tests/ would be great.
Or is there some documentation? What font is used?
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freede
> > >I guess gio/gvfs should be able to
> > > fetch files from http[s] (no libcurl please ;). Is it what you
> > >(Dietmar) are looking for?
> >
> > Why gvfs? libcurl look much simpler.
>
> libcurl would look a bit alien in the rest of the code base, and if we ever
> want to do the download async
> In my opinion, we could support running 'remote-viewer
> https://proxmox.example.com/myvm.vv',
Well, but we need to handle basic auth.
>I guess gio/gvfs should be able to
> fetch files from http[s] (no libcurl please ;). Is it what you (Dietmar) are
> looking for?
Why gvfs? libcurl look much
> > > Can't you write a simple wrapper/script to take care of that?
> >
> > Sure. Then I have to maintain/install a script and remote-viewer, and
> > I want to avoid that.
> >
> > Why is the ovirt code included? I guess it is just convenient.
>
> I haven't used the ovirt support, but my impression
> Since it's simply a data fetch from https, why does it needs to be part of
> virt-
> viewer?
>
> Can't you write a simple wrapper/script to take care of that?
Sure. Then I have to maintain/install a script and remote-viewer, and I want to
avoid that.
Why is the ovirt code included? I guess
> Besides, is there an easy way to implement a https client using glib only? If
> not, is there a small library we can use for that purpose? - any suggestions?
Answering myself, I think libcurl would be a good candidate - see:
http://curl.haxx.se/libcurl/competitors.html
But would you accept a p
Currently, remote-viewer is able to connect to the ovirt REST API using
something like:
ovirt://x.y.z/a/b
Unfortunately, this just works with ovirt, and not with our API (Proxmox VE).
I think a better approach would be to allow download of setup file from https:
https://x.y.z/a/b
If that retu
94 matches
Mail list logo
