@sudburr This would do the same but give dates and no-longer active branches too. The count is adjustable. This is a snippet from something I’m working on.

git for-each-ref --count=10 --sort=-committerdate refs --format='%(committerdate:short)_%(refname:short)'

Done as requested. After all, people do like choices.

@wernercd it is worth noting, with the new client rebuilding it is no longer needed. And if for some reason you still need to, there’s automated build scripts available: https://github.com/fogproject/fog-client#building

@Wayne-Workman Added support for persistent MySQL.

My infrastructure is completely based on containers, so it was a nice challenge to integrate FOG as container. At this point its not really a container because no capabilities are dropped and the host network is used.

Normally I would split FOG in multiple containers (MySQL, dnsmasq, tftpboot etc.), but because it’s an also an appliance for me i build a “all-in-one” container.

@george1421 as long as people understand that, then yeah this is great.

Interesting. Thanks for the tip.

Just set this up, thanks

@LibraryMark Look at this.

http://ipxe.org/cmd/login

Also, I have hidden menu turned on, and the iPXE code for the password screen looks like tis:

:menuAccess login params param mac0 ${net0/mac} param arch ${arch} param platform ${platform} param username ${username} param password ${password} param menuaccess 1 param debug 1 isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme :bootme chain -ar http://10.2.1.11/fog/service/ipxe/boot.php##params

So if you look at the above, it collects a username and password on the login screen.
Then, it chains to boot.php and passes the parameters. The web server validates the credentials and if they are good, it provides the full menu via the chaining.

On ipxe.org they give a basic example of verifying the parameters using PHP:
http://forum.ipxe.org/showthread.php?tid=5435

https://wiki.fogproject.org/wiki/index.php?title=Surface_Pro

@Sebastian-Roth Of course that’s fine. You help exactly where it matters most, and that makes a big difference.

Coming back to this topic, I mentioned that scripts could be built to make fog mobile. Well, a few of us here in the FOG community did just that.

Here’s the project link:
https://github.com/wayneworkman/FOGUpdateIP

This basically makes FOG 1.3.0 completely mobile, it allows the FOG server to receive a DHCP address, and then scripts automatically update FOG’s files, database, and automatically re-configure dnsmasq to work with the new IP.

@george1421 I’d like to work with you to get this side project to work with UEFI too, only problem is if we do that, maybe we need to include an actual dnsmasq binary for x86_64, and after the project installer installs dnsmasq, it just swaps out the binary file all sneaky like lol. At least until the current latest dnsmasq version is mainstream.

Added to the wiki here:
https://wiki.fogproject.org/wiki/index.php?title=Include_any_ISO_in_the_FOG_Bootmenu#Gparted

This has been added to the wiki here:
Link

This has been added to the wiki here:

Link

@marcolefo The sleep 5 you’ve added will only happen if the $imgpart is not found. This seems rather pointless if you ask me. (Again following along @Sebastian-Roth I’m not intending to offend, but why does having sleep 5 in a spot where no code is run to begin with “help” a user with multi partition imaging via multicast?

Thanks for the heads-up. I have changed my posted recipe.

@Joe-Schmitt You are welcome! Fogs ability to deploy snapins is awesome and deserves acknowledgement.