I’m having issues with snapins :

When editing an existing snapin, the files snapin files are being truncated to 0 length.

Replication checkbox is enabled, however I only have 1 storage node.

Is there something I’m overlooking?

Fog trunk/7190

Last I used VMware to shrink a disk, it was done via a VMware supplied tool called “vmware tools” for a windows guest. This is a guest OS application that is installed from VMware from a CD ISO image (ESXi, accessed by selecting “install vmware tools” in the host manager).

As this is a program/tool supplied by VMware, and is Host dependant, as well using private (and hidden) vmware API’s, I am quite certain that there is no linux derivative of said tool. If you have access to the VMDK file from a linux system you can manage to squeeze vcli [url]https://www.vmware.com/support/developer/vcli/[/url] onto it, I would suggest thinking about creating a new (smaller) VMDK file, and then cloning to the new VMDK. Of course this requires a fair amount of room itself (as does the hot shrink that VMware supplies for windows guests)

TL;DR; Windows guests, you need to use vmware tools. Linux guests, you need to do a lot of research, and get some 3rd party tools and install VMware tools (which likely won’t work on macos) to possibly even try with enough spare disk space to create a second copy of the VMDK.

Bonding works wonders, but beware your switch has to support it… and unless it’s LACP, you won’t benefit fully.

35 minutes seems a bit long for 37 gigs… <math>37g/35min=1.06 gigs per min</math> yes, that’s quite low. 4-5 gigs per minute with a single gigabit link from the server is pretty standard with multicast. Are you using Multicast? Any other bottlenecks? Decent switch? Unicast to a single client is 4-6 gigs per min?

I don’t see anything particularly wrong so far… I use DNS hostnames for DHCP option 66 on my network. The tftp is failing before undionly.kpxe is loaded via tftp, so it’s not a FOG configuration issue (server ip during setup).

Have you verified tftp works from that client location already?

1.2.0 stock has the known issue above… if you don’t wish to use the SVN tree, then the above scripts in my previous post could be applied manually.

You upgraded to 1.2.0? If so, you might want to verify that the default domain settings are correct in FOG config, noting that the domain portion should NOT be included in the username anymore.

If you have clients that are not using the default (as in you specified the OU, and therefore the rest of the domain settings as well), then you may need to double check the individual clients/groups as well for misconfigured domain/user’s

FOG’s windows client uses HTTP requests to contact the fog server to push/pull information.

What are you looking for in a Linux client? ability to change the host name? anything else? If that is all you need, a simple script could do this on first boot, and then delete itself.

Network issues I’ve experienced: STP taking too long to enable forwarding between network stack reloads, poor quality network wire or damaged runs (this is where I experienced your exact error message, it will work on dhcp, but fail on bigger packets), and amazingly enough, bugs in the switches (in my case, Cisco SG200’s with layer3 protection that could not be disabled - a firmware fix is available now) that caused issues with UDP on privileged port ranges (NFS), and slow DHCP servers.

This sounds a lot like the services are crashing before any logs are output. When they crash or exit unexpectedly, the output is masked by start-stop-daemon, and goes into the “black hole”.

What happens if you manually run the services like so… (these do not background when run like this… if successful, you will not see any output, they will appear to just sit there. Control+Z to suspend, then bg to send to background)
[code]
sudo /opt/fog/service/FOGImageReplicator/FOGImageReplicator
{Control+z}
bg
sudo /opt/fog/service/FOGMulticastManager/FOGMulticastManager
{Control+z}
bg
sudo /opt/fog/service/FOGTaskScheduler/FOGTaskScheduler
{Control+z}
bg
[/code]
Any errors?

[quote=“Ericsj860, post: 36176, member: 25563”]I was wondering if anyone has experience imaging Ubuntu across different hardware? With windows machines I know there are different steps to take when imaging across different hardware. Does anybody know if this is the same for Linux?[/quote]

If I get this correctly, your asking about deployment for Linux (Ubuntu) clients?

If yes, then here’s what I would surmise:
A) most current distro’s/kernels are all modular - EG, the kernel will load any needed modules (other than disk access) as needed for most hardware. HBA modules should be for the most part included (ata for the large majority of client computers).
B) Video support could be an issue - Linux frame buffer and X11 (Gnome) settings are usually tailored to the client computer’s video adapter and monitor.
C) Ethernet devices tend to get static names if they are not virtualized = EG, a NIC that came up as ETH0 in the master computer is not available in the client computer, and while there’s only one NIC available, the “new” NIC will be ETH1. A script would have to be written to remove the persistent-net-dev entries.

Other than that, I don’t see anything off the top of my head that would pose an issue. If your familiar with linux (Ubuntu), this should all be scriptable. FOG itself does not have any “oobe” type prep tools, and I’m not aware of any that are available otherwise for Ubuntu.

In my production env, I’m using Debian 7.6, fog 1.2.0 stock (with a patch to make multicast/scheduled tasks work), in a VM running under ESXi. Single storage node. Crazy reliable and fast. 6.3 GB/Min. Pushes an image out to a lab of 30 computers in ~10 minutes for a 30 G image. Task start to finish including sending Adobe CS 6 Master Collection as a snap in (yes… a snapin), along with several other largeish snapins is about 23 minutes.

Debian 7.6 is pretty much point and shoot for fog 1.2.0. I purging network-manager (debian and ubuntu) (apt-get purge network-manager network-manager-gnome) and statically configuring the network in /etc/network/interfaces as should be done for any server.

Toying around complete… Conclusions:
A) once base.inc.php is included, the full FOGCore/FOGBase is initialized. There doesn’t look to be any way I can see with the current structure to have the classes wait for the database when used as a daemon. Once called, an exception and exit is desired for normal circumstances (called via the CGI/Apache SAPI) if the database isn’t available. If we create an exemption for daemons (CLI SAPI) during DB class construction, then we are stuck with having to determine which service is currently executing and output to the correct output device the daemon for messages and waiting. I don’t see this as desirable operation inside the base DB classes as this isn’t the job of the DB class, or for that matter FOGCore/Base.

B) have a class specific to daemons that handles wait_interface_ready and wait_db_ready routines. Feasibly, the only use for these routines would be for the daemons anyways.

I’ve gone ahead and have done option B.

Attached are the patched /opt/fog/service/FOG*/FOG* files, as well as a Daemon.class.php (/var/www/fog/lib/fog/Daemon.class.php).
$Daemon->wait_db_ready() and $Daemon->wait_interface_ready() are both implemented. wait_interface_ready() has some fixes to make it a little more compatible with servers that are using Network-Manager/Network-Manager-Gnome.

Tested against Debian 7.6 and Ubuntu 14.04, with and without NM purged.

[url=“/_imported_xf_attachments/1/1313_FOGServices.zip?:”]FOGServices.zip[/url]

[quote=“Tom Elliott, post: 35689, member: 7271”]Mentaloid,

I’ve added much of the scripts you did (less the nettest.php as I added it directly into FOGCore class.) Also all the edits. Hopefully this will help us all out. Thank you for taking the time to test/troubleshoot and post your findings.[/quote]

No worries at at all Tom, the least I can do to help the project!
I had figured you would add it directly to the FOGCore class

I tested this against Ubuntu as well. Unfortunately, Ubuntu/upstart ignores LSB headers in the init scripts (bah… Ubuntu re-invents the wheel, and cripples it in the process again). Another solution will have to be found for this mysql issue for more compatibility.
2 options exist…
A) write a routine that checks for mysql to be alive, similar to wait_interface_ready.
B) Create an upstart style initscript, and install that instead of insserv/lsb initscript when installing on upstart OS’s

I like option A better, as it wouldn’t require separating the installer into ubuntu/upstart and debian/inserv again (yuck). I’ll look into how/where you implemented wait_interface_ready in the FOGCore class, and see if I can create a similar routine for mysql this weekend (or soon thereafter). The problem I can see with this is that FOGCore itself is what bombs without mysql. I’ll toy and see whats possible.

I also noticed a device output mistake in /var/www/fog/lib/fog/MulticastManager.class.php on line 227. This should be MULTICASTDEVICEOUTPUT. In SVN, it is using REPLICATORDEVICEOUTPUT.

So I’ve been playing around more with this.
I’m using a fresh install of FOG 1.2.0 on Debian 7.6

First off, the init scripts don’t seem to be added to the startup correctly.
Fixed this via
[code]
insserv -d /etc/init.d/FOGMulticastManager
insserv -d /etc/init.d/FOGScheduler
insserv -d /etc/init.d/FOGImageReplicator
[/code]

Second, going by the old idea that the network wasn’t ready yet, I wrote a routine to wait for the network interface
/var/www/fog/commons/nettest.php
[code]
<?php
function clear_screen($outputdevice) { $GLOBALS[‘FOGCore’]->out(chr(27).“[2J”.chr(27).“[;H”,$outputdevice); }
function wait_interface_ready($interface,$outputdevice) {
while (true) {
$retarr = array();
exec(‘netstat -inN’,$retarr);
array_shift($retarr);array_shift($retarr);
foreach($retarr as $line) {
$t = substr($line,0,strpos($line,’ '));
if ($t === $interface) {
$GLOBALS[‘FOGCore’]->out(“Interface now ready…”,$outputdevice);
break 2;
}
}
$GLOBALS[‘FOGCore’]->out(“Interface not ready, waiting…”,$outputdevice);
sleep(10);
}
}
?>
[/code]
Second I added this to /opt/fog/service/FOG*/FOG* similar to below (with appropriate differences for the different files)
[code]
<?php
@error_reporting(0);
require_once( dirname(realpath(FILE)) . “/…/etc/config.php” );
require_once( WEBROOT . “/commons/base.inc.php” );

new code here

require_once( WEBROOT . “/commons/nettest.php” );
clear_screen(MULTICASTDEVICEOUTPUT);
$FOGCore->out($FOGCore->getBanner(), MULTICASTDEVICEOUTPUT);
wait_interface_ready($FOGCore->getSetting(‘FOG_UDPCAST_INTERFACE’),MULTICASTDEVICEOUTPUT);

    $MM = new MulticastManager();
    if( ! file_exists( UDPSENDERPATH ) )
    {
            $MM->outall(sprintf(" * Unable to locate udp-sender!."));
            exit;
    }
    $MM->serviceStart();
    $MM->serviceRun();
    $MM->outall(sprintf(" * Service has ended."));

?>
[/code]
At this point I tested with the network interfaces being up/down when service is started, and it tests ok… the various /opt/fog/service/FOG*/FOG* scripts will wait until a network device is available before continuing.
Now I rebooted, expecting the issue to be solved… but nope. While more robust, it’s still failing to start with a boot.
After fooling around awhile, I figured out that it’s because the FOG* scripts are being called before mysql is started in the boot sequence. These scripts fail hard without a SQL connection. I’m not sure how to fix that, but I’m not sure that it’s a needed fix at this point.
With the above routine still in place, I also modified the LSB headers in /etc/init.d/FOG*, removing the default run levels so the system can maintain them properly on it’s own, and adding mysql to the required start line (Yes, the lack of $ is important, as it’s a service provided by another init script, not a system service)
[code]

BEGIN INIT INFO

Provides: FOGMulticastManager

Required-Start: $local_fs $remote_fs $network $syslog $network $inetd mysql

Required-Stop: $local_fs $remote_fs $network $syslog $network $inetd

Default-Start:

Default-Stop:

X-Interactive: true

Short-Description: Start/Stop FOGMulticastManager

Long-Description: Created by Chuck Syperski

Used to stop and start the FOGMulticastManager Service.

FOGMulticastManager is used to destribute images through

Multicast. Useful to image large amounts of systems simultaneously.

It serves this ability only if it’s the master node.

END INIT INFO

[/code]
Ran insserv again to update the bootscripts…
[code]
insserv -d /etc/init.d/FOGMulticastManager
insserv -d /etc/init.d/FOGScheduler
insserv -d /etc/init.d/FOGImageReplicator
[/code]

And now after a reboot, all the services are starting correctly.

I could test in a few days a few things.
However as one who’s messed with the internals of a ESXi host before… It seems a little overkill (and drive space killing) to use FOG for this. At least for the data drives/partitions. Personally I use the backup method detailed on vmware’s knowledge base to grab a config (state.tgz), and restore the backup to my new host using the reciprocal restore tool (or directly embedding in the new disk using a script I wrote) after modifying the config (including the mac addresses of the nics, this is important especially if you have bonded links).

Anyways, I would suspect this is more likely because of the way the linux image is handled. ESXi has a bootstrap process thats different from most linux installs: it’s a modified syslinux boot strap with the kernel appended as far as I can tell. The boot strap also modifies the disk the first time it’s booted with a few UUID’s. You may have to do a sector/sector copy. Not sure what this looks like with 2 drives installed… again I would have to try this out.

I’ve rambled a bit here: LTS, my suggestion would be to try a sector by sector copy.

Developers, by “Multiple Partitions, all disks, non resizeable” does this mean multiple hard disks, or just separate “disks” as in partitions on the first disk (physical disk)?

Also, .ps1 (powershell) scripts will work if you have a system script policy of unrestricted
run with “powershell”
run with arguments “-File”

in the script, don’t forget everything must have a full path by default!

As one that has had this exact issue bite me in the behind in multiple ways, use an untagged port. If you have STP turned on, also make sure portfast is turned on for this port.

I had FOG .32 running fine (albeit slow) on a network with tagged/pvid and STP enabled… it worked. The new kpxe in FOG 1.x bombed out in weird spots due to the forwarding delays.

The forwarding delay is triggered each time the network card is initialized (4 times) during Bios > pxe > kpxe > linux kernel. This creates a timeout problem that looks like it’s not an issue, but really is. Trust me. Do not test on a port with forwarding delays!

[quote=“Tom Elliott, post: 34771, member: 7271”]There’s a problem, similar to the tftpd-hpa issue, with mysql. I believe this is what you’re encountering.

It’s trying to start mysql, tftpd-hpa, and the FOG Services before the network device is available to run. What ends up happening is the processes (FOGMulticastManager,FOGImageReplicator,FOGScheduler) are running, but can’t communicate. So a restart doesn’t work because the restart simply kills and starts a new process. The previous process can’t stop so it just starts another process using the original process generated as if it were a child process. Because that doesn’t exist, and horrible looping pattern can be seen. I don’t know what to do to fix it. The proper fix for it is to run:
[code]sudo service FOGMulticastManager stop
sudo service FOGMulticastManager stop
sudo service FOGScheduler stop
sudo service FOGMulticastManager start
sudo service FOGImageReplicator start
sudo service FOGScheduler start[/code][/quote]

So, after taking a 5 minute look at this, there’s a quick fix, albeit an semi-incorrect fix.
Things to note here:
A) I use Debian.
B) The fog Ubuntu/Debian installer uses sys-rc-conf to register the initscripts which on a Debian system, while it works, is wrong.

The solution I came up with to make this work in a hurry:
A) Edit /etc/init.d/FOG* and change line #4 from [code]# Required-Start: $local_fs $remote_fs $network $syslog $network $inetd[/code] to [code]# Required-Start: $local_fs $remote_fs $network $syslog $network $inetd $all[/code]. Adding the $all keyword here is frowned upon, however I’m looking for a quick fix, not a correct fix… Possibly I will revert this at some point after changing the services themselves to start gracefully and wait for a network to be available, rather than bombing out. (If I do this, I’ll submit a patch)

B) update-rc.d (or insserv) is the correct way to register init scripts for Debian. I ran
[code]
insserv -d /etc/init.d/FOGMulticastManager
insserv -d /etc/init.d/FOGScheduler
insserv -d /etc/init.d/FOGImageReplicator
[/code] to reset the registration of the initscripts to the correct dependencies/runlevels as requested in the LSB headers of the initscripts.

After a reboot, all services were running, and I could get multicast running correctly.