Re: [Spacewalk-devel] pgsql merge status
On Wednesday 22 July 2009 01:32:51 Jeff Ortel wrote: All, I spend most of the day doing side-by-side verification of oracle schema installed from master and pgsql. I've resolve most of the discrepancies and pushed them. I still have a few to deal with, most of them straight forward. I also fixed a bug in chameleon and it will have to be rebuilt in koji and pushed into the build roots. One of the items that resurfaced is synonyms. The original plan was to do away with the synonyms because postgres does not support them. I've removed references to the synonyms in the schema (insert files) but the monitoring code seems to depend heavily on them. So, do leave the synonyms in the schema as oracle specific (the monitoring code will be broken for postgres) or do we replace references to the synonyms in the monitoring code for 0.6? Can someone comment on the LOE for this? I'll see about removing the synonyms from the monitoring code in master branch for Spacewalk 0.6. -Milan ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Selinux Temporarily Disabled in Devel Repo
On Tue, Jul 21, 2009 at 05:33:51PM -0300, Devan Goodwin wrote:
On Mon, Jul 20, 2009 at 03:53:14PM -0300, Devan Goodwin wrote:
We've got both selinux build problems for Fedora 11, as well as
selinux denials post install on at least el5. As such I've
temporarily disabled
What are the AVC denials on EL 5? I'm aware of the build problems
Now filed here:
https://bugzilla.redhat.com/show_bug.cgi?id=513071
Happened on CentOS 5.2.
As it turns out to be user error and not a bug in the code, could you
please revert the commit which commented out the Requires of *-selinux
packages, and just put in a check for 0%{?fedora} == 11, similar to
spacewalk-monitoring.spec?
That way we still have *-selinux packages installed and hopefully
tested on F10 and EL5. As Spacewalk 0.5 worked with SELinux in
Enforcing on those two OSes, we should try not to introduce
regressions, and keeping the modules in the transaction seems like the
best way to achieve that.
Thank you,
--
Jan Pazdziora
Senior Software Engineer, Satellite Engineering, Red Hat
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Selinux Temporarily Disabled in Devel Repo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 22 Jul 2009 15:00:28 +0200
Jan Pazdziora jpazdzi...@redhat.com wrote:
On Tue, Jul 21, 2009 at 05:33:51PM -0300, Devan Goodwin wrote:
On Mon, Jul 20, 2009 at 03:53:14PM -0300, Devan Goodwin wrote:
We've got both selinux build problems for Fedora 11, as well as
selinux denials post install on at least el5. As such I've
temporarily disabled
What are the AVC denials on EL 5? I'm aware of the build problems
Now filed here:
https://bugzilla.redhat.com/show_bug.cgi?id=513071
Happened on CentOS 5.2.
As it turns out to be user error and not a bug in the code, could you
please revert the commit which commented out the Requires of *-selinux
packages, and just put in a check for 0%{?fedora} == 11, similar to
spacewalk-monitoring.spec?
That way we still have *-selinux packages installed and hopefully
tested on F10 and EL5. As Spacewalk 0.5 worked with SELinux in
Enforcing on those two OSes, we should try not to introduce
regressions, and keeping the modules in the transaction seems like the
best way to achieve that.
Thank you,
Sure.
- --
Devan Goodwin dgood...@redhat.com
Software Engineer Spacewalk / RHN Satellite
Halifax, Canada 650.567.9039x79267
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
iEYEARECAAYFAkpnEg8ACgkQAyHWaPV9my7Z2gCfVrBnEU9biKq2z6MLg0KvMuDG
PZsAn3RkxfO1mZqhb6ueN//hMrA02ABH
=EuH3
-END PGP SIGNATURE-
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] pgsql merge status
Tom Lane wrote: Jeff Ortel jor...@redhat.com writes: One of the items that resurfaced is synonyms. The original plan was to do away with the synonyms because postgres does not support them. I've removed references to the synonyms in the schema (insert files) but the monitoring code seems to depend heavily on them. So, do leave the synonyms in the schema as oracle specific (the monitoring code will be broken for postgres) or do we replace references to the synonyms in the monitoring code for 0.6? Can someone comment on the LOE for this? Perhaps we could use views as a PG substitute for synonyms? I agree with the idea of getting rid of them over the long term, but it would be nice to not have that in the critical path if there is a lot of code that would have to change. Perhaps. My concern about using views even as an interim solution is that the monitoring code has high insert/update demands (I'm assuming) and we'd have to use 'on insert/update' rules to make the views seem mutable, right? Wouldn't this degrade performance? I sniffed the code a little and found that there is a mixture of references to the table names and synonyms. I found about 83 references to the table names and I'm not sure about the synonyms since they don't have an easy pattern like 'rhn_' to grep on like the synonyms. But, it makes me hopeful that the number of references to synonyms is relatively small. Thanks for the suggestion. It's good to have this as an option. regards, tom lane ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] pgsql merge status
Jeff Ortel jor...@redhat.com writes: Tom Lane wrote: Perhaps we could use views as a PG substitute for synonyms? Perhaps. My concern about using views even as an interim solution is that the monitoring code has high insert/update demands (I'm assuming) and we'd have to use 'on insert/update' rules to make the views seem mutable, right? Wouldn't this degrade performance? Yeah, you're right. I had thought monitoring suggested read-mostly, but if it's write-heavy we probably don't want that even as a stopgap solution. It's not so much that I care about speed at this point, as that having to write a bunch of rules would be dead-end effort. regards, tom lane ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] pgsql (web_user_pi_timestamp) trigger
In master, the 'web_user_pi_timestamp' trigger on 'web_user_personal_info' is being defined in: 'rhnsat/tables/web_user_personal_info.sql' (SNIP#1) Then redefined in (and the filename is all wrong): 'rhnsat/tables/web_user_contact_permission.sql' (SNIP#2) The net effect is that the 'web_user_pi_timestamp' trigger is begin installed as: BEFORE INSERT OR UPDATE ON web_user_personal_info FOR EACH ROW BEGIN :new.modified := sysdate; END; instead of: before insert or update on web_user_personal_info for each row begin :new.email_uc := upper(:new.email); :new.modified := sysdate; end; Does anyone know what was really intended here? I've corrected for the net effect in pgsql but wanted to be sure the intended effect was being achieved. Thanks, Jeff SNIP #1 --- 2904 -- SQL relevant contents from file rhnsat/tables/web_user_personal_info.sql ... 2943 create or replace trigger 2944 web_user_pi_timestamp 2945 before insert or update on web_user_personal_info 2946 for each row 2947 begin 2948 :new.email_uc := upper(:new.email); 2949 :new.modified := sysdate; 2950 end; 2951 / SNIP#2 -- 36408 -- SQL relevant contents from file rhnsat/tables/web_user_contact_permission_triggers.sql 36409 create or replace trigger 36410 web_user_pi_timestamp 36411 BEFORE INSERT OR UPDATE ON web_user_personal_info 36412 FOR EACH ROW 36413 BEGIN 36414 :new.modified := sysdate; 36415 END; 36416 / 36417 show errors ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Re: Branch 'pgsql' - 2 commits - schema/spacewalk
On Wednesday 22 July 2009 01:11:17 Jeff Ortel wrote: [..] |2 schema/spacewalk/common/tables/rhnSet.sql |2 schema/spacewalk/common/tables/rhnSystemMigrations.sql [...] commit 79a08479f36399c26aae812fec749d0e9f38179c Author: Jeff Ortel jor...@redhat.com Date: Tue Jul 21 16:01:15 2009 -0500 Resolve differences between databases created master and pgsql sources. [...] diff --git a/schema/spacewalk/common/tables/rhnSet.sql b/schema/spacewalk/common/tables/rhnSet.sql index 78105d0..87e8b83 100644 --- a/schema/spacewalk/common/tables/rhnSet.sql +++ b/schema/spacewalk/common/tables/rhnSet.sql @@ -21,7 +21,7 @@ CREATE TABLE rhnSet REFERENCES web_contact (id) ON DELETE CASCADE, label VARCHAR2(32) NOT NULL, -elementNUMBER NOT NULL, +elementNUMBER, element_twoNUMBER, element_three NUMBER, CONSTRAINT rhn_set_user_label_elem_unq UNIQUE (user_id, label, element, element_two, element_three) Are we sure this is correct? rhnSet table in current master branch does set not null constraint on element column. diff --git a/schema/spacewalk/common/tables/rhnSystemMigrations.sql b/schema/spacewalk/common/tables/rhnSystemMigrations.sql index b5c8d74..6d81a87 100644 --- a/schema/spacewalk/common/tables/rhnSystemMigrations.sql +++ b/schema/spacewalk/common/tables/rhnSystemMigrations.sql @@ -16,11 +16,11 @@ CREATE TABLE rhnSystemMigrations ( -org_id_toNUMBER +org_id_toNUMBER NOT NULL CONSTRAINT rhn_sys_mig_oidto_fk REFERENCES web_customer (id) ON DELETE SET NULL, -org_id_from NUMBER +org_id_from NUMBER NOT NULL CONSTRAINT rhn_sys_mig_oidfrm_fk REFERENCES web_customer (id) ON DELETE SET NULL, I'm not sure about this change either. rhnSystemMigrations in master branch does not set not null constraint for those two columns. -Milan ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
