@marted Looking good.

May also want to check to see if the computer object already exists in AD. If the account does exist, the join account also needs the ability to modify that account either by virtue of being the creator/owner or by having the permission to modify computer objects in the target OU.

@Sebastian-Roth Yeah, this isn’t something readily available in the code.

@endia If you’re at least semi familiar with code, you might look into /var/www/fog/lib/fog/bootmenu.class.php

This isn’t currently coded for, but you might even be able to do what you want using a simple (relatively speaking) hook to alter the boot menu system.

There’s a template hook already created that should help get you started. By creating a hook, you aren’t altering the core code within FOG. Hooks are meant as a means to inject custom data specifically around what you’re requesting to happen.

The hook that’s setup is located in /var/www/fog/lib/hooks/bootitem.hook.php

Ultimately what you would do is make your changes and set the active flag to true. (it’s a variable named active)

@babouche said in Client Host not showing after 2nd restart:

It’s only when i manually ping from my server to the client that i can see my firewall deny the ping.

Ping (ICMP protocol) is handled different by a firewall than TCP connections are. Ping being denied might be a hint on other protocols also being restricted but doesn’t give you a definitive answer on that question.

@NateUH Yes it is supposed to auto-start on bootup of your FOG server.

Please run

systemctl is-enabled FOGMulticastManager.service

to see if it’s enabled on bootup. If you get disabled there must have been an issue when running the installer. You might run

systemctl enable FOGMulticastManager.service

or re-run the installer to do this for you.

But if it’s enabled already then you might be running into a startup dependency issue in FOG 1.5.7 which we have fixed lately. Ask here if you need more details on this.

@Tom-Elliott

Nice, it is working now.

There was a slight blip where it got stuck at

Downloading kernel, init and fog-client binaries…

So I ‘quit’ the install removed user fogproject and ran the install again.

I was able to update the database schema, continue the install and login.

New interface looks slick!

@justeverything Do you have the working version of this?

@zuf76 Yes, take a look at the so called “Service Settings” tab within the host’s view. As well there is a global service setting in FOG Configuration -> FOG Settings -> FOG Client - … sections.

@xfz said in Endless reboots:

The snapin does not even require reboot.

While I am not exactly sure I would think that this is not caused by a snapin task.

Yeah, unfortunately i deleted the task already. It was the group deploy thing.

And does machineB still reboot in an endless loop? Probably not or do I get this the wrong way?

@fry_p said in About image acquisition error.:

Sunucudaki “fogproject” kullanıcı hesabının parolasını değiştirdiniz mi? Bu hesap yalnızca FOG için bir hizmet hesabı olarak kullanılır ve sis yönetiminde kullanılmaz. Bunu yaptıysanız, aşağıdaki yerlerde şifreleri eşleştirmeniz gerekir:
Web Interface -> Storage Management -> [Your storage node] -> Management Username & Management Password

Web Interface -> FOG Configuration -> FOG Settings -> TFTP Server -> FOG_TFTP_FTP_USERNAME & FOG_TFTP_FTP_PASSWORD

The local ‘fogproject’ user’s password on the Linux FOG server

Server file: /opt/fog/.fogsettings -> password

Sunucudaki hizmet hesabı parolasını (fogproject) değiştirdiyseniz bunu düzeltmenin en kolay yolu, bunu yaparak Ubuntu’daki bu parolayı diğer konumlarla eşleştirmektir.
sudo -i
passwd fogproject

Yeni bir şifre girmeniz istenir. Lütfen başka bir yerde şifreyle eşleştiğinden emin olun.

@fry_p

Finally happened 🙂 . Thank you very much for the quick answer.

Latest inits should have all the fixes included. Marking as solved.

Marking as fixed as we have this added to dev-branch and it will be in the next release.

@Demache Nice we found this and you were able to fix it so quickly. When looking through the code I thought about HTTP/HTTPS possibly being an issue but dropped that idea. Now looking at it again I think you have found a bug in the code! Just pushed a fix.

Though I still really wonder why the backup logic of checking size via FTP didn’t work in your case either.

I appreciate the quick reply Tom. I was just curious if there was already a quick check box to turn this off or not. I think I will hold off on it and just let my team know they need to be sure to approve hosts after installing the client. I appreciate your insight and look forward to a possible feature addition in the future!

Marking as solved as we haven’t heard back since one week.

Oh yes, that is most likely what it is. It is when you click the wrench at the top right in the web interface.

FOG Version Information
404 Not Found

@george1421
I try it to install several times but i have same issue with missing files(i try github version too).I also try re run install on existing FOG server but same results .Can you please advise most stable or more less problematic linux distribution ?Fog-install.txt

Thanks all. It makes sense why it was happening now.

@Quazz

Yes, it was a legacy 10 install that was converted to EFI.

@jhumpf All I can say is that based on the two to three years of using that configuration for different fog admins, we haven’t needed to deviate from that configuration since dnsmasq is not giving out dhcp addresses the mask “should be” irrelevant. The remote subnets should just work as long as dnsmasq is being informed of them requesting a dhcp address.

If you want to debug deeper into the matter, I would suggest that you reset the configuration back to what I have in the article then follow this procedure to see if we can capture a bad remote proxydhcp request and then capture a good remote proxydhcp request so we can compare. There also may be some value in taking a computer on the remote “bad” subnet and loading wireshark on it. Start the capture filter of port “67 or port 68”. That would capture what the dhcp and dnsmasq are sending to the target computer, from the target computer’s point of view. https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

Upload those 3 captures to a share file site and share them as public. Either DM me directly or post the links here and I will review them.

My gut feeling is that you have something not configured right in your infrastructure not related to FOG or dnsmasq.

@hj104 said in Scheduled Tasks (Delayed / Cron-style) not working, but instant tasks are.:

My only question now is whether restarting the server has the same effect on the FOGScheduler service as running systemctl restart FOGScheduler?

I am pretty much sure this can be answered with yes. Sorry but I have no idea why this was wrong in the first place but working now. Seems like you have not changed anything.