Unsupported orchestrator type Kubernetes for browse is the error i get when trying to browse a newly created ACS kubernetes cluster
so the problem as usual was user error. the correct command is az acs kubernetes browse
Related
We have NiFi and Registry with LDAP authorization.
While updating Flow version via regestry-api this error appears:
Failed to register flow with Flow Registry due to Error creating snapshot: Untrusted proxy [CN=192.168.199.87, OU=NIFI] for write operation.
How can I create this user [CN=192.168.199.87, OU=NIFI] with "Can proxy user requests" option in Registry?
Thanks.
I am setting up a development server for Trino using Trino's docker image. I need to integrate Trino to LDAP so we decided to secure Trino behind a load balancer (see here) but after enabling password authentication, we see the following when we access Trino (https://trino_domain) WebUI:
My config.properties are as follows:
By right I should be prompted with the usual login screen with the password field enabled. There is no errors in the logs. The only warning I could find is
I could not find anything on google on this so I am not sure what is missing/wrong. Please help.
This is expected behavior when attempting to connect via http when the coordinator is configured for https.
This video might help you configure Trino with a load balancer and LDAP:
https://www.youtube.com/watch?v=KiMyRc3PSh0
I have the Sonos Acme developer test service setup and running but my Sonos Player doesn't seem to be able to connect. I'm wondering if a TLS SSL certificate is required no matter what even in a sandboxed environment.
I'm running the java service on a remote AWS instance behind a domain. The service is setup with the default installation details. It does not log any sort of connection attempt once I add the service to the Sonos player via customSD.
Accessing the Sonos Player via customSD and adding the Acme service does respond with Success! But again it doesn't show up in the service list. Manually pulling the WSDL does work correctly via the http request.
Also to note that Sonos seems to be in the middle of creating it's new developer portal and since last Monday ( June 24th ) the new portal no longer references the Acme test service. I'm wondering if this is due to it no longer being valid and it's documentation out of date (est. 2017-2018).
I expect the service to show up in the Sonos Controller when adding a new service but it doesn't appear and the log doesn't show any attempts to connect.
An SSL endpoint is required for production, but you can use a non-SSL endpoint for testing. See the comments in this answer for details: With a Sonos player, adding local service to customSD does not show up Music Services
I've setup a kubernetes cluster using Windows containers on Azure Container Service and have successfully deployed my first replication controller.
I'd like to utilize the k8s dashboard as documented here: https://kubernetes.io/docs/tasks/access-application-cluster/web-ui-dashboard/
Navigating to the clusters DNS name via https with /ui appended to the path results in "Unauthorized". Same for the public IP of the cluster.
Then I tried "kubectl cluster-info" and it spits out a "kubernetes-dashboard" Url which is different than the above Url and also results in "Unauthorized".
Any ideas how I get this to work in ACS?
This is documented in the ACS documentation pages. See https://learn.microsoft.com/en-us/azure/container-service/kubernetes/container-service-kubernetes-ui
We have front and back end cloud service that communicate via WCF services which are secured using certificate credentials. The problem we are having is that the request fails with the following error:
verb="POST"
authenticationType="NOT_AVAILABLE" activityId="{00000000-0000-0000-0400-0080000000F7}"
failureReason="STATUS_CODE"
statusCode="403.16"
triggerStatusCode="403.16"
(From IIS failed request tracing)
I believe the issue is as described here:
https://support.microsoft.com/en-gb/help/252657/iis-5.0-http-403.16-forbidden-client-certificate-untrusted-or-invalid
(That the server does not trust third party CAs by default. )
If I do as described in the link the issue is resolved but the cloud service isn't part of a domain and I don't know how to apply this setting as part of the deployment or programmatically as part of the start-up.
What I also find strange is that this issue doesn't seem common even though I presume securing WCF communications on Azure cloud services using certificates isn't unusual, so I wonder if the issue is a symptom of something else I am doing wrongly.