Re: [ovirt-users] oVirt AD integration problems

[Karli Sjöberg]

Den 14 okt. 2016 4:30 em skrev cmc :
>
> Hi Ondra,
>
> It manages to authenticate, but appends the domain again once I'm logged in, 
> for instance, if I log in as user 'cam', it will log me in,
> and display the login name in the top right corner as 
> 'c...@domain.com@domain.com' (this shows up in the log as well: it shows me
> logging in as c...@domain.com, but then returns an error as user  
> c...@domain.com@domain.com is not authorized). My thought was
> that something done earlier when I was playing around with sssd, kerberos and 
> AD is doing this, though I have removed these packages
> and run authconfig to remove sssd. Any ideas?

Can't say why, but it's the same for us. It's unsightly, kindly put.

/K

>
> Cheers,
>
> Cam
>
> On Thu, Oct 13, 2016 at 2:04 PM, cmc  wrote:
>>
>> Hi Ondra,
>>
>> That is good to know that we don't need Kerberos - it complicates things a 
>> lot.
>>
>> I think the errors might be the options I'd selected during the setup. I was 
>> thrown a bit that
>> it passed all the internal tests provided by the setup script, but failed on 
>> the web GUI. When
>> I've seen 'unspecified GSS failure' and 'peer not authenticated' it's 
>> usually been due to
>> Kerberos (though admittedly these are just generic errors). So I tried the 
>> Redhat guide for SSO at:
>>
>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.6/html/Administration_Guide/Configuring_LDAP_and_Kerberos_for_Single_Sign-on.html
>>
>> which uses Kerberos (in ovirt-sso.conf) I had to remove the symlink to the 
>> Apache
>> config it says to create, as it results in internal server errors in Apache. 
>> It uses an SPN for
>> Apache in the keytab.
>>
>> Now that you've confirmed that it can actually work without any need for the 
>> Kerberos stuff,
>> I will start afresh from a clean setup and apply what I've learnt during 
>> this process.
>>
>> I'll try it out and let you know either way.
>>
>> Many thanks for all the help!
>>
>> Kind regards,
>>
>> Cam
>>
>>
>>>
>>> Yes, you really do not need anything kerberos related to securely bind
>>> to AD via LDAP simple bind over TLS/SSL. This is really strange to me
>>> what errors you are getting, but you probably configured apache (or
>>> something else?) to require keytab, but you don't have to, and you can
>>> remove that configuration.
>>>

 Thanks,

 Cam




 Thanks,

 Cam

 ___

 Users mailing list
 Users@ovirt.org 
 >
 http://lists.ovirt.org/mailman/listinfo/users
 
 >



>>
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] oVirt AD integration problems

[cmc]

Hi Ondra,

It manages to authenticate, but appends the domain again once I'm logged
in, for instance, if I log in as user 'cam', it will log me in,
and display the login name in the top right corner as 'c...@domain.com@
domain.com' (this shows up in the log as well: it shows me
logging in as c...@domain.com, but then returns an error as user
c...@domain.com@domain.com is not authorized). My thought was
that something done earlier when I was playing around with sssd, kerberos
and AD is doing this, though I have removed these packages
and run authconfig to remove sssd. Any ideas?

Cheers,

Cam

On Thu, Oct 13, 2016 at 2:04 PM, cmc  wrote:

> Hi Ondra,
>
> That is good to know that we don't need Kerberos - it complicates things a
> lot.
>
> I think the errors might be the options I'd selected during the setup. I
> was thrown a bit that
> it passed all the internal tests provided by the setup script, but failed
> on the web GUI. When
> I've seen 'unspecified GSS failure' and 'peer not authenticated' it's
> usually been due to
> Kerberos (though admittedly these are just generic errors). So I tried the
> Redhat guide for SSO at:
>
> https://access.redhat.com/documentation/en-US/Red_Hat_
> Enterprise_Virtualization/3.6/html/Administration_Guide/
> Configuring_LDAP_and_Kerberos_for_Single_Sign-on.html
>
> which uses Kerberos (in ovirt-sso.conf) I had to remove the symlink to the
> Apache
> config it says to create, as it results in internal server errors in
> Apache. It uses an SPN for
> Apache in the keytab.
>
> Now that you've confirmed that it can actually work without any need for
> the Kerberos stuff,
> I will start afresh from a clean setup and apply what I've learnt during
> this process.
>
> I'll try it out and let you know either way.
>
> Many thanks for all the help!
>
> Kind regards,
>
> Cam
>
>
>
>> Yes, you really do not need anything kerberos related to securely bind
>> to AD via LDAP simple bind over TLS/SSL. This is really strange to me
>> what errors you are getting, but you probably configured apache (or
>> something else?) to require keytab, but you don't have to, and you can
>> remove that configuration.
>>
>>
>>> Thanks,
>>>
>>> Cam
>>>
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Cam
>>>
>>> ___
>>>
>>> Users mailing list
>>> Users@ovirt.org 
>>> >
>>> http://lists.ovirt.org/mailman/listinfo/users
>>> 
>>> >> >
>>>
>>>
>>>
>>>
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Could not associate brick

[Davide Ferrari]

Yes, the brick on vm04.storage.billy correctly resolves in the
hosted-engine VM to 10.30.0.4, and that IP is set in the corresponding
hosts' bond1 (linked to the "gluster" network interface I created in
"Networks")

2016-10-14 13:06 GMT+02:00 knarra :

> On 10/14/2016 04:23 PM, Davide Ferrari wrote:
>
> Hello
>
> I'm seeing several ot these warnings:
>
> 2016-10-14 10:49:23,721 WARN  [org.ovirt.engine.core.vdsbroker.gluster.
> GlusterVolumesListReturnForXmlRpc] (DefaultQuartzScheduler7) [] Could not
> associate brick 'vm04.storage.billy:/gluster/ssd/data/brick' of volume
> '23f8f1ae-a3ac-47bf-8223-5b5f7c29e508' with correct network as no gluster
> network found in cluster '0002-0002-0002-0002-0345'
>
> I was reading this May thread
>
> http://lists.ovirt.org/pipermail/users/2016-May/040069.html
>
> but there is no final answer about how to solve this warning. As the other
> poster, I created the gluster network before installing ovirt (it's an
> hosted-engine installation) and I used DNS names to point to the bricks.
> DNS resolution is working correctly (every host has everthing in
> /etc/hosts).
>
> I also created a non-VM network and assigned it to every host's bond1 (the
> gluster network)
>
> How can I fix this?
>
> TIA
>
> --
> Davide Ferrari
> Senior Systems Engineer
>
>
> ___
> Users mailing listUsers@ovirt.orghttp://lists.ovirt.org/mailman/listinfo/users
>
> Hi David,
>
> you should not be seeing this error once the network with gluster role
> is been attached to every host in the system. Could you please check if
> your bricks are having the ip of what your bond1 network has ?
>
> Thanks
>
> kasturi.
>



-- 
Davide Ferrari
Senior Systems Engineer
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Could not associate brick

[knarra]

On 10/14/2016 04:23 PM, Davide Ferrari wrote:

Hello

I'm seeing several ot these warnings:

2016-10-14 10:49:23,721 WARN 
[org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListReturnForXmlRpc] 
(DefaultQuartzScheduler7) [] Could not associate brick 
'vm04.storage.billy:/gluster/ssd/data/brick' of volume 
'23f8f1ae-a3ac-47bf-8223-5b5f7c29e508' with correct network as no 
gluster network found in cluster '0002-0002-0002-0002-0345'


I was reading this May thread

http://lists.ovirt.org/pipermail/users/2016-May/040069.html

but there is no final answer about how to solve this warning. As the 
other poster, I created the gluster network before installing ovirt 
(it's an hosted-engine installation) and I used DNS names to point to 
the bricks. DNS resolution is working correctly (every host has 
everthing in /etc/hosts).


I also created a non-VM network and assigned it to every host's bond1 
(the gluster network)


How can I fix this?

TIA

--
Davide Ferrari
Senior Systems Engineer


___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Hi David,

you should not be seeing this error once the network with gluster 
role is been attached to every host in the system. Could you please 
check if your bricks are having the ip of what your bond1 network has ?


Thanks

kasturi.

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] Could not associate brick

[Davide Ferrari]

Hello

I'm seeing several ot these warnings:

2016-10-14 10:49:23,721 WARN
[org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListReturnForXmlRpc]
(DefaultQuartzScheduler7) [] Could not associate brick
'vm04.storage.billy:/gluster/ssd/data/brick' of volume
'23f8f1ae-a3ac-47bf-8223-5b5f7c29e508' with correct network as no gluster
network found in cluster '0002-0002-0002-0002-0345'

I was reading this May thread

http://lists.ovirt.org/pipermail/users/2016-May/040069.html

but there is no final answer about how to solve this warning. As the other
poster, I created the gluster network before installing ovirt (it's an
hosted-engine installation) and I used DNS names to point to the bricks.
DNS resolution is working correctly (every host has everthing in
/etc/hosts).

I also created a non-VM network and assigned it to every host's bond1 (the
gluster network)

How can I fix this?

TIA

-- 
Davide Ferrari
Senior Systems Engineer
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Ovirt Hypervisor vdsm.Scheduler logs fill partition

[Francesco Romani]

- Original Message -
> From: "Simone Tiraboschi" 
> To: "Steve Dainard" , "Francesco Romani" 
> 
> Cc: "users" 
> Sent: Friday, October 14, 2016 9:59:49 AM
> Subject: Re: [ovirt-users] Ovirt Hypervisor vdsm.Scheduler logs fill partition
> 
> On Fri, Oct 14, 2016 at 1:12 AM, Steve Dainard  wrote:
> 
> > Hello,
> >
> > I had a hypervisor semi-crash this week, 4 of ~10 VM's continued to run,
> > but the others were killed off somehow and all VM's running on this host
> > had '?' status in the ovirt UI.
> >
> > This appears to have been caused by vdsm logs filling up disk space on the
> > logging partition.
> >
> > I've attached the log file vdsm.log.27.xz which shows this error:
> >
> > vdsm.Scheduler::DEBUG::2016-10-11
> > 16:42:09,318::executor::216::Executor::(_discard)
> > Worker discarded:  > action= > 'virt.periodic.DriveWatermarkMonitor'>
> > at 0x7f8e90021210> at 0x7f8e90021250> discarded at 0x7f8dd123e850>
> >
> > which happens more and more frequently throughout the log.
> >
> > It was a bit difficult to understand what caused the failure, but the logs
> > were getting really large, then being xz'd which compressed 11G+ into a few
> > MB. Once this happened the disk space would be freed, and nagios wouldn't
> > hit the 3rd check to throw a warning, until pretty much right at the crash.
> >
> > I was able to restart vdsmd to resolve the issue, but I still need to know
> > why these logs started to stack up so I can avoid this issue in the future.
> >
> 
> We had this one: https://bugzilla.redhat.com/show_bug.cgi?id=1383259
> but in your case the logs are rotating.
> Francesco?

Hi,

yes, it is a different issue. Here the log messages are caused by the Worker 
threads
of the periodic subsystem, which are leaking[1].
This was a bug in Vdsm (insufficient protection against rogue domains), but the
real problem is that some of your domain are being unresponsive at hypervisor 
level.
The most likely cause is in turn unresponsive storages.

Fixes are been committed and shipped with Vdsm 4.17.34.

See: ttps://bugzilla.redhat.com/1364925

HTH,

+++

[1] actually, they are replaced too quickly, leading to unbound growth.
So those aren't actually "leaking", Vdsm is just overzealous handling one error 
condition,
making things worse than before.
Still serious issue, no doubt, but quite different cause.

-- 
Francesco Romani
Red Hat Engineering Virtualization R & D
Phone: 8261328
IRC: fromani
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Ovirt Hypervisor vdsm.Scheduler logs fill partition

[Simone Tiraboschi]

On Fri, Oct 14, 2016 at 1:12 AM, Steve Dainard  wrote:

> Hello,
>
> I had a hypervisor semi-crash this week, 4 of ~10 VM's continued to run,
> but the others were killed off somehow and all VM's running on this host
> had '?' status in the ovirt UI.
>
> This appears to have been caused by vdsm logs filling up disk space on the
> logging partition.
>
> I've attached the log file vdsm.log.27.xz which shows this error:
>
> vdsm.Scheduler::DEBUG::2016-10-11 
> 16:42:09,318::executor::216::Executor::(_discard)
> Worker discarded:  action=
> at 0x7f8e90021210> at 0x7f8e90021250> discarded at 0x7f8dd123e850>
>
> which happens more and more frequently throughout the log.
>
> It was a bit difficult to understand what caused the failure, but the logs
> were getting really large, then being xz'd which compressed 11G+ into a few
> MB. Once this happened the disk space would be freed, and nagios wouldn't
> hit the 3rd check to throw a warning, until pretty much right at the crash.
>
> I was able to restart vdsmd to resolve the issue, but I still need to know
> why these logs started to stack up so I can avoid this issue in the future.
>

We had this one: https://bugzilla.redhat.com/show_bug.cgi?id=1383259
but in your case the logs are rotating.
Francesco?


>
> Hypervisor host info:
> CentOS 7
> # rpm -qa | grep vdsm
> vdsm-yajsonrpc-4.17.32-1.el7.noarch
> vdsm-xmlrpc-4.17.32-1.el7.noarch
> vdsm-infra-4.17.32-1.el7.noarch
> vdsm-hook-vmfex-dev-4.17.32-1.el7.noarch
> vdsm-python-4.17.32-1.el7.noarch
> vdsm-4.17.32-1.el7.noarch
> vdsm-cli-4.17.32-1.el7.noarch
> vdsm-jsonrpc-4.17.32-1.el7.noarch
>
> Engine host info:
> CentOS 7
> $ rpm -qa | grep ovirt
> ovirt-engine-lib-3.6.7.5-1.el7.centos.noarch
> ovirt-iso-uploader-3.6.0-1.el7.centos.noarch
> ovirt-engine-wildfly-overlay-8.0.5-1.el7.noarch
> ovirt-engine-webadmin-portal-3.6.7.5-1.el7.centos.noarch
> ovirt-engine-jboss-as-7.1.1-1.el7.x86_64
> ovirt-engine-setup-plugin-vmconsole-proxy-helper-3.6.7.
> 5-1.el7.centos.noarch
> ovirt-host-deploy-1.4.1-1.el7.centos.noarch
> ovirt-engine-vmconsole-proxy-helper-3.6.7.5-1.el7.centos.noarch
> ovirt-engine-backend-3.6.7.5-1.el7.centos.noarch
> ovirt-setup-lib-1.0.1-1.el7.centos.noarch
> ovirt-engine-setup-plugin-websocket-proxy-3.6.7.5-1.el7.centos.noarch
> ovirt-engine-websocket-proxy-3.6.7.5-1.el7.centos.noarch
> ovirt-engine-tools-3.6.7.5-1.el7.centos.noarch
> ovirt-engine-setup-base-3.6.7.5-1.el7.centos.noarch
> ovirt-engine-setup-3.6.7.5-1.el7.centos.noarch
> ovirt-vmconsole-1.0.2-1.el7.centos.noarch
> ovirt-engine-wildfly-8.2.1-1.el7.x86_64
> ovirt-engine-tools-backup-3.6.7.5-1.el7.centos.noarch
> ovirt-engine-userportal-3.6.7.5-1.el7.centos.noarch
> ovirt-engine-3.6.7.5-1.el7.centos.noarch
> ovirt-release35-006-1.noarch
> ovirt-engine-extension-aaa-ldap-1.1.0-0.0.master.
> 20151021074904.git92c5c31.el7.noarch
> ovirt-release36-3.6.7-1.noarch
> ovirt-engine-setup-plugin-ovirt-engine-3.6.7.5-1.el7.centos.noarch
> ovirt-host-deploy-java-1.4.1-1.el7.centos.noarch
> ovirt-image-uploader-3.6.0-1.el7.centos.noarch
> ovirt-engine-dbscripts-3.6.7.5-1.el7.centos.noarch
> ovirt-engine-sdk-python-3.6.3.0-1.el7.noarch
> ovirt-engine-extension-aaa-jdbc-1.0.7-1.el7.noarch
> ovirt-engine-extensions-api-impl-3.6.7.5-1.el7.centos.noarch
> ovirt-engine-restapi-3.6.7.5-1.el7.centos.noarch
> ovirt-engine-setup-plugin-ovirt-engine-common-3.6.7.5-1.el7.centos.noarch
> ovirt-vmconsole-proxy-1.0.2-1.el7.centos.noarch
> ovirt-engine-cli-3.6.2.0-1.el7.centos.noarch
>
>
> Thanks,
> Steve
>
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users