Age | Commit message (Collapse) | Author |
|
|
|
The 3rd party library used for calculating the SNMP hashes in advance only
worked for SHA and nod for MD5 as SHA was hardcoded [1]. The code has been
replaced by a class-less implementation providing only the required
functionality.
[1]: https://github.com/TheMysteriousX/SNMPv3-Hash-Generator/issues/2
|
|
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).
|
|
For an unknown reason snmpd not always starts after reboot.
|
|
|
|
airbag must now be explicitly installed.
the patch also allow to fully disables the installation of the logging
code at setup (and not just installing and doing nothing)
|
|
After migrating PowerDNS to systemd and also its configuration files to a
volatile directory in commit 77d725f ("dns-forwarding: T2185: move configuration
files to volatile /run directory") the path for the control file has not
been altered and pushed to the client rec_control binary"
|
|
convert all call to jinja to use template.render
|
|
os.system does print the ouput of the command, run() does not.
A new function called call() does the printing and return the error code.
|
|
As little change a possible but the function call
The behaviour should be totally unchanged.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
A consistency check was missing to prevent deleting the SNMP configuration
but still setting "service lldp snmp enable".
|
|
As we need to operate with usmUser, we can search for it directly if its
present or not. There is always one usmUser entry for the system user.
|
|
|
|
|
|
|
|
|
|
This is actually an "upstream" bug, see [1] but it can be fixed via our own
scripts.
[1]: https://bugs.launchpad.net/ubuntu/+source/net-snmp/+bug/1384122
|
|
This reverts commit 6945b2e3561cd76d193d41dd6ab5249661230460.
|
|
|
|
|
|
Remove informative but noisy messages:
Dec 30 11:45:02 vyos snmpd[2870]: Connection from UDP: [172.16.100.1]:42781 ...
Dec 30 11:45:02 vyos snmpd[2870]: Connection from UDP: [172.16.100.1]:57331 ...
|
|
suppress error message:
Dec 30 11:44:10 LR1 snmpd[2870]: error on subcontainer 'ia_addr' insert (-1)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
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.
|
|
* typo fixed
|
|
Systems not runing BGP won't boot anymore. Syslog shows:
snmpd[5404]: getaddrinfo: inetCidrRouteTable Name or service not known
snmpd[5404]: getaddrinfo("inetCidrRouteTable", NULL, ...): Name or service not known
snmpd[5404]: Error opening specified endpoint "inetCidrRouteTable"
snmpd[5404]: Server Exiting with code 1
snmpd[5401]: Starting SNMP services::
systemd[1]: snmpd.service: control process exited, code=exited status=1
systemd[1]: Failed to start LSB: SNMP agents.
systemd[1]: Unit snmpd.service entered failed state.
This reverts commit e45648cdd5a52569be7f3ac30473b0c7474a7894.
|
|
|
|
|
|
WHen building up the SNMP v2 community ro/rw access all hosts from
a INET version could access even when the community was locked to one
INET family.
Example #1:
set service snmp community bar network 172.16.0.0/12
Allowed access only to IPv4 network 172.16.0.0/12 but it allowed acces from
IPv6 ::/0.
Example #2:
set service snmp community baz network 2001:db8::/64
Limited IPv6 access to 2001:db8::/64 but IPv4 was open to 0.0.0.0/0
|
|
|
|
supress duplicate error messages.
|
|
|