Hi Wayne & Frank,

I have read extensively through all the information I could get at the time I investigated that (like 2 years ago), we have macminis, 2011 & 2012. And I never could get them to properly boot on the network, so what I did was to live boot a Ubuntu image on the mac, and “fog” myself (well, that is why I helped have partclone replace partimage in fog, because partimage couldn’t handle hfs).

Now I see you updated the wiki from what I remembered, as I was doing all that in the “pre ipxe” era. So I might give it a try next week… Thanks for the updates, I’ll let you know if that helps.

Cheers,
Gilles

installing from latest SVN on debian8 (on mysql 5.5), I encountered an error due to the latest schema update not mentioning the type of new columns. I suppose they are meant to be INT, but I guess it was just forgotten there

The following errors occured

Update ID: 198 - 0

Database Error:

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘’ at line 1

Database SQL:

ALTER TABLE fog.snapinGroupAssoc ADD COLUMN sgaPrimary

Update ID: 198 - 1

Database Error:

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘’ at line 1

Database SQL:

ALTER TABLE fog.imageGroupAssoc ADD COLUMN igaPrimary

Hi,

I have a similar scenario, with images being built in one place, then transferred out to other independent FOG servers (NOT secondary sites). I do it rather manually, using rsync and mysqldump on images (something like mysqldump fog images --where ‘imageId IN (xx,xx,xx)’ with the corresponding images to pull down).

I’ve thought about integrating them into fog, but sometimes, we need to pull back images from other servers, and not all sites have the same kind of connectivity, so the transfers have to happen at different times of day… So well, I use my brain, and we do sync using rsync/mysqldump as required. I will probably end up with some file synchronization system… but rsync works nicely for this. And the “one way image pull” is easy to script.

One way (meaning you don’t care what’s on the slave, as far as images go):
on master: mysqldump fog images > /images/images.sql
on “slave”: rsync -avP fog@master:/images/ /images && mysql fog < /images/images.sql

I think it’s not too appropriate to use the storage node feature for this, unless we can indeed define a bandwidth limit and time for the sync to happen, which can be done using a script & crontab without touching FOG. And if you want independent servers (I do), that won’t do, you need a full master on each site.

EDIT: ah, I just saw Tom’s news https://news.fogproject.org/imagesnapin-replication/
Well. That could do it… I guess we need to be able to flag a “big master”, or maybe have the ability to set an image as shared wherever it comes from on “masters”.
Cheers,
Gilles

You’d end up with something like this: https://github.com/gilou/fogproject/releases/tag/1.4.0-RC-2
and github “guarantees” the link to remain as is with its tags (or release name), and gives you a /releases/latest as stated in here: https://help.github.com/articles/linking-to-releases/

Hi,

This is more an idea rather than a real feature request, but I see the installer gets its binary from fogproject.org, which is nice, but probably could be spared easily the bandwidth hogging by releasing and using github’s assets and redirecting/linking to them.

This can also be included in a deployment script as you can use their API, or you can upload them manually along with the release creation: https://help.github.com/articles/creating-releases/

As I couldn’t identify an obvious build script or Makefile for the binaries, I was stuck with https://wiki.fogproject.org/wiki/index.php?title=Building_a_Custom_Kernel and https://wiki.fogproject.org/wiki/index.php/Build_FOG_file_system_with_BuildRoot to rebuild the kernel & the init.xz, are there more precise pointers to do that?
Not sure about the client part, but I haven’t even looked at that part.

Cheers
Gilles

yes, /etc/hosts as told in my post indeed, and /etc/resolv.conf as well. All information required to be fetched a way or another. Be it by a custom client or something else.

But again, using a simple script in /images/postdownloadscripts/ you could easily change the hostname (assuming it’s set at the FOG hostname).
Actually, I’m even considering a patch, but there are a few issues at hand.

• DNS : if no hostname, or if we want the domain name, can we request it?
• IP if we want to fill /etc/hosts as well (DNS, again)
• can we assume $part to hold / on a 50 osID ?
  => Reply: no, we can’t, so it should be /dev/sda1 forced, not too nice…

Idea is basically (and assuming DHCP will provide DNS domain and is set up for each host):

if [ "$osId" == "50" && ! -z $hostname ]; then
     mount /dev/sda1 /mnt
     echo $hostname > /etc/hostname
     sync
     umount /mnt
fi

Edited to make it a little bit more realistic ;)

Well… if you really want to protect your images, you’d also need to secure the access to the imaging process… It’s true that if /images requires auth, it makes it harder for someone to leak your images, however you’d need to make sure your attacker can’t just fake the MAC of a to-be-imaged computer and just retrieve your fog image with the credentials…

I’d say using samba/cifs is a bit overkill, especially if you don’t have proper security on layer2… But I see the point

Hmm, renaming could be done directly after imaging though, either using the postdownload script, or by writing it in the init…
Before rebooting, I guess /etc/hosts & /etc/hostname are enough.
Another way I’ve been using is hook the DHCP client on the linux systems to set the hostname to what the DHCP sets it to, but that of course requires that your FOG hosts are properly set in DHCP/DNS.

As on Windows, waiting for the client is probably not a necessity for that precise feature.

Hi,

I have a similar scenario, with images being built in one place, then transferred out to other independent FOG servers (NOT secondary sites). I do it rather manually, using rsync and mysqldump on images (something like mysqldump fog images --where ‘imageId IN (xx,xx,xx)’ with the corresponding images to pull down).

I’ve thought about integrating them into fog, but sometimes, we need to pull back images from other servers, and not all sites have the same kind of connectivity, so the transfers have to happen at different times of day… So well, I use my brain, and we do sync using rsync/mysqldump as required. I will probably end up with some file synchronization system… but rsync works nicely for this. And the “one way image pull” is easy to script.

One way (meaning you don’t care what’s on the slave, as far as images go):
on master: mysqldump fog images > /images/images.sql
on “slave”: rsync -avP fog@master:/images/ /images && mysql fog < /images/images.sql

I think it’s not too appropriate to use the storage node feature for this, unless we can indeed define a bandwidth limit and time for the sync to happen, which can be done using a script & crontab without touching FOG. And if you want independent servers (I do), that won’t do, you need a full master on each site.

EDIT: ah, I just saw Tom’s news https://news.fogproject.org/imagesnapin-replication/
Well. That could do it… I guess we need to be able to flag a “big master”, or maybe have the ability to set an image as shared wherever it comes from on “masters”.
Cheers,
Gilles

installing from latest SVN on debian8 (on mysql 5.5), I encountered an error due to the latest schema update not mentioning the type of new columns. I suppose they are meant to be INT, but I guess it was just forgotten there

The following errors occured

Update ID: 198 - 0

Database Error:

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘’ at line 1

Database SQL:

ALTER TABLE fog.snapinGroupAssoc ADD COLUMN sgaPrimary

Update ID: 198 - 1

Database Error:

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘’ at line 1

Database SQL:

ALTER TABLE fog.imageGroupAssoc ADD COLUMN igaPrimary

Hi Wayne & Frank,

I have read extensively through all the information I could get at the time I investigated that (like 2 years ago), we have macminis, 2011 & 2012. And I never could get them to properly boot on the network, so what I did was to live boot a Ubuntu image on the mac, and “fog” myself (well, that is why I helped have partclone replace partimage in fog, because partimage couldn’t handle hfs).

Now I see you updated the wiki from what I remembered, as I was doing all that in the “pre ipxe” era. So I might give it a try next week… Thanks for the updates, I’ll let you know if that helps.

Cheers,
Gilles

Hi,

This is really interesting, but annoying. I haven’t read all about NetSUS & stuff like that, but if I understand properly, for now, you need to patch ISC’s DHCP server to get to “properly” boot a mac from PXE?

I have tried that a lot, with former wiki entries & dark information about how it works, but it usually didn’t work on ALL the mac we have. If we could get the mac to netboot on ipxe, a great deal would be done already. Now to make sure the fog linux client boots on mac… but ipxe would already be quite good. I’ll read about that

(Sorry if I’m late in that, I’m trying to keep up with all that is happening with FOG lately… And it’s not easy.)