@sideone So we’re looking into the issue.
I updated the old “legacy” sender method, but I may have forgotten that the file deploy process depends on the same “old” methodology.
I haven’t confirmed (or rather we (@JJ-Fullmer) for sure yet, but now that this is brought up, it’s one thing I have at the forefront of my brainbox. Thank you!
@elchapulin Start your system in normal mode.
Disable fastboot.
Retry the capture.
https://forums.fogproject.org/post/101232
While you’re working on Windows 11, the process should be mostly the same.
@Cire3 Honestly we don’t know.
The information didn’t make sense to any specific “thing” being wrong or what even truly was wrong.
@alexpolytech94
You’re really not clearly defining what issue or issues you’re having?
Your firs tpost you said, “When I create, delete an image on the web interface nothing happen”
Well what do you mean nothing happened? Which happened? You created the image definition? You deleted the image definition? What are you expecting to happen? What happened overnight?
Now you are saying any new actions are not considered? What do you mean? You’re saying nothing makes sense, but not really telling anyone anything.
What does you having “full rights on images folder” have to do with anything UI related?
What “new actions” do you mean exactly. You are saying new “What”? When you do a “new something” what IS happening? What ISn’t happening? You cannot create hosts, images, groups, etc…?
You cannot edit things? I’m really confused what problem you’re thinking “suddenly occurred overnight” because I have NOTHING to work from.
@IT-MAN I don’t follow what you mean?
"Other lines work without the three “pnputil.exe”?
First if the script is exactly as you have defined, then the issue is you don’t have the right information.
You script should look, per the tutorial:
REM INSTALLATION DES DRIVERS
pnputil.exe /add-driver “C:\Drivers\*.inf” /subdirs /install
pnputil.exe /add-driver “C:\Drivers\*.inf” /subdirs /install
pnputil.exe /add-driver “C:\Drivers\*.inf” /subdirs /install
shutdown -t 0 -r
@echo off
That is not what you ahve.
That said, what do you mean the script “runs undefinitely”? I’m guessing (and i realize semantics but just trying to clarify) you mean “indefinitely” but is that really the case?
Installing drivers can take quite some time, so it could be minutes, to hours - generally. So what is your basis of running indefinitely?
If it takes more than 6 hours, I might say you’re seeing things run very slowly.
Now the reason the script pathing is important.
C:\Drivers*.inf is looking for anything called “C:\Drivers<anythinghere>.inf”
Where:
C:\Drivers\<anythinghere>.inf is what I am confident you are meaning. You want to delve into drivers folder and anything that has .inf in there (recursively as necessary)
setupcomplete.cmd only runs after sysprep, so assuming your system is sysprepped, but you’re having to manually enter the options after you deploy the image, I don’t know.
You kind of left off all the details.
@IT-MAN The whole drivers install bit only works with an unattend of Windows.
The setupcomplete.cmd doesn’t “just run” because it exists. It is only used during Windows during OOBE setup and as such your script won’t do anything.
Not sure how you expected it to work?
@xirrax No. You haven’t provided a single bit of information beyond “It’s not working, how do I fix?”
I would say, try a machine that does work? If I seem a bit rude, it’s a little intended. We can’t help with so little to work off of.
Now I’m not just calling you out, I’m trying to ask you to think about how you post so we can try to help you and maybe figure out what is actually wrong, so we can try to help you figure out how to fix, and provide you some experience in learning how to troubleshoot a bit for yourself.
What do I mean?
If I walked into a Mechanic (Walk being the operative word) and said, my car isn’t starting, what’s the solution? They’re going to potentially understand at least I have a car, and that it’s not starting. That’s it.
There’s going to be a ton of questions though. “Does the car turn over? Is there gas in it? Did you lose the keys, has it ever ran? Is this your car? Why do you have thief’s tools?”
Please try to give us something to work with so we can help you.
@george1421 The autoexec.ipxe is from the newer builds of iPXE and is meant for executing things without network access or something like that
This message is perfectly fine and harmless. If it was missing the true embed script we’d not even get the point of it trying to load anything else. Just a heads up.
@alessandro19884 Can you change your bootfile from snponly.efi to ipxe.efi and see if that works better?
This was reported and tested and reported, as well tested the fix by the github username bluetoothStrawberry.
Thank you!
This was reported and tested and reported by the github username philipp-tg.
Thank you!
https://github.com/FOGProject/fogproject/security/advisories/GHSA-3xjr-xf9v-hwjh
This issue after our initial fix we still allowed some insecure locks. This was reported after the root vulnerability was patched. This addressed in dev-branch and working-1.6
Thanks all.
https://github.com/FOGProject/fogproject/security/advisories/GHSA-7h44-6vq6-cq8j
This should contain any relevant information pertaining directly but the TL;DR;
There’s known issues with <1.5.10.34 versions of the export script that allow RCE. This has been patched in 1.5.10.34 and up, and the export.php no longer is present on 1.6
To patch existing versions, use the script in the link or copy this to your fog server and run it:
#!/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
# Quick patch for GHSA-7h44-6vq6-cq8j
# source https://github.com/FOGProject/fogproject (dev-branc)
# based on fix applied to 1.5.10.34
export_hash='ecc84d2ce81f9c3d188758a8ca17519e'
report_hash='eabb801aab46dd25e6e2cb99df50f746'
BASE_INSTALL='/var/www/html/fog'
echo "Initiating patch for advasory GHSA-7h44-6vq6-cq8j"
echo "Testing if system is vulnerable"
# Is the system vulnerable?
curl -s -X POST \
-F 'fogguiuser=fog' \
-F 'nojson=2' \
'http://127.0.0.1/fog/management/export.php?filename=%24%28touch+p.txt%29&type=pdf' &> /dev/null
if [[ ! -f "${BASE_INSTALL}/management/p.txt" ]]; then
echo "system does not look vulnerable! aborting patch"
exit 0
fi
rm -f "${BASE_INSTALL}/management/p.txt"
echo "System is vulnerable! applying patch..."
# Can we reach github ?
ping -c1 raw.githubusercontent.com &> /dev/null
if [[ "${?}" -ne "0" ]]; then
echo "Could not reach github. Aborting"
exit 5
fi
# Can we modify the files ?
if [[ "${UID}" -ne "0" ]]; then
echo "sorry, We need root to make changes under ${BASE_INSTALL}"
exit 1
fi
# Are BASE_INSTALL where we expect ?
if [[ ! -f "${BASE_INSTALL}/management/export.php" ]]; then
echo "Could not find ${BASE_INSTALL}/management/export.php"
echo "Please, check settings manually"
exit 2
fi
# Backup old files.
tar -cvpf /root/fogbkp.tar "${BASE_INSTALL}/management/export.php" \
"${BASE_INSTALL}/lib/fog/reportmaker.class.php" &> /dev/null
if [[ ! -f /root/fogbkp.tar ]]; then
echo "warning could not backup export.php and reportmaker.class.php"
exit 3
fi
echo "Created backups fot export.php and reportmaker.class.php at /root/fogbkp.tar"
echo "Downloading patches and checking file hashes"
# Download patches and check hashsum
curl -s 'https://raw.githubusercontent.com/FOGProject/fogproject/dev-branch/packages/web/management/export.php' -o /root/export.php
curl -s 'https://raw.githubusercontent.com/FOGProject/fogproject/dev-branch/packages/web/lib/fog/reportmaker.class.php' -o /root/reportmaker.class.php
if [[ "$(md5sum /root/export.php|awk '{print $1}')" != "${export_hash}" ]]; then
echo "export.php was modified! This patch is no longer up to date. Please, update to latest stable release."
exit 4
fi
if [[ "$(md5sum /root/reportmaker.class.php|awk '{print $1}')" != "${report_hash}" ]]; then
echo "reportmaker.class.php was modified! This patch is no longer up to date. Please, update to latest stable release."
exit 4
fi
echo "Fixing file permissions"
# Adjusting File permissions
chown www-data:www-data "${BASE_INSTALL}/management/export.php"
chown www-data:www-data "${BASE_INSTALL}/lib/fog/reportmaker.class.php"
chmod 0644 "${BASE_INSTALL}/management/export.php"
chmod 0644 "${BASE_INSTALL}/lib/fog/reportmaker.class.php"
# Copy patches to destination
cp -p /root/export.php "${BASE_INSTALL}/management/export.php" && \
rm -f /root/export.php
cp -p /root/reportmaker.class.php "${BASE_INSTALL}/lib/fog/reportmaker.class.php" && \
rm -f /root/reportmaker.class.php
# Cleaning up stuff we no longer need
rm -f /root/export.php
rm -f /root/reportmaker.class.php
echo "We have finished patching fog!"
@Tauric I don’t think any amount of rollback is necessary, but you’re more than welcome to. Pretty sure there weren’t any schema updates or major component changes between 1.5.10 and 1.5.10.34
that said, this looks more like a problem with the kernel, not a problem with FOG and its ability to capture/deploy images.
You could download the kernels from the FOG GUI Kernel Updates
@Tauric When you say “newest version” what exactly do you mean?
Dev-branch latest version is 1.5.10.34
Working-1.6 latest version is 1.6.0-alpha.1357
Master latest version is 1.5.10
Master is “oldest” in the tree as it was last updated in 2023 sometime.
That all said, it seems to me, based on this:
https://bugzilla.kernel.org/show_bug.cgi?id=204887
Maybe the drive is suspending which is causing issues.
I believe you’d want acpi turned off for this to image successfully? (I’m just taking a WAG at this point though (Wild A$$ Guess - 
)
@kylian001 https://forums.rockylinux.org/t/php-ssh2-install/6923
Seems you might have success if you install libssh2-devel?
@kylian001 I am running blind it seems, but I don’t know what OS you’re running, or the version of PHP your FOG instance is using.
If you state yoru PHP version is 7.2, then the php72-php-pecl-ssh2 installation should’ve worked, but I’m unsure why you have so many options.
What I see when I run:
sudo dnf search php-pecl-ssh2
[sudo] password for telliott:
Last metadata expiration check: 0:04:44 ago on Tue 09 Jul 2024 04:26:54 AM CDT.
==================================================================================================== Name Exactly Matched: php-pecl-ssh2 =====================================================================================================
php-pecl-ssh2.x86_64 : Bindings for the libssh2 library
I’m running Fedora 40 at this point.
I know at least one other person is using CentOS 7 and didn’t have issues. Pretty sure the other system is using CentOS 9 Stream and similar success.
@kylian001 You will need to add:
php-pecl-ssh2 to our /opt/fog/.fogsettings packages= line.
Please do so and re-run the installer.
Or you can just add it to the packages line, but also just run:
sudo dnf -y install php-pecl-ssh2 and you should be able to restart php-fpm: systemctl restart php-fpm
This might help things.