Bug 977878 - [RFE] Satellite ISS: preserve channel-access-permissions when doing master->slave sync
[RFE] Satellite ISS: preserve channel-access-permissions when doing master->s...
Status: CLOSED CURRENTRELEASE
Product: Spacewalk
Classification: Community
Component: Server (Show other bugs)
1.10
All Linux
medium Severity medium
: ---
: ---
Assigned To: Grant Gainey
Red Hat Satellite QA List
: FutureFeature, Triaged
Depends On: 865030
Blocks: space20
  Show dependency treegraph
 
Reported: 2013-06-25 10:01 EDT by Grant Gainey
Modified: 2013-08-02 09:16 EDT (History)
6 users (show)

See Also:
Fixed In Version: spacewalk-java-1.10.127-1 spacewalk-backend-1.10.54-1 spacewalk-schema-1.10.61-1 spacewalk-utils-1.10.16-1 spacewalk-config-1.10.5-1
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: 865030
Environment:
Last Closed: 2013-08-02 09:16:42 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Comment 1 Stephen Herr 2013-06-25 11:13:30 EDT
Fixing checkstyle errors in spacewalk-backend:
c85e241f94205cc48248c75af5bb23edf3b235a1
Comment 2 Stephen Herr 2013-06-27 15:20:24 EDT
Trust syncing should remove trusts that no longer exist.
b8290655ca8d89093555012728cd6f46211d3281
Comment 3 Grant Gainey 2013-06-27 16:27:49 EDT
Clean up maps on local-org-removal
5bf4cfe5818cc072bd4a326e249ac1a5238422e3
Comment 4 Stephen Herr 2013-06-28 15:07:11 EDT
Fixing bug: web_customer and web_contact are not the same thing.
ca2380db490c287abe7faeea449994606f1b94d8
Comment 5 Grant Gainey 2013-07-01 14:56:51 EDT
Packaging and fixes to sync_setup
cf466e39c65a36c32d2d71e1e404a16f3d1b563b
3a292597c0126ca6ff347fcc10a3ce60f1dd8c9c
Comment 6 Stephen Herr 2013-07-02 15:43:01 EDT
Moved the iss_parent and iss_ca_cert options into the database out of rhn.conf:
83d0a2fc447ac75ca42047f564f402c4d9fa7d6f
Comment 7 Grant Gainey 2013-07-02 16:50:40 EDT
Fixed JUnits that overlapped in painful ways
f7fb1238a6de4cfd028a52607544ae2ec7fdebdf
Comment 8 Stephen Herr 2013-07-03 09:28:52 EDT
Oracle wasn't happy with my index:
8ac37bd912a8009a80064f59dd6bb3aa9232394c
45353d38d943c42d2725b7d76b59ed2abe9936e9
Comment 9 Stephen Herr 2013-07-03 10:02:37 EDT
Ca cert path field was not long enough.
fb7e32847df91726897146fadb487502042a9890
Comment 11 Grant Gainey 2013-07-08 18:32:59 EDT
Added UI to access iss_parent and iss_ca_cert to/from DB
7f9f26a08bf7c163b792506c9befa45bef5d4ad9
0b17ec5e07e5302bd77e43a1763ee1ad12d65a11
1b25ccc9ecb0e11a28ab61b32dc9e8ad02b07b3e
Comment 12 Grant Gainey 2013-07-09 11:39:31 EDT
Teach sapcewalk-sync-setup about isDefault and cacert
1728ba14a194fa35c6de424d4d209278cf7b384b
Comment 13 Grant Gainey 2013-07-09 13:34:06 EDT
Set default-template-names correctly
2df999c8d93e1e8a4c57a1113a36975e99415728
Comment 14 Clifford Perry 2013-07-09 15:12:15 EDT
Flipping to public.
Comment 15 Clifford Perry 2013-07-09 15:20:16 EDT
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
Comment 16 Grant Gainey 2013-07-11 14:44:34 EDT
79a4b70e2407a398bf34e6f65b3473b33005aa94
Comment 17 Tomáš Kašpárek 2013-08-02 09:16:42 EDT
Fix for this bug is present in Spacewalk 2.0, closing this bug as CURRENTRELEASE.

Note You need to log in before you can comment on or make changes to this bug.