Topics created by DBCountMan

@george1421 Thanks! I wonder if a chat bot could help with reading through what worked and make a tutorial.

@Tom-Elliott said in Hide/Secure FOG Client download page:

Private key is built to the client at install time. The Public server ca cert is pulled at install time

This is what I was unclear about. I thought the installer already had FOG’s private key. So each client gets its own private key?

@DBCountMan In the post init or post install scripts the $mac variable contains the mac address of the target computer

To get the ip address this script will work

myip=`ip route get 8.8.8.8 | awk 'NR==1 {print $NF}' | cut -d "." -f1-2`;

Getting the user id of who did it will be a bit harder since they never log into the web ui. The user ID and password they key in during the deploy image stays in ipxe and is not sent onto FOS Linux. I’d like to say that the username field can be trapped from iPXE and then pass that variable as a kernel parameter onto fos linux. Once that is done then the $username variable should exist in your fog scripts. Getting that info into the fog database is another challenge. In the post install script the /ntfs directory is mapped over to the fog servers /images/dev where you could append an echo statement into a text file.

Understand I’m taking in programming pseudo code. But I see an path here and it should work.

@DBCountMan From my memory, yes, that is correct.

@Sebastian-Roth I know nothing about API’s so I wouldn’t know where to start with that, like even how to form a proper question to ask the google lol. I’m using FOG 1.5.10. I have to keep testing and troubleshooting the image cron jobs.

@DBCountMan I suggest to verify the checksum (sha256 file on github). If the checksum is wrong, then re-download init.xz. But if it’s right then try another init.xz version, e.g. https://github.com/FOGProject/fos/releases/download/1.5.10/init.xz

@george1421 That would be the next step. When I said “replicate” I meant that I have a cron sync from primary to secondary every night, not instantly. So lets say I set up both servers to accept ipxe req’s and a field tech loads a new image on the primary at 10am and wants to deploy them to 20 PCs in the field. Primary FOG server takes a dump. The secondary FOG server won’t have the image until midnight. So there’s one issue. Unless I set cron to sync every hour or 30min. Another issue I found with rsync as much as I love it, is that if the primary server goes offline, the secondary, which has the /images nfs share from FOG1 mounted, will appear empty, and rsync will sync an empty dir to its own /images, thus wiping out that folder. I read that rsync can be tuned to not sync if a directory is empty but I have to research and test.

@DBCountMan said in Snap-in: Run a powershell script prior to capture:

I have no experience with snapins and was wondering how can I use them to run a powershell script before rebooting to capture. I have a script that clears the Windows logs and in that script (right now) at the very end shuts the computer down, preparing it for manual capture. I have the FOG client installed on my test system.

:EDIT: Sorry I think I figured it out.

Might as well think out loud in case anyone else can use this info. I got the snapin to run my clearalllogs.ps1 script, now the next challenge is to have the script run then immediately after it reboots, start the capture.

Run a PowerShell script prior to capture is a handy feature that allows you to automate tasks and streamline your workflow. Great addition to the toolset

@george1421 I see the set fog-ip variable and set storage-ip variable. Could I set those two variables with IPs of different interfaces? So for example, the interface IP server ipxe will be the “set fog-ip” and the interface IP serving NFS will be the “set storage-ip” var. Would that work?

since you mentioned that you do not want to partition the volume, an alternative approach could involve creating a disk quota at the operating system level. Disk quotas are a feature provided by the operating system (in this case, the Hyper-V host) that allows you to set limits on the amount of disk space a specific user or group can consume.
Set up the network share on the Hyper-V host where you will store the FOG images. Ensure the share is accessible from the FOG VM. Inside the FOG VM, mount the network share to the /images directory, which is where FOG stores the images. You can do this using the mount command or by adding an entry in /etc/fstab for persistent mounting. Configure disk quotas on the Hyper-V host for the user or group associated with the FOG VM. Set the quota limit to the desired amount of disk space you want FOG to use for images.
Keep in mind that disk quotas are managed at the operating system level and are not specific to FOG. Therefore, this method will not provide real-time monitoring of disk usage within the FOG web interface. You will need to monitor the disk space usage separately on the Hyper-V host.

@Sebastian-Roth Challenge accepted!😁

@Milheiro Zstd level is compression level right? That I’m aware of. Makes sense if you increase compression that it would take longer to capture/deploy. What I was experiencing was linux kernel level errors, only when deploying to a virtual disk that resides on the xenserver’s local storage array. I wonder if it is something like Truenas where it performs worse when you let the storage controller handle the array vs a soft-raid controlled by the OS.

@brakcounty said in ipxe boot slow after changing to HTTPS:

Even when using the Paravirtualized Network Adapter in VBox?

Learning something new every day! Wow, didn’t know this and never tried it before. Thanks!!!

@george1421 I tried entering a hostname after the prefix was appended, for example I entered “TestVM” thinking the full registered hostname would be “NCIT-TestVM”, but the device was registered as “TestVM”.

@george1421 said in Does LDAPS work during iPXE menu login?: mcdvoice

@brakcounty The code support switching to ldaps by adjusting the port number, I suspect that bit won’t work as advertised. I don’t think that element was ever tested. The reason why I say that is to make it work it needs an LDAP certificate installed.

Good one. Thanks for sharing a nice piece of info.

Just for reference as the link did not get pasted…
https://forums.fogproject.org/topic/14621/ldap-with-access-control-default-role-assignment-at-first-login

In case anyone else has this question, the Reports tab serves this purpose. Once an AD user logs into FOG and starts doing things, the history report will log it.