Update problems
by Frank McCormick
Hi all
Got this this morning...is it a problem on my end or theirs?
[frank@localhost ~]$ sudo yum check-update
Loaded plugins: langpacks, refresh-packagekit
Update notice FEDORA-2013-13577 (from updates-testing) is broken, or a
bad duplicate, skipping.
You should report this problem to the owner of the updates-testing
repository.
Update notice FEDORA-2013-15734 (from updates-testing) is broken, or a
bad duplicate, skipping.
Update notice FEDORA-2013-15106 (from updates-testing) is broken, or a
bad duplicate, skipping.
Update notice FEDORA-2013-14132 (from updates-testing) is broken, or a
bad duplicate, skipping.
Update notice FEDORA-2013-14172 (from updates-testing) is broken, or a
bad duplicate, skipping.
[frank@localhost ~]$
Thanks
10 years, 8 months
Re: [Spice-devel] [virt-tools-list] More on virt-viewer for windows
by Fernando Lozano
Hi,
>>> Can someone from the Spice community chime in? Why is
>>> spice-space.org shipping a Fedora 18 build of libvirt (0.10.2.x)
>>> rather than Fedora 19 (1.0.5.x)? Who does the builds, and how often
>>> are they updated?
>> I do builds when releasing new virt-viewer versions, and I use the latest
>> stable Fedora available at that time. We've not done any virt-viewer
>> release since F19 came out.
>>
>> There's no reason why I couldn't do bug fix re-builds of the installer
>> though at any time if deemed neccessary.
> It would be nice to do a bug fix rebuild as soon as 0.10.2.8 is
> released, as that would pick up the patch for mingw refusing to create
> sockets, and hopefully get people a lot further at actually being able
> to use virsh on mingw.
I got confused by those release numbers: if Fedora has libvirt 1.0.5.x
why should the next windows build use older 0.10.2.8? I though
development were being done only on the latest releases.
[]s, Fernando Lozano
10 years, 8 months
libvirtd auth for qemu+ssh connections
by Fernando Lozano
Hi,
I asked this before but as it was mixed with another question on the
same message I guess nobody noticed:
>>> I am experimenting with different security settings for libvirtd, so
>>> I can give sysadmins administrative access to the KVM hypervisor
>>> without giving them root access on the host. I had success using TLS
>>> (with client-certs) and SASL, but have not managed to make polkit
>>> and ssh to work so far.
>>>
>>> If I change /etc/libvirt/libvirtd.conf auth_tcp or auth_unix_rw a
>>> local virsh connection gets this error:
>>>
>>> "Authorization requires authentication but no agent is available"
>>>
>>> Thus I'm using "sasl" for tcp and "none" for the unix socket.
What should I have for libvirtd polkit authentication? I'd like to use
regular user PAM passwords (either from local files or from LDAP). But I
only managed to get working the other options: no auth, client-cert
(TLS) or SASL digest-md5 own password database.
>>> When I try a "qemu+ssh" remote virsh connection evething works fine.
I found no auth configuration on /etc/libvirt/libvirtd.conf for ssh
connections. This means they are using unix sockets, like they were
local connections?
[]s, Fernando Lozano
10 years, 8 months
Re: [Spice-devel] [virt-tools-list] Strange behaviour using qemu+ssh on virt-manager
by Fernando Lozano
Hi there,
>>> When I try a "qemu+ssh" remote virsh connection evething works fine.
>>> But then I try the same URL using virt-manager, and then try to open
>>> a guest console, virt-manager prompts multiple times for a ssh login
>>> password.
>>>
>>> Is this a bug?
>> Each console rquires that we setup a new SSH tunnel, since every
>> console is on a different socket on the remote host and we don't
>> know them all ahead of time.
So far, that's expected, but it should require only one password prompt
for each console.
> This is particularly bad with spice, which wants multiple fds for each channel
> (display, audio, usb redirection, a few others). Each channel requires an ssh
> connection, so if you are only using a default ssh setup it will launch
> askpass many times.
That's my case, using SPICE for guest consoles.
While now I understand why all those password prompts, that's very bad
from a usability perspective. And I guess it's also bad from a network
perspective (having multiple TCP connections for the same interative
remote user session). Couln't all SPICE channels be multiplexed on the
same TCP connection, and so use the same SSH connection?
[]s, Fernando Lozano
10 years, 8 months
ssh reverse port forwarding - ssh keys
by bruce
Hey...
testing out ssh port forwarding/reverse tunneling using sshkeys
i've got the process of going from machineA to machineB using keys..
The test doing ssh user(a)foo.com -p 5011 works
- auto login using the ssh keys..
However, the test of going from machineB to machineB is a bit chaotic.
I've created the private/pub rsa key.. on the machineB for the user
that will conduct the ssh connections, the id_rsa key was updated with
the private key.
The test then updated the machineA for the specified user with the
updated pub key in the authorized_keys file
The test also ensured the perms/owners on the machineA are correct.
the issue I'm having is that the test is still requiring a password to
complete the ssh session.
I'm not sure if I have to do something else to the machineB given that
the port forwarding/reverse tunnel essentially maps the port of the
localhost to the port of machineA
on machineB
ssh tom@localhost -p 1999
which should use the private/pub keys to go through the tunnel to get
back to machineA
however, the process currently still asks for the password...
thoughts/suggestions...
thanks
10 years, 8 months
Strange behaviour using qemu+ssh on virt-manager
by Fernando Lozano
Hi there,
I am experimenting with different security settings for libvirtd, so I
can give sysadmins administrative access to the KVM hypervisor without
giving them root access on the host. I had success using TLS (with
client-certs) and SASL, but have not managed to make polkit and ssh to
work so far.
If I change /etc/libvirt/libvirtd.conf auth_tcp or auth_unix_rw a local
virsh connection gets this error:
"Authorization requires authentication but no agent is available"
Thus I'm using "sasl" for tcp and "none" for the unix socket.
When I try a "qemu+ssh" remote virsh connection evething works fine. But
then I try the same URL using virt-manager, and then try to open a guest
console, virt-manager prompts multiple times for a ssh login password.
Shoudn't virt-manager resue the same ssh connection for guest console
access? And even if it needs to open a new ssh connection for the spice
connection, this should require only one additional ssh login.
But I tried many times, carefully typing the password each time, and I'm
sure they were not typos: virt-manager is actually asking for the ssh
login password many times!
Maybe people who use ssh keys (passwordless) logins didn't notice, but I
think virt-manager should't require more than one addtional ssh
connection per guest console. Is this a bug?
[]s, Fernando Lozano
10 years, 8 months
Re: [virt-tools-list] [Spice-devel] More on virt-viewer for windows
by Fernando Lozano
Hi Eric,
>> Hi,
>>
>> Still hoping someone takes my test results and fix the windows port. ;-)
>>
>> I configured my host to accept remote tcp libvirtd connections, once
>> with sasl security and the seccond time without any security. Both
>> setups were validated by a linux client, who could connect using virsh
>> and virt-manager without problem. Bu then the windows port fails with
>> the same error message it displayed when using TLS certificates:
>>
>> C:\Program Files\VirtViewer\bin>virsh -c qemu+tcp://kvmhost/system
>> error: Unable to set close-on-exec flag: Success
>> error: failed to connect to the hypervisor
> What version of libvirt again? This error is not possible on the latest
> libvirt.git. That error message is printed ONLY by virnetsocket.c,
> after a failed call to virSetCloseExec(); but looking at
> src/util/virutil.c, virSetCloseExec() _always_ returns 0 for mingw.
> Looking further, it looks like commit fcfa4bfb in Oct 2012 was what
> changed things to always return 0 (instead of always failing); that
> commit is in v1.0.0, but not in v0.10.2. If your build of virsh comes
> from libvirt 0.10.2, that would explain your failure scenario, and it's
> just a simple matter of building a newer libvirt. At any rate, I've
> just now backported that particular commit to the v0.10.2-maint branch,
> so it will be included in the v0.10.2.8 build (hopefully out soon,
> because it fixes several CVEs).
Yes, the libvirt comes grom 0.10.2. I'm running the latest windows
binaries provided by spice-space.org:
C:\Program Files\VirtViewer\bin>virsh -V
Virsh command line tool of libvirt 0.10.2
See web site at http://libvirt.org/
Compiled with support for:
Hypervisors: PHYP ESX Test
Networking: Remote
Storage:
Miscellaneous: Debug
If someone provides newer windows binaries -- which aren't missing dlls,
like the ones at http://teuf.fedorapeople.org/virt-viewer-msi/ -- I will
test then.
>> It looks there is a basic network client code error on the windows port,
>> as using different authentication schemes do not make a difference. :-(
> Rather, it is yet another case of Microsoft's environment being so
> woefully non-compliant with POSIX, and a case of our code assuming POSIX
> semantics and failing when the assumption didn't work. In this case, it
> was pretty easy to work around the assumption.
Please someone give me newer binaries I can test! ;-)
>> If someone wants, I can generate libvirt debug logs and Proccess Monitor
>> logs for those cases, but I guess they'd show more or less the same
>> things as the TLS test I already sent.
> Process Monitor is only useful if you make system calls; but libvirt is
> choking even before attempting the system calls because mingw is just
> such a hostile programming environment to programs that assume POSIX.
That's precisely mingw advantage over cigwin: mingw binaries are native
windows binaries, using native windows semantics, not unix emulation.
They provide a better experience for windows users. Welcome to the
wonderful world of cross-platform developent! ;-)
> Gnulib has helped a lot, and often times, it is just a matter of someone
> running under gdb to see where an assumption went wrong to make a quick
> patch to fix an issue. Where it gets tricky is that it is hard to find
> developers willing to do volunteer work on issues for a platform where
> you typically have to pay money before you can even use it. Also, the
> fact that you are using a pre-built version of a relatively old libvirt,
> instead of building your own from the latest sources, makes it hard to
> know what OTHER issues may have been fixed in the meantime (when given a
> choice, developers prefer to debug issues in the latest source, rather
> than trying to figure out which patches to backport to older branches).
I understand that, but I'm trying to be useful as a (windows) tester. If
I could I'd try to help as a developer. cross-compiling is not for the
faint of heart, and learning the first steps require a significant
investment in time. :-(
Is there a how-to I can follow to generate binaries from the latest
sources? I do have Linux expertize, I use fedora on my personal
computer, but as C developer I can only run "configure; make; sudo make
install".
[]s, Fernando Lozano
10 years, 8 months
Re: [Spice-devel] More on virt-viewer for windows
by Fernando Lozano
Hi,
Still hoping someone takes my test results and fix the windows port. ;-)
I configured my host to accept remote tcp libvirtd connections, once
with sasl security and the seccond time without any security. Both
setups were validated by a linux client, who could connect using virsh
and virt-manager without problem. Bu then the windows port fails with
the same error message it displayed when using TLS certificates:
C:\Program Files\VirtViewer\bin>virsh -c qemu+tcp://kvmhost/system
error: Unable to set close-on-exec flag: Success
error: failed to connect to the hypervisor
It looks there is a basic network client code error on the windows port,
as using different authentication schemes do not make a difference. :-(
If someone wants, I can generate libvirt debug logs and Proccess Monitor
logs for those cases, but I guess they'd show more or less the same
things as the TLS test I already sent.
[]s, Fernando Lozano
10 years, 8 months
installiing joomla
by Martin S
I'm trying to set up Joomla on my laptop to play around with a site I'm
planning. However SELinux seems to block write access for the installation
routine to the direcotry /var/www/html and none of the solutions I've found by
googling to allow SELinux httpd write access seems to work (installation hangs
immediately).
setenforce 0 deosn't have any effect either as far as I can tell, as I still
can't install Joomla.
Anyone successfully installed Joomla 3 on Fedora 19 please can tell how I
should proceed?
10 years, 8 months