In dieser Anleitung wird davon ausgegangen, dass Ubuntu 18.04 bereits auf der Maschine installiert wurde. Weiter setzt die Anleitung eine funktionierende Internetverbindung auf dem Proxy voraus.

Um keine Probleme mit Berechtigungen zu bekommen, stellen Sie bitte sicher, dass Sie nun als Admin unterwegs sind:

sudo su

Zunächst laden wir uns dann das aktuelle Repository-Konfigurationspaket herunter:

wget https://repo.zabbix.com/zabbix/4.0/ubuntu/pool/main/z/zabbix-release/zabbix-release_4.0-2+bionic_all.deb
dpkg -i zabbix-release_4.0-2+bionic_all.deb

Dann aktualisieren wir Paketinformationen:

apt-get update

Jetzt können wir das Proxy-Paket herunterladen und installieren:

apt-get install zabbix-proxy-pgsql

Anschließend aktivieren und starten wir den Proxy:

systemctl enable zabbix-proxy
systemctl start zabbix-proxy

Nun erstellen wir den PostgreSQL-Benutzer, der vom Proxy verwendet wird, um auf die lokale Datenbank zuzugreifen. Sie werden nach Eingabe der Zeile wiederholt um die Eingabe des Kennworts für den User gebeten. „zabbix“ beschreibt den Benutzernamen, der natürlich variieren kann.

sudo -u postgres createuser --pwprompt zabbix

Im nächsten Schritt erstellen wir die Datenbank für den Proxy. Wir nennen diese im Beispiel ebenfalls „zabbix“:

sudo -u postgres createdb -O zabbix -E Unicode -T template0 zabbix

Dann wenden wir das von Zabbix mitgelieferte Schema auf die Datenbank an:

zcat /usr/share/doc/zabbix-proxy-pgsql/schema.sql.gz | sudo -u zabbix psql zabbix

Im letzten Schritt passen wir die Zabbix Proxy-Konfiguration an:

nano /etc/zabbix/zabbix_proxy.conf

Folgende Parameter müssen angepasst werden:

# IP oder FQDN des Hauptservers
Server=192.168.1.20
# Hostname des Proxies
Hostname=ZBX-PROXY
# DBHost muss wirklich leer bleiben, also wie abgebildet
DBHost=
# Name der Datenbank
DBName=zabbix
# Zuvor definierter Benutzer, den der Proxy zur DB-Verbindung verwendet
DBUser=zabbix
# Zuvor definiertes Passwort, das der Proxy zur DB-Verbindung verwendet
DBPassword=*******

Im Anschluss können wir den Zabbix Proxy einmal neustarten:

service zabbix-proxy restart

Bei Bedarf können mit folgender Zeile die Logfile-Einträge des Proxys in Echtzeit ausgegeben werden:

tail -f /var/log/zabbix/zabbix_proxy.log

Damit sollte die Installation abgeschlossen sein und Sie können den Proxy in Ihrer Zabbix-Oberfläche einrichten.

Ursache:

NFon hat eine eigene Firmware installiert, welche Drittanbieter abweist

Lösung: 

Werksreset ausführen–>beim Neustart: Provisionsdaten holen ->abbrechen auswählen ->mit Admin/Admin im Webmenü des Telefones einloggen.
Yealink Firmware vom Hersteller: aktuell 29.72.0.25 herunterladen und im Telefon installieren
Danach können SIP Daten normal/erfolgreich gespeichert werden

Stellen Sie zunächst sicher, dass der SSH-Dienst auf dem ESXi-Host aktiviert ist: Host –> Manage –> Reiter: Services –> TSM-SSH starten (falls nicht gestartet).

Dann greifen wir per SSH auf den Host zu. Die Zugangsdaten sollten Sie parat haben.

Nacheinander führen wir folgende Schritte aus:

Enfernung der aktuellen Lizenzdatei

rm -r /etc/vmware/license.cfg

Kopieren der neuen Lizenzdatei (liegt bereits auf Host):

cp /etc/vmware/.#license.cfg /etc/vmware/license.cfg

ESXi-Dienst neustarten:

/etc/init.d/vpxa restart

Nun können Sie testen, ob alles wieder funktioniert. In unserem Fall lies sich eine VM dennoch nicht starten. Bei uns hat es geholfen, dann noch komplett alle ESXi-Dienste neuzustarten:

/etc/vmware/sbin/services.sh restart

Nun sollten Sie weitere 60 Tage ESXi testen können. Diese Schritte sollten Sie selbstverständlich nur im Testlab ausführen und nicht produktiv nutzen!

Die IP-Konfiguration des Integrated Management Modules (IMM) muss nicht zwingend über das BIOS/UEFI geschehen. Sie können diesen Schritt auch direkt über das Betriebssystem erledigen und müssen hierbei nicht einmal den Server neustarten. Lediglich das IMM-Modul wird hier kurz im Kreis gedreht.

Benötigt wird dafür das sogenannte ASU, ein Programm, dass Sie von IBM beziehen können. Laden Sie die für Sie passende Version herunter:

Ältere IBM-Systeme
Neuere Lenovo-Systeme – ab etwa 2015
(Sie müssen jeweils etwas herunterscrollen um den Download aufrufen zu können. Dort sehen Sie dann die kompatiblen Systeme)

Wählen Sie beim Download die HTTPS-Variante, um den unnötigen Downloadmanager zu vermeiden. Laden Sie dann die .exe-Date herunter.

Die .exe-Datei verschieben Sie dann auf dem jeweiligen Host in einen extra Ordner. Der Grund dafür ist, dass Sie beim Klick auf die Datei selbige nur im aktuellen Ordner entpacken. Sie können die ursprüngliche Datei im Anschluss sogar löschen. Der Inhalt des Ordners sollte dann wie folgt aussehen:

Ordnerinhalt

Mit der Kommandozeile sollten Sie sich nun in diesen Ordner begeben. Dann geben Sie bitte folgende Zeilen nacheinander ein:

asu64.exe set imm.hostipaddress1 [IP-Adresse]
asu64.exe set imm.hostipsubnet1 [Subnetzmaske]
asu64.exe set imm.gatewayipaddress1 [Gateway-IP]
asu64.exe set imm.dhcp1 disable
asu64.exe rebootimm

Praktisches Beispiel:

asu64.exe set imm.hostipaddress1 192.168.10.20
asu64.exe set imm.hostipsubnet1 255.255.255.0
asu64.exe set imm.gatewayipaddress1 192.168.10.1
asu64.exe set imm.dhcp1 disable
asu64.exe rebootimm

Der letzte Befehl startet das IMM neu, so dass Sie wenig später die neue IP-Adresse im Browser aufrufen können.

Sofern phpMyAdmin über apt-get installiert wurde, können Sie die Software nur so lange aktualisieren, wie Ihre gewählte Distribution noch neue Versionen unterstützt. Aufgrund aktueller Sicherheitsprobleme wollen wir aber phpMyAdmin in diesem Beispiel auf die wirklich aktuellste Version aktualisieren, welche von der Distribution so nicht mehr unterstützt wird.

Dazu aktualisieren wir die phpMyAdmin-Version zunächst auf die höchste, von der Distribution zugelassene Version:

# Als erstes aktualisieren wir unsere Update-Liste.
sudo apt-get update
# Dann aktualisieren wir phpmyadmin, tatsächlich mit 'install'.
sudo apt-get install phpmyadmin

Normalerweise sollte phpMyAdmin nun unter /usr/share installiert sein. Dort gehen wir nun als nächstes hin.

cd /usr/share

Dort angekommen, entfernen wir das phpMyAdmin-Verzeichnis:

rm -rf phpmyadmin

Mittels wget (muss eventuell zuvor heruntergeladen werden) können wir nun die aktuellste Version über den Hersteller beziehen. Den Link für die .tar.gz-Datei fügen Sie bitte in den nächsten Befehl ein.

# Hier bitte den Link einsetzen und die eckigen Klammern entfernen
wget -P /usr/share/ "[Link]"

# Beispiel 
wget -P /usr/share/ "https://files.phpmyadmin.net/phpMyAdmin/4.8.4/phpMyAdmin-4.8.4-all-languages.tar.gz"

Das heruntergeladene Paket werden wir nun extrahieren, den extrahierten Inhalt in den ursprünglichen Ordner kopieren und letztendlich dann die nicht mehr benötigten Dateien entfernen.

# Entpacken
tar -xvzf phpMyAdmin-4.8.4-all-languages.tar.gz
# Kopieren
cp -r phpMyAdmin-4.8.4-all-languages phpmyadmin
# Rest entfernen
rm -rf phpMyAdmin-4.8.4-all-languages
rm phpMyAdmin-4.8.4-all-languages.tar.gz

Ab jetzt könnte man wieder auf phpMyAdmin zugreifen, wir führen aber noch weitere Anpassungen durch, um Probleme zu vermeiden.

Als erstes erstellen wir ein TMP-Verzeichnis für phpMyAdmin und weißen diesem die richtigen Rechte zu.

# Ins richtige Verzeichnis springen
cd /usr/share/phpmyadmin/
# Ordner anlegen
mkdir tmp
# Rechte anpassen
chown -R www-data:www-data /usr/share/phpmyadmin/tmp

Anschließend erstellen wir noch eine Konfigurationsdatei und passen diese noch ein wenig an. Als Vorlage verwenden wir hier die Sample-Datei.

# Ins richtige Verzeichnis springen
cd /usr/share/phpmyadmin/
# Vorlage kopieren
cp config.sample.inc.php config.inc.php
# Datei editieren
nano config.inc.php

Als erstes fügen wir das Blowfish-Secret ein, um das Kennwort im Cookie von phpMyAdmin zu verschlüsseln. Dazu generieren wir als erstes eine Zeichenfolge, Recherchen haben mich zu folgendem Generator geführt: https://www.motorsportdiesel.com/tools/blowfish-salt/pma/. Die dort ausgegebene Zeile ersetzt die Zeile $cfg[‚blowfish_secret‘] = “; in der Konfigurationsdatei. Beispiel:

$cfg['blowfish_secret'] = '%KE0>eWP`67o]t+Qkw*g^o5CJphcvW';

Prinzipiell sind wir hier fertig und Sie können die Konfigurationsdatei speichern und schließen. Wir haben jedoch noch folgende Anpassungen durchgeführt:

Optional: Warnungen und information_schema-Tabelle ausblenden

Als nächstes bewegen wir unseren Cursor in der Konfigurationsdatei herunter bis zur Stelle /* Server parameters */. Hier hängen wir noch folgende Zeilen an:

/* custom settings */
$cfg['Servers'][$i]['hide_db'] = 'information_schema';
$cfg['PmaNoRelation_DisableWarning'] = true;

Nun können Sie die Konfigurationsdatei abspeichern. Ein Dienstneustart ist nicht erforderlich, die PHP-Seiten werden mit dem nächsten Seitenreload neu eingelesen und übernommen.

Recherchequelle: StackExchange (AskUbuntu)

Man kann mit der Computerverwaltung nicht nur den lokalen Computer verwalten, sondern sich auch remote auf andere Rechner schalten. In unserem Fall war es nun aber so, dass wir von einem Rechner in einer ActiveDirectory-Domain (A) auf einen Rechner drauf wollten, der sich nicht in der Domain befand (B). Der User, mit dem wir uns also auf Rechner B schalten wollten, war selbigem komplett unbekannt. Somit stellte sich die Frage, wie wir uns hier mit einem anderen Benutzer authentifizieren können.

Aber der Reihe nach. Als erstes greifen wir auf die lokale Computerverwaltung zu:

Dort angekommen, können wir uns nun mit dem anderen Computer per IP-Adresse verbinden:

Dies mag sogar manchmal noch gehen, jedoch bekommt man spätestens beim Zugriff auf die Dienste o.ä. einen „Zugriff verweigert“-Fehler zurück.

Um diesen Fehler zu verhindern, gibt es einen ziemlich tollen Trick. Mittels des „net use“-Befehls kann man sich nämlich an einem fremden Rechner authentifizieren, um beispielsweise ein Netzlaufwerk zu mappen. Diese Authentifizierung gilt global, also über das Laufwerkmapping hinaus und somit auch tatsächlich für unsere Computerverwaltung.

Wir öffnen also die Kommandozeile ([Win] + [R] –> cmd) oder PowerShell und geben folgende Zeile ein:

net use \c$ /user:

Damit verbinden wir uns auf die versteckte C$-Freigabe, die auf wirklich jedem PC verfügbar sein sollte. Dabei ersetzen wir die eingefärbten Zeichenfolgen natürlich sinnvoll. Ist der Zielcomputer nicht in einer Domäne, so können Sie „“ weglassen. Statt dem Computernamen können Sie natürlich auch eine IP eintragen.

Sie bekommen dann noch eine Passwortabfrage, die Sie für den User entsprechend ausfüllen sollten. Sofern alles passt, bekommen Sie den Erfolg mit der Meldung „Der Befehl wurde erfolgreich ausgeführt.“ quittiert:

Nun können Sie sich nochmal auf den Remotecomputer schalten und diesen ohne Probleme verwalten können.

Falls Sie Perfomance-Probleme mit Ihrer Dynamics CRM / 365-Instanz haben, können Sie mit den folgenden Schritten etwas mehr ins Detail gehen, um zu sehen, an welcher Stelle es tatsächlich hängt.

Rufen Sie als erstes bitte ein Formular auf, von dem Sie denken, dass es wirklich langsam lädt. In unserem Beispiel verwenden wir das Firmenformular:

Der nächste Schritt ist Browserabhängig:
Internet Explorer: Drücken Sie [Strg] + [Shift] + [Q] zum Aufruf des Performance Centers
Chrome: Drücken Sie [Strg] + [D] und drücken Sie dann auf [Mehr …]. Als URL geben Sie folgende Zeichenfolge ein (ohne Anführungszeichen): „javascript:Mscrm.Performance.PerformanceCenter.get_instance().TogglePerformanceResultsVisibility()“ und als Namen beispielsweise „Performance Center“. Dadurch haben Sie oben nun einen Knopf in der Lesezeichenleiste, den Sie nun drücken um das Performance Center aufzurufen.
Firefox: Drücken Sie [Strg] + [B] um die Lesezeichenleiste aufzurufen. Fügen Sie hier ein neues Lesezeichen mit der URL „javascript:Mscrm.Performance.PerformanceCenter.get_instance().TogglePerformanceResultsVisibility()“ (ohne Anführungszeichen) ein und benennen Sie es treffend. Klicken Sie dieses danach an, während Sie das betroffene Formular im aktiven Tab geöffnet haben.

In allen Fällen sollten Sie nun ein Performance Center sehen. Hier drücken Sie nun nacheinander [Enable] (1) und dann [Close] (2):

Lösen Sie nun einen Reload der Seite aus. Dies kann durch drücken von [F5] oder des „Aktualisieren“-Knopfes erfolgen.

Rufen Sie anschließend wieder das Performance Center auf. Sie sehen nun den Ablauf des Seitenaufbaus (3). Mit dem Knopf [Copy All] (4) können Sie nun die Wartezeiten auch nochmal als Text herauskopieren.

Sollten Sie für unser Hosted Dynamics 365 einen Performance-Auszug machen, so würden wir Sie zum einen um den Text bitten, den Sie über den [Copy All]-Knopf heraus bekommen und zum anderen könnten Sie uns noch einen Screenshot von der Balkendiagramm-Darstellung schicken.

Dies ist ein Beispiel für einen Netplan mit IPv4- und IPv6-Konfiguration. Dabei wurden die IP-Adressen durch allgemein gültige ersetzt.

# Diese Datei beschreibt die verfügbaren Netzadapter in Ihrem System
# Für mehr Informationen netplan(5) aufrufen.
network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      # DHCP wird deaktiviert
      dhcp4: no
      dhcp6: no
      # Konfiguration der Adressen, pro Adresse eine Zeile.
      addresses:
        - 192.168.1.123/24
        - 123:4567:ab12:3:192:168:1:123/64
      # Gateways
      gateway4: 192.168.1.1
      gateway6: 123:4567:ab12:3::1
      # Konfiguration der DNS-Server, auch hier mehrere Server respektive Zeilen möglich.
      nameservers:
        addresses:
          - 192.168.1.1
          - 192.168.1.2
          - 123:4567:ab12:3:192:168:1:1
          - 123:4567:ab12:3:192:168:1:2

Angewendet wird der Netplan dann über folgenden Befehl:

sudo netplan apply

Zuerst lassen wir uns die verfügbaren Disks anzeigen, um herauszufinden, auf welcher Disk wir die neue Partition erstellen:

fdisk -l

In unserem Beispiel gehen wir nun von der 2. Disk aus, die über /dev/sdb adressiert wird. Auf dieser Disk erstellen wir nun als erstes ein sogenanntes Physical Volume. Dazu gehen wir zuerst in die LVM-Befehlszeile:

sudo lvm

Anschließend können wir das Physical Volume erstellen:

pvcreate /dev/sdb

Sie können an dieser Stelle auch mehrere Physical Volumes erstellen, die Sie dann im nächsten Schritt zusammenfassen. Wenn Sie mehrere Volumes anlegen wollen, können Sie diese entweder mittels Leerzeichen getrennt an obigen Befehl ranhängen, oder aber den Befehl für jedes Volume entsprechend ausführen.

Das Ergebnis können wir folgendermaßen anzeigen:

pvdisplay /dev/sdb

Nun können wir die zuvor angelegten Physical Volumes zu einer Volume Group zusammenfassen. Dazu geben wir zuerst den Namen an und anschließend die Physical Volumes – wieder durch Leerzeichen getrennt. In unserem Fall haben wir nur eines:

vgcreate sql-vg /dev/sdb

Das Resultat können wir über folgenden Befehl abrufen:

vgdisplay sql-vg

Innerhalb der Volume Group können wir nun endlich die Logical Volumes erstellen – Unsere nachher in Unix sichtbaren Partitionen. Dabei geben wir die Größe der Partition, den Namen und die Volume Group an:

lvcreate -L 199.996G -n sqldata sql-vg

Die Größe wurde übrigens genommen, weil ursprünglich 200G (volle Größe der Volume Group) geplant waren, das aber als „zu groß“ vom System abgelehnt wurde. Deswegen hab ich dann immer 1MB abgezogen und nochmal versucht. Bei 199.996G ging es dann und wurde auch aufgerundet vom System.

Das Resultat können wir wieder mit folgendem Befehl betrachten:

lvdisplay /dev/sql-vg/sqldata

Nun sind wir in der LVM-Befehlszeile fertig und können diese verlassen:

exit

Anschließend formatieren wir unsere neue logische Partition noch mittels folgendem Befehl (ext3):

mke2fs -j /dev/sql-vg/sqldata

Jetzt können wir die neue Partition noch mounten. In unserem Fall wollten wir die Partition direkt unter Root mounten. Dazu erstellen wir ein Verzeichnis am Zielort und mounten die Partition dann:

mkdir /sqldata
mount /dev/sql-vg/sqldata /sqldata

Damit wird die Partition nutzbar. In unserem Fall war es das Datenverzeichnis für unsere ersten Gehversuche mit MSSQL unter Linux.

Ressourcen-Postfächer kann man so konfigurieren, dass Sie Termine automatisch annehmen. Geschieht die Konfiguration über das ECP oder über den simplen

Get-CalendarProcessing [Identity] | Set-CalendarProcessing -AutomateProcessing AutoAccept

-Befehl, so klappt die automatische Annahme solange, bis ein Terminkonflikt entsteht. In einer Terminserie ist das dann besonders ärgerlich, da alle Serienelemente abgelehnt werden, sobald sich ein Element mit einem vorhanden Termin überschneidet. Dies kann man umgehen, in dem man weitere Parameter anpasst. Grundsätzlich zu klären wäre dabei folgende Frage: Sind Überschneidungen erlaubt?

Wenn Überschneidungen erlaubt sind, kann man die Einstellungen wie folgt überschreiben:

Get-CalendarProcessing [Identity] | Set-CalendarProcessing -AutomateProcessing AutoAccept -AllowConflicts $true

Damit werden die Termine einfach parallel zu eventuell bereits bestehenden Terminen eingetragen. Das macht dann Sinn, wenn ein Raum beispielsweise doppelt belegbar ist.

Wenn man Überschneidungen vermeiden will und stattdessen wünscht, dass sich überschneidende Termine einfach abgelehnt werden ohne die ganze Serie abzulehnen, so ist folgender Befehl zu verwenden:

Get-CalendarProcessing [Identity] | Set-CalendarProcessing -AutomateProcessing AutoAccept -AllowConflicts $false -ConflictPercentageAllowed 50 -MaximumConflictInstances 15

Der Parameter –ConflictPercentageAllowed gibt hierbei an, welcher Anteil an Serienelementen auf Grund von Überschneidungen abgelehnt werden darf (in Prozent, aber anzugeben ohne ‚%‘-Zeichen), während -MaximumConflictInstances angibt, wie viele Serienelemente wegen Überschneidungen abgelehnt werden dürfen. Beide Werte kann man dabei natürlich utopisch hochsetzen um zu garantieren, dass jede Serie angenommen wird. Dennoch sind sicher an der ein oder anderen Stelle sinnvoll gewählte Grenzwerte nützlich.

Achtung: Solange -AllowConflicts auf $true steht, haben die für –ConflictPercentageAllowed und -MaximumConflictInstances gesetzten Werte keinen Einfluss, sie werden ignoriert.