FOG Project

Before you start: what PXE imaging requires

FOG images machines by PXE network boot, and that imposes real network requirements. Read this before you design your deployment, because it determines where this VM belongs.

A machine being imaged powers on, asks its local DHCP server for an address, and that DHCP server tells it where to fetch a bootloader (options 66 and 67). The machine then fetches the bootloader over TFTP, chains to FOG over HTTP, and moves image data over NFS.

• The DHCP handoff happens on the client's local broadcast domain, so the DHCP server that answers must be one you can configure. This appliance does not provide it.
• Everything after that handoff (TFTP, HTTP and NFS) is routed unicast. The FOG server itself therefore does not need to be on the same layer 2 segment as the clients. It needs to be routable from them.

The supported topology on Azure is therefore this VM in your VNet, with your client machines on premises or in a connected network. The clients reach the VM over VPN or ExpressRoute. Your existing on-premises DHCP server sets options 66 and 67 to point at this VM's private address.

Two FOG capabilities genuinely do not work on an Azure VNet, and no configuration changes that:

• Multicast deployment, which images many machines simultaneously from one stream. Azure VNets do not carry multicast. Unicast deployment to each machine works normally.
• FOG's proxyDHCP mode, which supplies boot options without running a full DHCP server. It depends on broadcast traffic, which Azure VNets also do not carry. Setting options 66 and 67 on your own DHCP server is the supported path, and is what Step 9 covers.

Plan for bandwidth as well. Disk images are tens of gigabytes, and deploying them from Azure to on-premises machines pulls that volume across your VPN or ExpressRoute link for every machine. For large on-premises fleets, a FOG storage node on the client network is the usual answer, with this VM as the management server.

Prerequisites

You need an active Azure subscription, an SSH key pair, and a VNet and subnet in the target region. Standard_B2ms (2 vCPU / 8 GiB RAM) is the recommended size, because FOG runs Apache, PHP, MariaDB, NFS and TFTP together.

The OS disk holds /images. Captured images are large, so size the disk for your image library. Alternatively, attach a data disk and mount it at /images.

NSG inbound rules: allow 22/tcp from your management network, 80/tcp from the networks that need the console, and 69/udp, 2049/tcp and 21/tcp from the subnets whose machines will be imaged. Do not expose any of these to the internet. The boot plane is anonymous by design, so the NSG is what scopes it.

Step 1 - Deploy from the Azure Marketplace

In the Azure portal, search the Marketplace for FOG Project on Ubuntu 24.04 LTS by SecureAnyCloud and select Create.

Choose your subscription, resource group and region, and set the size to Standard_B2ms. Select SSH public key authentication with the username azureuser. Allow inbound 22/tcp from your management network only.

Add the remaining rules from the Prerequisites section after the VM is created.

Step 2 - Deploy from the Azure CLI

Run these commands on your own workstation, not on the VM. Accept the image terms once per subscription before the first deployment:

az vm image terms accept --publisher sac --offer fog-project-ubuntu-24-04 --plan default
az group create --name fog-rg --location eastus
az vm create \
  --resource-group fog-rg \
  --name fog-server \
  --image sac1647283583153:fog-project-ubuntu-24-04:default:latest \
  --size Standard_B2ms \
  --storage-sku StandardSSD_LRS \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

Step 3 - Connect to your VM

ssh azureuser@<vm-ip>

Step 4 - Confirm the services are running

FOG is several cooperating services, so check them together. All of them must report active.

sudo systemctl is-active apache2 mariadb tftpd-hpa nfs-kernel-server vsftpd

active active active active active

The seven FOG daemons run alongside them:

sudo systemctl is-active FOGScheduler FOGImageReplicator FOGImageSize FOGMulticastManager FOGPingHosts FOGSnapinHash FOGSnapinReplicator

active active active active active active active

The web console answers on the loopback interface:

curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1/fog/management/index.php

200

Step 5 - Confirm no DHCP server is running

This property makes FOG safe to run on a cloud network, so verify it yourself. FOG records its DHCP decision in its own settings file:

sudo grep -E '^(bldhcp|dodhcp)=' /opt/fog/.fogsettings

dodhcp='N' bldhcp='0'

No DHCP server package is installed:

for p in isc-dhcp-server kea-dhcp4-server dnsmasq; do if dpkg-query -W -f='${Status}' "$p" 2>/dev/null | grep -q '^install ok installed$'; then echo "$p: INSTALLED" else echo "$p: not installed" fi done

isc-dhcp-server: not installed kea-dhcp4-server: not installed dnsmasq: not installed

Nothing is listening on the DHCP server port:

ss -lnu | grep -c ':67 ' || echo 0

0

Step 6 - Retrieve your per-VM credentials

Every credential on this VM was generated on its own first boot. The file is readable only by root.

sudo cat /root/fog-project-credentials.txt

You will see the console login, both API tokens, the server address and the database credentials. The console password is what you use in Step 8:

sudo grep -E '^(fog_web_url|fog_admin_user|fog_server_address|fog_tftp_bootfile)=' /root/fog-project-credentials.txt

The file is 0600 root:root:

sudo ls -l /root/fog-project-credentials.txt

FOG's documented default login, fog / password, does not work on your VM. The build replaces it with the generated password before the image is captured, and first boot then sets a value unique to your machine.

Step 7 - Confirm the boot plane and image store

Fetch a PXE bootloader over TFTP exactly as a booting machine would:

cd /tmp && rm -f undionly.kpxe && tftp 127.0.0.1 -c get undionly.kpxe && ls -l undionly.kpxe

-rw-r--r-- 1 azureuser azureuser 105509 Jul 19 08:40 undionly.kpxe

The iPXE chain file tells booting machines where to find the FOG server. It is regenerated with your VM's address on first boot:

sudo tail -1 /tftpboot/default.ipxe

The image store is exported over NFS, scoped to your VM's own subnet rather than to every host:

sudo exportfs -s

/images 10.0.0.0/24(sync,no_wdelay,hide,insecure_locks,fsid=0,anonuid=1001,anongid=1001,sec=sys,ro,secure,root_squash,all_squash) /images/dev 10.0.0.0/24(async,no_wdelay,hide,fsid=1,anonuid=1001,anongid=1001,sec=sys,rw,secure,root_squash,all_squash)

If your machines are imaged from a different subnet reached over VPN or ExpressRoute, add that CIDR to /etc/exports and re-export. The following block is an example to adapt, not something to run as is:

# /etc/exports - add your imaging subnet alongside the local one /images 10.50.0.0/16(ro,sync,no_wdelay,subtree_check,insecure_locks,all_squash,anonuid=1001,anongid=1001,fsid=0) /images/dev 10.50.0.0/16(rw,async,no_wdelay,subtree_check,all_squash,anonuid=1001,anongid=1001,fsid=1)

Step 8 - Sign in to the FOG console

Browse to http://<vm-ip>/fog/management. Sign in as fog with the fog_admin_password value from Step 6.

The dashboard shows the server at a glance: storage group activity, disk usage on the storage node and imaging activity over the last 30 days.

Step 9 - Point your DHCP server at the FOG server

FOG needs your existing DHCP server to tell booting machines where to find it. Set two options on the scope serving the machines you want to image:

• Option 66 (next-server / TFTP server name): this VM's private IP address, which is the fog_server_address value from Step 6
• Option 67 (filename / bootfile name): undionly.kpxe for BIOS machines, or snponly.efi for UEFI machines

On an ISC DHCP server, the scope looks like this. Adapt the addresses to your network. This is an example, not something to run on this VM:

# dhcpd.conf - point PXE clients at the FOG server subnet 10.50.0.0 netmask 255.255.0.0 { range 10.50.10.100 10.50.10.200; option routers 10.50.0.1; next-server 10.0.0.4;
# your FOG server's private IP filename "undionly.kpxe"; # use "snponly.efi" for UEFI clients }

On a Windows DHCP server, set scope option 066 Boot Server Host Name to the FOG server's IP and 067 Bootfile Name to undionly.kpxe or snponly.efi.

Mixed BIOS and UEFI fleets need your DHCP server to select the bootfile by client architecture. Both ISC DHCP and Windows Server support this. FOG's documentation covers the exact syntax.

Step 10 - Register a machine

With DHCP pointing at the server, boot a client machine from the network. It fetches the bootloader, chains to FOG, and presents the FOG boot menu. Choose Perform Full Host Registration and Inventory to add it to FOG with its hardware inventory.

Registered machines appear under Host Management, where you assign an image, put them in groups and schedule tasks.

Step 11 - Define an image and capture

Under Image Management, select Create New Image and give it a name, a storage group and an image type. Single Disk - Resizable suits most single-disk Windows and Linux workstations.

To capture, assign the image to your reference machine under Host Management, schedule a Capture task, and network boot that machine. It boots into FOG's imaging environment and uploads the image to /images.

To deploy, assign the same image to the target machines, schedule a Deploy task, and boot them.

Step 12 - Use the REST API

FOG's REST API is enabled on this image with tokens generated for your VM. Both tokens are stored ready to paste straight into the request headers:

API_TOKEN=$(sudo grep '^fog_api_token=' /root/fog-project-credentials.txt | cut -d= -f2-)
USER_TOKEN=$(sudo grep '^fog_user_api_token=' /root/fog-project-credentials.txt | cut -d= -f2-)
curl -s -H "fog-api-token: ${API_TOKEN}" -H "fog-user-token: ${USER_TOKEN}" \
  http://127.0.0.1/fog/system/info

success

List the registered machines as JSON:

API_TOKEN=$(sudo grep '^fog_api_token=' /root/fog-project-credentials.txt | cut -d= -f2-)
USER_TOKEN=$(sudo grep '^fog_user_api_token=' /root/fog-project-credentials.txt | cut -d= -f2-)
curl -s -H "fog-api-token: ${API_TOKEN}" -H "fog-user-token: ${USER_TOKEN}" \
  http://127.0.0.1/fog/host | head -c 200

Requests without valid tokens are rejected:

curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1/fog/system/info

403

FOG's hostName column is 16 characters, so machine names are truncated beyond that.

Security

• No DHCP server. FOG's own DHCP server is not installed and is not running. The build asserts this, and every first boot asserts it again. The appliance refuses to start a DHCP server.
• No default credentials. FOG's documented fog / password default does not authenticate on your VM. The console password, both API tokens, both database passwords and the storage account password are generated on your VM's first boot and exist nowhere else. They are written to /root/fog-project-credentials.txt at 0600 root:root.
• The database is not reachable off the VM. MariaDB is bound to 127.0.0.1 with name resolution disabled.
• The image store is scoped. Upstream FOG exports /images to every host with /images/dev writable. This image exports it to your VM's own subnet instead, and you widen it deliberately as shown in Step 7.
• The boot plane is anonymous by protocol necessity. TFTP has no authentication, and a machine that is powering on cannot present credentials. Scope 69/udp, 2049/tcp and 21/tcp with your NSG to the subnets that image machines, and never expose them to the internet.
• FOG stores console passwords as unsalted MD5. That is upstream FOG's scheme and cannot be changed without forking its authentication. Treat the console as a trusted-network service, put it behind your NSG, and do not reuse the console password anywhere else.
• Change the console password from Users in the web console if you want a value you have chosen rather than the generated one.

Maintenance

Ubuntu security updates apply automatically through unattended upgrades. Restart the appliance after a kernel update:

sudo systemctl restart apache2 mariadb tftpd-hpa nfs-kernel-server

Back up the FOG database and your image library. The database holds the inventory, groups, tasks and settings:

sudo mysqldump fog | gzip > /tmp/fog-backup.sql.gz && ls -lh /tmp/fog-backup.sql.gz

Watch free space on /images, because it fills as your image library grows:

df -h /images | tail -1

License and source

FOG Project is licensed under the GNU General Public License, version 3 or later. The complete corresponding source for the version in this image ships on the image:

ls /opt/fog-source/LICENSE /opt/fog-source/SAC-SOURCE-NOTICE.txt

The notice file records the exact upstream commit, the source URLs for the bundled iPXE and Syslinux bootloaders, and a written offer for machine-readable source. Nothing in SecureAnyCloud's terms restricts your rights in the FOG software or any other GPL-licensed component.

Support

SecureAnyCloud provides 24/7 support for this image. Contact sales@secureanycloud.com. For questions about FOG itself, the project's own documentation is at docs.fogproject.org and its community forum is at forums.fogproject.org.

Deploy on Azure

Launch FOG Project on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com

Before you start: what PXE imaging requires

FOG images machines by PXE network boot, and that imposes real network requirements. Read this before you design your deployment, because it determines where this instance belongs.

A machine being imaged powers on, asks its local DHCP server for an address, and that DHCP server tells it where to fetch a bootloader (options 66 and 67). The machine then fetches the bootloader over TFTP, chains to FOG over HTTP, and moves image data over NFS.

• The DHCP handoff happens on the client's local broadcast domain, so the DHCP server that answers must be one you can configure. This appliance does not provide it.
• Everything after that handoff (TFTP, HTTP and NFS) is routed unicast. The FOG server itself therefore does not need to be on the same layer 2 segment as the clients. It needs to be routable from them.

The supported topology on AWS is therefore this instance in your VPC, with your client machines on premises or in a connected network. The clients reach the instance over VPN or Direct Connect. Your existing on-premises DHCP server sets options 66 and 67 to point at this instance's private address.

Two FOG capabilities genuinely do not work on a cloud VPC, and no configuration changes that:

• Multicast deployment, which images many machines simultaneously from one stream. VPC subnets do not carry multicast. Unicast deployment to each machine works normally.
• FOG's proxyDHCP mode, which supplies boot options without running a full DHCP server. It depends on broadcast traffic, which VPC subnets also do not carry. Setting options 66 and 67 on your own DHCP server is the supported path, and is what Step 9 covers.

Plan for bandwidth as well. Disk images are tens of gigabytes, and deploying them from AWS to on-premises machines pulls that volume across your VPN or Direct Connect link for every machine. For large on-premises fleets, a FOG storage node on the client network is the usual answer, with this instance as the management server.

Prerequisites

You need an AWS account, an EC2 key pair, and a VPC and subnet in the target region. m5.large (2 vCPU / 8 GiB RAM) is the recommended instance type, because FOG runs Apache, PHP, MariaDB, NFS and TFTP together.

The captured image library lives on a dedicated EBS data volume mounted at /images, separate from the OS disk and independently resizable. Grow it as your image library grows.

Security group inbound rules: allow 22/tcp from your management network, 80/tcp from the networks that need the console, and 69/udp, 2049/tcp and 21/tcp from the subnets whose machines will be imaged. Do not expose any of these to the internet. The boot plane is anonymous by design, so the security group is what scopes it.

Connecting to your instance

Connect over SSH. On Ubuntu 24.04 LTS, the SSH login user is ubuntu:

ssh ubuntu@<instance-public-ip>

Step 1 - Launch from the AWS Marketplace

In the AWS Marketplace, search for FOG Project - Network Imaging and Cloning Server AMI by SecureAnyCloud. Choose Continue to Subscribe, then Continue to Configuration, then Continue to Launch.

Select the m5.large instance type, your VPC and subnet, and your EC2 key pair. Set the security group to allow inbound 22/tcp from your management network only. Add the remaining rules from the Prerequisites section after launch.

Step 2 - Launch from the AWS CLI

Run these commands on your own workstation, not on the instance. Replace the AMI ID with the one shown for your Region on the Marketplace launch page. Use your own key pair, subnet and security group IDs:

aws ec2 run-instances \
  --image-id ami-xxxxxxxxxxxxxxxxx \
  --instance-type m5.large \
  --key-name your-key \
  --subnet-id subnet-xxxxxxxx \
  --security-group-ids sg-xxxxxxxx \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=fog-server}]'

Step 3 - Connect to your instance

ssh ubuntu@<instance-public-ip>

Step 4 - Confirm the services are running

FOG is several cooperating services, so check them together. All of them must report active.

sudo systemctl is-active apache2 mariadb tftpd-hpa nfs-kernel-server vsftpd

active active active active active

The seven FOG daemons run alongside them:

sudo systemctl is-active FOGScheduler FOGImageReplicator FOGImageSize FOGMulticastManager FOGPingHosts FOGSnapinHash FOGSnapinReplicator

active active active active active active active

The web console answers on the loopback interface:

curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1/fog/management/index.php

200

Step 5 - Confirm no DHCP server is running

This property makes FOG safe to run on a cloud network, so verify it yourself. FOG records its DHCP decision in its own settings file:

sudo grep -E '^(bldhcp|dodhcp)=' /opt/fog/.fogsettings

dodhcp='N' bldhcp='0'

No DHCP server package is installed:

for p in isc-dhcp-server kea-dhcp4-server dnsmasq; do if dpkg-query -W -f='${Status}' "$p" 2>/dev/null | grep -q '^install ok installed$'; then echo "$p: INSTALLED" else echo "$p: not installed" fi done

isc-dhcp-server: not installed kea-dhcp4-server: not installed dnsmasq: not installed

Nothing is listening on the DHCP server port:

ss -lnu | grep -c ':67 ' || echo 0

0

Step 6 - Retrieve your per-instance credentials

Every credential on this instance was generated on its own first boot. The file is readable only by root.

sudo cat /root/fog-project-credentials.txt

You will see the console login, both API tokens, the server address and the database credentials. The console password is what you use in Step 8:

sudo grep -E '^(fog_web_url|fog_admin_user|fog_server_address|fog_tftp_bootfile|fog_uefi_bootfile)=' /root/fog-project-credentials.txt

fog_web_url=http://<instance-public-ip>/fog/management fog_admin_user=fog fog_server_address=<instance-private-ip> fog_tftp_bootfile=undionly.kpxe fog_uefi_bootfile=snponly.efi

The file is 0600 root:root:

sudo ls -l /root/fog-project-credentials.txt

FOG's documented default login, fog / password, does not work on your instance. The build replaces it with the generated password before the image is captured, and first boot then sets a value unique to your machine.

Step 7 - Confirm the boot plane and image store

Fetch a PXE bootloader over TFTP exactly as a booting machine would:

cd /tmp && rm -f undionly.kpxe && tftp 127.0.0.1 -c get undionly.kpxe && ls -l undionly.kpxe

-rw-rw-r-- 1 ubuntu ubuntu 105509 Jul 21 09:50 undionly.kpxe

The iPXE chain file tells booting machines where to find the FOG server. It is regenerated with your instance's address on first boot:

sudo tail -1 /tftpboot/default.ipxe

chain http://<instance-private-ip>/fog/service/ipxe/boot.php##params

The image store lives on its own EBS data volume and is exported over NFS, scoped to your instance's own subnet rather than to every host:

findmnt -no SOURCE,TARGET,FSTYPE,SIZE /images

/dev/nvme1n1 /images ext4 97.9G

sudo exportfs -s

/images 172.31.80.0/20(sync,no_wdelay,hide,insecure_locks,fsid=0,anonuid=1002,anongid=1002,sec=sys,ro,secure,root_squash,all_squash) /images/dev 172.31.80.0/20(async,no_wdelay,hide,fsid=1,anonuid=1002,anongid=1002,sec=sys,rw,secure,root_squash,all_squash)

If your machines are imaged from a different subnet reached over VPN or Direct Connect, add that CIDR to /etc/exports and re-export. The following block is an example to adapt, not something to run as is:

# /etc/exports - add your imaging subnet alongside the local one /images 10.50.0.0/16(ro,sync,no_wdelay,subtree_check,insecure_locks,all_squash,anonuid=1002,anongid=1002,fsid=0) /images/dev 10.50.0.0/16(rw,async,no_wdelay,subtree_check,all_squash,anonuid=1002,anongid=1002,fsid=1)

Step 8 - Sign in to the FOG console

Browse to http://<instance-public-ip>/fog/management. Sign in as fog with the fog_admin_password value from Step 6.

The dashboard shows the server at a glance: storage group activity, disk usage on the storage node and imaging activity over the last 30 days.

Step 9 - Point your DHCP server at the FOG server

FOG needs your existing DHCP server to tell booting machines where to find it. Set two options on the scope serving the machines you want to image:

• Option 66 (next-server / TFTP server name): this instance's private IP address, which is the fog_server_address value from Step 6
• Option 67 (filename / bootfile name): undionly.kpxe for BIOS machines, or snponly.efi for UEFI machines

On an ISC DHCP server, the scope looks like this. Adapt the addresses to your network. This is an example, not something to run on this instance:

# dhcpd.conf - point PXE clients at the FOG server subnet 10.50.0.0 netmask 255.255.0.0 { range 10.50.10.100 10.50.10.200; option routers 10.50.0.1; next-server 172.31.91.112;
# your FOG server's private IP filename "undionly.kpxe"; # use "snponly.efi" for UEFI clients }

On a Windows DHCP server, set scope option 066 Boot Server Host Name to the FOG server's IP and 067 Bootfile Name to undionly.kpxe or snponly.efi.

Mixed BIOS and UEFI fleets need your DHCP server to select the bootfile by client architecture. Both ISC DHCP and Windows Server support this. FOG's documentation covers the exact syntax.

Step 10 - Register a machine

With DHCP pointing at the server, boot a client machine from the network. It fetches the bootloader, chains to FOG, and presents the FOG boot menu. Choose Perform Full Host Registration and Inventory to add it to FOG with its hardware inventory.

Registered machines appear under Host Management, where you assign an image, put them in groups and schedule tasks.

Step 11 - Define an image and capture

Under Image Management, select Create New Image and give it a name, a storage group and an image type. Single Disk - Resizable suits most single-disk Windows and Linux workstations.

To capture, assign the image to your reference machine under Host Management, schedule a Capture task, and network boot that machine. It boots into FOG's imaging environment and uploads the image to /images.

To deploy, assign the same image to the target machines, schedule a Deploy task, and boot them.

Step 12 - Use the REST API

FOG's REST API is enabled on this image with tokens generated for your instance. Both tokens are stored ready to paste straight into the request headers:

API_TOKEN=$(sudo grep '^fog_api_token=' /root/fog-project-credentials.txt | cut -d= -f2-)
USER_TOKEN=$(sudo grep '^fog_user_api_token=' /root/fog-project-credentials.txt | cut -d= -f2-)
curl -s -H "fog-api-token: ${API_TOKEN}" -H "fog-user-token: ${USER_TOKEN}" \
  http://127.0.0.1/fog/system/info

success

List the registered machines as JSON:

API_TOKEN=$(sudo grep '^fog_api_token=' /root/fog-project-credentials.txt | cut -d= -f2-)
USER_TOKEN=$(sudo grep '^fog_user_api_token=' /root/fog-project-credentials.txt | cut -d= -f2-)
curl -s -H "fog-api-token: ${API_TOKEN}" -H "fog-user-token: ${USER_TOKEN}" \
  http://127.0.0.1/fog/host | head -c 200

Requests without valid tokens are rejected:

curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1/fog/system/info

403

FOG's hostName column is 16 characters, so machine names are truncated beyond that.

Security

• No DHCP server. FOG's own DHCP server is not installed and is not running. The build asserts this, and every first boot asserts it again. The appliance refuses to start a DHCP server.
• No default credentials. FOG's documented fog / password default does not authenticate on your instance. The console password, both API tokens, both database passwords and the storage account password are generated on your instance's first boot and exist nowhere else. They are written to /root/fog-project-credentials.txt at 0600 root:root.
• The database is not reachable off the instance. MariaDB is bound to 127.0.0.1 with name resolution disabled.
• The image store is scoped. Upstream FOG exports /images to every host with /images/dev writable. This image exports it to your instance's own subnet instead, and you widen it deliberately as shown in Step 7.
• The boot plane is anonymous by protocol necessity. TFTP has no authentication, and a machine that is powering on cannot present credentials. Scope 69/udp, 2049/tcp and 21/tcp with your security group to the subnets that image machines, and never expose them to the internet.
• FOG stores console passwords as unsalted MD5. That is upstream FOG's scheme and cannot be changed without forking its authentication. Treat the console as a trusted-network service, put it behind your security group, and do not reuse the console password anywhere else.
• Change the console password from Users in the web console if you want a value you have chosen rather than the generated one.

Maintenance

Ubuntu security updates apply automatically through unattended upgrades. Restart the appliance after a kernel update:

sudo systemctl restart apache2 mariadb tftpd-hpa nfs-kernel-server

Back up the FOG database and your image library. The database holds the inventory, groups, tasks and settings:

sudo mysqldump fog | gzip > /tmp/fog-backup.sql.gz && ls -lh /tmp/fog-backup.sql.gz

Watch free space on /images, because it fills as your image library grows. It is a dedicated EBS volume that you can resize independently of the OS disk:

df -h /images | tail -1

/dev/nvme1n1 98G 44K 93G 1% /images

License and source

FOG Project is licensed under the GNU General Public License, version 3 or later. The complete corresponding source for the version in this image ships on the image:

ls /opt/fog-source/LICENSE /opt/fog-source/SAC-SOURCE-NOTICE.txt

The notice file records the exact upstream commit, the source URLs for the bundled iPXE and Syslinux bootloaders, and a written offer for machine-readable source. Nothing in SecureAnyCloud's terms restricts your rights in the FOG software or any other GPL-licensed component.

Support

SecureAnyCloud provides 24/7 support for this image. Contact sales@secureanycloud.com. For questions about FOG itself, the project's own documentation is at docs.fogproject.org and its community forum is at forums.fogproject.org.

Deploy on AWS

Launch FOG Project on AWS with 24/7 support from SecureAnyCloud.

View on Marketplace

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com