Testers

@Tom-Elliott said in FOG User Tracking -Search:

1.6

I have ## Version: 1.5.7.56 installed…
what repo is 1.6 in?

@Daniel-Miller said in FOG User Tracking -Search:

@Greg-Plamondon said in FOG User Tracking -Search:

I checked the userTracking table in the fog database and it has 22104 records

You can keep pushing execution time out, but it is quite possible that you may have too many entries for php to handle the data in a reasonable time frame, especially if this instance has been running for a while. If you don’t need the historical data, truncating the userTracking table (truncate table fog.usertracking) as suggested in https://forums.fogproject.org/topic/11713/503-service-unavailable-error/54 should get it up and running and will show data going forward until it gets too ungainly again.

I was able to truncate the table and then run a report. I wish i was able to store more records.

@Daniel-Miller said in FOG User Tracking -Search:

Good, the values are changing.

It may take upwards of a minute or two depending on how many entries are getting pulled.

I checked the userTracking table in the fog database and it has 22104 records
By the way, this hasn’t worked for us for quite some time, I just never got around to reporting it.
but now I have been getting a lot of requests for reports and it was nice to be able to quickly generate what time a user logged into the pc.

@Daniel-Miller said in FOG User Tracking -Search:

Good, the values are changing.

there is also an execution time limit that should be set in one of the ini / conf files as well. I believe the setting is max_execution_time which I think takes a value in seconds and defaults to 30. you may want to play with that value to see if you can get a response in a reasonable time. It may take upwards of a minute or two depending on how many entries are getting pulled.

So far I have changed the /etc/php.ini max_execution_time = 300 with no luck.

[Fri Dec 06 14:20:04.488209 2019] [proxy_fcgi:error] [pid 2045] (70007)The timeout specified has expired: [client 192.168.10.170:63425] AH01075: Error dispatching request to :, referer: http://10fogserver.mtstrans.com/fog/management/index.php?node=report&sub=file&f=dXNlciB0cmFja2luZw==```

First let me preface this with I don’t feel wifi is the proper technology to use for imaging. I do acknowledge there are certain circumstances where it is the only option. For that reason I worked out a path to image over wifi. To be able to successfully do this the FOG tech will need to be able to boot the target device using FOS loaded onto a usb flash drive. Since we are dealing with WIFI leaving iPXE out of the solution was the best route. To that end if you use the usb booting methodology you the FOG tech will give up certain features that are supplied by iPXE.

I’m mainly documenting this process in case has to duplicate the process some time in the future. To successfully build the wifi option you will need to have a buildroot and linux kernel environment. For buildroot I used 2019.02.4 and for the linux kernel linux-4.19.65

For the linux kernel here is the patch from the FOS 1.5.7 base image
kernel_4.19.65_wifi.patch-1.5.7.txt

For buildroot here is the patch from the FOS 1.5.7 base image
BR-wireless.patch-1.5.7.txt

In the build root environment these are the applications I added to the build

Target packages  --->
 Networking applications  --->
 [*] iw

 [*] wireless-regdb
 [*] wireless tools
 [*]   Install shared library
 [ ] wireshark
 [*] wpa_supplicant
 [*]   Enable nl80211 support
 [ ]   Enable AP mode
 [*]   Enable autoscan
 [*]   Enable EAP
 [*]   Enable HS20
 [*]   Enable syslog support
 [*]   Enable WPS
 [*]   Install wpa_cli binary
 [*]   Install wpa_client shared library
 [*]   Install wpa_passphrase binary

In addition I had to create and patch 2 startup files that go into …/board/FOG/FOS/rootfs_overlay/etc/init.d directory.
S35wifiset.txt

and I added a bit of code to S40network
S40network.txt

That code would be in this section of S40network

Here are two wifi configuration files that go into the …/board/FOG/FOS/rootfs_overlay/etc directory
wpa_default.conf.txt
wpa_supplicant.conf.txt

Kernel parameters added:
ssid == SSID to connect to
ssidpw == SSID Password of the wifi SSID
ssidkeymgmt == Key Managment method will set the key_mgmt= value in the wpa_supplicant.conf file.

    echo "Starting $iface interface and waiting for the link to come up"
    echo -e "auto $iface\niface $iface inet dhcp\n\n" >> /etc/network/interfaces
    /sbin/ip link set $iface up

    ## New code start
    if [ ! -z "$ssid" ]
    then
        read isWifi <<< $(/sbin/iwconfig $iface 2> >(awk '{print toupper($2)}'))
        if [ "$isWifi" != "NO" ];
        then
            echo "Assigning WiFi drivers to $iface"
            /usr/sbin/wpa_supplicant -B -i$iface -c/etc/wpa_supplicant.conf -Dnl80211,wext -s -I/etc/wpa_default.conf
            sleep 10
        fi
    fi
    ## New code end

   # Wait till the interface is fully up and ready (spanning tree)
    timeout=0
    linkstate=0

The FOS Linux USB grub configuration file would look like this to support wifi.

set myfogip=192.168.1.100
set myimage=/boot/bzImageWiFi
set myinits=/boot/initwifi.xz
set myloglevel=4
set timeout=-1
set ssid=mudpuppy
set ssidpw=idontknowit
insmod all_video

menuentry "1. FOG Image Deploy/Capture" {
 echo loading the kernel
 linux  $myimage loglevel=$myloglevel initrd=init.xz root=/dev/ram0 rw ramdisk_size=275000 keymap= web=$myfogip/fog/ boottype=usb consoleblank=0 rootfstype=ext4 ssid=$ssid ssidpw=$ssidpw
 echo loading the virtual hard drive
 initrd $myinits
 echo booting kernel...
}

menuentry "2. Perform Full Host Registration and Inventory" {
 echo loading the kernel
 linux  $myimage loglevel=$myloglevel initrd=init.xz root=/dev/ram0 rw ramdisk_size=275000 keymap= web=$myfogip/fog/ boottype=usb consoleblank=0 rootfstype=ext4 mode=manreg ssid=$ssid ssidpw=$ssidpw
 echo loading the virtual hard drive
 initrd $myinits
 echo booting kernel...
}

menuentry "3. Quick Registration and Inventory" {
 echo loading the kernel
 linux  $myimage loglevel=$myloglevel initrd=init.xz root=/dev/ram0 rw ramdisk_size=275000 keymap= web=$myfogip/fog/ boottype=usb consoleblank=0 rootfstype=ext4 mode=autoreg ssid=$ssid ssidpw=$ssidpw
 echo loading the virtual hard drive
 initrd $myinits
 echo booting kernel...
}

menuentry "4. Client System Information (Compatibility)" {
 echo loading the kernel
 linux  $myimage loglevel=$myloglevel initrd=init.xz root=/dev/ram0 rw ramdisk_size=275000 keymap= web=$myfogip/fog/ boottype=usb consoleblank=0 rootfstype=ext4 mode=sysinfo ssid=$ssid ssidpw=$ssidpw
 echo loading the virtual hard drive
 initrd $myinits
 echo booting kernel...
}

menuentry "5. Quick Deploy an Image" {
 echo loading the kernel
 linux $myimage root=/dev/ram0 rw ramdisk_size=275000 ip=dhcp web=$myfogip/fog/ consoleblank=0 loglevel=4 type=down img=Win7SP1x64 ftp=$myfogip imgType=n imgPartitionType=all osid=5 storage=$myfogip:/images/ capone=1 boottype=usb ssid=$ssid ssidpw=$ssidpw
 echo loading the virtual hard drive
 initrd $myinits
 echo booting kernel...
}

menuentry "6. FOG Debug Kernel" {
 echo loading the kernel
 linux  $myimage loglevel=7 init=/sbin/init root=/dev/ram0 rw ramdisk_size=275000 keymap= boottype=usb consoleblank=0 rootfstype=ext4 isdebug=yes ssid=$ssid ssidpw=$ssidpw
 echo loading the virtual hard drive
 initrd $myinits
 echo booting kernel...
}

@AdrianW changing the image definition and the directory structure in the /images directory should do it. Just note the “-M” it self should not cause the issue but a “<space>-M” would or any “<space>-<character>” would be interpreted by iPXE as a command line switch.

But your right the last thing you did, should be the first place you look.

@Tom-Elliott I haven’t looked just yet, but there should be a sysctl.conf file in FOS Linux for 1.5.x too.

As I said before FOS Linux isn’t a general purpose OS. We need it to image as fast as possible, power saving states are not wanted or needed. So turning off sleep states for any device should be preferred. I just noticed as I worked on a Dell 9020 there was a specific firmware parameter to disable APST sleep/power management states for pcie devices. When I saw that I went, “Hey I know what that does…”

@Sebastian-Roth said in Very slow cloning speed on specific model:

nvme_core.default_ps_max_latency_us=0

I don’t see an issue with just adding into sysctl inside FOS and not worry about passing it. That way the variable conversion won’t have an issue. Also since its a nvme specific kernel tweak, if nvme isn’t use (i.e. sata disk) then the kernel “should” ignore it. I only say “should” because we don’t have a large enough sample population to say yes or no yet. But that is just my opinion.

As I said before the OP did a great job helping us come up with a sound solution. Without having the troubled hardware in front of us it would have been impossible to find a solution.

I still think adding the nvme-cli tool to FOS will add value in trying to debug issues later on too.

@AdrianW There isn’t a -M option in the ipxe menu you posted.

To add a little clarity

1. What were you doing when it threw this -M error? Just booting into the ipxe menu to register or where you trying to image?
2. Do you get the same results when just booting into register or only when imaging?
3. Can you get A computer to fail with the -M error message and then run Tom’s query again but with the mac address of the computer that threw the error like this http://10.0.0.1/fog/service/ipxe/boot.php?mac=00:00:00:00:00 where 00:00:00:00:00 == the mac address of the computer that generate the error.

I have seen sometimes users naming the image name with something like “Win10 -May2020” Might confuse the iPXE boot loader.