Topics created by sudburr

there’s now yet another folder within all the installer for ipxe binaries. squeaky wheel, grease, something blah glah

Confirmed and fixed. Maintained as RC14.

The original HDD as reported by Gnome Partition Editor 0.26.1-5:

Partition | Name | Label | File System | Flags /dev/sda1 | EFI system partition | | fat32 | boot, hidden, esp /dev/sda2 | Microsoft reserved partition | | unknown | msftres /dev/sda3 | Basic data partition | Windows |ntfs | msftdata /dev/sda4 | Basic data partition | WinRE_DRV |ntfs | hidden, diag

Editing d1.fixed_size_partitions of the captured image to be:

:1:2:4

… then deploying the image to a smaller HDD results in this:

* Attempting to expand/fill partitions ... Done * Seems like you are trying to restore to an empty disk. Be aware this will most probably cause trouble. Attempting to deploy image Using Partclone An error has been detected! No image file(s) found that would match the partition(s) to be restored (performRestore> Args Passed: /dev/sda /images/test all Computer will reboot in 1 minute

Deploying the same image to a larger (500 GB) HDD results in:

Partition | Name | Label | File System | Flags /dev/sda1 | EFI system partition | | fat32 | boot, esp /dev/sda2 | Microsoft reserved partition | | unknown | msftres /dev/sda3 | Basic data partition | Windows | ntfs | msftdata (still shrunk at 25.4 GB) unallocated (211.82 GB) /dev/sda4 | Basic data partition | WinRE_DRV | ntfs | hidden, diag (correctly sized to 1000 MB) unallocated (227.29 GB)

GParted initially launches with this error:

Not all of the space available to /dev/sda appears to be used, you can fix the GPT to use all of the space (an extra 2014 blocks) or continue with the current setting?

Selecting FIX or IGNORE doesn’t change the partitions.

So it more or less mirrored the original 256 GB HDD layout onto the 500 GB HDD leaving the extra space after sda4 empty, instead of dumping sda4 onto the end of the space, then expanding sda3 into the donut hole.

< https://youtu.be/If3SXJeZzMQ >

Thank you horse’s mouth!

The reason I created the make_fog_portable script is because we have about 70 sites serviced by VirtualBox servers.

The Oracle VirtualBox VM has a fixed MAC address.

Each of these sites is on its own IP subnet with its own scope properties.

That particular MAC address has an IP reservation, bootfile configuration and a DNS entry at every one of those sites/subnets. This allows any OVB VM to work at any site.

The same goes with the physical servers. If we change the subnet for that site, the script would automatically reconfigure the server at next reboot.

This has the added benefit of my being able to create a FOG server in my DEV environment, on my private scope and not have to worry about configuring the server with the IP of a foreign subnet; I just configure the name.

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

@sudburr In my FOG installation (1.5.5), the value for DATABASE_PASSWORD in config.class.php is in single quotes, so the sed statement for needs to be:

sed -i.bak 's|DATABASE_PASSWORD', '<oldpassword>'|DATABASE_PASSWORD', '<newpassword>')|g' /var/www/html/fog/lib/fog/config.class.php

I would also like to note that the values in .fogsettings are only initial values for during installation. So it does not matter if you patch the password there really (not 100% sure though).

@george1421 It’s RTM now. No longer preview.

Tom has done his best to ensure all of it’s features work. But for instance, Directory cleaner on the legacy client ONLY worked on Windows XP. All the core functionality works - up to Windows 8.1. The legacy client is not supported on Win10 - can you blame it though? The legacy client was developed when XP was the latest - and it’s designed to do stuff to the OS, to the registry, etc. OSs Change. The new fog client should be good for many future versions of Windows, plus Joe is keeping on top of it also.

@Wayne-Workman If I remember correctly there was an issue that @Tom-Elliott found in the current iPXE code. Well not exactly in the code but we saw issues with binaries compiled with a later version. Tom and I talked about git-bisect-ing to find out what exactly is the problem. Unfortunately this would take a little bit of time - although not too much. It’s not too much of trouble if you have a device that hangs on that issue (is it only the surface devices or others as well??) and a couple of hours to bisect from the known working version up to current.

Anyone keen to do this? I should be able to do the bisect-ing and provide the binaries. Who is willing to test?

I had to republish rc 8 which pushed svn up one but I did not update the svn version because it would not have matched git. This is to be fixed when rc 9 is released.

@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.

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

Good to know. Thank you!

Updated with some new formatting .

@sudburr you can do all that with storage nodes. And how many servers to use is up to you. If you want portable virtual boxes, you can do that still.

@sudburr I can see that post you removed, It uses TCP.

Also, see here:
https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#Maintain_Control_Of_Hosts_When_Building_New_Server

That is oriented for migrating to a new server, but it’s the same thing to just move certs to another server for use there too.

You may start looking into Ansible, version 1.7 or greater comes with ability to control windows clients.
http://docs.ansible.com/ansible/intro_windows.html

And ansible is free (I think), but Ansible Tower costs.

I’d be against that.

The certificate is the central and single point of success or failure of security for the fog client. If an attacker could get it by any means at all, all security is compromised. Having an actual feature that allows it to be downloaded would increase the risk of compromise several times fold.

a local admin ought to be the only person that can touch it.