@cmurray139 Just to add a bit more information. default.ipxe -> http://x.x.x.x/fog/service/ipxe/boot.php

But I guess you will run into another issue as the FOS Linux system is another environment that you’d need to use the fake MAC address…

Nevertheless it’s an interesting idea. Please give it a try and see how far you get. Let us know what you find out and if we can help you with anything.

@Quazz Thanks for the help. I really appreciate.

Thank you all for your responses. Thye have been very useful.
I’ve been able to do it using a real machine. It was indeed a Virtualbox problem.

The only time you will impact current systems in production is if your current environment relies on dhcp next-server (option 66) or boot-file (option 67) or uses ProxyDHCP (udp port 4011) to communicate configuration files to your booting devices (such as a voip phone needing to find the pbx system to get its configuration file). If a booting device never attempts to get booting information from dhcp then there is no impact.

Having FOG and either Microsoft’s WDS or SCCM on the same network will cause conflicts.

@george1421 I forgot to mention that in my notes. I will fix that. Changing fetch=tftp://${fog-ip}/gparted/filesystem.squashfs to fetch=tftp://<fog_server_ip>/gparted/filesystem.squashfs worked just fine and booted properly.

@LindsayS said in AD Join:

it would auto-encrypt the password

Have you used the old legacy client before? With the new fog-client we don’t do the password encryption anymore.

@Miodog Please let us know if we can improve the Multicast address thing within FOG even more. We are open for any kind of suggestion on this.

@Alois Please try the following commands:

sudo su - apt-get install php7.2-mysql phpenmod mysqli systemctl restart apache2 systemctl restart php7.2-fpm

@JB2019 please paste the contents of your install log. it should be located, from the base directory of the install files, in /bin/error_logs/foginstall.log

Another solution is to have a fog snapin schedule a PDQ Deploy package or packages. That snapin would run at the end of the deployment process to trigger PDQ Deploy to push out what ever is in the package group. You would also setup PDQ Deploy for on demand application pushes. This method will require the paid for version of PDQ Deploy but the paid for version is well worth the price because of the additional features you get over the free version.

@processor said:

Hi Sebastien, I just did the test again and put the new ini files create the FTP error and put back the original 1.5.5 ini file correct it.

So are you saying that using the 1.5.6 inits is causing the FTP issue but using the 1.5.5 inits you don’t get the FTP error but the UUID issue?!??!

Well we changed the FTP username from fog to fogproject from 1.5.5 to 1.5.6 but that is not hardcoded in the inits and shouldn’t cause this issue I think. You might still try updating to 1.5.6 to see if that fixes the problem.

@Sebastian-Roth Thank you very much. It worked. Now everything is ok.

@Pi0tR Nice find! It’s interesting it states “Invalid TCP packet for current connection state” as this is the first packet (only SYN flag) of a TCP three way handshake and therefore surely the connection does not exist yet.

@ianabc Had a bit more time to look into this now. You have missed one important point here. You need to manually create a new TaskType (web UI -> main menu -> TaskTypes -> Create New Task Type) and name that trusty-install - exactly the name of the task that is used in lib/hooks/boottask.hook.php (line 73). As soon as you’ve created this task type you should see it in Host -> Basic Tasks (or Host -> Basic Tasks -> Advanced Tasks if you’ve checked the “Is Advanced” checkbox when creating it!).

Now you can schedule this task type for any client or group and when it boots up it uses the arguments you set in lib/hooks/boottask.hook.php (line 83 to 93). But only if the names match. So if you name your new task bababoo you need to have that in your lib/hooks/boottask.hook.php line 73 as well.

@Pi0tR Lets start a new thread since your issues are different at this point. New topic - new problem.

@Miodog This is for 1.5.5 version.
But you can do a workaround:

go to FOG_DIRECTORY/lib/plugin/ldap/hooks Do a copy of ldappluginhook.hook.php #cp ldappluginhook.hook.php ldappluginhook.hook.php.ori Lets go to edit one line of the code: # vim ldappluginhook.hook.php /** * Sets our user type to filter from user list * * @param mixed $arguments the item to adjust * * @return void */ public function setTypeFilter($arguments) { $arguments['types'] = array(990,991); } Change the line: $arguments['types'] = array(990,991);

To:

$arguments['types'] = array(991);

With this change you can see the local users and LDAP admin users

@george1421 Nice work George!!

@barachd Have you read my post about there being a bug within the Linux client implementation. See further down in this topic.

I guess what do you mean nothing happens?

Do you see it transfer vmlinuz ?
Is vmlinuz in /tftpboot/os/lubuntu directory?

If the menu is executing correctly it should transfer both vmlinuz and initrd.lz. It might not boot, but it should transfer the files.

If the menu is not executing at all, did you remember to fill out the description field in the ipxe menu config for that ipxe entry?

Thanks All!..

Solution has worked perfectly!