Project

Profile

Help

Issue #8620

closed

pulp_installer fails to recognize pulpcore_port_t

Added by mdepaulo@redhat.com over 1 year ago. Updated about 1 year ago.

Status:
MODIFIED
Priority:
Normal
Category:
Installer - Moved to GitHub issues
Sprint/Milestone:
-
Start date:
Due date:
Estimated time:
Severity:
2. Medium
Version:
Platform Release:
OS:
Triaged:
Yes
Groomed:
No
Sprint Candidate:
No
Tags:
Sprint:
Sprint 100
Quarter:

Description

This task failed for newswangerd :

TASK [pulp.pulp_installer.pulp_api : Apply the SELinux type to the TCP port that pulpcore-api listens on] *************
An exception occurred during task execution. To see the full traceback, use -vvv. The error was: ValueError: Type pulpcore_port_t is invalid, must be a port type
fatal: [localhost]: FAILED! => {"changed": false, "msg": "ValueError: Type pulpcore_port_t is invalid, must be a port type\n"}

I suspect the problem was that the handlers for installing the selinux policies in the dependency role pulp_common were not run.

I suspect that happened because pulp-api was run without pulp_database_config being run 1st, which would have called meta: flush_handlers.

So the solution would be to add meta: flush_handlers in either pulp_common after SELinux policies get installed, or in both pulp_api and pulp_content before applying the label

Actions #1

Updated by mdepaulo@redhat.com over 1 year ago

  • Assignee set to mdepaulo@redhat.com
  • Triaged changed from No to Yes
Actions #2

Updated by mdepaulo@redhat.com over 1 year ago

A user manually applied the policy (to work around this) after an upgrade, but still got errors:

https://listman.redhat.com/archives/pulp-list/2021-May/msg00031.html

I will investigate them while working on this.

SELinux is preventing /usr/libexec/platform-python3.6 from read access on the l nk_file /var/lib/pulp/assets/admin/css/autocomplete.css

SELinux is preventing /usr/libexec/platform-python3.6 from name_connect access on the tcp_socket port 5432

SELinux is preventing /usr/libexec/platform-python3.6 from create access on the file /var/run/pulpcore-worker-1/

Actions #3

Updated by dkliban@redhat.com about 1 year ago

This problem occurred for me because the handlers are only fired after a play finishes AND if the task that is supposed to notify the handler produces a change. The first time I ran the installer, I had an error occur during the preflight check so the handler did not run. The second time I ran the installer the task that compiles the selinux policy didn't produce the change so the handler did not run. Flushing the handlers right after the policy is installed will prevent a similar problem from occurring in the future.

Actions #4

Updated by dkliban@redhat.com about 1 year ago

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

Added by dkliban@redhat.com about 1 year ago

Revision f14af642

Flush the handlers right after the SELinux policy is compiled

fixes: #8620 https://pulp.plan.io/issues/8620

Added by dkliban@redhat.com about 1 year ago

Revision f14af642

Flush the handlers right after the SELinux policy is compiled

fixes: #8620 https://pulp.plan.io/issues/8620

Actions #5

Updated by pulpbot about 1 year ago

  • Status changed from ASSIGNED to POST
Actions #6

Updated by dkliban@redhat.com about 1 year ago

  • Status changed from POST to MODIFIED
Actions #7

Updated by dkliban@redhat.com about 1 year ago

  • Status changed from MODIFIED to ASSIGNED
Actions #8

Updated by dkliban@redhat.com about 1 year ago

  • Status changed from ASSIGNED to MODIFIED

Also available in: Atom PDF