SNMP auf UCS?

UCS - Univention Corporate Server
1

Hi,

isher überwache ich die Leistungswerte meiner Linux Server via SNMP und Cacti. Das sind:
-Netzwerk/ Interface
-Hauptspeicher
-CPU Nutzung
-Load
-Festplattenplatz
-Swap Aktivität
-Swap Platz

Ich habe jetzt noch nichts zu SNMP auf dem UCS finden können- außer irgendwelche Traps zu Nagios (was ich bisher beides nicht nutze).

Welchen Weg soll ich gehen, um SNMP zu aktivieren? Das normale net-snmp Paket von Debian und dann selbst konfigurieren? Wie schalte ich 161/ UDP frei in der Firewall?

Danke!

/knebb

2

Ich würd mir das mal angucken:

$ aptitude search snmp i libnet-snmp-perl - Script SNMP connections i A libsnmp-base - SNMP (Simple Network Management Protocol) MIBs and docu i A libsnmp-session-perl - Perl support for accessing SNMP-aware devices i A libsnmp15 - SNMP (Simple Network Management Protocol) library p python-pysnmp-common - Python SNMP library for agents and managers (version se p python-pysnmp4 - Python SNMP library for agents and managers (unstable b i snmp - SNMP (Simple Network Management Protocol) applications p snmpd - SNMP (Simple Network Management Protocol) agents p univention-snmp - UCS - SNMP client configuration p univention-snmpd - UCS - snmpd configuration

3

Das meine ich ja mit “selbst installieren”. Dachte, vielleicht gibt es einen offiziellen Weg von Univention.

Bleibt dennoch die Frage nach der Firewall mit Port 161/UDP.

/knebb

4

Du schriebst nichts von “selbst installieren”, nur was von “selbst konfigurieren”. Und genau das scheint nicht nötig zu sein, da es Univention-Pakete gibt. Und diese werden vermutlich auch selber ein Firewall-Regel anlegen. Ich würds einfach mal ausprobieren.

5

Jo, probiert.

[code][root@rem ~]# nmap -sU -p161 192.168.6.5

Starting Nmap 5.21 ( http://nmap.org ) at 2013-09-01 22:39 CEST
Nmap scan report for 192.168.6.5
Host is up (0.0016s latency).
PORT STATE SERVICE
161/udp closed snmp

Nmap done: 1 IP address (1 host up) scanned in 13.11 seconds
[/code]

Wie öffne ich den Port?

6

Z.B. so:

ucr set security/packetfilter/package/snmp/udp/161/all=ACCEPT
ucr set security/packetfilter/package/snmp/udp/161/en=snmp
/etc/init.d/univention-firewall restart
7

Wohl eher nicht… :frowning:
Wobei ich natürlich zugeben muß, daß ich noch nicht überprüft habe, was die Befehle im Detail machen…

root@rem:/etc/snmp# ucr set security/packetfilter/package/snmp/udp/161/all=ACCEPT Create security/packetfilter/package/snmp/udp/161/all File: /etc/security/packetfilter.d/10_univention-firewall_start.sh File: /etc/security/packetfilter.d/80_univention-firewall_policy.sh root@rem:/etc/snmp# ucr set security/packetfilter/package/snmp/udp/161/en=snmp Create security/packetfilter/package/snmp/udp/161/en File: /etc/security/packetfilter.d/10_univention-firewall_start.sh File: /etc/security/packetfilter.d/80_univention-firewall_policy.sh root@rem:/etc/snmp# /etc/init.d/univention-firewall restart Stopping Univention iptables configuration::. Starting Univention iptables configuration::Bad argument `161' Try `iptables -h' or 'iptables --help' for more information.

Und der Port ist immer noch zu:

[code][root@rem ~]# nmap -sU -p 161 192.168.6.5

Starting Nmap 5.21 ( http://nmap.org ) at 2013-09-01 23:17 CEST
Nmap scan report for 192.168.6.5
Host is up (0.0015s latency).
PORT STATE SERVICE
161/udp closed snmp

Nmap done: 1 IP address (1 host up) scanned in 13.11 seconds
[/code]

8

Hm, ich hab das jetzt nur analog zu den Vorhanden Variablen gemacht. Anscheinend scheint das nur für Deb-Pakete zu sein. Bist du sicher, daß da nichts angelegt wurde? Was sagt

ucr search --brief snmp
9

Hallo,

ich denke schon, dass die UCR-Variablen angelegt wurden, allerdings mit der falschen Syntax.
Vorgeschlagen wurde:

ucr set security/packetfilter/package/snmp/udp/161/all=ACCEPT ucr set security/packetfilter/package/snmp/udp/161/en=snmp

Es müsste folgendermaßen lauten:

ucr set security/packetfilter/package/snmp/udp/161/all=ACCEPT ucr set security/packetfilter/package/snmp/udp/161/all/en=snmp

Eigene Filtersettings sollten auch über die vorgesehen Variablen gesetzt werden.

security/packetfilter/tcp/.*: <empty> Variables to setup custom firewall rules (e.g. security/packetfilter/tcp/2000/all=REJECT, security/packetfilter/udp/500/all=ACCEPT).
Generell werden die Filter-Variablen mit Paketnamen im Key Variablen, über das entsprechende Konfigurationspaket erzeugt:

univention-install univention-snmp

Die fehlerhafte Variable sollten Sie zuvor entfernen:

ucr unset security/packetfilter/package/snmp/udp/161/en

Sehen Sie gern auch die folgende Dokumentation:
Network Packet Filter

Mit freundlichen Grüßen,
Tim Petersen

10

Naja, das sagt schon, daß die Dinger irgendwo angelegt wurden.

root@nrem~# ucr search --brief snmp security/packetfilter/package/snmp/udp/161/all: ACCEPT security/packetfilter/package/snmp/udp/161/en: snmp

Aber das Ergebnis ist das gleiche. Werde wohl doch richtig tief in die REgistry einsteigen müssen, was?
:frowning:

11

Hallo,

wie in meiner Antwort bereits beschrieben ist die Variable so weiterhin nicht korrekt.
Bitte führen Sie konkret die folgenden Schritte aus, die das Verhalten beheben sollten:

ucr unset security/packetfilter/package/snmp/udp/161/en ucr set security/packetfilter/package/snmp/udp/161/all/en=snmp /etc/init.d/univention-firewall restart

Mit freundlichen Grüßen,
Tim Petersen

12

Hallo,

hatte die Antwort von heute früh erst später gesehen…

Habe die Schritte nun wie vorgeschlagen ausgeführt und auch die alten Variablen gelöscht (unset). Soweit scheint der Port jetzt auch frei zu sein:

root@rem:~# iptables -L -n |grep 161 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:161

Jetzt wurde ja noch gesagt, daß ich das Paket so installieren soll:

 aptitude search snmp

Habe das auch via “aptitude install snmpd” installiert, in /etc/snmp/snmpd.conf angepaßt. Der Prozess lief ja auch.
Aufgrund des heutigen Postings habe ich nun den offizielleren Weg genommen:

univention-install univention-snmp

Dummerweise ist jetzt zwar der Port offen, aber der snmpd läuft nicht…

Starte ich ihn mittels “service snmpd start”, beendet er sich sofort wieder und ich finde das im Logfile:

syslog:Sep 2 11:15:02 rem snmpd[487]: payload OID: snmperrErrMessage syslog:Sep 2 11:15:02 rem snmpd[487]: /etc/snmp/snmpd.conf: line 145: Error: unknown payload OID syslog:Sep 2 11:15:02 rem snmpd[487]: Unknown payload OID: snmperrErrMessage syslog:Sep 2 11:15:02 rem snmpd[487]: /etc/snmp/snmpd.conf: line 145: Error: Unknown payload OID syslog:Sep 2 11:15:02 rem snmpd[487]: trigger OID: snmperrErrorFlag syslog:Sep 2 11:15:02 rem snmpd[487]: /etc/snmp/snmpd.conf: line 145: Error: unknown monitor OID syslog:Sep 2 11:15:02 rem snmpd[487]: Turning on AgentX master support. syslog:Sep 2 11:15:02 rem snmpd[487]: net-snmp: 33 error(s) in config file(s) syslog:Sep 2 11:15:02 rem snmpd[487]: Error opening specified endpoint "udp:161" syslog:Sep 2 11:15:02 rem snmpd[487]: Server Exiting with code 1

Schaue ich mit Zeile 145 an, steht da:

138:# 139:# Event MIB - automatically generate alerts 140:# 141: # Remember to activate the 'createUser' lines above 142:iquerySecName internalUser 143:rouser internalUser 144: # generate traps on UCD error conditions 145: defaultMonitors yes 146: # generate traps on linkUp/Down 147:linkUpDownNotifications yes 148:

Und nein, damit kann ich leider garnichts anfangen :frowning:

13

Für den Daemon ist natürlich univention-snmpd zuständig. Eigentlich nahm ich an das Paket wäre längst installiert.

14

Wie sind denn die Zusammenhänge?

Muß ich zu dem eigentlichen snmpd immer auch das univention-* dazu packen? Warum installiert das eine denn nicht automatisch das andere?

Naja.

Habe jetzt jedenfalls die snmpd.conf gelöscht, beides nochmal installiert und jetzt geht es:

aptitude install snmpd univention-install univention-snmp

Danke!