If you created a sym link (or even better mounted the new disk over /images, then you shouldn’t need to change anything. The mount should be transparent to fog. Understand this tutorial may be a bit more than you need since I’m moving all dynamic files off the root partition including the images and snapins. The general outline should give you an idea
The basic steps are outlined here: https://forums.fogproject.org/topic/11048/moving-fog-s-images-files-off-the-root-partition-2017-edition
Best posts made by george1421
-
RE: Mount System Error
-
RE: Fog client DNS name instead of IP
You can use a dns name and create a split horizion dns where you make fogserv.domain.com at each school point locally to the local fog server.
The issue is as Wayne said, Once the client touches a fog server it becomes tattooed to that fog server. Now if you know that ahead of time you can synchronize (i.e. copy the ssl certificate from your master FOG servers to the other remote fog servers) then have the clients reach out via dns name. If you have any clients that have touched one of the older non master fog server, you will have to reinstall the fog client on the target computer.
-
RE: Parted Magic
The latest parted magic iso image I can find (free) is 2013. So I looked through that iso and based on what I see I have an observation.
The error message mentions unable to mount the squashed file system file.
- I don’t see where you are transferring that file system via iPXE?
- I do see that file on the iso in /pmagic/pmodules directory.
I would be interested in reviewing the following files from the 2018 iso image.
- /boot/syslinux/syslinux.cfg
- /boot/pxelinux/sample_pxelinux.cfg
Lastly are you trying to iPXE boot this image on a uefi or bios based image?
-
RE: Change group ID number?
@vince-villarreal said in Change group ID number?:
Query OK, 0 rows affected
Records: 0 Duplicates: 0 Warnings: 0
ERROR: No query specifiedThis message is expected based on your query (it ran OK). You didn’t update or select any rows from the database. You altered a table descriptor.
-
RE: Upgraded to Fog 1.5.3 from 1.4.4. Cannot PXE boot anymore get PXE-55
@buercky ok I see something (and its not dead people…)
For the above system you have 2 dhcp servers responding with offers.
89.0.0.92 which is giving a next server of 98.0.192.40 with a boot file of undionly.kpxe (you might want to update your dhcp server since you have Undionly.kpxe define and not all lower case undionly.kpxe)Then you have the troubling one: 98.0.192.75 (which appears to be a dell computer) is also responding with a next server of itself with no boot file name, but it does have dhcp option 60 set indicating its a proxy dhcp server (where your error message on port 4011 is coming from).
To fix shoot 98.0.192.75 and pxe booting will start working better. Understand this is not a FOG problem but a networking infrastructure issue.
-
RE: Multiple MAC in Pending mac list
Are these windows 10 clients? If so Win 10 has a “feature” to enable dynamic mac addresses. This is done for security ( ?? ) reasons. The pending macs view are for fog client detected mac address. Where the fog client reports in to the fog server the mac addresses it detects on its network interfaces. I use a Linux Mint computer at the moment so I can’t direct you to the exact location of this switch in the Win10 gui, but it should be around the network settings.
-
RE: Replication: Only working on 1/5 nodes
@jflippen The last I knew the entire content of the /image/drivers directory is replicated. I do have to say we don’t change drivers much and something may have change since all of the drivers are on all storage nodes at the moment. I’ll have to confirm it still works as I thought.
both the image as well as the snapin replicator should use the lftp command defined in this file
fog/lib/service/fogservice.class.php
Double checking I don’t see any other instance of lftp.
-
RE: FOG Interface Completely Unresponsive
@joe-gill Ah OK, when you get back to it, we may need to up the memory settings in php-fpm since the php.ini settings are ignored by php-fpm. Understand we are still tuning the php-fpm settings. We need real world feedback to get the most appropriate settings for everyone.
-
RE: Replication: Only working on 1/5 nodes
@jflippen Each fog server has a local user account called
fog
with its own password. Have you tried to log into the remote fog server using the appropriate linux userfog
password as defined in the storage node configuration for that storage node and done by ftp?I know that was a mouth full, but the basic premise is to ftp to the remote storage node using the appropriate
fog
account. Change to the /images directory and ensure that you canput
anddelete
files over ftp. -
RE: fogcontroller.class.php on line 260 : Allowed memory size of 3145728000 bytes exhausted
@quazz said in fogcontroller.class.php on line 260 : Allowed memory size of 3145728000 bytes exhausted:
you are running a reverse proxy Nginx
If I had to guess (unless the OP is doing something strange) that ngix might be the FOG servers. I believe that is where the FOG management gui reaches out to the FOG Project servers to get the information, both on the login and configuration pages.
The memory exhaustion issue could be php-fpm but that issue should have been fixed with FOG 1.5.4. We can test if it is php-fpm by turning it off in the configuration file to see if the memory error is coming from there. I can see issue #1 could be related to the tighter (more exact) restrictions on php code than apache php.
-
RE: How to check if I actually moved my /images/ directory to secondary HDD
@howtogravity OK to test if your updates are correct. Please post the output of these commands.
sudo lsblk
and
sudo df -h
The first command shows the block devices (i.e. storage devices) that your fog server knows about.
The second command shows how your storage devices are connected.
-
RE: Issues with Fog 1.5.2
@k-hays said in Issues with Fog 1.5.2:
. would 90 be a stretch?
Don’t do that much you could run into a situation of resource exhaustion. Under normal imaging you shouldn’t see more than 10 worker thread. For max children I would set it to 40.
If you are using FOG 1.5.2 or later here is what I would change in the www.conf file for php-fpm.
php_admin_value[memory_limit] = 256M pm.max_requests = 2000 pm.max_children = 40 pm.min_spare_servers = 6 pm.start_servers = 5
Update those settings then restart php-fpm.
Queue up your multicast then on the fog server linux console start
top
then pressP
to sort by CPU usage. Watch, you should have 5-7 php-fpm worker threads running, they should be the top cpu users. -
RE: Issues with Fog 1.5.2
@k-hays Between FOG 1.5.0 and 1.5.1 (or 1.5.1 and 1.5.2 sorry I can’t remember) the developers switched from using the built in php engine in apache to using a dedicated php engine (php-fpm). This was done to address an issue with GUI slowness reported with the new 1.5.x Web GUI on certain distributions. Baseline testing then showed an excellent improvement in GUI responsiveness as well as client check ins were not causing an issue with heavy web server load as they were before.
After 1.5.2 was released the developers started seeing other reports of issues with multicasting and unicasting in larger environment that wasn’t see during development. So certain tweaks to the php-fpm config files were made in 1.5.3 and 1.5.4. Increasing the memory limit even more to 256MB resolved a multicasting issue was discovered after 1.5.4. was released. That setting will be in 1.5.5 when its released in a few months. With these new settings you should see a pretty stable multicasting deployment.
-
RE: Date off in dashboard #253 - Github
I wonder if its related to a php time being off. Since you are PDT, I might have expected it to be a day ahead not behind if php is using UTC time.
Is the system timezone set correctly?
Do you have the timezone set correctly inside the fog gui (FOG Settings)? -
RE: No image file(s) found
Lets collect a bit more information here.
- What version of FOG are you using?
- You captured an image from a reference computer, what hardware was that reference image created on?
- Is the hardware you are deploying that image to the same as the source computer?
- Did you capture the image as single disk resizable?
- Is the target hardware running in the same mode as the source computer (i.e. bios and bios, or uefi and uefi?)
-
RE: Booting WinePE on uefi system
Something you might consider.
login kernel nfs://10.100.0.55/winimgs/iso/Winpe/wimboot gui iseq ${platform} pcbios && goto mem_bios || goto no_mem :mem_bios initrd -n bootmgr.exe nfs://10.100.0.55/winimgs/iso/Winpe/bootmgr.exe bootmgr.exe goto mem_cont :no_mem initrd -n bootx64.efi nfs://10.100.0.55/winimgs/iso/Winpe/bootx64.efi bootx64.efi :mem_cont initrd -n bcd nfs://10.100.0.55/winimgs/iso/Winpe/BCD bcd ...
Also realize that
${fog-ip}
is a variable that expands out to the IP address of your fog server. If you use the variable it makes your pxe menus portable between FOG servers. -
RE: Date off in dashboard #253 - Github
@mparlette Ok you have a few things to work on.
First I would set your system timezone correctly (not UTC). Understand this is the linux timezone setting of your linux distro. Once that is set, then in the fog gui under Fog Settings->Fog Configuration expand all menus and search for
time
make sure that is right. Once all are set correctly reboot the fog server. From then on your times should be correct. -
RE: Date off in dashboard #253 - Github
@mparlette said in Date off in dashboard #253 - Github:
CentOS 7 w/ FOG 1.5.4
/etc/php.ini date.timezone entry was commented out.
corrected with:
date.timezone =“America/Vancouver”Technically that may not help you. In a normal world it would. But in FOG’s case its using php-fpm which has its own opinion of things and if you have php 7.x installed then the /etc/php.ini file is typically not referenced since php 7 has this file in a different path.
But having the OS and fog menus in agreement should get you to where you want to be. So good job!!
-
RE: Slow Fog 1.5.X WebUI due to Storage Node
Why did you install fog 1.5.1 instead of 1.5.4?
I can say I think there is an issue with Debian 9.4 installer for FOG that does not create the config file properly for php-fpm. If this is the case you will have a very slow UI in 1.5.2 and later version of FOG.
There is a quick test to see if php-fpm is configured correctly. Open a linux console and run
top
then pressP
to sort by CPU usage. You should have php-fpm at the top of the processes. There should be 3 or 4 instances running. If apache is at the top then php-fpm is not configured correctly on your FOG server.There are a few tweaks needed to FOG 1.5.4 that was discovered after 1.5.4 was released. Once we are sure that php-fpm is running then we can look at those settings.
-
RE: Replication problems 1.5.4 - always copying
@jflippen Just as an idea (first let me say I’m not a programmer), if you look about in the code where you can find an example of the replication agent writing to a log file. Clone that and place it in the correct location in the code to write both md5 hash codes into the log. Once the fog server has restarted then it should log that information into the replicator log file. I’ve had to do somethings similar in the past to reverse engineer some of the magic Tom does with his code.