I can’t speak to the fog project, but in general many FOSS applications that are free to use, charge for the branding enabled options. And they typically stipulate that the FOSS application name and copyright information still appears (somewhere visibly) on the branded material, considering that the MSP is probably making some kind of profit from the setup of the FOSS software is only right that the MSP contribute some token back to the FOSS developers.

@juice381 said in Making Fog Portable:

@Wayne-Workman I’m familiar with dnsmasq however bash not my strong point here. My career hgas taking me the Microsoft path need me to write a powershell script, vb, batch i’m your man. I’m sure I can figure out bash just might take me some time to understand the syntax.

You will find the roots of batch, vb and powershell in bash (actually the unix command shell). The unix shell has been around for a really long time and is the mother of them all. With that said, if you know programming concepts then what you are missing is the syntax. That is where google will fill in the gaps. Bash programming is not as cryptic as perl programming, but is much more powerful than batch. Now that I have to totally confused, don’t worry. Work with it a bit and you will get the hang of the power it has.

Yes it is. This is what I call a Multi-Master setup. Understand this is NOT a supported configuration but will work with a caveat. (FWIW this is how I have my dev environment connected to my production environment. I build and test the images in dev and then replicate them to the prod servers when ready).

But anyway, you need to pick one node to be your root node in the multi-master configuration. This will probably your HQ node. On your HQ node (in the web gui) create a storage group, add in your root node into that storage group. Then create a slave node in that storage group. Give that slave node the configuration for the remote master node. You will need to ensure the fog (linux) users is setup correctly. Since the root node will need to connect to the remote master node for image creation. Once that is setup you can either wait or just restart the fog replication service and you should see the images start to populate in the /images folder on the remote master node.

Now for the caveat, the root master node doesn’t update the image database on the remote master node so you will need to export your image configurations from the root node (with the web gui) and then import them into the remote master node via its web gui. If you have skills you can actually create a cron job to do this, but that is a bit beyond this specific question. If you only update images on your root node then you don’t have to do anything, if you add new images to your root node you will then need to export and import your configuration (or just copy the settings by hand between the to master server)

The current ldap plugin is missing the capability to authenticate via AD using LDAP. This request will document the changes needed to add this capability.

@cnewman402 I did write a tutorial a bit ago about pxe booting a winpe disk that shows two examples. While its a bit off point of what you are doing right now it does show you the steps.
https://forums.fogproject.org/topic/6284/booting-mdt-2013-litetouch-with-fog

I also wrote one that shows how to boot the windows setup via a pxe boot.
https://forums.fogproject.org/topic/7765/pxe-booting-into-ms-windows-7-setup

Couple that with the FOG Wiki that Sebastian referenced
https://wiki.fogproject.org/wiki/index.php?title=Include_any_ISO_in_the_FOG_Bootmenu

That should get you started. Now understand each iso is different. The ones that are based on linux typically will have instructions on the provider web site on how to pxe boot them.

With that information you should be able to build your pxe boot menus nicely with the fog management gui.

@george1421 I’ve been working on other projects and haven’t had time to get back to this one. I have this plugin working in my production environment and it is working well. I’m to the point where I would like to test it in a few more AD environment as well as OpenLDAP. If you are willing to help test, please let me know and I’ll send the instructions. I have not yet submitted the code to the Developers for their review to be included in the official 1.3.0RC stream as of now. I wanted to ensure it functioned as we expected it before adding additional workload one the developers.

Here is a current screen clip of the fields and the expected values. We’ve added the ability to only do a name match with users at the search base dn. With this option the user must only appear in a defined OU or below. If a user is in that OU and the uid and password match then the user is considered a FOG admin. I don’t like using this option but there were several use cases (like all my fog admins are already in a defined OU) where I can understand the requirement (but still not like it ). The more secure way is to use group matching. In this case you will need to create an AD/LDAP group and put the admin/mobile users in these groups. This now changes the login requirements to 1) You must be a users in the specified OU, 2) Your uid and password must authenticate 3) Your uid must be in the authorized group for FOG.

You are in the worse of all configurations. Have only mpls for site to site links. Unless you have aggregated T1 MPLS you are limited to 1.5Mb/s throughput.

FOG can still be used really well in this configuration. As Tom said storage nodes will be your tool. But before I go too deep into the details, please tell me a few things.

1. How many systems target systems is there in your environment?
2. Do you do all of your development at HQ and your intent is to make these images and snapins available throughout your organization?
3. How many sites you do have?
4. Do you have centralized IT that is responsible for remote deployment?
5. How do you deploy images (i.e. you have a tech sit in front of the computer to start imaging, or do you want unattended imaging where you tell a whole classroom to just update itself)?

While this trigger is not supported by the developers, Tom did look at it and updated it so the fields were escaped properly.

DELIMITER $$

CREATE TRIGGER `new_groupmember_added` 
AFTER INSERT ON `groupMembers` 
FOR EACH ROW
BEGIN

 SET @myHostID = `NEW`.`gmHostID`;
 SET @myGroupID = `NEW`.`gmGroupID`;

 SET @myTemplateID = (SELECT `hostID` FROM `groups` INNER JOIN `hosts` ON (`groupName` = `hostName`) WHERE `groupID`=@myGroupID);

 IF (@myTemplateID IS NOT NULL) AND (@myHostID <> @myTemplateID) THEN
   UPDATE `hosts` `d`, (SELECT `hostImage`, `hostBuilding`, `hostUseAD`, `hostADDomain`, `hostADOU`, 
   `hostADUser`, `hostADPass`, `hostADPassLegacy`, `hostProductKey`, `hostPrinterLevel`, `hostKernelArgs`, 
   `hostExitBios`, `hostExitEfi`, `hostEnforce` FROM `hosts` WHERE `hostID`=@myTemplateID) `s`
   SET `d`.`hostImage`=`s`.`hostImage`, `d`.`hostBuilding`=`s`.`hostBuilding`, `d`.`hostUseAD`=`s`.`hostUseAD`, `d`.`hostADDomain`=`s`.`hostADDomain`,
   `d`.`hostADOU`=`s`.`hostADOU`, `d`.`hostADUser`=`s`.`hostADUser`, `d`.`hostADPass`=`s`.`hostADPass`, `d`.`hostADPassLegacy`=`s`.`hostADPassLegacy`,
   `d`.`hostProductKey`=`s`.`hostProductKey`, `d`.`hostPrinterLevel`=`s`.`hostPrinterLevel`, `d`.`hostKernelArgs`=`s`.`hostKernelArgs`,
   `d`.`hostExitBios`=`s`.`hostExitBios`, `d`.`hostExitEfi`=`s`.`hostExitEfi`, `d`.`hostEnforce`=`s`.`hostEnforce`
   WHERE `d`.`hostID`=@myHostID;

   INSERT INTO `locationAssoc` (`laHostID`,`laLocationID`)
   SELECT @myHostID as `laHostID`,`laLocationID`
   FROM `locationAssoc` WHERE `laHostID`=@myTemplateID;

   INSERT INTO `printerAssoc` (`paHostID`,`paPrinterID`,`paIsDefault`,`paAnon1`,`paAnon2`,`paAnon3`,`paAnon4`)
   SELECT @myHostID as `paHostID`,`paPrinterID`,`paIsDefault`,`paAnon1`,`paAnon2`,`paAnon3`,`paAnon4`
   FROM `printerAssoc` WHERE `paHostID`=@myTemplateID;

   INSERT INTO `snapinAssoc` (`saHostID`,`saSnapinID`)
   SELECT @myHostID as `saHostID`,`saSnapinID` 
   FROM `snapinAssoc` WHERE `saHostID`=@myTemplateID;

   INSERT INTO `moduleStatusByHost` (`msHostID`,`msModuleID`,`msState`)
   SELECT @myHostID as `msHostID`,`msModuleID`,`msState`
   FROM `moduleStatusByHost` WHERE `msHostID`=@myTemplateID;

 END IF;

END;
$$

DELIMITER ;

Here is a great starter script for the advanced menu.
https://forums.fogproject.org/topic/7329/sub-menu-within-fog-advanced-menu

You can also create more parent menu items (in addition to the advanced menu) and use the same concept as above. For example on the same level as the advanced menu, you can create an entry for WinOS setup pxe boot another one for disk utilities and a third for debug utilities. They don’t all have to be in one advanced menu.

You have to remember that you must be on the 1.3.0-rcX build (1.2.0 will not have the utiltiies to manage the iPXE menus from the GUI) and your paste into the parameters field must be a complete iPXE menu, so you must learn iPXE menu design (or find one you can hack up to your needs /like above/. http://ipxe.org/examples

First let me get the warning out of the way. Anytime you setup automated disk killing, you also run the risk of killing your over boss’s computer on accident. Doing this may change your job title to “Unemployed”. I’ve had that title before, I can tell you that you don’t want to have that job for very long.

With that said I don’t have a clear answer. But there is a FOG plugin called “tasktypeedit” that allows you to create new “FOG like” tasks you can assign to hosts.

So in theory you could create a new task called Killdisk and then give it a kernel and kernel parameters to pxe boot the iso you created.

If during testing you created a fog iPXE menu and can boot into the iso from the iPXE menu you can use / move the kernel parameters into the task type edit plugin.

@dureal99d I guess I’ll start with a simple statement wow, that’s quite an nfs export.

I would (personally) collapse them down to this
/var/www/fog/service/ipxe *(ro,sync,no_wdelay,insecure_locks,no_root_squash,insecure)

Actually if it was me I would move my files out of the fog directory all together to avoid them from being clobbered during an upgrade.

I might put them into some place like /opt/bootimgs and then export that location. You should be able to map a directory below your mount (share) point. So if you share /opt/bootimgs you should be able to mount /opt/bootimgs/Centos I would test this from another linux server by using the following command mount -t nfs <fog_server_ip>:/opt/bootimgs/Centos /mnt just to make sure it mounts over correctly with only sharing the /opt/bootimgs

Your advanced menu code for fedora looks spot on. You have to be sure that the vmlinuz file you use is capable of network booting via nfs. Not all of them are. I personally would start with live media for all platforms you want to pxe boot. The distributions should give you guidance on what you have to configure for kernel parameters to pxe boot the target computer.

We all must understand the impact of turning on (or off depending on the logic used) this function. With the display only defined images enabled you will not be able to do a quick image on an unregistered host. Because an unregistered host will not be in fog so there will be nothing to display in that quick image menu. If you turn this feature off then you will be able to quick image any unregistered system, but you will also see all possible images when you try to quick image a registered host.

This is a handy feature as long as you understand the caveats of it being enabled/disabled.

@kwetiaw I did a quick check this AM and there are excellent powershell examples of creating IE favorites and desktop shortcuts. The bit of a pain was automating the creation of google chrome bookmarks. But as Wayne said, this is all doable with a snapin or third party application like PDQ Deploy.

Simple answer is don’t use a slash [ / ] or other special characters in the image name. The slash character is allowed in the file name to setup special file grouping on the storage node.

For example if your image name is “town1/image31” the fog server will put the image name [image31] inside a subfolder [/images/town1] on the storage node. This is done to allow image grouping on the fog server. If this isn’t what you intended to do, take the slash out of the image name.

@Wayne-Workman said in Microsoft Surface Pro 4 with Surface Docking Station - Unable to get boot file:

I just wish I had one of these things to test with. They are just so expensive…

Just remember that the FOG Project team is always willing to accept donations of a surface pro 4, if getting FOG 1.3.0 fully compatible with a surface pro 4 is mandatory for the posters environment.

@x23piracy said in FOG Client / FOS report bios product key to database (Host) Activate through BIOS key (Deployment):

Windows as subscription will come

Um, yeah its already here: https://docs.microsoft.com/en-us/windows/deployment/windows-10-enterprise-subscription-activation

Solution: Switch to Linux Mint and your M$ problems go away.

In an effort to see if I could get a proper configuration for dnsmasq to offer both bios (legacy) and uefi iPXE kernels to the booting target I came up with this after reading many (many) configuration docs.

# Don't function as a DNS server:
port=0

# Log lots of extra information about DHCP transactions.
log-dhcp

# Set the root directory for files available via FTP.
tftp-root=/tftpboot

# The boot filename, Server name, Server Ip Address
# dhcp-boot=undionly.kpxe,,192.168.112.24

# Disable re-use of the DHCP servername and filename fields as extra
# option space. That's to avoid confusing some old or broken DHCP clients.
# dhcp-no-override

dhcp-vendorclass=BIOS,PXEClient:Arch:00000
dhcp-vendorclass=UEFI32,PXEClient:Arch:00006
dhcp-vendorclass=UEFI,PXEClient:Arch:00007
dhcp-vendorclass=UEFI64,PXEClient:Arch:00009

dhcp-boot=net:UEFI32,i386-efi/ipxe.efi,,192.168.112.24
dhcp-boot=net:UEFI,ipxe.efi,,192.168.112.24
dhcp-boot=net:UEFI64,ipxe.efi,,192.168.112.24
dhcp-boot=net:BIOS,undionly.kpxe,,192.168.112.24

# PXE menu.  The first part is the text displayed to the user.  The second is the timeout, in seconds.
pxe-prompt="Press F8 for boot menu", 10

# The known types are x86PC, PC98, IA64_EFI, Alpha, Arc_x86,
# Intel_Lean_Client, IA32_EFI, BC_EFI, Xscale_EFI and X86-64_EFI
# This option is first and will be the default if there is no input from the user.
# PXEClient:Arch:00000
pxe-service=X86PC, "Boot BIOS PXE", undionly
# PXEClient:Arch:00007
pxe-service=BC_EFI, "Boot UEFI PXE-BC", ipxe.efi
# PXEClient:Arch:00009
pxe-service=X86-64_EFI, "Boot UEFI PXE-64", ipxe.efi

dhcp-range=192.168.112.24,proxy

Running wireshark with the above configuration actually sent the right dhcp options to the target computer, but alas the target computer would not boot. Looking at the packet capture I can see the target send out the dhcp discover and both my home router and the dnsmasq device (fog server) respond. But the target never sent a dhcp request, it only started the process again sending a dhcp discover again.

For clarity the FOG server and dnsmasq is running on my FOG-Pi server running raspbian jessie. Dnsmasq version is 2.72. The target computer is a Dell e6230 switched into uefi mode. In the above configuration file 192.168.112.24 is my dnsmasq/FOG-Pi server and my dhcp server is a home router running factory stock firmware.

I do a modification of this (CIDR extraction) for my post install script for proper OU placement.

myip=`ip route get 8.8.8.8 | awk 'NR==1 {print $NF}' | cut -d "." -f1-2`;

case "${myip}" in
     10.1)
         sitecode="NYC";
         timezone="Eastern Standard Time";
         oupath="ou=computers,ou=nyc,dc=domain,dc=com";
         ;;
     10.2)
         sitecode="LA";
         timezone="Western Standard Time";
         oupath="ou=computers,ou=la,dc=domain,dc=com";
         ;;
     *)
         # Default code for the unknowns
         sitecode="CORP";
         timezone="Eastern Standard Time";
         oupath="ou=computers,ou=corp,dc=domain,dc=com";
         ;;
esac

I think it would be a great idea. Any time we can eliminate system errors its a great plan.

Ref: https://forums.fogproject.org/topic/7740/the-magical-mystical-fog-post-download-script/6

Being the daring person I am,. I downloaded the source code for dnsmasq 2.76 to the Raspberry Pi. I checked and gcc was installed so I “thought” I was good to go. I compiled and installed dnsmasq 2.76. Everything went great until I tried to restart the dnsmasq service. The start command responded with an illegal command switch was used to launch the application. There was not indication to what or why just it wasn’t going to start.

After doing a bunch of digging and reverse engineering I found that a few options needed to be defined in the src/config.h file. More precisely.

#define HAVE_DBUS
#define HAVE_IDN
#define HAVE_CONNTRACK
#define HAVE_DNSSEC

As well as some required libraries:

sudo apt-get update
sudo apt-get install -y libdbus-1-dev libnetfilter-conntrack-dev libidn11-dev nettle-dev libval-dev dnssec-tools

Once everything was in place I ran the following command again:
sudo make install

then
sudo service dnsmasq restart

I started wireshark again and pxe booted the target laptop. This time I saw the dhcp discover, offer from both the router and the dnsmasq server, then dhcp request and finally the dhcp ack from the router. !! On the client it had booted to the point the iPXE kernel was initializing devices. (!!)

The rest of the settings didn’t change all I did for this pass is upgrade dnsmasq from 2.72 to 2.76 (the version reported to work with uefi firmware).

I know there was a discussion a while back about this specific issue. I “thought” the developers added that feature request at that time. This allowed only the defined image to be deployed to the computer from the Deploy image menu.

I’m not in the office at the moment, but look in the FOG Settings->FOG Configuration page. Under the boot menu settings there should be a check box about image list or deploy menu (something). Uncheck that and see what happens.