Posts made by atripp

Hi @colin_0011 , that certainly is an odd issue!

We've never seen it before, but it's coming from the library we're using (libgit2). I don't really know what it means, or what's causing it (is it a number of files in the repository, etc.), but I just have a couple ideas.

1. Restart server
2. Clear the GitWorkspaces (C:\ProgramData\BuildMaster\Temp\Service\GitWorkspaces)
3. Try using git.exe instead of the built-in library

You can do #3 by setting GitExePath parameter on the operation, or configuring a $DefaultGitExePath variable at the server or system level in BuildMaster; this will force all Git source control operations to use the CLI instead of the built-in library

It's possible the bug was already fixed in a newer version of the lbirary. What version of BuildMaster are you using?

Hi @robert_3065 ,

Glad it's working!

Good point about the error message; it's in a kind of general place, so I just replaced that unhelpful base64 decoding message with this (via PG-2069):

string userPassString;
try
{
    userPassString = context.Request.ContentEncoding.GetString(Convert.FromBase64String(authHeader.Substring("Basic ".Length)));
}
catch (FormatException)
{
    throw new HttpException(400, "Invalid Basic credential (expected base64 of username:password)");
}

Not the perfect solution, but better than now!

Cheers,
Alana

Hi @robert_3065,

Based on this, I think the _auth token in your .npmrc file isn't correct. That is the token that's sent to http://OURSERVER/npm/npm_internal/, which is supposed to be in a base64-formatted api:apikey or 'user:password format.

Here's some more information about it:
https://docs.inedo.com/docs/proget-feeds-npm#npm-token-authentication

Npm auth isn't so intuitive unfortunately :/

Alana

@Stephen-Schaff great to hear! And I guess another way to do it would be enabling/disabling the semver restrictions on the feed

Let us know if it keeps happening, and you can find a pattern - we'll see if we can identify what might be the cause of it

@mcascone

existing connection forcibly closed

I'm afraid this is more of the same; there's some sort of network policy that's blocking this connection. It could be the way your laptop is configured, but maybe it's also happening on the HTTPS/SSL level? Anyways, the remote server (not proget.inedo.com, but some intermediate) is disconnecting at some point.

The ProGet-5.3.43.upack would really only be useful for manual installation; but it also might be bad/corrupt/incomplete. You could try unzipping it to see.

Oh.... I probably should have said it before, but we have premade, single-exe offline installers for specific versions of ProGet: https://my.inedo.com/downloads/installers

Here is some more information about them; https://docs.inedo.com/docs/desktophub-offline

These 403 errors are all coming from your proxy server (firewall); unfortunately we/you have no visibility on that.

But it's clear that some requests are allowed, and others aren't. Maybe it doesn't like requests that are downloading a file called .upack. maybe it doesn't like the agent header. Maybe it tries to scan/verify contents with a virus check? It's a total guess

From here, best bet is to check with IT to see if they can inspect the firewall/proxy logs.

@Stephen-Schaff said "Any ideas on how I can get the latest tag to be auto applied?"

the "virtual" tags are recomputed when a tag is added, so if you can try tagging your image 1.0.2 (or something), and then deleting that tag, you should see1, 1.0, and latest all applied to that image

Hi @mcascone,

Our products our built with .NET 4.5.2, which uses the Windows certificate chain.

I suspect that ZScaler is replacing the certificate, and that's causing a trust problem. Maybe you can try installing ZScaler certificate directly in the store, and there are some registry tweaks / hacks that might make it work. Unfortunately I don't have any specifics on what you can try.

You should see same errors if you log-in as service account user, and try to visit the site in IE or Edge. PowerShell would also exhibit the same errors.

In any case, I would search for like "ZSCaler Certificate TLS error Windws" and what not, and hopefully find some specific things to try...

Best,
Alana

Hi @marc-ledent_9164 ,

We're currently investigating this.

FYI: Based on the URL, I think that there is not a valid license... which would make sense if you just set up the instance. No license will trigger an automatic redirect to /administration/licensing to address the license. However, that page is marked is "no license required"... so it shouldn't be redirecting.

Please stay tuned.

@hwittenborn thanks for letting me know -- that was going to be my next suggestion. It's very possible the key had an unexpected combination of properties/permissions and that didn't translate to the v6 internal model

But easy enough to recreate in a case like that :)

@hwittenborn this can sometimes be tricky to get working...

Did this work in ProGet v5? We made a major change to the api keys in v6, so knowing if it's a regression would help track this down

@shaun-d-scott_2657 Inedo products do not use log4j, so it's not an issue for ProGet :)

See more information here: https://blog.inedo.com/log4shell-high-severity-vulnerabilities

@darkbasics_6739 thanks, of course that's not the problem then

We're still investigating this, and it's quite odd why the extension isn't getting transfered. The workaround you're doing is fine to at least evaluate/test, but we'll most certainly get this fixed ASAP

@v-makkenze_6348 thanks for the additional information

ProGet does not cache npm package lists/indexes. It's always generated from the information in the database, so if you pushed it - then it's in the database. You should be able to see it in the ProGet UI right after publishing.

It's very possible that the npm client is doing some sort of caching as well, but isn't doing that cache with authenticated requests. I'm not familiar enough, but that's my guess.

You could use a tool like Fiddler to verify / see what requests npm is actually making.

Hi @mike_4027 ,

I would definitely recommend upgrading; 5.1 is a couple major versions behind.

The issue is most certainly related to the connector; when you disable it, do you get a near-immediate 404? Under Admin > Diagnostic Center, you may see connector errors/warnings as well.

Once you confirm it's the connector, then the next best thing to do would be to monitor the traffic between ProGet and the internet. This involves setting up a Proxy (Fiddler works nicely), and then having ProGet connect to that proxy (Admin > Proxy). You should be able to identify corresponding requests, and maybe we'll see something there!

Let us know what you find,

Alana

Hi @darkbasics_6739 ,

That's really weird, but I can see how that error might happen now. It's been addressed as OT-446, and will be fixed in the next maintenance release.

We're still not sure why the SCripting extension isn't coming over. We're thinking, it might be due to a time out of sorts, since the file is now pretty large. Obviously that should throw a different error.... is there a lot of bandwidth between servers?

Cheers,
Alana

@v-makkenze_6348 it looks like you've enabled caching, which means that ProGet's responses won't be newly generated. Please disable this :)

@sbindra_9387 you can enter the activation code in ProGet, when you click the activate button

Here is the instruction for manual activation:
https://docs.inedo.com/docs/myinedo-activating-a-license-key

Hi @patrick-groess_2616 ,

The /symbols/<feed-name> URL is only for Visual Studio's Symbol Location setting, and is used to download symbols. Do not try to use it with nuget.exe, it will give that error.

You need to use /nuget/<feed-name> to push symbol or nuget.exe packages.

Thanks,
Alana

@entro_4370 we are definitely seeing "package" interest from "data science" teams inside of large organizations, but it seems they're more Python users instead of R users ‍️

@jblaine_9526 sounds good, I've forwarded this to our presales / customer success team internally - so they'll probably reach-out in the coming days about that process to see how they can help

Hi @entro_4370,

I'm afraid not... seems this thread has been a little quiet.

We haven't had many enterprise customers or sales leads requesting it as a feature, and we didn't see a good way to market the feature. It seems very few people search for CRAN-related topics or wanting private repository

Best,
Alana

@lukel_3991 thanks.

So this works totally fine if you're using localhost instead of computername.domain.com then And then, computername.domain.com is a Windows server?

If that's the case, it means the agent (which is connected via PowerShell Remoting) isn't fully loading; basically, the Scripting extension isn't loading, or had an error.

Can you try using a different Temp path? Maybe there's a relation....

Thanks,
Alana

Hi @falk-winkler_2111,

ProGet free edition only supports self-connectors when they connect directly to ProGet. If you bypass the proxy, that should resolve the license violations for you.

To do this, just use http://localhost or http://<PROGET_IP_ADDRESS> in your connector without issue. Please give that a try and let me know if you run into any issues.

Cheers,
Alana

@jblaine_9526 good question; it's not exactly spec'd out, but that would make sense. If SAML is enabled (as one of the directories), then users should be able to bypass SAML behavior. Maybe two Login Buttons, or something.

Since SAML is a ProGet Enterprise feature, it's very possible we could implement this specific requirement much sooner as part of a different program (i.e. "customer success" vs "product roadmapping"), but neither is really my department

I can get you in touch with my colleague who's on that team, but he's not on the forums -- let me know if it's okay to share your email to him (I can see it from my end)

Hi @jblaine_9526 , there are!

I don't have a schedule just yet, but we are planning to simplify the "hybrid" user directory by just making it so that you can set an "active/inactive" flag on each user directory, and then ProGet will run through the active ones in a prioirty order.

Cheers,
Alana

Hi @mcascone,

It looks like this isn't being displayed in ProGet's UI, so we'll fix this via PG-2038

cheers,
Alana

Hello,

This is unfortunately due to bugs in the PowerShellGet & PowerShell Gallery API that aren't feasible to workaround. Basically, the API is reporting different versions than the package file, which makes working with local/cached packages and remote packages painful like this. However, it seems like it's going to be addressed by Microsoft, finally, in PowerShellget v3.

In any case, given your architecture (i.e. "Machines on our network cannot connect to PSGallery direct due to the firewall and are only allowed to retrieve via this one feed."), we recommend using a Package Approval Workflow instead.

• create an 'unapproved-powershell' and approved-powershell feed
• create a connector on 'unapproved-powershell' to PSGallery.org
• Promote packages from unapproved-powershell to approved-powershell

This will totally eliminate the "bad API" problem as well.

Cheers,
Alana

Generally speaking, if yo ucan try to identify the pattern -- like which pages are slow -- that will help.

Some different pages to investigate:

• / is somewhat resource intensive, and involves database calls
• /health uses minimal system resources
• /resources/images/layout/logo.svg is a static image, is unauthenticated, and is cached by the browser

Hi @dac_4595 ,

If ProGet is hosted in IIS, then one thing that might be happening is that Application Pool shuts down if it's not accessed in a set amount of time. That 5-10 seconds might be the initial start-up time. You can control the timeouts in IIS, and even set it to be AlwaysOn.

Otherwise, there's nothing in the browser's cache that would cause this. If anything, clearing the cache would cause things to go slower, as pages need to re-load.

Cheers,
Alana

@forcenet_4316 great, sounds good! Actually we didn't end up shipping 6.0.0 yet (we will soon), so I just changed PG-2011 to target 5.3.40, which is scheduled for release on Friday. This way it will be in both.

Thanks @drew-stinnett_4680 !

I've updated the documentation with a link to this discussion.

@forcenet_4316 thanks to the data you sent, I was finally able to figure this out!

The problem is with antlr4-runtime-4.5.2-1-sources.jar. When ProGet replicates or promotes this package (logic is the same), the artifact's fileType is assumed to be .jar instead of -sources.jar; this is what's causing the PK constraint. This seems to only impact a very small number of artifacts, since I think I mostly saw .sources.jar in other cases (which would work).

I've fixed this via PG-2011, which is scheduled for 6.0.1 (shipping later this week).

Are you planning to upgrade to v6 soon? If not, I should be able to backport the fix to v5.3.

It seems that PowerShell client doesn't provide much details about errors, so glad you could figure out what the issue was for powershellgallery.com. That message probably could mean a lot of things, and is probably unrelated to TLS/SSL..

So the first thing that's jumping out to me is this:

WARNING: Unable to resolve package source 'http://proget.domain.org/nuget/ps'

There is no https connection, so there'd be no TLS/SSL issues. But assuming you may have changed the url when posting this... here is a registry key you can use to force that setting (it makes that powershell command unnecessary)

https://inedo.com/support/kb/1161/tls-v12-configuration-and-connection-errors

If you're on HTTPS the other thing to look at would be certificates.

Otherwise, you may need to use something like Fiddler to see the actual request/responses that PowerShell client is issuing/reciveing.

hi @paul_6112 - just curiosu if this continues to happen? We had another report about this, but are still struggling to find out why / and a resolution. We're going to try to take another stab at figuring this out again.

Hi @jan_ko ,

Thanks for sharing this; the .nuspec file looks okay to me, so it doesn't seem like a problem with the package.

After building the agent pushed these nupkg's to the Azure DevOps Artifacts. This feed is connected to a ProGet connector.

Well, I'm thinking the issue is in the Azure DevOps Artifacts API. We found many bugs in their feeds already (i.e. not implementing the API as specified). It happens to work in Visual Studio, or Visual Studio already worked around the bug.

We can spot it very easily with a debugger; if you can share to use a feed url and credentials (I think it's just n access token?), then we can connect to the feed and see what's causing that error. You can send us the details via the ticket, so then it's not public.

Cheers,
Alana

@forcenet_4316 very sorry on the delayed response -- didn't notice that you had sent something to the box (it gets filled with spam very quickly) I've reopened this issue, and we will investigate ASAP

@mcascone unfortunately this is where it can get complex; there's nothing you can change in ProGet, so it's going to be either a server or proxy change

The most likely case is that the server doesn't trust the certificate presented by chocolatey.org; it's also very possible that your proxy server is stripping/replacing the certificate, and your server doesn't trust the proxy server's certificate.

It could also be a cipher issue. One user reported a very strange custom Windows setting caused this error; "a cipher not present on the server, due to a custom cipher list policy declared in the registry key (HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Cryptography\Configuration\SSL\00010002).

Since this is happening in the service, you should be able to log-in to server using the Service Account that ProGet is running under, and use the web browser to visit that URL. That will make it easier for your IT team to fix the certificate issues, in theory.

Thanks @philippe-camelio_3885 - with this, we can clearly see what the issue is; basically it's a UI bug on this page where we must have forgot to save the data as a UTC time. We'll get this fixed ASAP - stay tuned.

Hello; sorry on the slow response, but I'm still trying to reproduce this. I even downloaded antlr4-runtime and can't seem to do it.

[1] Are you able to provide us a copy of the MavenArtifactFiles in your database? Basically just SELECT * FROM MavenArtifactFiles, and send results to support at inedo dot com, with [QA-674] in the subject? That will let us spot some things right away. I'm struggling with seeing how this error is even possible, given the way that stored procedure works.

[2] What version of ProGet are you using? When did you start using this maven feed.

[3] Have you used replication for the feed?

Thanks,
Alana

@mcascone do you happen to remember where you found that link? We are trying to be conservative about adding a ton of redirect rules...

We are now running automated scans, so HOPEFULLY it's picking up bad links within the docs.

Hi @forcenet_4316

While the message isn't great, it's saying that the artifact (antlr4-runtime.jar-v4.5.2-1) is already in the target feed.

Can you confirm if that's the case? We should improve the message of course, but i want to check it

Thanks,
Alana

Hi @Stephen-Schaff ,

Yes, this can be a little bothersome. Actually this is something that we're considering for v6, to mostly replace the "impersonation" feature:

• Allow on Feeds:
  • [feed1, feed2, «group1»]
• Feed Permission:
  • View/Download
  • Publish/Push
  • Delete/Overwrite

The "username" would still be there, but mostly for "personal api keys".

Thanks,
Alana

Hello;

I'm not all that familiar with Ruby Gems, but I'll try to help. At first, I think the problem is that you're using host instead of source.

gem push <gem file> --source http://<redacted>/rubygems/RubyGem

Hope that does the trick :)

FYI; we recently updated our RubyGems Documentation to help others get setup.

Hello;

Thanks for all the detailed information, we'll definitely investigate what could be causing a segfault. This definitely shouldn't be the case...

is anything logged in Admin > Diagnostic Center?

Thanks.
Alana

Thanks @antony-booth_1029 !

This should get fixed via BM-3740 in the next maintenance release of BuildMaster

@grant-sparks_1282 I'm surprised there's no index, but I guess that's a property popular repository, so we can make ProGet not error in this case.

i logged PG-2007 to handle this :)

@nkr said in ProGet shows seemingly random versions as "latest" when using a NuGet connector:

quite an old build of the NuGet Gallery.

Oooh that might cause a lot of headaches/problems

Older versions of the NuGet Gallery have some notoriously strange/quirky behaviors -- so much so that we had a special feed type just handle them ("Quirks Feeds"). We finally removed that feed type last year (ProGet 5.3) after the bugs were mostly fixed.

The "missing dependency info" sounds very familiar, and the same thing happened with packages from nuget.org. It was such a long time ago, and the nuget team fixed it with new code and a data update.

Anyway.. I would recommend just migrating your packages using a bulk import.

Hi @grant-sparks_1282

Maven Connectors work by downloading a file called /.index/nexus-maven-repository-index.gz from the repository. It's weird, but I guess Google's repository doesn't have such an index?

https://dl.google.com/dl/android/maven2/.index/nexus-maven-repository-index.gz

I didn't know that repositories didn't have those... but you can confirm this is indeed the error under Admin > Scheduled Jobs > FullMavenConnectorIndex > History --- Can you confirm, and see it?

I guess it's not a problem, if you can still download artifacts. But without an index, you can't search then...

Thanks,
Alana

Hi @brett-polivka ,

Hmm.. I tried to look at a way we can get more diagnostic info, but I don't think we can find much more. It sounds like is an authentication problem with your PAT?

Did this happen after an upgrade of ProGet? We haven't made any changes to connectors in a while, but if you can tell the from->to versions, we can see if it might be related.

Otherwise, I'm thinking it's on the end of github, and maybe a relation to the PAT? It's possible your token expired, doesn't have right permission, etc. They may have also change the API too.

Thanks,
Alana