| Age | Commit message (Collapse) | Author |
|---|
|
After the RESTRICTED view was introduced snmpd requires a network to be
specified. Before adding the RESTRICTED view snmpd always assumed the default
network 0.0.0.0/0.
This commit re-adds the build in default networks for IPv4 and IPv6 and
exposes it as a proper default to the CLI so the user is informed about it:
vyos@vyos# set service snmp community foooo
Possible completions:
authorization Authorization type (default: ro)
+ client IP address of SNMP client allowed to contact system
+ network Subnet of SNMP client(s) allowed to contact system (default:
0.0.0.0/0, ::/0)
|
|
|
|
T4857: SNMP: Implement FRR SNMP Recomendations
|
|
|
|
Excluded to not spam the log as there is an access restriction to that
folder which SNMP user can not access.
|
|
If no client and network is defined only a `community` config
is created. This also adds the `community6` part
|
|
The variable 'client' was accidently used where 'network should
have been used. This lead to missing community6 string when
an IPv6 network was defined instead of an IPv6 client.
|
|
|
|
|
|
|
|
|
|
|
|
Commit 945300c6f5 ("snmp: mibs: import from vyatta-cfg-system") imported
the MIBs from vyatta-cfg-system and provided them with a symlink to
/usr/share/vyos/mibs. The symlink was never installed as the directory already
existed. Adjust the MIBDIRS environment variable to load the MIBs from the
proper VyOS folder and use no symlink at all.
|
|
- Remove all old ifTable entries with the same ifName as newly appeared
interface (with different ifIndex) - this is the case on e.g. ppp interfaces
- Add new op-mode command "restart snmp" to restart the daemon
|
|
|
|
Commit a2ac9fac ("vyos.template: T2720: always enable Jinja2 trim_blocks
feature") globally enabled the trim_blocks feature. Some templates still used
in-line trim_blocks "{%"- or "-%}" which caused miss-placed line endings.
This is fixed by removing all in-line trim_block statememnts of Jinja2 templates.
|
|
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.
|
|
Linux tries to bind sshd to the VRF but it is yet not ready - for any arbitrary
reason. After restarting SSH to often (rate-limiting) it is blocked by systemd.
Using Restart/RestartSec is not enough - systemd services use start rate
limiting (enabled by default). If service is started more than StartLimitBurst
times in StartLimitIntervalSec seconds is it not permitted to start any more.
Parameters are inherited from DefaultStartLimitIntervalSec (default 10s) and
DefaultStartLimitBurst (default 5).
|
|
|
|
|
