Project

Profile

Help

Issue #540

Upgrading Pulp with lots of synced content can take hours

Added by bkearney@redhat.com almost 5 years ago. Updated 10 months ago.

Status:
CLOSED - CURRENTRELEASE
Priority:
Normal
Category:
-
Sprint/Milestone:
-
Start date:
Due date:
Severity:
2. Medium
Version:
Master
Platform Release:
2.6.1
Blocks Release:
OS:
Backwards Incompatible:
No
Triaged:
Yes
Groomed:
No
Sprint Candidate:
No
Tags:
Pulp 2
Complexity:
Smash Test:
Verified:
Yes
Verification Required:
No
Sprint:

Description

Description of problem:

While upgrading Pulp, if you have a lot of synced content, the SELinux re-label process takes hours. While re-labeling it shows that it is installing the pulp-selinux RPM. The relabel of /var/lib/pulp takes a long time with content. This isn't necessary since pulp 2.4 and many earlier versions already have the correct labels on /var/lib/pulp.

I expect an upgrade of Pulp to only perform restorecon statements if they are actually needed.

Associated revisions

Revision 77fb48dc View on GitHub
Added by dkliban@redhat.com almost 5 years ago

540 - Check previous version of pulp-server SELinux policy at ugrade

This patch enhances the pulp-selinux RPM install process. The version of the
pulp-server SELinux policy is recorded in /var/lib/rpm-state/pulp before the new
policy is installed. Then that version is passed as an argument to relabel.sh.
The relabel script then only relabels the files that have not been properly labeled
in the previously installed version. If no version is passed in, all files
are relabeled.

Fixes #540

Revision 77fb48dc View on GitHub
Added by dkliban@redhat.com almost 5 years ago

540 - Check previous version of pulp-server SELinux policy at ugrade

This patch enhances the pulp-selinux RPM install process. The version of the
pulp-server SELinux policy is recorded in /var/lib/rpm-state/pulp before the new
policy is installed. Then that version is passed as an argument to relabel.sh.
The relabel script then only relabels the files that have not been properly labeled
in the previously installed version. If no version is passed in, all files
are relabeled.

Fixes #540

History

#1 Updated by bmbouter almost 5 years ago

If pulp-selinux is being installed or uninstalled it has to run the restorecon statements. If there is a lot of file contents in the pulp areas of the filesystem, the SELinux policy needs to take its time to label them properly or the SELinux policy won't work.

Labeling them asynchronously is not viable IMO either because there is an expectation from the user that once the pulp-selinux install is complete they are protected, but asynchronous labeling would not yet be in place so they would still be vulnerable.

I believe the way to resolve this is to avoid doing work necessarily. The reason we do work unecessarily is because pulp-selinux is versioned in lock-step with Pulp. We should not have pulp-selinux lock step version with Pulp. To do that right it needs to be moved to its own package with its own version. There are a few practical things that prevent us from doing that right now, but we're working through those.

If pulp-selinux was not upgraded everytime a new Pulp release comes out then yum wouldn't even run the restorecon statements unless it actually needs to.

+ This comment was cloned from Bugzilla #1145720 comment 1 +

#2 Updated by stbenjam@redhat.com almost 5 years ago

You can also detect when changes are made, and only run restorecon on the applicable paths. This works better anyway, because if the future separated pulp-selinux has a small change unrelated to /var/lib/pulp, you don't also relabel that.

I haven't looked into this too much, but it may help:

14:09 | stbenjam > is it typical to always run restorecon in a selinux PRM %post? this is insane on pulp-selinux... /var/lib/pulp has hundreds of thousands of files :(
14:11 | Dominic > stbenjam: you can optimise it in various ways, see fixfiles -C and probably selinux-policy pre/post script
14:11 | Dominic > stbenjam: I think you're basically only restoring contexts of files where there's a change in fcontext 14:21 | Dominic > stbenjam: line 277-282 in %pre, followed by 263-268 in %post.. http://pkgs.fedoraproject.org/cgit/selinux-policy.git/tree/selinux-policy.spec#n265

+ This comment was cloned from Bugzilla #1145720 comment 2 +

#5 Updated by dkliban@redhat.com almost 5 years ago

  • Status changed from NEW to ASSIGNED
  • Assignee set to dkliban@redhat.com

We will start checking which version the upgrade is from. If a fresh install, all the restorecon statements will be run. Otherwise only new restorecon statements will be run.

#7 Updated by bmbouter almost 5 years ago

  • Severity changed from Medium to 2. Medium

#8 Updated by dkliban@redhat.com almost 5 years ago

  • Status changed from ASSIGNED to POST

#9 Updated by dkliban@redhat.com almost 5 years ago

  • Status changed from POST to MODIFIED
  • % Done changed from 0 to 100

#10 Updated by bmbouter almost 5 years ago

  • Subject changed from selinux relabel after yum update of pulp-selinux to Upgrading Pulp with lots of synced content can take hours
  • Description updated (diff)
  • Private changed from Yes to No

#11 Updated by dkliban@redhat.com almost 5 years ago

  • Platform Release set to 2.6.1

#12 Updated by dkliban@redhat.com almost 5 years ago

  • Status changed from MODIFIED to ON_QA

#13 Updated by dkliban@redhat.com almost 5 years ago

A good way to test this is to install Pulp 2.5.x or 2.6.0 and then perform the following operations:

# create a test file
sudo touch /var/lib/pulp/test
sudo chown apache:apache /var/lib/pulp/test
# set security context to something different
sudo chcon 'system_u:object_r:var_run_t:s0' /var/lib/pulp/test
# verify security context
ls -laZ /var/lib/pulp

Upgrade to 2.6.1 and check the security context of /var/lib/pulp/test is still 'system_u:object_r:var_run_t:s0'.

#14 Updated by pthomas@redhat.com almost 5 years ago

  • Status changed from ON_QA to VERIFIED
  • QA Contact set to pthomas@redhat.com

#15 Updated by pthomas@redhat.com almost 5 years ago

wrote:
wrote:
verified

upgraded from 2.5-> 2.6
before upgrade
[root@qe-blade-11 ~]# ls -laZ /var/lib/pulp
drwxr-xr-x. apache apache system_u:object_r:httpd_sys_rw_content_t:s0 .
drwxr-xr-x. root   root   system_u:object_r:var_lib_t:s0   ..
 drwxr-xr-x. apache apache system_u:object_r:httpd_sys_rw_content_t:s0 celery
 drwxr-xr-x. apache apache system_u:object_r:httpd_sys_rw_content_t:s0 content
drwxr-xr-x. apache apache system_u:object_r:httpd_sys_rw_content_t:s0 published
-rw-r--r--. apache apache system_u:object_r:httpd_sys_rw_content_t:s0 sn.dat
drwxr-xr-x. apache apache system_u:object_r:httpd_sys_rw_content_t:s0 static
 -rw-r--r--. apache apache system_u:object_r:var_run_t:s0   test
drwxr-xr-x. apache apache system_u:object_r:httpd_sys_rw_content_t:s0 uploads
drwxr-xr-x. apache apache system_u:object_r:httpd_sys_rw_content_t:s0 working
[root@qe-blade-11 ~]# 
<\pre>

after upgrade
 <pre>
[root@qe-blade-11 ~]# ls -laZ /var/lib/pulp
drwxr-xr-x. apache apache system_u:object_r:httpd_sys_rw_content_t:s0 .
drwxr-xr-x. root   root   system_u:object_r:var_lib_t:s0   ..
drwxr-xr-x. apache apache system_u:object_r:httpd_sys_rw_content_t:s0 celery
drwxr-xr-x. apache apache system_u:object_r:httpd_sys_rw_content_t:s0 content
drwxr-xr-x. apache apache system_u:object_r:httpd_sys_rw_content_t:s0 published
-rw-r--r--. apache apache system_u:object_r:httpd_sys_rw_content_t:s0 sn.dat
drwxr-xr-x. apache apache system_u:object_r:httpd_sys_rw_content_t:s0 static
-rw-r--r--. apache apache system_u:object_r:var_run_t:s0   test
drwxr-xr-x. apache apache system_u:object_r:httpd_sys_rw_content_t:s0 uploads
drwxr-xr-x. apache apache system_u:object_r:httpd_sys_rw_content_t:s0 working
[root@qe-blade-11 ~]#

<\pre>

#16 Updated by dkliban@redhat.com over 4 years ago

  • Status changed from VERIFIED to CLOSED - CURRENTRELEASE

#18 Updated by pulpbot almost 3 years ago

  • Verified changed from No to Yes

#19 Updated by bmbouter 10 months ago

  • Tags Pulp 2 added

Please register to edit this issue

Also available in: Atom PDF