@imagingmaster21 said in Windows 7 Image:

The machines using the image will be using BitLocker Encryption.

FOG cannot image machines with bitlocker encryption except with RAW images, which is terribly slow, inefficient, and the worst way to image.

Here’s the best practices:

• Always use resizable images if you can.
• Use ZSTD compression with a setting optimized for your network:server load (this is unique to your environment, you have to find the sweet spot).
• Turn off bitlocker in your image, re-enable after image deployment via group policy or a snapin or something.

@coxm said in Image Replication Across Storage Groups:

should i image a pc in that remote site which is made part of that remote site storage group it will pull the image from that node, not the master Fog server on my local site.

Not necessarily. Without the location plugin, fog just picks whatever server that has empty slots.

You should look at the location plugin (link posted earlier), I think that’s what you need. The location plugin allows you to assign storage groups and storage nodes a physical location, and allows you to set physical location on hosts. If host A is assigned location A, and a storage node is assigned location A, then all imaging on host A would only use node A.

@coxm said in Image Replication Across Storage Groups:

Just to confirm, any machine I put into the same storage group as the storage node will pull the data from that box rather than the Full Fog master server, is that correct?
Thanks.

I’m not sure I understand your question, so I’ll explain the order of operations.

Replication first does group-to-group which is from a master group’s master node —> non-master group’s master node.
Next, replication does inner-group replication from a group’s master node to all non-master nodes in the same group.

This is outlined in the wiki article on replication.

@george1421 said in Provisioning Raspberry Pis with FOG:

were there are other documented and proven ways to deploy to the Pis.

We have ARM devices we use embedded linux on at work, they have multiple block devices in them (one could substitute with a permanent USB Flash on a Pi). We instruct the devices what block device to boot from. When we want to image, we boot to a special block device that has everything we need to image the other local block device.

So, one might say that my current job could possibly use FOG to image ARM devices. But we already have a successful strategy for doing this now.

@junkhacker said in Provisioning Raspberry Pis with FOG:

Broadcom is not releasing the source for the network boot files.

Broadcom just lost brownie points in the open-source world…

@coxm said in Image Replication Across Storage Groups:

Where is it pulling the username/password from and where should it be set?

In Storage Management, there is a credentials area for every single storage node. Those credentials are the ones that work for the local account that FOG uses for FTP operations. Keep reading: On each storage node/fog server there is a file at /opt/fog/.fogsettings that has a username and password setting. When you update FOG on these, the installer looks to this local file to know what to do. So you must ensure that password and the one in Storage Management are correctly set - otherwise this will just all break the next time you update and you’ll be left wondering why. Here’s an article detailing the .fogsettings file: https://wiki.fogproject.org/wiki/index.php?title=.fogsettings

@coxm said in Image Replication Across Storage Groups:

I am guessing that the problem is that the master and slave are in different storage groups?

That’s not a problem, that’s a choice. and it’s ok because fog can replicate across groups, it’s done in Image Management. Go to image management, click an image, and you should be able to find a sub-area where you can define what storage groups the image belongs to. In this same area, you can set which storage group is the master group for that image.

When you set this, whichever is designated as the master group is the one where captures will go, and replication goes only from the master group to the non master group. Group-to-Group replication uses the masters in the group. So you need to set GroupB’s storage node as the master for it’s group.

Also, you should read these fully, I think you’ll learn everything you need from them:

• https://wiki.fogproject.org/wiki/index.php?title=Replication
• https://wiki.fogproject.org/wiki/index.php?title=Location_Plugin

@siheobs FOG can only deploy FOG images. You need to capture the manufacturer’s image with FOG before you can deploy it with FOG.

@george1421 Right, and then there’s the problem of DHCP giving out the right binary, and that binary requesting the right kernel and init.

I think all the PXE binaries and FOS need compiled for ARM for this to work??

@coxm said in Image Replication Across Storage Groups:

I have got 4 office locations and, at the moment, 2 FOG instances. One master at location A and in storage group 1 and one storage node in location B win storage group 2.
what i want to end up with is a storage group for each location with a storage node in that location (Physically and in FOG config) but the single master in location A. This would then allow image management for all remote storage node locations from my base office location.
Is that possible?

Yep. And it’s a good design too. Did you need help with setting it up or just wondering if it can be done or not?

@lebrun78 said in Manage scheduled task:

May be examples are lacking in the documentation ?

Help us write examples? Post them here.

@siheobs said in Problems with exit boot on M.2 SSD drive:

The image was made by the manufacturer

Is it a FOG image?

@greg-plamondon said in Login takes 5minutes+:

I forgot to mention that the Fogserver is also handleing dhcp for 4 subnets.

Ok, gotta say it… You should put MySQL onto a dedicated VM, and point the FOG Web Server to it instead of the local one. Separate out stuff like this to scale horizontally (more VMs) instead of vertically (bigger VMs).

@siheobs said in Problems with exit boot on M.2 SSD drive:

I had try to change multiple exit boot settings like (Host Bios Exit Type, Host EFI Exit Type) and nothink works.

Make sure you try the EFI grub exit type, then EFI grub first hdd.

@sebastian-roth said in Is supporting Secure Boot now possible?:

We follow up with the latest iPXE versions so yes, the version changes on every release and even between releases in beta/RC code branch - if you follow that.

In other words, the FOG Team is ON TOP OF IT!

@greg-plamondon said in Login takes 5minutes+:

  REQS REQ/S    KB KB/S URL
  147  5.88 284.2 11.4*/fog/management/index.php
  134  5.58   1.2  0.0 /fog/service/getversion.php

The main load are those two. The getversion is done by storage nodes, The other is the dashboard I think. @Tom-Elliott Ideas on this one?

@jackiejack said in Reinstalling Backing up Database Failed:

You know any good links/yt vids on this topic. Thx.

There are so many tutorials on this… Here’s a few:

• https://www.howtoforge.com/tutorial/how-to-create-a-local-red-hat-repository/
• https://linux.die.net/man/1/reposync
• https://access.redhat.com/solutions/9892
• https://linux.die.net/man/8/createrepo
• This one was particularly useful to me: https://deviantengineer.com/2016/03/repo-centos7/

The basic premises of running an RPM/Deb mirror is 1. Copy the files from the internet regularly using the right tool(s). 2. Finagle the files however you need. 3. serve via HTTP 4. Configure your clients to use the mirror.

For Fedora,CentOS, and RHEL, you’ll use the commands reposync and createrepo for most of this stuff. For Ubuntu/Debian land, there’s the less than ideal apt-mirror which gets the job done but is really terribly lacking of features.

Once mirrored, serve via HTTP, then configure your clients to use that web address.

I’ve done this before several times. What I’m leading you on is home-brewing your own solution. Of course, you could pay 11,000 dollars a year for Red Hat Satellite Server but I really feel like an ounce of scripting skills plus another ounce of CRON with a sprinkle of Apache know-how totally replaces Satellite Server honestly. For Ubuntu, there’s the paid solution called “Landscape” if memory serves. I wrote a replacement for that one too. Though I can’t share any of that work because it was for my last employer and they own the intellectual property. All I can do is show you the way.

@sjensen said in Issues with disk in an unsafe state:

I’m not where to change this ip address at.

It’s in /opt/fog/.fogsettings it’s the field called ipaddress=

@caw001 You’ll want to read through this, it has the configuration steps you need: https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence