Topics created by rhythmtone

Great, thanks again. I saw an older thread about automatically associating the pending MACs with a host, so you don’t have to open each host and click + to add the wireless MAC.

Is that actually possible and/or could you point me in the right direction? Because it seems like it would be a time-saver…

Thanks,
D.L.

Hi,
Upgrading to 2074 fixed it, thank you for your assistance, and for the link!

Now I can and will check the SVN’s and code/bug history before posting anything, which is great.

FOG FTW!

Thank you again,
D.L.

Just saw that this was fixed in SVN, etc.

My bad, I need to read more of the development threads…

Thanks,
D.L.

Okay, I did something dumb, but learned something new…

In XUbuntu the password for the actual Linux user fog does not create/synchronize - This can be found under Storage Management, Default Member, Management Password - this should be the actual GUI login password for user fog in the Linux OS.

This password is randomly generated, and inserted in this field, and can be used to log in as user fog, although I’ve almost never need to do that. Instead of just changing the Linux login password to the randomly generated password found on the Web UI, Storage Management, Default Member, Management Password (which would have been smarter) I just changed this field to a common administrator password. I then made this common administrator password the actual login password for user fog on the Linux installation, and this issue is solved…

Just thought that I would post what happened,
D.L.

I probably should have described it better, but it sits at the “Starting to restore image screen” and the multicast task never actually begins, as described in this thread :
[url]http://fogproject.org/forum/threads/fog-1-1-0-multicast-sits-at-starting-to-restore-image-to-device-dev-sda1.10782/page-2#post-31993[/url]

Also (or as a result of this) in /opt/fog/log FOG version 1.1.2 does not create the multicast.udpcast.1.log (approximate file name) file, nor does it create any entries in the multicast.log file. Since I was confused by this I pulled up an old .32 installation - in .32 it has the same behavior, however it does make entries in the multicast.log to at least let you know what is going on:

[07-01-14 9:54:10 am] * Starting FOG Multicast Manager Service
[07-01-14 9:54:15 am] * [07-01-14 9:54:15 am] Checking for new tasks every 10 seconds.
[07-01-14 9:54:15 am] * [07-01-14 9:54:15 am] Starting service loop.
[07-01-14 9:54:15 am] | [07-01-14 9:54:15 am] Failed to connect to database server, will try again in next iteration.
[07-01-14 9:54:25 am] | [07-01-14 9:54:25 am] Failed to connect to database server, will try again in next iteration.
[07-01-14 9:54:35 am] | [07-01-14 9:54:35 am] Failed to connect to database server, will try again in next iteration.

And yeah, on one test installation I did create a password for the root user. I’ve checked in Config.class.php in /var/www/html/fog/lib/fog and it is correct and I’ve also verified it by running mysql -u root -p and entering the correct password. This test installation will not multicast, and gets stuck as described above. On another test installation I used all of the same settings, and I did not enter a SQL password on installation - this box will start multicast tasks…

Thanks Tom, you’re the man,
D.L.

That’s a bit of a shame because it was neat to have it at your fingertips, ready to go on any machine, without having to install anything. But I also understand the downside of having to support it, code it into the web UI, etc.

Thanks for the help and for the information,
D.L.

Hi,
Apparently a “no password” setting does fix this issue across the board, reliably, every time.

I would much rather have a password in my situation, that is my goal.

The strangest thing is how it happens randomly - my new FOG installations have been fine being up all weekend, but I’m guessing that sometime this week it will happen again…

Thanks for any help and/or advice,
D.L.

You do not need to install the new client, I just wanted to know which one you were having issues with so I could better help troubleshoot it for you.

It sounds like you fixed it though.

The MySQL Issues could play into account as much of the data Polled comes out of the database. So it’s not too surprising to see the issue. This may also explain why a reinstall seems to help fix some of the issues. Not a complete reinstall from scratch, just simply rerunning the installer in place.

If you need help, Convo me (not everybody all at once), but I can try to assist and direct where you may need it.