Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue with copr git #3266

Closed
andersrh opened this issue May 18, 2024 · 8 comments
Closed

Issue with copr git #3266

andersrh opened this issue May 18, 2024 · 8 comments
Assignees

Comments

@andersrh
Copy link

Hi.

I have tried to make a build this morning for our project because a new linux kernel release came out.

When I start the build I get 500 error from the copr git repo and the build fails.

log can be found here:

https://download.copr.fedorainfracloud.org/results/bieszczaders/kernel-cachyos-dev/fedora-39-x86_64/07456843-kernel-cachyos-lts/builder-live.log.gz

@samoht0
Copy link

samoht0 commented May 18, 2024

The same for all recent builds.
https://copr.fedorainfracloud.org/recent/all/

@FrostyX
Copy link
Member

FrostyX commented May 18, 2024

Thank you for the report @andersrh and @samoht0,
the issue is fixed now.

It was caused by a git package update, specifically:

 git                 x86_64        2.45.1-1.fc39          updates         53 k
 git-core            x86_64        2.45.1-1.fc39          updates        4.7 M
 git-core-doc        noarch        2.45.1-1.fc39          updates        2.9 M
 git-daemon          x86_64        2.45.1-1.fc39          updates        389 k
 perl-Git            noarch        2.45.1-1.fc39          updates         39 k

I think we should configure our servers to not run automatic security upgrades on weekends ...

Not sure what is the problem with the new git, so I only did

[root@copr-dist-git ~][PROD]# dnf downgrade git
[root@copr-dist-git ~][PROD]# dnf versionlock git

as a workaround until somebody can investigate the issue properly.

@andersrh
Copy link
Author

Hi @FrostyX

Thanks a lot :) it seems to be working now :)

@samoht0
Copy link

samoht0 commented May 18, 2024

Yeah, working fine again. Thanks for the quick solution.

@praiskup
Copy link
Member

Red Hat Copr fix needed.

@praiskup
Copy link
Member

@FrostyX claims we should check if we can configure dnf-automatic for non-weekend times

@FrostyX
Copy link
Member

FrostyX commented Jun 4, 2024

The mentioned git update is now available
https://bodhi.fedoraproject.org/updates/FEDORA-2024-630b8cf863

It didn't help but I can finally see the errors in the httpd log:

AH01215: stderr from /usr/libexec/git-core/git-http-backend: fatal: detected dubious ownership in repository at '/var/lib/dist-git/git/frostyx/foo/copr-cli.git'
AH01215: stderr from /usr/libexec/git-core/git-http-backend: To add an exception for this directory, call:
AH01215: stderr from /usr/libexec/git-core/git-http-backend:
AH01215: stderr from /usr/libexec/git-core/git-http-backend: \tgit config --global --add safe.directory /var/lib/dist-git/git/frostyx/foo/copr-cli.git

This is probably caused by the fact that the directory is owned by the copr-dist-git user and the web server is running under the apache user. Creating /etc/gitconfig with

[safe]
        directory = /var/lib/dist-git/git/frostyx/foo/copr-cli.git
        directory = .

works and makes it possible to clone the repository. For the record, I don't know what directory = . means.

The problem is that it is not possible to configure /var/lib/dist-git/git/ to be safe recursively and we would have to add every new repository manually. Not fun with our 789533 repositories.

The only thing that works is

[safe]
        directory = *

which completely disables the feature. Per man git-config:

To completely opt-out of this security check, set safe.directory to the string *. This will allow all repositories to be treated as if their directory was listed in the safe.directory list.

Which isn't ideal but may be fine in our situation?

@FrostyX
Copy link
Member

FrostyX commented Jun 5, 2024

I am keeping this open because I still want to send a message to git mailing list. But I deployed the fix and we are now running the up-to-date version of git, so technically, the issue is fixed.

@FrostyX FrostyX closed this as completed Jun 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

No branches or pull requests

4 participants