Posts made by stefan.hakansson_8938

@stevedennis thank you for the update and insights. Looking forward to what Q4 (or later) will bring!

@dan-brown_0128 thanks for the update. I'll ponder about what we should do and provide an update here if we find a solution involving ProGet as debian mirror with a decent performance.

Hi @dan-brown_0128 have you made any further progress on this? I'm seeing exactly the same behaviour, and it makes things like Ansible playbooks involving apt: update_cache: yes time out.

Any tip on how to improve the performance would be great (I have a default ProGet installation with default database and web server BTW).

Thanks,
Stefan

Thank you @stevedennis, this makes sense.

One odd thing is that I noted that when I had set metadatacache=true using pgutil, the time the WebUI showed Loading Packages.... and the time it took to do sudo apt update in clients went from long to super long. It went back to long when I set metadatacache=false again. I don't know if there is a logical explanation for this or of it was just a coincidence.

Br,
Stefan

Hi @stevedennis, thank you for looking into this.

I was on ProGet 2025.1 Build 5, and just upgraded to ProGet 2025.2 Build 15

$ ./pgutil health
Checking https://packages.prod.antura.cloud/...all OK
Version: 2025.2 (Build 15) (2025.2 (Build 15))

Database: OK
License:  OK
Service:  OK
$ ./pgutil connectors properties list --connector="noble updates"
url=https://archive.ubuntu.com/ubuntu/
feedType=debian
timeout=60
metadataCacheEnabled=true
metadataCacheCount=100
metadataCacheMinutes=30

while the Web UI looks like

I will be away for a few weeks now but will investigate more when I'm back, I just wanted to upload the info I have now.

Best regards,
Stefan

Hi @stevedennis, thank you.

I contemplated the idea store the fingerprint in another location (and doing so at a point in time when I'm convinced things are not compromised), and then, when a new host is to subscribe to the ProGet feed, compare the calculated fingerprint of the ProGet provided key with the one obtained from the other store. If they do not match I know one of them have been tampered with.

But maybe I'm going overboard, and I still can do it by downloading the key to the second location and calculating the fingerprint there if I really want to, so things are fine.

Thank you again,
Stefan

Hi,

I did pgutil connectors properties set --connector=myconnector --property=metadataCacheEnabled --value=true, and when then doing pgutil connectors properties list --connector=myconnector it says metadataCacheEnabled=true.

However, it is still said being disabled in the Web UI.

Br,
Stefan

Hi,

I think it is best practice to verify the fingerprint of a signing key before accepting it. I do not think it is super important in my case as I am in control of ProGet and the Ubuntu clients that are to use the ProGet instance for apt update, apt ungradeetc. as well as the network connecting these entities.

But I wanted to ask anyway: can the fingerprint be obtained? How (I'm sorry if it is obvious)? (I guess I could do one download and trust that one, and then calculate the fingerprint myself, but asking if it is directly available)

Br,
Stefan

Hi Steve, thank you!

I will try badssl.com out and see how ProGet reacts.

Thank you again,
Stefan

Thank you Steve!

I also noted that the defaults in setting up a connection proposes http - perhaps something to update eventually as well.

Given the reliance on SSL/HTTPS, can you tell what verification ProGet does in terms of certificate, certificate chain and hostname (and what else that can be verified - I'm no expert, but want to make sure someone cannot pretend to be archive.ubuntu.com and get through with it).

Cheers,
Stefan

Hi,

sorry if this is documented or clarified already (please supply a pointer in that case).

I am setting up ProGet as an apt mirror, and I try to understand the trust model. There are clear instructions on how to add (I guess it is) ProGet's .asc (dearmoured) to the downstream hosts. But how does ProGet verify the upstream? A standard ubuntu.sources seem to look something like

Types: deb
URIs: http://archive.ubuntu.com/ubuntu/
Suites: noble noble-updates noble-backports
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

and when setting up a connector in ProGet I had expected to have to add a key, but did not have to. Further, the URI is w/o tls, so using http://archive.ubuntu.com/ubuntu/ in the connector, and not adding a key, seems to make this open to mitm attacks. And notably the example in "Connectors for Debian (apt) feeds" (https://docs.inedo.com/docs/proget/feeds/debian#connectors-for-debian-apt-feeds) uses http, not https.

TL; DR basically I want to know the trust model, what kind of verifications done by ProGet, and how to best setup the upstream part of an apt-mirror feed.

Br,
Stefan

Thanks @rhessinger, that clarifies things, and I can move on. Best regards, Stefan

Using the default / built-in for everything.

When trying in InedoHub (on-line version) I get the error "Upgrade Blocked" "DBO privileges are required for the product's connection string to upgrade to this version."

Great, thanks!

Hi Steve, I fully understand. I will carry on using the existing format then. Thanks for the tip regarding use of pgutil!

Thanks,
Stefan

Hi Steve, thanks for responding so quickly.

I think deb822 is a newer format (than the "one-line-style" format), and it is preferred in the context I'm working in. There is some info in https://manpages.debian.org/stretch/apt/sources.list.5.en.html.

I have to focus on other stuff for some time now, so perhaps we can let this one rest until I can provide more input. But for some info, my /etc/apt/sources.list.d/ubuntu.sources file contains
Types: deb
URIs: http://sto1.clouds.archive.ubuntu.com/ubuntu/
Suites: noble noble-updates noble-backports
Components: main
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

I hope to be able to just replace the URI (and the key) to point at a ProGet feed connected to http://sto1.clouds.archive.ubuntu.com/ubuntu/ that I have setup. However it seems that curl http://sto1.clouds.archive.ubuntu.com/ubuntu/ returns something that I can not obtain from curling to the ProGet feed so I am not sure it will work. But let me investigate more and come back later.

Of course it is possible to work around and go back to .list files, buf my preference would be to keep using .sources.

Thanks,
Stefan

The instructions should be updated, instead of
&& sudo apt-key add "feedname.gpg"
something like
| gpg --dearmor | sudo tee /etc/apt/keyrings/feedname.gpg > /dev/null
should be used, and
echo "deb http..... should be something like
echo "deb [signed-by=/etc/apt/keyrings/feedname.gpg] http....
(if I have understood things correctly)

Recent Ubuntu releases use deb822 / ubuntu.sources for package handling. However, if I connect an deb822 source (e.g., http://sto1.clouds.archive.ubuntu.com/ubuntu/) to a feed, it seems that the output of that feed is not deb822 but rather according to the old format. Is there any plan to properly handle deb822 sources in ProGet?