Deployed OpenVidu 2.12 PRO on premise. Get prompted for username and password in https://YOUR_DNS_NAME/inspector, but all the login details I have available don’t work.
Is there a default login to the inspector? If not, where do I set login details?
Any information regarding this? I see others are able to setup and log in, so is there a tutorial step I’ve missed somewhere?
Hi,
URL https://YOUR_DNS_NAME/inspector should direclty show you the login page of OpenVidu Inspector, without asking for any previous username/password. That is, by default that path is completely open. If the browser is asking for basic auth credentials at /inspector, then that means that your path is probably protected some other way. Do you have any proxy or firewall in front of your OpenVidu Pro deployment?
I’ve basically set up a VM in Azure and given it a DNS name. So now it’s called something in the lines of
“https://awesome-server.region.cloudapp.azure.com/inspector”. I’ve set certificate to be Let’s Encrypt, and the deployment is a success. What is the default login for the OpenVidu Inspector? Does it look like this?
Finally figured it out! I opened an incognito tab to be sure it was reproducible.
If I first log in to url/kibana then go over to url/inspector, I will get the popup login posted above.
If I open an incognito tab and go directly to /inspector, then I’ll get the secret log in as you’ve mentioned.
So something about storing cookies from kibana log in?
Spoke too soon, now the login window pops up even in incognito mode. Tried both Edge and Chrome browser. Is there any way to disable kibana? I tried disabling and stopping the kibana.service on the server node, but the popup still shows.
But Kibana shouldn’t interfere with path https://YOUR_DOMAIN/inspector
Kibana is protected only at path https://YOUR_DOMAIN/kibana
This is working fine in our deployments. Can you check please for what element is the browser exactly asking the credentials? You can do this like this:
- Open the bowser’s console.
- Go to “Network” tab. There you will find all the requests performed by the web page.
- Whenever the browser prompts for the credentials, dismiss the message. You should see immediately some request go red, to a failure status (and with a 401 unauthorized status).
Which element is the one failing in your case?
Regards.
Okey, not what I expected. You are in fact getting the error just at /inspector.
Okey, first of all. That basic auth credentilas should be:
User: OPENVIDUAPP
Pass: Your secret (the secret you set up on deployment time)
But I still don’t understand why path /inspector is asking them, as it is not protected at all. If those credentials don’t work, then we’ll know something else is happening. If they work, I’ll have to set up an Azure deployment as close as possible to yours to test it out myself.
Then I get an 404 error.
Maybe the Inspector doesn’t correctly start up or something? And it defaults to basic auth of something else? Is there a way I can restart the Inspector manually or check if it is running properly?
I’m able to initiate sessions on the server, and everything else seems to work quite nicely.
Inspector doesn’t need to be started. It is not a separated service, it is just static files being served by OpenVidu Server Pro Service. I don’t know, this could be a networking issue. Have you met the network requirments stated in OpenVidu Pro On Premise deplyment Docs for your OpenVidu Server Pro Node?
Would you mind pasting here the incoming network rules set up for this machine in your Azure account?
Quite permissive as is now… I’ve also wondered if any of these (ofcourse SSH) can be removed/restricted to certain IP ranges. Any input on that while we’re here?
Any new ideas? I’ve tested on multiple PCs, so it’s nothing local or specific to the machine I’m on.
@pabloFuente Sorry for pinging, but I’ve exhausted most of my resources on this. Do you have any thoughts or suggestions that can help me move forward with debugging the issue? Any commands I can run on the VM?
Hi,
The only thing I can do is trying to replicate your exact scenario in Azure and see if the error occurs. Please, can you give me all of the details of your deployment? That would be all of the infromation of the machines you are using to deploy the cluster with Ansible. Including networking info.
I’ve already checked that in AWS this doesn’t seem to happen, so something related to Azure must be happening.
Set up two VMs within same resource group running Ubuntu 16.04 LTS.
Both running F2s sizes with accelerated networking on VM gen 2. Need to assign a DNS name to the server for the certificate. Can be done in Azure Portal pretty simply.
Ports on server node is that of above and ports on media node is the same as in the docs.
Since they are on the same vnet within the same resource group, the IPs to the media nodes become 10.0.x.x or 192.168.x.x.
Had to manually install Certbot on the server for the ansible deployment to work. Some log symbols fail in the ansible deployment as well, but don’t know if that affects anything.
Not sure if you need anything more specific?
We fixed some issues in the last couple of days regarding the On Premise deployment in Azure. Could you try to re-deploy again using these last changes? (already commited to the repository, so following the instructions again should be enough). I don’t think they will help with the particular problem stated in this post, but no certbot changes should be needed and no symbol errors should appear now.
So the tag is updated with the latest changes? Just doublechecking that I don’t need to specifiy a specific branch/commit for the deployment.
Yeap, tag is updated
Setting it all up again, with new everything, did indeed make the inspector accessible! So I’m not entirely sure what was wrong the last time, but it seems fixed for now. Haven’t tried entering Kibana (and I’m not sure if I dare 
), but the Inspector is working as intended.
The openvidu-server.jar file, is that the same as the one used in OpenVidu CE?