API System giving 404 errors
-
Server
- FOG Version: 1.4.4
- OS:
- Ubuntu 16.04
- PHP 7.1
Client
- Service Version:
- OS:
Description
I have decided to attempt to learn the API system, with the overall goal in mind to use the API system to create a script that creates and rename images based on our hosts. I enabled the API System in the FOG Configure settings and tried experimenting with the API by running: “curl -H ‘fog-api-token: token’ -H ‘fog-user-token: token’ -X GET http://fogserver/fog/task/current” to list our current/active task. However, I keep getting 404 errors returned as shown in the following image.
If anyone could help me understand why I keep getting these errors and/or help me better understand the API it would be much appreciated.
-
Is the API system enabled in the FOG Configuration Settings?
-
I’m not seeing a problem. Is API actually enabled for the user and overall?
-
@george1421 Yes, it is enabled in the configure settings
-
@Tom-Elliott Yes, it is enabled for both user and overall
-
Any thoughts on why this is 404ing?
-
@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 -
@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.
-
Do me a favor and try:
sudo a2dissite 000-default sudo systemctl restart apache2
-
@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.
-
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.
-
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).
-
@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.
-
@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”).
-
Can you post a copy of your current /etc/apache2/sites-enabled/001-fog.conf please?
-
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!
-
@mwarner Loose the “api” portition of the call. ALl requests are happening via /fog/<item>/<item>
/fog/api/<item> is invalid
-
@tom-elliott it still returns a 404 without /api in the URL
-
trying to hit you on chat.
-
@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