@jmcg service dnsmasq status;service dhcpd status

@dolf That probably means you should reset the encryption for all hosts, as I think this is done for you when you image a host.

The below script should do it, and it should work in Cron fine since I pathed out the mysql command dynamically.

The software the forums uses, nodeBB, has a bug in it lately where it removes spaces from BASH scripts. In the below script where you see [[ and ]] There needs to be a space after [[ and a space before ]]

#!/bin/bash

#----- MySQL Credentials -----#
snmysqluser=""
snmysqlpass=""
snmysqlhost=""
# If user and pass is blank, leave just a set of double quotes like ""
# if the db is local, set the host to just double quotes "" or "127.0.0.1" or "localhost"


#----- Begin Program -----#

mysql=$(command -v mysql)

resetEncryptionForAll="UPDATE hosts SET hostPubKey=\"\", hostSecToken=\"\", hostSecTime=\"0000-00-00 00:00:00\""

#Test lines to make sure the sql looks good.
#echo
#echo $resetEncryptionForAll
#echo

options="-sN"
if [[ $snmysqlhost != "" ]]; then
        options="$options -h$snmysqlhost"
fi
if [[ $snmysqluser != "" ]]; then
        options="$options -u$snmysqluser"
fi
if [[ $snmysqlpass != "" ]]; then
        options="$options -p$snmysqlpass"
fi
options="$options -D fog -e"


#Do it
$mysql $options "$resetEncryptionForAll"

@monasmith529 you don’t use the link, and git pull is run from within the fogproject directory. You simply go to the fog directory like cd /root/fogproject and then just run git pull

Pinging @george1421 and @Lee-Rowlett to take a look.

@THEMCV It’s failing on this line:

rsync -aqz "$remotedriverpath" "$clientdriverpath" >/dev/null 2>&1

SO, just before that, for troubleshooting purposes, echo out the command it’s running like:

echo
echo "rsync -aqz \"$remotedriverpath\" \"$clientdriverpath\""
echo

Put those three lines one line above the problem line, exactly as I typed it. It will echo out the actual command being run. Then, run the script. The command will get echoed out and look proper. Examine it, copy it, and try to run the command by itself and see what happens.

If you’re coming from 1.2.0, you would have been using the legacy client. There’s no trust relationship for the legacy client - which is one of the many reasons why the legacy client isn’t secure. So no worries there.

I think 1.2.0 had a host export feature? I don’t remember exactly. But, on the old server look at Host Management and look for an export link on the left menu.

If there’s not one there, you could just export the whole DB and import it into the new server. If the new server has a different IP than what the old one used, you’ll need to adjust certain fields via the web interface post-import so those IP addresses get fixed. Steps on that here: https://wiki.fogproject.org/wiki/index.php?title=Change_FOG_Server_IP_Address Remember you’d just be changing the web gui stuff, nothing in the backend would need changed.

And lastly, if your new server has a new IP, you’ll need to update your DHCP server’s option 066.

And, if the new server has a new IP, and you installed the legacy clients using an IP, well then don’t worry about them anymore. You can use Group Policy startup scripts to uninstall the old client via msiexec /x {product code here} /qn and then install the new client and give the proper arguments to point it at the correct server and use the options you want it to use. Steps on that are here: https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#FOG_Client_0.10.0.2B_Installation_Options I recommend the MSI installer if you’re going to deploy out the new client with policy.

Another option, if you don’t rely on the fog client, is to just not worry about the exiting clients or deploying. Your systems will get the new client the next time you image them.

@Tom-Elliott I find it funny how people assume it will take forever to get a response, because they don’t reply back typically until 1 hour to 1 day later.

Clone this whole repository using git:
https://github.com/FOGProject/fog-community-scripts

It’s the one in there called “MakeFogMobile”, there’s an installer and all.

If you need help or have issues, come back to this thread and tell us.

@ernie ohh… I’ll look into that.

I assume you want to expand your disk because the images you have presently on your fog server, you want to keep. I also assume this server is virtualized, since you only have one disk listed in gparted. I’d first recommend snapshotting this server if you’ve not done so. You might think about copying the images directory to somewhere for safety also.

Then read through this:
http://www.geoffstratton.com/expand-hard-disk-ubuntu-lvm

I think you can probably start in that article at the step where they are extending root’s logical volume with all available free space.

It’s not necessary to type in all caps. We also need the exact errors to help. You can copy/paste them or screenshot or take a photo. The Multicast log would also be helpful, found in fog configuration -> log viewer -> multicast.

@sudburr

Inside of /opt/fog/.fogsettings

Set:
blexports='0'

This should stop the installer from overwriting an existing installation’s exports file.
Reference: https://wiki.fogproject.org/wiki/index.php?title=.fogsettings

So if you’re deploying to just one host, you get 9GB/M but if you are deploying 2 hosts at once you get 300-800MB/M ?

That doesn’t make a lot of sense, these numbers just don’t align.

First, you need to have tests where you change just one thing, and not many things. I don’t know how you tested and came to these numbers, but the test probably wasn’t consistent which is why the numbers make no sense. Here’s what I would do:

• Pick an image and stick with that.
• Pick 2 computers of the same model and stick with them.
• Don’t move the computers, use the same drops for both tests.
• Image one computer, note the ending speeds towards the end of imaging.
• Image the other computer, note the ending speeds again for this. Write these things down.
• Then for the last phase, image both at the same time, write down the ending speeds for each.
• Think about the results, share the results. Also share if their physical network links were 100Mbps or 1Gbps.

Also,
It may not be the FOG Server. It could be that the two computers you imaged at once are on a 100Mbps switch, and all the ports on that switch share a 100Mbps uplink to the next-tier device. It could also be that these two computers you imaged at the same time are just old, and that’s as fast as they can go. Cheap little netbooks get terrible speeds because of their low-power economy processors.

This new server, you’re sure it has a SATA 3 (6Gbps) disk in it? How much RAM does it have? Is it at least dual-core ?
Do you have it in a VM, if so, perhaps the VM Host’s storage was just very busy at the moment?

Also, A compression of 1 will most likely degrade your speeds, and a compression of 9 would also degrade your speeds. The compression is what balances network and cpu. If you have super-fast CPUs but a super-slow network, it makes sense to put compression on 9. If you have a super-fast network and super-slow CPUs, it makes sense to put compression on 1. Most people aren’t in these two extremes but are somewhere in the middle. 6 has been found to be the best balance for a 1Gbps network and Sata3 disks with modern Core i5+ processors. Refer to this for community-research on compression: https://wiki.fogproject.org/wiki/index.php?title=Image_Compression_Tests

Could it be related to the image compression option when initially creating the image?

Maybe, doubt it. If this image deployed fine before, it would not suddenly get terrible after being migrated to the new server - unless you deployed/captured it at a compression of 1 or 9 instead of just transferring the files from old->new.

Could it be something to do with my current Kernel?

Unlikely.

@digi newsid was retired for a reason. The creator posted a massive post about it, read up if you have time its a good read. x23 posted a piece of it below, I recommend reading it in full.

But, for reasons that the creator of newSid listed himself, I’d recommend against using it. Just use sysprep instead if you need SIDs to be unique.

@george1421 Sounds like a good script for the new fog-community-scripts repo. A lot of work from @sudburr and myself is already done in this area, it should be a snap to write up something generalized for 1.3.0. I’ve been meaning to do this for a long time, I have a moment so why not start I guess.

@george1421 Started a new script project called UpdateIP, you can see it here:
https://github.com/wayneworkman/fog-community-scripts

It’s not ready for use just yet. In fact I’ve not even test-ran it because I know it’ll fail. But it’s almost done. Due to the nature of how it’ll be used, this script will need to correct ISC-DHCP appropriately if that’s marked for use inside of the .fogsettings file.

Go over to a computer on that subnet and (assuming windows) run this command: ipconfig /release && ipconfig /renew and then see what DNS address it’s using.

@zta104 The next step is to upload a copy of the c:\fog.log from an affected system. Setup a task as you described, let it go for a bit, then grab the log.

@K.Hays lol half a year later.