Bug 2219647

Summary: ServiceInfoApiServer failed to start if files section configured
Product: Red Hat Enterprise Linux 9 Reporter: Xiaofeng Wang <xiaofwan>
Component: fido-device-onboardAssignee: idiez
Status: CLOSED DUPLICATE QA Contact: Xiaofeng Wang <xiaofwan>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: CentOS StreamCC: bstinson, idiez, jwboyer, miabbott, perobins
Target Milestone: rcKeywords: Triaged
Target Release: 9.3   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-08-03 10:00:59 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Xiaofeng Wang 2023-07-04 17:34:43 UTC
Description of problem:
Start fdo-aio service failed when the "files:" section configured, like
sudo /usr/local/bin/yq -iy '.service_info.files |= [{path: "/etc/sudoers.d/fdouser", source_path: "/tmp/fdouser"}]' /etc/fdo/aio/configs/serviceinfo_api_server.yml

If removed files section configuration and set to "files: null", service fdo-aio can get started.

I also tried "service_info.diskencryption_clevis" and "service_info.initial_user", service can get started.

This issue does not exist on CS9 repo CentOS-Stream-9-20230626.0

Version-Release number of selected component (if applicable):
  fdo-admin-cli-0.4.7-3.el9.x86_64                                              
  fdo-client-0.4.7-3.el9.x86_64                                                 
  fdo-init-0.4.7-3.el9.x86_64                                                   
  fdo-manufacturing-server-0.4.7-3.el9.x86_64                                   
  fdo-owner-cli-0.4.7-3.el9.x86_64                                              
  fdo-owner-onboarding-server-0.4.7-3.el9.x86_64                                
  fdo-rendezvous-server-0.4.7-3.el9.x86_64

How reproducible:

Steps to Reproduce:
1. Deploy a CS9 instance from GCP
2. git clone https://github.com/virt-s1/rhel-edge.git
3. cd rhel-edge && ./ostree-simplified-installer.sh

Actual results:
Service fdo-aio should get started

Expected results:
Failed to start fdo-aio service

Additional info:

Comment 1 idiez 2023-07-05 13:45:21 UTC
this is the concrete error:

systemd[1]: Started FDO service info API server.
fdo-serviceinfo-api-server[75684]: Error: Error preparing ServiceInfo configuration
fdo-serviceinfo-api-server[75684]: Caused by:
fdo-serviceinfo-api-server[75684]:     0: Failed to read file /tmp/fdouser
fdo-serviceinfo-api-server[75684]:     1: Permission denied (os error 13)
fdo-serviceinfo-api-server.service: Main process exited, code=exited, status=1/FAILURE
fdo-serviceinfo-api-server.service: Failed with result 'exit-code'.

Comment 2 Xiaofeng Wang 2023-08-03 09:27:01 UTC
Still have selniux issue on FDO packages:
fdo-rendezvous-server-0.4.12-1.el9_2.x86_64
fdo-owner-onboarding-server-0.4.12-1.el9_2.x86_64
fdo-owner-cli-0.4.12-1.el9_2.x86_64
fdo-manufacturing-server-0.4.12-1.el9_2.x86_64
fdo-admin-cli-0.4.12-1.el9_2.x86_64

The manufacturing-server error log:
fdo-manufacturing-server[22613]:  2023-08-03T03:35:41.627Z WARN  fdo_http_wrapper::server > Error processing request: Rejection([Error(ErrorMessage { error_code: InternalServerError, previous_message_type: DIUNConnect, error_string: "Error storing session", error_timestamp: None, error_uuid: 17963275242146807119 }), MethodNotAllowed])
fdo-manufacturing-server[22613]:  2023-08-03T03:35:41.628Z INFO  manufacturing-server     > 192.168.100.50:41750 "POST /fdo/101/msg/210 HTTP/1.1" 500 "-" "-" 10.0919ms

So the manufacturing-server reply with error code 500 (internal error) to 192.168.100.50 (edge vm)

I disabled selinux with `setenforce 0` and run again. Didn't catch this kind of error in manufacturing-server log. Every manufacturing-server log looks reasonable.

Comment 3 Peter Robinson 2023-08-03 09:34:35 UTC
So I think if we run all the services in permssive mode and gather the AVC logs for all the services, looks like it's manufacturing and service-info-api at the moment but I bet they'll all have issues, we should be able to come up with a set of rules for this. Xiaofeng are you able to do this? Maybe one comment for each of the services?

Comment 4 Xiaofeng Wang 2023-08-03 10:00:59 UTC

*** This bug has been marked as a duplicate of bug 2026795 ***