Mutlicast deploy does not autostart after minimum receivers?

[drh1716]

Thanks very much for your updates and additions to the FLDT.....the setup document helped quite a bit.

When attempting to use the multicast for deployment, clients connect and wait. But even after the number specified as a minimum are ready, the multicast does not start. If I kill the multicast and start it again with the same number of clients, the clients that have been waiting begin immediately. It seems as if multicast deployment doesn't work unless start it after clients are already sitting and waiting for the task to begin. Is this the expected behavior?

[tomswartz07]

Hey there!

Thanks for the kind words. I'm glad my updates helped! :smile:

To your question: I do not believe that this is expected behavior. However, I have noticed a few minor quirks with the program that have yet to be ironed out.

1. I have noticed that some 'clients' (devices to be imaged) will not fully complete the netboot process, and hold up the count. Only once every device has fully booted will the total count begin. I'd take a quick glance over and make sure that the devices are linked up properly and that they are all sitting on the same netboot screen.
2. Sometimes the FLDT server service needs to be restarted. I've found that I needed to refresh the service at least once per 50 devices. I have not had a chance to dig in and find out why.

Perhaps try checking these two? I'll look to see if there's a way to get a 'live' count of the connected devices.

[drh1716]

Tom....

I think they are properly connecting b/c as soon as I stop/restart the task, they kick off immediately. It isn't a large issue by means.

We do have a number of Windows machines and I have to say I'm about to pull out my hair with fog and multicast. I'm wondering if FLDT would be able to handle our Win machines in some fashion if I was able to get partclone.ntfs into an image. I tried copying the partclone.ntfs off of the server and into the same bin directory in FLDT where I found partclone.extfs, but all I get is partclone.ntfs not found when I try to run from the mkImageNTFS I made based of of mkImage (even if I use full path)........by any chance do you have any suggestions about how I might add partclone.ntfs into the system?

Have a great weekend, David

On Mon, Feb 9, 2015 at 8:27 AM, Tom Swartz notifications@github.com wrote:

Hey there!

Thanks for the kind words. I'm glad my updates helped! [image: :smile:]

To your question: I do not believe that this is expected behavior. However, I have noticed a few minor quirks with the program that have yet to be ironed out.

1. I have noticed that some 'clients' (devices to be imaged) will not fully complete the netboot process, and hold up the count. Only once every device has fully booted will the total count begin. I'd take a quick glance over and make sure that the devices are linked up properly and that they are all sitting on the same netboot screen.
2. Sometimes the FLDT server service needs to be restarted. I've found that I needed to refresh the service at least once per 50 devices. I have not had a chance to dig in and find out why.

Perhaps try checking these two? I'll look to see if there's a way to get a 'live' count of the connected devices.

— Reply to this email directly or view it on GitHub https://github.com/tomswartz07/FLDT/issues/5#issuecomment-73538976.

[tomswartz07]

Hey David,

Thanks for the info.

I'm gonna split your question here into two parts.

Part 1

It's tough to say exactly what may be the cause of the hangup with imaging.

Just for the sake of argument, let's check the most likely cause: Perhaps the dnsmasq service has run out of IP addresses to assign? When you restart the FLDT service, startup.sh calls a restart for dnsmasq, thus clearing old addresses that were handed out.

Perhaps try adding a configuration line in the /etc/dnsmasq.conf file to reduce the DNS lease time. Heck, 5 minutes might be good enough for the addresses for your purposes. I believe the line would look like this: option 'leasetime' '5m'

Part 2

I'm sure that FLDT might be able to handle NTFS imaging, but I have not ever tried to build up a deployable image. I was actually planning to see if I could get it to work sometime before the summer, but right this moment it's a low-end priority. I don't think that it would be much different than the standard procedure.

I have the process semi-automated with Packer and Jenkins. The 'inline' sections below can be run from any machine that you want to image. Within my packer.json file, my 'provisioner' is a shell script (rather than VBox or VMWare):

            "type": "shell",
            "inline": [
                "apt-get clean",
                "umount /boot",
                "mkdir /realboot",
                "mount /dev/sda1 /realboot",
                "cp -ar /realboot/* /boot/",
                "umount /realboot",
                "rm -Rf /realboot",
                "lvcreate -L 5G -s -n clone /dev/FLDT{{user `version`}}-vg/root",
                "mkdir /media/files",
                "mount -t vboxsf files /media/files",
                "apt-get install partclone -y",
                "partclone.ext4 -c -s /dev/FLDT{{user `version`}}-vg/clone -o /media/files/{{user `partclone_image`}}",
                "umount /media/files",
                "lvremove -f /dev/FLDT{{user `version`}}-vg/clone"
            ],

Using jenkins, but (almost) exactly the same for the command line

PACKER_CACHE_DIR=/data/packer_cache/ packer build -var "version=$BUILD_NUMBER" -var "partclone_image=FLDT-daily.img" packer.json

scp /data/images/FLDT-daily.img tom@FLDTBOX:/media/Storage/FLDTImageDaily/sda1

ssh tom@FLDTBOX chmod 777 -R /media/Storage/FLDTImageDaily

Essentially, what this does is create a LVM partition snapshot for the drive, then partclone will take a full clone of the snapshot, allowing you to use it elsewhere as a .img file.

So, for NTFS, I suppose you could swap the

"partclone.ext4 -c -s /dev/FLDT{{user `version`}}-vg/clone -o /media/files/{{user `partclone_image`}}",

for

"partclone.ntfs -c -s /dev/FLDT{{user `version`}}-vg/clone -o /media/files/{{user `partclone_image`}}",

and then use the mkImageNTFS? I would double-check the partitions as well, sometimes the boot partition of Windows machines are FAT, not NTFS.