Kategorien-Archiv Blog

Exchange 2019 – Mailbox entfernen löscht AD-Benutzer

Danke Microsoft. Hier hat wohl eure Qualitätssicherung geschlafen. Löscht man eine Mailbox im ECP von Exchange, wird automatisch der dazugehörige AD-Benutzer gelöscht. Ernsthaft Microsoft?

.r00 Dateien für Virusversand und die Probleme mit OpenSource

Kürzlich erhielten wir von einem Kunden ein Virus-Sample, weil dies durch den Spam/Virenfilter ging aber vom lokalen Windows-Virenscanner des Kunden erkannt wurde. Warum war das so?

Der böse Absender hat hier bewusst zwei Lücken ausgenutzt:

• Die Datei war mit Rar – Version 5 komprimiert. Hier hängt der Support in der Linux/Unix-Welt in allen Distributionen hinterher.

me@mx01:/home/me# file scan335019041109350063746475.pdf.r00
scan335019041109350063746475.pdf.r00: RAR archive data, v5

Clamav hat hier „erst“ zum Ende des Jahres die Unterstützung eingebaut:

https://blog.clamav.net/2018/12/clamav-01010-has-been-released.html

Aufgrund div. Release-Zyklen, zieht sich dies bis Pakete für die Distributionen kompiliert werden.

• Aufgrund von Lizenzproblemen, liefern die großen Distributionen, den Support zum Entpacken von Rar-Dateien, nur über optionale Repositories an (non-free). Für clamav gibt es das getrennte Paket libclamunrar

HyperV VHD-Images zu Proxmox Ceph migrieren

Man exportiere in HyperV, VMs mit altem DiskFormat VHD (VHDX ist neuer) und möchte die VHD-Files, direkt in den Ceph-Store importieren.

Nötig ist, dass über die Proxmox-Oberfläche, mindestens in der VM eine Disk auf dem Ceph-Store angelegt wird mit passender Größe.

Achtung – mit qemu-img info VHD-DATEI prüfen, was die tatsächliche Größe des Images ist, etwas „Luft“ addieren und in dieser Größe das Image im Ceph-Pool/Storage anlegen. Dann mit folgendem Voodoo-Befehl, das Image direkt – ohne Umwege importieren:

root@pve2:/mnt/pve/NAS/SBS2011/Virtual Hard Disks# qemu-img convert -p -n -f raw -O raw „/mnt/pve/NAS/SBS2011/Virtual Hard Disks/SBS2011_C.VHD“ ‚zeroinit:rbd:rbd_ssd/vm-107-disk-0:conf=/etc/pve/ceph.conf:id=admin:keyring=/etc/pve/priv/ceph/rbd_ssd.keyring‘
(19.00/100%)0%)

Der Fortschritt wird dann angezeigt.

elasticsearch sizing & replicas

root@kibana:/# curl -XGET 'http://localhost:9200/_cluster/health'
{"cluster_name":"elasticsearch","status":"yellow","timed_out":false,"number_of_nodes":1,"number_of_data_nodes":1,"active_primary_shards":1010,"active_shards":1010,"relocating_shards":0,"initializing_shards":0,"unassigned_shards":1000,"delayed_unassigned_shards":0,"number_of_pending_tasks":0,"number_of_in_flight_fetch":0,"task_max_waiting_in_queue_millis":0,"active_shards_percent_as_number":50.24875621890548}

Wir sehen hier schön, dass unassigned_shards hinterlegt sind, die fast identisch sind zur Anzahl active_shards. Das ist ein Anzeichen, dass hier nur auf einem Knoten der Index liegt, welcher auf keinen zweiten synchronisiert werden kann.

Workaround (setzt für den bestehenden Index, die Replikation auf 0 – kann auch nicht anders, wenn wir nur einen haben)

curl -H ‚Content-Type: application/json‘ -XPUT http://127.0.0.1:9200/_settings -d ‚
{
„index“ : {
„number_of_replicas“ : 0
}
}
‚

Zusätzlich, für neuen Index, per Default auch auf 0 setzen mit

curl -H 'Content-Type: application/json' -XPUT http://127.0.0.1:9200/_template/all
{
  "template": "*",
  "settings": {
    "number_of_replicas": 0
  }
}