Overview
Request 503528 revoked
https://lists.opensuse.org/opensuse-factory/2017-05/msg00250.html
- Created by tserong
- In state revoked
- Supersedes 496707
- Open review for openSUSE:Factory:Staging:adi:85
Request History
tserong created request
https://lists.opensuse.org/opensuse-factory/2017-05/msg00250.html
factory-auto added opensuse-review-team as a reviewer
Please review sources
factory-auto added factory-repo-checker as a reviewer
Please review build success
factory-auto accepted review
Check script succeeded
licensedigger accepted review
ok
staging-bot added as a reviewer
Being evaluated by staging project "openSUSE:Factory:Staging:adi:85"
staging-bot accepted review
Picked openSUSE:Factory:Staging:adi:85
factory-repo-checker accepted review
Builds for repo filesystems:ceph/openSUSE_Tumbleweed
jengelh declined review
There is no library in here to justify Group: System/Libraries.
jengelh declined request
There is no library in here to justify Group: System/Libraries.
tserong revoked request
use of /srv violates packaging guidelines. subdirs owned by a user is a secuity problem. not acceptable.
We need to ship these files under /srv, because that's where salt (which deepsea builds upon) expects to find them.
As for subdirectory ownership, would it be acceptable if it were something like %attr(0755, root, salt), so root owned but group salt? That would probably work for us in most cases, although IIRC the salt user will need to be able to write to at least one directory tree under /srv/pillar/ceph.
Then salt needs to be enhanced to also read files from vendor provided, read only locations. That's such a basic feature and common practice I'd be very surprised if that isn't possible.
The group doesn't help as long as anyone != root can write there.
deepsea makes use of salt orchestration runners, which run on the salt master -- the user invokes these runners in order to use deepsea to configure a ceph cluster. Some of the runners in deepsea need to write to /srv/pillar/ceph, in order to create/edit configuration. The salt master daemon runs as the unprivileged salt user, so those directories need to be writable by the salt user. We can't change this.
This SR would potentially override users own files in /srv/salt/ceph
This would be potentially catastrophic for any customer using salt to manage ceph themselves and having the misfortune of choosing the name naming convention as /srv/salt/ceph
I think this package will require a new out of band location for it's salt states and pillars, and I think that should be provided by the ceph package
Maybe something like /usr/lib/salt/states and /usr/lib/salt/pillars which would need to be configured by adding additional paths to the appropriate *_root: params default in our salt package (https://docs.saltstack.com/en/latest/ref/configuration/master.html )
" I think that should be provided by the ceph package "
I meant to say SALT, not ceph here
I think our salt package should provide a vendor-distributed location for vendor-distributed salt states and pillars
I agree - there should be a way to provide vendor-distributed salt states and pillars. AFAIK that doesn't exist yet though, so this is where we are :-/
All the pieces deepsea ships that might conflict with user-provided files are marked %config, so installing this won't destroy existing user files that conflict; they'll be renamed instead.
Let's continue the discussion at https://github.com/SUSE/DeepSea/issues/360
How could we get the other Salt stakeholders involved in the discussion?
Let's also keep the security concerns in perspective: DeepSea is used to deploy Ceph clusters. It's not likely to be installed on an unsecured machine (i.e. a machine with non-admin users).