Bug 23725 - UDM-Nagios-Integration muss mit ARecord an der Domäne klar kommen
UDM-Nagios-Integration muss mit ARecord an der Domäne klar kommen
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: Monitoring (Prometheus or Nagios)
UCS 3.0
Other Linux
: P5 normal (vote)
: UCS 3.0 - MS2
Assigned To: Janek Walkenhorst
Alexander Kläser
:
Depends on: 23554
Blocks: 23943
  Show dependency treegraph
 
Reported: 2011-09-20 18:04 CEST by Janek Walkenhorst
Modified: 2011-12-13 15:49 CET (History)
2 users (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Janek Walkenhorst univentionstaff 2011-09-20 18:04:21 CEST
Diese Änderung verwirrt die Nagios-Integration. Dies führt zu 
 univentionNagiosHostname: @.univention.qa
an den nagios/service Objekten.

+++ This bug was initially created as a clone of Bug #23554 +++

Für die Samba 4 Anmeldung und GPO Auswertung ist es erforderlich, dass die DNS
Forward Zone eine ARecord Eintrag bekommt. Das müsste per UDM Modul gesetzt
werden können.

root@master5:/usr/share/doc/bind9# univention-ldapsearch -LLL -b
cn=dns,dc=deadlock5,dc=local zoneName=deadlock5.local -s one
dn: zoneName=deadlock5.local,cn=dns,dc=deadlock5,dc=local
nSRecord: master5.deadlock5.local.
objectClass: top
objectClass: dNSZone
objectClass: univentionObject
univentionObjectType: dns/forward_zone
dNSTTL: 10800
relativeDomainName: @
zoneName: deadlock5.local
aRecord: 10.201.5.1
sOARecord: master5.deadlock5.local. root.deadlock5.local. 47 28800 7200 604800
  10800

root@master5:/usr/share/doc/bind9# head -n 20
/var/cache/bind/deadlock5.local.zone 
$ORIGIN .
$TTL 10800      ; 3 hours
deadlock5.local         IN SOA  master5.deadlock5.local. root.deadlock5.local.
(
                                47         ; serial
                                28800      ; refresh (8 hours)
                                7200       ; retry (2 hours)
                                604800     ; expire (1 week)
                                10800      ; minimum (3 hours)
                                )
                        NS      master5.deadlock5.local.
                        A       10.201.5.1
$ORIGIN deadlock5.local.
$TTL 80600      ; 22 hours 23 minutes 20 seconds
_kerberos               TXT     "DEADLOCK5.LOCAL"
$ORIGIN _msdcs.deadlock5.local.
67f44995-a9e7-436a-a82d-108df4e7b2b8 CNAME master5.deadlock5.local.
$ORIGIN _tcp.Default-First-Site-Name._sites.dc._msdcs.deadlock5.local.
$TTL 10800      ; 3 hours
_kerberos               SRV     0 100 88 master5.deadlock5.local.
_ldap                   SRV     0 100 389 master5.deadlock5.local.
root@master5:/usr/share/doc/bind9# host deadlock5.local
deadlock5.local has address 10.201.5.1
root@master5:/usr/share/doc/bind9# 

Siehe auch Bug #23481.
Comment 1 Janek Walkenhorst univentionstaff 2011-09-20 18:11:44 CEST
Die LDAP-Suchfilter wurden angepasst, dass Zonen-Objekte (relativeDomainName=@) ignoriert werden:

univention-directory-manager-modules (7.0.82-1)
Comment 2 Alexander Kläser univentionstaff 2011-09-29 16:15:52 CEST
(In reply to comment #1)
> Die LDAP-Suchfilter wurden angepasst, dass Zonen-Objekte (relativeDomainName=@)
> ignoriert werden:
> 
> univention-directory-manager-modules (7.0.82-1)

QA: Nagios hat zwar nun den korrekten Eintrag, allerdings ist die Abfrage immer noch nicht korrekt, da sie mehrere Einträge liefert. Diese Einträge scheinen mit Samba4 in Verbindung zu sehen:

====================
root@master:~# univention-ldapsearch | \
  grep univentionNagiosHostname | sort | uniq
univentionNagiosHostname: master.univention.qa
====================

Hier das Ergebnis der LDAP-Abfrage:

====================
root@master:~# univention-ldapsearch "(&(objectClass=dNSZone)(aRecord=*)(zoneName=*)(relativeDomainName=*)(!(relativeDomainName=@)))" | ldapsearch-wrapper | grep -e aRecord -e dn:
# filter: (&(objectClass=dNSZone)(aRecord=*)(zoneName=*)(relativeDomainName=*)(!(relativeDomainName=@)))
dn: relativeDomainName=master,zoneName=univention.qa,cn=dns,dc=univention,dc=qa
aRecord: 10.200.26.27
dn: relativeDomainName=gc._msdcs,zoneName=univention.qa,cn=dns,dc=univention,dc=qa
aRecord: 10.200.26.27
dn: relativeDomainName=DomainDnsZones,zoneName=univention.qa,cn=dns,dc=univention,dc=qa
aRecord: 10.200.26.27
dn: relativeDomainName=slave,zoneName=univention.qa,cn=dns,dc=univention,dc=qa
aRecord: 10.200.26.28
====================

→ REOPEN
Comment 3 Janek Walkenhorst univentionstaff 2011-09-30 15:04:27 CEST
univention-directory-manager-modules (7.0.96-1) unstable; urgency=low

  * ignore other new DNS objects (Bug #23725)
Comment 4 Alexander Kläser univentionstaff 2011-10-05 14:13:06 CEST
(In reply to comment #3)
> univention-directory-manager-modules (7.0.96-1) unstable; urgency=low
> 
>   * ignore other new DNS objects (Bug #23725)

QA: OK erst einmal, das System funktioniert.

Da die Suche nichtdestotrotz erst einmal fehleranfällig scheint, wird in neuer
Bug aufgemacht (→ Bug 23943). Es kann wahrscheinlich mit self.info['fqdn'] etc.
gearbeitet werden, aber das müsste genauer geprüft werden. Auf meiner
Testmaschine erhalte ich bspw. zwei Einträge:

====================
root@master:~# univention-ldapsearch
"(&(objectClass=dNSZone)(aRecord=*)(zoneName=*)(relativeDomainName=*)(&(!(relativeDomainName=@))(!(relativeDomainName=*.*))))"|
ldapsearch-wrapper | grep -e aRecord -e dn:
# filter:
(&(objectClass=dNSZone)(aRecord=*)(zoneName=*)(relativeDomainName=*)(&(!(relativeDomainName=@))(!(relativeDomainName=*.*))))
dn: relativeDomainName=master,zoneName=univention.qa,cn=dns,dc=univention,dc=qa
aRecord: 10.200.26.27
dn:
relativeDomainName=DomainDnsZones,zoneName=univention.qa,cn=dns,dc=univention,dc=qa
aRecord: 10.200.26.27
====================

→ erst einmal VERIFIED
Comment 5 Sönke Schwardt-Krummrich univentionstaff 2011-12-13 15:49:01 CET
UCS 3.0-0 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer
neueren Version von UCS erneut auftreten, so sollte dieser Bug dupliziert
werden: "Clone This Bug"