Welcome, Guest. Please login or register.

Author Topic: Problems with NeDi 2.3C and PHP 8.0 / 8.1  (Read 521 times)

ggessler

  • Newbie
  • *
  • Posts: 8
    • View Profile
Problems with NeDi 2.3C and PHP 8.0 / 8.1
« on: May 03, 2024, 01:27:28 pm »
Dear all,

I have upgraded our NeDi 2.0 installation on CentOS to NeDi 2.3 on SLES 15 by upgrading 2.0 -> 2.1 -> 2.3 and have problems with all PHP pages which show e.g. device details (e.g. Devices-List.php or Devices-Status.php).
Both PHP pages are not fully loading, they are both stopping at the table cell which displays device serial number.

Devices-List.php breaks in line 319
Apache error log shows:
[Fri May 03 12:23:09.872768 2024] [php:error] [pid 2947] [client 10.200.249.67:40209] PHP Fatal error:  Uncaught mysqli_sql_exception: Table 'nedi.vendorinfo' doesn't exist in /var/nedi/html/inc/libdb-mysql.php:335\nStack trace:\n#0 /var/nedi/html/inc/libdb-mysql.php(335): mysqli_query()\n#1 /var/nedi/html/inc/libdev.php(1035): DbQuery()\n#2 /var/nedi/html/Devices-List.php(319): InvCheck()\n#3 {main}\n  thrown in /var/nedi/html/inc/libdb-mysql.php on line 335, referer: http://xxxx.xxxx.xxxx/Devices-List.php

Devices-Status.php breaks in line 525 + 1328
Apache error log shows:
[Fri May 03 13:21:32.987417 2024] [php:error] [pid 2959] [client 10.200.249.67:40803] PHP Fatal error:  Uncaught mysqli_sql_exception: Table 'nedi.vendorinfo' doesn't exist in /var/nedi/html/inc/libdb-mysql.php:335\nStack trace:\n#0 /var/nedi/html/inc/libdb-mysql.php(335): mysqli_query()\n#1 /var/nedi/html/inc/libdev.php(1035): DbQuery()\n#2 /var/nedi/html/Devices-Status.php(525): InvCheck()\n#3 {main}\n  thrown in /var/nedi/html/inc/libdb-mysql.php on line 335, referer: http://xxxx.xxxx.xxxx/Devices-Modules.php

[Fri May 03 12:23:38.586608 2024] [php:error] [pid 2950] [client 10.200.249.67:40212] PHP Fatal error:  Uncaught mysqli_sql_exception: Table 'nedi.vendorinfo' doesn't exist in /var/nedi/html/inc/libdb-mysql.php:335\nStack trace:\n#0 /var/nedi/html/inc/libdb-mysql.php(335): mysqli_query()\n#1 /var/nedi/html/inc/libdev.php(1035): DbQuery()\n#2 /var/nedi/html/Devices-Status.php(1328): InvCheck()\n#3 {main}\n  thrown in /var/nedi/html/inc/libdb-mysql.php on line 335, referer: http://xxxx.xxxx.xxxx/Devices-Modules.php

Commenting out all three lines allows the PHP pages to fully render, but obviously the device serial number is missing.

When looking at the "devices" table directly in the database, I cannot see any problem with the content.

Does anyone have a solution / fix for this?

Thanks, Gerhard

rickli

  • Administrator
  • Hero Member
  • *****
  • Posts: 2897
    • View Profile
    • NeDi
Re: Problems with NeDi 2.3C and PHP 8.0 / 8.1
« Reply #1 on: May 10, 2024, 09:56:17 am »
You seem to be missing the vendorinfo table, as it wasn't created when updating from previous versions. NeDi 2.4 will create it with the DB update. Alternatively, you can download the table at http://www.nedi.ch/services/customer-area/index.html and add it via System-Files -> Import Database.
Please consider Other-Invoices on your NeDi installation for an annual contribution, tx!
-Remo

ggessler

  • Newbie
  • *
  • Posts: 8
    • View Profile
Re: Problems with NeDi 2.3C and PHP 8.0 / 8.1
« Reply #2 on: May 17, 2024, 05:48:49 pm »
Dear Rickli,
thank you very much, this did the trick.

But now I run into another problem:
Nedi is no longer able to access the switches with SSH. No matter if I discover a new switch or want to backup the configuration of an existing switch, I always receive error message that usessh policy:

During a backup:
Config (CLI)   ----------------------------------------------------------------  Fri May 17 16:50:52 2024
CLI :ssh connection prohibited by usessh policy
EVNT:MOD=B/1 L=150 CL=cfge TGT=bghsw-700e-IT310-01 MSG=Config backup error: Connection prohibited by usessh policy

During discovery:
GG: usessh == never --
TEL :Connect NeDiService;1@10.202.22.20:23 Tout:10s OS:ProCurve EN:(\x1b\[[;\?0-9A-Za-z]+)+[\w\s()'+.-]+#\s?(\x1b\[[;\?0-9A-Za-z]+)+$
TEL :Connect admin;2@10.202.22.20:23 Tout:10s OS:ProCurve EN:(\x1b\[[;\?0-9A-Za-z]+)+[\w\s()'+.-]+#\s?(\x1b\[[;\?0-9A-Za-z]+)+$
TEL :Connect admin;3@10.202.22.20:23 Tout:10s OS:ProCurve EN:(\x1b\[[;\?0-9A-Za-z]+)+[\w\s()'+.-]+#\s?(\x1b\[[;\?0-9A-Za-z]+)+$
TEL :Connect admin;4@10.202.22.20:23 Tout:10s OS:ProCurve EN:(\x1b\[[;\?0-9A-Za-z]+)+[\w\s()'+.-]+#\s?(\x1b\[[;\?0-9A-Za-z]+)+$
TEL :Connect admin;5@10.202.22.20:23 Tout:10s OS:ProCurve EN:(\x1b\[[;\?0-9A-Za-z]+)+[\w\s()'+.-]+#\s?(\x1b\[[;\?0-9A-Za-z]+)+$
EVNT:MOD=B/1 L=150 CL=cfge TGT=bghsw-700e-IT210-01 MSG=Config backup error: can't start session

My standard setting in nedi.conf was to have usessh commented out so that is tries first SSH then Telnet:
# Set ssh policy for CLI access:
# always        = only explicitly mapped ports will be used with telnet
# never         = never try ssh
# known         = only connects when hostkey is known (add with nedi.pl -k, keyscan or manually with ssh)
# commented     = try whatever will work
;usessh         always-known
;usessh         never

After upgrade to 2.3C it and the new host OS SUSE SLES seems it does not honor what usessh option I set. I started with the above commented out variant of usessh but also tried to set "usessh always". But nothing seem to work.
As perl installation on SLES 15 is a bit unclear, I tried already with different SLES package but also with SSH from CPAN.

Cheers, Gerhard

rickli

  • Administrator
  • Hero Member
  • *****
  • Posts: 2897
    • View Profile
    • NeDi
Re: Problems with NeDi 2.3C and PHP 8.0 / 8.1
« Reply #3 on: May 21, 2024, 10:20:21 am »
Have you tried CLI reset in Devices-Status by clicking on red icon next to CLI? Only then will NeDi retry CLI access. Also I don't think it's related to the update as there were no changes in 2.3...
Please consider Other-Invoices on your NeDi installation for an annual contribution, tx!
-Remo

ggessler

  • Newbie
  • *
  • Posts: 8
    • View Profile
Re: Problems with NeDi 2.3C and PHP 8.0 / 8.1
« Reply #4 on: June 07, 2024, 11:45:55 am »
Hi Rickli,

sorry for the late reply, I was out on vacation.
Yes, I have tried this already several times. Also changed the CLI port in the database to 22 to ensure that SSH is used - but this did not change anything here.

Cheers, Gerhard