Admin diary on 5.0.3-660 failing on replica

1

when placing in a replica of your AD on a different subnet/site, the admin diary does nto function

the new site shows an error

univention-join-hooks: looking for hook type "join/pre-joinscripts" on dc02.some.com
Found hooks:
  
RUNNING 60univention-admin-diary-backend.inst
2023-05-08 10:49:11.589737907+08:00 (in joinscript_init)
createuser: creation of new role failed: ERROR:  role "admindiary" already exists
createdb: database creation failed: ERROR:  database "admindiary" already exists
ALTER ROLE
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 2228, in _wrap_pool_connect
    return fn()
  File "/usr/lib/python3/dist-packages/sqlalchemy/pool.py", line 425, in connect
    return _ConnectionFairy._checkout(self)
  File "/usr/lib/python3/dist-packages/sqlalchemy/pool.py", line 822, in _checkout
    fairy = _ConnectionRecord.checkout(pool)
  File "/usr/lib/python3/dist-packages/sqlalchemy/pool.py", line 554, in checkout
    rec = pool._do_get()
  File "/usr/lib/python3/dist-packages/sqlalchemy/pool.py", line 1346, in _do_get
    return self._create_connection()
  File "/usr/lib/python3/dist-packages/sqlalchemy/pool.py", line 370, in _create_connection
    return _ConnectionRecord(self)
  File "/usr/lib/python3/dist-packages/sqlalchemy/pool.py", line 499, in __init__
    self.__connect(first_connect_check=True)
  File "/usr/lib/python3/dist-packages/sqlalchemy/pool.py", line 701, in __connect
    connection = pool._invoke_creator(self)
  File "/usr/lib/python3/dist-packages/sqlalchemy/engine/strategies.py", line 114, in connect
    return dialect.connect(*cargs, **cparams)
  File "/usr/lib/python3/dist-packages/sqlalchemy/engine/default.py", line 437, in connect
    return self.dbapi.connect(*cargs, **cparams)
  File "/usr/lib/python3/dist-packages/psycopg2/__init__.py", line 130, in connect
    conn = _connect(dsn, connection_factory=connection_factory, **kwasync)
psycopg2.OperationalError: FATAL:  no pg_hba.conf entry for host "192.168.0.15", user "admindiary", database "admindiary", SSL on
FATAL:  no pg_hba.conf entry for host "192.168.0.15", user "admindiary", database "admindiary", SSL off

also following the settings for the above note ,
the port settings inside teh univention config reg, show port 10514, this is not shown in the note and does not seem correct for a postgresql database

2

Hi , is there any update on this? Having the same issue. Thanks.

3

had to go in manually & change the config to point to the database on the master.

4

Point where what? Can you elaborate on this? The join script for admin diary on my replicas fail. Firewall is not an issue.

5

Basically the admin diary is badly written…
it runs fine on the master ,because THAT is where the database is installed

BUT… when you install it on a slave, it does not install the database & it is not smart enough to set the connection strings to the master database

so you have to go into the admin config… then point the ip address to the public ip address of the master controller

however the question then becomes… if the master goes off line & a slave takes over running of your domain & you do admin…
then the changes are not logged… and it throws errors again.

in reality it needs a local database that is then synced to the master whenever it can connect…

so… yes you can use it … but caveats apply

also be aware that if the client is on the “master” the it should be connecting to the database using localhost, NOT the full domain (even though it can)

But on a slave system it needs to point to the full domain & have a hole in your firewall, that can let anyone with half a brain probe your back end database. on your master…

and to really complicate it…
if you have a master & a backup, and the backup points to the master ,then the master goes off line, then the backup would need to reconfigure the admin logging to itself (as it is the new master) …

so as i say it is badly written… because it’s not capable of tracking admin changes during a failure event with the master.

perhaps they should have just shoved the crap into an LDAP on the server then use the univention sync is as per a normal replication.
so it would give a fully replicated database of all admin changes across all the systems.

6

What “admin” config? UCR Registry? Which key?

7

OK…
another couple of issues.

there is no “filter” available to filter what gets added.

so tens of thousands of. DHCP zone modifications get added as well
as well as workstation host records.

Really this needs a filter so you can decide what gets put into this ever expanding record

8

try going into
Univention Configuration Registry

admin/diary/

oh and
postgres11/pg_hba/config/01