Posts made by atripp

hi Simon, not too familiar with usage of tzdata or TZ: variables; do you have examples of how these get used or added in containers, especially when we rely on system-provided time. I can make a suggestion to the product team, if it's easy.

hi Simon,

This records are maintained via Package Usage Scanning, which is something that routinely scans external resources for packages, and updates the status when a package is or isn't installed.

It's a little different from deployment records, in that deployment records are historic data and package usage is current data.

While you could write your own PackageContainerScanner by using the Inedo.SDK, Otter can collect the packages that are actually installed on various servers; the Otter-usage scanner (buitl in) simply queries to Otter about the status of those scans.

A server cluster can have up to 5 nodes; so in the case of a HA cluster, then it'd be the $10K for servers (But you could have up to 5).

Hello;

The pricing for ProGet is available on the ProGet Pricing Page.

ProGet Enterprise can be installed as a server cluster, but you'd really be best requesting a quote, because there are a lot of configurations, and we'd want to better understand your use case before we share to you our recommend configuration.

Alana

Hello;

The InedoHub just edits that ProGet.Config file; but in any case, those bindings are only used for the integrated web server, not IIS. We should definitely improve that experience so it's clearer. Are you able to access your instance via http://local.proget.net/ in a browser? If so, then, it seems to have worked.

I don't know npm very well, but I looked at the docs of [npm publish](https://docs.npmjs.com/cli/publish), and it seems that --registry isn't an option on that page. But there's also this page: https://docs.npmjs.com/misc/registry

Hope that helps

Great, thanks!

What specific information is missing from the "landing" page? Even the "old" package page has many tabs, so not everything is displayed.

I'm not sure where to troubleshoot either... ProGet doesn't have any control over upload/download speed, it just uses as fast of connection as possible.

I haven't seen it before. It must be network related, but I'm not so experienced on networking. I think if you search for like, "slow upload/download from docker container" maybe you'll find a lot of advice? Please share what you find

Hello; thanks for the feedback.

In all of the "new view" testing, we received positive feedback from users; and since release, the feedback has almost entirely positive. Our goal was be load faster, break up the relevant information more logically, and simplify the code (thereby reducing bugs in the future and enabling much quicker improvements). However, changes are changes, and they take some "training" to get used to, even for us.

On the "List Packages" page, there are now two links: List Package Versions and Package Package Version:

We may add an enhancement, like "Latest Pre-release" version or something on this list as well, so you can see, there's a lot of opportunity for adding even more relevant info in the future.

I'm guessing, you're simply trained to click on the bigger link (as I am), and aren't clicking on the smaller (version). Do note, on the List Package Versions (the bigger link), we will add more relevant information, such as information about the latest version and pre-release version, vulnerabilities, disk size, etc.

As for the "All Versions", that is now in the bread crumb:

It takes "training" as well. This is where we're hoping the "List Versions Page" will provide a view that will be more informative.

Please continue to share suggestions about improvements, and we'll do our best to make them happen quickly!

As for the "old view", it will be removed at some point... the reason both "old" and "new" are available are so that we provide functionality, and work to improve "new" one.

The JSON-LD (v3) API is available in ProGet 5.3 and later, so please upgrade. We'll update the documentation to clarify that!

Hello; this issue is known now, I've logged an issue and we'll get it fixed in the next release; PG-1727

Release is scheduled for Friday, but we may ship it sooner.

Ah, I can see that.

So, in this case, you'd want to:

• Grant access to Feed API
• Specify a Username to impersonate with the appropriate access to feeds/tasks

In this case, you'll need to remove the Feeds_OverwritePackage privilege from the API Key or User that's doing the push. The behavior you want/expect is not possible otherwise.

nuget.exe does not send any information to ProGet about whether packages should or shouldn't be overwritten; the --skip-duplication option merely treats certain server errors (i.e. a 409 error) as a warning instead of a failure.

Thanks for the very detailed analysis.

The NetBIOS mapping is only used for Windows Integrated Authentication, and to convert names like SOMTHNG\username to username@something.local.

Unfortunately, as you noticed, the "Search recursively" can be painfully slow in some configurations. We're not sure why, it doesn't seem to necessarily be related to the number of groups, or the nesting levels.

The SearchGroupsRecursively option (see code) does not attempt to extract all groups, it simply crawls up the group tree; this is the only way that we could find to get users' nested groups, and we even asked to Microsoft who confirmed this was the way to do it.

HOWEVER, when I say "slow", I mean on the order of "30 seconds", like your PowerShell script. 9 minutes is crazy! Even 5 seconds to load a page, without that option, seems very slow, so there might be some underlying networking/configuration issues?

In any case we can make a few optimizations to recursive searching, but you shouldn't bee seing 5-second page load times in any case.

Sounds neat, we'd love to learn how you have it set-up! This is the first request for this, and like all feature requests, we want to make sure we can document it well.

So I wonder, can you think of a way to improve our documentation with an example of your Stack File, and some mention how you're suing docker swarm to monitor things?

Maybe as a subpage? Here's what we have now:
https://docs.inedo.com/docs/proget/installation/installation-guide/linux-docker

In any case, we are definitely open to collaborating with ways to improve not only our API, but our docs. Seems this might be a great way to work together?

We honestly don't anything but basic knowledge on swarm / Stack Files, so if you could write how you set it up / monitor it, we will be happy to fix the code to work with the docs. I suspect changing the API to work as you requested would be infinitely easier for us than figuring out Docker swarm :)

Also --- please note that we are now using proget.inedo.com instead DockerHub, it seems a lot of other vendors are doing the same, and it's easier for us to maintain our own build process (not possible on Dockerhub).

Hi Ryan,

We'd definitely appreciate any help in getting the forum posts updated, so if you remember which ones you visited, we can try to update them. It'd be nice if we can add a section like "slowness" to this document.. https://docs.inedo.com/docs/various/ldap/troubleshooting

Just to be clear, what do you mean by "Only specified trusted domains"? Can you send a screenshot of your configs?

Can you disable Integrated Windows Authentication from IIS?

About how big is your active directory installation? domains / users / etc?

Also as an FYI, here is the code we use (SDK 1.5 is used in ProGet 5.2, hence the 1.5 version instead of master): https://github.com/Inedo/inedox-inedocore/blob/1.5/InedoCore/InedoExtension/UserDirectories/ADUserDirectory.cs

Thanks.
Alana

There hasn't been any activity or other reports of this problem since I asked the earlier questions.... it's obviously nothing we can reproduce.

If you can help by answering those questions then we can start to investigate. Thanks :)

@atripp said in Debian Feed problem:

How did you create the package? Please share the commands you used, etc.

Can you share this package? Please attach it or upload it

How did you push this package? Please share commands you used to do it

Oh my bad... yes it seems a bug. I looked at GitHub in the UI, anwyays I think it's fixed.

Can you try the new pre-release version?

You can manually install, or point your extensions feed (Advanced SEttigns) to to https://proget.inedo.com/upack/PrereleaseExtensions/

https://proget.inedo.com/packages/overview?feedId=1&packageGroup=inedox&packageName=GitLab&packageVersion=1.7.6-RC.2

There are two fields on a GitLab Branches List Variable Source

• From GitHub resource ("ResourceName") should be the name of a Secure Resource, which defines your api url, project name, etc.

• ProjectName is optional, and may override the project name

Based on the message, I think, the resource name isn't filled out?

This is the sort of error you can expect when the application code and database are not the same version.

Had you installed the the same version you had on the old server, it wouldn't be a problem. But fortunately it's an easy fix I think.

Just follow the Database Manual Installation Instructions and run inedosql against your database. Then it'll get updated to the right version.

FYI please review the Backing Up & Restoring as well :)

Hi Markus,

The package metadata records are in the database, but the files are on disk.

The error is thrown when the operating system reports file-not-found when loading a file.

Why is the operating system reporting that, it's hard to say. With Docker, there are two things to consider:

• The package store (typically Admin > Advanced Settings > Root Package Store) refers to files within the container
• The docker run -v command maps a directory outside of the container to one within the container

Perhaps the directory outside of the contaienr doesn't have the file, or is a typo or something? Please let us know what you find...

Hope that helps.
Alana

Hello; at first, what version of ProGet is this?

Whoops, I accidentally forked the topic, so I'm just going to quote it in here instead

@smolkov-anton_1636 said in Unlisted NuGet Packages showing as listed in feed:

@atripp Hello.
I have got the same behaviour too.
With fiddler i see that all versions i unlisted before have property
<d:Listed m:type="Edm.Boolean">false</d:Listed>
, but still apeear in VisualStudio, nuget list and even Rider.
Version - 5.3.0 (Build 126-5.3.0).

I think this one is related:
https://forums.inedo.com/topic/2675/owner-has-unlisted-the-package-on-nuget-org-but-proget-still-shows-it-in-the-list-of-availible-versions/4

@smolkov-anton_1636 said in Unlisted NuGet Packages showing as listed in feed:

@atripp Hello.
I have got the same behaviour too.
With fiddler i see that all versions i unlisted before have property
<d:Listed m:type="Edm.Boolean">false</d:Listed>
, but still apeear in VisualStudio, nuget list and even Rider.
Version - 5.3.0 (Build 126-5.3.0).

I think this one is related:
https://forums.inedo.com/topic/2675/owner-has-unlisted-the-package-on-nuget-org-but-proget-still-shows-it-in-the-list-of-availible-versions/4

@smolkov-anton_1636 said in Unlisted NuGet Packages showing as listed in feed:

The same is for new nuget V3 API.
Steps to reproduce:

1. Unlist all versions of package in proget UI
2. List only one version / push new version

Expected result:
Visual Studio UI shows only one version which was listed

Observed result:
Visual Studio UI shows all the versions

UPDATE in 2023 - see Inedo Products and Prometheus support to learn more about how to integrate our products together

Thanks for the suggestion! It's the first time I heard about Prometheus; do you think this would be easy to do?

We do integrate with a took called Loupe by Gibraltar Software, which does provide great, details, and information about performance.

Hi Simon;

The Linux-based error is an error-logging-an-error sort of problem, so we can just get rid of the underlying error and be OK.

The underlying error in this case is a bug, and it's that Impersonate User is required (even though it shouldn't be). Just put in a user that has ViewPackage privilege to the target feed.

Actually you don't even need an API Key for this endpoint, just view package is enough.

Best,

Alana

Not in particular; .NET does garbage collection, in the background, as needed; so it's not uncommon to see processes "swell" to consume available memory and then "contract" overtime, as memory usage (percentage-wise) gets high.

I'm not aware of how to do it; ProGet does not provide monitoring at this network level. Do you have an ngix proxy in front of it? We've heard that's very important, and it can help deal with some other mono bugs around not closing keep-alive connections quickly. And and also lets you have SSL as well.

This sounds like it's network-traffic related, and likely the server is getting overwhelmed...

See How to Prevent Server Overload in ProGet to learn more.

HI Simon;

The error appears to be occurring while logging the API body; can you try disabling that as see if it helps?

Admin > Api Keys > Edit > Uncheck Log request body , Uncheck Log response body

Is this ProGet for Linux, by chance? There was a related error in an earlier version of ProGet regarding this.

Hello;

I think that error is coming from choco client.

ProGet will respond with a 403: Invalid API Key error response when an invalid API is sent, then terminate the request. A 401 will cause the NuGet client to prompt for credentials.

ni Nik,

There could certainly be a timeout... but if that were the case, it wouldn't be causing an "authentication" error.

You can check errors in ProGet, Admin > Diagnostic Center, perhaps something is logged? If not, then ProGet isn't making the error.

We have seen intermediate servers (proxy, traffic shaping, etc), terminate long-running connections and return a strange/inappropriate error (i.e. something other than Gateway Timeout) to the client. It's really hard to guess. You can install an intermediate tool, like Fiddler or Wireshark, to capture traffic from your workstation. Maybe the raw traffic will give you a better clue.

Hello;

That's a good question; we can't reproduce this, if the file is instantaneous through the browser, we can be totally assured that the problem isn't ProGet finding and sending that .deb file over the web. apt install isn't any more complicated than that.

Can you put a sort of Proxy Server or traffic monitor between the two? Maybe it's network related? Maybe at a TCP/SSL packet level? Maybe apt has a sort of throttle? I guess you could also try to curl the file from whatever server you're doing apt install on to further track it down?

hope thsi helps track it down, please share what you find in case anyone else experiences it.

Alana

HI Marc

These errors are unrelated to license restrictions or your license key.

Check out the errors on Admin > Diagnostic Center, they should be logged.

There must have been some configuration change on your server or network, perhaps a proxy server or new firewall restriction, that is preventing your ProGet server from retrieving the packages.

Alana

Hello; it's the first request for this, but we're going to investigate adding this to ProGet as PG-1702. We'll update as we make progress on investigation.

Thanks! Cool "badge site" (shields.io) that you use for the status image like this

NIce ideas, but a couple concerns; currently we use ApplicationName as the querystring parameter, which then searches for the current active build or that application.

To be able to use $CommitId, it would make it more complicated. It would mean we would need to find a build with a variable named $CommitId and with that value. And at this point, then, we could just allow any number of build variables to be used, which might be nice. $Branch for example.

But a concern is performance. That could be a lot of variables to search, so having an ApplicationName filter would be important (build variables are indexed by application Id); it could still be hundreds of thousands of records rows search even in one application.

We could limit it to active builds, which would reduce searching by many orders of magnitudes and be not a problem.

Hello;

Actually, I think one of those public repositories you are connecting to is a ProGet instance, but it's (incorrectly) configured to warn when ProGet Free connects to it.

We're in touch with the vendor now and are providing them with the proper key to allow it.

Thanks.
Alana

Hello;

When you edit a connector on ProGet Free, that messaging ("ProGet Free is only permitted to have a connector to public repositories...") is informational. It's always displayed when creating or editing a connector, if your license key is free.

If you create a connector to another ProGet Free instance... or if another ProGet Free connects to your instance... then ProGet will detect this, and record a license violation. The License Violations Documentation should give some more information about how this works, but in any case, those violations are "informational only" and do prevent functionality of the software. It just displays the banner to make you aware of the restriction and violation.

What information is being shown under Admin > License Key > License Violations? That should record IP address and descriptions.

How are you changing the license key? When you change the license key (doesn't matter to what... even an invalid string), it will delete all recorded license violations.

Thanks,
Alana

Hmm, for this, then it seems -Repository is the argument?

This sounds like a nice idea, and I think something we could implement easily. Of course, figuring out the new specifications / documentation is always the hard part I think :)

How might you suggest changing the CI Status Badges we have now?

I'm envisioning adding in a querystring parameter for Stage or something? If you could suggest us how to change the docs / API, that would go a long way in helping us get this implemented :D

It looks like you're not specifying the -Source argument? I'm not totally sure, but here's the docs on Publish-Module might help diagnose.

Hi Nik;

There's nothing in ProGet that would yield this behavior, and it's not behavior that others experience, so I think it must be something between ProGet and your workstation. Maybe proxy server, request filtering, etc.?

Just to check, you are using chunked uploads with Docker, right? It's been the default for years, but i guess it can still be disabled. The same intermediate server may be stripping out ProGet's support of chunks? I don't know -- https://github.com/docker/distribution/blob/master/docs/spec/api.md#chunked-upload

We've also had reports of strange errors happening on random blobs from one or two customers. They discovered it was the Request Filtering feature enabled in IIS. The error was different, and it had to do with blocking query strings with :’s in them. But maybe it's this?

hope this helps

Otter uses Inedo.SDK 1.6, where as BuildMaster is on Inedo.SDK 1.7. The major addition to 1.7 is SecureResources and SecureCredentials, which replace ResourceCredentials. However, it's still backwards compatible.

The current (1.7) version of GitLab::Get-Source has two changes:

• Changed Credentials property to From (but keeps Credentials as an alias)
• Added From as the default property, so it will be used as argument right after the operation name

This keeps it backwards compatible.

We will add SDK 1.7 to Otter later this year, but in the mean time you can use the Otter version code and create a ResourceCredential in BuildMaster of the same name.

For this case, you're right -- the Instance ID would be the way to go. On the new BuildMaster server, you can set the Agent.InstanceId field (any string is fine, "bm62" would work) , so this way, both BuildMaster instances won't collide.

We are using our "Customer Success Program" to provide upgrade assistance for BuildMaster 6.2, so the best way to get started on this would be to talk to your account representative.

You can also submit a ticket and put 6.2 UPGRADE in the "How can we help" section, and we'll route that to the right people :)

Indexing the symbol server wouldn't make a difference. I would try clearing your connector cache.

It's very unlikely that this is a regression in 5.3; this is a very common use case, nothing strange about the package, and I can't reproduce it. So it's likely configuration or network related.

To rollback, please follow the restore instructions: https://docs.inedo.com/docs/proget/installation/backing-up

I think this is related to the foreign layer. This is a known issue, it's actually not an "error", but "by design" of Docker.

https://medium.com/@amlys/solution-docker-push-fails-with-skipping-foreign-layer-a119e03bdf0d

I think this will fix it.

Hello;

That "error" message is to be expected; that's what ProGet returns when you visit to /v2 with a web browser. But the error sounds like a sort of SSL/certificate configuration problem.

After searching for "tls: no renegotiation", here is an article I found about that might help: https://www.digicert.com/news/2011-06-03-ssl-renego/

Hi Nik, ProGet does indeed support pushing Windows containers.

What sort of errors are you receiving?

Oh I see; in this case, please remove your credentials from the connector. They're not required for NuGet.org; ProGet does not push to connectors, only download files.

It's a common mistake and we will try to make it clear in the UI.

First, upgrade to BuildMaster 6.1 (see KB#1163 Upgrading to BuildMaster 6.1; this is a relatively low risk, as BuildMaster 6.1 still has all of the legacy features included. There are several "bridge features" to help get you to 6.2

Then, consider a upgrade or migration strategy to BuildMaster 6.2 (see KB#1766 Upgrading to BuildMaster 6.2). Depending on your legacy feature usage, you may want to do a direct upgrade, or you may want to migrate.

And lastly, please keep in mind this note from the docs on BuildMaster v6.2 Migration:

Because this upgrade is more involved than previous upgrades, special support for it has been included with paid licenses. If you are interested in learning more, use the Submit Ticket Form and put 6.2 UPGRADE in the "How can we help" section to let us know when you are going to upgrade. We also recommend you include the Legacy Features Dashboard Report Logs in the body of the ticket.

Hello; I'm not able to reproduce this.

I can successfully download Microsoft.EntityFrameworkCore 3.1.3 without an issue from ProGet 5.3.0-m5.

Can you navigate to the package in your instance, and hit the Download button?

Maybe it was a temporary NuGet outage?

Hello; i don't know how easy it is to implement, but I put I added this for an internal assessment; https://inedo.myjetbrains.com/youtrack/issue/BM-3595

We'll try to evaluate in the coming weeks. Stay tuned!