On Tue, Jan 21, 2020 at 3:48 PM Paul Gevers <elb...@debian.org> wrote:
> Control: tags -1 moreinfo > > Hi Jim, > > Thanks for reporting issues you encounter. > You're most welcome, thank you for maintaining software I've found tremendously useful over the last 15 years. > > On 21-01-2020 21:15, Jim McNamara wrote: > > * What led up to the situation? > > Upgraded machine from Stretch to Buster, cacti was upgraded in > process from 0.8.8 to 1.2.2. > > > > * What exactly did you do (or not do) that was effective (or > > ineffective)? > > Any host added through the use of > /usr/share/cacti/cli/add_device.php reports success, but the device-id is > always 0 and the host never appears either in the web interface or via > /usr/share/cacti/cli/add_tree.php --list-hosts > > > > * What was the outcome of this action? > > ++ /usr/share/cacti/cli/add_device.php --template=1 > --description=192.168.112.200 --ip=192.168.112.200 --community=public > > + ADDHOST='Adding 192.168.112.200 (192.168.112.200) as "Generic > SNMP-enabled Host" using SNMP vnet-snmp with community "public" > > Success - new device-id: (0)' > > > > The host is not added, and 0 seems like an odd device-id as they > seem to start from 1 > > > > * What outcome did you expect instead? > > > > Host would be added with the next available device-id, that new > device-id should be reported by the add-device.php script > > I found this upstream report: https://github.com/Cacti/cacti/issues/3111 > Can you check your cacti.log for errors and see if the issue matches? > That is precisely my issue, thank you. The error when trying to add my host shows that net-snmp was being provided as the snmp_version - 01/21/2020 14:44:50 - DBCALL ERROR: SQL Save Failed for Table 'host'. SQL:'INSERT INTO host (`id`, `host_template_id`, `poller_id`, `site_id`, `external_id`, `description`, `hostname`, `notes`, `location`, `snmp_version`, `snmp_community`, `snmp_username`, `snmp_password`, `snmp_auth_protocol`, `snmp_priv_passphrase`, `snmp_priv_protocol`, `snmp_context`, `snmp_engine_id`, `snmp_port`, `snmp_timeout`, `disabled`, `availability_method`, `ping_method`, `ping_port`, `ping_timeout`, `ping_retries`, `max_oids`, `device_threads`) VALUES (267, 1, 1, 1, '', '192.168.112.200', '192.168.112.200', '', '', net-snmp, 'public', '', '', '', '', '', '', '', 161, 500, '', 1, 1, 23, 400, 1, 10, 1) ON DUPLICATE KEY UPDATE `host_template_id`=VALUES(`host_template_id`), `poller_id`=VALUES(`poller_id`), `site_id`=VALUES(`site_id`), `external_id`=VALUES(`external_id`), `description`=VALUES(`description`), `hostname`=VALUES(`hostname`), `notes`=VALUES(`notes`), `location`=VALUES(`location`), `snmp_version`=VALUES(`snmp_version`), `snmp_community`=VALUES(`snmp_community`), `snmp_username`=VALUES(`snmp_username`), `snmp_password`=VALUES(`snmp_password`), `snmp_auth_protocol`=VALUES(`snmp_auth_protocol`), `snmp_priv_passphrase`=VALUES(`snmp_priv_passphrase`), `snmp_priv_protocol`=VALUES(`snmp_priv_protocol`), `snmp_context`=VALUES(`snmp_context`), `snmp_engine_id`=VALUES(`snmp_engine_id`), `snmp_port`=VALUES(`snmp_port`), `snmp_timeout`=VALUES(`snmp_timeout`), `disabled`=VALUES(`disabled`), `availability_method`=VALUES(`availability_method`), `ping_method`=VALUES(`ping_method`), `ping_port`=VALUES(`ping_port`), `ping_timeout`=VALUES(`ping_timeout`), `ping_retries`=VALUES(`ping_retries`), `max_oids`=VALUES(`max_oids`), `device_threads`=VALUES(`device_threads`)' Redoing the call to add and including --version=1 solves things in the short term: ./add_device.php --template=1 --description=192.168.112.200 --ip=192.168.112.200 --community=public --version=1 Adding 192.168.112.200 (192.168.112.200) as "Generic SNMP-enabled Host" using SNMP v1 with community "public" Success - new device-id: (267) Thanks again, sorry I missed the upstream bug. Jim