[QUOTE]This isn’t highly documented as it’s relatively new. In an attempt to allow legacy and new client’s to operate with a single version of FOG, I created a Field for the New Client (FOG_AD_DEFAULT_PASSWORD) and the legacy client (FOG_AD_DEFAULT_PASSWORD_LEGACY).[/QUOTE]
Perfect explanation - I ran into this issue today, wasn’t aware of the new legacy field. All is working fine now.
[QUOTE]Update to SVN 3281 and this should be fixed for you.[/QUOTE]
Yep, looks good.
Found a little quirk in SVN 3275. When I boot to fog and choose full registration and do a question mark to get the image list, the list is all over the place. It used to be formatted in a nice column and press enter to go to the next page.
Hmm, that’s a possibility. I’ll keep that in mind for the summer when we go touch every station.
Ha. I’d love to. Long explanation there though, totally unrelated to fog. We have teachers who use netop vision to wake up their computer labs in the morning. They complained about the extra time the pxe boot added to startup. I know, all of 15 seconds at most, but that’s a battle I wasn’t willing to fight. So 90% of our labs are set to boot right to the hard disk when they get the magic packet.
[QUOTE=Wayne Workman]I remember another thread about making tasks have a TTL sort of feature… Has that been implemented? If the default TTL is maybe 24 hours, then this guy wouldn’t have had the multicast issues the next day… it’d just resolve itself because the old tasks would get deleted.[/QUOTE]
I like this idea. Usually when I’m imaging, I start the task and go PXE boot the machine(s) within a few minutes - maybe an hour or 2 at most. Maybe there could be a custom TTL for users who would want a longer timeframe?
Ahh it was the leftover tasking that was holding me back. It’s working now and I’m currently watching 4 machines being multicasted to. Thanks again everyone.
Ahh sorry, I wasn’t quite clear.
It is not working. When I click multicast for a group, I see the tasks for the individual machines show up under active tasks. But nothing appears under Active Multicast Tasks.
Hmm, we’re getting closer. I only get the second error now:
[Mon Apr 20 11:11:44 2015] [error] [client 10.162.3.26] PHP Warning: Invalid argument supplied for foreach() in /var/www/fog/lib/fog/Host.class.php on line 978, referer: [url]http://10.162.1.212/fog/management/index.php?node=group&sub=deploy&id=84&type=8[/url]
Edit: Sorry, still getting both errors. I had my log scrolled down too far to see the first ones.
I’ve got something else weird going on now. I’m on SVN 3275 and when I try to multicast to a group, I see these errors in apache:
[Mon Apr 20 10:48:27 2015] [error] [client 10.162.3.26] PHP Warning: in_array() expects parameter 2 to be array, null given in /var/www/fog/lib/pages/TaskManagementPage.class.php on line 344, referer: [url]http://10.162.1.212/fog/management/index.php?node=tasks&sub=listgroups[/url]
[Mon Apr 20 10:48:27 2015] [error] [client 10.162.3.26] PHP Warning: Invalid argument supplied for foreach() in /var/www/fog/lib/fog/Host.class.php on line 978, referer: [url]http://10.162.1.212/fog/management/index.php?node=tasks&sub=listgroups[/url]
This is an issue that seems to be related just to my installation of fog and our database, as it works correctly on a fresh install of the SVN. I’m not sure what I should be asking now: Is there a way to check for invalid data, or what would be a good troubleshooting step? At this point I don’t think multicasting itself is the issue (again, because it works on a fresh install)
Nice, thanks! I didn’t know that setting existed. Everything loads okay now.
Looks like it might have something to do with our large database, specifically. I tried 3275 on our testing server and it works fine.
I updated to SVN 3275 and am getting memory errors on several pages. Right now I’m trying to add hosts to a group, but when I click the group name from the list I get a blank page in the browser and this error in apache:
[Mon Apr 20 09:08:28 2015] [error] [client 10.162.3.26] PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 81 bytes) in /var/www/fog/lib/fog/FOGController.class.php on line 344, referer: [url]http://10.162.1.212/fog/management/index.php?node=group&sub=list[/url]
Our server has 8gb memory and the memory limit in php.ini is set to 8192M, in both the apache2 and cli folders.
Alrighty. I’m on SVN 3264. I just set up a new server today to test with as I don’t want to mess around with our production server. The images are in partclone format. They were uploaded to our main server running fog 1.2.0, then I just copied the files over to the new one.
I typed that command on the server, and then typed this into the clients:
udp-receiver --portbase 9000 --mcast-rdv-address 10.162.70.30 | partimage -f3 -b restore /dev/sda stdin
I did find that odd though - I know unzipping happens on the client but it’s a bit confusing as to why the gunzip command goes to the server?
If the portbase is likely incorrect, what do you suggest changing it to?
I’m back on the hunt for a solution to multicasting. The last time I really looked into this was last summer and I gave up, but now our imaging projects are coming up again.
First things first: I’m currently testing on a new install of Ubuntu 12.04 and using the latest fog SVN 3264. The problem I’m seeing is clients get to the please wait screen and then never go past that.
I’m working through this wiki: [url]http://fogproject.org/wiki/index.php?title=Troubleshooting_a_multicast[/url]
Testing 1 client is successful
Testing 2 clients is successful
Under something else to try, that fails and I see this on the server:
root@fogtesting:~/svn/trunk/bin# gunzip -c “/images/U160SGEJuly2014” | /usr/local/sbin/udp-sender --min-receivers 2 --portbase 9000 --interface eth0 --half-duplex --ttl 32
Udp-sender 20120424
Using mcast address 234.162.70.30
UDP sender for (stdin) at 10.162.70.30 on eth0
Broadcasting control to 224.0.0.1
New connection from 10.162.3.33 (#0) 00000009
Ready. Press any key to start sending data.
New connection from 10.162.3.38 (#1) 00000009
Ready. Press any key to start sending data.
Starting transfer: 00000009
Timeout notAnswered=[0,1] notReady=[0,1] nrAns=0 nrRead=0 nrPart=2 avg=8362
Timeout notAnswered=[0,1] notReady=[0,1] nrAns=0 nrRead=0 nrPart=2 avg=8362
It looks like the clients are communicating with the server but the data just doesn’t send correctly. I’d like to think multicasting is configured correctly on our network because we have other multicast applications working properly.
Thoughts?
In the Config.class.php file, there’s a section not too far from the top of the file that starts with “private static function db_settings()”.
Database_host should most likely be ‘localhost’ unless you have your database stored somewhere else
Database_name should be fog
Database_username and Database_password should be an account with access to the fog database. I’ve changed my username/password so I can’t tell you for sure what the default is
Hi cassie,
The fix for me worked on Fog 1.1.2 on Ubuntu 12.04.
For the mysql part, the file I changed is at /etc/mysql/my.cnf Find the line that says bind-address = 127.0.0.1 and put a # in front to comment it out. Save the file and do a “service mysql restart” to reload the configuration.
Then in the fog config files, I edited /var/www/fog/lib/fog/Config.class.php and had to enter the correct mysql connection info in the db_settings function.