API System giving 404 errors

[mwarner]

Any thoughts on why this is 404ing?

[Wayne Workman]

@mwarner You’re trying /fog/task/current but I think it’s supposed to be /fog/task/active

Look at these posts for examples:
https://forums.fogproject.org/topic/9779/can-i-use-some-kind-of-script-to-create-image-and-ghost-my-lab-machines/10

[mwarner]

@Wayne-Workman this endpoint does not work either. I tried every single endpoint in the example you showed and none of them seem to return anything but a 404, whether I’m using CURL, Postman, or a Node.js application.

[Tom Elliott]

Do me a favor and try:

sudo a2dissite 000-default
sudo systemctl restart apache2

[Wayne Workman]

@mwarner Please do what @Tom-Elliott asked below.

Because the commands that I know work don’t work for you, something else must be wrong here. I think Tom is on the right path.

[Tom Elliott]

So the problem you’re seeing is due to how Ubuntu deals with named virtual hosts. I’m going on a limb and guessing you’re accessing the fog server via dnsname of the fog server? What if you change the dnsname to ip? The fog config for Apache doesn’t add in named hosts by dns name, by default. It does it based on the ip. Because the servername element of the config is the ip, that config isn’t running for the dns called name. The default site is the trying to route it, which is not configured to rewrite the request to the API.

[mwarner]

No dice. I disabled the default Apache configuration (000-default) and even set a ServerAlias for fog.emg-usa.com (where I, as you correctly guessed, typically visit the site from) in the 001-fog configuration file.

I did try replacing the DNS name with an IP and still no luck. My IP for the main FOG server is, let’s call it, 10.1.10.254 and I tried the following endpoints:

10.1.10.254/fog/task/current
10.1.10.254/fog/api/task/current
10.1.10.254/task/current

all of which received a 404 error. Same thing with the new ServerAlias added. I made sure to restart the apache2 service after each edit to the config files.

Interestingly enough, 10.1.10.254/fog/api returns a 403 Forbidden, but after investigating the api/index.php file it doesn’t seem to shed any light into the issue (at least from what I saw).

[Tom Elliott]

@mwarner A 403 means you’re missing the FOG-API-Token.

401 (after getting fog-api-token set and sent) = you aren’t using a user token/basic auth to get information.

[mwarner]

@Tom-Elliott Right, but if I attach a proper endpoint (say /api/task/current) I get a 404. As far as I’m aware, /api by itself is useless and that seems to be the only endpoint sending a meaningful response (one that isn’t “not found”).

[Tom Elliott]

Can you post a copy of your current /etc/apache2/sites-enabled/001-fog.conf please?

[mwarner]

@tom-elliott

NameVirtualHost *:80
<VirtualHost *:80>
    KeepAlive Off
    ServerName 10.1.10.254
    ServerAlias fog.emg-usa.com
    DocumentRoot /var/www/
    <Directory /var/www/fog/>
        DirectoryIndex index.php index.html index.htm
    </Directory>
    RewriteEngine On
    RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
    RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-d
    # RewriteRule ^\/(.*)$ /fog/api/index.php [QSA,L]
</VirtualHost>

Just realized that I tried to comment out the RewriteRule in an attempt to get it working earlier. I just uncommented it and it works fine. So it definitely was the missing ServerAlias that was causing the issue.

fog.emg-usa.com/fog/api/task/current

and

10.1.10.254/fog/api/task/current

are both returning 403 errors now. I’ll add an API key in a moment to see if we can get some actual data back along with a 200 code!

[Tom Elliott]

@mwarner Loose the “api” portition of the call. ALl requests are happening via /fog/<item>/<item>

/fog/api/<item> is invalid

[mwarner]

@tom-elliott it still returns a 404 without /api in the URL

[Tom Elliott]

trying to hit you on chat.

[mwarner]

@Tom-Elliott I take that back, it returns a 403 in the browser but when I use CURL it returns 0 bytes of data unless I use /api in the URL

[Tom Elliott]

Remoted with @mwarner and we were able to fix the problem.

They were accessing the api using :<url>/task/current when it should’ve been :<url>/fog/task/current.

The confusion came because they weren’t expecting to need the /fog portion as they allow the :<url> to go directly to the fog gui.

[Tom Elliott]

You think it’s safe to solve this now?

[Wayne Workman]

The examples I posted do have the /fog directory included in them.

[mwarner]

@Tom-Elliott Yes it is safe to solve now, sorry for the delay. Thanks again!