Yes i never released the re-coded version for 0.32 and it already is available in 0.33b

Thats exactly why i devloped the location patch and Tom has now recoded it as a plugin. You set the location as Campus A for the host and it will only pull the image from that node that uve assigned to location campus A and if u dnt slecify a node u can set it to a storage group also.

[url]http://www.fogproject.org/wiki/index.php?title=FOGUserGuide#Full_Listing_of_Ports_used_by_FOG_server_and_client[/url]

[url]http://www.fogproject.org/wiki/index.php/SVN[/url]

that wiki will show you how to install svn version of fog (the very latest i.e. 0.33b)

DO NOT use this to upgrade any production version of fog.

would recommend setting up a test environment for you to play around with

answer to the question:
no - you build the image as normal (random computer name, set to join workgroup etc)
when you image a machine, fog will deploy that image (with the random computer name, set to join workgroup etc)
once the image is on the disk (before it boots into windows or anything) the init.gz will then mount the hard drive/partition, find sysprep file, open it, re-write it to include the hostname, and domain details, save the sysprep file and then let the machine carry on and reboot as normal.

then sysprep will go through the process as it normally would but the sysprep file will have the correct hostname and the correct details to join domain.

i removed the need for the windows service regarding name change domain join (as long as it’s a sysprepped image you’re using) so the only thing i use the windows service is to deploy a snapin/script that installs several pieces of software.

i don’t use the HOSTNAME_EARLY feature, i get fog/init.gz to change the sysprep.inf or unattend.xml after imaging(before it reboots) to match whatever is set in fog for that particular machine so it sets hostname and ad all at once so when sysprep initially boots up the sysprep.inf or unattend.xml is already customized to match that machines details also meaning no need for reboots for domain join too.

the error you’ve posted is connection issue, try this (on 10.24.1.2):

[LIST=1]
[]nano /etc/mysql/my.cnf
[]comment the quoted content “bind-address = 127.0.0.1” use # symbol
[*]restart server or mysql service
[/LIST]

no sorry, you need to reset the fogstorage user on the main server (once you’re connected locally to mysql)

[SIZE=3][FONT=arial]SET PASSWORD FOR ‘fogstorage’ = PASSWORD(‘fs123456’)[/FONT][/SIZE][SIZE=3][FONT=arial]; and do the same on your node (only diff will be the password will be the one under storage management for your node)[/FONT][/SIZE]

just so you can rule out an account issue

Ok well lets get the node connecting to the main server so do the local command to on main server to reset/set password:

Btw ur commands looking similar to this?
I.e. mysql -u fogstorage fog -pfs9345 -h192.168.169.212

You may need to reset the node user account aswell so connecting local to node mysql database.

imaging reports seemed to be broken (for me anyway) using latest svn, when option to set dates (start and end) i’m given the options of 1 to 3 and then two blank rather than actual dates and no matter what is set, no image tasks are shown in the report

[FONT=arial][SIZE=3]a way to try and troubleshoot (Everything in red in the commands you need to change before running command.)[/SIZE][/FONT]

[FONT=arial][SIZE=3]first off - run the below command on your [U][B]main server[/B][/U]:[/SIZE][/FONT]
[FONT=arial][SIZE=3]mysql -u fog fog -p[COLOR=#ff0000]PASSWORD_GIVEN_AFTER_INSTALLING_FOG_ON_THE_NODE[/COLOR] -h[COLOR=#ff0000]IP_OF_NODE[/COLOR][/SIZE][/FONT]

[FONT=arial][SIZE=3]this command above will just confirm your main server can connect to mysql database on your node.[/SIZE][/FONT]

[FONT=arial][SIZE=3]then run on your [U][B]node[/B][/U]:[/SIZE][/FONT]
[FONT=arial][SIZE=3]mysql -u fogstorage fog -p[COLOR=#ff0000]whatever is set in fog settings under FOG_STORAGENODE_MYSQLPASS[/COLOR] -h[COLOR=#ff0000]IP_OF_MAIN_SERVER[/COLOR][/SIZE][/FONT]

[FONT=arial][SIZE=3]from what you are saying the above command, you should get “Access Denied”[/SIZE][/FONT]

[FONT=arial][SIZE=3]then run on your [U][B]main server[/B][/U]:[/SIZE][/FONT]
[FONT=arial][SIZE=3]mysql -u fogstoage fog -p[/SIZE][/FONT][SIZE=3][FONT=arial][COLOR=#ff0000]whatever is set in fog settings under FOG_STORAGENODE_MYSQLPASS[/COLOR][/FONT][/SIZE]

[FONT=arial][SIZE=3][COLOR=#000000]the above command is connecting locally using fogstorage mysql user account (the one your nodes trying to use)[/COLOR][/SIZE][/FONT]
[FONT=arial][SIZE=3][COLOR=#000000]if it does connect - you have an issue with connecting remotely to your mysql database on your main server, if it doesn’t connect then it’s more likely an mysql user issue.[/COLOR][/SIZE][/FONT]

[FONT=arial][SIZE=3][COLOR=#000000]and if so you could reset the password for the fogstorage account on mainserver.[/COLOR][/SIZE][/FONT]

[FONT=arial][SIZE=3][COLOR=#000000]on [U][B]main server[/B][/U] do this:[/COLOR][/SIZE][/FONT]
[FONT=arial][SIZE=3]mysql -u root fog (if you set a pw when installing mysql specifiy it with -p[COLOR=#ff0000]THE_PASSWORD[/COLOR])[/SIZE][/FONT]
[FONT=arial][SIZE=3]then run:[/SIZE][/FONT]
[FONT=arial][SIZE=3]SET PASSWORD FOR ‘fogstorage’ = PASSWORD(‘[COLOR=#ff0000]whatever is set in fog settings under FOG_STORAGENODE_MYSQLPASS[/COLOR]’);[/SIZE][/FONT]

[FONT=arial][SIZE=3]then try the command above that you run before on your node.[/SIZE][/FONT]

[FONT=arial][SIZE=3]hope this helps/makes sense[/SIZE][/FONT]

initial testing (16GB image) image pushed from same server to same client, same image uploaded from same client but one image upload with no compression and the other image upload with highest(9) compression. no other traffic on 1GB network during testing.

upload speed seems much better on partclone than partimage regardless of compression.

[U]No Compression Results:[/U]
Upload speed = Avg 2.02GB/Min
Image size on Server = 16,244,393,968 (main partition)
Deploy speed = Avg. 3.08GB/Min

[U]Highest Compression Results:[/U]
Upload speed = Avg 1.2GB/Min
Image size on Server = 7,576,511,522 (main partition)
Deploy speed = Avg. 4.51GB/Min

Re-run both tests to make sure!!

i actually got better deploy speeds with high compression! doesn’t seems logical to me but not complaining!! May be due to decent processor (quad core i7 4770K) on the client, might be worth testing on clients with low spec processors to see if get same outcome - also noticed deploy speeds much better if the image was uploaded using partclone rather than using existing image created by partimage.

Hi all,

just out of curiosity has anyone done much testing with compression over download speed? especially with it now being partclone?

it’s just space is not a concern but wondered how much benefit there is with compression regarding deploy tasks, i know it makes upload tasks quicker (when not compressed) or the image smaller (compressed) but has everyone found that the more compression the impact of deploy speed?

just seeing what everyone elses experiences are…

we had this issue on a fair few dell models and setting up chain loading fixed it so i believe ipxe should do the trick! if not:

[url]http://fogproject.org/forum/threads/dell-bootloop-chainloader-problem.4147/#post-11373[/url]

now with ipxe could it be possible that when you do full registration for the host and you choose image now, could we now avoid a need to reboot before the imaging starts?

the code tom’s posted is what i actively use to handle Win7/8/8.1 (mutli-partition) and i build my image in vm and have the disk only a few GB’s bigger than the image (20-25GB) and expand if the image gets bigger that way you never have to worry about putting it onto a “smaller hard drive” and extend partition in the unattend handles the rest

Myself, Tom and james are looking to working on this as a plugin potentially may take sometime… just watch this space

…i’ll speak to Tom about maybe getting something implemented so any “options/pre-reqs” aren’t hard coded and you can set them from the Web GUI i.e. folder path (C:\Drivers) and maybe have a “Driver Management” page so you can manage the folders without having to do it all back end on the server.

it also means you do not have to run an additional script after sysprep and i build my images on a VM so that there is bare minimum drivers on the image during audit mode - also means again image can stay small for faster deploys.

I do exactly the same to handle drivers except i get the init.gz to detect the machine model, download the relevant drivers folder (drivers in .inf form) from the closest node and then add the registry entry to devpath so all drivers (as long as they’re signed) are handled and installed by sysprep that way i can keep the image small and drivers up to date without having to modify the image - also means i can have one image per OS