@benjamind @george1421
I’m using a master and nodes configuration with a lot of multihomed locations (140 as goal) with between 2 and 9 VLANS for node.
I solve this problem for my custom config with the procedure that i wrote on this link https://forums.fogproject.org/topic/13387/unable-to-change-multicast-nic/14 maybe it helps you.
It works for me, but i’m using a custom multihomed nodes installation with a beta customized location plugin to do all tasks locally on the VLAN.
I use custom modifications because if i try the next procedure i can get more than 350 locations/nodes.
Using that procedure as basis i think:
If you have a single multihomed master without nodes, maybe you can try to configure a StorageGroup for each VLAN, a StorageNode for each NIC and, using this data, a location for each VLAN and then configure pc’s on his VLAN location.
"TAKE A LOT OF CARE ON DISABLE REPLICATION!!!."
If you need the Image replication service you can use a false user/password pair to avoid it or try to don’t assign images/snapins to that StorageGroups.
Reason to think that. MulticastManager also use management node ip to select the multicast iface. I think that I saw this on my experiments. Maybe @Sebastian-Roth can confirm it.
Try it at your own risk.
Plz wrote the test results.
@Quazz said in HP Probook x360 11 G1 EE Unable to Image:
This particular model seems to be bad news in Linux environments in general.
People having trouble installing Linux on it, getting it to boot, etc
To me this sounds pretty clear. We might still try to help getting this fixed but it won’t be easy I suppose. It’s not something FOG is doing wrong but HP decided to release a device that seems to be Linux unfriendly.
What I’d suggest is you download different kinds of Linux live CD ISOs and try booting those one after the other to see if any is able to boot up and run this hardware without issue. Ubuntu Live, Knoppix, Kanotix, CentOS live, openSUSE, SystemRescueCD, …
@ians said in Fog Client fails to join AD Domain with error 1326:
I hadn’t even thought of the possibility that it could be the special characters in the password. I went ahead and created a new domain admin account and used only letters and it worked!
Ohhh, do we actually have a special character issue?!
Updating the settings on my groups also updated the settings on my hosts, yay!
So this sounds like you were able to get things right and domain join on the client worked? Shall we mark this solved?
About the group settings you want to use the forum search and ask it for “persistent groups”. My guess is that you are expecting something from FOG’s group capabilities that it doesn’t have.
@ckasdf said in Errors in Apache log and www-error.log:
Perhaps those are less errors, and more just warnings?
Abdolutely but it’s still imporant to get rid of those to not cause any confusion when we tell people to consult the logs when looking for an error.
Is LDAP login possible with the current build?
While I have not tested it myself in our test environment lately I am fairly sure it does work. I remember others posting questions on this in the forums and did succeed.
If so, I’ll open a new post requesting help with that.
Probably not too bad of an idea. Doesn’t cost much extra and it’s good to keep things sorted a bit so people find answers more easily themselves.
Just a quick hint: Are you able to connect to your LDAP using the same credentials in a tool like ldapbrowser?
@bogle The FOG server talks to the target computer via the FOG Client/service. That service has a check in interval that is set in the fog settings. So the default may be 5 minutes (300 seconds), so if you issue a task to the target computer it could take up to 5 minutes before the target system reacts.
Also on the fog up/down indicator it doesn’t use a ping, but a connect to port 445 to confirm the system is up or not. If your windows firewall is blocking connections to port 445 then fog will assume its down.
