System diagnostic Errors

UCS - Univention Corporate Server
#1

Hi, Who can help me to fix there errors:
Samba replication status error:

Traceback (most recent call last):
  File "/usr/lib/pymodules/python2.7/univention/management/console/modules/diagnostic/__init__.py", line 270, in execute
    result = execute(umc_module, **kwargs)
  File "/usr/lib/pymodules/python2.7/univention/management/console/modules/diagnostic/plugins/41_samba_tool_showrepl.py", line 149, in run
    problems = list(drs.replication_problems())
  File "/usr/lib/pymodules/python2.7/univention/management/console/modules/diagnostic/plugins/41_samba_tool_showrepl.py", line 98, in replication_problems
    for replica_info, neighbour in self.neighbours():
  File "/usr/lib/pymodules/python2.7/univention/management/console/modules/diagnostic/plugins/41_samba_tool_showrepl.py", line 93, in neighbours
    (info_type, info) = self._replica_info(replica_info_direction)
  File "/usr/lib/pymodules/python2.7/univention/management/console/modules/diagnostic/plugins/41_samba_tool_showrepl.py", line 87, in _replica_info
    (info_type, info) = self.drsuapi.DsReplicaGetInfo(self.handle, 1, req1)
WERRORError: (8442, 'WERR_DS_DRA_INTERNAL_ERROR'

KDC service check:

The following KDCs were unreachable: tcp ucs-7758.domain.intranet:88, udp ucs-7758.domain.intranet:88

URC templates errors:

Errors found by `univention-check-templates`. The following UCR files are modified locally. Updated versions will be named FILENAME.dpkg-*. The files should be checked for differences. 

 /etc/univention/registry.info/variables/heliumv-app.cfg
/etc/univention/templates/files/opt/heliumv/apache-tomcat-7.0.47/conf/Catalina/localhost/restapi.xml
/etc/univention/templates/files/opt/heliumv/apache-tomcat-7.0.47/conf/server.xml

Thanks for any suggestions.

#2

Hey,

lets’ start with the easier problems.

The KDC service check

This is likely a false positive (see this bug report for details). The system diagnostics contain several other checks that rely on Kerberos and therefore the KDC (Key Distribution Center) working. As there aren’t other KDC-related bugs such as nsupdate failed, this problem can be safely ignored.

The template errors

In Univention a lot of files are created from templates which combine configuration snippets, UCR variables & LDAP content in order to form the final configuration files. If you modify such templates yourself, the upgrade process will not overwrite your modified old templates with newer versions of the templates. This is dangerous as the result might be that newer versions of daemons won’t work with older versions of the configuration file templates.

There are two main reasons for this error:

  1. You really did modify the templates. In that case you should find the new versions of the template files in the same place but with an additional extension (.dpkg-new). For example, you might look for /etc/univention/templates/files/opt/heliumv/apache-tomcat-7.0.47/conf/server.xml.dpkg-new as the new version for /etc/univention/templates/files/opt/heliumv/apache-tomcat-7.0.47/conf/server.xml. The way to resolve this is to migrate your manual changes from the old version of the template to the new one, rename the new with the temporary name one to the original name and to call ucr commit /path/to/generated/file (that’s the path to the file that’s created, not the path to the template file, e.g. ucr commit /opt/heliumv/apache-tomcat-7.0.47/conf/server.xml).
  2. The templates might come from a package that had been installed at one point but isn’t installed fully anymore. Instead it might be in state rc (= “removed, but still configured”). Check if the files still exist, which package they belong to (e.g. dpkg -S /etc/univention/templates/files/opt/heliumv/apache-tomcat-7.0.47/conf/server.xml) and what state that package is in (dpkg -l <name-of-package-it-belongs-to>). If it is indeed in state rc, you can purge the remaining configuration files with dpkg --purge <name-of-the-package>.

The Samba replication status error

This one is a bit trickier. Googling hasn’t helped me much. Please post the full output of the following command:

samba-tool drs showrepl

Kind regards
mosu

#3

The Samba replication status error:

samba-tool drs showrepl from UCS Master:
https://pastebin.ubuntu.com/p/VCyZPbq9Dh/

#4

Hey,

thanks. The errors show that there were no successful connections since August 24th, neither inbound nor outbound. Do the two other AD DC servers “UCS-Backup” and “UCS-Slave” still exist? Does Samba still run on them? Is there any firewall between the machines that might prevent successful connections?

m.

#5

Hi, restarted Slave and Backup:

root@ucs-Slave:~# samba-tool drs showrepl
Failed to connect host 172.16.6.66 on port 135 - NT_STATUS_CONNECTION_REFUSED
Failed to connect host 172.16.6.66 (ucs-Slave.damain.intranet) on port 135 - NT_STATUS_CONNECTION_REFUSED.
ERROR(<class 'samba.drs_utils.drsException'>): DRS connection to ucs-Slave.Doamin.intranet failed - drsException: DRS connection to ucs-Slave.domain.intranet failed: (-1073741258, 'The transport-connection attempt was refused by the remote system.')
  File "/usr/lib/python2.7/dist-packages/samba/netcmd/drs.py", line 44, in drsuapi_connect
    (ctx.drsuapi, ctx.drsuapi_handle, ctx.bind_supported_extensions) = drs_utils.drsuapi_connect(ctx.server, ctx.lp, ctx.creds)
  File "/usr/lib/python2.7/dist-packages/samba/drs_utils.py", line 56, in drsuapi_connect
    raise drsException("DRS connection to %s failed: %s" % (server, e))
#6

Hey,

OK, this is most likely a firewall issue. Please post the output of the following commands for each of the three servers (your DC Master, “UCS-Backup” and “UCS-Slave”):

lsof -PniTCP:135 -sTCP:LISTEN
iptables -L INPUT -nv|grep -E 'policy|:135'
ip a

m.

#7

Master:
https://pastebin.com/VeTWXiyK
Backup:
https://pastebin.com/9q6tbJtS
Slave:
https://pastebin.com/70WqKNTS

#8

Thanks. The output for “UCS-Slave” and “UCS-Backups” shows that Samba only listens on the local-loopback interface (lo) on those servers. Therefore no connection between them and the DC Master is possible.

The remedy is simple: on your “UCS-Backup” and “UCS-Slave”, either set the UCR variable samba/interfaces/bindonly to no (in which case Samba will listen on all available local interfaces including e.g. the Docker interface), or set samba/interfaces to lo <interfaces/primary> (in which case Samba will only listen on the local-loopback interface as well as the machine’s primary interface, which is eth0 for both of your other servers; just don’t remove lo from that list or other things will stop working!). Afterwards restart Samba.

If this succeeded, lsof -PniTCP:135 -sTCP:LISTEN should list a lot more lines includes ones where the server’s IP address is listed (compare to the output on your DC Master where everything is fine already).

Kind regards
mosu

#9

Ok On Slave and Backup:

COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
samba   1308 root   48u  IPv6  22565      0t0  TCP [::1]:135 (LISTEN)
samba   1308 root   49u  IPv4  22566      0t0  TCP 127.0.0.1:135 (LISTEN)
samba   1308 root   50u  IPv4  22567      0t0  TCP EXTERNAL IP:135 (LISTEN)

but samba-tool drs showrepl on Master have same errors

#10

As far as I know, the connections aren’t updated/attempted immediately when Samba starts. Give it some time, e.g. quarter of an hour, and see if things have changed by then.

#11

Ok,Thaky ou for help

#12

@Moritz_Bunkus Have you news about?

Mastodon