@NoIPName Can you get to https://192.168.1.1/fog in a web browser without any cert is bad prompts?
Because pxe wants to use the ip address in the url you have to have the ip address san in the certificate that your fog web server is using.
That cert for the web server needs to be from the custom ca.
That public cert can also affect client communication if you change it in the default path from fog install.
@bwilli78 I would try ipxe.efi instead of snponly.efi for testing the pxe boot file route. .kpxe and .kkpxe boot files are for legacy systems that don’t support UEFI. However it sounds like you’re getting to the fog pxe boot menu so that’s an unlikely culprit.
Where in the process are you getting the kernel panic?
Are you queueing the imaging before hand or are you queuing it in the fog boot menu?
The general process is
Where in this general overview are you seeing this error?
@lperoma What do you get running mariadb -V
@iljared98 I don’t suppose you’d be willing to share more on this config? What specific rights you gave the service account, did you have to do this whole thing https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1 related to this whole thing https://support.microsoft.com/en-us/topic/kb5020276-netjoin-domain-join-hardening-changes-2b65a0f3-1f4c-42ef-ac0f-1caaf421baf8 ?
I’ve previously attempted to create a standard user with such permissions, but I hadn’t tried a service account, that’s a grand idea. I would love to document the creation of a least privilege service account for fog domain operations.
@Quintin-Giesbrecht It’s been a while since I’ve had to mess with it, if memory serves it may show in the output of the imaging itself. You might need to do a deploy in debug mode on a fast/normal speed machine and then a slow one and compare what you see.
You may also find some logs in the log viewer of fog within the fog configuration page. Where the logs are on the server depend on your fog version and your OS version.
Like for me on Rocky 9 with Fog 1.6 and using apache with php 8 the log with the most information is /var/log/php-fpm/www-error.log but I don’t believe kernel level stuff will output there.
@Laurent https://docs.fogproject.org/en/latest/installation/server/install-fog-server/#choosing-a-fog-version
Essentially, instead of checking out the stable branch and doing a git pull and running the installer, you check-out the working-1.6 branch, do a git pull and run the installer.
It’s still in “beta” but I believe we’re very close to releasing it as the new stable version.
It’s a whole new ui it’s pretty great. Lots of feature and security enhancement in the backend, faster search results in a universal search tool, cool stuff like that.
@Quintin-Giesbrecht I think there’s potential for a solution for it but it’s tricky to nail down. I imagine you’ve also tested machines that go faster on the same ethernet cable and port? It’s very odd that it would capture fast but not deploy fast. What level of compression are you using on the image? iirc when uploading the image, compression happens on the fog server, when deploying the image decompression happens on the client. So if your compression is too high, it could cause this behavior but it would be more wide spread.
You could play with making a custom kernel (see https://docs.fogproject.org/en/latest/compile-fos-kernel) adding different driver options that might relate, but since the network is already being recognized I’m not sure that would make a difference. It could also be a storage level issue rather than network which could also be something in the kernel.
You can also adjust the kernel log level settings to be higher and you’ll get more output that might point to a different problem.
Also be sure your bios is up to date and navigate through the bios settings for anything that seems like it could relate.
There’s also playing with the different pxe boot files (i.e. ipxe.efi vs snponly.efi) this shouldn’t really make a difference once you’re in part clone and imaging, but I figure it’s worth testing all parts of the process when you’re not sure where the problem lies.
I would also check the fog server dashboard, specifically the bandwidth reports and see if there are lots of dropped packets, perhaps there’s a different network configuration needed for this model?
@Laurent said in Problem with FOG Service …:
I use an encrypted password because I don’t want other fog users to see my password in plain text
I would recommend using a separate domain admin account rather than any 1 user’s domain account. Partly because of the issue you describe (though that’s not something that can be seen in the web gui) but also so that it’s a password that won’t expire with a user leaving and it’s a password that can be rotated without affecting other services.
Just my 2 cents.
@sideone Are you getting different IP addresses in the snapin download url and the communication url? i.e. is the communication URL going to your master and the download going to a storage node? Maybe a storage node has something goofy in its storage node config?
The communication url is derived from the c:\program files (X86)\Fog\settings.json file where it uses the Https flag, server name, and webroot values to construct that base url i.e. http://10.xx.xx.xx/fog
I’m not sure if the download url is combo of the settings.json file with info from the server or if it’s just from the server or what. But your download url is missing the http/https and is also has an extra slash.
P.S. you don’t really need to hide the ip of the fog server. It’s an internal subnet only ip address, it doesn’t expose anything to say what ip you’re using. Do whatever makes you feel safe, just saying is all.
@sideone So the taskid increment is normal, that’s the id of that specific task.
I just tested a snapin on my server which is on the same version of 1.6.0 and didn’t have the issue. But I did notice something glaring
17/10/2024 08:41:58 Middleware::Communication Download: ://10.xx.xx.xx//fog/service/snapins.file.php?mac=0C:9D:92:C9:DE:33|0C:9D:92:C9:DE:32&taskid=1700
The download url is missing http or https
So we need to work out why that’s happening.
@sideone Is this happening on all snapins or just this one?
Any errors around the same time in /var/log/php-fpm/www-error.log ?
Can we see a screenshot of this snapins config in the gui? Maybe there’s something there.
The taskid bit is odd
@LiamRetrams I recently published a function related to this in my FogApi Powershell module (see my signature)
I posted an example of using it in a snapin to change a host’s boot order to pxe boot as the first boot option
https://forums.fogproject.org/topic/16784/powershell-snapin-no-output-non-error?_=1729112272355
as @george1421 stated this is a windows issue, part of the oobe process involves changing the boot order. But you can utilize bcdedit to fix it. I’ve made an attempt at creating a universal option with my Set-WinToBootToPxe function, It works for me on some Asus motherboard based systems, I’d be very interested to hear if it works on custom Gigabyte builds as well.
See also
Glad to hear it’s working for capture now. You should be able to mount /images on a separate disk without issue, but having it all in the same place is fine too.
I’m not 100% sure what that error is saying. At least not with enough detail to be helpful right off the bat.
First thing that comes to mind is a sector mismatch. If your image was captured from a disk with 512e sectors and you try to deploy to a 4kn disk (or vice versa) you’ll get errors when it tries to align the partition table because the sector sizes can’t align. It’s a limitation in disk alignment at a lower hardware level. I have some notes on when I was debugging such an issue in this post https://forums.fogproject.org/topic/17112/surface-go-4-incompatible
It could also be a simpler issue of the image doesn’t fit on the new disk. In most cases the resizable takes care of it, but if the image’s min size is bigger than the disk, not much can be done. But it looks like it’s an all disk or all partition image?
@danieln said in Using Snap Ins to run scripts post imaging...?:
@JJ-Fullmer Thanks for the reply! This is helpful.
I feel like maybe the best way to go about it is to assign the Snap In to each host. Just to confirm, this will deploy the Snap In after each time that host is image, regardless of which image it receives?
Yes that is correct, unless you specify otherwise (I think that’s really only available in the api though) the standard operation is to queue all assigned snapins to deploy after an image task
I’m also thinking of separating my inventory into FOG Groups by computer model and then assigning the Image Associated with it and Snap Ins at the group level.
Is this QC check also installing and or checking drivers? You could also use postdownload scripts to install drivers and have just 1 image that is universal and the drivers are injected and installed during sysprep specialize phase. Takes some setting up but works very well, see https://docs.fogproject.org/en/latest/kb/how-tos/post-download-scripts/?h=post
Also, if you wanted to create groups based on the model in the FOG Inventory you could build that out pretty quickly with my FogApi powershell module ( see my signature)
Something like this would get you a list of all unique model names you have in fog, this example uses is for 1.6 but should also work in 1.5.10.x
It also doesn’t include the initial api connection bits.
#get all your fog hosts with full details
$allhosts = Get-FogHosts | % { (Get-foghost -hostID $_.id -ea 0)}
#get the sysproduct field from the inventory of each host, and get the unique entries only
$uniqueModelNames = ($allhosts).inventory.sysproduct | sort-object -Unique
#list the model names in the shell
$uniqueModelNames
There may be some additional filtering to do here depending on your inventory (like HP sometimes has slight differentiations of a model) but if that list is what you want your groups to be
$uniqueModelNames | Foreach-object {
$jsonObj = @{
name = $_;
description = "Computers that are of the model $($_)"
}
#I have a pending issue for creating a simple New-FogGroup function
new-fogobject -type object -coreObject group -jsonData ($jsonObj | convertto-json)
}
Then you’d set the membership of the matching hosts
#loop through the model names you created groups of by name
$uniqueModelNames | Foreach-object {
#get the group name and the matching group object
$groupname = $_;
$group = get-FogGroupByName -name $groupName;
#find any host that is the given model and loop through them
$allhosts | Where-object { $_.inventory.sysproduct -eq $groupName;} | Foreach-Object {
#set the group association/membership required fields
$jsonGroupData = @{
groupID = $group.id
hostID = $_.id
}
#create the group membership association
New-FogObject -type object -coreObject groupassociation -jsonData ($jsonGroupData | convertto-json) -ea 0;
}
}
Then you can go in the Fog web gui and assign hosts to each image. This can also be done in the api, but I just don’t have time to work out an example for that.
Also note that groups are not persistent config containers. Group membership sticks around, but it’s meant to be used as a bulk setter. If you set an image in a host it will set it on all the hosts in the group. But if you go change the image on 1 host in the group, it doesn’t auto change back, nor does it auto set when you add it to a group. There is a plugin that changes this behavior called persistent groups, but using it as a bulk setting and as a simple container/organizer of hosts is usually sufficient as you get into things more and more.
@MatMurdock This could be implemented via a plugin where you build a db trigger and an imagesnapinassociation that assigns snapins assigned to an image to any host with that image. It could be done. I don’t think it would be added to the default config.
Granted, you could create a postdownload script that assigns and deploys snapins via the api based on what image was used.
When I configured the snapin with my example script that installs the FogApi Module and runs the universal command with the snapin setup with “powershell x64” like this
The snapin worked as expected and the host boots to pxe. I only tested this snapin method on a VM so far but I imagine it will work beyond that.
I’m just going to put these right here
https://fogapi.readthedocs.io/en/latest/commands/Set-WinToBootToPxe/
https://github.com/darksidemilk/FogApi/blob/master/FogApi/Public/Set-WinToBootToPxe.ps1
Not an answer to the snapin issue with bcdedit, but I have published a powershell function within the FogApi module for managing the bcdedit commands and setting a host to boot ot pxe.
I did just test it as a snapin with a simple script like this:
#registery the psgallery repository and trust it
Register-PSRepository -Default -ea 0;
Set-PSRepository -Name PSGallery -InstallationPolicy Trusted;
#install the fogapi module from the gallery
install-module fogapi -Repository PSGallery -ea 0 -Confirm:$false -Force -Scope AllUsers;
#run command to set pxe boot
Set-WinToBootToPxe;
But when run as a snapin it still isn’t working, run manually on a machine it does work.
I’m not sure yet why the command run in the context of a snapin doesn’t work.
@danieln I don’t know of a way to default assign a snapin to every new host that is built-in to fog.
However, if a snapin is assigned to a host the deployment of said snapins is automatic when you deploy an image.
Here’s a few ways you could make it close to or completely automatic on all new/existing hosts.
If you wanted to bake it into the image you would just have it as part of your setupcomplete.cmd or unattend.xml firstlogoncommands.
@Jim-Graczyk I agree with you and I actually ran into similar issues in my migration and I’m still working out what is the best approach for migrating without losing client connections.
I took notes on my internal migration that I hope to utilize in creating a new doc for migrating a server without losing the client connection, but I also hope to make the PKI/Certs of fog more flexible in general, it’s just a matter of finding the time to work on it.
If you want to help in creating such a doc in the new docs site (see also https://github.com/FOGProject/fog-docs/tree/master) that would be very welcome.
I’d love to build a script for migrating, or include it as an option in the installer, but scaling that to support all supported linux distros and standard supported configurations would take some serious work that I don’t realistically have time to do.
By the by, if the Powershell commands worked, that is something that can be scaled in most windows environments and could be deployed as a group policy script or you can use Powershell methods such as Invoke-Command to run it remotely on all machines.
@Jim-Graczyk said in What Prevents a FOG Client from Connecting to A FOG Server?:
I DID run into 1.5.10.xxx when downloading FOG, somehow. I used the “master” branch in git for my installs. I follow what I believe are FOG wiki pages that contain specific instructions.
Recently, as in back in like June of this year, we started doing more frequent releases and created a ‘stable’ branch. There were some security issues reported in 1.5.10 but the changes made didn’t fully justify a 1.5.11 release in our versioning schema. So we created a flow for more frequent releases, it’s described here https://github.com/FOGProject/fogproject/tree/stable?tab=readme-ov-file#versioning-and-branches
We’ve built out a CI/CD automated release workflow to do monthly releases so that new minor features, bug fixes, and security fixes are released to users more frequently.
The ‘stable’ branch is now the default branch which should be installed from. The wiki is being slowly migrated over to a new docs site and the latest install doc is found here: https://docs.fogproject.org/en/latest/install-fog-server
Also yes, changing the ip address typically does involve a recommendation for updating the certs because the ip address is including in the public cert’s san. If you can re-use the same IP and have used that alias in the public cert, then you should be able to migrate without needing to re-install clients.