@kinger37 While now this is off point, it started me thinking…

There is an older linux version that could be used in FOG post install script to set/change the boot order, I may need to play a bit with my dev environment.
http://www.dell.com/support/home/us/en/04/Drivers/DriversDetails?driverId=K3RNG

While this reference shows how to enable the TPM chip with MDT, the concepts are the same for dealing with a bios password with cctk.
http://www.daina84.org/bitlocker-mdt-dell-and-tpm

@Wayne-Workman said in Rudimentary Shell Script - SVN Update for CentOS 6.7:

The best suggestion still stands though - move to CentOS 7. There’s no reason not to, it’s a free and open OS.

I would be totally for it, although this server does nothing but sit there and run fog – which is what a server is supposed to do, now that I think about it.

That main reason is redoing the hardware RAID and making sure that is all set right as rain, and that all of our images make the transfer. It’s one of those too much to do in too little of a time frame – I mean this server has been here about 4 years before I got this position and it was still running FOG .29 (While the most updated version was 1.2.0).

More or less, I am stuck with it for the time being.

In place upgrade probably should not mess anything up, but the should is what I am skeptical about.

Hi,

normally every common installer has silent parameters, if not just googling will bring you sites that may list such parameters, even when hidden. So installing software is in normal not more then a single batch line.

One example: http://www.itninja.com/

Regards X23

@cerebron That is a great tip! Thank you for posting!

#wiki worthy

@Wayne-Workman said in New Fog client and security:

@LibraryMark said in New Fog client and security:

It’s just that for my situation, in a public library with public hosts on a network totally separate from our staff net, I am not sure I have a need for bullet-proof security there.

You’re public users are not a security risk? And I know you say you have HDD locking software (Centurion SmartShield or Faronics DeepFreeze probably), but this doesn’t really matter. If there’s a security hole and someone knows how to exploit it, they can exploit it every time they want. Once there’s a compromise, those computers are no longer safe for users to use, no matter how many times they are rebooted and ‘reset’. The legacy client is not secure. The legacy-enabling functionality server-side is also not secure. It is advised that once you have moved to the new fog client, to remove legacy passwords from the FOG server.

We are using Reboot Restore Rx. Are you talking about the fog client still?

@Wayne-Workman said in FOG Imaging Over MPLS:

Throwing options out there… Intel NUC with a 120GB drive, fanless, for 230 bucks. You could totally make these into fog storage nodes (George already did, I think).
http://www.thebookpc.com/product-p/de3815tykhe.htm?gclid=CMKPvuSQvc4CFQuLaQodNsUEhA

Yeah. probably not those. We used them for a few digital signage projects. They are a bit sluggish with the single core atom processor. (windows performance index of 1.1) You can get a dual core celeron with wireless and bluetooh card build it for just a little more and they are smaller: http://www.thebookpc.com/product-p/dn2820fykh.htm?gclid=CKTtmP2Rvc4CFQaQaQodiNkLYg

Or an i3 for about $270USD https://www.amazon.com/Intel-D34010WYK-DisplayPort-i3-4010U-Consumer/dp/B00F3F381A

You have to understand these are kit computers, you also need to purchase ram and a hard disk (SSD) to make it a complete bit of kit.

Thank you above command working…And i got the loaction of the files

Storage nodes per-building is also an option.

If you want to go with a mobile fog laptop server using dnsmasq, I actually have a project that can automate this for you.

@Wayne-Workman Agreed, I figured I should file it as a bug anyway. Thanks for the help here. I’ll post shortly regarding this.

@cnewman402
Check out what I have done in my server with this iPXE boot menu. I’ve got quite a few ISO’s booting on my setup using memdisk.

:dban menu DBAN Nuke Menu item autonuke AutoNuke DoD 3-Pass item zero AutoNuke 1-Pass Zero Wipe item choose-disk Single Disk Selection item return Back to top menu... item choose --default return --timeout 10000 target && goto ${target} :autonuke kernel http://${fog-ip}/dban/dban.bzi nuke="dwipe --autonuke" silent vga=785 boot || goto failed :zero kernel http://${fog-ip}/dban/dban.bzi nuke="dwipe --autonuke --method zero" silent vga=785 boot || goto failed :choose-disk kernel http://${fog-ip}/dban/dban.bzi nuke="dwipe" silent vga=785 boot || goto failed :return chain ${boot-url}/service/ipxe/boot.php?mac=${net0/mac} || prompt goto MENU :WHDD kernel http://${fog-ip}/whdd/whdd.bzi initrd http://${fog-ip}/whdd/initramfs boot :HDT initrd http://${fog-ip}/hdt/hdt.iso chain http://${fog-ip}/hdt/memdisk iso raw boot :AVG initrd http://${fog-ip}/avg/avg.iso chain http://${fog-ip}/avg/memdisk iso raw boot :BreakIn initrd http://${fog-ip}/breakin/breakin.iso chain http://${fog-ip}/breakin/memdisk iso raw boot

@Wayne-Workman Sounds good. I appreciate the advice! I’m just glad it installed. 🙂

@Joe-Gill Yep. Correct until Tom makes another change to it.

@sudburr said in What is the Automatic Order of Operations of the New Fog Client?:

I would strongly vote against renaming and joining the domain in a single reboot. This can lead to Active Directory issues. Namely you end up with two objects on the AD, one with the original name and another with the new name, or it may retain the old name anyways.
My vote is to mandatory restart after renaming, then mandatory restart after joining the domain. This is the MS method as well.

I would agree. I have experience in this area, it’s never gone well.

@Wayne-Workman
Ok… so once I made some tweaks on this… I ran into a small issue getting the DBAN working properly while doing the timeout config. Ultimately here is where I stand with my current menu. This includes a new choice for disk selection as well as a default timeout of 10 seconds. It will then kick back to the main menu if it times out. I reverted back to using ${fog-ip} as well. After looking back at it as my ${boot-url} is http://${fog-ip}/${fog-webroot}. but all of my ISO’s whether mounted or chained using memdisk are mounted or stored in a directory off of webserver root instead of buried under the fog subdirectory.

:dban menu DBAN Nuke Menu item autonuke AutoNuke DoD 3-Pass item zero AutoNuke 1-Pass Zero Wipe item choose-disk Single Disk Selection item return Back to top menu... item choose --default return --timeout 10000 target && goto ${target} :autonuke kernel http://${fog-ip}/dban/dban.bzi nuke="dwipe --autonuke" silent vga=785 boot || goto failed :zero kernel http://${fog-ip}/dban/dban.bzi nuke="dwipe --autonuke --method zero" silent vga=785 boot || goto failed :choose-disk kernel http://${fog-ip}/dban/dban.bzi nuke="dwipe" silent vga=785 boot || goto failed :return chain ${boot-url}/service/ipxe/boot.php?mac=${net0/mac} || prompt goto MENU

Excellent. Thank you! It’s good to know that a netdom pull is no longer required.

Good to know. Thank you!

Celebrate your vestigial umbilical cord!

@Wayne-Workman i am not really used with github but i can upload it somewhere and share it sure.
Give me some time, if you like you can share it via github.

EDIT:

Post 1 updated @Wayne-Workman

Regards X23

@cnbgeren Yeah it looks like your dhcp server isn’t running.

Since it appears you have a unbuntu server you might want to review this document. https://help.ubuntu.com/community/isc-dhcp-server