I deleted one user (Provider: LDAP) and his email account.
Now I found a lot of error logs like:
08:40 imap: Error: Authenticated user not found from userdb, auth lookup id=3045195777 (auth connected 1 msecs ago, handshake 1 msecs ago, request took 1 msecs, client-pid=11844 client-id=1) dovecot
08:40 auth: Error: plain(USERxyz,127.0.0.1,<FdwvZMqyKNV/AAAB>): user not found from any userdbs dovecot
I checked that no client has configured such an email account.
Thank you for this idea.
I actually expect that the reapplied user will get a different internal ID and all manual delete actions will refer to it. Therefore I still hesitate to test such an operation on the production system.
Aren’t the users created somewhere and the user (or its remaining ID) could be deleted manually from the directory or database?
Does anyone have any experience with this? I won’t be the first user who has to delete a user…
Run in “Kamikaze” mode, you can easily clean up your AD - I think there is still the user there.
You would also need to check if the user-home (/var/lib/nethserver/users) is still there (delete if yes).
Such a very long shot that I hesitated before posting:
Since it is a so strange number (FdwvZMqyKNV/AAAB), is it possible that it comes from a vhost that you created with Cockpit then deleted it ?
SOGO I uninstalled, but surprisingly a CRON job is still running
-rw-r–r–. 1 root root 128 Aug 9 2019 0hourly
-rw-r–r-- 1 root root 316 Oct 8 20:27 backup-data
-rw-r–r-- 1 root root 1398 Feb 23 2020 clamav-unofficial-sigs
-rw------- 1 root root 203 Jul 17 18:15 clamav-update
-rw-r–r-- 1 root root 116 Oct 12 17:06 fail2ban-statistics
-rw-r–r-- 1 root root 249 Oct 10 14:20 getmail
-rw-r–r-- 1 root root 438 Oct 18 10:29 nethserver-blacklist
-rw-r–r-- 1 root root 111 Oct 16 15:40 nextcloud
-rw-r–r-- 1 root root 455 May 25 16:35 ntopng
-rw-r–r–. 1 root root 159 May 22 2019 ptrack_purge
-rw-r–r–. 1 root root 108 Nov 27 2019 raid-check
-rw-r–r-- 1 root root 350 Oct 10 19:25 runmysqlbackup
-rw-r–r–. 1 root root 61 Oct 7 10:58 shorewall-update-dst
-rw-r----- 1 root root 1231 Oct 8 22:54 sogo
[root@ns-srv01 cron.d]# cat sogo
# ================= DO NOT MODIFY THIS FILE =================
#
# Manual changes will be lost when this file is regenerated.
#
# Please read the developer's guide, which is available
# at NethServer official site: https://www.nethserver.org
#
#
# Sogod cronjobs
# Vacation messages expiration
# The credentials file should contain the sieve admin credentials (username:passwd)
0 0 * * * sogo /usr/sbin/sogo-tool update-autoreply -p /etc/sogo/sieve.creds
# Session cleanup - runs every minute
# - Ajust the nbMinutes parameter to suit your needs
# Example: Sessions without activity since 60 minutes will be dropped:
#* * * * * sogo /usr/sbin/sogo-tool expire-sessions 60
# Email alarms - runs every minutes
# If you need to use SMTP AUTH for outgoing mails, specify credentials to use
# with '-p /path/to/credentialsFile' (same format as the sieve credentials)
* * * * * sogo /usr/sbin/sogo-ealarms-notify > /dev/null 2>&1
# Daily backups
# - writes to ~sogo/backups/ by default
# - will keep 31 days worth of backups by default
# - runs once a day by default, but can run more frequently
# - make sure to set the path to sogo-backup.sh correctly
30 0 * * * sogo /usr/share/doc/sogo-*/sogo-backup.sh
[root@ns-srv01 cron.d]#
I have checked all other crons: no one with */2 * * * *
find and kill the session
I don’t have an unique PID, because they change randomly too.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5727 netdata 20 0 56224 5988 1808 S 2.0 0.1 1:13.43 apps.plugin
1 root 20 0 199872 4220 2364 S 1.3 0.1 3:25.69 systemd
5410 root 20 0 3108932 38348 22828 S 1.3 0.5 1:08.19 f2b/server
1313 ntopng 20 0 1690256 256780 16708 S 0.7 3.1 117:50.80 ntopng
5588 netdata 20 0 357016 103276 3504 S 0.7 1.3 0:22.49 netdata
8929 root 20 0 563300 6660 3892 S 0.7 0.1 0:12.46 cockpit-bridge
27550 suricata 20 0 911516 383708 4864 S 0.7 4.7 10:58.95 Suricata-Main
761 dbus 20 0 70776 2428 1692 S 0.3 0.0 1:52.75 dbus-daemon
1221 unbound 20 0 149816 21864 3324 S 0.3 0.3 1:04.22 unbound
5723 netdata 20 0 167852 22052 4288 S 0.3 0.3 0:10.40 python
8739 cockpit+ 20 0 530104 7992 4448 S 0.3 0.1 0:07.40 cockpit-ws
27343 root 20 0 75444 4864 3636 S 0.3 0.1 1:36.99 openvpn
28068 root 20 0 162272 2500 1580 R 0.3 0.0 0:00.02 top
2 root 20 0 0 0 0 S 0.0 0.0 0:00.04 kthreadd
4 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H
6 root 20 0 0 0 0 S 0.0 0.0 0:18.86 ksoftirqd/0
7 root rt 0 0 0 0 S 0.0 0.0 0:01.54 migration/0
8 root 20 0 0 0 0 S 0.0 0.0 0:00.75 rcu_bh
Yes, but it don’t solve the problem. I did not expect this either, because it is not a 2-minute cron.
Unfortunately there is no 2-minute cron at all to convict the culprit.
My next suspicion would be WebTop, if WebTop would manage known users somewhere.
