Fixing checkstyle errors in spacewalk-backend: c85e241f94205cc48248c75af5bb23edf3b235a1
Trust syncing should remove trusts that no longer exist. b8290655ca8d89093555012728cd6f46211d3281
Clean up maps on local-org-removal 5bf4cfe5818cc072bd4a326e249ac1a5238422e3
Fixing bug: web_customer and web_contact are not the same thing. ca2380db490c287abe7faeea449994606f1b94d8
Packaging and fixes to sync_setup cf466e39c65a36c32d2d71e1e404a16f3d1b563b 3a292597c0126ca6ff347fcc10a3ce60f1dd8c9c
Moved the iss_parent and iss_ca_cert options into the database out of rhn.conf: 83d0a2fc447ac75ca42047f564f402c4d9fa7d6f
Fixed JUnits that overlapped in painful ways f7fb1238a6de4cfd028a52607544ae2ec7fdebdf
Oracle wasn't happy with my index: 8ac37bd912a8009a80064f59dd6bb3aa9232394c 45353d38d943c42d2725b7d76b59ed2abe9936e9
Ca cert path field was not long enough. fb7e32847df91726897146fadb487502042a9890
Added UI to access iss_parent and iss_ca_cert to/from DB 7f9f26a08bf7c163b792506c9befa45bef5d4ad9 0b17ec5e07e5302bd77e43a1763ee1ad12d65a11 1b25ccc9ecb0e11a28ab61b32dc9e8ad02b07b3e
Teach sapcewalk-sync-setup about isDefault and cacert 1728ba14a194fa35c6de424d4d209278cf7b384b
Set default-template-names correctly 2df999c8d93e1e8a4c57a1113a36975e99415728
Flipping to public.
Summary from the two Satellite RFEs, Removing a few bits from private comment #0 Description of problem: satellite-sync between master and slave discards private|protected|public attribute on a channel. 'satellite-sync' ignores the organization affiliation of custom channels. 1. Proposed title of this feature request satellite-sync between master and slave satellite servers preserves private|protected|public 3. What is the nature and description of the request? When performing a satellite-sync between a master and slave the channels are not being preserved with the private|protected|public attribute. The customer would like that to be preserved on a master->slave sync. 4. Why does the customer need this? (List the business requirements here) So after performing the sync they do not need to go back to customer channel and content to reset the private|protected|public attributes on the slave server. It should be preserved. 5. How would the customer like to achieve this? (List the functional requirements here) - run satellite-sync from master to slave. 6. For each functional requirement listed in question 5, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented. - once the slave has synced the content from the master, check and make sure the private|protected|public attributes are set as they are on the master without having to reconfigure. FROM BZ 860083: 1. Proposed title of this feature request. The 'satellite-sync' tool should, by default, sync organization IDs identically, and slave satellite servers with the same organization structure should end up with the same software channel assignment in-sync with the master. 3. What is the nature and description of the request? By default the 'satellite-sync' tool should sync organization IDs identically, and slave satellite servers with the same organization structure should end up with the same software channel assignment on syncs with their master. One can fix this manually via the XMLRPC API but this should be the standard behaviour as expected by any 'sync'. 4. Why does the customer need this? (List the business requirements here) The customer would need to export and re-import channels every time there is a sync that needs to be done from master to slave. This is inconvenient and the satellite-sync should preserve the orgid assignments for channels. 6. For each functional requirement listed in question 5, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented. - configure a master and slave RHN satellite server. - create custom channels with custom org ID's assigned to those channels. - run satellite sync on slave using --iss-parent=<master satellite> - channels are synced and preserving the orgID assignments. --- Additional comment from Jan Pazdziora on 2013-04-04 06:58:55 EDT --- If this RFE is about preserving the trust as well, we need to add information about organizations to the channel dumps as well. My proposed solution would be to create a catalogue of organization mapping, populate that catalogue during some initial satellite-sync on the slave, let the admin on the slave define what orgs should the original orgs be mapped to, and then use the mapping during subsequent synces. Something like rhnSyncOrgCatalogue id integer not null primary key label varchar(64) not null unique rhnSyncOrgs id integer not null primary key catalogue_id integer not null foreign key rhnSyncOrgCatalogue(id) source_org_id integer not null source_org_name varchar(...) not null target_org_id integer references web_customer(id) -- can be null unique(catalogue_id, source_org_id) unique(catalogue_id, source_org_name) The rhnSyncOrgCatalogue.label would hold the hostname (or URL?) of the master for ISS situations. Upon initial sync, rhnSyncOrgs would be populated with list of source_org_* data for that master. We could do some magic like prepopulating the target_org_ids in cases when the org 1's name would match on the master and client and orgs with the same names would exist on the slave ("hot standby" situation). Otherwise, the target_org_id could be null and the Satellite Admin on the slave could define the target orgs manually, if they wished so. By having both source_org's id and name, we could check upon subsequent synces that the orgs on the master did not change -- if they did, abort (or warn) and let the admin intervene manually. I should point out that this RFE is by no means ISS specific -- we will have to come up with a solution which will work for normal exports on disk as well. For that case, let's have a special rhnSyncOrgCatalogue.label 'disk' or '*' which would be used for non-ISS scenarios. And let's have an option to satellite-sync to chose different catalogue then the default one. Ideally, if we are creating some organization mapping for use on the slave and adding information about orgs to the channel dups, we should also create something similar on the master, to specify which orgs (and their channels) should be exported by default or offered for export during ISS. This is to avoid information leaks about orgs. For that, I envision something like rhnISSSlave id integer not null primary key slave not null unique enabled char(1) not null check( 'Y', 'N' ) allow_all_orgs char(1) not null check( 'Y', 'N' ) rhnISSSlaveOrgs slave_id integer not null org_id integer not null references web_customer(id) So, on the master, the Satellite admin would create list of slaves identified by their IP addresses/FQDNs, and for them specify list of orgs that will be presented to this particular slave. Or have that allow_all_orgs option to leave it open, even for newly created orgs. The table rhnISSSlave would then replace the allowed_iss_slaves option in rhn.conf -- the permissions for the slaves (and what org content they see) would be fully managed in the database. --- Additional comment from Grant Gainey on 2013-06-25 09:51:05 EDT --- This work will be part of Satellite5.6.0 Spacewalk commits: e5d301780f8c093c490d2497c4675f7e873c3211 [spacewalk-schema] release [1.10.50-1] 69631feb2339046a27910590513118e150713c03 [spacewalk-backend] release [1.10.50-1] dad7bf34524b25b0a1b47a971d957d40430a12e0 [spacewalk-java] release [1.10.105-1] 2712558a2d7cc9d98bb7c459c67022185aea4a2d 9fe1b4cf5cee3b2035e1f0c4b849614df731716a e4cc53a075b92f1f3d457d5f8deef7f54ba659aa 0307f864aadf5f01368174faebddb66b26117b29 dcd72ac289b38c2012de05ea26545567ee984469 ed4fcab48f20e3d2bc6a3c85b4e13edcd7bd7ec3 f952fa3393946ca009e00c878091cd5c73f1d435 de7551116c87093781f1df5bbc2e0c458d16e5a0 c3ecd25f31bae426ae343cfc195665d4326644a7 397f81b267e37a85ca272cffbe2785a9b1b692a5 b36aee67450a98223bed49023cbfa0bd6d973d36 2c62e37ddc90f9579f3da646d25047162adb1cb1 423e84c84199ffbf297fe3e4b014424b69feba50 ad5b1b98c77a4d0235a2cab84de3adcb9321a5dc 82da91c79925a7b4ecaeb3336a9e10d12147fa0e a6cc5d5cc19929a2c2bdafca14b13808c7e11036 8354ac8222d3731b581e9e9fbe72ba6cf565ddd2 581dc7d013c1887db21929319590cb6de65f4d56 7675a7063e381bf7af983d5b7180952a73bc39dd a78ab17d9f204b298d97524bb94a53c27daa30ce 93c5b12885890d68cf8824ff59d4ebd1c23aaa8e 1533ed6ac10338e4d5661fefb3c1b625e6e176a1 4ae41e46f073d0c47e4298a8f54af9dd631bde77 72e391eee6e5dcec5a9697eae13b5abb84033201 185f59e4a146ecc1ddda152e8442ef6a2552e8dd e69b60a5d924a3a09743f9b4e56e89be43c2b8b3 d31dde4c5e7716b8549a0aa9eadf85a0b64f1006 e3132d1f360e14cd3d4668119ded72b43a0e66da f884f2875b3138debfd4d47bb5b2bb9b8f4cf071 348090dd457c8ebe6b2081f6edb5724a3199ce77 3fa0b368d8d024e5ccb33ac1807e67980d3d1f45 5809b67546da6e5c06b5199581593ddae8475f67 a3a4162f0b85e49bd4774ed204ccd0344df4d2ae caab1a0495afec63f9618eab43ce4d478e758587 f75b157a89519cf3fef569804669a9775fcd3b8e 0598e8ac77f9e71a1d38809a7d38d4bfdc991d5f 046e1137c7c4b5be5c6f2df45cc419fb297c02d8 41b8af0d1137463763b7cef63255d6879d06009d a0889bacb2af83fe8f74ffb29d089d5cfd367d92 a98a2831074e10c7d587bcec17bb7396ca453392 f5ecc2cc73826fb46c475716413aa09a9c822542 2d1b855e513b269f14f5edb88037b1530194da84 cb0438f03944c3e1290a6e0dc29ec6a89622a08c
79a4b70e2407a398bf34e6f65b3473b33005aa94
Fix for this bug is present in Spacewalk 2.0, closing this bug as CURRENTRELEASE.