Re: [Users] LDAP
On 02/26/2012 09:46 AM, Yair Zaslavsky wrote: On 02/26/2012 09:45 AM, Yair Zaslavsky wrote: On 02/26/2012 09:18 AM, Oved Ourfalli wrote: Found the problem. We are identifying if the LDAP server is AD or not by checking if the root DSE contains the "defaultNamingContext" attribute. This attribute is not in the LDAP standard, thus it appears in AD, and not in IPA and RHDS... Looking at the rootDSE you provided it looks like it was added to IPA, therefore we identify it as AD. Can you open us a bug on that upstream? Given that issue, I think we should also provide a way to set the ldap provider type (using the engine-manage-domains utility), in order to workaround such issues in the future. Don't you think that now this key (i.e providerType=IPA) kinda becomes mandatory? Or actually, maybe we should have it optional - if set - then this value will be used for providerType, if not - our "auto-deduction" mechanism takes place. Thoughts? Drop the auto-detection. Y. Thank you, Oved - Original Message - From: "Nathan Stratton" To: "Oved Ourfalli" Cc: users@ovirt.org Sent: Friday, February 24, 2012 8:31:02 PM Subject: Re: [Users] LDAP On Fri, 24 Feb 2012, Oved Ourfalli wrote: The identification of the provider type is done using the following logic, according to the results from the root DSE query: * if it contains a defaultNamingContext attribute --> AD * else * Check the vendorName attribute * if it is "389 Project" then it is IPA * if it is "Red Hat" then it is RHDS. We added support for AD, IPA and RHDS. I guess that 389ds has a different vendor name. What does your root DSE query show? You can run it using ldapsearch, with the options" -LLL -Y GSSAPI -D -h -b "" -s base objectClass=* the distinguished name will be something like: uid=username,dc=example,dc=com [root@ipa-master ~]# ldapsearch -LLL -Y GSSAPI -D uid=nathan,cn=users,cn=accounts,dc=blinkmind,dc=net -h localhost -b "" -s base objectClass=* SASL/GSSAPI authentication started SASL username: ad...@blinkmind.net SASL SSF: 56 SASL data security layer installed. dn: objectClass: top namingContexts: dc=blinkmind,dc=net defaultnamingcontext: dc=blinkmind,dc=net supportedExtension: 2.16.840.1.113730.3.5.7 supportedExtension: 2.16.840.1.113730.3.5.8 supportedExtension: 2.16.840.1.113730.3.5.10 supportedExtension: 2.16.840.1.113730.3.8.10.3 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedExtension: 2.16.840.1.113730.3.8.10.1 supportedExtension: 2.16.840.1.113730.3.5.3 supportedExtension: 2.16.840.1.113730.3.5.12 supportedExtension: 2.16.840.1.113730.3.5.5 supportedExtension: 2.16.840.1.113730.3.5.6 supportedExtension: 2.16.840.1.113730.3.5.9 supportedExtension: 2.16.840.1.113730.3.5.4 supportedExtension: 1.3.6.1.4.1.1466.20037 supportedControl: 2.16.840.1.113730.3.4.2 supportedControl: 2.16.840.1.113730.3.4.3 supportedControl: 2.16.840.1.113730.3.4.4 supportedControl: 2.16.840.1.113730.3.4.5 supportedControl: 1.2.840.113556.1.4.473 supportedControl: 2.16.840.1.113730.3.4.9 supportedControl: 2.16.840.1.113730.3.4.16 supportedControl: 2.16.840.1.113730.3.4.15 supportedControl: 2.16.840.1.113730.3.4.17 supportedControl: 2.16.840.1.113730.3.4.19 supportedControl: 1.3.6.1.4.1.42.2.27.8.5.1 supportedControl: 1.3.6.1.4.1.42.2.27.9.5.2 supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.3.6.1.4.1.42.2.27.9.5.8 supportedControl: 1.3.6.1.4.1.4203.666.5.16 supportedControl: 2.16.840.1.113730.3.4.14 supportedControl: 2.16.840.1.113730.3.4.20 supportedControl: 1.3.6.1.4.1.1466.29539.12 supportedControl: 2.16.840.1.113730.3.4.12 supportedControl: 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.13 supportedSASLMechanisms: EXTERNAL supportedSASLMechanisms: PLAIN supportedSASLMechanisms: GSSAPI supportedSASLMechanisms: ANONYMOUS supportedSASLMechanisms: CRAM-MD5 supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: LOGIN supportedLDAPVersion: 2 supportedLDAPVersion: 3 vendorName: 389 Project vendorVersion: 389-Directory/1.2.10.rc1 B2012.035.328 dataversion: 020120223201756 netscapemdsuffix: cn=ldap://dc=ipa-master,dc=blinkmind,dc=net:389 lastusn: 468 It will help us understand which vendor name is shown in your ldap server, and we might use it in order to improve the identification. It surprises me that IPA is not identified correctly, as "389 Project" is the vendor name that was used there (unless it was changed). As for 389ds, as I said before we added RHDS support, so there might be changes in the schema, and also probably the vendor name there is not "Red Hat". Looks like "389 Project" However I still see: -bash-4.2# engine-manage-domains -action=add -domain=blinkmind.net -user=nathan -interactive Enter password: No user in Directory was found for nat...@blinkmind.net. Trying next LDAP server in list Failure while testing domain blinkmind.net. Details: No user information was found for user On my FreeIPA server I see: [24/Feb/2012:18:28:46 +] conn=144 op=3 SRCH base="dc=blinkmind,d
Re: [Users] LDAP
On 02/26/2012 09:45 AM, Yair Zaslavsky wrote: > On 02/26/2012 09:18 AM, Oved Ourfalli wrote: >> Found the problem. >> We are identifying if the LDAP server is AD or not by checking if the root >> DSE contains the "defaultNamingContext" attribute. >> This attribute is not in the LDAP standard, thus it appears in AD, and not >> in IPA and RHDS... >> >> Looking at the rootDSE you provided it looks like it was added to IPA, >> therefore we identify it as AD. >> >> Can you open us a bug on that upstream? >> Given that issue, I think we should also provide a way to set the ldap >> provider type (using the engine-manage-domains utility), in order to >> workaround such issues in the future. > Don't you think that now this key (i.e providerType=IPA) kinda becomes > mandatory? Or actually, maybe we should have it optional - if set - then this value will be used for providerType, if not - our "auto-deduction" mechanism takes place. Thoughts? > >> >> Thank you, >> Oved >> >> - Original Message - >>> From: "Nathan Stratton" >>> To: "Oved Ourfalli" >>> Cc: users@ovirt.org >>> Sent: Friday, February 24, 2012 8:31:02 PM >>> Subject: Re: [Users] LDAP >>> >>> On Fri, 24 Feb 2012, Oved Ourfalli wrote: >>> The identification of the provider type is done using the following logic, according to the results from the root DSE query: * if it contains a defaultNamingContext attribute --> AD * else * Check the vendorName attribute * if it is "389 Project" then it is IPA * if it is "Red Hat" then it is RHDS. We added support for AD, IPA and RHDS. I guess that 389ds has a different vendor name. What does your root DSE query show? You can run it using ldapsearch, with the options" -LLL -Y GSSAPI -D -h -b "" -s base objectClass=* the distinguished name will be something like: uid=username,dc=example,dc=com >>> >>> [root@ipa-master ~]# ldapsearch -LLL -Y GSSAPI -D >>> uid=nathan,cn=users,cn=accounts,dc=blinkmind,dc=net -h localhost -b >>> "" -s >>> base objectClass=* >>> SASL/GSSAPI authentication started >>> SASL username: ad...@blinkmind.net >>> SASL SSF: 56 >>> SASL data security layer installed. >>> dn: >>> objectClass: top >>> namingContexts: dc=blinkmind,dc=net >>> defaultnamingcontext: dc=blinkmind,dc=net >>> supportedExtension: 2.16.840.1.113730.3.5.7 >>> supportedExtension: 2.16.840.1.113730.3.5.8 >>> supportedExtension: 2.16.840.1.113730.3.5.10 >>> supportedExtension: 2.16.840.1.113730.3.8.10.3 >>> supportedExtension: 1.3.6.1.4.1.4203.1.11.1 >>> supportedExtension: 2.16.840.1.113730.3.8.10.1 >>> supportedExtension: 2.16.840.1.113730.3.5.3 >>> supportedExtension: 2.16.840.1.113730.3.5.12 >>> supportedExtension: 2.16.840.1.113730.3.5.5 >>> supportedExtension: 2.16.840.1.113730.3.5.6 >>> supportedExtension: 2.16.840.1.113730.3.5.9 >>> supportedExtension: 2.16.840.1.113730.3.5.4 >>> supportedExtension: 1.3.6.1.4.1.1466.20037 >>> supportedControl: 2.16.840.1.113730.3.4.2 >>> supportedControl: 2.16.840.1.113730.3.4.3 >>> supportedControl: 2.16.840.1.113730.3.4.4 >>> supportedControl: 2.16.840.1.113730.3.4.5 >>> supportedControl: 1.2.840.113556.1.4.473 >>> supportedControl: 2.16.840.1.113730.3.4.9 >>> supportedControl: 2.16.840.1.113730.3.4.16 >>> supportedControl: 2.16.840.1.113730.3.4.15 >>> supportedControl: 2.16.840.1.113730.3.4.17 >>> supportedControl: 2.16.840.1.113730.3.4.19 >>> supportedControl: 1.3.6.1.4.1.42.2.27.8.5.1 >>> supportedControl: 1.3.6.1.4.1.42.2.27.9.5.2 >>> supportedControl: 1.2.840.113556.1.4.319 >>> supportedControl: 1.3.6.1.4.1.42.2.27.9.5.8 >>> supportedControl: 1.3.6.1.4.1.4203.666.5.16 >>> supportedControl: 2.16.840.1.113730.3.4.14 >>> supportedControl: 2.16.840.1.113730.3.4.20 >>> supportedControl: 1.3.6.1.4.1.1466.29539.12 >>> supportedControl: 2.16.840.1.113730.3.4.12 >>> supportedControl: 2.16.840.1.113730.3.4.18 >>> supportedControl: 2.16.840.1.113730.3.4.13 >>> supportedSASLMechanisms: EXTERNAL >>> supportedSASLMechanisms: PLAIN >>> supportedSASLMechanisms: GSSAPI >>> supportedSASLMechanisms: ANONYMOUS >>> supportedSASLMechanisms: CRAM-MD5 >>> supportedSASLMechanisms: DIGEST-MD5 >>> supportedSASLMechanisms: LOGIN >>> supportedLDAPVersion: 2 >>> supportedLDAPVersion: 3 >>> vendorName: 389 Project >>> vendorVersion: 389-Directory/1.2.10.rc1 B2012.035.328 >>> dataversion: 020120223201756 >>> netscapemdsuffix: cn=ldap://dc=ipa-master,dc=blinkmind,dc=net:389 >>> lastusn: 468 >>> >>> It will help us understand which vendor name is shown in your ldap server, and we might use it in order to improve the identification. It surprises me that IPA is not identified correctly, as "389 Project" is the vendor name that was used there (unless it was changed). As for 389ds, as I said before we added RHDS support, so there might be changes in the schema, and also probably the vendor name there is not "Red Hat". >>> >>> Looks like "389 Project" >>> >>> However I
Re: [Users] LDAP
On 02/26/2012 09:18 AM, Oved Ourfalli wrote: > Found the problem. > We are identifying if the LDAP server is AD or not by checking if the root > DSE contains the "defaultNamingContext" attribute. > This attribute is not in the LDAP standard, thus it appears in AD, and not in > IPA and RHDS... > > Looking at the rootDSE you provided it looks like it was added to IPA, > therefore we identify it as AD. > > Can you open us a bug on that upstream? > Given that issue, I think we should also provide a way to set the ldap > provider type (using the engine-manage-domains utility), in order to > workaround such issues in the future. Don't you think that now this key (i.e providerType=IPA) kinda becomes mandatory? > > Thank you, > Oved > > - Original Message - >> From: "Nathan Stratton" >> To: "Oved Ourfalli" >> Cc: users@ovirt.org >> Sent: Friday, February 24, 2012 8:31:02 PM >> Subject: Re: [Users] LDAP >> >> On Fri, 24 Feb 2012, Oved Ourfalli wrote: >> >>> The identification of the provider type is done using the following >>> logic, according to the results from the root DSE query: >>> * if it contains a defaultNamingContext attribute --> AD >>> * else >>> * Check the vendorName attribute >>> * if it is "389 Project" then it is IPA >>> * if it is "Red Hat" then it is RHDS. >>> >>> We added support for AD, IPA and RHDS. I guess that 389ds has a >>> different vendor name. >>> >>> What does your root DSE query show? >>> You can run it using ldapsearch, with the options" -LLL -Y GSSAPI >>> -D -h -b "" -s >>> base objectClass=* >>> >>> the distinguished name will be something like: >>> uid=username,dc=example,dc=com >> >> [root@ipa-master ~]# ldapsearch -LLL -Y GSSAPI -D >> uid=nathan,cn=users,cn=accounts,dc=blinkmind,dc=net -h localhost -b >> "" -s >> base objectClass=* >> SASL/GSSAPI authentication started >> SASL username: ad...@blinkmind.net >> SASL SSF: 56 >> SASL data security layer installed. >> dn: >> objectClass: top >> namingContexts: dc=blinkmind,dc=net >> defaultnamingcontext: dc=blinkmind,dc=net >> supportedExtension: 2.16.840.1.113730.3.5.7 >> supportedExtension: 2.16.840.1.113730.3.5.8 >> supportedExtension: 2.16.840.1.113730.3.5.10 >> supportedExtension: 2.16.840.1.113730.3.8.10.3 >> supportedExtension: 1.3.6.1.4.1.4203.1.11.1 >> supportedExtension: 2.16.840.1.113730.3.8.10.1 >> supportedExtension: 2.16.840.1.113730.3.5.3 >> supportedExtension: 2.16.840.1.113730.3.5.12 >> supportedExtension: 2.16.840.1.113730.3.5.5 >> supportedExtension: 2.16.840.1.113730.3.5.6 >> supportedExtension: 2.16.840.1.113730.3.5.9 >> supportedExtension: 2.16.840.1.113730.3.5.4 >> supportedExtension: 1.3.6.1.4.1.1466.20037 >> supportedControl: 2.16.840.1.113730.3.4.2 >> supportedControl: 2.16.840.1.113730.3.4.3 >> supportedControl: 2.16.840.1.113730.3.4.4 >> supportedControl: 2.16.840.1.113730.3.4.5 >> supportedControl: 1.2.840.113556.1.4.473 >> supportedControl: 2.16.840.1.113730.3.4.9 >> supportedControl: 2.16.840.1.113730.3.4.16 >> supportedControl: 2.16.840.1.113730.3.4.15 >> supportedControl: 2.16.840.1.113730.3.4.17 >> supportedControl: 2.16.840.1.113730.3.4.19 >> supportedControl: 1.3.6.1.4.1.42.2.27.8.5.1 >> supportedControl: 1.3.6.1.4.1.42.2.27.9.5.2 >> supportedControl: 1.2.840.113556.1.4.319 >> supportedControl: 1.3.6.1.4.1.42.2.27.9.5.8 >> supportedControl: 1.3.6.1.4.1.4203.666.5.16 >> supportedControl: 2.16.840.1.113730.3.4.14 >> supportedControl: 2.16.840.1.113730.3.4.20 >> supportedControl: 1.3.6.1.4.1.1466.29539.12 >> supportedControl: 2.16.840.1.113730.3.4.12 >> supportedControl: 2.16.840.1.113730.3.4.18 >> supportedControl: 2.16.840.1.113730.3.4.13 >> supportedSASLMechanisms: EXTERNAL >> supportedSASLMechanisms: PLAIN >> supportedSASLMechanisms: GSSAPI >> supportedSASLMechanisms: ANONYMOUS >> supportedSASLMechanisms: CRAM-MD5 >> supportedSASLMechanisms: DIGEST-MD5 >> supportedSASLMechanisms: LOGIN >> supportedLDAPVersion: 2 >> supportedLDAPVersion: 3 >> vendorName: 389 Project >> vendorVersion: 389-Directory/1.2.10.rc1 B2012.035.328 >> dataversion: 020120223201756 >> netscapemdsuffix: cn=ldap://dc=ipa-master,dc=blinkmind,dc=net:389 >> lastusn: 468 >> >> >>> It will help us understand which vendor name is shown in your ldap >>> server, and we might use it in order to improve the >>> identification. >>> >>> It surprises me that IPA is not identified correctly, as "389 >>> Project" is the vendor name that was used there (unless it was >>> changed). >>> As for 389ds, as I said before we added RHDS support, so there >>> might be changes in the schema, and also probably the vendor name >>> there is not "Red Hat". >> >> Looks like "389 Project" >> >> However I still see: >> >> -bash-4.2# engine-manage-domains -action=add -domain=blinkmind.net >> -user=nathan -interactive >> Enter password: >> >> No user in Directory was found for nat...@blinkmind.net. Trying next >> LDAP server in list >> Failure while testing domain blinkmind.net. Details: No user >> information was found for user >> >> >> On
Re: [Users] LDAP
Found the problem. We are identifying if the LDAP server is AD or not by checking if the root DSE contains the "defaultNamingContext" attribute. This attribute is not in the LDAP standard, thus it appears in AD, and not in IPA and RHDS... Looking at the rootDSE you provided it looks like it was added to IPA, therefore we identify it as AD. Can you open us a bug on that upstream? Given that issue, I think we should also provide a way to set the ldap provider type (using the engine-manage-domains utility), in order to workaround such issues in the future. Thank you, Oved - Original Message - > From: "Nathan Stratton" > To: "Oved Ourfalli" > Cc: users@ovirt.org > Sent: Friday, February 24, 2012 8:31:02 PM > Subject: Re: [Users] LDAP > > On Fri, 24 Feb 2012, Oved Ourfalli wrote: > > > The identification of the provider type is done using the following > > logic, according to the results from the root DSE query: > > * if it contains a defaultNamingContext attribute --> AD > > * else > > * Check the vendorName attribute > > * if it is "389 Project" then it is IPA > > * if it is "Red Hat" then it is RHDS. > > > > We added support for AD, IPA and RHDS. I guess that 389ds has a > > different vendor name. > > > > What does your root DSE query show? > > You can run it using ldapsearch, with the options" -LLL -Y GSSAPI > > -D -h -b "" -s > > base objectClass=* > > > > the distinguished name will be something like: > > uid=username,dc=example,dc=com > > [root@ipa-master ~]# ldapsearch -LLL -Y GSSAPI -D > uid=nathan,cn=users,cn=accounts,dc=blinkmind,dc=net -h localhost -b > "" -s > base objectClass=* > SASL/GSSAPI authentication started > SASL username: ad...@blinkmind.net > SASL SSF: 56 > SASL data security layer installed. > dn: > objectClass: top > namingContexts: dc=blinkmind,dc=net > defaultnamingcontext: dc=blinkmind,dc=net > supportedExtension: 2.16.840.1.113730.3.5.7 > supportedExtension: 2.16.840.1.113730.3.5.8 > supportedExtension: 2.16.840.1.113730.3.5.10 > supportedExtension: 2.16.840.1.113730.3.8.10.3 > supportedExtension: 1.3.6.1.4.1.4203.1.11.1 > supportedExtension: 2.16.840.1.113730.3.8.10.1 > supportedExtension: 2.16.840.1.113730.3.5.3 > supportedExtension: 2.16.840.1.113730.3.5.12 > supportedExtension: 2.16.840.1.113730.3.5.5 > supportedExtension: 2.16.840.1.113730.3.5.6 > supportedExtension: 2.16.840.1.113730.3.5.9 > supportedExtension: 2.16.840.1.113730.3.5.4 > supportedExtension: 1.3.6.1.4.1.1466.20037 > supportedControl: 2.16.840.1.113730.3.4.2 > supportedControl: 2.16.840.1.113730.3.4.3 > supportedControl: 2.16.840.1.113730.3.4.4 > supportedControl: 2.16.840.1.113730.3.4.5 > supportedControl: 1.2.840.113556.1.4.473 > supportedControl: 2.16.840.1.113730.3.4.9 > supportedControl: 2.16.840.1.113730.3.4.16 > supportedControl: 2.16.840.1.113730.3.4.15 > supportedControl: 2.16.840.1.113730.3.4.17 > supportedControl: 2.16.840.1.113730.3.4.19 > supportedControl: 1.3.6.1.4.1.42.2.27.8.5.1 > supportedControl: 1.3.6.1.4.1.42.2.27.9.5.2 > supportedControl: 1.2.840.113556.1.4.319 > supportedControl: 1.3.6.1.4.1.42.2.27.9.5.8 > supportedControl: 1.3.6.1.4.1.4203.666.5.16 > supportedControl: 2.16.840.1.113730.3.4.14 > supportedControl: 2.16.840.1.113730.3.4.20 > supportedControl: 1.3.6.1.4.1.1466.29539.12 > supportedControl: 2.16.840.1.113730.3.4.12 > supportedControl: 2.16.840.1.113730.3.4.18 > supportedControl: 2.16.840.1.113730.3.4.13 > supportedSASLMechanisms: EXTERNAL > supportedSASLMechanisms: PLAIN > supportedSASLMechanisms: GSSAPI > supportedSASLMechanisms: ANONYMOUS > supportedSASLMechanisms: CRAM-MD5 > supportedSASLMechanisms: DIGEST-MD5 > supportedSASLMechanisms: LOGIN > supportedLDAPVersion: 2 > supportedLDAPVersion: 3 > vendorName: 389 Project > vendorVersion: 389-Directory/1.2.10.rc1 B2012.035.328 > dataversion: 020120223201756 > netscapemdsuffix: cn=ldap://dc=ipa-master,dc=blinkmind,dc=net:389 > lastusn: 468 > > > > It will help us understand which vendor name is shown in your ldap > > server, and we might use it in order to improve the > > identification. > > > > It surprises me that IPA is not identified correctly, as "389 > > Project" is the vendor name that was used there (unless it was > > changed). > > As for 389ds, as I said before we added RHDS support, so there > > might be changes in the schema, and also probably the vendor name > > there is not "Red Hat". > > Looks like "389 Project" > > However I still see: > > -bash-4.2# engine-manage-domains -action=add -domain=blinkmind.net > -user=nathan -interactive > Enter password: > > No user in Directory was found for nat...@blinkmind.net. Trying next > LDAP server in list > Failure while testing domain blinkmind.net. Details: No user > information was found for user > > > On my FreeIPA server I see: > > [24/Feb/2012:18:28:46 +] conn=144 op=3 SRCH > base="dc=blinkmind,dc=net" > scope=2 > filter="(&(samaccounttype=805306368)(userprincipalname=nat...@blinkmind.net))" > attrs="nsUniqueId ipaUniqueID objectguid
Re: [Users] Uploaded ISO file doesn't show up in admin portal
On 02/25/2012 06:57 PM, Terry Phelps wrote: On Sat, Feb 25, 2012 at 5:13 AM, Maor mailto:mlipc...@redhat.com>> wrote: Hi Spyro, thanks for the advice, I didn't tried this approach before, but its definitely worth trying if it solved your problem. I was thinking first, trying some little troubleshooting, Terry, I saw in one response, part of this thread, you were added a file named "me", by touching it in the ISO mounted directory. Can you please try the following: mv me me.iso sudo chown 36:36 me.iso #(36:36 equals to vdsm:kvm) and then try to run getIsoList as before: vdsClient -s 0 getIsoList 9775f154-7578-4e22-ae44-4664b298a8cc If it still didn't return any files, try changing the file mode (just a hunch on this) sudo chmod 666 me.iso Hope it works, if it does, we can try to troubleshooting the other files. Hey, this DID work: vdsClient -s 0 getConnectedStoragePoolsList f465251e-5679-11e1-ba81-97917332892e [root@oravm2 ----]# vdsClient -s 0 getIsoList f465251e-5679-11e1-ba81-97917332892e -- ISO list with proper permissions only --- me.iso An "ls -l" shows: # ls -l total 3507192 -rw-r--r--. 1 4294967294 4294967294 0 Feb 25 16:26 me.iso -rw-r-. 1 4294967294 4294967294 3591360512 Feb 24 14:14 OracleLinux-R6-U2-Server-x86_64-dvd.iso The only difference I can see is the 644 and 640 permissions. Let me change the real .iso to 644 and see what happens. I changed the permissions to be both 644 on the ovirt engine, but when I look at the node, the permissions on the real ISO file is still 640. And vdsClient doesn't show it. Oh, wait! I ran the above vdsClient and "ls -l" as root on the node. root could not change the permissions on the ISO, so I switched to run as vdsm. When I look at things when running as vdsm, both the permissions and vdsClient look the same for both files: bash-4.2$ ls -l total 3507192 -rw-r--r--. 1 4294967294 4294967294 0 Feb 25 16:26 me.iso -rw-r--r--. 1 4294967294 4294967294 3591360512 Feb 24 14:14 OracleLinux-R6-U2-Server-x86_64-dvd.iso bash-4.2$ history|grep vdsC 34 history|grep vdsC bash-4.2$ vdsClient -s 0 getIsoList f465251e-5679-11e1-ba81-97917332892e -- ISO list with proper permissions only --- me.iso OracleLinux-R6-U2-Server-x86_64-dvd.iso Oh! I just looked back at the admin portal, and it sees both ISO files now. But I haven't touched the real one that I never could see all along. Now, I'm really confused, so let me summarize what I did: From the ovirt-engine, I did "touch me.iso" to create a new iso file, and did a chown to 36:36. The me.iso, and NOT the real one, showed up in the admin portal. From the node, as root, I did the "ls -l" which showed me.iso with permissions as 644, but the real ISO showed 640. From the node, I tried, as root, to change the real ISO permissions to 644. It wouldn't let me. From the node, I switched to run as vdsm, to try to change the permissions. But, as vdsm, "ls -l" showed both files as 644. I looked back at admin portal, after doing all this, and refereshed the ISODomain images panel. BOTH files showed up. As best I can tell, the only thing I did was to manually create the me.iso file and do the chown. well, i assume this isn't relevant since it took you enough time, but adding the iso to the domain manually won't make it appear in the UI for a few minutes until the refresh happens, less you click the refresh button manually in the UI (I could be wrong - details around the implementation of how/when iso list is refreshed have been changed recently) ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Problems attaching ISO Domain to second dc
On 02/24/2012 07:49 PM, Deepak C Shetty wrote: On 02/24/2012 09:57 PM, Itamar Heim wrote: On 02/24/2012 02:52 PM, Deepak C Shetty wrote: On 02/23/2012 06:21 PM, Deepak C Shetty wrote: Hi, I had one iso domain attached to a DC (nfs based). I had second DC (fc based) and wanted to share the same iso domain as above. When i tried to attach the same ISO domain to the fc dc, it failed and all the other storage domains (data and master, nfs based) present in the nfs dc, went down/inactive. for some time i could see the status as "Contend" ( dont remember if it was against the storage domains or dc overall) ISO storage domains (backed by nfs) should be able to be attached to more than 1 dc.. but it failed for me... what could be the reason ? Hello, Is attaching 1 ISO to multiple DC's supported or not ? supported So i have 2 dc's NFS and FC based, i have a iso domain ( backed by nfs) currently attached to NFS dc, but when i try to attach the same iso domain to fc dc, it appears on the UI , with Locked as status for a while and then dissapears... is there something that i am missing ? don't think so. tail -f of backend and vdsm logs from when you are doing the attach operation i guess ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Uploaded ISO file doesn't show up in admin portal
On Sat, Feb 25, 2012 at 5:13 AM, Maor wrote: > Hi Spyro, thanks for the advice, > I didn't tried this approach before, but its definitely worth trying if > it solved your problem. > > I was thinking first, trying some little troubleshooting, > Terry, I saw in one response, part of this thread, you were added a file > named "me", by touching it in the ISO mounted directory. > Can you please try the following: > mv me me.iso > sudo chown 36:36 me.iso #(36:36 equals to vdsm:kvm) > and then try to run getIsoList as before: > vdsClient -s 0 getIsoList 9775f154-7578-4e22-ae44-4664b298a8cc > > If it still didn't return any files, try changing the file mode (just a > hunch on this) > sudo chmod 666 me.iso > > Hope it works, if it does, we can try to troubleshooting the other files. > > Hey, this DID work: vdsClient -s 0 getConnectedStoragePoolsList f465251e-5679-11e1-ba81-97917332892e [root@oravm2 ----]# vdsClient -s 0 getIsoList f465251e-5679-11e1-ba81-97917332892e -- ISO list with proper permissions only --- me.iso An "ls -l" shows: # ls -l total 3507192 -rw-r--r--. 1 4294967294 4294967294 0 Feb 25 16:26 me.iso -rw-r-. 1 4294967294 4294967294 3591360512 Feb 24 14:14 OracleLinux-R6-U2-Server-x86_64-dvd.iso The only difference I can see is the 644 and 640 permissions. Let me change the real .iso to 644 and see what happens. I changed the permissions to be both 644 on the ovirt engine, but when I look at the node, the permissions on the real ISO file is still 640. And vdsClient doesn't show it. Oh, wait! I ran the above vdsClient and "ls -l" as root on the node. root could not change the permissions on the ISO, so I switched to run as vdsm. When I look at things when running as vdsm, both the permissions and vdsClient look the same for both files: bash-4.2$ ls -l total 3507192 -rw-r--r--. 1 4294967294 4294967294 0 Feb 25 16:26 me.iso -rw-r--r--. 1 4294967294 4294967294 3591360512 Feb 24 14:14 OracleLinux-R6-U2-Server-x86_64-dvd.iso bash-4.2$ history|grep vdsC 34 history|grep vdsC bash-4.2$ vdsClient -s 0 getIsoList f465251e-5679-11e1-ba81-97917332892e -- ISO list with proper permissions only --- me.iso OracleLinux-R6-U2-Server-x86_64-dvd.iso Oh! I just looked back at the admin portal, and it sees both ISO files now. But I haven't touched the real one that I never could see all along. Now, I'm really confused, so let me summarize what I did: >From the ovirt-engine, I did "touch me.iso" to create a new iso file, and did a chown to 36:36. The me.iso, and NOT the real one, showed up in the admin portal. >From the node, as root, I did the "ls -l" which showed me.iso with permissions as 644, but the real ISO showed 640. >From the node, I tried, as root, to change the real ISO permissions to 644. It wouldn't let me. >From the node, I switched to run as vdsm, to try to change the permissions. But, as vdsm, "ls -l" showed both files as 644. I looked back at admin portal, after doing all this, and refereshed the ISODomain images panel. BOTH files showed up. As best I can tell, the only thing I did was to manually create the me.iso file and do the chown. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[Users] Documentation
Hi, I`m new in ovirt world. I found the instalation guide and now I would like to know where do I find users guide, administration guide and so on. Thank`s in advance for your help. Regards, -- Xyko ( José Francisco Ribeiro Neto ) ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Uploaded ISO file doesn't show up in admin portal
Hi Spyro, thanks for the advice,
I didn't tried this approach before, but its definitely worth trying if
it solved your problem.
I was thinking first, trying some little troubleshooting,
Terry, I saw in one response, part of this thread, you were added a file
named "me", by touching it in the ISO mounted directory.
Can you please try the following:
mv me me.iso
sudo chown 36:36 me.iso #(36:36 equals to vdsm:kvm)
and then try to run getIsoList as before:
vdsClient -s 0 getIsoList 9775f154-7578-4e22-ae44-4664b298a8cc
If it still didn't return any files, try changing the file mode (just a
hunch on this)
sudo chmod 666 me.iso
Hope it works, if it does, we can try to troubleshooting the other files.
On 02/25/2012 02:34 AM, Spyro Polymiadis wrote:
>
>
>
> disabling nfsv4 in /etc/sysconfig/nfs (adding -N 4 to the start up options)
> was a work around for me to make my uploaded iso appear.
>
> see my previous thread on this list
>
> - Original Message -
> From: "Maor"
> To: "Terry Phelps"
> Cc: users@ovirt.org
> Sent: Saturday, 25 February, 2012 5:57:07 AM
> Subject: Re: [Users] Uploaded ISO file doesn't show up in admin portal
>
> On 02/24/2012 10:23 PM, Douglas Landgraf wrote:
>> Hi Terry,
>>
>> On 02/24/2012 02:51 PM, Douglas Landgraf wrote:
>>> On 02/24/2012 10:28 AM, Terry Phelps wrote:
It looks like you were doing this as root, so I did, too. In any case,
the result looks good to me:
# mount | grep iso
oravm3.acbl.net:/isodomain/ on
/rhev/data-center/mnt/oravm3.acbl.net:_isodomain type nfs4
(rw,relatime,vers=4,rsize=524288,wsize=524288,namlen=255,soft,nosharecache,proto=tcp,port=0,timeo=600,retrans=6,sec=sys,clientaddr=172.16.2.52,minorversion=0,local_lock=none,addr=192.168.118.10)
]# ls /rhev/data-center/mnt/oravm3.acbl.net:_isodomain
48a5390f-2f86-485c-8537-b6bc9dd71796 vdsmTest
[root@oravm2 ~]# vdsClient -s 0 getFileList
48a5390f-2f86-485c-8537-b6bc9dd71796
file: OracleLinux-R6-U2-Server-x86_64-dvd.iso status: {'status':
469, 'ctime': '1330092866.03', 'size': '3591360512'}
NOTE: That "vdsmTest" file you see has appeared there since yesterday,
I think. I didn't put it there.
>>>
>>> You didn't, this file can be removed, yesterday the nfs-check
>>> couldn't complete the test (remove the file)
>>> as you answered me (below) and it's still there.
>>>
# python nfs-check.py oravm3.acbl.net:/isodomain
Current hostname: oravm2.acbl.net - IP addr 127.0.0.1
Trying to /bin/mount -t nfs oravm3.acbl.net:/isodomain...
Executing NFS tests..
Removing vdsmTest file..
Traceback (most recent call last):
File "nfs-check.py", line 268, in
os.removedirs(LOCALPATH)
File "/usr/lib64/python2.7/os.py", line 170, in removedirs
OSError: [Errno 16] Device or resource busy: '/tmp/tmpV9KEh5'
>>>
>>>
>> Just to confirm, during the execution of nfs-check have you manually
>> entry into /tmp/tmpV9KEh5 (from another shell)?
>> If not, this EBUSY error might be like symptom of this weird behaviour...
>>
>> However, let me continue... looking the previous messages of this
>> thread, looks like you have the iso correctly uploaded.
>> Have you tried to restart jboss-as service (oVirt Engine) to see if your
>> iso appears into the GUI?
>>
>> BTW, most of ovirt people are available to chat and help 'on-the-fly' at
>> irc.oftc.net, channel #ovirt , fell free to join us there .
>>
> Hi Terry,
> The engine.log should contain logs regarding ISO files,
> can you please attach it to the mail, maybe we can find some clues there.
>
> Regards,
> Maor
> ___
> 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
