search

fedora-copr / copr

RPM build system - upstream for https://copr.fedorainfracloud.org/
113 stars 62 forks source link

Issue with copr git #3266

Closed andersrh closed 5 months ago

andersrh commented 5 months ago

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 commented 5 months ago

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

FrostyX commented 5 months ago

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 commented 5 months ago

Hi @FrostyX

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

samoht0 commented 5 months ago

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

praiskup commented 5 months ago

Red Hat Copr fix needed.

praiskup commented 5 months ago

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

FrostyX commented 5 months ago

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 commented 5 months ago

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.