Posts made by atripp

It's definitely possible; we've seen some situations in Cloud Storage where a package's casing changes between versions, and this is the result. But it only impacted replication to our knowledge.

The cloud storage package stores were modified to fix that, but I suppose it could happen on Linux-based as well, but this is the first report to my knowledge.

Can you confirm this is happening? It's a very risky change (unlike the cloud storage, which is easy to rollback becuase it's in an extension) that fixes a very small edge case, so we need to be extremely careful in fixing it. It's not clear what's being impacted here, aside from the package verification job...

Hi Philipp;

Glad you were able to find the feature of Repackaging, it's quite helpful!

Now, when the WPF Application is going to be tested, we'd like to generate a whole tree of all those dependencies labeled as "-prerelease".
And after testing we'd like to move the whole tree into the production state where all packages do not have any prelease tag at all.

This sounds good to me! I think this process makes a lot of sense to do.

I'm not sure if you're asking about the ability to tell ProGet "repackage the WPFApp package and all it's dependencies", using one API call or something? In this case it's not possible.

The reason is, it's not feasible for ProGet to handle the dependency resolution. Actually it's quite complicated (especially with version ranges possible), and NuGet's algorithm is among the most complex in the industry. Because of this, it's not really possible to do dependency resolution from ProGet, since you'd need to specifying additional context including what framework version you're targeting and what version of Visual Studio you're using, etc.

But anyways, the idea you have to promote all packages in one stage sounds nice to me!

What you're describing is a "drop folder", which ProGet has for some feed types -- they're not supported for asset directories, however.

Do note that there is an Import Directory Endpoint in the Asset Directory API where you can publish a ZIP file that gets automatically extracted.

In this case, you can just install on top of the old installation -- the database or package store won't be overwritten.

But do note it might impact the IIS/application pool customizations you made.

Hello; you might be able to use an Asset Directory for that, but note that they don't support connectors at this time.

Hello,

Please see the guide over here - https://docs.inedo.com/docs/proget/feeds/nuget/symbol-and-source-server

If you wish to use a separate symbols package (snupkg), then you will need to create a separate feed, and push the symbols package to that feed.

@scroak_6473 thanks, I just updated that too, hopefully this will help :)

Thanks for the report , very simple code typo and now it'll be fixed in BM-3611 in the next maintence release

Hello, what version did you upgrade from?

Can you also check the version of the Windows extension you had loaded?

Hello;

There are a few things that could cause re-activation of ProGet, or any of our products:

• The software was moved to a different system
• Changing or adding a license key
• The software was installed on virtual machine that changes CPU IDs or network interfaces when it restarts (to prevent this, configure the network adapter of the virtual machine hosting the software to be a static value)
• A new network interface was added
• Upgrading to a minor or major version of the software

The License Key Activation Documentation explains in more detail as well.

Hope that helps,

Alana

Thanks!! I fixed it.

Hello; due to limitations of the DockerHub, we no longer distribute the software on their registry. Instead you can get it from our own instance of ProGet :)

However it's available here: proget.inedo.com/productimages/inedo/proget:<version>

https://docs.inedo.com/docs/proget/installation/installation-guide/linux-docker

If you can suggest where to better notificy users of this change, please do :)

Hello; thank you pointing this out, this is a documentation bug, and that page wasn't updated. But I just fixed it now.

Configuration files now use the OtterScript/ExecutionEngine to handle replacements, so please use the grave apostrophe (`) to escape, so in the case, it's \$myvar `

  <variable name="fileNamePrefix" value="`${var:logRoot}/`${shortdate}" />  

Cheers!

Hello, great question.

.indeox deployment is no longer supported, so I updated the documentation as follows

Direct Deployment {#zip-file}

An extension can be directly deployed to an Inedo product's extension root as a simple universal package.

To do for an extension named MyExample, first create a manifest file called upack.json with the following contents:

{
  "name": "MyExample",
  "version": "1.0.1"
}

Then, create a zip file called MyExample.zip with the compiled output in a package folder, and the upack.json at the root, like this:

  /package/
     /MyExample.dll
     /SomeLibrary.dll
  
  /upack.json

Rename the the zip file to MyExample.upack, and copy the .upack file into the Product extensions directory. By default, this will usually be in C:\ProgramData\«product-name»\Extensions, but you can verify the exact location by going to the Admin->All Settings page and looking for the ExtensionsPath value.

Finally, restart the product services (and application pool if hosting in IIS).

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...

The ProGet Free to ProGet Enterprise blog article talks more about this, but ultimately load-balancing is a solution that will prevent this peak usage / overwhelming problem.

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