Try stopping the service before running the installer, then it should work.

Got it! Then this would likely fall inline with an upcoming major feature, and the communication between Otter servers ("main" and "secondary" as you describe) would be done using API/HTTPS/Web requests, in a direction of ("Publisher" -> "Listener").

Basically, you would create a Git-based raft in both instances of Otter, and have them both point to the same Git repository.

The biggest gotcha would be that both instances can potentially update the raft, but as long as you're aware of that it wouldn't be a problem.

I see; in this cases, go to Advanced Settings, and change the base url property.

You can edit the connection string using Inedo Hub; it should be listed right under the Configuration tab. Note you will need to stop/start the service and web app afterwards.

Might be best to stop both beforehand, however, so you don't have two potentially active databases.

How are you performing a feed migration? Is this being done by feed replication?

If so, the biggest consideration will be data. If you have terabytes of data to transfer, it's going to take a long time and probably kill your bandwidth. You could always use the drop-path feature, and then import from a physical disk you move/send?

Not any useful ETAs, but it's something we definitely want to accomplish this year (this has been a very long-standing request), just a matter of prioritizing which part of the year it gets done in, etc.

I'm not familiar with SCCM so well, but I think I understand. Let me try to reexplain though just to make sure.

• Otter should be able to routinely "publish" server configuration (i.e. the key/value pairs) that it collected to another instance of Otter
• Otter should be able to "listen" for server configuration that is sent from another instance of Otter, and then apply (overwrite) that configuration to any matching servers

Am I understanding correctly?

Definitely on our roadmap, and we'd like to Open-source it and make it a community item.

The hardest part, to be honest, is determining the input/outputs of these CmdLets. If you'd be willing to help us think these out, we'd love your help in designing it and making this a reality :)

Definitely! This was one of the usecases of rafts :)

Currently, Git repositories are the way to go, but we plan to support Universal-package Based Rafts as well.

Yes, ProGet supports this.

However, you will need a paid version of Chocolatey in order to do that
https://chocolatey.org/faq#i-would-like-to-be-able-to-offer-my-non-admin-desktop-users-an-option-for-self-service-type-of-installations

I spoke with the engineering team briefly on the issue, and here's some quick feedback.

If we support "double-hop" authentication in the Inedo Agent, we would implement that functionality ourselves, using our own secure channels to ensure end-to-end security. Fortunately that's relatively easy to do, since we control both ends of the pipe.

This is not the case in PowerShell, and we cannot bypass PowerShell's security measures. PowerShell Remoting (and Kerberos) already has the concept of "double hob" authentication. It's very complicated, so we'd encourage you to read this article to understand the challenges with it.

So, long story short, if we implement a relay service ("double-hop authentication") in the Inedo agent, we may be able to use the same UI to control PowerShell, but there is a significant amount of configuration and control required to get it to work.

As far as the concept of "collectors", we will be researching a major new feature to Otter that simplifies the collection of like you're describing. So we'll consider it in there

Just to close this post: this was fixed in InedoCore 1.0.12, after diagnosing the issue on a ticket (EDO-5683).

Are you saying you can't create a job from a template?

The main purpose of the template is:

Instead of specifying the plan and server targeting each time you create a job, you can create a job template that will specify these for you. The template can also specify variables that will need to be entered when the job is run.

While this can save you a few steps when running jobs, the biggest benefit of job templates is that, once defined, you can now trigger jobs using a the job trigger API. This will allow you to use nearly any other tool, such as Jenkins or a PowerShell script, to trigger an Otter orchestration job.

However, we plan to expand it to be a lot more useful with better variable selection, etc.

Did the changes from OT-284 help at all? That should have drastically sped up the servers overview page at least. It was in Otter 2.1.3.

Thanks Josh; I'll make sure we discuss this as a team and respond soon!

We definitely won't remove them (especially w/o a replacement), because this functionality is important. We just want to make sure we understand more usecases that are related specifically to build/deploy scenarios as opposed to general-purpose jobs, and make sure we support those really well.

Docker doesn't need to be installed on the server.

Your workstation (i.e. the docker client) needs to trust the certificate. So make sure to do that on your computer as well.

Unfortunately the Native API is essentially a database wrapper, and one of the few things that can't be handled at the database layer is encryption.

While we want to create a resource credential API at some point, in the meantime, the only workaround would be to encrypt/decrypt the secrets yourself, using the Encryption Key stored in your configuration file.

There were no changes that would have caused this, but common things to check are

• Make sure WebDAV or another HTTP-filter didn't get enabled or installed by mistake; this will block certain requests from ever reqching ProGet

• Grant anonymous user full permissions to make sure the connection works; often times, the error is between ProGEt and the client

• Once it works with anonymous, start restoring privileges/API keys until you identify which configuration is causing it

Unfortunately, the Docker client does not seem to support non-SSL connections (despite what their documentation says).

But based on that error, you just need to trust the certificate. This document shows you how to trust the self-signed certificate you created. That's probably what the signing error means.

note you need to reboot after trusting.