Cacti 1.2.9 SNMPv3 errors when changing multiple devices

[bmfmancini]

Hey guys

I noticed that when you mass change devices the following error occours

2020/03/05 20:41:00 - CMDPHP SQL Backtrace: (/host.php[70]:form_actions(), /host.php[284]:api_device_change_options(), /lib/api_device.php[333]:db_execute_prepared()) 2020/03/05 20:41:00 - CMDPHP ERROR: A DB Exec Failed!, Error: Unknown column 'snmp_security_level' in 'field list' 2020/03/05 20:41:00 - CMDPHP SQL Backtrace: (/host.php[70]:form_actions(), /host.php[284]:api_device_change_options(), /lib/api_device.php[326]:db_execute_prepared()) 2020/03/05 20:41:00 - CMDPHP ERROR: A DB Exec Failed!, Error: Unknown column 'snmp_security_level' in 'field list'

The device will continue to show down and SNMPV3 although the information shows filled in the device form the device will show a snmp host error

Steps to reproduce

go to console select multiple devices click dropdown and select change device settings fill out snmpv3 options

Notice no error comes up but in the log you will see the dbexec failure and device wont work on snmp

[bmfmancini]

These are the colums I see

| snmp_community | varchar(100) | YES | | NULL | | | snmp_version | tinyint(1) unsigned | NO | | 1 | | | snmp_username | varchar(50) | YES | | NULL | | | snmp_password | varchar(50) | YES | | NULL | | | snmp_auth_protocol | char(6) | YES | | | | | snmp_priv_passphrase | varchar(200) | YES | | | | | snmp_priv_protocol | char(6) | YES | | | | | snmp_context | varchar(64) | YES | | | | | snmp_engine_id | varchar(64) | YES | | | | | snmp_port | mediumint(5) unsigned | NO | | 161 | | | snmp_timeout | mediumint(8) unsigned | NO | | 500 | | | snmp_sysDescr | varchar(300) | NO | | | | | snmp_sysObjectID | varchar(128) | NO | | | | | snmp_sysUpTimeInstance | int(10) unsigned | NO | | 0 | | | snmp_sysContact | varchar(300) | NO | | | | | snmp_sysName | varchar(300) | NO | | | | | snmp_sysLocation | varchar(300) | NO | | | |

Oddly enough I have snmpv3 devices working just fine but those came in via autom8 thankfully this is a lab and not prod I was about to roll out 1.2.9 next week

[bmfmancini]

BTW this was a upgrade from 1.2.7 to 1.2.9 just in case that helps

[bmfmancini]

I did the following just for a test and seems to solve the issue ALTER TABLE host ADD snmp_security_level varchar(255);

Now funny thing If I delete the affected devices then re-add them via AUTOM8 they go in just fine Also you can move from snmpv3 to v2 without an issue its just v2 to v3 where this problem came up

The only thing is that this is a remote poller setup so I am sure that creating the colum manually doesnt replicate to the other pollers unless I am mistaken ?

This is the data that starts to get populated in the table I had just put varchar255 tempoarily but I assume that this table if its even supposed to be there should be something else

MariaDB [cacti]> select snmp_security_level from host where snmp_security_level like "%auth%"; +---------------------+ | snmp_security_level | +---------------------+ | authPriv | +---------------------+ 1 row in set (0.00 sec)

MariaDB [cacti]>

[bmfmancini]

Alright so I checked my prod instance which is on 1.2.7 this colum doesnt exist there and moving from v2 to v3 works like a charm

So it looks like there is an issue with the save function going into the wrong colum I belive its an issue with the api edit device

[netniV]

So, I believe that the snmp_security_level field is supposed to be a virtual field which is defined based on snmp_auth_protocol and snmp_priv_protocol which is why you don't see it in the host definition.

However, the form save tries to push that field out to the remote poller because it exists, so it should really be unset before the api_device_save() call in the data array.

I'm going to get a second opinion before I change that, but so far that's my understanding since $snmp_security_level is barely anywhere in the code, but $snmp_auth_protocol and $snmp_priv_protocol are heavily used.

[bmfmancini]

Yeah I confirm this is even present in 1.2.7 as well but in that case changing to v3 works fine but it does yield and error in the log

[TheWitness]

There should be no snmp_security_level in the host table period. You should drop that column.

[netniV]

Then we need to make sure that the field isn't attempting to be replicated unnecessarily. I am assuming it's coming from the html form data rather than the table defintiion.

[bmfmancini]

Thanks guys

Yea I just added that column to see what data would be populated that was not added by the installer

On Sat., Mar. 7, 2020, 5:27 a.m. Mark Brugnoli-Vinten, < notifications@github.com> wrote:

Then we need to make sure that the field isn't attempting to be replicated unnecessarily. I am assuming it's coming from the html form data rather than the table defintiion.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Cacti/cacti/issues/3326?email_source=notifications&email_token=ADGEXTFXC2PSZNWCP65TEELRGIOP5A5CNFSM4LCWVO42YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEODVOEI#issuecomment-596072209, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADGEXTFL3LN6ECR44GKEC5LRGIOP5ANCNFSM4LCWVO4Q .

[bmfmancini]

This also happens on single poller systems as well I just tested on 1.2.10 same deal even though its a standalone setup

[TheWitness]

I think this is really not an issue. Basically, you just need to remove that column. Likely you created while doing some testing. Close if you concur.

[bmfmancini]

I only created that column because I was curious on what would be populated the error came up before I made that column

but if you think this is just a dummy alarm then I would say we should be good Maybe we could document these types of errors so people dont get hung up on why there is an error showing

[netniV]

@TheWitness is this a documentation issue?

[TheWitness]

@bmfmancini added the column on his own while trying to figure things out. The only thing to be documented is that the column is interpreted and not stored in the database. But no one should be messing with the database, so we should just close it.