MediaMill Blog

Kategorie: Allgemein

  • SSH Host Key aus der Datei known_hosts entfernen

    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.

    Quelle: http://www.linuxforme.de

  • Konfiguration der SharePoint 2013-Funktionalität „Zugriffsanforderungen“

    ​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
    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 von SharePoint 2013
    Aufrufen des Konfigurationsmenüs

     

    Aufrufen der Websiteeinstellungen einer SharePoint Website
    Aufrufen der Websiteeinstellungen

     

    Aufrufen des "Websiteberechtigungen" - Dialogs einer SharePoint 2013 Website
    Aufrufen des „Websiteberechtigungen“-Dialogs
    Aufrufen der Einstellungen für Zugriffsanforderungen bei SharePoint 2013
    Aufrufen der Einstellungen für Zugriffsanforderungen
    Konfiguration der E-Mail Adresse für die Zugriffsanforderungen auf eine SharePoint 2013 Website
    Konfiguration 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 Zugriffrechten auf eine SharePoint 2013 Website
    Fehlermeldung bei nicht ausreichenden Zugriffsrechten auf eine SharePoint 2013-Website

     

  • mysqldump / AutoMySQLBackup Warning: Skipping the data of table mysql.event. Specify the –events option explicitly

    Nach einem Update auf MySQL 5.5.3, taucht in den Logs der Datenbank-Backups folgende Warnung auf:

    -- Warning: Skipping the data of table mysql.event. Specify the --events option explicitly

    Unter mysql-and-warnings-yet-another wird ausführlich auf die Problematik eingegangen.

    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 )

  • Das MySQL Init Script /etc/init.d/mysql schlägt unter Debian mit dem Fehler „error: ‚Access denied for user ‚debian-sys-maint’@’localhost’“ fehl

    Nach einer Migration von einem openSUSE Linux zu einem Debian System funktionierte das init Script /etc/init.d/mysql zum Verwalten des MySQL Dienstes nicht mehr. Während der Migration wurde ein Backup aller Datenbanken in dem neuen System eingespielt, unter anderem auch die MySQL Systemdatenbank mysql.

    Bei einem Versuch, anschließend mit „/etc/init.d/mysql stop“ den Datenbankdienst zu beenden, trat folgender Fehler auf:

    # /etc/init.d/mysql stop
    Stopping MySQL database server: mysql failed!

    Der Versuch, den Status des MySQL Dienstes anzuzeigen, brachte einen ersten Hinweis:

    # /etc/init.d/mysql status
    /usr/bin/mysqladmin: connect to server at ‚localhost‘ failed
    error: ‚Access denied for user ‚debian-sys-maint’@’localhost‘ (using password: YES)‘

    Das init Script versucht mit einem eigenen User namens ‚debian-sys-maint‘, den MySQL Datenbankserver zu verwalten. Dieser User existiert aber nicht, da alle Datenbanken inklusive der MySQL Systemdatenbank von einem Opensuse System stammen. In dieser MySQL System Datenbank existiert natürlich kein User namens ‚debian-sys-maint‘.

    Eine Webrecherche brachte dann Gewissheit. Debian benutzt einen eigenen User für Operationen mit dem MySQL Dienst. Die Credentials für diesen User sind in der Datei /etc/mysql/debian.cnf abgelegt:

    # less /etc/mysql/debian.cnf
    # Automatically generated for Debian scripts. DO NOT TOUCH!
    [client]
    host = localhost
    user = debian-sys-maint
    password = PASSWORD
    socket = /var/run/mysqld/mysqld.sock
    [MySQL_upgrade]
    host = localhost
    user = debian-sys-maint
    password = PASSWORD
    socket = /var/run/mysqld/mysqld.sock
    basedir = /usr

    Um obiges Problem zu lösen, muss also ein User namens ‚debian-sys-maint‘ auf dem MySQL Server mit den entsprechenden Rechten existieren.

    Dazu meldet man sich bei MySQL an:

    mysql -u root -p

    Mit folgendem Befehl wird in einem Schritt der User ‚debian-sys-maint‘ angelegt und mit den entsprechenden Rechten ausgestattet.

    MySQL> GRANT ALL PRIVILEGES ON *.* TO ‚debian-sys-maint’@’localhost‘ IDENTIFIED BY ‚PASSWORD‘ WITH GRANT OPTION;

    Ab jetzt sollte das Init Script /etc/init.d/mysql wieder wie gewohnt funktionieren:

    # /etc/init.d/mysql stop
    Stopping MySQL database server: mysqld.
    # /etc/init.d/mysql start
    Starting MySQL database server: mysqld.
    Checking for corrupt, not cleanly closed and upgrade needing tables..
    # /etc/init.d/mysql status
    /usr/bin/mysqladmin Ver 8.42 Distrib 5.1.49, for debian-linux-gnu on i486
    Copyright 2000-2008 MySQL AB, 2008 Sun Microsystems, Inc.
    This software comes with ABSOLUTELY NO WARRANTY. This is free software,
    and you are welcome to modify and redistribute it under the GPL license
    Server version 5.1.49-3
    Protocol version 10
    Connection Localhost via UNIX socket
    UNIX socket /var/run/MySQLd/mysqld.sock
    Uptime: 6 sec
    Threads: 2 Questions: 655 Slow queries: 0 Opens: 9766 Flush tables: 1 Open tables: 64 Queries per second avg: 109.166.

  • Bei TYPO3 den „div wrap csc-default“ um HTML Inhaltselemente entfernen

    Bei der Umsetzung eines CSS-Entwurfs einer Webseite in TYPO3 störte mich, dass TYPO3 seit der Version 4.3 um jedes Contentelement einen DIV Tag mit der Klasse csc-default legt.
    Normal stört dieser DIV auch nicht – nur wenn man Inhalt an eine Stelle des Templates ausgeben will, die von einem HTML Tag umgeben ist, das keine Blockelemente wie DIV erlaubt. Konkret wollte ich Adressinformationen in einem ADDRESS Tag ausgeben. Dabei entsteht eine ungültige Konstellation, in der ein DIV Blockelement in einem ADDRESS Element eingebettet ist.

    Im Web fand ich verschiedene Lösungsansätze:

    1. Im Template unter include static CSS Styled Content durch CSS Styled Content TYPO3 v4.2 ersetzen.
    2. Entfernen der Wraps um alle Contentelemente

      tt_content.stdWrap.innerWrap >

    Mit beiden Ansätzen konnte ich mich nicht so recht anfreunden. Einerseits will ich nicht immer und ewig TYPO3 4.2 kompatibele statische Templates verwenden, andererseits wollte ich nicht auf die Möglichkeit verzichten, Contentelemente mit Rahmen zu versehen. Diese Möglichkeit hat man nicht mehr, wenn man alle DIV Wraps um die Contentelemente entfernt. Ich habe nach einer Möglichkeit gesucht, selektiv nur bei HTML Inhaltselementen die DIV Wraps zu unterbinden.

    Auf www.typo3forum.net fand ich eine Typoscript Lösung, die genau das tut:

    tt_content.html.prefixComment >
    tt_content.stdWrap.innerWrap.override = |
    tt_content.stdWrap.innerWrap.override.if {
    equals = html
    value.field = CType
    }

  • TYPO3 Extension tt_news: Uhrzeit nicht anzeigen, wenn keine Zeit festgelegt wurde. Anzeige der Uhrzeit 00:00 unterdrücken.

    Bei einem Projekt sollte die TYPO3 Extension tt_news für die Anzeige von Terminen verwendet werden. Dabei sollte das Erstelldatum als Datum eines Termins missbraucht werden. Da aber nicht jeder Termin eine Uhrzeit hatte, kam es zu dem unschönen Effekt, dass bei einem Termin ohne Zeitangabe die Uhrzeit immer mit 00:00 angezeigt wurde. Eine Webrecherche ergab, dass schon verschiedene andere das gleiche Problem hatten, aber eine Lösung nicht zu finden war. Den Zeitplatzhalter generell aus dem Template zu entfernen war keine Lösung, da ja bei Terminen mit einer Zeitangabe die Uhrzeit angezeigt werden sollte. Die Lösung musste also folgendermaßen aussehen: Wenn bei einem Newsartikel (Termin) eine Uhrzeit festgelegt wird, soll diese angezeigt werden. Wenn keine Uhrzeit festgelegt wurde, bzw. die Uhrzeit auf 00:00 steht, dann soll keine Uhrzeit angezeigt werden.

    tt_news Anzeige mit Uhrzeit 00:00
    Anzeige mit Uhrzeit 00:00
    tt_news ohne Uhrzeit 00:00
    Anzeige ohne Uhrzeit 00:00

    Nach einigem Probieren erreichte ich mit folgenden Typoscript-Zeilen den gewünschten Effekt.

    #List Anzeige
    plugin.tt_news.displayList.time_stdWrap.strftime = %H:%M Uhr
    plugin.tt_news.displayList.time_stdWrap.wrap = – |
    plugin.tt_news.displayList.time_stdWrap.if.value.field = datetime
    plugin.tt_news.displayList.time_stdWrap.if.value.strftime = %H:%M
    plugin.tt_news.displayList.time_stdWrap.if.equals = 00:00
    plugin.tt_news.displayList.time_stdWrap.if.negate = 1
    #Latest Anzeige
    plugin.tt_news.displayLatest.time_stdWrap.strftime = %H:%M Uhr
    plugin.tt_news.displayLatest.time_stdWrap.wrap = – |
    plugin.tt_news.displayLatest.time_stdWrap.if.value.field = datetime
    plugin.tt_news.displayLatest.time_stdWrap.if.value.strftime = %H:%M
    plugin.tt_news.displayLatest.time_stdWrap.if.equals = 00:00
    plugin.tt_news.displayLatest.time_stdWrap.if.negate = 1

  • Sortierte Ausgabe von du -h (Kombinieren von du -h und sort)

    Eine Ergänzung zu dem Artikel „Unter Linux eine Liste der größten Dateien ausgeben“

    Ich habe schon öfters nach einer Möglichkeit gesucht, die Ausgabe des Linux-Befehls du mit dem Parameter „-h“ (für human-readable) sortiert nach der Größe ausgeben zu lassen. Sortieren ohne die Option „-h“ ist kein Problem. Dann wird die Ausgabe von du standardmäßig nach KB sortiert.

    du /var --max-depth=1 |sort -nr
686528 /var
575840 /var/lib
62848 /var/log
46628 /var/cache
872 /var/adm
156 /var/spool
128 /var/run
28 /var/lock
8 /var/tmp
4 /var/X11R6
4 /var/opt
4 /var/games
4 /var/crash

    Mit dem Parameter –block-size=1M oder  –block-size=1G kann man noch die Einheit der Größenangabe festlegen.

    du /var --block-size=1M --max-depth=1 |sort -nr

6729 /var
5237 /var/lib
1021 /var/cache
412 /var/log
54 /var/www
7 /var/backups
1 /var/tmp
1 /var/spool
1 /var/opt
1 /var/mail
1 /var/local

    Was aber immer noch fehlt ist die sortierte Ausgabe mit flexiblen, je nach Ordnergröße angepassten, „Human Readable (wie KB MB GB)“ Größenangaben. Dies lässt sich durch eine Kombination von du sort cut xargs und wieder du erreichen.

    du  /var/ --max-depth=1 | sort -nr | cut -f2 | xargs -n 1 du -hs

6,6G    /var/
5,2G    /var/lib
1023M   /var/cache
413M    /var/log
54M     /var/www
6,5M    /var/backups
72K     /var/spool
4,0K    /var/tmp
4,0K    /var/opt
4,0K    /var/mail
4,0K    /var/local

  • Ermitteln der Linuxdistribution, Linuxversion, Kernelversion, CPU, RAM, HD-Kapazität

    Befehle zum Ermitteln der Linux-Distribution und der Version der Linux-Distribution:

    cat /etc/issue

    Beispielausgabe:

    Fedora release 9 (Sulphur)
Kernel \r on an \m (\l)

    oder

    Welcome to openSUSE 11.1 - Kernel \r (\l).

    Befehle zum Ermitteln der Version des Linuxkernels:

    uname -r

    Ausgabe:

    2.6.27.12-78.2.8.fc9.x86_64

2.6.18-028stab064.7

2.6.27.48-0.1-pae

    oder

    cat /proc/version

    Ausgabe:

    Linux version 2.6.18-028stab064.7 (root@rhel5-64-build) (gcc version 4.1.2 20070 626 (Red Hat 4.1.2-14)) #1 SMP Wed Aug 26 13:11:07 MSD 2009

Linux version 2.6.27.48-0.1-pae (geeko@buildhost) (gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) ) #1 SMP 2010-07-05 22:20:39 +0200

     

    Befehle zum Ermitteln der CPU Informationen:

    cat /proc/cpuinfo

    Ausgabe:

    processor : 0
vendor_id : AuthenticAMD
cpu family : 16
model : 2
model name : Quad-Core AMD Opteron(tm) Processor 2347 HE
stepping : 3
cpu MHz : 1431.598
cache size : 512 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 4
apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc nonstop_tsc pni cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy altmovcr8 abm sse4a misalignsse 3dnowprefetch osvw
bogomips : 3817.59
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate [8]

    oder

    lscpu

    Ausgabe:

    lscpu
Architecture:          i686
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                4
Vendor ID:             AuthenticAMD
CPU family:            16
Model:                 2
Stepping:              3
CPU MHz:               1425.000
BogoMIPS:              3817.70
Virtualization:        AMD-V

    Befehle zum Ermitteln der HD Speicherplatzbelegung:

    df -h

    Ausgabe:

    Dateisystem Size Used Avail Use% Eingehängt auf
/dev/vzfs   25G  21G  4,6G  82%  /

    Befehle zum Ermitteln der RAM Speicherbelegung:

    free -m -t

    Ausgabe:

          total used free shared buffers cached
Mem:  2048  72   1975 0      0       0
-/+ buffers/cache: 72 1975
Swap: 0 0 0
Total: 2048 72 1975

  • Nach dem Update von TYPO3 auf die Version 4.3 funktioniert ImageMagick nicht mehr

    Problem:

    Nach dem Update von TYPO3 auf die Version 4.3 funktioniert ImageMagick 4.2.9 nicht mehr.

    Symptome:

    Im Backend werden z.B. keine Vorschaubilder von Grafiken mehr generiert. Stattdessen
    erscheint ein Bild mit dem Hinweis: No thumb generated!

    Im Install-Tool unter dem Menüpunkt Image Processing schlagen die Grafikoperationen fehl.

    Lösung:

    Ändern der neu hinzugekommenen Einstellung im_useStripProfileByDefault im Install-Tool unter All Configurations von 1 auf 0.

    Vorher:

    [‚GFX‘][‚im_useStripProfileByDefault‘] = 1

    Nachher:

    [‚GFX‘][‚im_useStripProfileByDefault‘] = 0

    Quelle:
    http://www.typo3forum.net

    Nähere Infos:
    http://bugs.typo3.org

  • Entfernen des „Versteckt“(hidden)-Attributs von einem Ordner nach einer Robocopy-Aktion

    Wenn man mit Robocopy ein komplettes Laufwerk in ein Verzeichnis auf einem anderen Datenträger kopiert, wird man feststellen, dass der Zielordner plötzlich versteckt ist. Das heißt, das Hidden-Attribut des Ordners ist gesetzt. In den Dateieigenschaften kann man dieses hidden Flag auch nicht deaktivieren. Die Checkbox ist ausgegraut.

    Versteckt Attribut eines Ordners gesetzt aber nicht bearbeitbar
    Versteckt Attribut eines Ordners gesetzt aber nicht bearbeitbar

    Verursacht wird dieses Verhalten, wenn mit Robocopy Systemdateien wie z.B. der Ordner „System Volume Information“  mit in das Zielverzeichnis kopiert werden. Dadurch wird anscheinend im übergeordneten Ordner auch das System-Flag gesetzt und gleichzeitig das Hidden-Flag. Ein erster Versuch mit dem Kommandozeilenprogramm attrib

    attrib -h ORDNERPFAD

    das Hidden-Flag zu entfernen, schlug fehl. Die Fehlermeldung lautete „Systemdatei wird nicht zurückgesetzt“. Also versuchte ich mit

    attrib -s ORDNERPFAD

    das System-Flag des neuen Ordners zu entfernen. Aber auch hier erscheint die Fehlermeldung „Versteckte Datei wird nicht zurückgesetzt“.

    Erst die Kombination der beiden Parameter brachte den gewünschten Erfolg.

    attrib -s -h  /S ORDNERPFAD

    Nun wurde das Hidden-Attribut des Ordners entfernt. Der Parameter /S sorgt dafür, dass auch rekursiv alle Unterordner und Dateien bearbeitet werden.