@sebastian-roth Looks typical to me:

;;;;;;;;;;;;;;;;
; File Uploads ;
;;;;;;;;;;;;;;;;

; Whether to allow HTTP file uploads.
; http://php.net/file-uploads
file_uploads = On

; Temporary directory for HTTP uploaded files (will use system default if not
; specified).
; http://php.net/upload-tmp-dir
;upload_tmp_dir =

; Maximum allowed size for uploaded files.
; http://php.net/upload-max-filesize
upload_max_filesize = 3000M

; Maximum number of files that can be uploaded via a single request
max_file_uploads = 20

Wait a second… I’m at 91% consumed on / . I think the package I’m uploading may exceed the available 580MB available on the partition. It may be a little premature of me, but it looks like this one is solved!

@altitudehack Confirmed this was caused by running out of disk space. Growing the disk and retrying it worked, so this is solved. Thank you for your time!

@sebastian-roth Yes, you’re absolutely right! The original had a secondary MAC matching the clone. I deleted it and expect the clone to show up shortly. Thanks for your patience!

@sebastian-roth Perfect. The original install was through a Group Policy .msi push, so I added the newer agent to replace the old one. Appreciate the quick info!

Haven’t really found a great fix here, I’d love to get some logging to work. But this seems to be working better than before. It moves the argument from the calling command and embeds it into the Snapin Arguments:

• Snapin Type: Normal Snapin
• Snapin Run With: powershell.exe
• Snapin File (exists): runCmd.ps1
• Snapin Arguments: "%ProgramFiles%\FusionInventory-Agent\Uninstall.exe /S"

the command in runCmd.ps1 then no longer passes an argument so needs to be changed to:
start-process -filepath "$exe"

That’s awesome! I was hoping there was a simple workaround.
It does look like it completed successfully in seven seconds, but the process didn’t have the expected result. When I run Uninstall.exe /S manually the folder gets emptied. In this case, the files are still present.

Any tips on increasing verbosity or leaving a log of what happened?

Thanks!

I realize this is an oldie but as a feature request it made sense to me to just bump it rather than creating a new one.
I have a program installed that has a built-in uninstaller. I’d like to execute uninstall.exe /S to remove it, however the snapin needs to add a file in order to do so. Guess I could just upload a script with this command in it but it seems much simpler to just allow running a command.
Thanks!

Hi @malansanni70, I could help you figure out how to open ports, but to be clear that’s just one step of many that are necessary to get PXE working. Have you already set DHCP options 66 & 67 and ensured your network is traversable for PXE/TFTP (as in, everything is behind a single router or using iphelper on a larger network)?
Flavor and version of your server’s operating system? What’s your end-goal here?

@george1421 said in User Tracking search not working:

little gear on original post

I see no gear or settings on the original post, leading me to believe this is a moderator-only feature. Thank you for marking the solution!

@george1421 How the heck do I mark the answer as solved on the forum?

I ended up searching for memory_limit in /etc/php*:

grep -r memory_limit /etc/php*

The two active files were /etc/php.ini and /etc/php-fpm.d/www.conf:

/etc/php-fpm.d/www.conf:php_admin_value[memory_limit] = 1024M
/etc/php-fpm.d/www.conf:;php_admin_value[memory_limit] = 256M
/etc/php.ini:memory_limit = 512M
/etc/php.ini:;memory_limit = 128M

I duplicated the lines, commented out the original with ;, then quadrupled the values. Restarted the services with:

systemctl restart httpd
systemctl restart php-fpm.service

User Tracking queries now work as expected.

@george1421
You’re right. Thanks for the tip!

tail /var/log/httpd/ssl_error_log
...
[Thu Dec 02 11:44:24.766930 2021] [php7:error] [pid 24293] [client my_IP:38154] PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 16384 bytes) in /var/www/html/fog/lib/fog/fogcontroller.class.php on line 260, 

The data’s there, and it’s less than 5000 rows, so doesn’t seem like an excessive query:

MariaDB [fog]> select * from userTracking;
+------+----------+-------------+----------+---------------------+--------+------------+---------+
| utID | utHostID | utUserName  | utAction | utDateTime          | utDesc | utDate     | utAnon3 |
+------+----------+-------------+----------+---------------------+--------+------------+---------+
...
...
| 4816 |       41 | jesie          | 1        | 2021-12-02 08:52:08 |        | 2021-12-02 |         |
| 4817 |        6 | magpie         | 1        | 2021-12-02 08:59:26 |        | 2021-12-02 |         |
| 4818 |       20 | lennard           | 1        | 2021-12-02 09:02:32 |        | 2021-12-02 |         |
| 4819 |       57 | albatros         | 1        | 2021-12-02 10:19:25 |        | 2021-12-02 |         |
+------+----------+----------------+----------+---------------------+--------+------------+---------+
4819 rows in set (0.003 sec)

It returns a blank page even when I specify a user and the machine they’re assigned to.

Updated to Version 1.5.9.113 but behavior is still the same. Page never loads, just shows blank.

URL:
https://fogserver.my-domain.com/fog/management/index.php?node=report&sub=file&f=dXNlciB0cmFja2luZw%3D%3D

tail /var/log/php-fpm/error.log shows nothing since I restarted it (the above search was performed after 14:43):

[01-Dec-2021 14:43:58] NOTICE: exiting, bye-bye!
[01-Dec-2021 14:43:58] NOTICE: fpm is running, pid 27319
[01-Dec-2021 14:43:58] NOTICE: ready to handle connections
[01-Dec-2021 14:43:58] NOTICE: systemd monitor interval set to 10000ms