@Sebastian-Roth Hi Sir I will do so thnx

@george1421

I’ve read a lot to solve the problem, and I think that’s the quid of question:
Snapins Run as SYSTEM or root
All Snapins including SnapinPacks run as the SYSTEM or root user’s security context. If a snapin or SnapinPack runs successfully by manual execution but not via the FOG Client - this is typically related to the security context. For example, say you have a shared directory that is granted read access for all Domain Users. Well, an individual host’s local SYSTEM or root account is not a member of Domain Users. Therefore, unless alternative credentials are supplied to access the share, any script executed that tries to read this share will not work. There are a few solutions to this. Granting the share read access for anonymous users is the most simple. Specifying credentials within scripts or as arguments are viable options.

How can i specifying credentials with scripts or arguments in snapin console? Could you put an example?

Thks a lot.

@Jamaal Good to hear you figured this out. Would have been quite hard for us I reckon.

Hello mate,
Had the FOG issue: Warning: mysql_connect() [function.mysql-connect]: Access denied for user ‘root’@‘localhost’ (using password: NO) in /var/www/fog/management/index.php

This is caused by the FOG PHP session looking to connect to ‘localhost’, the correct password is not being passed causing the failure. Not having time to research the exact fix I found the following is a quick solution…

Before trying to open the FOG management webpage
Install PHPMYADMIN (this makes database management easy)
Open //localhost/phpmyadmin
Create a new user and give them ALL permissions for ALL HOSTS (basically they should be the same as ROOT
Check the user is there and the permissions are set correctly.
Go into the PERMISSIONS tab and remove the password for ROOT under localhost & 127.0.0.1
Open the FOG webmanagement page
Set up the users in FOG
Go back to PHPMyAdmin and make sure FOG has been added as a database. You will need to log on as the ‘new user’ above
Reset the root password to something secure (as per pre install???)
Open the FOG database
Go to Permissions and BLANK the root password for localhost & 127.0.0.1
That should solve the issue.
Best regards
Arso

@Cameron-w A couple of things that come to mind skipping through that video:

FOG 1.2.0 is very old. Make sure you install the most current version which is 1.5.5 as of writing. From you question it seems like you already have - just wanted to stress this point. (K)Ubuntu 14.04 is dated as well. I would advise you to use a more recent one as well. Changing the FOG server’s IP address is more an advanced thing and not something I would advise new users to do! Better make sure you can have a setup with internet access and static IP address right from the start. Saves you some headaches. If you really want to do an IP change use Wayne’s script found here. This way you don’t have to worry about FOG_WOL_HOST and the others this guy is changing. Just go with a static address for your first lessons and you can completely skip that changing part of the video (20:00 to 31:00).

The rest of the video seems ok, although talking about an old FOG version. Have fun.

Marking as solved. @JiC Please let us know if you see it replicating the same image files over and over - definitely shouldn’t.

@p4cm4n In the case of storage nodes, the fog server that hosts the database has to be updated with the remote node’s new IP address. So to answer your question, No. Though since the database credentials are present on the storage node, some alterations to the scripts could make this possible.

dhcp general settings on LAN:

0_1542798476261_2368dc54-6215-4e93-855b-ada35d7e0f02-image.png

dhcp settings on other VLAN:

0_1542798558095_52779031-4102-4b2d-84c6-f1b69ab59a94-image.png

@Keating178 Please schedule the same task again but tick the checkbox for debug task this time. When you get to the shell start it using command fog and step through.

It will fail again I am sure but will drop you back to the shell. Now run the sgdisk you see on screen to get the full error…

A fog “image” consists of 2 parts.

The raw image files stored in /images The metadata stored in the mysql database.

You can copy all of the raw image files simply by the copy command. The metadata can easily be exported from the webgui into a csv file. With the raw data and metadata you can rebuid the images on a new fog server or whatever. If you don’t have the metadata but the raw image files you could rebuild the metadata if you are careful on how you name your images and are a good guesser for the rest. Point being, backup the image metadata with the raw data files and you will be good.

This sure resembles the issue where someone changes the linux user fog’s password, or they are using this linux user fog for system administration.

I do have a tutorial on how to resync the linux user fog so you can get past this step: https://forums.fogproject.org/topic/11203/resyncing-fog-s-service-account-password

Understand this is for the linux user fog that is FOG’s service account not the webui default admin by the same name.

It’s there now and working. It was not there on Friday, on any of the pages. Not sure if you guys did a refresh or anything like that, but it’s working just fine now. Thanks a bunch!

I got it sorted out by mistake (i hit enter to early while trying to enter MariaDBs shell - without a password). I entered a mysql password during installation, but it seems like this didn’t get set in MariaDB. I started MariaDB as root with no password entered and could then change the root passwort to what it was supposed to be.

@george1421 @jgiovann I just updated the wiki article. dnsmasq 2.76 is now available in most distros (Ubuntu, Debian, CentOS 7, …), so I moved the part about compiling it far down.

@Raymond-Bell said in TFTP Server:

It was that ATA… Sorry for all the trouble guys

That is why we are here to help. I’m glad you have it worked out. Something simple, but it caused you so much problems. On the plus side you are now on 1.5.5 with all of the fixes, so you are in a better place than when you started the day.

@quinniedid Thanks for your help. You guys are the best!

It is now working. I think I found the issue. I was using the Smartinstaller my old server generated. It used the same IP address and hardware, so I didn’t think it’d be a problem.

Hi again,

Only for give more information about this in a huge scenario. In our case the FOGPingHosts service give 4 hours and 30 minutes, more or less, to do ping to all clients.

Capture of the traffic in one client:

18:10:43.216290 IP fog7.lgp.ehu.es.39006 > u032668.lgp.ehu.es.microsoft-ds: Flags [S], seq 3515736006, win 29200, options [mss 1460,sackOK,TS val 2691861063 ecr 0,nop,wscale 7], length 0 18:10:44.216894 IP fog7.lgp.ehu.es.39006 > u032668.lgp.ehu.es.microsoft-ds: Flags [S], seq 3515736006, win 29200, options [mss 1460,sackOK,TS val 2691862064 ecr 0,nop,wscale 7], length 0 22:46:19.552188 IP fog7.lgp.ehu.es.47968 > u032668.lgp.ehu.es.microsoft-ds: Flags [S], seq 14809462, win 29200, options [mss 1460,sackOK,TS val 2708397399 ecr 0,nop,wscale 7], length 0 22:46:20.552909 IP fog7.lgp.ehu.es.47968 > u032668.lgp.ehu.es.microsoft-ds: Flags [S], seq 14809462, win 29200, options [mss 1460,sackOK,TS val 2708398400 ecr 0,nop,wscale 7], length 0 03:19:37.718318 IP fog7.lgp.ehu.es.51734 > u032668.lgp.ehu.es.microsoft-ds: Flags [S], seq 3380421067, win 29200, options [mss 1460,sackOK,TS val 2724795565 ecr 0,nop,wscale 7], length 0 03:19:38.720889 IP fog7.lgp.ehu.es.51734 > u032668.lgp.ehu.es.microsoft-ds: Flags [S], seq 3380421067, win 29200, options [mss 1460,sackOK,TS val 2724796568 ecr 0,nop,wscale 7], length 0 07:52:47.623417 IP fog7.lgp.ehu.es.57902 > u032668.lgp.ehu.es.microsoft-ds: Flags [S], seq 1502300674, win 29200, options [mss 1460,sackOK,TS val 2741185470 ecr 0,nop,wscale 7], length 0 07:52:48.624903 IP fog7.lgp.ehu.es.57902 > u032668.lgp.ehu.es.microsoft-ds: Flags [S], seq 1502300674, win 29200, options [mss 1460,sackOK,TS val 2741186472 ecr 0,nop,wscale 7], length 0

@bmick10 So now that you have it configured to not restart when the system is that’s good. Now just make sure the settings are correct in your .fogsettings file so that the dhcp server isn’t reenabled when you update FOG.

@msi Just to let you know, we have worked on the replication code and fixed a couple of issues. The new release is on the door step and should work fairly well.

We’ll put that into the release notes as well but just to let you know beforehand:
Nodes being on different versions (1.5.4 vs. 1.5.5) will replicate images over and over again as some of the hashing code needed to be changed. Therefore we advise you to update all nodes in one go! Please make sure you stop replication on the master first (systemctl stop FOGImageReplicator), then update the storage node(s) and then update master node as a last step.