You could simply create a group that has those specific snap-ins assigned to them and then modify the fog.man.reg or which ever file is being referenced for your registration process to take in a group id. Then pass that to your registration by changing the body of the full_reg function in the lib/reg-task/registration.class.php to update the host’s group. If your fog configuration doesn’t already make the tasks for pushing snap-ins then create some tasks using the host.class.php to queue up those in the same full_reg function at the end after you have created and saved the host.
Best posts made by Dahrell
-
RE: Automatically add FOG Snapin on registration
-
RE: Microsoft Surface Pro 4 (using dock) has Issues with DHCP for Imaging Task
Verified today that it does indeed require the Microsoft Ethernet Adapter on Surface Pro 4 and that it works with a Kernel Argument of has_usb_nic = 1 and Host Kernel of bzImage version 4.13.4! You have to create a host in the FOG Web Interface with the MAC of the adapter. Make sure the dock is removed before booting. When it prompts to remove the usb and replug leave the adapter in. Do not remove and hit ENTER.
Thanks again for your help previously!
Latest posts made by Dahrell
-
RE: 1.6 Issues/Reporting
Not a huge issue by any means, but there’s a small bug with the UI.
When the side menu is collapsed and you hover over “Storage Groups” the list items’ text run out of the containing div.
-
RE: FOG 1.40 - Network traffic does not stop
The first picture you posted showed on the Storage Group Activity that it had two active tasks as of the time of posting. Those tasks must have completed before you checked Active Tasks.
-
RE: 1.6 Issues/Reporting
@tom-elliott No worries, just trying to contribute Thanks for the response! Hope things are working out for you.
-
RE: 1.6 Issues/Reporting
Nope, orphaned or not it still spits out those PHP:warns in the error.log.
I cleaned the hostMAC table where there were no hostID in hosts that existed for a hmHostID which resolved the listings of null for Host Name but then I tried deleting again and no changes were made via “Select All -> Delete Selected”.
-
RE: 1.6 Issues/Reporting
Hi,
I grabbed the working-1.6 branch and am running it through Ubuntu16.04 on Windows as a test environment for the team’s newest releases! I must say the UI looks amazing!
The issue I noticed tinkering with the new UI is that on the “Pending MACs” page (under the hosts dropdown menu on the side nav), when I attempted to select all and delete the entries it doesn’t reflect changes after postback.
After navigating away and back or just refreshing it reflects changes but shows the values for Hostname as null.
These might just be orphaned records that are causing issues but regardless, here is the last 5 lines in apache2 error.log after trying to delete the entries that had their hostname changed to null:
[Tue Jul 10 12:51:10.799229 2018] [php7:warn] [pid 600] [client 169.254.98.2:37676] PHP Warning: ftp_close() expects parameter 1 to be resource, null given in /var/www/fog/lib/fog/fogftp.class.php on line 115, referer: http://169.254.98.2:8080/fog/management/index.php?node=host&sub=pendingMacs [Tue Jul 10 12:51:14.147645 2018] [php7:warn] [pid 600] [client 169.254.98.2:37676] PHP Warning: ftp_close() expects parameter 1 to be resource, null given in /var/www/fog/lib/fog/fogftp.class.php on line 115, referer: http://169.254.98.2:8080/fog/management/index.php?node=host&sub=pendingMacs [Tue Jul 10 12:51:15.069292 2018] [php7:warn] [pid 600] [client 169.254.98.2:37676] PHP Warning: ftp_close() expects parameter 1 to be resource, null given in /var/www/fog/lib/fog/fogftp.class.php on line 115, referer: http://169.254.98.2:8080/fog/management/index.php?node=host&sub=pendingMacs [Tue Jul 10 12:51:16.442140 2018] [php7:warn] [pid 600] [client 169.254.98.2:37676] PHP Warning: ftp_close() expects parameter 1 to be resource, null given in /var/www/fog/lib/fog/fogftp.class.php on line 115, referer: http://169.254.98.2:8080/fog/management/index.php?node=host&sub=pendingMacs [Tue Jul 10 12:51:17.333016 2018] [php7:warn] [pid 600] [client 169.254.98.2:37676] PHP Warning: ftp_close() expects parameter 1 to be resource, null given in /var/www/fog/lib/fog/fogftp.class.php on line 115, referer: http://169.254.98.2:8080/fog/management/index.php?node=host&sub=pendingMacs
Another interesting line amidst all the other warning lines is:
[Tue Jul 10 12:48:19.594482 2018] [php7:warn] [pid 552] [client 169.254.98.2:37584] PHP Warning: gethostbyname(): Host name is too long, the limit is 255 characters in /var/www/fog/lib/fog/fogbase.class.php on line 2159, referer: http://169.254.98.2:8080/fog/management/index.php?node=host&sub=pendingMacs
-
RE: /Fog/management page not coming up
My best guess is that if you navigate to
cd /var/www/fog/management/
and don’t find an index.php file, there’s a chance that you didn’t run the installfog.sh script with the sudo permissions needed to write the files to the proper folders that the apache server needs to complete the request. -
RE: Microsoft Surface Pro 4 (using dock) has Issues with DHCP for Imaging Task
Verified today that it does indeed require the Microsoft Ethernet Adapter on Surface Pro 4 and that it works with a Kernel Argument of has_usb_nic = 1 and Host Kernel of bzImage version 4.13.4! You have to create a host in the FOG Web Interface with the MAC of the adapter. Make sure the dock is removed before booting. When it prompts to remove the usb and replug leave the adapter in. Do not remove and hit ENTER.
Thanks again for your help previously!
-
RE: Microsoft Surface Pro 4 (using dock) has Issues with DHCP for Imaging Task
Yeah they’re forcing only Microsoft PXE devices on Surfaces.
https://docs.microsoft.com/en-us/surface/ethernet-adapters-and-surface-device-deployment
"Booting from the network (PXE boot) is only supported when you use an Ethernet adapter or docking station from Microsoft. To boot from the network, the chipset in the Ethernet adapter or dock must be detected and configured as a boot device in the firmware of the Surface device. Microsoft Ethernet adapters, such as the Surface Ethernet Adapter and the Surface Dock use a chipset that is compatible with the Surface firmware.
The following Ethernet devices are supported for network boot with Surface devices:
Surface USB to Ethernet adapter Surface USB 3.0 Ethernet adapter Surface Dock Surface 3 Docking Station Surface Pro 3 Docking Station Docking Station for Surface Pro and Surface Pro 2
Third-party Ethernet adapters are also supported for network deployment, although they do not support PXE boot."
-
RE: Microsoft Surface Pro 4 (using dock) has Issues with DHCP for Imaging Task
It still won’t get to PXE. I think any non-Microsoft USB peripherals or USB Bootable devices are being ignored on boot? Maybe the updated UEFI firmware has changed the behavior of what peripherals are usable at boot. Once I get to the section where it asks me to replug the generic USB adapter and I move the ethernet over to it, it works on 4.15.2. I tried Kernel Versions 4.10.1 and 4.10.10 with the dock and the adapter by itself but still no success.
-
RE: Microsoft Surface Pro 4 (using dock) has Issues with DHCP for Imaging Task
Yeah I can test if using 4.10 for the dock will work as well.