proget:25.0.22-ci.4 seems to work.
The CPU consumption stays steady while ProGet is not under heavy load. The Debian connectors does not grow infitely. So for the third day this is the output:
root@xxxxxxxxxxxxxx:/usr/share/ProGet/LocalStorage/Connectors# du -chs * | grep G
2.6G total
I'll get back to you on this in a week.
Thank you for the support.
Hi,
we had the same issue.
For Debian Trixie, there is a negative effect with sqv (Seqouia Verification Tool) using the universal signing key. When verifying the signing key, a message with (... --not-after ...) and exit status 1 is displayed. It is necessary to check whether the time has been synchronized correctly!!!
Here is what you need to check:
timedatectl
...
System clock synchronized: yes # It should be yes, if your environment is using ntp-server.
...
@gdivis Thank you very much. We will do the test. Stay tuned for my feedback.
Thank you for your response. We also have a Proget test environment where we can test this. We would like to test it.
Here is another example of this behavior. These are only Debian connectors:
root@xxxxxxxxxxxxxx:/usr/share/ProGet/LocalStorage/Connectors# du -chs * | grep G
2.4G C104
2.5G C105
2.5G C106
62G C117
13G C266
9.2G C268
15G C281
3.1G C63
119G total
Hi,
some Debian feeds, especially for kali-rolling, are very slow after a day since the connector was renewed. I have to repeatedly reset or renew the connector in order to be able to work with it.
If not, an “apt update” takes several minutes or it is going to be stucked up. The index.sqlite files grow to up to 50 GB. In addition, index.sqilte3-shm and -wal also grow to almost the same size. And CPU consumption increases proportionally to these problems. And if the connectors are not renewed, the sqlite database consumes all the available storage space in the partition where the volumes for packages are located.
Additional Information:
Upstream link that we are testing and using:
http://mirror.netcologne.de/kali/
http://http.kali.org/kali
ProGet version: 2025.20(Build 23) with external database (MSSQL), both in containers
Connector configuration: Index poll frequency is already set to triple digits in minutes.
Further Information I've already researched:
Please investigate this behavior. In addition to RPM repos, we also use a lot of Debian repos.
If the cause is known, can you implement additional clean measures in addition to “Index poll frequency”?
Can the problem perhaps be avoided by using a proxy?
Update:
And we found some images like busybox:1.37 which is directly pulled from upstream dockerhub. This is the same case. The ProGet-Layer-Scanner is not able to find any packages in there.
Hi,
thanks for quick response.
Yes, we do see that logs. And we are not using gzip as compression-format. So this is a naturely the effect, when we are using zstd. right?
For the moment is the solution, to avoid using other compression-format, because ProGet Layer-Scanner is not supporting zstd???
Hello,
We always use podman push with --compression-format=zstd:chunked in our CI/CD.
But when it comes to layer scanning on ProGet, neither the packages nor the vulnerabilities are suddenly listed for the pushed images.
Otherwise, images pushed with the default settings of podman push are scanned correctly.
Thank you very much and best regards
Hello,
Note on the instructions for downloading packages from Debian Feed. The syntax of the command is incorrect there. You can find
For example: sudo apt install “binutils:2.44-3”
Instead of a colon, the command should look like this: sudo apt install “binutils=2.44-3” or, with a colon, sudo apt install “binutils:amd64=2.44-3”
Thank you very much for considering my request. I truly appreciate the time and attention you’ve given to review it. Your willingness to listen to user feedback means a lot, and I’m grateful that this suggestion has been taken into account.