[Engine-devel] [ATN] moving dbscripts location
Hello All, During the work I am doing to clean up the build of upcoming 3.3, I am going to move[1] dbscripts directory from: backend/manager/dbscripts to: packaging/dbscripts The packaging directory is a new directory established for files we copy as-is to installation media, dbscripts was the last remaining directory of that nature. dbscripts does not really belong to the java sources nor to required for java project build (except few validation that were kept). The packaging directory has the following advantages: 1. Simplify the build system to blindly copy files recursively from packaging to installation media. 2. Do not copy unnecessary files as we copy today, example is pom.xml. 3. Allow easy split plain files within packaging directory to sub packages in future. 4. Easier to understand the target system file layout by browsing the packaging directory, no magic of renaming or on the fly creation. 5. A clear separation between the maven build and the packaging build. Regards, Alon Bar-Lev. [1] http://gerrit.ovirt.org/#/c/15743 ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [ATN] moving dbscripts location
- Original Message - From: Alon Bar-Lev alo...@redhat.com To: engine-devel engine-devel@ovirt.org Cc: Eli Mesika emes...@redhat.com Sent: Monday, June 17, 2013 11:24:20 AM Subject: [ATN] moving dbscripts location Hello All, During the work I am doing to clean up the build of upcoming 3.3, I am going to move[1] dbscripts directory from: backend/manager/dbscripts to: packaging/dbscripts The packaging directory is a new directory established for files we copy as-is to installation media, dbscripts was the last remaining directory of that nature. dbscripts does not really belong to the java sources nor to required for java project build (except few validation that were kept). The packaging directory has the following advantages: 1. Simplify the build system to blindly copy files recursively from packaging to installation media. 2. Do not copy unnecessary files as we copy today, example is pom.xml. 3. Allow easy split plain files within packaging directory to sub packages in future. 4. Easier to understand the target system file layout by browsing the packaging directory, no magic of renaming or on the fly creation. 5. A clear separation between the maven build and the packaging build. Regards, Alon Bar-Lev. [1] http://gerrit.ovirt.org/#/c/15743 Hi I had reviewed that patch and it seems that it can be merged ASAP. +1 for merging that ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Cloud-Init integration
On Jun 16, 2013, at 18:04 , Dan Kenigsberg dan...@redhat.com wrote: On Sun, Jun 16, 2013 at 05:50:38PM +0300, Greg Padgett wrote: On 06/16/2013 05:08 PM, Mike Kolesnik wrote: - Original Message - On Thu, Mar 28, 2013 at 07:35:23PM -0400, Greg Padgett wrote: Hi Everyone, I'd like to propose a feature we've been doing some investigation into, which is to integrate cloud-init support into oVirt. Cloud-init is used to help provision new Linux systems by setting the hostname, ip, ssh keys, timezone, injecting files, and more. It's used by OpenStack (amongst others) now, and has a lot of features that may be helpful to our users. Details are still evolving, but for more info please see the wiki page: http://www.ovirt.org/Features/Cloud-Init_Integration All feedback is welcome! All feedback? Even if it's 3 months too late? I'll have to be more careful next time to specify a time limit :) But really, thank you both for the comments. Feel free to add them to a nice to have list on the wiki page, or I can add it. Replies inline... If so, then here's a few comments: 1. oVirt-3.2 completely supports IPv6 within guests. It would be nice to carry this on to cloud-init, by allowing to set the IPv6 address of the guest. (or are we happy with the auto configured ipv6 addresses?) It would, but unfortunately cloud-init doesn't yet translate ipv6 fields from /etc/network/interfaces (its chosen networking input format) to ifcfg files. Now that you mention it, it doesn't add IPV6INIT=yes, either. ifcfg files? What's that? Those easily-edited text files that are being deprecated by NetworkManager? Does cloud-init play well with the latter? (we found a couple of pitfalls, the hard way). These are things we can add--to both oVirt and cloud-init, I guess at a later time. 2. I think that the GUI used for setting IP addresses should be immitated here. It allows Static/DHCP/None, and disables the irrelvant fields when DHCP/None is selected. It's close: there is a checkbox for dhcp, and if selected it will hide the non-relevant fields. I hate surprises, so I'm in favor of having the same thing, as well as the keep recent config in memory when bootproto is moved to None semantics. This applies more strongly to the REST api. Host level configuration http://www.ovirt.org/Features/Design/Network/SetupNetworks#Scheme has host_nic nameem1/name ip address=10.35.1.247 netmask=255.255.254.0 gateway=10.35.1.254/ boot_protocoldhcp/boot_protocol /host_nic And for reporting guest configuration http://www.ovirt.org/Feature/ReportingVnicImplementation#API_Changes has network_device namep1p2/name descriptionguest reported data/description ips ip version=v4 address=10.35.1.177/ ip version=v6 address=fe80::21a:4aff:fe16:151/ /ips /network_device which we should strive to maintain with this feature. Even if cloud-init is not currently capable of setting multiple addresses, let the API allow for it. Additionally, you should consider showing the vNIC name and not eth0 etc. IIUC udev rules are rather unpredictable in this regard and could give your vNIC a different name on different VM instances (probably by MAC address and/or PCI address). Either way, I think it's less confusing to refer to the vNIC itself. Similarly to the above, I'm not sure how much cloud-init supports with respect to vNICs. The name is used as the /etc/network/interfaces adapter name and the ifcfg-* suffix (per distro), so I guess if you plumbed everything around that in the image and could finish the setup with just the interfaces/ifcfg config file then it would work as-is. If that isn't adequate (I haven't looked or tested) then we may need to consider submitting a patch to add this to cloud-init. Either way, RHEV should not expose in its own interface the eth0 names that we cannot enforce within the guest. E.g., my Fedora has funny interface names such as em1 and wlp3s0, nothing like the good old eth*. 3. Is Support custom volume label for vm payloads still on the TODO list? Note: F19's dosfstools has renamed mkfs.msdos to mkfs.fat. This means that creating a virtual floppy with a payload currently does not work there (it's a tiny fix, for sure). It's implemented. Of course, it still uses mkfs.msdos. Implemented but not yet posted, I presume? Because upstream vdsm's does not use mkfs.msdos's -n. 4. I do not see ovirt-guest-agent mentioned in the feaure page. It is the obvious channel to report that cloud-init is Done to Engine. You're right, and this is one part of the feature that hasn't been done. It may also require some work on cloud-init, or for us to use a different input format (i.e. a mime-formatted sequence instead of vanilla config-drive-2). It would be great to add this, though my time to do that now is a bit limited. What
Re: [Engine-devel] SELinux problem
Il 17/06/2013 14:49, Eli Mesika ha scritto: Hi I am using SELinux Enforcing mode on Fedora 18 (selinux-policy-3.11.1-97.fc18.noarch) As part as our Postgres DB restore we have to 1) Open a postgres backup packed as a TAR file 2) Restore the database from those files after unpacking with tar xvf. Why using tar xvf instead of pg_restore? -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] SELinux problem
- Original Message - From: Sandro Bonazzola sbona...@redhat.com To: Eli Mesika emes...@redhat.com Cc: Daniel Walsh dwa...@redhat.com, engine-devel engine-devel@ovirt.org Sent: Monday, June 17, 2013 3:53:27 PM Subject: Re: [Engine-devel] SELinux problem Il 17/06/2013 14:49, Eli Mesika ha scritto: Hi I am using SELinux Enforcing mode on Fedora 18 (selinux-policy-3.11.1-97.fc18.noarch) As part as our Postgres DB restore we have to 1) Open a postgres backup packed as a TAR file 2) Restore the database from those files after unpacking with tar xvf. Why using tar xvf instead of pg_restore? There is another PG BZ that prevents us from using the pg_restore We have to open the TAR and hack the content of the restore.sql file for more details see http://www.postgresql.org/message-id/e1trqx7-0002qd...@wrigleys.postgresql.org -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] SELinux problem
- Original Message -
From: Daniel J Walsh dwa...@redhat.com
To: Eli Mesika emes...@redhat.com
Cc: Yair Zaslavsky yzasl...@redhat.com, Barak Azulay
bazu...@redhat.com, engine-devel
engine-devel@ovirt.org
Sent: Monday, June 17, 2013 6:51:23 PM
Subject: Re: SELinux problem
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/17/2013 08:49 AM, Eli Mesika wrote:
Hi
I am using SELinux Enforcing mode on Fedora 18
(selinux-policy-3.11.1-97.fc18.noarch)
As part as our Postgres DB restore we have to
1) Open a postgres backup packed as a TAR file 2) Restore the database from
those files after unpacking with tar xvf.
I have found that I get a Permission Denied when trying to restore the
database data files. After investigation , I had found that running :
setenforce 0 the restore completes with no errors. Further investigation
shows that when I am extracting the TAR file , I have to set the same
SELinux context as in /var/lib/pgsql/data directory , i.e.
unconfined_u:object_r:postgresql_db_t:s0
I had tried to do that with chcon :
chcon -u unconfined_u -r object_r -t postgresql_db_t file
This was failed (also when running with root privileges) and audit2why
--all shows a lot of those errors :
type=AVC msg=audit(1371464569.023:671): avc: denied { relabelto } for
pid=18144 comm=chcon name=toc.dat dev=tmpfs ino=117639
scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
tcontext=system_u:system_r:postgresql_t:s0 tclass=file Was caused by:
Missing type enforcement (TE) allow rule.
You can use audit2allow to generate a loadable module to allow this
access.
After goggling around that , I found an article by you:
https://docs.fedoraproject.org/en-US/Fedora/11/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Fixing_Problems-Allowing_Access_audit2allow.html
It says : Missing Type Enforcement rules are usually caused by bugs in
SELinux policy, and should be reported in Red Hat Bugzilla. For Fedora,
create bugs against the Fedora product, and select the selinux-policy
component. Include the output of the audit2allow -w -a and audit2allow -a
commands in such bug reports.
Should I open a BZ on that ?
The TAR I am using is attached. (I am opening it with tar xvf and trying to
change the context to desired context as explained above)
Thanks
Eli
Just untar the files and run restorecon -R on them
restorecon -R PATH
Thanks for the quick response
I had tried it and nothing happen , same results
So I had tried with -RVVF flags and got the following
restorecon: Warning no default label for
/tmp/db/00579652_221211073824_pgdump.tar_dir/3622.dat
( this appears on each file of the extracted files )
So, it seems that the pg_dump did not set the correct SELinux defaults on those
file when packaging them , right ?
Any workaround to get out of that...
Thanks again
Eli
SHould put the default labels on the content.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlG/MHsACgkQrlYvE4MpobOjNACff0Ugxb2zWZqx+At3orGPS4s7
CZ0AoNQSRB2QSCrise2m4gFiEO2sbCh1
=hdyR
-END PGP SIGNATURE-
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] SELinux problem
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/17/2013 08:49 AM, Eli Mesika wrote:
Hi
I am using SELinux Enforcing mode on Fedora 18
(selinux-policy-3.11.1-97.fc18.noarch)
As part as our Postgres DB restore we have to
1) Open a postgres backup packed as a TAR file 2) Restore the database from
those files after unpacking with tar xvf.
I have found that I get a Permission Denied when trying to restore the
database data files. After investigation , I had found that running :
setenforce 0 the restore completes with no errors. Further investigation
shows that when I am extracting the TAR file , I have to set the same
SELinux context as in /var/lib/pgsql/data directory , i.e.
unconfined_u:object_r:postgresql_db_t:s0
I had tried to do that with chcon :
chcon -u unconfined_u -r object_r -t postgresql_db_t file
This was failed (also when running with root privileges) and audit2why
--all shows a lot of those errors :
type=AVC msg=audit(1371464569.023:671): avc: denied { relabelto } for
pid=18144 comm=chcon name=toc.dat dev=tmpfs ino=117639
scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
tcontext=system_u:system_r:postgresql_t:s0 tclass=file Was caused by:
Missing type enforcement (TE) allow rule.
You can use audit2allow to generate a loadable module to allow this
access.
After goggling around that , I found an article by you:
https://docs.fedoraproject.org/en-US/Fedora/11/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Fixing_Problems-Allowing_Access_audit2allow.html
It says : Missing Type Enforcement rules are usually caused by bugs in
SELinux policy, and should be reported in Red Hat Bugzilla. For Fedora,
create bugs against the Fedora product, and select the selinux-policy
component. Include the output of the audit2allow -w -a and audit2allow -a
commands in such bug reports.
Should I open a BZ on that ?
The TAR I am using is attached. (I am opening it with tar xvf and trying to
change the context to desired context as explained above)
Thanks
Eli
Just untar the files and run restorecon -R on them
restorecon -R PATH
SHould put the default labels on the content.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlG/MHsACgkQrlYvE4MpobOjNACff0Ugxb2zWZqx+At3orGPS4s7
CZ0AoNQSRB2QSCrise2m4gFiEO2sbCh1
=hdyR
-END PGP SIGNATURE-
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] IE9 Issue with UI Plugin
Hi Vojtech, I had previously sent you an email about IE9 compatibility where the problem we were having was solved by omitting console logging when a console was unavailable (i.e. IE). However, it is looking like IE9 may have a bigger issue with regards to the plugin framework. Now that we have gotten dialogs to open via dynamically inserted buttons within RHEV tabs (for example, a NetApp button in the Storage tab), we can go through our whole process with the exception of closing the window. In all other browsers, our dialog will close as expected, but in IE the window remains open. It can be closed by hitting the red x in the corner, but it appears the code in the frame itself cannot close the window, with a console message in the dev tools of IE9 showing an error of 'Math' is undefined. I've read up on this, and it seems like this is a very widespread error in Internet Explorer concerning the manner/order in which iframes are dynamically inserted. I've copied engine-devel in case anyone has similar issues/solutions, but it seems as though we need some sort of clause in the plugin framework for IE when it comes to dynamic insertion of new windows. - Ricky Hopper ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] SELinux problem
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/17/2013 03:17 PM, Eli Mesika wrote:
- Original Message -
From: Daniel J Walsh dwa...@redhat.com To: Eli Mesika
emes...@redhat.com Cc: Yair Zaslavsky yzasl...@redhat.com, Barak
Azulay bazu...@redhat.com, engine-devel engine-devel@ovirt.org
Sent: Monday, June 17, 2013 6:51:23 PM Subject: Re: SELinux problem
On 06/17/2013 08:49 AM, Eli Mesika wrote:
Hi
I am using SELinux Enforcing mode on Fedora 18
(selinux-policy-3.11.1-97.fc18.noarch)
As part as our Postgres DB restore we have to
1) Open a postgres backup packed as a TAR file 2) Restore the
database from those files after unpacking with tar xvf.
I have found that I get a Permission Denied when trying to restore
the database data files. After investigation , I had found that
running : setenforce 0 the restore completes with no errors. Further
investigation shows that when I am extracting the TAR file , I have
to set the same SELinux context as in /var/lib/pgsql/data directory ,
i.e. unconfined_u:object_r:postgresql_db_t:s0
I had tried to do that with chcon :
chcon -u unconfined_u -r object_r -t postgresql_db_t file
This was failed (also when running with root privileges) and
audit2why --all shows a lot of those errors :
type=AVC msg=audit(1371464569.023:671): avc: denied { relabelto }
for pid=18144 comm=chcon name=toc.dat dev=tmpfs ino=117639
scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
tcontext=system_u:system_r:postgresql_t:s0 tclass=file Was caused
by: Missing type enforcement (TE) allow rule.
You can use audit2allow to generate a loadable module to allow this
access.
After goggling around that , I found an article by you:
https://docs.fedoraproject.org/en-US/Fedora/11/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Fixing_Problems-Allowing_Access_audit2allow.html
It says : Missing Type Enforcement rules are usually caused by bugs in
SELinux policy, and should be reported in Red Hat Bugzilla. For
Fedora, create bugs against the Fedora product, and select the
selinux-policy component. Include the output of the audit2allow -w -a
and audit2allow -a commands in such bug reports.
Should I open a BZ on that ?
The TAR I am using is attached. (I am opening it with tar xvf and
trying to change the context to desired context as explained above)
Thanks
Eli
Just untar the files and run restorecon -R on them
restorecon -R PATH
Thanks for the quick response I had tried it and nothing happen , same
results So I had tried with -RVVF flags and got the following
restorecon: Warning no default label for
/tmp/db/00579652_221211073824_pgdump.tar_dir/3622.dat
( this appears on each file of the extracted files )
So, it seems that the pg_dump did not set the correct SELinux defaults on
those file when packaging them , right ?
Any workaround to get out of that...
Thanks again
Eli
SHould put the default labels on the content.
Why are you storing your postgresql database on a /tmp directory?
If you put it in the normal places, it would have worked.
If you must have it there then you need to label it with
chcon -Rt postgresql_db_t /tmp/db
Will change the label to be useable by postgresql.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlG/fF0ACgkQrlYvE4MpobPoXwCfeKhb+JEJX1l/xL/RbavAOjwf
mwMAoOAhh/m3cifg3ktXF9oAkpHLLlZB
=4S5u
-END PGP SIGNATURE-
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] SELinux problem
- Original Message -
From: Daniel J Walsh dwa...@redhat.com
To: Eli Mesika emes...@redhat.com
Cc: Yair Zaslavsky yzasl...@redhat.com, Barak Azulay
bazu...@redhat.com, engine-devel
engine-devel@ovirt.org
Sent: Tuesday, June 18, 2013 12:15:09 AM
Subject: Re: SELinux problem
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/17/2013 03:17 PM, Eli Mesika wrote:
- Original Message -
From: Daniel J Walsh dwa...@redhat.com To: Eli Mesika
emes...@redhat.com Cc: Yair Zaslavsky yzasl...@redhat.com, Barak
Azulay bazu...@redhat.com, engine-devel engine-devel@ovirt.org
Sent: Monday, June 17, 2013 6:51:23 PM Subject: Re: SELinux problem
On 06/17/2013 08:49 AM, Eli Mesika wrote:
Hi
I am using SELinux Enforcing mode on Fedora 18
(selinux-policy-3.11.1-97.fc18.noarch)
As part as our Postgres DB restore we have to
1) Open a postgres backup packed as a TAR file 2) Restore the
database from those files after unpacking with tar xvf.
I have found that I get a Permission Denied when trying to restore
the database data files. After investigation , I had found that
running : setenforce 0 the restore completes with no errors. Further
investigation shows that when I am extracting the TAR file , I have
to set the same SELinux context as in /var/lib/pgsql/data directory ,
i.e. unconfined_u:object_r:postgresql_db_t:s0
I had tried to do that with chcon :
chcon -u unconfined_u -r object_r -t postgresql_db_t file
This was failed (also when running with root privileges) and
audit2why --all shows a lot of those errors :
type=AVC msg=audit(1371464569.023:671): avc: denied { relabelto }
for pid=18144 comm=chcon name=toc.dat dev=tmpfs ino=117639
scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
tcontext=system_u:system_r:postgresql_t:s0 tclass=file Was caused
by: Missing type enforcement (TE) allow rule.
You can use audit2allow to generate a loadable module to allow this
access.
After goggling around that , I found an article by you:
https://docs.fedoraproject.org/en-US/Fedora/11/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Fixing_Problems-Allowing_Access_audit2allow.html
It says : Missing Type Enforcement rules are usually caused by bugs in
SELinux policy, and should be reported in Red Hat Bugzilla. For
Fedora, create bugs against the Fedora product, and select the
selinux-policy component. Include the output of the audit2allow -w -a
and audit2allow -a commands in such bug reports.
Should I open a BZ on that ?
The TAR I am using is attached. (I am opening it with tar xvf and
trying to change the context to desired context as explained above)
Thanks
Eli
Just untar the files and run restorecon -R on them
restorecon -R PATH
Thanks for the quick response I had tried it and nothing happen , same
results So I had tried with -RVVF flags and got the following
restorecon: Warning no default label for
/tmp/db/00579652_221211073824_pgdump.tar_dir/3622.dat
( this appears on each file of the extracted files )
So, it seems that the pg_dump did not set the correct SELinux defaults on
those file when packaging them , right ?
Any workaround to get out of that...
Thanks again
Eli
SHould put the default labels on the content.
Why are you storing your postgresql database on a /tmp directory?
If you put it in the normal places, it would have worked.
The reason is that this is a backup file from which I have to restore the
database.
If you must have it there then you need to label it with
chcon -Rt postgresql_db_t /tmp/db
That worked !!!, thank you very much for your kind help.
Will change the label to be useable by postgresql.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlG/fF0ACgkQrlYvE4MpobPoXwCfeKhb+JEJX1l/xL/RbavAOjwf
mwMAoOAhh/m3cifg3ktXF9oAkpHLLlZB
=4S5u
-END PGP SIGNATURE-
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
