URL rewriting issue after new Umbrella installation

[jykae]

I installed Umbrella 0.8.0 from .deb package.
We are currently using SSL certs that came with the package.

When I publish API configuration, Umbrella rewrites URLs so that I am not able to access /admin path.

We have another server that has SSL certificates setup, it works.
Could this be better informed in API Umbrella documentation, bolded or something..

Currently it is in one sentence under "Installation":
"API Umbrella will use as self-signed certificate which won't be valid for production use."

I think it should be mentioned under "Getting started" as well.

[brylie]

As @jykae mentions, the /admin path is unavailable, rendering a 404. This is strange behavior, as it doesn't crop up until the first API backend is published. /admin is available on the fresh installation.

[jykae]

And to be precise, this is Nginx "not found" message, I get after API configuration publishing.

[GUI]

Sorry for the trouble! Now that you mention this issue, I think I've possibly seen this before with the v0.8.0 package release. It hinges on a couple factors, and I'm pretty sure it got fixed later in git master, but that unfortunately doesn't help you with the package release. As a workaround can you try adding this to your /etc/api-umbrella/api-umbrella.yml config file on the server and then restart API Umbrella (sudo /etc/init.d/api-umbrella restart)?

hosts:
  - hostname: YOUR_HOSTNAME_HERE
    default: true

Substitute YOUR_HOSTNAME_HERE with whatever domain name you're using for the public-facing site (from the linked issue above, it sounds like that might be hostname: umbrella.apinf.io). I think manually defining the hostname like this in the YAML config file will make things work in API Umbrella v0.8.0. Let me know if that doesn't do the trick, though.

I'll verify that this situation is indeed fixed in git master and add some test coverage around this scenario. We're also trying to wrap up a few things and the get the v0.9.0 package releases out in the next week or two, so hopefully that will also help more permanently solve this issue (but the above YAML should still be perfectly valid under v0.9.0).

[jykae]

Thanks! Solved the issue.