Oh, nice. Sorry didn’t see that. I just started watching the video, as I plan on moving to PDQ within the coming year.

Glad they did this.

Update, I created the .fogsettings file and updated. It would not let me update the schema so I added the MySQL credentials (instead of leaving them blank) and update was successful. Things, host, users, images, etc, look good from the FOG webpage. I will do some testing next week. This is a XEN guest so I have copies. We have not imaged yet, (purpose of upgrade was for XP and Vista imaging). DBAN errors out with a chaining error, we use HTTP to load DBAN. I will do some testing next week.

Thank you for your help. In our environment starting from scratch is easy but then we would not be as familiar with our install.

@ITCC I’d make sure on both fronts.

Yes, tick the box in the fog settings, but the “checkbox” is typically checked on hosts even if they’re not “enforcing”. This because it get’s its information from the FOG Settings -> Active Directory Defaults -> Similar named checkbox setting.

Just because this is checked on the host does not mean it’s actually set. It’s not because I like making people confused, but rather how the checkbox is checked. I can’t know which method you’re intending for while being able to auto-set the box when you do want to enable domain join and what not, so this is set based on the value in the default location specified above.

@Tom-Elliott that’s what i meant to convey. the default is 10, and that works fine for most in initial setups and test environments. it’s up to the person running the server to monitor and adjust settings to fit their environments optimal configuration.

@george1421 It worked!
I clicked on the host name in the list and in that page reset the encryption data. Now that host has joined the domain and got the right printer.

I will now do these steps on our master image.

Thank you for your kind and patient help.

alt text

FOG does support imaging IA32/IA64 compliant Macs. Setting up some of the pxe (netbooting) requirements are sometimes challenging, but that is a Mac thing not a FOG thing.

There is a wiki page that talks about imaging Macs with FOG. https://wiki.fogproject.org/wiki/index.php?title=FOG_on_a_MAC

@Nicolas-Bricet said in One FOG server for multiple teams:

To avoid, for example, accidental deletions of images.

The latest version of Fog records who deletes what images in the history table, in the DB. I had this come up once and asked the senior devs to record who, and they implemented it.

Also in the latest version, there is a checkbox called “Protected” for each image - when this is enabled, fog won’t let the image be overwritten or deleted via the GUI.

Both of those functionalities are only available in 1.3+

You could provide an account to people for the duration of imaging only, then delete their account. You could provide accounts only to your top tier folks, and give everyone else mobile access - so they have to be at the physical boxes in order to image them. Or you could just trust folks, they can do it - you just have to teach them how to do things safely, how stuff works. Let the knowledge flow instead of having a monopoly on it.

I would not recommend a multi-master setup.

I come from a school district at my last job, from a department of about 30 people with the same title, “equals” on paper. We had a 14ish server FOG setup - one master and the rest all storage nodes at all the various schools in the district. Everyone had a fog account. In all training I gave about FOG, I always stressed the responsibility that everyone had to have to use fog - and to be extra careful. Out of 2 years usage and that many people in one big system, there were no significant issues. Just pound it into their heads that they must be responsible - and to ask if they don’t know. Extend an olive branch and show them how things work.

@Junkhacker I suspect the same.

Or, it could possibly be something else. Remember that time I was beating my head against the wall for a week over why the fog server was crippled? Turned out it was a broken fiber cable left laying unfixed for a week by a piece-of-trash contractor that should have been fired.

Not saying it’s a broken fiber cable but… it could be the last thing you would expect, something very wild and off the wall.

George’s steps will absolutely work - because George is just that kind of guy. His stuff works. I am so sure of this that I didn’t even read what he wrote - I just assume he’s correct.

But I’ve faced this exact problem before and I solved it by adding the storage node as the master to my new server’s default group. This way replication goes from the old storage node -> New server. I let that run and sync - and after it was done I removed master from the old node and applied master to the new one. Of course image definitions must exist on the new server for this to happen - you have to recreate these either way.

Related article: https://wiki.fogproject.org/wiki/index.php?title=Replication

There are several documents that will get you started.
https://wiki.fogproject.org/wiki/index.php?title=CentOS_7

It is now recommended that you change selinux setting to permissive and not disabled as it appears in some documentation. Also if you need to leave the firewall enabled you can do that. The developers has provided some guidance on what firewalld rules need to be configured. Or you can just disable the firewalld service as outlined in the docs. Its also best practices to create a new vmdk (virtual disk) for your images and then mount the new vmdk onto the root partition over the /images directory. I have a document on doing that if you need.

At its most basic step its just installing centos 7 selecting bare minimum configuration, then installing wget, git, and then downloading the fog installers.

This one is a bit dated and created by some third party, but the steps are almost the same today: http://blog.ibuddy.info/index.php/2015/06/fog-v-1-3-on-centos-7-full-install-guide/

@maximillian Keep us posted, I am VERY interested to see your work/what you find!

@Sebastian-Roth said in Using FOG with older OS? (Win2000 or even 98/ME, earlier OSX/Linux):

Right now we have support for btrfs, ext2, ext3, ext4, fat(12/16/32), hfs+, ntfs, xfs as those seem to be the filesystems that most people use.

that being said, some of those we don’t test much. not too many people are deploying systems on fat(12/16/32) these days. so, let us know how it goes.

Huh, simply change the Git repo… Perfect, worked a charm! Thanks, Wayne!

@fredlwal

Do you have a webfilter appliance?

You may have to add launchpad.net to the whitelist, or the bypass list so that the traffic is not monitored?

We filter all traffic anything ssl gets decrypted and sent down to the client (basically a man in the middle) and I had to add the url to the bypass list so the traffic is not decrypted.

I could get to the website fine, but I saw issues with adding the repository. (I even added the repo to the sources.list which helped some but not completely.)

@Tom-Elliott If I convert the disk to GPT (which wipes over the clone). After I clone the drive again (after converting disk to GPT) I will need to segment the drive in 4TB partitions (excluding OS partition). Since there will be several partitions (ex. (2) 4TB partitions) how will this need to be setup up in FOG regarding images moved across several partitions?

I did do this at my last job for one classroom.

We had mixed models in there, some were Lenovo, some Dell. I hate mixed model rooms. But anyways…

I had three groups for that classroom. One for the whole room, one for the Lenovos, one for the Dells.

Before deployment, I would use the classroom group to ensure exactly and only the snapins I wanted were set for the entire room, the right printers, the right AD Credentials.

Then with the two sub-groups I set the image I wanted each model to have.

Then I would deploy the Lenovos and Dells separately using their groups. Both groups would wake, image, boot, join the domain, deploy snapins and printers.

Like magic.

@Schuede Please check:

FOG Configuration Page->FOG Settings->Web Server->FOG_WEB_ROOT and make sure it’s set to /fog.

There is no function like that in fog. You could create a FOG snapin (deployment package) to do something similar. But the prompting will still be an issue. That capability doesn’t exist today.

@danpbow create a batch script (with .bat extension) to do exactly as you need.

At the end of the wmic command tack on output redirection like > \\x.x.x.x\my_share$\%computername%.txt

Ending a share name with $ in windows makes it undiscoverable, this is a security thing I recommend you do. The share should allow read/write in the share and security tabs for anonymous logon - this is because the fog client runs as system on the local machine.

Once the script is working manually, you would create a new snapin and use the batch template and upload the script. Then just try it out on a few hosts in fog web interface.