Posts made by JJ Fullmer

@SOSF2 Check out this doc https://docs.fogproject.org/en/latest/change-fog-server-ip-address there are a few other places you need to make changes

@cornycopia Hi!
Are you familiar with powershell at all? If not, it’s too hard to learn,
I have made a powershell module to help with managing these things (see my signature for more links)

For example there’s a command to make a new fog host https://fogapi.readthedocs.io/en/latest/commands/New-FogHost/
I would recommend giving that a go.

That said, let’s take a look at why this isn’t working

The first issue I see with your body is the macs need to be an array
You might also have to have the modules param defined in the body.
In my PowerShell function I have a function to get all the modules and I filter it to the default ones so that the behavior is the same as when you add a host in the gui instead of creating a host with nothing in it.
https://fogapi.readthedocs.io/en/latest/commands/Get-FogModules/

Here’s a simplified table of that output, I think the ids are always the same in all installs, but they could be unique to your install

id name
-- ----
1  Directory Cleaner
2  User Cleanup
3  Display Manager
4  Auto Log Out
5  Green FOG
6  Snapins
7  Client Updater
8  Host Registration
9  Hostname Changer
10 Printer Manager
11 Task Reboot
12 User Tracker
13 Power Management

Anyway, here’s an example of a json body for creating a host with the default service modules enabled (these are my defaults, you may have different ones configured)

{
  "macs": [
    "A4:BF:01:6E:E4:F2"
  ],
  "name": "demo",
  "modules": [
    "7",
    "9",
    "13",
    "6",
    "11",
    "2",
    "12"
  ]
} 

@cul3r0 The https redirect is actually only working for me if I go to the fqdn on http, i.e. http://fog-server.domain.tld will redirect to https but http://fog-server will not redirect.
I’m pretty sure it’s possible to adjust the rules to redirect everything to the fqdn on https. You can probably mess with the rules to make it rewrite anything to go the the fqdn on https

@JJ-Fullmer I captured an image from the surface go 4 with the new kernel that has UFS support and I was able to deploy that image with its 4k block based partition table without issue.
Of course that image can now not be deployed on 512e block based disks.

If I ever get the time, I may try testing manipulation of the parition blocks and using an efi tool in a fog post install script to make it so an image can be deployed to either but its probably unlikely to be possible.

For reference, here’s what the 4k block based partitions look like

d1.partitions

label: gpt
label-id: DEECB42F-8F01-49B9-85BE-8398A932E4E5
device: /dev/sda
unit: sectors
first-lba: 6
last-lba: 31246330
sector-size: 4096

/dev/sda1 : start=         256, size=       76800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=FE5BA595-3498-4D4A-B741-9EB5D84C1EA5, name="EFI system partition", attrs="GUID:63"
/dev/sda2 : start=       77056, size=        4096, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=752C5B50-96B7-4130-9789-9A02B05F8A75, name="Microsoft reserved partition", attrs="GUID:63"
/dev/sda3 : start=       81152, size=    31024716, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=C088525B-56B9-4D7E-A040-1C8F5A782ADC, name="Basic data partition"
/dev/sda4 : start=    31106048, size=      139776, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=E2B6791E-DC55-4039-A658-9007B5749FEE, attrs="RequiredPartition GUID:63"

d1.minimum.partitions

label: gpt
label-id: DEECB42F-8F01-49B9-85BE-8398A932E4E5
device: /dev/sda
unit: sectors
first-lba: 6
last-lba: 31246330
sector-size: 4096

/dev/sda1 : start=         256, size=       76800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=FE5BA595-3498-4D4A-B741-9EB5D84C1EA5, name="EFI system partition", attrs="GUID:63"
/dev/sda2 : start=       77056, size=        4096, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=752C5B50-96B7-4130-9789-9A02B05F8A75, name="Microsoft reserved partition", attrs="GUID:63"
/dev/sda3 : start=       81152, size=    31024716, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=C088525B-56B9-4D7E-A040-1C8F5A782ADC, name="Basic data partition"
/dev/sda4 : start=    31106048, size=      139776, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=E2B6791E-DC55-4039-A658-9007B5749FEE, attrs="RequiredPartition GUID:63"

Something odd is it doesn’t look like the main OS partition (sda3) shrunk, but it for sure did as it is only 10.56 GB on the server (compressed size) and deploys around 20 GB on the client, same size as the VM based 512e image.

@AlleneBrick @alexamore90
Lets clarify further first.

What DHCP server are you using and what is its ip?
What do you want the fog server ip to be?

@alexamore90 I’m not sure where you are wanting to change your ip.

Is fog your DHCP server?
Are you needing to change the ip of the Fog Server?
Did you change or add a different DHCP server on this new ip?
If it’s a new DHCP server, have you pointed option 66 to fog? (https://docs.fogproject.org/en/latest/installation/network-setup/dhcp-server-settings/)

@FRG You can specify the disk to image to in the host settings screen with the host primary disk field

By default Fog will use the first disk it finds (I believe) or you can specify per host.
i.e. if you wanted it to image to a second disk you could specify /dev/sda2 or /dev/nvmen1n1

@cul3r0 It does not, that configuration is elsewhere. If you enabled https support at install then you have to do something special to get that disabled for pxe because it embeds the self-signed cert made at install into the on-the-fly pxe compilation process.

@ksrvpvl Ok, I think I’m getting what you’re saying. I misunderstood earlier.

Is your custom menu option to boot to winPE working? Or are you asking for help with that part too? There is some very basic guidelines on creating a winpe boot option here https://docs.fogproject.org/en/latest/ipxe

The plugin system needs to be enabled in the fog settings, then you should see a plugin menu where you can activate and then install the tasktypeedit plugin. Some basic plugin system info is here https://docs.fogproject.org/en/latest/plugins but it looks like you got past that bit now.

I also found this post https://forums.fogproject.org/topic/10274/creating-task-with-tasktypemanagement?lang=en-US&page=1 where someone was doing the same thing. Perhaps it may offer some help.

It’s looking like I have to find a way to either capture the image or a separate image from a device that defaults to 4k logical sectors or a way to force the device to change sector size to 512 when deploying a 512e based image

I tried hdparm but got this error

hdparm --set-sector-size 512 --please-destroy-my-drive /dev/sda

/dev/sda:
READ_LOG_EXT(SECTOR_CONFIGURATION) failed: No such file or directory

I also tried capturing the image using the new kernel on the off chance that would make a difference, but no good.

I guess I will have to try making an image from a 4k native device since it’s not being changed?

@Sebastian-Roth or @Tom-Elliott any chance you have some time to help me out with this issue?
It’s looking like its a 4k block issue.
I was trying to find a formulaic way to change the partitions files to line up to the 4k layout, like dividing by 8 and some other tweaking as needed but found it more complicated than expected.

Any ideas?

The image did complete but it did not boot into Windows. Looks like I need to embed the storage controller driver for UFS.

Or it could be a 512b vs 4k block disk type issue.

So more findings

Did a test of a different image that is based on /dev/sda instead of /dev/nvmeXnX

That image deployed with the modified kernel just fine (minus booting to the OS, but that was a windows server image, which I didn’t expect to work on a surface go).

But wait there’s more!

As I started playing around in a debug session I found that the UFS disk wants to have a sector size of 4096. This is the dump after manually creating the partitions to match the d1.minimum.partitions of the image

 sfdisk --dump /dev/sda
label: gpt
label-id: 745A6813-735A-4940-840D-28D0E805850A
device: /dev/sda
unit: sectors
first-lba: 6
last-lba: 31246330
sector-size: 4096


/dev/sda1 : start=         256, size=       25600, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=CFB2D745-2975-480D-BD56-EA18B65E03C5, name="EFI system partition", attrs="GUID:63"
/dev/sda2 : start=       25856, size=        4096, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=57426B89-9DEE-4BDF-9CBF-E9452D985FD5, name="Microsoft reserved partition", attrs="GUID:63"
/dev/sda3 : start=       29952, size=     7340032, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=857B1626-9DC1-44FD-8120-2AB922BBBD85, name="Basic data partition"
/dev/sda4 : start=     7369984, size=      140032, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=DE086091-5C6A-4D63-89E2-579581B9BD63, attrs="RequiredPartition GUID:63"

Whereas the header of d1.minimum.partitions in my normal base image is 512, though it seems like it might actually be 2048 based on math of partitionSectors/sector-size = size in MB (but I might be wrong about that formula, it’s been a minute since I’ve had to deal with sectors).

This is the contents of my d1.minimum.partitions from the image I want to deploy

label: gpt
label-id: 745A6813-735A-4940-840D-28D0E805850A
device: /dev/nvme0n1
unit: sectors
first-lba: 34
last-lba: 83886046
sector-size: 512

/dev/nvme0n1p1 : start=        2048, size=      204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=CFB2D745-2975-480D-BD56-EA18B65E03C5, name="EFI system partition", attrs="GUID:63"
/dev/nvme0n1p2 : start=      206848, size=       32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=57426B89-9DEE-4BDF-9CBF-E9452D985FD5, name="Microsoft reserved partition", attrs="GUID:63"
/dev/nvme0n1p3 : start=      239616, size=    57417925, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=857B1626-9DC1-44FD-8120-2AB922BBBD85, name="Basic data partition"
/dev/nvme0n1p4 : start=    82761728, size=     1120256, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=DE086091-5C6A-4D63-89E2-579581B9BD63, attrs="RequiredPartition GUID:63"

I tried what @Sebastian-Roth mentions in another post here https://forums.fogproject.org/topic/15608/imaging-from-large-drive-to-small-drive/4?=1700488459744 and what @Tom-Elliott mentions here https://forums.fogproject.org/topic/13004/error-trying-to-restore-gpt-partition-tables-on-multiple-dell-machines/13?=1700488480736

When I try to restore from the original file I get an error saying the last-lba is invalid/too high for the disk.

What’s weird, is I can use that syntax to restore the server based image, and that min parts file also has a higher lba, but it makes a little sense as the final sector is below the drive’s “31246330” last lba.

cat ../SVR-Base-Stable/d1.minimum.partitions
label: gpt
label-id: 0B6865A1-3053-4F45-9371-B73F033C7395
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 188743646
sector-size: 512

/dev/sda1 : start=        2048, size=      204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=3DF3DEBB-C856-4CC2-9263-EAF0AABF2DDF, name="EFI system partition", attrs="GUID:63"
/dev/sda2 : start=      206848, size=       32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=C9738054-91F0-4B3A-AFFA-A9C9ABCC9663, name="Microsoft reserved partition", attrs="GUID:63"
/dev/sda3 : start=      239616, size=    27175378, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=42364778-3F9E-4421-88C1-698974428C14, name="Basic data partition", attrs="GUID:63"
/dev/sda4 : start=    27415040, size=     1269760, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=CA25B771-91EC-40A3-B200-1360371A0AD8, attrs="RequiredPartition GUID:63"

So I made a backup of my original image mbr and patition files and edited the d1.minimum.partitions to look like this

label: gpt
label-id: 745A6813-735A-4940-840D-28D0E805850A
device: /dev/nvme0n1
unit: sectors
first-lba: 6
last-lba: 31246330
sector-size: 4096

/dev/nvme0n1p1 : start=        256, size=      25600, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=CFB2D745-2975-480D-BD56-EA18B65E03C5, name="EFI system partition", attrs="GUID:63"
/dev/nvme0n1p2 : start=      25856, size=       4096, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=57426B89-9DEE-4BDF-9CBF-E9452D985FD5, name="Microsoft reserved partition", attrs="GUID:63"
/dev/nvme0n1p3 : start=      29952, size=    7340032, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=857B1626-9DC1-44FD-8120-2AB922BBBD85, name="Basic data partition"
/dev/nvme0n1p4 : start=    7369984, size=     140032, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=DE086091-5C6A-4D63-89E2-579581B9BD63, attrs="RequiredPartition GUID:63"

Making it match the dump after making the partitions by MB and GB size manually.

After editing it this command worked without error

sfdisk /dev/sda < /images/Base-Stable/d1.minimum.partitions

So I made a new version of the d1.mbr
sgdisk -b /mnt/d1.mbr /dev/sda

And popped that on the server to test deploying with that. ON this test, I’m not editing the d1.partitions or d1.shrunken.partitions which may make it so it doesn’t expand properly, but we’ll see how it goes…

It got past the previous errors and is now imaging! woo hoo!
How to fix this permanently though, that’s a different question.

@matthewadams12 Why do you need the Fog Server to be offline?
Maybe there’s a solution where we can isolate just the part you want to isolate. i.e. if you are trying to remove internet access where images are stored you could setup a storage node and keep that offline after initial install. The storage node would also need packages and updates to fog, but you could capture them during updates on the main server and then sneakernet them to the storage node.

Storage nodes are just what I’m using as an example. If it’s not the images stored on the server you’re trying to isolate, then there could still be another solution. You could also firewall the server with your external firewall or the os firewall to only allow access to the fog github page for update downloads and then the repo sites that download the package updates?

Just thought I’d throw out some other possibilities.

@ksrvpvl said in ability to load a menu item on a specific machine as an immediate task:

@baovipboy156 I don’t understand where is this plugin? is there documentation?

There is documentation! https://docs.fogproject.org/en/latest/tasks
The documentation is still under construction a bit, but task info can be found there

Another minor bugfix release, I left a random ‘a’ at the end of a line.
Also added a switch to set-fogsnapins for running the repair-fogsnapinassociations before attempting to add new ones

Release notes: https://github.com/darksidemilk/FogApi/releases/tag/2311.6.4
PSGallery: https://www.powershellgallery.com/packages/FogApi/2311.6.4

@cul3r0

I have such a redirect

<VirtualHost *:80>
    <FilesMatch "\.php$">
        SetHandler "proxy:fcgi://127.0.0.1:9000/"
    </FilesMatch>
    KeepAlive Off
    ServerName ip.of.fog.server
    ServerAlias hostnameOfFogServer
    DocumentRoot /var/www/html/
    <Directory /var/www/html/fog/>
        DirectoryIndex index.php index.html index.htm
    </Directory>
    RewriteEngine On
    RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
    RewriteRule .* - [F]
    RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
    RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-d
    RewriteRule ^/fog/(.*)$ /fog/api/index.php [QSA,L]
</VirtualHost>

This is assuming you have your cert configured in ssl.conf too.
I’m running centos with httpd as that might make a difference if you’re running debian based apache

@processor Are we good to mark this as solved then?

Made a pull request for including the ufs in the kernel config
https://github.com/FOGProject/fos/pull/78

Probably should get it fully working before doing that pull though

@SEBASTIAN-ROTH any thoughts?

@lan The latest “public” version of fog is 1.5.10
The dev-branch version install is described in the latter sections of this doc
https://docs.fogproject.org/en/latest/install-fog-server