Bug 1841192

Summary:	leapp fails to use repositories configured with file:///
Product:	Red Hat Enterprise Linux 7	Reporter:	jcastran
Component:	leapp-repository	Assignee:	Leapp Notifications Bot <leapp-notifications-bot>
Status:	CLOSED MIGRATED	QA Contact:	upgrades-and-conversions
Severity:	medium	Docs Contact:	Miriam Portman <mportman>
Priority:	medium
Version:	7.9	CC:	bhoefer, fkrska, kwalker, lkuprova, mbocek, mmacura, mportman, podvody, pstodulk
Target Milestone:	rc	Keywords:	MigratedToJIRA
Target Release:	---	Flags:	pm-rhel: mirror+
Hardware:	All
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Known Issue
Doc Text:	When your custom repository is configured to point to a local directory (`baseurl=file:///<path>`), Leapp is unable to access the repository. If you are using the Apache HTTP Server, you can work around this problem by following these steps: 1. Move the repository files to the `/var/www/html/<repository_name>` directory or create a symbolic link. If you choose to use a symlink, navigate to the `/var/www/html/` directory and create the symlink by executing the `ln -s <repository_path>` command. 2. Ensure the repository files have an appropriate SELinux context. In the `/var/www/html/` directory, execute the `ls -Z` command and verify that the command returns the following context for `<repository_path>`: unconfined_u:object_r:httpd_sys_content_t:s0 Alternatively, change SELinux mode to permissive. 3. Change the custom repository configuration to point to `baseurl=http://localhost/<repository_name>`.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2023-09-12 11:02:44 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:
Bug Depends On:
Bug Blocks:	1818077, 1818088

Description jcastran 2020-05-28 15:41:28 UTC

Description of problem:
Using the steps from https://access.redhat.com/articles/4977891 and creating a repo on the system, fails when you use file:/// as the baseurl in /etc/leapp/files/leapp_upgrade_repositories.repo



Version-Release number of selected component (if applicable):
leapp-0.10.0-2.el7_8

How reproducible:
Everytime

Steps to Reproduce:
1. Making baseos and appstream repos on the RHEL 7 machine
    - Requires a RHEL 8 system to reposync them both and the repodata
2. # cat /etc/leapp/files/leapp_upgrade_repositories.repo
[appstream]
name=appstream
baseurl=file:///repo/appstream

[baseos]
name=baseos
baseurl=file:///repo/baseos

3. leapp upgrade --no-rhsm

Actual results:
leapp fails to syncronize cache for the repositories

Expected results:
leapp uses the repos

Additional info:
If you put the repo in /var/www/html and use baseurl=http://localhost/<name> then it works.

Comment 2 Petr Stodulka 2020-05-29 08:45:55 UTC

Hi John,
thanks for the report. We will look at it closer.

Comment 3 Pavel Odvody 2020-05-29 14:19:40 UTC

Thanks John for the info, I'm interested in seeing what errors you were getting because I'm running into slightly different problem -- can you please verify that your local mirror also has `repodata` folder?

I did a quick test and here's what I found:

* I was testing this with only BASEOS repository being local mirror defined with file:///
 - APPSTREAM was too big for my VM disk

Nevertheless, it seems like RPMs provided via fille:/// repository are treated as "local RPMs" and DNF somewhat refuses to depsolve those together with non-file:/// repository:

```
2020-05-28 10:02:09.931819 [ERROR] Actor: dnf_transaction_check
Message: DNF execution failed with non zero exit code.
STDOUT:
Last metadata expiration check: 0:00:48 ago on Thu May 28 10:01:19 2020.
Package python-requests-2.6.0-9.el7_8.noarch is already installed.
Package python-virtualenv-15.1.0-4.el7_8.noarch is already installed.
Package python-urllib3-1.10.2-7.el7.noarch is already installed.
Package python-libs-2.7.5-88.el7.x86_64 is already installed.
Package python-setuptools-0.9.8-7.el7.noarch is already installed.
Package git-1.8.3.1-22.el7_8.x86_64 is already installed.
Package python-devel-2.7.5-88.el7.x86_64 is already installed.

STDERR:
No matches found for the following disable plugin patterns: subscription-manager
Warning: Packages marked by Leapp for install not found in repositories metadata: perl-ExtUtils-Command python2-lxml perl-ExtUtils-Miniperl python3-pyOpenSSL gdb-headless perl-Text-Balanced python3-abrt-addon perl-Math-BigInt-FastCalc mariadb-connector-c python3-libreport python3-systemd dnf-plugin-spacewalk python2-pyyaml python3-babel perl-B-Debug perl-PerlIO-via-QuotedPrint perl-Devel-PPPort perl-open postfix-pgsql python2-ipaddress postfix-ldap git-core-doc perl-perlfaq python2-babel perl-IPC-SysV perl-Devel-Peek python3-langtable perl-Attribute-Handlers python3-pycurl perl-Filter-Simple perl-SelfLoader python2-backports python2-six perl-Net-Ping perl-Memoize perl-bignum git-subtree perl-Pod-Html python2-chardet python2-backports-ssl_match_hostname python3-lxml python3-augeas perl-Test perl-Devel-SelfStubber redhat-backgrounds postfix-mysql perl-Unicode-Collate python3-abrt python3-hwdata python36-devel python3-newt perl-Math-BigRat python3-virtualenv
Transaction check:

 Problem 1: conflicting requests
  - nothing provides python2-six needed by leapp-deps-el8-5.0.0-100.202005261959Z.3a0acf4.master.el8.noarch
 Problem 2: conflicting requests
  - nothing provides python3 needed by leapp-repository-deps-el8-5.0.0-100.202005261959Z.3a0acf4.master.el8.noarch
 Problem 3: conflicting requests
 Problem 4: package git-1.8.3.1-22.el7_8.x86_64 requires /usr/bin/python, but none of the providers can be installed
  - conflicting requests

```

Comment 5 Lenka Špačková 2020-06-25 13:57:32 UTC

Known issue documented in https://access.redhat.com/articles/4977891#repos-known-issues

Comment 6 Michal Bocek 2020-08-17 11:02:53 UTC

Until we have a proper fix for this issue, in the next release of leapp, the upgrade won't be allowed if there's a file:/// used in a repo baseurl. Related upstream PR: https://github.com/oamg/leapp-repository/pull/531

Comment 11 RHEL Program Management 2023-09-12 11:02:12 UTC

Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

Comment 12 RHEL Program Management 2023-09-12 11:02:44 UTC

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.