Möchte man in einem Windows-Netzwerk von einem Management-Rechner auf die Ereignisanzeige anderer Computer zugreifen, klickt man mit der rechten Maustaste in der Ereignisanzeige auf „Ereignisanzeige“. Im Kontextmenü klickt man dann auf „Verbindung mit anderem Computer herstellen“.
Danach kann man in dem Eingabefeld „Anderer Computer“ den Computernamen des Computers eintragen, auf dessen Ereignisanzeige man zugreifen möchte.
Kommt keine Verbindung mit der Ereignisanzeige des Remotecomputers zustande, ist meistens die lokale Firewall des Remotecomputers daran Schuld.
Damit der Remotezugriff auf das Ereignisprotokoll funktioniert, müssen die Firewallregeln
Remote-Ereignisprotokollverwaltung (NP eingehend)
Remote-Ereignisprotokollverwaltung (RPC)
Remote-Ereignisprotokollverwaltung (RPC-EPMAP)
aktiviert werden.
Für den Remotezugriff auf die Windows-Ereignisanzeige notwendige Firewallregeln
Nach dem Aktivieren dieser Firewallregeln auf dem Remotecomputer sollte der Zugriff auf die Remote-Ereignisprotokolle funktionieren.
Erfolgreicher Zugriff auf die Ereignisanzeige eines Remote-Computers
Wenn eine SSH-Verbindung zu einem Server aufgebaut werden soll und der Host Key des Zielservers nicht mit dem Host Key für diesen Server in der lokalen Datei known_hosts übereinstimmt, wird aus Sicherheitsgründen keine Verbindung aufgebaut, da die Identität des Zielservers nicht eindeutig sichergestellt ist.
Beispielhafte Fehlermeldung:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: POSSIBLE DNS SPOOFING DETECTED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
The RSA host key for server.server.test has changed,
and the key for the corresponding IP address 88.188.188.88
is unchanged. This could either mean that
DNS SPOOFING is happening or the IP address for the host
and its host key have changed at the same time.
Offending key for IP in /root/.ssh/known_hosts:13
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
88:88:88:01:7f:f9:19:73:53:79:dd:a5:ac:88:88:88.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending RSA key in /root/.ssh/known_hosts:12
RSA host key for server.server.test has changed and you have requested strict checking.
Host key verification failed.
Wenn man die Gründe kennt, warum der Host Key des entfernten Servers nicht mit dem lokal gespeicherten Host Key übereinstimmt, dann kann man den lokalen Host Key aus der Datei known_hosts entfernen.
Bei älteren Linux-Systemen konnte man einfach den Key manuell aus der Datei known_hosts entfernen, da der Servername in Klartext den Key identifizierte. Da bei neueren Systemen aus Sicherheitsgründen der Servername verschlüsselt ist, geht ein manuelles Löschen des Host Key nicht mehr. Man muss nun den Host Key mit dem Programm ssh-keygen und dem Parameter -R und dem Servernamen für den Server, dessen Host Key entfernt werden soll, aus der Datei known_hosts entfernen.
Beispiel:
ssh-keygen -R server.server.test
Nach dem Entfernen des Host Key aus der Datei known_hosts wird man bei einem erneuten SSH-Verbindungsaufbau gefragt, ob man dem Zielserver vertraut. Wenn diese Frage mit „ja“ beantwortet wird, dann wird der aktuelle Host Key des Remoteservers der Datei known_hosts hinzugefügt.
Beispiel:
The authenticity of host 'server.server.test (88.188.141.88)' can't be established.
RSA key fingerprint is 88:88:88:01:7f:f9:19:73:53:79:dd:a5:ac:88:88:88.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'server.server.test' (RSA) to the list of known hosts.
Zukünftige SSH-Verbindungen zu dem Zielserver sollten dann ohne Sicherheitsabfrage funktionieren.
Neben dem in einem vorherigen Blogartikel vorgestellten Windows Live Writer kann man auch Microsoft Word 2013 als Editor für seine SharePoint-Blogeinträge verwenden.
Um jetzt Word 2013 mit seinem SharePoint-Blog zu verbinden, klickt man in seinem Blog in dem Blogtools-Menü auf den Eintrag Blogging-App starten.
Danach öffnet sich Word 2013 und man muss noch das Anlegen eines neuen Blogkontos bestätigen.
Nach dem Anlegen des Blogkontos für den SharePoint-Blog kann man Word für die Erstellung und die Bearbeitung von Blogeinträgen verwenden.
Wie auch beim Windows Live Writer kann man Word 2013 dazu verwenden, Beiträge für mehrere Blogs gleichzeitig zu veröffentlichen. Dazu kann man z. B. einen WordPress-Blog über die Option Konten Verwalten / Neu als Zielplattform hinzufügen.
Bei der Konfiguration für einen WordPress-Blog muss man nur die Blog-URL, den Benutzernamen und das Kennwort angeben. Alle weiteren Einstellungen werden von Word 2013 automatisch konfiguriert.
SharePoint 2013 bietet eine Website-Vorlage, mit der sich ein einfacher Blog realisieren lässt. Die Funktionalitäten eines SharePoint-Blogs bleiben aber weit hinter denen von z. B. WordPress zurück. Um wenigstens das Editieren von Blogbeiträgen etwas komfortabler zu gestalten, kann man den Windows Live Writer Editor von Microsoft als Editor für die Erstellung seiner Blogbeiträge verwenden.
Der Windows Live Writer ist Bestandteil der kostenlosen Windows Essentials von Microsoft.
Mit dem Windows Live Writer ist es unter anderem auch möglich, einen Blogbeitrag gleich für mehrere unterschiedliche Blogs zu erstellen. Beispielsweise kann man einen Blogbeitrag gleichzeitig für SharePoint und für einen WordPress-Blog zur Verfügung stellen.
Hier ein Screenshot von dem Windows Live Writer, mit dem dieser Artikel erstellt wurde:
Eine der wichtigsten Erleichterungen beim Erstellen von SharePoint-Blogbeiträgen durch den Windows Live Writer ist die Funktionalität, Bilder direkt aus der Zwischenablage in den Blog einfügen zu können, ohne das Bild vorher hochzuladen.
SharePoint 2013 bietet eine Funktion, die es Benutzern ohne ausreichende Zugriffrechte auf eine SharePoint-Webseite erlaubt, eine Anfrage zu senden, um Zugriff für diese Website zu beantragen.
Zugriffsanforderung auf eine SharePoint-Website durch einen Benutzer
Wenn diese Funktion aktiviert ist, dann ist als Standard eine Platzhalter-E-Mail-Adresse someone@example.com als Ziel für die Anfrage konfiguriert. Ändert man diese E-Mail-Adresse nicht auf einen gültigen Wert, bekommen die Anfragenden eine Fehlermeldung, dass die Mail nicht zugestellt werden kann.
Um diese Funktion zu konfigurieren, muss der Besitzer der SharePoint-Website-Sammlung die Einstellungen für die Website-Berechtigungen aufrufen.
Aufrufen des Konfigurationsmenüs
Aufrufen der Websiteeinstellungen
Aufrufen des „Websiteberechtigungen“-DialogsAufrufen der Einstellungen für ZugriffsanforderungenKonfiguration der E-Mail-Adresse für die Zugriffsanforderungen auf eine SharePoint 2013-Website
In den Einstellungen für die Zugriffsanforderungen auf eine SharePoint 2013-Website kann man nun die gewünschte E-Mail-Adresse des Empfängers der Zugriffsanforderungen konfigurieren. Hier lässt sich aber auch das Feature „Zugriffsanforderungen“ deaktivieren, in dem man die Option „Zugriffsanforderungen zulassen“ deaktiviert.
Dann bekommt ein Benutzer ohne Zugriffsrechte auf eine SharePoint-Website nur einen Hinweis. Eine Zugriffsanforderungsanfrage kann er dann nicht stellen.
Fehlermeldung bei nicht ausreichenden Zugriffsrechten auf eine SharePoint 2013-Website
Damit man diese Fehlermeldung wieder los wird, hat man folgende Optionen:
–events als Parameter dem mysqldump Befehl hinzufügen. –> Die Warnung verschwindet, da nun die Event-Tabelle explizit gesichert wird.
–ignore-table=mysql.event als Parameter dem mysqldump Befehl hinzufügen. –> Die Warnung verschwindet, da nun die Event-Tabelle explizit NICHT gesichert wird.
Wenn man das Backup-Script AutoMySQLBackup(Bugreport) einsetzt, findet man im Script folgende Zeile, in der man die gewünschte Option einfügen kann:
OPT="--quote-names --opt --single-transaction" # OPT string for use with mysqldump ( see man mysqldump )
Wenn die Event-Tabelle gesichert werden soll:
OPT="--quote-names --opt --single-transaction --events" # OPT string for use with mysqldump ( see man mysqldump )
Oder wenn die Event-Tabelle NICHT gesichert werden soll:
OPT="--quote-names --opt --single-transaction --ignore-table=mysql.event" # OPT string for use with mysqldump ( see man mysqldump )
Wenn das Bash-Completion-Feature auf Debian-Systemen richtig funktioniert, kann man z. B. die Dienste beim Service-Kommando mit der Tabulatortaste vervollständigen.
Beispiel für die Befehlsvervollständigung:
service ap<Tab>
service apache2 rel<Tab>
service apache2 reload
Wenn auf einem Debian-System die Vervollständigung von Befehlen mittels der Tabulatortaste nicht funktioniert, kann es sein, dass das Paket Bash-Completion nicht installiert ist.
Um zu überprüfen, ob das Bash-Completion-Paket installiert ist, kann man folgenden Befehl benutzen:
dpkg -l bash-completion | tail -1
Die Ausgabe des Befehls sollte dann wie folgt aussehen:
ii bash-completion 1:2.0-1 all programmable completion for the bash shell
Bleibt diese Ausgabe leer, dann ist das Paket Bash-Completion nicht installiert. Es lässt sich mit folgendem Befehl installieren:
apt-get install bash-completion
Sollte die Bash-Vervollständigung trotz installiertem Paket Bash-Completion nicht funktionieren, kann es daran liegen, dass das Vervollständigungs-Feature noch nicht aktiviert wurde. Bei Debian kann man diese Funktion in der Datei /etc/bash.bashrc aktivieren. Man muss nur die Kommentarzeichen vor folgenden Zeilen entfernen:
###Vorher
#if ! shopt -oq posix; then
# if [ -f /usr/share/bash-completion/bash_completion ]; then
# . /usr/share/bash-completion/bash_completion
# elif [ -f /etc/bash_completion ]; then
# . /etc/bash_completion
# fi
#fi
###Nachher
if ! shopt -oq posix; then
if [ -f /usr/share/bash-completion/bash_completion ]; then
. /usr/share/bash-completion/bash_completion
elif [ -f /etc/bash_completion ]; then
. /etc/bash_completion
fi
fi
Damit diese Einstellung aktiv wird, muss man sich am System ab- und wieder anmelden.
Das Erstellen einer Community-Website in SharePoint schlägt wegen eines fehlenden Features ‚Ratings‘ mit folgender Meldung fehl:
Das Abhängigkeitsfeature ‚Ratings‘ (ID: 915c240e-a6cc-49b8-8b2c-0bff8b553ed3) für das Feature ‚CommunitySite‘ (ID: 961d6a9c-4388-4cf2-9733-38ee8c89afd4) ist in diesem Bereich nicht aktiviert.
Lösung:
Aktivierung des Features ‚Ratings‘ mit der Powershell.
Aufgabenstellung: Man betreibt in seinem Heimnetzwerk einen Linux-Server und mehrere Windows-Rechner. Vom Internet aus möchte man nun auf seine Windows-Rechner per RDP (Remote Desktop Protocol Port 3389) zugreifen. Aus Sicherheitsgründen ist aus dem Internet aber kein direkter Zugriff auf den RDP Port 3389 im Heimnetzwerk möglich. Allein der Zugriff auf den Linux-Rechner per SSH ist per Port-Weiterleitung im Router des Heimnetzwerks aktiviert.
Lösung: Tunneln der RDP-Verbindung durch das SSH-Protokoll.
a) Nativ von einer Linux / Mac OSX Shell:
ssh -LYYYY:NAME_DES_WINDOWS_RECHNERS:3389 BENUTZERNAME@IP_DES_ROUTERS -p XXX
# -LYYYY = Lokaler Port über den die RDP-Vebindung geöffnet wird.
# NAME_DES_WINDOWS_RECHNERS: Name oder IP des Windows Rechners, auf den per RDP zugegriffen werden soll, im lokalen Netz
# -p XXX = Port der vom Router fürs Internet freigegeben wurde und an den SSH Port des Linux Rechner weiter geleitet wird.
# IP_DES_ROUTERS = Öffentliche IP Adresse oder DNS-Name unter der der Router im Internet zu erreichen ist.
# z.B:
ssh -L5000:192.168.1.234:3389 max@mustermann.dyndns.com -p 10000
b) Mit dem SSH-Client Putty von einem Windows-System:
Um mit Putty das RDP-Protokoll über eine SSH-Verbindung tunneln zu können, muss man in den Sessioneinstellungen, unter Connection –> SSH –> Tunnels den lokalen Port, den zu tunnelnden Remote Port und den Zielrechner für den Tunnel definieren:
Um nun also vom Internet aus auf seinen Windows-Rechner per RDP (Remote Desktop Protocol Port 3389) zuzugreifen, muss man, nachdem die SSH-Verbindung geöffnet wurde, eine RDP-Verbindung zu localhost:5000 (Localhost Port 5000) öffnen.
Beim Aufrufen einer Sharepoint-Seite mit Webparts, von denen der aktuelle Benutzer keine Rechte besitzt, wird folgender Fehler angezeigt:
Webpartfehler: Zugriff verweigert. Sie haben keine Berechtigung, diesen Vorgang auszuführen oder auf diese Ressource zuzugreifen.
SharePoint 2010: Webpartfehler Zugriff verweigert (Access Denied Web Part Error)
Die Sharepoint-Webseite soll Uploads von verschiedenen Benutzern zentral sammeln. Damit ein Benutzer nur Zugriff auf seine eigenen Uploads haben soll, wurde für jeden User eine eigene Dokumentenbibliothek angelegt. Bei dieser Dokumentenbibliothek wurde die Berechtigungsvererbung entfernt und nur dem User selbst und den administrativen Usern Rechte explizit gewährt. Um den Komfort zu erhöhen, wurde für jede Dokumentenbibliothek ein Webpart in die Standardseite eingefügt. Als ich mich mit einem Testuser, der nur Rechte auf eine Dokumentenbibliothek hatte, bei der Sharepoint-Webseite anmeldete, musste ich feststellen, dass die Webparts, auf die der User keine Berechtigungen hatte, nicht automatisch ausgeblendet wurden. Für jeden Webpart ohne Berechtigungen wurde der oben stehende Fehler angezeigt. Im Blogeintrag „SharePoint 2010 Access Denied Web Part Error“ musste ich lesen, dass man diesen Umstand nicht mit Sharepoint-Bordmitteln beheben kann („I am still waiting on Microsoft for that as well“). Die Lösung, die der Blogeintrag empfiehlt, ist eine „Quick and Dirty“-Lösung mit jQuery, die die Fehlermeldungen einfach clientseitig ausblendet. Dazu soll ein Inhaltswebpart mit einem jQuery Javascript Snippet am Seitenende eingefügt werden.
Dabei bin ich auf ein neues Problem gestoßen. Ich fand beim Inhaltswebpart von Sharepoint 2010 – im Unterschied zu Sharepoint 2007 – keine Option, um HTML-Quellcode einzugeben. Folgender Blogeintrag brachte eine einfache Lösung: „Insert JavaScript into a Content Editor Web Part„. Man muss den Code in eine Datei auslagern und diese dann dem Inhaltswebpart von Sharepoint 2010 zuweisen.
Einbinden von Code in das Inhaltswebpart
Nachdem dieses Problem gelöst worden war, musste ich feststellen, dass die Lösung, die Fehler mit jQuery auszublenden, noch nicht zufriedenstellend war. Die eigentlichen Fehler sind zwar ausgeblendet, die umgebenden Container aber nicht.
Ausgeblendete Webpartfehler Version 1
Leider waren immer noch Linien der umgebenden Containern zu sehen, ebenso störte der große Abstand zum Seitentitel. Nach etwas Experimentieren mit Firebug habe ich das Script wie folgt abgeändert:
Mit diesem Script wurden die Webpartfehler und die umgebenden Container vollständig ausgeblendet. Was jedoch bei dieser Lösung beachtet werden muss, ist, dass in der Ausgabe der Webparts, die angezeigt werden sollen, nicht das Wort ‚Fehler‘ vorkommt, da sonst auch dieses Webpart ausgeblendet werden würde.
