@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.

@Sebastian-Roth Unfortunately the USB external drive wasn’t see by FOG, I tried the serial number listed in Windows but it backed up an NVMe drive Please disregard

@lostitguy We you will need to make up your own fog ipxe menu to specifically call the wipe function.

I am not 100% sure I have the stanza right but it should look like this

Menu Item: fog.wipeit
Description: FOG builtin Disk Eraser Tool
Parameters:
kernel tftp://${fog-ip}/bzImage
initrd tftp://${fog-ip}/init.xz
imagargs bzImage initrd=init.xz root=/dev/ram0 rw ramdisk_size=256000 ip=dhcp web=${fog-ip}/fog/ consoleblank=0 loglevel=4 mode=wipe wipemode=full
imgfetch init.xz
boot ||
goto MENU
Menu Show with: All Hosts

If you ALWAYS want to wipe before a deploy in one step that is also possible but you will need to “hack” the fog deploy script to include the shred command. That is a bit more complicated than creating a fog ipxe menu, but modifying the fog deploy script is not that difficult either. There are just more steps involved.

@buddyaderholt I don’t see how this is directly related. Please remove the link you posted or we will do so unless you can explain the context of how this fits into the picture.

@banaunnuh said in FOG With more than 1 subnet:

used the TFTP get command for my main FOG server and got the same error when I try to boot with the 172 clients. The file does not come, it gives a timeout error

Can you ping the fog server IP address from the 172 subnet?
Is there some kind of screening/firewall between the 200 and 172 subnets? The tftp protocol uses UDP port 69 NOTE: If you test tftp pull between a windows computer on 172 and the fog server on 200 you need to temporarily disable the windows firewall on the test computer because tftp, is like FTP in that it opens a command channel and a data channel for communications.

@lostitguy not in the way you’re thinking but yes kind of.

Essentially it rewrites the partition tables (which effectively wipes the drive completely). Once the partition table is written it then block by block writes the image to the disk.

@Martin-IT-Systems said in Where do I find the file undionly.kpxe and default.ipxe:

Now to my question: on Github FOG Project / Backet someone has set under tftp a lot of ipxe so also the undionly.kpxe file. Can I use this or where do I get this so I can copy this into /tftpboot?

Sure you can manually download the files. BUT the files not being in /tftpboot might be a hint that the FOG installer never finished all the way to the end. I suggest you re-run the installer, carefully read what you see on screen, follow it’s instructions and it should take care of everything for you.

And where do I get the default.ipxe file or should I do it myself according to the instructions in FOG Wiki?

Same answer. The installer will create it when it runs all the way to the end.

Would there also have to be a dnamasq integrated into the network?

You can manually setup dnsmasq in your network if you think you need a DHCP Proxy. The FOG installer does not so this for you.

@Sebastian-Roth
Thanks, looks promising.
Will set up a test.

@gandzioreek said in Boot Porteus Kiosk iso from fog pxe menu:

I tried, didn’t worked

What didn’t work? What did you see?

While this thread is 2 years old, I just looked at the Porteus Kiosk iso image again, and it looks pretty much the same, so the menu settings I recommended previously should still work.

If it wasn’t for the details most things would work right out of the box.

@sega Yes, though I think it’s specific to the multicast sessions bandwidth capability and limited at the storage node level (if my memory serves correctly)

@Sebastian-Roth Thanks Sabastian.

@typotony That’s Great to hear!
Glad you got it working and that it was as easy as intended.

@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 Thanks Guyz !!

@plegrand Correct

@rizingknight72 You ahve to create an image definition and assign it to the host.

Zero touch just means that the image you’re using doesn’t require the machine to be touched after imaging.

Please review the FOG Documents as this is one of the first things discussed when dealing with FOG.

@brent I don’t recommend this solution.

But I did test something similar many years ago: https://forums.fogproject.org/topic/6941/windows-server-as-fog-storage-node-proof-of-concept-blog

There is also this method: https://forums.fogproject.org/topic/9430/synology-nas-as-fog-storage-node

Another choice is to create an iscsi target and connect the fog server to that iscsi target to the /images directory on the fog server.

But FOG Project only supports using a linux computer with the FOG Storage node configured loaded as valid.

@tom-elliott Many thanks!! I used now the internal ip address of the AD server … This was the whole problem.
A vaild domain name here did not work.

Normally this AD server is reachable with this fqdn YYYY.XXXX.com (it’s not the real domain). I can’t type public this domain here for security reasons.

I can now login with users from my AD into FOG.

@jmeyer said in How to Use FOG to PXE Boot MultiBoot 2k10 Unofficial:

chain memdisk iso raw

Just adding a bit of a caveat here.

memdisk is a BIOS boot loader only. There is currently not an equivalent function for UEFI based systems.

The iso image you boot from must be less than 2GB in size (remember 32bit address space) AND the booting computer must have at least 2 times the memory of the 2GB iso to function. So in the case of a 2GB ISO image, your computer needs to have 4GB of RAM.

@MasterOfUs Now that I have had a good sleep I figured that proposing to use SSH is just raising the hurdle once more but not solving the concern. Why? Because some kind of secret (probably SSH key) needs to be included in the FOS inits to authenticate when connecting. Even if this is done properly (random generated key pair) we can not prevent an attacker from loading the FOS init manually and extracting the secret, right?

So making it secure would mean the user needs to enter a connect passphrase manually on each deploy/capture.