SOLVED Error HTTP 5xx No master node available

  • Dear all,

    I am fairly new to this project and I am currently trying to set up my own system of a master and storage node. Unfortunately, the moment I create a capturing task the client is not able to boot from my storage node anymore (HTTP 5xx error appears in the second stage). When I delete the task from the main server again the booting succeeds and the iPXE boot menu is displayed.

    About the setup:

    The master node is running somewhere in the cloud and can be reached via a public IP address, while the storage node runs locally in my network without a globally routable IP (local only).
    My idea to resolve the problem of replication was to connect the two systems via a shared network such as zerotier. This works so far that the master detects the storage node and all its information.

    I already tried to add two storage nodes to the master server, one with the IP of the zerotier network and one with the local IP in the hope of fixing something without any luck.

    I know that this is not necessarily a default scenario, but I did not find another way of saying a FOG server in the cloud with a local storage instance while using the FOGImageReplicator service.
    Any pointers, ideas or other help is well appreciated! Thanks!

    Master Node:
    Internal IP:
    Public IP: 36.xx.xx.xx (resolved by

    Storage Node:
    Internal IP:

    Installation method: git
    FOG version: working-1.6
    OS: Ubuntu 18.04 LTS
    HTTPS: yes
    Custom CA: no

    Storage node config:

    You will need this, write this down!
    IP Address:
    Interface:           enp0s3
    Management Username: fogproject
    Management Password: *************************

    From the apache error log from the storage node:

    [Wed Jan 20 23:44:19.091107 2021] [proxy_fcgi:error] [pid 8722] [client] AH01071: Got error 'PHP message: PHP Fatal error:  Uncaught Exception: No master nodes available in /var/www/fog/lib/fog/storagegroup.class.php:283\nStack trace:\n#0 /var/www/fog/lib/fog/bootmenu.class.php(1384): StorageGroup->getMasterStorageNode()\n#1 /var/www/fog/lib/fog/bootmenu.class.php(419): BootMenu->getTasking()\n#2 /var/www/fog/service/ipxe/boot.php(52): BootMenu->__construct()\n#3 {main}\n  thrown in /var/www/fog/lib/fog/storagegroup.class.php on line 283\n'

    In case it helps… this is the generated boot.php file from the storage node.

  • @george1421 Thanks for your advice! I will consider building a more distributed FOG environment once more clients will be setup with FOG.

    Btw should I mark the thread as resolved or something?

  • Moderator

    @tomtom2770 So let me discuss what FOG needs to work in your environment.

    The master node is kind of the brains of the FOG system since it houses the fog database.

    The storage nodes are disk storage for deploy only. It needs to be in contact with the FOG server 100% of the time for the storage node to remain functional.

    So lets say you have 1 sites HQ and SiteA. You have a master node at HQ and a storage node at SiteA. At SiteA you have the dhcp options to point to the local storage node and the needed boot file.

    You pxe boot a target computer at SiteA. It downloads the boot file from the local storage node and iPXE starts up. Then iPXE reaches out to the local storage node to download default.ipxe file. That file points to your master node boot.php script which builds the iPXE Menu. If the computer isn’t registered, when you select register it will download FOS Linux (over the wan) from HQ to the target computer. (once the computer is registered and associated with a location, the storage node will be used for all other file transfers).

    Now if you have the fog client installed on the target computer it will only talk to the master node to get instructions (install snapin, update inventory, etc). If the target computer get an instruction to install a snapin, that snapin is downloaded from the local storage node.

    So the point here is that the HQ fog server is important here and must be at a fully routable location from all remote sites.

    If your site to site VPN ever goes down so does FOG imaging. Depending on your goal, number of client computers, and stability of the VPN network, you might want to install a full fog server at each location.

  • So I followed @george1421 advice and removed the public IP from my FOG instance. Instead I connected all nodes via the zerotier network.

    Clients can still be setup without joining them to the zerotier network by using a router which is configured to connect to the same zerotier network (“site-to-site” in a wider sense).

  • Thanks @george1421 for your reply, I will reconsider my setup and try to make the master node not public. Can you imagine any immediate problems if only the storage node could reach the master node and the clients can only contact the storage nodes?

    Btw I fixed the original problem by properly setting the IP of the master storage node to it’s public IP instead of the private one.

  • Moderator

    @tomtom2770 You need to do the vpn as site to site so that its transparent to both the servers as well as client computers then it will work.

    Also the FOG server isn’t secure enough to have it public facing. If it is truly public facing its a security risk to your organization.

    FWIW I would NOT install 1.6 just yet (dev branch or not). Stick with 1.5.9 (dev branch if you want). The 1.5.9 is much more mature and stable of a product than 1.6.