@george1421 Nice idea you’ve come up with! Should be fairly straight forward and robust to implement.
@typotony Now it’s your turn to come up with a solution that works in your environment. You are welcome to share it as well with the community: https://github.com/FOGProject/fog-community-scripts/
@typotony Probably a good idea to not export the whole DB but just the images table (mysqldump -u fogmaster -p fog images > images.sql). Though you need to make sure the IDs of the images do not diverge. For example, if you create new images on the other two servers manually (not via the import) and assign those to hosts it will break as soon as you import the mysql dump which essentially wipes the whole images table and re-creates it.
Surely one can come up with some kind of “check and merge” instead of the DROP/CREATE/INSERT done by a plain mysql export/import but it would take a fair amount of coding skill to make this fail proof I reckon.
@phonebread Just pushed a fix to dev-branch. Please update.
@abulhol said in Does FOG check free disk space before starting capture?:
That’s nice - but as far as I understand, it still doesn’t protect against the new image needing 10GB, but there are only 9GB left.
Right?
Yes, right, it doesn’t protect from that. We discussed different “solutions” and thought we should better keep it simple. If you are keen you can still jump in and add a more thorough check - estimating how much size the new image will need. While it is possible to do it’s not that easy because images are being compressed and other variables can vary as well.
@nkduy1508 You can either use Greasemonkey or other plugins to hide the IDs.
Or you can manually edit the PHP code (/var/www/fog/lib/pages/imagemanagementpage.class.php on your local filesystem) to remove the ID. Though the later will be gone when you update your FOG install.
@dyacishyn said in Unable to access FOG management web site:
Should the fog installation be in the /root directory?
No, can be pretty much anywhere, except not in /var/www and some other uncommon places.
Some people have it in /opt others in /root or /home…
Did the mentioned commands fix the issue for you?
@brakcounty said in ipxe boot slow after changing to HTTPS:
Did the -s switch during setup automatically compile all those efi binaries and place them into /tftproot?
Yes.
@phonebread This is a known issue in the latest dev-branch version and will be fixed soon.
@typotony Uhh, I somehow forgot about the third option, which would be scripting the import via mysql.
How do the people in the other offices tranfer the image files to those FOG servers? Using WinSCP or something similar? Or did you script the download of images from the cloud storage?
In any case you should be able to automate the import via mysql. Maybe a script can check if a SQL dump file exists in a certain place every minute and if it does than do the import and rename/delete the import.sql.
Let us know if you need further help with this.
@typotony said in Copy Cloud Storage of /images to Remote Servers Globally:
Is there a way to have images that are copied to /images automatically be imported so we don’t have to run the manual process myself of exporting and importing CSVs?
No, there is no auto detection of images within FOG. You can either do the simple CSV export/import thing or go the manual route - create the image definitions on the other nodes and make sure they match exactly the ones you have on your other server. I’d definitely use CSV. If you transfer the extra large image files around the world. What keeps you from generating the CSV and importing it to the other servers?
@brakcounty Ok, from the tests we have done so far it kind of looks like this is going to be an iPXE network driver issue. Interesting I have not thought of this before.
Have you tried different iPXE binaries yet? ipxe.efi vs. snponly.efi? ipxe.pxe vs. undionly.kkpxe?
@rodluz Thanks for testing and reporting back! I would still want to find out if this is caused by a change in the FOG code or the different MySQL version. Could you please do me a favor and update your Ubuntu 20.04.1 - FOG 1.5.9 - MySQL 10.3.34 setup to the latest dev-branch (which does not have the fix included yet)?
We’ll be waiting for George as well to comment on the pull request before merging it.
@mikmatcr If this only ever happens on multicast deploys we should start looking at those logs I reckon. Please upload all the log files you find in /var/log/fog/ that have multicast in their filename.
Though I am not much optimistic we’ll find the issue in multicasting. I say this because in the pictures we see errors at various points in the deployment process. That points to hardware issues on those machines I would guess. Maybe dying hard drives or memory or whatever.
@JJ-Fullmer Ok, lets get into this. First of all I have to say you have build a great tool chain around FOG. Amazing! Well done.
Sounds really strange from what you describe so far. I have never heard from environment and bash in general acting differently on Surface Go 1 or being hardware specific at all.
Could it be something you do even earlier in the process (bootup) that could be specific to the Surface Go 1?
From what you posted I do see environment variables I have never heard of before: $domainJoinStr, $unattend and many more. So I guess you have a modified fog/service/ipxe/boot.php (actually bootmenu.class.php) file, right?
Let’s start by looking at the different kernel cmdline. Boot up a system not showing the issue, run cat /proc/cmdline and post output here. Then do the same thing in a debug session on the Surface Go 1.
@abulhol This is really weird. I just cannot replicate the issue for the heck of it.
but it doesn’t find php this way, probably because at this point a full shell isn’t available yet (?).
Probably right. Looks like environment.d is systemd’s part to generate the environment. I am trying to figure out how to analyze this. So I am just throwing a few commands at you and we’ll see what we find. Please run the same commands on your system and compare the outputs:
root@ubuntu2204-fog:~# systemd-analyze critical-chain
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.
graphical.target @19.463s
└─multi-user.target @19.460s
└─FOGSnapinReplicator.service @19.447s
└─mariadb.service @17.581s +1.755s
└─basic.target @17.468s
└─sockets.target @17.468s
└─snapd.socket @17.428s +33ms
└─sysinit.target @17.397s
└─cloud-init.service @16.654s +738ms
└─systemd-networkd-wait-online.service @3.060s +13.592s
└─systemd-networkd.service @2.966s +92ms
└─network-pre.target @2.960s
└─cloud-init-local.service @1.075s +1.883s
└─systemd-remount-fs.service @952ms +99ms
└─systemd-journald.socket @658ms
└─system.slice @615ms
└─-.slice @615ms
root@ubuntu2204-fog:~# systemd-analyze blame | head
13.592s systemd-networkd-wait-online.service
2.483s dev-sda2.device
1.883s cloud-init-local.service
1.778s cloud-config.service
1.755s mariadb.service
1.029s cloud-final.service
879ms networkd-dispatcher.service
874ms snapd.service
791ms php8.1-fpm.service
777ms systemd-random-seed.service
root@ubuntu2204-fog:~# systemd-analyze plot >systemd-plot.svg
Now copy that SVG file to another system where you have a UI and open it (e.g. using the Linux tool eog - here is how mine looks like (not the whole lot because that’s too big to upload here):
root@ubuntu2204-fog:~# systemd-analyze dot 'FOG*' |dot -Tsvg > systemd-dot.svg
root@ubuntu2204-fog:~# ls -al $(which php)
lrwxrwxrwx 1 root root 21 Feb 22 13:24 /usr/bin/php -> /etc/alternatives/php
root@ubuntu2204-fog:~# ls -al /etc/alternatives/php
lrwxrwxrwx 1 root root 20 Feb 22 13:26 /etc/alternatives/php -> /usr/bin/php.default
root@ubuntu2204-fog:~# ls -al /usr/bin/php.default
lrwxrwxrwx 1 root root 6 Jan 28 2022 /usr/bin/php.default -> php8.1
root@ubuntu2204-fog:~# ls -al /usr/bin/php8.1
-rwxr-xr-x 1 root root 5531064 Jan 16 15:19 /usr/bin/php8.1
@abulhol Thanks to @rodluz the new FOS inits will check server disk space: https://github.com/FOGProject/fos/pull/67
@RTOadmin said in Booting Grub witch SPINWAI ERROR: AFECAL for cor 2 failurd:
wlc_phy_radio2069_afecal: SPINWALIT EROOR: AFECAL for core 2 failed
This error does not seem to be very common. The only relevant information I find on the web is this log file: https://www.tonymacx86.com/attachments/2019-04-05_00-07-04-979981-airportbrcm4360_logs-001-txt.397495/
This does not look like a Linux kernel error message but something generated by macOS itself. Can you please take a picture or video of the error message on screen so we get an idea of the context?
@rodluz Good news. Found the time to look into this already and I might have it fixed as well. Before I commit the changes I would like to ask George to take a look as well as a sanity check. This is the first time I have played with this plugin and MySQL triggers in general…
I was able to get some more information on why it failed by trying to insert the group membership association by hand:
mysql> INSERT INTO `groupMembers` (`gmHostID`,`gmGroupID`) VALUES ('4','2') ON DUPLICATE KEY UPDATE `gmHostID`=VALUES(`gmHostID`),`gmGroupID`=VALUES(`gmGroupID`);
ERROR 1364 (HY000): Field 'paAnon5' doesn't have a default value
Proposed change on github: https://github.com/FOGProject/fogproject/pull/546/files (some comments added for clarification)
@george1421 May I ask you to comment on that?
Interestingly enough I am still not sure what change is caused the issue! Could be the MySQL version but I rather think it’s the change to InnoDB we made with FOG 1.5.9.133 (commit 7330fbc4).
I think it’s worth figuring out to make sure the proposed fix is not breaking other setups!! Anyone keen to figure that out?
@Jordane said in ERROR: Could not get security token:
Indeed, in the local security strategy of our clients, the FIPS encryption is activated.
But also the option, Configure the types of encryption allowed for Kerberos “AES256 and future”.
These are the options that would block me?
Probably yes. And I really do understand your organization is forcing FIPS compliance.
AES is not compatible with FOG services?
Well, AES is actually a subset of the Rijndael implementation used in the fog-client. So it’s pretty close. I guess we can switch to using AES as I said before but not in a quick move! Needs code changes and testing.
I was going to open an issue report on github to keep track of this but turns out this has been around since a long time already as well as another forum topic (sounds like the fix isn’t that easy…)
Is it possible to disable encryption from fog and the TOKEN function?
No, not right now. One of my future plans was to remove the self made encryption from the fog-client/forproject code but switch to using HTTPS (enforced). This way we’d rely on state of the art crypto done by webservers and system crypto libraries. But that is even further away than switching to AES.
Ideally, it should communicate with clients without encryption.
I don’t get this. Why would you enforce FIPS compliance but then let the communication go unencrypted?!?!? Just doesn’t make sense to me.
@mikmatcr Please do not double post on the same issue!!
https://forums.fogproject.org/topic/16589/pc-crashes-after-a-few-minutes-using-multicast
Topic locked.