The link (symlink) that point to the real package in a repository (content view) are broken so I can find a package but when I try to download it I have a 404 file not found. If I look in the file system
ls -l /var/lib/pulp/published/yum/http/repos/ORG/Library/CentOS_6/custom/EPEL_6/x86_64/Packages/g/*
I have all broken symlink there
So how can I repair all those symlink ?
Get the package and content view working
Foreman and Proxy versions:
Foreman and Proxy plugin versions:
Other relevant data:
[e.g. logs from Foreman and/or the Proxy, modified templates, commands issued, etc]
Don’t think it’s so newbie … I don’t need to republish a new CV but fix one that have broken symlink. This problem came with GeoIP-GeoLite-Data that is in EPEL 6 Repo. The EPEL 6 repo is part of a composite CV. If I look in the EPEL 6 Repo I can see that the rpm should be there but if I follow the link to download the file I have 404 file not found. The file is in the EPEL 6 repo but not in the CV. If I look on the server, the symlink is RED so it’s pointing to a wrong place and that’s the problem … To solve this problem, I republished the CV and now in the new version of the CV EPEL 6 the file is there but not in the previous version. The problem is that I had to move on with update that we didn’t test in DEV first.
The issue came out 3 days ago and I didn’t change any of the logging default because the symlinks wasn’t good so event if I change logging the problem occur before so if not in the log it won’t be after the change to the logging level.
These broken symlinks you’re seeing are likely ‘normal’ and are the result of the base repository having a download policy of “On_Demand”. This download policy means that packages are not actually downloaded locally until some client fetches them (hence the broken symlinks). In this case my guess is that the packages were deleted from the upstream repo before any of your clients actually requested them.
For Epel, i would highly recommend using the immediate download policy, as this will cause all the rpms to downloaded as part of the sync and not wait for a client to request them. To do this go to Content > Products > click your product > click your repo > click on the Download Policy and chnage it to ‘Immediate’. Then simply re-sync the repo. You will have to republish your content view(s) to cause the new packages to be seen (which it seems you’ve already done and confirmed it resolved the issue).
YES … That put light on what happened exactly and I LOVE to know what happen even if I can solve the problem. The RPM was replace by EPEL for GeoIP-GeoLite-Data 2018 and my server was asking for GeoIP-GeoLite-Data 2017 and “on-demand” didn’t download the RPM before EPEL removed it and replaced it by the 2018.
I’ll change to policy to “immediate” as you said to solve futur issue like this.
It happen again and the policy is now “Immediate” for the repo. Probably because I created the repo with “On demand” and change it to “Immediate”, the download doesn’t work. It still do “On demand”. So, is there a way to force the download when it’s set to “Immediate”