Dead node still in software monitor

I still have an entry in software mointor for a UCS Virtual machine that used to be a BDC but no longer exists.

Pretty sure it was removed from the domain using the script to do so on the master and it doesn’t show up in computers on the domain, think it’s just a left over entry in the software monitor DB, is there an easy way to remove it (not that it really matters that much)

Is the leftover server completely removed? Can you check that via:

[code]# univention-ldapsearch cn=

univention-s4search cn=[/code]

Maybe there are leftover entries in the DNS? Do you use Samba4? If yes check the replication too:

# samba-tool drs showrepl

Looks like there’s still some remains there.

[code]root@ucs-1025:~# univention-ldapsearch cn=ucs-8317

extended LDIF

LDAPv3

base <dc=flying-beast,dc=intranet> (default) with scope subtree

filter: cn=ucs-8317

requesting: ALL

ucs-8317, flying-beast.intranet, dhcp, flying-beast.intranet

dn: cn=ucs-8317,cn=flying-beast.intranet,cn=dhcp,dc=flying-beast,dc=intranet
objectClass: top
objectClass: dhcpServer
objectClass: univentionObject
dhcpServiceDN: cn=flying-beast.intranet,cn=dhcp,dc=flying-beast,dc=intranet
univentionObjectType: dhcp/server
cn: ucs-8317

search result

search: 3
result: 0 Success

numResponses: 2

numEntries: 1

root@ucs-1025:~#
[/code]

[code]root@ucs-1025:~# univention-s4search cn=ucs-8317

Referral

ref: ldap://flying-beast.intranet/CN=Configuration,DC=flying-beast,DC=intranet

Referral

ref: ldap://flying-beast.intranet/DC=DomainDnsZones,DC=flying-beast,DC=intranet

Referral

ref: ldap://flying-beast.intranet/DC=ForestDnsZones,DC=flying-beast,DC=intranet

returned 3 records

0 entries

3 referrals

root@ucs-1025:~#
[/code]

Connection -- Connection name: a25afce8-5a63-4860-9683-b21da29f3677 Enabled : TRUE Server DNS name : ucs-8317.flying-beast.intranet Server DN name : CN=NTDS Settings,CN=UCS-8317,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=flying-beast,DC=intranet TransportType: RPC options: 0x00000001 Warning: No NC replicated for Connection!

Edit: Got rid of the DHCP server entry for it, but looks like it still exists in samba?

Edit2: Also notice a lot of failures in the Neighbours but that doesn’t surprise me, usually means the IPSEC tunnels dropped out and didn’t reconnect.

I’d like to point out this is just a domain for my personal machines and my internal DNS so if I did need to nuke it from orbit and start again it’s not going to be a major headache/impact.

First (till no errors are left):

# samba-tool dbcheck --fix

Then: “ldbdel” can be used to remove objects. This could be needed e.g. if removed computer objects left reference objects underneath cn=configuration,$ldap_base:

# ldbdel -H /var/lib/samba/private/sam.ldb  <dn>

Edit: Please be very carefull, while operating with ldbdel on the sam.ldb…

did that got rid of the left over computer?

Has the topic become easier to deal with in the meantime?

Now i have directly access to the database, so how can i delete a host?

See here.

/CV

Thanks for this very good information. But seems to be not working here:

root@dc1:~# /usr/share/univention-samba4/scripts/purge_s4_computer.py --computername=bareos
Samba 4 computer account 'bareos' not found.

Is there anything else to be done?

Hi,

well, if it is not found it might not be there…

Are you still having issues with this entry? In what way?

/CV

Yes. Please see the screenshot. I would like to delete the bareos entry. bareos-software-monitor

And i get a lot of entries with slapcat.

objectClass: bareosClientHost
bareosEnableJob: Not
objectClass: bareosClientHost
bareosEnableJob: Not
objectClass: bareosClientHost
bareosEnableJob: Not
objectClass: bareosClientHost
bareosEnableJob: Not
objectClass: bareosClientHost
bareosEnableJob: Not
objectClass: bareosClientHost
bareosEnableJob: Not
objectClass: bareosClientHost
bareosEnableJob: Not
objectClass: bareosClientHost
bareosEnableJob: Not
objectClass: bareosClientHost
bareosEnableJob: Not
dn: cn=univention-bareos,cn=ldapschema,cn=univention,dc=osit,dc=cc
cn: univention-bareos
univentionOwnedByPackage: univention-bareos
univentionLDAPSchemaFilename: univention-bareos.schema
objectClass: bareosClientHost
bareosEnableJob: Not
objectClass: bareosClientHost
bareosEnableJob: Not
objectClass: bareosClientHost
bareosEnableJob: Not
objectClass: bareosClientHost
bareosEnableJob: Not
objectClass: bareosClientHost
bareosEnableJob: Not
objectClass: bareosClientHost
bareosEnableJob: Not
objectClass: bareosClientHost
bareosEnableJob: Not
objectClass: bareosClientHost
bareosEnableJob: Not
bareosEnableJob: Not
objectClass: bareosClientHost

Thanks a lot and best regards
Boospy

Well,

the host is in the database of software monitor but no longer in the ldap database.

What you see with slapcat are the remainings of bareos ldap-schema extensions. You should not remove them as the ldap server will complain when you still have references to an removed schema.

I do not know how to remove the entry from the software monitor, sorry. I would suggest to use sort of sql commands? But this would be very error prone…
Remove software monitor, it’s database and re-install?

/CV

1 Like

This should do the trick:

univention-pkgdb-scan --remove-system=ucs-8317

You may have to run it on the database host.

1 Like

Sorry, too late. I have deinstalled the application. So 2 of three servers now postgresql did not start any more. Because the config exits any more:
/etc/postgresql/9.6/main/pg_hba.conf

What have i done?

  1. Softwaremonitorapp remove on Master, and the two Backups
  2. loggend in to postgresql and deleted pykota, because the app was remove since an half an year.
  3. rebooted the vm

The Database was not deletedable:

DROP DATABASE pkgdb;
FEHLER:  kann aktuell geöffnete Datenbank nicht löschen

So my question:

  • On the two backup dc*s, the packages univention-postgresql and univention-postgresql-9.6 are removed. And on master no, so ist ok to remove the rest of PGSQL packges, so the system mean no SQL database is in use?
    On dc1 is selfservice and admindiary too.
  • But if that it’s right, why UCS did not remove the PGSQL, or disable the autostart?

So you’ve prefered to delete everything instead of reading the help entries or trying to remove the database entries via SQL? Are you always using sledgehammer to crack a nut? :roll_eyes:

I’m out …

Normal not. But were you read this command “univention-pkgdb-scan”. Nic to know.

That was a recommendation, and why should the deinstallation of the app want to delete the PSQL makes no sense. Therefore, this approach was already ok for my knowledge there.

And yes the command works perfectly.

And i can install “apt install univention-postgresql” this on the backup dc’s again and PGSQL works. After i had a look what databases are there i can see only the pkgdb was there, so it was right that UCS removed postgresql. What was strange is that the server was not removed completly, because of the systemd failed error.

   Name    | Eigentümer | Kodierung | Sortierfolge | Zeichentyp  |  Zugriffsprivilegien  
-----------+------------+-----------+--------------+-------------+-----------------------
 pkgdb     | postgres   | UTF8      | de_DE.UTF-8  | de_DE.UTF-8 | 
 postgres  | postgres   | UTF8      | de_DE.UTF-8  | de_DE.UTF-8 | 
 template0 | postgres   | UTF8      | de_DE.UTF-8  | de_DE.UTF-8 | =c/postgres          +
           |            |           |              |             | postgres=CTc/postgres
 template1 | postgres   | UTF8      | de_DE.UTF-8  | de_DE.UTF-8 | =c/postgres          +
           |            |           |              |             | postgres=CTc/postgres

Looks like a little bug.