Best posts made by Wayne Workman

If we can specify a FTP path for storage nodes, and that path be used for all things related to FTP with that storage node, this would permanently solve all issues with using NASs with FOG.

I feel like this feature is very needed as the issue of using various brands of NAS repeatedly arise in the forums. Additionally, there is a slue of WiKi articles just on using various NAS devices with FOG that are… sometimes… poorly written and confusing and often specific to one type of setup with one type of NAS device. These articles are fairly unmanageable because everyone with WiKi access does not have access to all these devices in order to update or improve the article’s content.

I suppose you could just disable the DHCP service and set a static address.

However, you know that if you disable DHCP, you’ll then need to rely on a properly configured DHCP server. When I say properly configured, I mean options 066 and 067, the boot file and next server.

To stop DHCP,
/etc/init.d/isc-dhcp-server stop

To set a static interface, look at the file /etc/network/interfaces and find your interface in there.

Example:

iface eth0 inet static
    address 10.0.0.100
    netmask 255.255.255.0
    gateway 10.0.0.1

After changing and saving the file, run /etc/init.d/networking restart

And at this point, I’ll always recommend FOG Trunk to people, but defiantly not on Ubuntu 11.

@mtmulch I help run FOG Trunk at 6 (soon to be 21) public schools. Respect the Trunk - it is a great thing to have it virtualized with snapshots before each major change or upgrade. Backup your DB often, keep your old DB backups. And don’t upgrade on a whim. Upgrade when you have a need to do so.

And of course, if you have any issues; the fog community is always willing to lend assistance.

@Arrowhead-IT Robocopy ??

Can we get some comments in that script?

I’ve said it before and I’ll say it again because I really think I’m right on this…

Download should be changed to “Deploy Image”

Upload should be changed to “Capture Image”

Nobody can confuse that terminology.

Also I’ll point out that If you have a feature name that NEEDS a description, and an alternative name that DOES NOT need a description, obviously the one that does NOT need a description is better named.

@Souldoubt said in Suggestions for server space recommendation and samba storage:

@Wayne-Workman

Any performance benefits/hits to storing the images in on the same FS as the FOG server?

Nope, other than everything being self contained. That’s how probably 95% of fog sites are. Large sites use multi-node setups.

Is there a best practices document for FOG that I can refer to.

Not really. There are some partitioning considerations that you need to think about, that’s probably the most important thing to get right from the start. Once you get into the groove of FOG, you will start doing things your way. We have some tutorials in the WiKi that are written for the absolute Linux newbie. If you’re a newbie I would recommend following one of the tutorials, and going with CentOS 7 only because it’s tutorial is up to date and I haven’t made tutorials for other distros yet… But if you wanted to go with another distro, we can help you along here in the forums.

@Trevelyan The only way to find out is to play around with it.

I’d suggest first creating a single partition disk resizeable image - and then just specify in the host’s general properties which Host Primary Disk to use. To find out what that is for the 2nd drive, boot into a debug upload task, and just find the name that fog uses to refer to the 2nd disk. It’ll be in the devices virtual file system ( /dev ), it’ll likely be /dev/sdb but you must look to be sure. Specify the correct Host Primary Disk in the host’s properties page and then do an image capture as usual.

Then try to deploy that image to a test machine (not your golden machine) and just see what happens. Make sure you specify the Host Primary Disk parameter for the test machine.

If that works as you want, try it on a different model test machine, with maybe a different sized hdd in it. See what happens.

Please let us know how it goes and what you learn.

@Arrowhead-IT said:

I hadn’t noticed that the hashes were different before, so I checked mine and they are different.

This is by design. https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#Security_design

Hello Developers,

I think this would be a super-simple request to implement and would greatly clarify all confusion about this topic.

Take this screen shot for example - it’s the Java MSI that comes packaged with the offline installer.

I’ve configured it to execute the snapin with this command:

 msiexec /i Java_8u60_x32.msi /quiet

So - I want another field in the snapin that is dynamically generated AS YOU EDIT the snapin - which is also READ ONLY - only for informational purposes.
I’d like the field to be called “Command to be executed” and it just list - in this example - this:

 msiexec /i Java_8u60_x32.msi /quiet

Does this make sense? Would this not clear up a ton of confusion?

@arduinoAndMore Check your cables first.
Check iptables second. iptables -v -L

also, can you connect a laptop or something to the network and see if you get DHCP via the laptop’s OS?

@mrayzies Thanks for raising these concerns.

All computers ship with public root certificates already installed. This includes Windows, OSX, Android, Linux, iOS, and so on.

The Dell laptops sound like they were shipped with Dell’s PRIVATE key… big no-no… someone should be fired over that.

Superfish had the functionality to install a new public root cert on the system it ran on without the user’s permission, which is why it was dangerous.

The ESET antivirus was just outright terribly written and designed antivirus.

@Jbob could best explain how the FOG Client’s public cert and authority is set up, since he designed the new client.

@Arrowhead-IT said:

Just make new images in the fog gui with the same settings and point them to the file names and they should work. Does that make sense?

People always mess that up.

Moved to Feature Requests.

When people like @george1421 say things like “oh that’s easy, just carefully do this then this then this then this…” Chances are they can get it done within a few hours.

I myself don’t see how it’s easily possible because not all ISOs work exactly the same. The kernels are in different directories, inits might be in different directories. Some might just flat out not work with NFS like WinPE or similar. I got a DBAN ISO to work across HTTP for instance… While the NFS method might be easy to automate for the mounting and menu entry aspects - All the ohter aspects will prove to be very difficult to script… just because there are so many differences across different ISOs.

That and… it’s not the intention of FOG to deliver ISOs on a boot menu. The intention of FOG is to create a seamless imaging environment and to reduce the workload associated with that imaging. Anything extra is a big bonus.

The @Developers have already provided a highly advanced boot menu editing system. That’s their way of saying “Here, use this for all that other stuff you want to do.”

Most information on that can be found here: https://wiki.fogproject.org/wiki/index.php?title=FOG_Client

As of svn 4724 cloud 6112 I am able to successfully upload a GPT type disk from this computer using “Single Disk - Resizable” type images - in UEFI mode using ipxe.efi

Secure boot had to be totally disabled though.

@Jamie-Read said:

it is version 1.2.0 and version 3.0 or fog service
thanks

The legacy client (the fog client you’re using) was written during XP’s time. It’s no surprise it doesn’t work on Windows 10. And updates/patches to the legacy client have been discontinued.

We have a new client. It’s quite amazing. And right now, it’s only available to FOG Trunk users. Fog Trunk is the developmental version of fog.

Several others and myself have used fog trunk in production for quite some time. It’s fairly stable, and works with newer hardware, and there are massive improvements to both security and performance. That said, minor bugs come and go. You just report them here and the developers take care of them, usually posting a patch within hours. (compared to microsoft posting a patch to a publically known problem 9 to 14 months later, same goes for Google, Android, and Apple).

Let me know if you’d like to try it out.

@Tom-Elliott But why have the default values putting things in such spread out locations? The defaults should be safe(er).

@george1421 According to rfc4578, Option 97 is one of the public DHCP options - meaning vendors can use it for whatever they want, including nothing. https://tools.ietf.org/html/rfc4578

That’s why there isn’t a DHCP option for 97 listed in the ISC-DHCP manual:
https://linux.die.net/man/5/dhcp-options

OR - set it up as a storage node. NFS and FTP, that’s all you need. No mounting or anything like that.

@anthonyglamis said:

Trust chain did not complete to the known authority anchor. Errors: The signature of the certificate cannot be verified.

That’s the issue.

Try to reinstall the client on that image, and then re-upload and try again. If it’s still not working, try resetting the encryption on the problematic target host.