vyos-1x.git/src/migration-scripts/snmp, branch mergify/bp/circinus/pr-4091

migration: T6007: convert all migration scripts to load as module

2024-09-11T16:53:48+00:00

(cherry picked from commit 26740a8d583f64dc0a27b59dd4ae303056972c0b)

T6199: remove unused Python imports from migration scripts

2024-04-06T08:46:30+00:00

T5427: Fix migration script arguments len expects 2 args

2023-08-02T09:12:23+00:00

The script's name is always provided as the first argument sys.argv[0] Expected length for argv is 2 (script itself + config file) Change: 'if (len(argv) < 1)' to 'if len(argv) < 2'

T5001: Replace links to the phabricator site

2023-02-12T19:55:16+00:00

Replace links to the phabricator site from https://phabricator.vyos.net to https://vyos.dev

T4857: Cleaning pr

2023-01-18T15:16:05+00:00

snmp: T2687: precalculate snmpv3 encrypted keys

2020-07-11T15:55:21+00:00

As of now when adding new credentials for any SNMPv3 user we submit the credential either plaintext or encrypted. A plaintext credential will be hashed by SNMPd in the background and then passed back into the CLI so it's not stored in cleartext. This feels like the wrong way in changing the CLI content with data produced by a 3rd party daemon which implements the service. It feels like the tail wiggles the entire dog. This should be changed in the following way: - After retrieving the plaintext password from CLI, use Python to hash the key in advance - Re-populate the encrypted key into the CLI and drop the plaintext one - Generate service configuration and continue startup of SNMPd This also fixes a race condition when SNMPd started up but not properly provided the hasehd keys in the configuration resulting in a ConfigurationError. Now as we also support binding SNMPd to a VRF this fixes a deadlock situation on bootup as we can only bind late to the VRF and require up to 5 restarts of the service - but the service will never start.

snmp: T1769: remove TSM (Transport Security Mode) support

2019-10-27T03:29:31+00:00

The SNMPv3 TSM is very complex and I know 0 users of it. Also this is untested and I know no way how it could be tested. Instead of carrying on dead and unused code we should favour a drop of it using a proper config migration script.

snmp: T818: T1738: remove per user/trap engine id

2019-10-27T03:07:11+00:00

As of the SNMP specification an SNMP engine ID should be unique per device. To not make it more complicated for users - only use the global SNMP engine ID.