Kopano automatisches Löschen von alten E-Mails oder Terminen oder Aufgaben
Im Leben eines Postfaches werden sehr viele Dateien & Termine & Aufgaben & Notizen angesammelt über die Jahre.
Kopano selbst kennt jedoch kein automatisches Löschen von alten Einträgen.
Wir bieten hierzu die Implementierung einer Skriptsammlung inkl. Protokollierung via E-Mail.
Damit können auf einem Linux/Unix-System in regelmäßigen Abständen, alte Einträge in Postfächern gelöscht werden.
Der Zeitraum läss sich in Tagen, Monaten oder Jahren definieren.
Unser Tool läuft damit dann z.B. monatlich los, löscht alte Einträge aus den Mailboxen und informiert darüber per E-Mail den Verantwortlichen.
Interessiert? Anrufen oder Anfrage senden 🙂
3CX-Schulungsbereich für die Telefonie der Zukunft eröffnet
| 3CX-Schulungsbereich für die Telefonie der Zukunft eröffnet |
| Sehr geehrte Damen und Herren, liebe Kunden und Partner, eine von uns durchgeführte Umfrage im Oktober 2020 unter 100 Interessenten hat gezeigt, dass lediglich 10% der Möglichkeiten einer modernen Telefonanlage in Unternehmen genutzt werden. Dies heißt für uns, dass häufig IT-Lösungen zum Einsatz kommen, ohne dass die damit arbeitenden Personen alle Vorteile kennen, schätzen und zur eigenen Erleichterung dann auch gerne einsetzen. Dies sehen wir als wichtigen Baustein zur Digitalisierung. Da uns das Thema am Herzen liegt und jeder täglich viel Zeit am Telefon verbringt, entstand die letzten Wochen für Sie eine 3CX-Test- und Schulungsumgebung in unseren Räumen in Trostberg. Hier haben Sie ab sofort die Möglichkeit: Telefonanlagen, Endgeräte und schnurlose Telefone zu testen Schulungsmöglichkeiten in Anspruch zu nehmen um Ihre Abläufe weiter zu optimieren Eine Umstellung Ihrer Telefonanlage ausführlich zu besprechen und zu planen Sich zum 3CX-Experten ausbilden zu lassen um eine Umstellung selbst durchzuführen PS: cubewerk ist der einzige und zertifizierte 3CX-Gold-Partner zwischen München und Salzburg. Ich freue mich auf Ihre Rückmeldung. |
error 43 nvidia passthrough proxmox & solution
TL/DR: Nehmt keine NVIDIA-Karten, kauft AMD.
Heutige Anforderung, eine Nvidia Grafikkarte an eine Linux-VM übergeben, damit dort dediziert die Rechenleistung der GPU zur Verfügung steht. Windows meldet nach Treiberinstallation jedoch Error Code 43.
Nvidia hat hier einen Check in seinen Treibern, der die Grafikkarte deaktiviert, wenn erkannt wird, dass im Einsatz in VM-Umgebung.
Nvidia möchte einen nötigen, eine teurere Graka für diesen Einsatzzweck zu kaufen. NVIDIA, so nicht, in Zukunft nehmen wir nur noch AMD.
Das generelle Passthrough war dann ziemlich Easy. Im Bios IOMMU aktiviert. Im Proxmox die Karte selbst, ge-backlisted, damit sich der Proxmox diese nicht schnappt und das „Weiterreichen“ verhindert mit
# lspci -n -s 01:00
01:00.0 0300: 1002:6779
01:00.1 0403: 1002:aa98
echo "options vfio-pci ids=1002:6779,1002:aa98" > /etc/modprobe.d/vfio.conf
update-initramfs -u
rebootFolgende Settings im Proxmox:
Wichtig war, erst Settings setzen , dann installieren. Nachträgliches ändern von MBR zu UEFI geht nicht einfach.
plesk increase pm.max_children
/var/www/vhosts/system/YOURDOMAIN/conf/php.ini
[php-fpm-pool-settings]
pm.max_children = 500
/usr/local/psa/bin/php_settings -u
grep max_children /etc/php5/fpm/pool.d/YOURDOMAIN.conf
should now show the new values.
Kopano langsame WebApp, Ordnerwechsel dauert Sekunden
Hier läuft im Hintergrund sehr viel Authentifizierung durch die ständigen LDAP-Binds. Bei einem UCS-Server mit Windows-AD zwingend prüfen, ob für den SRV-Record der Kerberos-Server nicht inaktive / nicht erreichbare Einträge hinterlegt sind.
Dann läuft das ganze in einen Timeout und erklärt die Verzögerung.
cubewerk erreicht höchste 3CX-Zertifizierungsstufe
Wir freuen uns besonders die höchste 3CX-Zertifizierungsstufe erreicht zu haben. Nach mehr als 70 installierten 3CX-Systemen und bereits im zweiten Jahr erreichter Gold-Partnerschaft freuen wir uns sehr auf weitere spannende Projekte mit 3CX.
PS: Seit 01.11.2020 steht in Trostberg die neue cubewerk 3CX-Schulungsumgebung für Kunden & Partner bereit.
Gigaset Go-Box 100 – kein Zugriff Firewall / NAT
Gigaset-Go-Box ist per ICMP/Ping erreichbar, aber Interface lässt sich nicht öffnen?
Wenn man selbst aus einem anderen Netz kommt, ignoriert die Go-Box Anfragen und antwortet nur auf Pings.
NAT hilft. Also SNAT.
Ohne NAT und tcpdump:
18:03:56.533708 IP 192.168.0.185.34862 > 172.16.9.4.80: Flags [S], seq 2121144699, win 64240, options [mss 1460,sackOK,TS val 380582646 ecr 0,nop,wscale 7], length 0
18:04:12.405705 IP 192.168.0.185.34860 > 172.16.9.4.80: Flags [S], seq 699571458, win 64240, options [mss 1460,sackOK,TS val 380598518 ecr 0,nop,wscale 7], length 0
18:04:12.661689 IP 192.168.0.185.34862 > 172.16.9.4.80: Flags [S], seq 2121144699, win 64240, options [mss 1460,sackOK,TS val 380598773 ecr 0,nop,wscale 7], length 0
3 mal unbeantwortet.
Mit SNAT:
18:05:39.976948 IP 172.16.9.1.19280 > 172.16.9.4.80: Flags [S], seq 104383790, win 64240, options [mss 1460,sackOK,TS val 380686089 ecr 0,nop,wscale 7], length 0
18:05:39.978124 IP 172.16.9.4.80 > 172.16.9.1.19280: Flags [S.], seq 13195151, ack 104383791, win 1608, options [mss 536], length 0
18:05:39.978329 IP 172.16.9.1.19280 > 172.16.9.4.80: Flags [.], ack 1, win 64240, length 0
SYN / SYN-ACK ACK. Wir kennens noch aus der Ausbildung…
Outlook mit Kopano synchronisiert Mails nicht – lessons learned
Kommt es zu Sync-Problemen, fehlen im Outlook Mails und Outlook meldet rechts unten ‚KONTONAME‘ wird aktualisiert aber wird nicht fertig.
Häufigste Ursache, faule Einträge in Kalender/Postfach/Aufgaben des entfernten Postfaches.
Status prüfen auf Kopano-Server mit
z-push-admin -a list -u username -d device-ID
Zeigt dann z.B. dass ein Postfach nie fertig synchronisiert und bei einer Prozentzahl stehen bleibt.
Lösung häufig per WebApp verbinden mit jeweiligem Postfach und Serientermine bzw. Termine die durch das Funktionspostfach selbst erstellt wurden, zu entfernen oder zu verschieben und Outlook neustarten.
Zählt dann der Zähler hoch, hat man das „faule Ei“ identifiziert.
Weitere sinnvolle Debug-Tools/Protokolle:
tail -f /var/log/z-push/z-push-error.log
watch z-push-admin -a clearloop -u username -d device-id
z-push-admin -a resync -t calendar -u username
restore proxmox vm to backy2 ceph
mit backy2 ls, jeweilige sicherung finden
backy2 ls | grep vm-112
| 2020-11-05 20:55:05 | vm-112-disk-0 | backy2_20201105215504 | 8192 | 34359738368 | 2eb56114-1fa9-11eb-905a-3cfdfed31498 | 1 | 0 | daily | 2020-11-14 20:55:03 |
| 2020-11-06 20:55:06 | vm-112-disk-0 | backy2_20201106215504 | 8192 | 34359738368 | 593968e4-2072-11eb-abe4-3cfdfed31498 | 1 | 0 | daily | 2020-11-15 20:55:02 |
| 2020-11-07 20:55:05 | vm-112-disk-0 | backy2_20201107215504 | 8192 | 34359738368 | 835ddfe6-213b-11eb-8f22-3cfdfed31498 | 1 | 0 | daily | 2020-11-16 20:55:03 |
| 2020-11-08 20:55:05 | vm-112-disk-0 | backy2_20201108215504 | 8192 | 34359738368 | adb15312-2204-11eb-bb7f-3cfdfed31498 | 1 | 0 | daily | 2020-11-17 20:55:03 |
| 2020-11-10 02:45:06 | vm-112-disk-0 | backy2_20201110034505 | 8192 | 34359738368 | bdbef4e4-22fe-11eb-a795-3cfdfed31498 | 1 | 0 | daily | 2020-11-19 02:45:03 |
| 2020-11-11 04:20:06 | vm-112-disk-0 | backy2_20201111052005 | 8192 | 34359738368 | 2de02d98-23d5-11eb-b7d0-3cfdfed31498 | 1 | 0 | daily | 2020-11-20 04:20:03 |
| 2020-11-13 00:05:06 | vm-112-disk-0 | backy2_20201113010505 | 8192 | 34359738368 | e30dc5da-2543-11eb-a4b0-3cfdfed31498 | 1 | 0 | daily | 2020-11-22 00:05:03 |
ID merken und restore anleiern:
backy2 restore –sparse 2eb56114-1fa9-11eb-905a-3cfdfed31498 rbd://rbd_ssd/vm-112-disk-99
Der jeweiligen VM im Proxmox, neue Disk zuweisen.
Liegt unter /etc/pve/qemu-server/$VMID.conf
virtio0: rbd_ssd:vm-112-disk-0,size=32G
grep vm-112 /etc/pve/qemu-server/112.conf liefert dann:
virtio0: rbd_ssd:vm-112-disk-0,size=32G
Hier ändern auf -disk-99
Sync-Problem AD->UCS bei faulen Zeichen im AD
Migrationsprojekt Server 2012 AD-Umgebung zu UCS
Aufgrund OUs und Gruppen im AD mit ungültigen Namen (Sonderzeichen, Umlaute, Kaufmaannsund usw.)
war der UCS-Server beleidigt und logged
tail -f /var/log/univention/connector.log | egrep „Resync rejected“
13.11.2020 11:28:58.870 LDAP (PROCESS): sync to ucs: Resync rejected dn: CN=ADM-12345,OU=Computer\, virtuell,OU=Sys-Admin,DC=KUNDE,DC=local
Nachdem die Einträge im AD bereinigt wurden hat der UCS aber immer noch gecached in seiner lokalen sqlite-DB die faulen Eier:
univention-connector-list-rejected zeigt diese auch
Kurzerhand somit die SQLITE-DB sichern, oeffenen, faule Einträge entfernen und weiter gehts. Erstmal Dienst anhalten
/etc/init.d/univention-ad-connector stop
cd /etc/univention/connector/
cp internal.sqlite internal.sqlite.bak
sqlite3 /etc/univention/connector/internal.sqlite
sqlite> select * from ‚AD rejected‘;
19267|CN=ADM-12345,OU=Computer\, virtuell,OU=Sys-Admin,DC=KUNDE,DC=local
IDs der ersten Spalte merken und mit … weghauen:
sqlite> delete from ‚AD rejected‘ where Key=19267;
sqlite> .quit
Erfolg kontrollieren (Liste sollte leer sein)
root@kopano01:/etc/univention/connector# univention-connector-list-rejected
UCS rejected
AD rejected
There may be no rejected DNs if the connector is in progress, to be
sure stop the connector before running this script.
last synced USN: 52211632Dienst wieder starten und beobachten:
/etc/init.d/univention-ad-connector start
tail -f /var/log/univention/connector-status.log
sollte auch keine rejects mehr liefern:
try to sync 0 changes from UCS
done:
Changes from UCS: 0 (0 saved rejected)
try to sync 0 changes from AD
done:
Changes from AD: 0 (0 saved rejected)
- sleep 5 seconds (2/10 until resync) –
U.u. logged/spammed der univention-notifier dann immer noch die Logs zu, da der SLAPD es nicht geschafft hat, alles wegzusynchronisieren. Zeigt sich wie folgt:
root@kopano01:~# tail -f /var/log/univention/notifier.log
13.11.20 13:58:58.955 TRANSFILE ( WARN ) : 3166621 ldap_add() already exists
13.11.20 13:58:58.955 TRANSFILE ( WARN ) : 3166622 ldap_add() already exists
13.11.20 13:58:58.956 TRANSFILE ( WARN ) : 3166623 ldap_add() already exists
13.11.20 13:58:58.956 TRANSFILE ( WARN ) : 3166624 ldap_add() already exists
13.11.20 13:58:58.956 TRANSFILE ( WARN ) : 3166625 ldap_add() already exists
13.11.20 13:58:58.956 TRANSFILE ( WARN ) : 3166626 ldap_add() already exists
13.11.20 13:58:58.957 TRANSFILE ( WARN ) : 3166627 ldap_add() already exists
13.11.20 13:58:58.957 TRANSFILE ( WARN ) : 3166628 ldap_add() already exists
13.11.20 13:58:58.957 TRANSFILE ( WARN ) : 3166629 ldap_add() already exists
13.11.20 13:58:58.957 TRANSFILE ( WARN ) : 3166630 ldap_add() already exists
Lösung:
service slapd stop
service univention-directory-notifier stop
service univention-directory-listener stop
python python univention-reset-replication-counters.py
Von hier: https://help.univention.com/uploads/short-url/v7KTcKblYBxd7Gufjp9a71mvJCh.py
/usr/share/univention-ldap/setup-translog init –force
service slapd start
/usr/share/univention-directory-notifier/univention-translog import
ervice slapd start
service univention-directory-notifier start
service univention-directory-listener start
