@Sebastian-Roth It did containing

 04/13/2021 11:58:30 Installer Settings successfully saved in /opt/fog-service/settings.json
 04/13/2021 11:58:30 Middleware::Communication Download: http://fog-pxe-srv.XXX.de/fog/management/other/ca.cert.der

@Sebastian-Roth i checked the mono certificates and I did not see any fog ones anymore

I also checked the other issues, but I could only see beautiful green PASS messages

@Tom-Elliott @george1421 @Sebastian-Roth A quick follow up, so I deployed the image to many different PCs now and so far I did only have minor issues which might not actually be related to BTRFS in the first place.

I used to have the partition order:

1. EFI
2. BTRFS
3. SWAP 2GB
   on a VM with a 50GB HDD.

Image options: Single Disk - Resizable - Everything

Everything worked great if I deployed to HDDs with >=50GB.
However, it failed when I tried the deployment to an HDD with 40GB.

It seemed to be something like: The SWAP starting block on the original HDD is on a starting block that is not even present on the 40GB HDD.

So I moved the partition order to:

1. EFI
2. SWAP 2GB
3. BTRFS

And everything works as intended.

I will play around with different approaches though.
Like separate the partitioning from the actual image deployment.
We have many different systems requiring different amounts of SWAP space and/or dual/triple/many boot.
So my idea would be to deploy the partitioning first and afterwards only image the BTRFS partition itself and distribute it to a specified aim partition on the aim PC.

Thanks again for the help!

@george1421 @Sebastian-Roth I just wanted to let you know that I moved to snapins and never regreted it for one second
It is indeed much more flexible and involves way less maintenance on FOG updates.

Thanks again!

@Sebastian-Roth It even worked with my custom FOGMontior wrapper script and I did not receive any errors

Best,
Markus

@Sebastian-Roth Hello, so I tested the installer and did not receive any errors.

@sebastian-roth It sure is!
But I love how flexible FOG is with its postinit and postdownload scripts and the API functionality.
I can really create everything I need, really things as complex as this problem here, by simple using the FOS binaries as building blocks.

I have to say that FOG is indeed an amazing product!

For completeness, I will also provide the postinitscript I wrote to ignore the task on reboot.
It is the same condition I used above

condition
return_value=${?}
if [[ ${return_value} -eq 0 ]]
then
  # Continue with normal imaging
  :
elif [[ ${return_value} -eq 1 ]]
then
  # Continue with normal imaging
  :
elif [[ ${return_value} -eq 2 ]]
then
  # Abort imaging
  . /bin/fog.nonimgcomplete ${mac}
  exit 0
else
  echo 'Return value not yet known'
  exit 1
fi

@Sebastian-Roth Yeah I made it work and let me explain to you why I wanted it
I say wanted, because it is just making the whole process easier for us to maintain and execute.

We have a bunch of laptops that we use for workshops and borrow to students.
They are stored in a laptop charging cart with an attached switch so that they are exposed to the FOG server and WoL is used for imaging.
Afterwards, the laptops are actually used within the same network that has a connection to the FOG server.

Now we could have done the tedious and possibly error prone way:

1. On demand, select the laptops needed and that are still in the cage according to some documentation material manually and add them to a new FOG group.
2. Setup a deploy task; wait to finish
3. Provide the laptop to the user
4. Receive the laptop from the user after usage
5. Choose the same group and provide the “coming home” image that does wipe the laptop from all data

While this is a possible way of doing it, I fear the “worst case” scenario: By accident add an already provided laptop to the group and somewhere in the building you will hear a very loud scream because somebodies PhD Thesis just got remove from the harddrive due to a FOG task formatting the drive.

Therefore, I want those laptops to completely ignore FOG when they left the switch located in the cart, but are available for the next imaging round by just plugging it into the correct switch.
My FOGMonitor job is constantly checking the switch that the laptop is attached to and is ignoring all incoming tasks by ignoring them and additionally delete the task from the FOG server.

This has the additional benefit that the workflow changes as follows:

1. Select the laptop group containing all laptops at the FOG server
2. Deploy the image to every laptop, but only those attached to the switch will listen
3. Provide the laptops
4. Reiceve the laptops
5. Send all laptops the coming home signal
   You might need to remove pending tasks from the laptops that are not conneted to the network at all.

This should work great for us, since we barely have to image different laptops for different purposes exactly at the same time,
And since imaging is so fast, it is also not that bad if all of them are imaged or only the subset that is actually needed.

I hope this makes things a bit more clear

best,
Markus

@Sebastian-Roth Ideally every incoming task just gets ignored by the client and gets marked as done at the server.

I checked how it is done within the FOS in bin/fog.nonimagecomplete and figured everything out!
Thank you for pointing me to the part of the code that does the snapin part!
I will leave my setup here for reference on a Kubuntu 20.04 LTS system (Bash v 5.0.17(1)):

FOG Client running OS

Systemctl settings

# Disable FOGService on startup
systemctl disable FOGService.service
# Enable FOGMonitor on startup (manages FOGService)
systemctl enable FOGMonitor.timer

Systemctl setup

/lib/systemd/system/FOGMonitor.service

[Unit]
Description=FOGMonitor job; Manages the status of the FOGService.service
Before=FOGService.service

[Service]
ExecStart=bash /opt/fog-service-monitor/monitor.sh

[Install]
WantedBy=multi-user.target

/lib/systemd/system/FOGMonitor.timer

[Unit]
Description=Check required FOG status every minute

[Timer]
OnBootSec=0
OnCalendar=minutely

[Install]
WantedBy=basic.target

/opt/fog-service-monitor/monitor.sh

#!/usr/bin/bash
 
function condition(){
  if [[ # PUT YOUR ENABLE FOG SERVICE AND STOP TIMER SERVICE CONDITION HERE ]]
  then
    # This is the behaviour like systemctl enable FOGService
    return 0
  elif [[ # PUT YOUR ENABLE FOG SERVICE CONDITION HERE ]]
  then
    # This is the ENABLE FOG SERVICE condition
    return 1
  else
    # This is the DISABLE FOG SERVICE condition
    return 2
  fi
}

# Run the condition check and do things based on the return value
condition
return_value=${?}
if [[ ${return_value} -eq 0 ]]
then
  # Just like systemctl enable FOGService.service
  systemctl stop FOGMonitor.timer
  systemctl start FOGService.service
  exit 0
elif [[ ${return_value} -eq 1 ]]
then
  mode=start
  ignore_incoming=false
elif [[ ${return_value} -eq 2 ]]
then
  mode=stop
  ignore_incoming=true
else
  # Consistency check between the return values of the condition function and this
  echo "Situation not defined, yet. Define it here after you added more conditions to the condition function"
  exit 1
fi

systemctl ${mode} FOGService.service
web=http://FOG_SERVER_ADDRESS/fog
if [[ ${ignore_incoming} == true ]]
then
  for interface_name in /sys/class/net/*
  do
	mac_address=$(cat ${interface_name}/address)
	if echo ${mac_address} | grep -q '00:00:00:00:00'
	then
		continue
	fi
        uuid=$(dmidecode -s system-uuid)
        # Post_Wipe seems also be able to mark every tasks as complete which is not a snapin.
        curl -Lks --data "sysuuid=${uuid,,}&mac=${mac_address}" ${web}/service/Post_Wipe.php

       # Remove possible snapin tasks
       snapin_id=$(
         curl -Lks --data "mac=${mac_address}" ${web}/service/snapins.checkin.php \
         | grep -o 'JOBTASKID=[0-9]*' \
         | grep -o [0-9]*
       )
       if [[ ${?} -eq 0 ]]
       then
         curl -Lks --data "mac=${mac_address}&taskid=${snapin_id}&exitcode=0" ${web}/service/snapins.checkin.php
       fi
       
  done
fi

Best,
Markus

Hello FOG Team,

OS: Kubuntu 20.04 LTS
FOG server: 1.5.9
FOG client: 0.12.0

I have a wrapper service in place that decides if the FOG client service should run or not if a certain condition is met, e.g. the laptop is attached to a specific switch in the building.
Now while this is working as expected, the problem is that the task sent to this PC is still present at the FOG server because the “Task finished” signal has not been send.

Is there a way to mimic the FOG client behavior and send “Task finished” requests as a response to an incoming task?
I looked at the Zazzles code and how it is done in the Snapin case in the fog-client code, but I could not completely figure it out where the information about the taskId and so on is coming from to put the correct php request together.

Best,
Markus

@Sebastian-Roth No worries, take your time Right now, most mono updates happen during a snapin deployment and as a workaround I copy the needed certificates back to the mono directory at the end of the snapin.
While this is not ideal, it should not happen too often within the next weeks and therefore is not a too pressing issue right now

Ok I also found the answer to my search question:
https://forums.fogproject.org/topic/10036/api/2
The search syntax is slightly different to the news article.

So here would be an example command for completion:

curl -H 'fog-api-token: TOKEN' -H 'fog-user-token: TOKEN' -X GET  http://FOG-PXE-SRV.mpi-dortmund.mpg.de/fog/host | jq '.hosts[] | select(.name == "HOSTNAME") | .name'

Thanks again for letting me do my inner monologue on your platform!

Best,
Markus

Ok that was fast, So I answered my own question with the help of
https://forums.fogproject.org/topic/11058/fog-api/13

curl -H 'fog-api-token: TOKEN' -H 'fog-user-token: TOKEN_USER' -X PUT -d '{"kernelDevice": "/dev/sda"}' http://FOG-PXE-SRV.mpi-dortmund.mpg.de/fog/host/HOST_ID/edit

I checked the API page:
https://news.fogproject.org/simplified-api-documentation/

But it seems that the search option is not working the way I think it works:

curl -H 'fog-api-token: TOKEN' -H 'fog-user-token: TOKEN_USER' -X GET http://FOG-PXE-SRV.mpi-dortmund.mpg.de/fog/search/HOSTNAME

However, my idea for a workaround would be now to parse the host list for the hostname to figure out the HOST_ID and afterwards set the respective entry with the provided infos.
So now the only thing left is to modify the registration form

Best,
Markus

Hello FOG Team,

Almost every machine we are dealing with has more than one hard drive connected, typically one SSD for the OS, one SSD for fast scratch, and one or several for the data.

I realized that I can specify the SSD for the OS in the Host Management Edit Host Primary Disk, however, I would like to deploy images directly after registration and, therefore, it would be great to be able to set it during this process already.

I think I can adjust the registration form similiar to that:
https://forums.fogproject.org/topic/13500/dynamically-patching-fos-using-a-postinit-script

However, I am not sure how I to add the specific entry to the hosts FOG server entry.

I looked at the API system following this guide:
https://news.fogproject.org/simplified-api-documentation/

And I succesfully did

curl -H 'fog-api-token: TOKEN' -H 'fog-user-token: TOKEN_USER' -X GET http://FOG-PXE-SRV.mpi-dortmund.mpg.de/fog/host/list

and realized that it is the kernelDevice entry of my device that I want to modify.

Do you have an advise how to put together the respective “POST” command to change this entry or do you have another suggestion how to approach the problem in the first place?

Thank you!

Best,
Markus

@Sebastian-Roth So I gave it a try and things appear to be working in some way!

Installation looks like that

----------------------------------Information---------------------------------

Version.................................................................0.12.1
OS.......................................................................Linux
Current Path....................................................../home/cadmin
Install Location............................................../opt/fog-service
Systemd...................................................................True
Initd.....................................................................True

-----------------------------------Configure----------------------------------

FOG Server address [default: fogserver]: FOG-PXE-SRV.mpi-dortmund.mpg.de
Webroot [default: /fog]:                 
Enable tray icon? [Y/n]:                 
Start FOG Service when done? [Y/n]:      

----------------------------------Installing----------------------------------

Getting things ready....................................................[Pass]
Installing files........................................................[Pass]
Saving Configuration.................................................... 03/22/2021 08:08:15 Installer Settings successfully saved in /opt/fog-service/settings.json
[Pass]
Applying Configuration..................................................[Pass]
Pinning FOG Project..................................................... 03/22/2021 08:08:15 Installer FOG Project CA successfully installed
[Pass]
Pinning Server.......................................................... 03/22/2021 08:08:15 Data::RSA Unable to use CA cert from /home/cadmin/ca.cert.der, trying cert store now.
 03/22/2021 08:08:15 Data::RSA ERROR: FOG Server CA NOT found in keystore - needs to be installed
 03/22/2021 08:08:15 Middleware::Communication Download: http://FOG-PXE-SRV.mpi-dortmund.mpg.de/fog/management/other/ca.cert.der
 03/22/2021 08:08:16 Installer Successfully pinned server CA cert to CN=FOG Server CA
[Pass]

Starting FOG Service....................................................[Pass]

-----------------------------------Finished-----------------------------------

See /home/cadmin/SmartInstaller.log for more information.

However, this line is huge and red in my terminal and can be a disturbing factor for some people I suppose:
03/22/2021 08:08:15 Data::RSA ERROR: FOG Server CA NOT found in keystore - needs to be installed
Additionally it also does not go away when you install the program a second time on top of the first, so I assume that the keystore is still searched even though it is no longer used

This line is also confusing: See /home/cadmin/SmartInstaller.log for more information.
Because there is no log file created by the installer in the first place (I checked the previous installer 1.12.0 and there also no log file was created).

Prior installation I deleted all the mono certificates that contained FOG, but after the installation I checked the mono certificates and it appears that the tbp file found its way back:

root@pcf-server2021:/home/cadmin# grep FOG /usr/share/.mono/certs/Trust/* Binary file /usr/share/.mono/certs/Trust/tbp-090753F074AB4FB3C022CCC655B02AD21436BAD5E1191CF8870273478E46438D.cer matches

After a encrypten reset, thinks appear to be working though.
I will keep you updated!

@Sebastian-Roth Alright!
I will give it a try now

@Sebastian-Roth Sure I will be around and I will see how I can stop the update from happening

Looking forward to it!

Best,
Markus

Hello FOG Team,

I just encountered the problem, that the FOG certificates are removed when mono is updated.
This is of course horrible, because I need to re-install the FOG client on those machines manually since they lose their connection to the FOG server.

During installation of certifcates it looks like that:

Processing triggers for ca-certificates (20210119~20.04.1) ...^M
Updating certificates in /etc/ssl/certs...^M
0 added, 0 removed; done.^M
Running hooks in /etc/ca-certificates/update.d...^M
^M
done.^M
Updating Mono key store^M
Mono Certificate Store Sync - version 6.12.0.107^M
Populate Mono certificate store from a concatenated list of certificates.^M
Copyright 2002, 2003 Motus Technologies. Copyright 2004-2008 Novell. BSD licensed.^M
^M
Importing into legacy system store:^M
I already trust 131, your new list has 129^M
2 previously trusted certificates were removed.^M
Certificate removed: C=US, S=Illinious, L=Chicago, O=FOG Project, CN=FOG Project CA, E=noreply@fogproject.org^M
Certificate removed: CN=FOG Server CA^M
Import process completed.^M
^M
Importing into BTLS system store:^M
I already trust 129, your new list has 129^M
Import process completed.^M
Done^M
done.

I googled the problem and found this issue:
https://github.com/mono/mono/issues/9496

with the recommendation:

This is expected behaviour, but obviously not desired in this instance.

I’ll think about how to avoid this problem, without losing the (important) ability of cert-sync to remove no-longer-OS-trusted certificates.

Workaround for now: trust the cert at the OS level, by saving it in PEM format as /usr/local/share/ca-certificates/foo.crt

But it seems that the workaround stayed the solution.
Do you think that the described workaround is the best solution in this case or do you have an alternative idea

Best,
Markus

@Sebastian-Roth I successfully finished the FOS kernel build including git
I started with the FOS 1.5.9 TAG. I already started the build before I read your message.

I installed the following packages:

• CA Certificates <- Necessary for git https authentification
• git
• git-crypt <- We use this, so I was happy it is as easy as checking it

And things work great
Thank you for the guidance! It was actually very straight forward.

@george1421 Thank you for the input. As far as I understand it is required to have the FOG client up and running in order to deploy snapins? That actually might be something I will look into as well!
Actually during the FOS rebuild I had a similar idea, but instead of using snapins I was thinking of chrooting into the deployed system and run everything from there.
However, I am not sure if that would be a robust solution.