Hi,
Just noticed after update to proget (docker) 25.0.8:
In the gui, the version of a rpm package is displayed correctly:
But dnf (or yum) cannot find the package anymore. sudo dnf update should update the locally installed cloudtools, but instead the following is displayed:
Notice the release number in the listing is cut off (dash remains) and when the actual download is attempted, both the dash and the number are missing.
Suspect: PG-3074 (just a gut feeling 
)
Cheers,
-Fritz
As a reference and perhaps an example for how to run proget as quadlets, here are my config files for quadlets:
[Unit]
Description=Microsoft SQL server
[Service]
Restart=always
# Extend Timeout to allow time to pull the image
TimeoutStartSec=900
[Container]
Image=mcr.microsoft.com/mssql/server:2019-latest
EnvironmentFile=/etc/mssql.env
Volume=/var/data/mssql:/var/opt/mssql:U,Z
Network=inedo.network
HostName=inedo-sql
[Install]
WantedBy=multi-user.target
[Unit]
Description=Inedo proget
After=mssql.service
Requires=mssql.service
[Service]
Restart=always
# Extend Timeout to allow time to pull the image
TimeoutStartSec=900
[Container]
Image=localhost/proget:current
EnvironmentFile=/etc/proget.env
Volume=/var/data/proget/backups:/var/proget/backups:z
Volume=/var/data/proget/database:/var/proget/database:z
Volume=/var/data/proget/extensions:/var/proget/extensions:z
Volume=/var/data/proget/packages:/var/proget/packages:z
Volume=/var/data/proget/ssl:/var/proget/ssl:z
Volume=/etc/localtime:/etc/localtime:ro
Network=inedo.network
PublishPort=80:80
HostName=proget
[Install]
WantedBy=multi-user.target
[Network]
Remarks:
The Image in /etc/containers/systemd/proget.container is intentionally referencing a locally tagged image. This goes together with the following script for easily updating
proget:
#!/bin/bash
set -e
set -x
systemctl stop proget
sleep 5
itag=latest
if [ $# -eq 1 ] ; then
itag=$1
fi
podman tag proget:current proget:previous
podman pull proget.inedo.com/productimages/inedo/proget:${itag}
podman tag proget.inedo.com/productimages/inedo/proget:${itag} proget:current
systemctl start proget
cat<<EOF
Upgrade finished and proget started.
Old image has benn tagged proget:previous
EOF
and: Obviously, the hierarchy below /var/data/proget has to be manually created in advance. /var/data/proget is on a separate virtual disk.
Forgot the env files referenced in the .container files:
/etc/mssql.env:
ACCEPT_EULA=Y
MSSQL_SA_PASSWORD=*****REDACTED*****
MSSQL_PID=Express
/etc/proget.env:
PROGET_SQL_CONNECTION_STRING=Data Source=inedo-sql; Initial Catalog=ProGet; User ID=sa; Password=*****REDACTED*****
TZ=Europe/Berlin
Both are mode 0600, so that the passwords in there are a little bit more protected.
And: Just after freshly setting it all up, I normally immediately migrate to embedded postgres and then remove the mssql container as well as the inedo network.
Cheers
-Fritz
@wechselberg-nisboerge_3629 said in ERROR while migrating maven repository from Jfrog Artifactory.:
I am especially confused about the fact that it prints Windows paths, even though it is running as Linux Docker container.
That one fooled me previously as well, but if you look carefully, those are source paths from their build-system
e.g. C:\Users\builds\AppData\Local\Temp\InedoAgent\BuildMaster\...
@atripp I tested this one and it works.
However:
In the meantime, i have updated to the released 25.0.9 (aka latest) and now I cannot reproduce the error either - even if I explicitely revert the function to the old one where it produced the error before 
So I'm afraid that i might not be a reliable tester for this specific error anymore.
Cheers
-Fritz
@gdivis That was the missing information (wait 30sec AND fetch repodata) - it works as described.
To summarize what lead me to incorrectly assume that it was not fixed:
Thanks again for your clarification
-Fritz
As a reference and perhaps an example for how to run proget as quadlets, here are my config files for quadlets:
[Unit]
Description=Microsoft SQL server
[Service]
Restart=always
# Extend Timeout to allow time to pull the image
TimeoutStartSec=900
[Container]
Image=mcr.microsoft.com/mssql/server:2019-latest
EnvironmentFile=/etc/mssql.env
Volume=/var/data/mssql:/var/opt/mssql:U,Z
Network=inedo.network
HostName=inedo-sql
[Install]
WantedBy=multi-user.target
[Unit]
Description=Inedo proget
After=mssql.service
Requires=mssql.service
[Service]
Restart=always
# Extend Timeout to allow time to pull the image
TimeoutStartSec=900
[Container]
Image=localhost/proget:current
EnvironmentFile=/etc/proget.env
Volume=/var/data/proget/backups:/var/proget/backups:z
Volume=/var/data/proget/database:/var/proget/database:z
Volume=/var/data/proget/extensions:/var/proget/extensions:z
Volume=/var/data/proget/packages:/var/proget/packages:z
Volume=/var/data/proget/ssl:/var/proget/ssl:z
Volume=/etc/localtime:/etc/localtime:ro
Network=inedo.network
PublishPort=80:80
HostName=proget
[Install]
WantedBy=multi-user.target
[Network]
Remarks:
The Image in /etc/containers/systemd/proget.container is intentionally referencing a locally tagged image. This goes together with the following script for easily updating
proget:
#!/bin/bash
set -e
set -x
systemctl stop proget
sleep 5
itag=latest
if [ $# -eq 1 ] ; then
itag=$1
fi
podman tag proget:current proget:previous
podman pull proget.inedo.com/productimages/inedo/proget:${itag}
podman tag proget.inedo.com/productimages/inedo/proget:${itag} proget:current
systemctl start proget
cat<<EOF
Upgrade finished and proget started.
Old image has benn tagged proget:previous
EOF
and: Obviously, the hierarchy below /var/data/proget has to be manually created in advance. /var/data/proget is on a separate virtual disk.
Forgot the env files referenced in the .container files:
/etc/mssql.env:
ACCEPT_EULA=Y
MSSQL_SA_PASSWORD=*****REDACTED*****
MSSQL_PID=Express
/etc/proget.env:
PROGET_SQL_CONNECTION_STRING=Data Source=inedo-sql; Initial Catalog=ProGet; User ID=sa; Password=*****REDACTED*****
TZ=Europe/Berlin
Both are mode 0600, so that the passwords in there are a little bit more protected.
And: Just after freshly setting it all up, I normally immediately migrate to embedded postgres and then remove the mssql container as well as the inedo network.
Cheers
-Fritz
I am running the docker container on Rocky 9 and here, the license keeps valid.
Since rocky and alma are very similar, this must either be some difference of
podman or related to how you exactly start the container.
So:
How exactly do you start your container(s)? I use quadlets - the recommended way on RHEL.
Cheers
-Fritz
Ok, while I was testing on the sandbox (without being able to reproduce the error), the repodata files on my "production" proget got regenerated and since that happened, everything is working again. So this just leaves the question:
Out of curiosity:
How does one force the regeneration of those repodata files?
Obviously not one of these (tried those before)
Cheers
-Fritz
Hi, thanks for the response..
@gdivis said in ProGet bug - Regression: RPM feed repodata broken since 25.0.8:
One thing to note is that those repodata files in storage only get updated on-demand - so something would have to actually make a request for the index to get ProGet to rebuild it
For clarification, can you elaborate a little bit on that? I mean either deleting or uploading a package would count as "something", or does the content of the repodata files get completely held in memory by proget even if some update happens?
Anyway, I will setup a proget sandbox instance and see if I can reproduce it there. Will report back and/or open a ticket when I got more details.
Just a humble reminder - PG-3094 did not fix the problem in 25.0.9 for me.
Thanks
-Fritz
@wechselberg-nisboerge_3629 said in ERROR while migrating maven repository from Jfrog Artifactory.:
I am especially confused about the fact that it prints Windows paths, even though it is running as Linux Docker container.
That one fooled me previously as well, but if you look carefully, those are source paths from their build-system
e.g. C:\Users\builds\AppData\Local\Temp\InedoAgent\BuildMaster\...
@atripp I did write this from memory and I don't recall where exactly I saw the IP logged. But I usually look only in two places:
Unfortunately the system journal has just been rotated (1st of September) and I keep old logs only for the last month so I looked into the August logs, but the error (something reladed to an old Debian feed) wasn't in there either. Must have happened before.
Anyway, it would be very useful if you log either the remote-ip or (if exists) the X-Forwarded-For header value.
Something like this (pseudo code based on C):
printf("some error from %s", (xForwardedValue && strlen(xForwardedValue)) ? xForwardedValue : remoteIp);
Cheers
-Fritz
@atripp I tested this one and it works.
However:
In the meantime, i have updated to the released 25.0.9 (aka latest) and now I cannot reproduce the error either - even if I explicitely revert the function to the old one where it produced the error before
So I'm afraid that i might not be a reliable tester for this specific error anymore.
Cheers
-Fritz
@atripp said in proget 500 Internal server error when pushing to a proget docker feed:
we can also try to add something that allows you to patch via the UI as well!!
Huh? Well, I don't think this would be such a good idea. I assume you guys already have some code in proget for upgrading your DB-Schema when a new version is required. That's where the function should be replaced. This script is only meant as a intermediate solution until you guys have updated the function.
Cheers
-Fritz