Thanks @dongjie789_8066; of course we can definitely consider creating a different API, but you are first non-Edge user to ask about it :)
It's best to handle that through your My Inedo account with your work email, so we can work with your team/company about it
Hi @PhilipWhite ,
Can you clarify what you mean by empty?
Like, if you were to do Log-Information Hello $ApplicationName!;, it would just log Hello!? Or are you seeing it somewhere else?
There is an $ApplicationName "variable function" that will return the name of the current application in context. There is almost always an application in context, unless you're doing something like a system-level scheduled job or something.
However, variable functions have a low precedence, so if you were to do something like set $ApplicationName = whatever;, it would create a runtime variable called ApplicationName, and then $ApplicationName would resolve to that.
You can explicitly invoke a function by doing $ApplicationName(). So, Log-Information Hello $ApplicationName()!; should always work.
As for nothing showing up on that application page.. that's weird 
--- but something to dig through separately for sure.
Cheers,
Alana
Hi @PhilipWhite ,
You're correct, this is a regression in the validation code...
if (!value.All(c => (char.IsLetterOrDigit(c) && char.IsLower(c)) || c == '.' || c == '_' || c == '-' || c == '/'))
return new ValidationResults(false, $"Docker Repository names may only contain lowercase letters, digits, periods, underscores, slashes, or dashes.");
I guess we recently added char.IsLower because UpperCase characters caused all sorts of problems.... easy fix, and easy work around.
blah in the Repository name field, Click SaveWe'll get this fixed for teh next maintenance release via BM-3932
Cheers,
Alana
Added to our PRoGet 2024 roadmap to ivnestigate/explore - it might be easier this time!
ProGet 2023 introduced some big changes to replication, and since it's something that's infrequently configured, we did not create an API for it yet. We have some undocumented/special APIs that are used by ProGet Edge Edition, which relies heavily on replication configuration... but we want to work w/ users on this.
I couldn't find a ProGet Enterprise license associated with your email address, but if you can submit a ticket with your license key, I can make sure that someone reaches out to discuss this with you.
Hi @PhilipWhite
The Docker:: operations are intended to work with a Docker Repository Connection that you've configured for the application.
The Repository parameter refers to the name under Application > Settings > Connections, and the error message is saying you don't have a connection named mydockerserver/foo configured.
When it comes to Docker, our general guidance is to use the namespace part of a repository name, so instead of proget.corp.local/myDockerFeed/corp/myapp you would juse use corp/myapp or myapp.
Hope that helps,
Alana
Thanks for the bug report; this was a regression in the generated OtterScript, where it specified the wrong parameter name. Anyway, fix it via BM-3929, which will ship in the next maintenance release. Of course let us know if you'dl ike a pre-release version w/ that change, and I'm happy to ship it :)
Thanks,
Alana
Can you share the relevant OtterScript and execution log portion?
Behind the scenes, ProGet::Scan will use the package-lock.json file of your project. It's based on the pgscan tool (https://github.com/Inedo/pgscan) as an FYI.
Cheers,
Alana
Hi @scott-wright_8356 ,
Based on your other post, your server is under very heavy load, and another symptom is that clearing those logs can timeout. I believe this was improved in ProGet 2023, but deleting can be relatively slow when a ton of log messages have accumulated.
Just run TRUNCATE LogMessages against the database.
Best,
Alana
Hi @scott-wright_8356 ,
This is a common symptom of "server overload", and based on the usage pattern this is not surprising. It's not a question of hardware, but the fact that the NuGet client is effectively doing a "Denial of Service" on your ProGet server by issuing hundreds of simultaneous requests.
Keep in mind that every one of these requests must be forwarded to nuget.org (and perhaps other connectors?), so the traffic/waits multiply very quickly - and the symptom are timeouts like this on unrelated resources (like SQL Server). The FindPackagesById() query is notoriously slow on nuget.org, so there is a lot of waiting.
Setting up a ProGet Server Cluster that uses load balancing will be the best solution to handle these huge spikes in traffic There are a few other ways to squeeze more performance out of an instance.
FindPAckagesById()See How to Prevent Server Overload in ProGet to learn more.
Hope that helps,
Alana
This is the result of a long-standing WONTFIX bug within PowerShell Remoting. Considering that DSC is effectively dead, we don't see any point in try to work-around the bug. You can see more details/discussion here (Otter role issue after upgrading to 22.0.2).
In general, we advise all users to move away from PowerShell DSC. It was basically killed by Microsoft, and its corpse was resurrected to be used in Azure Automanage. From the docs:
DSC 2.0 is supported for use with Azure Automanage's machine configuration feature. Other scenarios, such as directly calling DSC Resources with Invoke-DscResource, may be functional but aren't the primary intended use of this version.
Since last year, there was a quasi-community effort started to bring back DSC as "DSC 3.0", but it's in early alpha and has no official support. Given the pace of similar PowerShell developments (like the v3 of PowerShell Gallery), I would expect 3-5 years for a somewhat stable version.
Best,
Alana
Both are working fine in our test lab.
I only looked at DSC, but according to the CollectDscModulesJob (which is what is doing the collection/parsing for the CollectDscModulesOperation), it's calling Get-DscResource and extracting ModuleName and Version.
I can't imagine why Version would be null/empty, but that seems to be the case??
Thanks,
Alana
Thanks for the report and work-around @Jon , we'll investigate this as part of the Otter 2024 roadmap.
@Jon I answered this in another thread, but
The error for "/api/releases" should be logged under Admin > Diagnostic Center; it's likely related to an unexpected/missing data in the application; you can narrow it down by specifying application id or something
If you can find what the error is, we can work to id/fix it!
Hi @Jon,
The Release and Build API Documentation is outdated and needs a lot of work. We are aware of the low-quality documentation, and this is on our list to rewrite.
To address your issues.
[1] The error for "/api/releases" should be logged under Admin > Diagnostic Center; it's likely related to an unexpected/missing data in the application; you can narrow it down by specifying application id or something
[2] You'll need to specify application/json as the content type when posting JSON documents; otherwise the request will be read as application/x-www-form-urlencoded values or querystring parameters.
[3] The pipeline name is incorrect, it should simply be Release (for an application pipeline) or global::MyGlobalPipeline for global pipelines.
Thanks,
Alana
Hi @Jon ,
Thanks for the note; this behavior is intended, and was decided after many years of supporting products in the field. The service is configured to automatically restart after a crash, and a database error will crash the service.
This is easiest to manage, since most database connection errors (even permissions-based ones) are are temporary in nature, so this behavior means the problem will be automatically resolved.
Best,
Alana
Hi @Jon ,
Unfortunately it's "not that simple", and this will require a bit of troubleshooting to figure out what the issue is, precisely. There are a lot of areas where this could occur, and we can't add a generalized "job killer" until we understand what the issue is.
You'll have to dig in behind the scenes (Admin > Executions) and identify exactly where things are freezing. The last log message will indicate that. Try to find as many examples as possible.
Keep in mind that Otter is not not really "connected" to a server, and a server does not (and cannot) "call home". Instead, Operations (i.e. OtterScript) opens a connection to a server, sends a command, then disconnects. All network errors we've ever seen in this process will yield a crash.
However, unless explicitly specified, a command will not timeout. So this means if you run a PowerShell script that basically just says "sleep indefinitely", then the Execution will never complete. Obviously no one would write that script, but some PowerShell scripts have a consequence of that. No built in Operation should ever cause that to happen, which is why we need to know precisely where this is happening.
Best,
Alana
The configuration looks okay, and is basically what we have documented. So I think it ought to work...
From here, I would start by monitoring the HTTP traffic between Maven and ProGet. You can use a tool like Fiddler Classic on Windows or Wireshark. What you should see is:
WWW-Authenticate: Basic headerAuthorization: Basic XXXXXXXThe XXXXX will be Base64 encoded api:your-api-key. If you don't see that, then something else is wrong. I would post it and maybe we can help.
You can also try downloading maven artifacts from an "Incognito" window. Your browser should also prompt you for a username/password, and then you can enter api and your api key.
Thanks,
Alana
Hi @PhilipWhite ,
Thanks for confirming that; after researching this, it seems that mounting /tmp with noexec is "old-school security measure" to prevent issues that have since been fixed, but is not an uncommon practice today. So we will make a code change to have Use Agent Temp folder instead of the system temporary directory for extension files extraction - this will be implemented via BM-3927 , hopefully in the next maintenance release (Tomorrow).
As for the Centos7 server, the underlying error message would be buried in the sshd logs. My guess is something with noexec, but who knows?
The Linux integration in BuildMaster v4 and BuildMaster 2022+ are a bit different:
So this added complexity seems to be causing some issues, but we'll figure it out!
FYI: eventually we intend to publish a Linux-version of the Inedo Agent, primarily to make it easier to configure than SSH.
Best,
Alana
Hi @phwhite_9282 ,
We're a bit baffled by this one, and think the issue is related to "some kind of configuration" on your RHEL server and the /tmp folder. Likely, security related. For testing purposes, can you make the BuildMaster user account (i.e. what you SSH in as) a root user?
Here's some more context... to help troubleshoot this further.
The first error was clearly related to some "strange" SSHD rejection (problem initializing a process), but changing the agent's temp path fixed it. We don't know what that error is specifically... but behind the scenes, BuildMaster starts by transferring executable files to the Agent's Temp directory (which clearly succeeded) and then executing those files (which failed).
The second error is an error loading a file from disk ('/tmp/Inedo/ExtensionCache/fafcab6c8d528766939b379f9e8f3dc9ba44db15/package/runtimes/linux-x64/native/libgit2-a2bde63.so). This usually means the file isn't on disk -- do you see that file on disk? The agent would have unpacked it there.
Our working theory is that some kind of security configuration is quarantining things that are written to /tmp and preventing execution. Which is unusual, because that's a common place where basically everything uses as a temp space.
Thanks,
Alana
Hi @phwhite_9282,
This is a low-level error, and could mean a number of different things on the SSH side.
Can you let us know:
Thanks,
Alana
Hi @hanna-doeberl_5189,
You should be able the operating system on your ProGet server without impacting the installed applications (like ProGet); we're not aware of any issues/problems arising with ProGet specifically.
As for upgrading ProGet itself, check out the docs on that:
https://docs.inedo.com/docs/proget-upgrade-guide
Cheers,
Alana
Hi @richard-allen_8963 ,
I'm afraid I'm really not sure how different versions the NuGet client tools behave in different scenarios... just really how ProGet works in implementing the Vulnerabilities information on the NuGet API.
This API is used by Visual Studio, and in our testing, they show up as we expected -- so if you're not seeing the desired behavior, that's where you'd want to look. Using something like Fiddler, you can see what's being called.
I do know there is an older, NuGet.org-only API that the tools may be calling. But we only implement the one I mentioned above.
Best,
Alana
Hi @Justinvolved ,
That looks like an error coming from PowerShell; you can see what Powershell commands are being emitted executed, so I'm guessing it's some kind of issue with the source?
I'd try to start there, and see if you figure out the underlyinig Powershell error. Here is the code that's generating the scrpt
Cheers,
Alana
Hi @richard-allen_8963 ,
In ProGet Free Edition, if vulnerabilities are enabled on the feed, a package will a vulnerability will always appear as critical, and the advisory URL will direct you to /vulnerable-nuget-package-info on your instance of ProGet.
In paid editions, you will get more relevant information and you can assess these vulnerabilities to control them from being displayed as critical.
I'm not entirely sure how to suggest to debug, but in the API, you should see advisoryUrl
listed on thePackageDetails` resource, along with deprecation as well, so I would try looking at the API for a sample package, and making sure you can see both deprecation and advisory info
Thanks,
Alana
Hi @caterina ,
Sadly I wasn't able to fix w/ that last release (I didn't have a test case to try, so kind of a blind fix), and was going to give it proper shot this weekend,.... but it looks like you guys submitted a pull request? Did that releaae solve the issue?
https://github.com/Inedo/pgscan/pull/46
Thanks so much,
Alana
Hi @caterina ,
We recommend migrating to the standard format (as they call it now) , which is .snupkg.
The .symbols.nupkg format is considered legacy, and the "embedded" format that we used to recommend was effectively a varation of the old format.
Cheers,
Alana
Hhi @caterina ,
What does the configuration of your Sybmol Server look like, on the Manage Feed page?
Thanks,
Alana
Hi @richard-allen_8963 ,
ProGet 2023 will return vulnerabilities when using the audit command and Visual Studio. Here is more information on our general approach:
https://blog.inedo.com/nuget/vulnerabilities/
If you're not seeing them, make sure you're using the NuGet v3 API endpoint. That's the one that ends in index.json -- the v2 API does not support vulnerabilities.
There is a restriction on vulnerability inforamtion in the Free Version, but they are returned in the API.
Thanks,
Alana
We didn't change the operation that I can tell, but I researched/tested it using the CmdLets that Otter invokes: Register-PSRepository and Unregister-PSRepository .
Here's what I discovered:
Unregister-PSRepository -Name PSGallery is fineRegister-PSRepository -Name PSGallery -Source ... is not allowed at allRegister-PSRepository -Default -Source ... is also not allowedRegister-PSRepository -Default is apparently the only allowed optionYou can see the Unregister/Register approach that we use in PsRepositoryConfiguration.cs#L187. So that's why you get this error....
How about doing this as a work-around?
{
Ensure-PsRepository
(
Exists: false,
Name: PSGallery
);
PSExec Register-PSRepository -Default;
}
That should have the same effect of restoring to the default values...
Thanks,
Alana
Cheers,
Alana
I just tried this, and noticed that the connector is timing out. This is the query that ProGet makes when you type that in, and it takes 13-15 seconds when I click the link:
https://www.powershellgallery.com/api/v2/Search()?$top=25&$skip=0&searchTerm='VMWARE.PowerCLI'&targetFramework=''&includePrerelease=true&semVerLevel=2.0.0
That's longer than the default (10s) time out, so I guess this result is expected. If you increase the timeot to 20 seconds, i guess it should work.
Cheers,
Alana
Thanks @philippe-camelio_3885; can you walk me through the scenario of what you're doing? The "Error" status doesn't seem quite right....
Otherwise, the "status" on a server can be a complicated thing in Otter sometimes, since it represents a few things.
Under Admin > Service, you can manually trigger some of the Task Runners that are responsible for changing status. Can you identify which one needs to be run in order to get Otter to report the desired status.
Once we understand what you're doing, and what task isn't being run by the service on time, we can try to fix
We're aware of this issue, and it's related to some bugs/quirks with the search results from the PowerShell Gallery API (v2). It's not really feasible to work-around, and unfortunately Microsoft will not fix the issue because it should be fixed in PowerShell Gallery API (v3).... which is due any year now. Its ~3 years late.
The results are suboptimal in both ProGet 5.3 and ProGet 2023, but ProGet 2023 is worse. This has to due with some performance optimizations we made with not paging as many results.
Fortunately this only impacts the search api, which is mostly limited to the ProGet UI. As long as you know the exact package name, you can naviage and install it fine.
Cheers,
Alana
Hi @philippe-camelio_3885 , what was the previous version? Otter 2022?
Hi @caterina ,
We just published pgscan 1.5.10, and I believe that it will solve this issue. Can you give it a shot?
Thanks,
Alana
It's been a while, but I believe we investigated this a little while back, but discovered it wasn't possible/feasible to do with the API we were using. That would have been in the .NET4+ days, not .NET6+, so it may have changed.
I don't remember
Here's the code we use to bind the Otter configuration to Microsoft.Web.Administration libraries: https://github.com/Inedo/inedox-windows/blob/master/Windows/InedoExtension/Configurations/IIS/IisSiteConfiguration.cs
It might be trivial now, and we'd be happy to accept a pull request if you're able to figure/try it out!
Cheers,
Alana
Hi @Justinvolved ,
Application Pools seem to run under a special user account (not NETWORK SERVICE, but like IIS\AppPoolName), so you need to give that user access.
In any case, make sure to restart the app pool/IIS, otherwise the permissions may not cascade? It can be a bit tricky unfortunately.
Cheers,
Alana
Hi @caterina ,
Thanks for sending this; looking over the SBOM, it looks like the scope is incorrectly encoded in the package.
<purl>pkg:npm/%40ampproject/remapping@2.2.1</purl><purl>pkg:npm/@ampproject/remapping@2.2.1</purl>Are you using pgscan to generate this? I think so, and in that case it seems to be a bug. We may wish to have ProGet also accept it, but I'm not sure.
FYI, here is a minimal SBOM that demonstrates the issue:
<?xml version="1.0" encoding="utf-8"?>
<bom serialNumber="urn:uuid:6109c18a7f7c403b9f9f11ff73c8fe34" version="1" xmlns="http://cyclonedx.org/schema/bom/1.2">
<metadata>
<timestamp>2024-01-17T08:23:58.4621303Z</timestamp>
<component type="application">
<name>Test</name>
<version>1.0.0</version>
</component>
</metadata>
<components>
<component type="library">
<name>@ampproject/remapping</name>
<version>2.2.1</version>
<purl>pkg:npm/@ampproject/remapping@2.2.1</purl>
</component>
</components>
</bom>
When npm/@ is replaced with npm/%40, the file is imported as expected.
Cheers,
Alana
In your command, you're specifying D:\ProGet as the target directory. The configuration files are written to %PROGRAMDATA%\Inedo\SharedConfig\.
Cheers,
Alana
Hi @andy222 ,
Based on the error/stack trace, it looks like you're getting a HTML page as a response instead of the expected JSON. I don't know what url is being queried, but it's clearly incorrect.
Looking at the OtterSCript, you shouldn't be specifying an ApiKey and EndpointUrl when also specifying a Source, since BuildMaster will automatically discover those from the source. I suspect this is where the issue is.
Try this instead:
ProGet::Download-Asset temp/TestEnvVariables_Win.zip
(
Source: directory::Assets,
To: C:\temp
);Hi @mike_5084 ,
Thanks for sharing this! Few things I wanted to share...
Retention Rules are definitely the way to do house keeping; it's much simpler and is something that just works in the background
We're definitely aware of this particular deletion issue, but it's tricky to reproduce (even using your scenario)... that said, we do have a patch for FeedPackageVersions_DeletePackageVersion available, but we're waiting for some other users to test it before releasing in the mainline. It sounds like you already deleted the packages, so it's not a big impact.
We introduced the Common Packages in ProGet 2023, and we will likely introduce a "Rate limit" of some kind in ProGet 2024 Free edition, since retention policies are one of the features that help "sell" ProGet to managers 
Cheers,
Adam
Thanks @caterina , confirming receipt! We will review this in the next week or so, please stay tuned.
@philippe-camelio_3885 that's a lot of namespaces! Sure, great idea, I logged it to BM-3922
I'm not sure if we can sort repository names however; those come in a "paged" UI, but we might :) At least you can search for those by typing.
Hi @andy222 ,
The workflow you describe -- TeamCity (CI) + BuildMaster (CD) -- is definitely supported.
However, artifacts are "pulled" (imported) from a TeamCity build. There are two patterns:
That being said, you can also create a TeamCity (CI) + ProGet (Package Repository) + BuildMaster (CD) workflow. This scenario is the closest to the "Octopus Deploy" workflow (i.e. TeamCity pushes a NuGet package), and a number of users will use this as a kind of "bridge" to migrate away from Octopus.
Cheers,
Alana
Hi @caterina ,
Can you share an SBOM that I can use to reproduce this? Doesn't need to be the whole one, just one that contains an example of a scoped package that you're not seeing.
Cheers,
Alana
@philippe-camelio_3885 thanks for the bug report!
we'll get fixed via OT-506 in an upcoming maintenance release :)
Hi @sbaeurle ,
I'm glad to issue is mostly resolved now!
In general, ProGet issues 500 errors when there are problems like database connections, overload, etc. We have not seen a 401 issued in a case like that. That's not to say it didn't happen to you, but that's not how ProGet will behave.
401/403 are only issued on API endpoints calls; if there's an error during authentication (like if you added an intentional bug to a procedure that checks the api key validity), then a 500 should be issued.
Cheers,
Alana
Hi @Justinvolved ,
This is a symptom that the web application lacks permission to control the service. There is an ancient tool called subinacl.exe that can fix this. We also have an ancient article based on that tool, but don't have anything updated:
https://inedo.com/support/kb/1090/granting-service-control-privileges
I did a quick search and found this content piece that also explains it
https://www.winhelponline.com/blog/view-edit-service-permissions-windows/?expand_article=1
Let us know what you find, we'd love to get that article updated :)
Cheers,
Alana
Hi @manager_7279 ,
This is likely because of a lack of database permissions; you'll need to grant permissions to the BuildMaster database in the local SQL Server database. We don't have a step-by-step guide for that, but it involves giving that user BuildMasterUser_Role permission using something like SQL Server Management Studio.
As an alternative, you can install the Inedo agent on the BuildMaster server (defaults to Local System) and then connect to that instead of localhost.
Cheers,
Alana
Hi @manager_7279 ,
Stopping/Starting IIS application pools requires administrative access. Looking at your stack trace, it seems like you're trying to stop an application pool on localhost (i.e. the server that BuildMaster is running on)?
That's not a common requirement; instead you'd stop/start an application on a different server.
In any case, the BuildMaster service runs under NETWORK SERVICE, and will not have permission to modify IIS application pools on localhost. So if you plan to do this (i.e. stop/start IIS on localhost), then you will need to make the BuildMaster server run under LOCAL SYSTEM instead of NETWORK SERVICE.
This will likely also require you to update database permissions, to allow LOCAL SYSTEM to connect to the database as well.
Alana