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.
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:
- 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).
- 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
The Samba replication status error:
samba-tool drs showrepl from UCS Master:
https://pastebin.ubuntu.com/p/VCyZPbq9Dh/
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.
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))
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.
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
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
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.
@Moritz_Bunkus Have you news about?