Posts made by rhythmtone

Just saw that this was fixed in SVN, etc.

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

Thanks,
D.L.

Hi all,
In FOG 1.1.2 when I go to [url]http://fogserver/fog/client[/url] it just gives me a blank splash page with the FOG logo - no download links for the FOG client, FOG prep, etc.

It was working in FOG 1.1.1…

I’m not sure if it’s my installation or my environment, but I just wanted to mention this. I’ve tried it in IE, Chrome, Firefox all with the same results. If there is something that I can do to test or fix this, let me know.

Thanks to the FOG development team for all of their work,
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.

Hi all,
I have seen other threads related to this issue, but those are not this exact situation… so I hope that it is okay to start a new one.

When re-building FOG boxes, migrated images will not deploy. I’ve re-built a FOG box from Ubuntu -> XUbuntu and copied the images over manually, but when you try to deploy it says:

Failed to create deployment tasks for the following Hosts
To setup download task, you must first upload an image

This must be because this image has never been uploaded to this installation of FOG, but rather manually copied over to the /images directory from an old FOG installation, but I’m wondering if someone has a workaround for this…

Not being able to manually migrate images between FOG installations (without re-uploading) seems like a big issue…

In theory, shouldn’t FOG just check that the image and path exist, and start the task? Why would it require that the image be re-uploaded? It must be checking “Last Uploaded” under the image definition and seeing that it is 0000-00-00 00:00:00 and thinking that the image does not exist…

I’ve checked image name/path/filename, etc. all are correct.

XUbuntu 14.04 x64
FOG 1.1.2

Thanks,
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.

Hi all,
I’m not sure if this warrants a new thread but in FOG 1.1.2 on Ubuntu 14.04 multicast works perfectly with a blank SQL database password, but the task won’t start when there IS a SQL database password. I have entered the password upon installation, verified it, etc…

It is just strange the number of issues that having a SQL database password creates, you would think that it would be possible to actually have one…

Thanks for any input, and thanks to the developers,
D.L.

To add,
If the storage node is the device actually pushing out the image via multicast, then shouldn’t the logs and UDPcast service and testing be done there? The reason that I’m asking is because the storage node(s) do not seem to have anything related to multi-casting, including the absence of FOGMulticastManager as a service…

I am definitely puzzled,
Thanks for reading,
D.L.

I’m also having this issue, and it is really hard to isolate. In my old setup all sites had their own 0.32 FOG Server using Normal installation, and multicast worked great. The catch with this setup was that the images were “per site” as they each had to point to their respective local FOG servers, and also having one SQL database per site was unmanageable and inefficient.

I’m attempting to downgrade / revert for testing purposes but in my new setup each site has a storage node set to “Master” (because only Master nodes can multicast) AND each site’s storage node is its own storage group. I’m not sure if this is the most efficient setup but I need to be sure which node(s) the machines are pulling their images from (at least for now) and if only Master nodes can send multicast traffic, then it follows that each site needs to have a Master node on its LAN.

I’m in the process of reverting and testing, but where would I find the best multicast debug page?

If there is anything else that I can add, please let me know - I plan on working on this all week…

Ubuntu 14.04 - FOG 1.1.2
Multicast log on main FOG server is empty
Multicast log on storage node does not exist (file not there)
Storage nodes ARE pushing images to clients in unicast mode correctly (tested and verified)

Thanks for any help,
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.

Hello all,
I cannot seem to find “Server Shell”, the Java-based SSH client, inside the FOG web UI anymore.

I thought that it used to be under “FOG Configuration”…

I’ve searched my FOG Web UI, and the Wiki, and I cannot seem to find it…

I must be missing something,
Thanks for any replies or help,
D.L.

After a bunch of trial and error, I just reset the MySQL password with this command :

sudo dpkg-reconfigure mysql-server-5.5

I put this same password into .fogsettings under snmysqlpass, and also into config.php and re-ran the FOG installer.

It overwrote my password in .fogsettings with yet another randomly-generated one (I still have no idea why or where this password is actually used) but after that everything worked great!

I’m sure I just screwed something up along the way and/or entered the MySQL password incorrectly…

Thanks for the help and advice, as always,
D.L.

P.S. - I did use snmysqluser=“root” and snmysqlhost=“localhost” - thanks for that info!

Thanks for the reply,
I’m only doing a Normal installation for now, so I’m attempting with those settings…

However the snmysqlpass field still doesn’t make sense to me - I went ahead and this to my SQL database password (that I set during initial installation) and re-ran the FOG installer and it overwrites it with a random password … so something seems wrong …

If it were using the password that I put into snmysqlpass before installation/upgrade, then why does it overwrite it?

Thanks,
D.L.

edit - fixed syntax mistakes…

Thanks for the reply,
I have no idea how to use SVN, but I will look into that and figure it out.

Regarding the .fogsettings file, is there any documentation on how it should be set? Excuse my lack of knowledge, but I have no idea what the settings are actually supposed to be, I’m just guessing. I can guess what the host should be (127.0.0.1 or my actual IP) but I’m not sure what the snmysqluser or snmysqlpass is supposed to be…

Especially confusing is the snmysqlpass - is that supposed to be the database password that I set? Or a random one generated by the FOG installer/configuration?

Thank you,
D.L.

edit - Seen last post, will try… but I still don’t get the randomly-generated password thing, which seemed to be what worked in FOG 1.1.0…

Ubuntu 14.04 x64
FOG 1.1.0 -> 1.1.1

Hello,
I too am having this exact problem after upgrading to 1.1.1 - I have not had time to try a fresh installation yet. For testing purposes, I guess that would be the next step but it would be great to get the update to load on an existing FOG installation as well.

I have tried every possible combination of settings mentioned in this thread and tried the steps from the link to the MySQL.sock page, no success…

I have never fully understood the MySQL password thing with FOG, how it has 2 SQL passwords - one main one (for the database) and one for the storage, or I don’t know? I did set a MySQL database password and I have verified that it is correct at /var/www/fog/commons/ - config.php

I checked .fogsettings and this is what I had :
snmysqluser=“”
snmysqlpass=“some random password”
snmysqlhost=“”

I’ve tried removing .fogsettings and re-installing, doesn’t work. I’ve also tried every setting I can think of inside the .fogsettings file including :
snmysqluser=“fog”
snmysqluser=“root”
snmysqlhost=“127.0.0.1”
snmysqlhost=“10.10.10.10”
snmysqlpass=“old random .fogsettings password”
snmysqlpass=“new random .fogsettings password”
snmysqlpass=“SQL database password from /var/www/fog/commons/ - config.php”

None of these seem to work…

Is snmysql user supposed to be “fog”, “root”, or “” - I believe that it was “” in previous versions and that worked…?
Is snmysqlpass supposed to be the database password from /var/www/fog/commons - config.php ? Or a random password generated by the FOG installer?

Maybe I’m screwed because I didn’t document earlier random passwords generated by FOG? I know what I set the database password to during installation, but I’ve gone through several random passwords trying to get this to work…

Thanks for any help,
D.L.

I just wanted to add that I do understand that basic scripting is not the same as developing, and is generally part of the job, but I’m sure that I will have some trouble getting this to work.

I will try it and report back, thanks again for all of the assistance and the great work on FOG,
D.L.

Thanks for the replies,
These are both good directions to point, and thank you for the suggestions. If/when I have time to try these, I will…

However, it would still be better if it was integrated as part of the FOG Service, or the main FOG installation, IMHO. Of course this will sound lazy, but having the work already done and having it mechanized, automated, and in the background is always better.

That it probably the single greatest thing about FOG and the FOG Service, it WORKS - yes, there are ways to do everything that FOG and the FOG Service do independently, on your own, but I would never be able to get them working. The deployhappiness.com link illustrates this perfectly as the comment section is full of folks having trouble with it, trying to get it to work, etc. and undoubtedly that would be me as well and I would probably just give up before I got it working…

That’s why you guys are developers and I’m just a user, haha!

Thanks again for all of your work and help,
D.L.

Thanks for the reply,
It seems like putting the serial in “Computer Description” might be better than trying to put it in the hostname, so I guess that would be my goal, yes. In simpler terms, getting the serial into Active Directory in some form is the MAIN goal, and “Computer Description” would seem to be the best and more appropriate place/way for this, rather than the hostname.

The problem with doing it via VBScript snapin is that is another thing to write/manage/push/worry about, and I would rather just have it be mechanized as part of the FOG Service. However, I will certainly try it that way as time allows.

Would a VBScript pull the serial from the SQL database, or from the local machine? Off the top of my head, I cannot remember if Windows stores the motherboard serial somewhere, but you would think so…

Also, cloning machines with/without sysprep might cause a VBScript to pull an incorrect serial if it’s pulling it from the local machine.

Thanks,
D.L.

I realize that it would be necessary to modify the FOG Service to do the “Computer Description” idea, but in theory the code/connections are already somewhat setup for something like that, correct?

Can the FOG Service pull the serial from the SQL database? My guess would be yes, and then it would be a (not simple) matter of passing that into “Computer Description” - after that, the serial would appear inside Active Directory in quite an elegant way.

Thanks,
D.L.

Another thought, although probably even more complicated, would be to pass the system serial into “Computer Description” inside Windows which allows up to 1024 characters, I believe. I now have a better understanding of the pitfalls and cumbersome nature of having the serial as the hostname, so perhaps this would be an alternative to make the serial view-able and searchable inside Active Directory.

The goal of this is to be able to cross-reference the systems that FOG has touched inside Active Directory (by more than just a hostname), and passing the system serial to “Computer Description” might be a more elegant or alternative way of doing this. Originally I went down the MAC path because that accomplishes this to a certain level, but that has its downside too.

Your time, work, and thoughts are greatly appreciated,
Thanks again,
D.L.

Thank you for your time thinking this through!

I had not thought about the issues that you mention, you are definitely right that it is more complicated than it seems at first.

I guess even Dells would only allow 8 characters in the “prefix” to stay within the 15 character hostname limit :

SSS-RRR-*

And you make a good point that since it is not standardized, it would fail on many systems - ACER, and ASUS come to mind as their serials are 30 or so characters with the first 22 or so being the same, by model. The HP’s that I use have 10 characters in the serial, which would still work, but then that limits the prefix as it could no longer be 8 characters. However, I know that many folks just use SSS-* (where SSS is the site, and * would be the serial) and in this case something like this would support all Dells, and I believe all HPs.

Since it is not standardized, and would probably require truncation then perhaps it would be more trouble than it is worth, but I just wanted to ask about this.

Although it would be confusing, since FOG allows duplicate hostnames (and only really cares about the MAC) having truncated serials that result in duplicate hostnames would not be the end of the world, until you wanted to join / integrate Active Directory, just a thought.

Maybe this isn’t something that would be part of the main release but could be a modification, plug-in, etc. because it is complicated, and some folks might actually hate this…

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