Posts made by Kiweegie

@Wayne-Workman Hi Wayne, Tom logged on remotely to my fog server to inspect the installfog.sh file and found a syntactical error within. I believe it was along the lines of looking for the Linux version calling /etc/*-release or similar and while my machine is running Centos 6.7 and returns output as follows:

CentOS release 6.7 (Final)
CentOS release 6.7 (Final)
CentOS release 6.7 (Final)

The code was transposing or omitting parts of that output so was failing at that point. Tom corrected whatever was wrong using sed. I didn’t see the exact part which was edited I’m afraid.

regards, Kiweegie.

Tom Elliot kindly helped me out with an issue with the latest git installer where it was firing a continual message:

Sorry, answer not recognized.

This was resolved and installer now completes however when clicking on the install/upgrade schema link in a browser it navigates to http://my-fogserver-ip/fog/management/index.php?node=schemaupdater but sits at a blank page.

has anyone else encountered similar? Might be something simple like a syntax error in installfog.sh file or similar.

cheers. Kiweegie

@Tom-Elliott Thanks again for the help Tom, greatly appreciated. Please mark this call as resolved.

regards, Kiweegie

@Wayne-Workman well that was quick, but not successful.

using latest git version same error is occuring - “Sorry, answer not recognised”

I have followed the steps on installing on Centos from the wiki so selinux and iptables etc are disabled and all repos are added on.

What could be triggering that last stanza in the installfog.sh file?

cheers Kiweegie

@Wayne-Workman Thanks Wayne. A possibly (and feel free to omit the possibly) stupid question. How does one find a list of valid SVN release version numbers? I’m sure when I had this working before on the FOG icon on the web GUI it shows the revision number.

This is from another of our FOG servers which is running ok.

Imgur link

Yet when I try and download that version on my faulty FOG server I get this

[root@fogserver svn]# svn co -r 4457 https://svn.code.sf.net/p/freeghost/code/trunk trunk/
svn: No such revision 4457

If on the working server I go to Fog Configuration it shows the following version info

Version: 4457

You are not running the most current version of FOG!

You are currently running version: 4457

Latest stable version is 1.2.0

Latest svn version is 3959

Latest git version is 4557

So I tried downloading the 3959 version via SVN and no dice - same error as before “Sorry, answer not recognised”.

Do the GIT and SVN versions get updated separately? I’m trying git now based on this wiki link:

regards Kiweegie.

@Wayne-Workman Hi Wayne thanks for getting back to me,

No, the directory /opt/fog does not exist. But given this is a brand new OS install now and I haven’t been able to install FOG yet due to the error below, I wouldn’t expect to see it yet.

Sorry, answer not recognized

Something I’ve been meaning to ask elsewhere but may help in this case, how does one pull down a specific version of the trunk via SVN version, is that possible? Wondering if i specify an earlier SVN version it could rule out issue with this particular installer?

Just a thought…

regards Kiweegie.

OK, I appear to be missing something here. I ended up wiping my existing FOG Server VM and rebuilding from scratch.

On a clean install of Centos 6.5 and the latest SVN download I’m still getting the repeated error below when launching /opt/svn/trunk/bin/installfog.sh

Sorry, answer not recognized

Am I missing somethign obvious? The README.md file within the downloaded SVN trunk folder suggests the method I’ve used is correct.

regards Kiweegie.

Hi Tom, appreciate the quick reply.

Steps I’ve followed to get and install latest svn version are:

sudo mkdir /opt/svn
cd /opt/svn
sudo svn checkout https://svn.code.sf.net/p/freeghost/code/trunk
cd trunk/bin
sudo ./installfog.sh

This line in your reply doesn’t compute my side though, could you elaborate please?

(That line has a purposeful New line but displays as a regular single line command) this could pose the issue.

Am I somehow running the installer incorrectly? This has worked just fine in the past up to and including yesterday morning.

Happy to use MysQL commands provided to disable plugins - I can access the GUI but there is no delete option there to remove them. However I need to get FOG reinstalled first…

regards, Kiweegie.

Thanks Tom, that makes sense. I can’t remove the plugin so was looking to do a clean reinstall of FOG to wipe out and start again. I’ve run this to clear settings

mv /opt/fog/.fogsettings /opt/fog/fogsettings-firstInstall

then removed all FOG related files

#Uninstall FOG

#remove service
sudo rm -rf /etc/init.d/FOGImageReplicator
sudo rm -rf /etc/init.d/FOGMulticastManager
sudo rm -rf /etc/init.d/FOGScheduler

#delete fog database
sudo mysql
#(or 'sudo mysql -u root -p' if you set a root password for mysql)
drop database fog;
quit

#Remove files
sudo rm -rf /var/www/fog 
sudo rm -rf /opt/fog 
sudo rm -rf /tftpboot 
sudo rm -rf /images 

#delete fog system user
sudo userdel fog

Tried installing latest SVN version but getting repeated error:

Sorry, answer not recognized

I can see that this is coming from the last few lines of the installfog.sh file

        ;;
        [nN]*)
        echo "  FOG installer exited by user request."
        exit 1;
        ;;
        *)
        echo "";
        echo "  Sorry, answer not recognized."
        echo "";
        ;;
    esac
done

but cannot see why. I’ve read on other posts that this can happen when copy/pasting and the installer reading a carriage return or similar but I’m typing commands by hand.

regards, Kiweegie.

Hello again…

I upgraded to latest SVN version of FOG this morning (4547) during troubleshooting of another issue - pulling image from remote storage node with the location plugin. While that issue is now resolved I find that if I click on the Create New Image link it hangs on a blank page while trying to navigate to: http://fqdn_of_main_fog_server/fog/management/index.php?node=image&sub=add

I did try and add the LDAP plugin just beforehand which prevented me from logging in at all to the web GUI. I got around this by renaming the plugin directory

mv /var/www/html/fog/lib/plugins/ldap /var/www/html/fog/lib/plugins/ldap1

I have since upgraded to svn version 4551 to see if that would solve things but same issue occurs.

The LDAP plugin may not be the issue here. I can login to the GUI and then rename the ldap1 to ldap again so I can use the LDAP plugin and remove all entries there but the issue still happens. I’ve also disabled the plugin system completely in FOG Configuration > FOG settings > Plugin System but once again issue persists.

Is this perhaps a bug in latest svn version? Or is the fact I can’t delete plugins indicative of an issue within the plugins system which could be somehow impacting the create new image link in some way?

regards Kiweegie

@Tom-Elliott absolutely, was looking for how I could mark resolved this side funnily enough,

@Tom-Elliott

Thanks Tom, looks to be the missing piece in my particular puzzle. I now have everything set up as before except with TFTP From Node checked and image deployment remotely works pulling image from the local storage node at each site.

Many thanks, Kiweegie.

Quick update.

I’ve updated to latest SVN today on both the main fogserver and one remote storage node on which I’m testing.

For the sake of example here’s how I’ve set things up here for now - names altered to protect the innocent.

Head office:

Auckland
fogservermain1 (normal), fogservermain2 (storage)

Remote offices:

Wellington
fogremote1 (storage)

Invercargill
fogremote2 (storage)

Dunedin
fogremote3 (storage)

I’ve set DHCP scope on all sites to point to fogservermain1 (066/067)

Location plugin has been added and setup locations for:
Auckland, Wellington, Invercargill and Dunedin

There are 2 storage groups setup - default and Auckland

All the remote sites point to the default storage group for images, Auckland is used for head office images only so that images are not replicated to the remote sites.

I’ve checked the fog user guide re location plugins here: https://wiki.fogproject.org/wiki//index.php/FOGUserGuide#FOG_Plugins

But there is not a great deal of detail. The plugin configuration only has a** name, storage group, storage node **and **TFTP from Node **entries which for Wellington remote node is set as

Location = Wellington
Storage group = default
Storage node = Wellington
TFTP From Node = unchecked

Am I missing something fairly obvious? I’m assuming that all the remote sites should still have PXE boot pointing to the main fog server, in this example Auckland. And that unless TFTP is configured on each remote site (I’ve not done this) then to leave TFTP From Node unchecked and the Storage Node entry itself is how the remote site knows which server to pull the image from.

Anyone who has successfully set up remote site imaging using the location plugin, could you chime in here to improve my understanding please?

Until todays update of the SVN version imaging remotely was dying a death. It is now imaging successfully however the image is being pulled from the Auckland main server not Wellington remote server still. I suspect I’m missing a very small step here but would appreciate a nudge in the right direction if possible please.

regards, Kiweegie

@Wayne-Workman HI Wayne, thanks for the reply. All images are set as Single Disk - Resizeable. The sharing between storage groups is not the issue - I have this particular image shared between the 2 storage groups I have currently. I don’t need to have each remote site in it’s own storage group do I? I presume the image replication still hits them if they are members of a storage group on which the master stores the image.

My issue appears mainly in getting the image to deploy an image from the main fog server in head office to a remote site but have the image itself pulled from that clients local storage node.

I wanted to double check that i had understood the setup with location plugin correctly and that I should still have DHCP scope pointing to the main fog server address (066/067 entries in DHCP) and if I neededed to have the TFTP from Node checked on the Location plugin for that remote client.

Ref the donation it’s definitely on my to-do list. I do give what I can to open source projects I use personally but it’s sometimes difficult to get the “powers that be” to buy into this philosophy. I’ll tackle with my management in due course though and see what can be done. You guys are doing awesome work and time “ain’t cheap”.

regards Kiweegie.

Hello fellow FOGgers

I’ve had a break from FOG for a few months but now the company I work for is moving away from using MDT and instead using FOG for all image deployment. So I’ve been tasked with getting the remote imaging part working now.

I have a aingle storage node at head office with 2 storage groups setup, one of which replicates to the remote storage nodes.

I have implemented the location plugin to handle image deployment to the remote sites. What I would like to achieve is using the head office normal node for all host registrations and image uploading but sync the image files to remote storage nodes and have image deployment controlled from head office but pulling the image file from the local storage node at each site.

This does not appear to be working however.

Initial TFTP on the remote client shows the IP Address of the main fog server looking for default.ipxe and boot.php then pulling down /bzImage and /init.xz files from the main server. The transfer of /init.xz file takes several minutes. I can see in PRTG that there is a connection between main fog server and the remote client.

Partclone then kicks in to restore the first partition (/dev/sda1) of around 300MB. But then the second partition piece (/dev/sda2) fails with error:

Partclone v0.270 http://partclone.org
Starting to retore image (-) to device (/dev/sda2)
device (/dev/sda2) is mounted at
error exit
-

This then continues on to black screen with the following error

#############################################################
#                                                                                                                                                   #
#                                  An error has been detected!                                                               #
#                                                                                                                                                  #
#############################################################

Image failed to restore

#############################################################
#                                                                                                                                                   #
#                                  Computer will reboot in 1 minute                                                      #
#                                                                                                                                                  #
#############################################################

On the fog server GUI the task shows commecning but then hangs at 97.10% on the first partition.

The same image can be deployed withn the head office fine so the image itself is ok. File size of the image on both the main server and storage node is the same - I’m going to check an md5 hash shortly to double check as potentially image is corrupt on node…

The other thing I wanted to check was the correct usage of the TFTP is node entry in the location plugin.

Way I have this configured at present is the remote node DHCP server points to the IP of the main fog server (not the storage node). And I have TFTP is Node entry unchecked. I have also tried checking this box but makes no odds.

So 2 main questions - has anyone seen the error above re the image and have a possible answer as to cause and a solution?

And secondly what is the correct setup with DHCP scope options and the TFTP is node entry in location plugin to achieve what I’m trying to achieve?

thanks for any advice one and all.

regards, Kiweegie,.

Mod edited to use code box.

@Wayne-Workman Success!

ok the latest snapin has worked as expected. Root cause I think was the locations and how I had set them up. Each host has a Location entry and each location points to a storage group.

I’d set the host I was testing this on to the only location I’d set up for head office and this was pointing to the wrong storage group.

I’ll do some further testing this week but hopefully others with same issue can at least learn from my mistakes…

Wayne, really appreciate the time and effort you put in to help me out with this one, greatly appreciated.

cheers, Kiweegie.

@Wayne-Workman Thanks for all your help so far Wayne.

I think the way I had set this up locations orignally wasn’t quite right anyway. I’m likely overthinking this or making more compllicated than it needs to be. I went with the SVN version based on Toms recommendations as I wanted specifically to make use of the location plugin to support main server for hosting image definitions and pulling image files from local storage servers…

An overview of how I have this setup may help

Setup is like so:

Head office1 = normal node (DefaultMember)
Head office2 = storage node (Storage)
remote nodes 1-7 (storage nodes named by location)

2 Storage groups, “default” and “Headofficestorage”

All storage nodes point to default storage group except Head offfice 2 (Storage) which points to Headofficestorage storage group. I’m using default storage group to replicate all images to the remote nodes and the Headoffice Storage node to keep all other images both those for that site only as well as some presysprep images for the other sites which we don’t want to replicate to the storage nodes.

I have now removed all locations and re-added this time with one for each remote storage node (pointing to default storage group) plus 2 locations for head office

HeadofficeLocal = default storage group
HeadofficeStorage = HeadofficeStorage storage group

Locations I originally had set up one for each “actual” location, the headoffice one pointing to the HeadOfficeStorage storage group when it should have been default (i.e. main server where the snapins are actually located).

So I’ve now created 2 locations for head office

HeadofficeLocal = default storage group
HeadofficeStorage = HeadofficeStorage storage group

I’ve create a brand new snapin using Filezilla which I know works and this is pointing to the default storage group. Deployed snapin still hangs and the fog.log now has new errors…

 15/06/2015 16:03 FOG::ClientUpdater File: C:\Program Files (x86)\FOG\tmp\UserTracker.dll hash doesn't match server hash!
 15/06/2015 16:03 FOG::ClientUpdater Checking Status : config.ini
 15/06/2015 16:03 FOG::ClientUpdater File: config.ini requires an update.
 15/06/2015 16:03 FOG::ClientUpdater File: C:\Program Files (x86)\FOG\tmp\config.ini hash doesn't match server hash!
 15/06/2015 16:03 FOG::ClientUpdater 1 new modules found!
 15/06/2015 16:03 FOG::ClientUpdater Checking Status : 
 15/06/2015 16:03 FOG::ClientUpdater File:  requires an update.
 15/06/2015 16:03 FOG::ClientUpdater An exception occurred during a WebClient request.
 15/06/2015 16:03 FOG::ClientUpdater    at System.Net.WebClient.DownloadFile(Uri address, String fileName)
   at FOG.SnapinClient.downloadAndDeploy(String localFile)
 15/06/2015 16:03 FOG::ClientUpdater Client update will be applied during next service startup.
 15/06/2015 16:03 FOG::ClientUpdater Client update process complete, exiting...

The reference to C:\Program Files (x86)\FOG\tmp\config.ini does help though as if I check there on the cllient what do I see? The 2 snapins I was trying to deploy earlier!!! Date modified matches when I tried to deploy originally and the file size shows 0

So (very) long story short it looks like the client was pulling the snapin down ok but hitting the tmp folder with zero file size.

Hopefully this might help you help me shed light on where its falling over?

regards Kiweegie

@Wayne-Workman Hi Wayne

all storage nodes are set using IP - I’m sure I read somewhere there was an issue adding DNS name here.

Just thinking out loud now…

I have 2 storage groups, default and Storage.
The main server (storage node = DefaultMember) uses the default storage group as do all my remote storage nodes. I have one more storage node at head office which uses the storage group - this is to hold images which I don’t want to sync to my remote nodes.

I’m guessing that there might be something funky with how I’ve set this up or with the location plugin or something (though fully prepared to accept I’m barking up the wrong tree). As a test i tried adding the snapin to the storage group but kept getting error:

Failed to add snapin, unable to locate snapin directory.

Does the other storage group “storage” need to be set as master even though its not replicating to other nodes?

I should also point out that I’ve edited the php file for max upload etc of snapin files.

regards Kiweegie

@Wayne-Workman Hi again Wayne, searching forum seems to be working a little better today and i’ve found this post which had same error mesage:

https://forums.fogproject.org/topic/3362/active-snapins/4

On that Tom Elliott had advised to ensure the snapin file name showed as file name only not the full path. It shows file name only.

The OP (BUdgester) on that call as workaround edited the /var/www/fog/service/snapins.file.php file line 31 (in my case on Centos path is /var/www/html/fog/service/snapins.file.php and lines 31 shows as:

                       $SnapinFile = "ftp://".$StorageNode->get('user').":".$StorageNode->get('pass')."@".$FOGCore->resolveHostname($StorageNode->get('ip')).'/'.ltrim(rtrim($StorageNode->get('snapinpath'),'/'),'/').'/'.$Snapin->get('file');

Do I need to look at manually editing some part of this file perhaps?

Unlike Budgesters issue this is a clean install of the SVN version of Fog and not an upgrade.

regards Kiweegie

@Wayne-Workman Hi Wayne, good plan. I have been able to FTP from client machine to the main fog server using the username fog and password which sits in FOG_TFTP_FTP_PASSWORD field

Default path it hits is /home/fog but I can navigate ok to the snapins directory at /opt/fog/snapins just fine.

So it doesn’t look like a permissions issue - I did also amend to 777 perms per your earlier suggestion but this I don’t think is necessary. I’ve amended back to original permissions and checked access via FTP again to be sure and it works fine. I can also pull file across to client via FTP not just view contents of fog directories.

regards, Kiweegie