@george1421
Thank you so much !
It works well !
Have a good day.

Thanks all. You are right. LDAP uses plain text password. I had ‘&’ symbol in the password and that breaks it. I set up a test RHEL server and was able to make it work by removing ‘&’ symbol. My “controlled” server however is till not working. No error in /var/log/php-fpm/www-error.log. Apache detected when I tried to login. Re-installing -php-ldap but no go. Does anyone know how to debug it? Thanks!

@george1421 said in Where are the general iPXE settings?:

and that should pull the file from the tftpboot directory. But then you will need to have a mac address file for each system. But then what happens if you don’t have a mac address file the boot fails.

in this case, you could just end the chain command with || and it would try the next available command, which can be booting to the fog server

@lebrun78 said in Need advice for network configuration:

Which architecture do you recommend?

That depends on the network components you have. What kind of router do you have? If possible I’d put the 500 educational hosts and the FOG server on the same switch/branch of your network. Don’t run it through your backbone if you can avoid it. Leaning towards setup one (above picture).

On the other hand I am not sure I understand why you’d make things more complicated by running the FOG server dual homed. Why not just have the FOG server in the educational hosts network segment and allow HTTP/HTTPS web access from the admin PCs to the FOG server across your router.

@Sebastian-Roth

ok

@Sebastian-Roth said in FOG client with dual boot image:

@EduardoTSeoane Ok, seems like I got a bit confused about the custom install path. Now I got it. Opened an issue on github for this so we won’t loose it: https://github.com/FOGProject/fog-client/issues/117

Hehe, that has name, is too much work…, I was thinking that it was a problem with our Windows Customizations, I had no time to investigate it.

Typically a post install script relies on the image being on the computer because the post install script would interact with the image once its downloaded to the disk.

With that said I can give you some tips to make debugging a bit easier.

Schedule your deployment task, but before you hit the submit button tick the debug checkbox. PXE boot the target computer. After a few screens of text that needs to be cleared with the enter key you will be dropped to a linux command prompt.
These next to steps are optional Get the IP address of the target computer using ip addr show Set root’s password with passwd give it a simple password like hello. Don’t worry it will be reset the system is rebooted. Now use putty and connect to the target computer using the information from steps 3 and 4. Using putty you will be able to cut/copy/paste a bit easier than using the FOS Linux console. But these 3 steps are up to you
The rest of the steps work both from the putty shell as well as the console shell. Start the deployment process from the command prompt by keying in fog. You will now single step through the imaging process pressing enter at the each debugPause command. You can insert the debugPause command into your post install script to stop the deployment at critical points. Pressing enter will continue the script until the next debugPause breakpoint.

Hints:

Add liberal echo commands to indicate the start, execution of critical points and exit of your post install script. If something goes wrong, pressing ctrl-c will exit out of the deployment script at the point where you hit ctrl-c. If you are linux savvy you can navigate to where the postinstall script is and rerun just that script after you fix what needs fixing. (I don’t know the path off the top of my head, sorry) You can start the deployment process over again without needing to reboot by just keying in fog again at the command prompt.

If you are interacting with windows, I have some post install scripts with examplesin the tutorial forum. While they are windows focused they should show you some trick you could implement in your scripts.

Personally I would install a second nic on the fog server. Have a dedicated imaging network and then a business network management interface. This is a normal configuration for FOG. Your FOG server will supply dhcp for the imaging network only.

You can change the IP address after FOG is install, but its a bit of a pain. All you need to install FOG cleanly with dual network interfaces is to know the interface name of the imaging network and to have your business network nic to be able to get to the internet directly or via a proxy server.

@Jack252 Do you have different IP address subnet in the isolated network??

You cannot simply change to a different subnet. There are a couple of things you need to do: https://wiki.fogproject.org/wiki/index.php/Change_FOG_Server_IP_Address

I’m not fully sure how to implement proper login checking. This is a feature that is kind of in flux. When initially coding the ipxe stuff, there was a lot of ties in to protect things that were “natural” to the main menu. However, this made making password protected items less possible because there isn’t a nice easy api in ipxe to call back and check “login” against a url.

The current password protected items have 2 different elements. The first is to pass the login stuff to the second element, and that second element cross checks login capability and passes through if all passes properly. It’s because of this double step that currently custom pxe items can’t just have a password protection nicely integrated. It would need a secondary element tied in to the main boot code. This could be done with hooks I’m sure, but it’s still fairly complicated. The simplest methods would be to do as you did (use ESC to force all menu items to be login protected) or use the advanced menu with login enabled.

@spooninbrian said in HTTPS FOG GUI webpage:

Im using ubuntu

Then just don’t say yes when asked if it should re-install Apache and PHP right at the beginning of the installer. You should be save then.

@george1421 Thanks!

@george1421 Wonderous. I did use the ipxe change like you suggested and it worked. I’ll hammer out the dnsmasq and see about gettin that working at a later time.

Thanks so much. Love this software and the people who help support it.

@jhumpf There is no resolution to this. UEFI captured images can only function on uefi based computers. The same is true for BIOS captured images they can only function on bios based systems. The hardware is interfaced differerntly between the two. Most will just create two images, one for BIOS and one for UEFI systems which is MUCH cleaner and a MS supported solution.

I’m having a similar issue… What’s the best manner to turn on DCHP on my fog server after i’ve already installed it?

Thanks again for your help. I will research more what the System User can do. It looks like I am out of luck to do things that require elevated permissions (such as enabling Bitlocker) using a SnapIn. I think I will start to evaluate other ways to do post-provisioning scripts/tasks.

@tomhtil said in Storage node behind NAT:

@Sebastian-Roth is there an easy way to sync the database as well? I’d be happy with multi master setup if i could sync the images folder and the relevant config for just the images.

Galera

@Sebastian-Roth Thank you for your help, sorry for the late reply was very busy in the last weeks.
I managed it with turning on/off the no menu option.

@jtappen From what you wrote it seems like you are on the right track with this - Active Directory Defaults in the FOG settings should be the was to go.

So which way do you actually register your clients?

Our Fog is on versoin 1.5.6

This is not the latest version. I cannot say for sure we have found und fixed in the latest but if we find this to be a bug I need you to update to the very latest version.

@ibivibiv Ok I was correct! I think maybe there is a more clever way to update the grub directory contents (grub update command etc.) but basically if I do the following I find myself with a fairly close to working system:

dd the MBR file to /dev/sda sfdisk the partitions to /dev/sda partclone restore d1p1.img to /dev/sda1 Take the grub contents from the original machine and overwrite them onto sda1 partclone restore d1p6.img to /dev/sda6 mkswap to /dev/sda5 with the uuid from the orig uuid file

This drops me into the grub menu and after the timeout it boots as normal.

Not too bad, and hopefully it helps anybody else that asks this question. I saw it gets brought up sometimes.