Um das mySQL-Passwort für den "root"-User zurück- oder neu zu setzen, benötigt es einen kleinen Trick auf der Shell. Loggt euch dazu mit eurem Linux-User per SSH (z.B. per puTTY) ein und gebt euch per "sudo su" die Root-Rechte. Nachdem ihr euch die Root-Rechte übertragen habt, könnt ihr den mySQL-Server stoppen und mit einigen Zusatzparametern aufrufen, um euch mit dem Root-User des mySQL-Servers ohne Passworteingabe anzumelden.

Nun setzt ihr das Passwort für den Root-User über eine mySQL-Query neu und meldet euch wieder aus mySQL ab. Danach solltet ihr euch auch vom Root-User per SSH abmelden, damit ihr keine fehlerhaften Eingaben bereuen werdet.

mySQL Root-Benutzer Passwort ändern:

#Stoppe den MySQL Server.
sudo /etc/init.d/mysql stop
 
#Start der mysqld-Konfiguration.
sudo mysqld --skip-grant-tables &
 
#Login in MySQL als root-Benutzer ohne Passworteingabe.
mysql -u root mysql
 
#Ersetzte den Marker "DEINNEUESPASSWORT" mit deinem neuen Passwort!
UPDATE user SET Password=PASSWORD('DEINNEUESPASSWORT') WHERE User='root'; FLUSH PRIVILEGES; exit;

TYPO3 Framework und CMS

Bei dem Einsatz der TYPO3 Extension "tt_news" wird oft nach dem Setzen des Seitentitels gefragt. Das setzen des Seitentitels mit der aktuell aufgerufenen News, lässt sich über einen TypoScript-Code lösen. Der TypoScript-Code greift auf die tt_news-Tabelle zurück und mittels "stripHTML", werden alle HTML-Tags entfernt. Vergleichbar ist die Funktion mit der PHP-Funktion "strip_tags()".

temp.newsTitel=COA
temp.newsTitel {
  wrap= |
  5=RECORDS
  5{
    # GET-Parameter der News holen
    source = {GPvar:tx_ttnews|tt_news}
    source.insertData = 1
    tables = tt_news
    conf.tt_news >
    conf.tt_news = TEXT
    conf.tt_news.field=title
    # Bereinigen des Titels mit stripHtml (alle HTML-Tags entfernen)
    conf.tt_news.stdWrap.stripHtml = 1
  }
}

Wer den Seitentitel selbst generiert, muss dann das TEMP-Objekt auf den eigens erstellten Seitentitel vererben. Zum manuellen Setzen des title-Tags, nehmen wir das PAGE-Objekt und setzten dort den Header via "headerData" ein. Der folgende TypoScript-Code ist sofern modular aufbereitet, sodass noch weitere TLO's (Top-Level-Objekte) via TypoScript gesetzt werden können.

config.noPageTitle = 2
page.headerData.100 {
wrap = |
 10 = COA
 10 {
  10 < temp.newsTitel
 }
20 = TEXT
20.value = &laquo; Seitentitel
}

TYPO3 Framework und CMS

Auf der Suche nach einer Lösung von Duplicate Content in TYPO3, stieß ich auf die Extension "ods_seo" (SEO Buddy). Die Extension hängt sich in den TypoScript-Code (page.headerData) und überprüft in der Datenbank, welches die eindeutige URL zu der aufgerufenen Seite ist und setzt diese als META-Tag (canonical) im Head-Bereich der Seite. Denn um die Duplicate Content Problematik zum Beispiel in TYPO3 zu lösen, gibt es seit längerem das “Canonical Meta-Tag”, dass die größten Suchmaschinen im Internet, Google, Yahoo! und Microsoft unterstützen.Im Head-Bereich der Internetseite wird nun unter den bekannten MetaTags wie "robots", "language", und weitere MetaTags auch der"rel=canoncial" Tag eingebunden.

Der Canonical MetaTag sieht wie folgt aus:

<link  rel="canonical" href="http://www.domain.de/pagename/" />

Im Framework TYPO3 hat man automatisch Duplicate Content, da eine Inhaltsseite  zum Beispiel über "http://www.domain.de/index.php?id=1" oder über "http://www.domain.de/?id=64", "http://www.domain.de/pagename" oder http://www.domain.de/pagename/ (via RealUrl umgeschrieben) erreichbar ist. Die Extension "ods_seo" versucht dies zu verhindern, indem in der Datenbank geschaut wird, welches die wirklich eindeutige aufrufbare Url für die angeforderte Seite ist.

Die Konfiguration der TYPO3-Extension ist denkbar einfach. Ebenfalls steht im TER auf typo3.org eine recht kurze aber ausführliche Anleitung zur Grundkonfiguration der Extension zur Vermeidung von Duplicate-Content zur Verfügung.
Wichtig zu wissen ist, dass ihr bei dem Einsatz dieser Extension einen modernen Server zur Verfügung hat, der auch größere Datenbankabfragen problemlos in kurzer Zeit verarbeiten kann. Die TYPO3 Extension schaut bei jedem Seitenaufruf in der Datenbank nach der eindeutigen (Unique-URL) Adresse. Sofern die Extension RealUrl installiert wurde, wird auf die Datenbanktabelle von RealUrl zurückgegriffen. Ist der Internetauftritt in diversen Sprachen und mit mehr als 500 Inhaltsseiten vorhanden, können die Datenbankabfragen sehr rechen- und zeitintensiv werden.

Bei dem Einsatz dieser Extension sollte ebenfalls beachtet werden, dass die eigens geschriebenen Extensions für das TYPO3-Frontend über das TYPO3-Framework generiert werden und nicht händisch durch eigene Funktionen erzeugt werden. Sind die Links durch eigene PHP-Funktionen generiert, so kann die Canonical-Extension nicht greifen, da diese Urls nicht in der RealUrl-Datenbanktabelle stehen oder von TYPO3 gecached wurden. Daher nutzt bitte in euren Frontend-Extensions immer die TYPO3-Kernfunktionen.

TYPO3-Kernfunktionen (tslib_pibase) zur Generierung von Links in Frontend-Extensions:

• pi_getPageLink ($id, $target='', $urlParameters=array())
• pi_linkToPage ($str, $id, $target='', $urlParameters=array())
• pi_linkTP ($str, $urlParameters=array(), $cache=0, $altPageId=0)
• pi_linkTP_keepPIvars ($str, $overrulePIvars=array(), $cache=0, $clearAnyway=0, $altPageId=0)
• pi_linkTP_keepPIvars_url ($overrulePIvars=array(), $cache=0, $clearAnyway=0, $altPageId=0)

Möglicherweise werdet ihr bei der Generierung der Canonical-Url einen GET-Parameter "cHash" erhalten. Dies scheint in der Extension "ods_seo" Probleme zu bereiten. Abhilfe schafft generell nur das Entfernen der Codezeilen in der "_pi1" der Extension, die den "cHash" berücksichtigen.

$pidList = implode(',', $given_PIDs); // Konvertiert Array zu einem Komma getrennten String. (z.B. 1,12,55)
$GLOBALS['TSFE']->clearPageCacheContent_pidList($pidList);

Der ehemalige Weg über die Funktion clear_cacheCmd() führt zu einem “Fatal error: Call to a member function writelog() on a non-object”.
Die Ursache ist die, dass die Funktion davon ausgeht das ein Backend-User eingeloggt ist, was zu 99,9% der Fälle nicht zutrifft.

Seit dem Erscheinen der TYPO3 Version 4.5.x, wurde auch im TYPO3-Bugtracker ein sehr hilfreicher Eintrag dazu veröffentlicht.
0016844: error when using t3lib_TCEmain->clear_cacheCmd in frontend (only for TYPO3 4.5 and higher)

Hat einer meiner Leser vielleicht noch einen Tipp, wie sich der Frontend-Cache mit einem Kommentar für das Protokoll im TYPO3-Backend leeren lässt? Seit der TYPO3-Version 4.5.x wird das Leeren des TYPO3-FE-Caches im Protokoll mit einem Kommentar versehen. Diese Methode wäre auch für den Frontend-Cache eine schöne Angelegenheit.

Zum Deaktivieren des Autostarts des BOINC-Clients, müsst ihr in der Konsole bzw. im Terminal die "rc.d" aktualisieren.
Beispiel für die Deaktivierung unter Ubuntu:

sudo update-rc.d -f boinc remove

Sollte dieser Befehl nicht greifen, so könnt ihr unter "/etc/rc(1-X).d/" die entsprechenden Einträge löschen.
Ihr werdet sicherlich mehrere Startup-Dateien haben. z.B. rc1.d, rc2.d, rc3.d, ...

TYPO3 Framework und CMS

Seit dem neuen TYPO3-Release, Version 4.6. --rebase, wird im IntsallTool beziehungsweise bei der Installation des TYPO3-Systems eine Fehlermeldung (Exception) "openssl missing" hervorgerufen. Aufgrund der neuen Sicherheitsfeatures in TYPO3 4.6. (saltedpasswords) und weiteren sicherheitsrelevanten Punkten, wird seit TYPO3 Version 4.6.x das PHP-Modul "openssl" vorausgesetzt. Zahlreiche ältere PHP 5.3.x Versionen, zum Beispiel eine ältere XAMPP-Installation unter Windows, haben das PHP-Modul nicht aktiv.

TYPO3 Exception / Fehlermeldung:

Uncaught TYPO3 Exception
#1294587482: TYPO3 Installation Error: The following PHP module(s) is/are missing: openssl
You need to install and enable these modules first to be able to install TYPO3. (More information)
RuntimeException thrown in file
C:\xampp\htdocs\typo3_4.6\typo3\sysext\install\mod\class.tx_install.php in line 202.

Ohne das aktivierte PHP-Modul ist die Installation der neuen TYPO3 Version 4.6 nicht möglich!

Wie lösen wir das Problem mit dem fehlenden openssl-Modul?
- Du musst in der php.ini-Datei das openssl-Modul aktivieren
- Die php.ini-Datei befindet sich im XAMPP-Installationsverzeichnis "xampp\php\php.ini" oder "/etc/php5/php.ini".
- In der php.ini-Datei muss die Zeile "extension=php_openssl.dll" aktiviert werden. Das Semikolon ";" muss am Anfang der Zeile entfernt werden.
- Ist diese Zeile nicht vorhanden, suche in der php.ini nach "extension=" und füge ans Ende des Blocks die oben genannte Konfiguration ein
- Ist die php.ini-Datei aktualisiert, muss noch der Apache-Dienst aktualisiert werden. Bei Xampp kann der Dienst gestoppt und gestartet werden. Unter Linux reicht oft schon ein "sudo /etc/init.d/apache2 reload" aus. Falls nicht, anstelle des "reload"-Parameters "stop" und "start" verwenden.

Ob die Aktivierung des PHP-Moduls "openssl" funktioniert habt, könnt ihr mittels eines phpinfo()-Aufrufs testen oder die TYPO3 4.6 Installation erneut laden.

TYPO3 Framework und CMS

Bei der Verwendung der von TYPO3 angebotenen Bildverkleinerung und des GIFBUILDER(s) für grafische Navigationen, kommt es leider auf vor, dass die Bildqualität sehr mit Artefakten versehen ist. Oder sogar die Konvertierung von GIF zu PNG fehlschlägt und ein schwarzer Hintergrund im Bild entsteht. Der Grund der mangelnden Bildqualität liegt an der Grundkonfiguration von TYPO3 im InstallTool bzw. der localconf.php im Ordner "typo3conf".

Die Lösung des Problems der Bildqualität von PNG/Gif mit dem GIFBUILDER oder dem Richt-Text-Editor mit Zauberbildern sieht wie folgt aus.
Überprüfung der vorliegenden Versionen von ImageMagick, PHP-Gdlib und der sich im Einsatz befindlichen TYPO3-Version bzw. des TYPO3-Cores. Zur Lösung der oben genannten Probleme, sollte auf dem Server ImageMagick in der Version 6 (Abkürzung: im6), PHP-Gdlib 2.x und TYPO3 mindestens in der Version 4.3.x vorliegen. Sofern die Versionen von ImageMagick, PHP-Gdlib und TYPO3 verfügbar sind, kann die Konfiguration von TYPO3 angepasst werden. Im Verzeichnis "typo3conf" befindet sich die Datei "localconf.php" und muss mit den Werten "jpg_quality", "gdlib_png", "png_truecolor" und "gdlib_2" gesetzt werden:

$TYPO3_CONF_VARS['GFX']['jpg_quality'] = '85';
$TYPO3_CONF_VARS['GFX']['gdlib_png'] = '1';
$TYPO3_CONF_VARS['GFX']['png_truecolor'] = '1';
$TYPO3_CONF_VARS['GFX']['gdlib_2'] = '1';

Diese Werte lassen sich auch über das TYPO3-Backend und das InstallTool unter dem Punkt "All Configuration" setzen.

TYPO3 Framework und CMS

TYPO3 Backend: Inhaltselement verbergen

Um die Eigenschaft "Inhaltselement verbergen" bei der Erstellung eines Content-Elements als Standardwert zu setzen, muss in der "Page TSConfig" der TCAdefaults-Wert für die Tabelle "tt_content" überschrieben werden.

Die TCAdefaults-Konfiguration lautet:

# Neue Inhalte (Content-Elemente) automatisch verbergen:
TCAdefaults.tt_content.hidden = 1

TYPO3-Backend: Inhaltselement per TCADefaults (tt_content.hidden) verbergen

Wurde dieser Wert gesetzt, wird bei der Neuanlage eines Inhaltselement, das Element automatisch verborgen und muss im Nachhinein aktiviert werden.

TYPO3 Framework und CMS

In der neuen TYPO3 Version 4.6 --rebase wurden zahlreiche depracted Funktionen aus dem TYPO3-Core entfernt. Viele sich im Einsatz befindliche TYPO3-Extensions arbeiten im TYPO3 Backend für die Module (mod1, mod2, ...) mit der Kernklasse t3lib_div und dessen ehemaligen Funktion fixed_lgd_pre(). Wird ein TYPO3 Projekt zum Beispiel von der Version 4.5 auf die Version 4.6.x aktualisiert, tritt dieser Fehler auf. Die Fehlerkorrektur ist recht simpel, leider muss dafür der Extensionkern (Ext-Core) angepasst werden, damit die Extension im TYPO3-Backend wieder funktionstüchtig ist. Bis zur nächsten Aktualisierung durch den eigentlichen Extension-Entwickler ist also diese Art Eingriff von Nöten.

Die neue PHP-Funktion in der Kernklasse t3lib_div lautet fixed_lgd_cs(), sie ersetzt die ehemalige Funktion fixed_lgd_pre().
Die Funktion fixed_lgd_pre() wurde zum Beispiel für die Extension "kickstarter" und "sk_pagecomments" eingesetzt.

Einen Patch für die Extension "kickstarter" wurde bereits am 31.05.2011 veröffentlicht.
In der Extension "sk_pagecomments" muss im Verzeichnis "mod1" die index.php-Datei in der Zeile 139 angepasst werden.

Ehemalige Codezeile (typo3conf/ext/sk_pagecomments/mod1/index.php)

$headerSection = $this->doc->getHeader("pages",$this->pageinfo,$this->pageinfo["_thePath"])."
".$LANG->sL("LLL:EXT:lang/locallang_core.xml:labels.path").": ".t3lib_div::fixed_lgd_pre($this->pageinfo["_thePath"],50);

Neue Codezeile (typo3conf/ext/sk_pagecomments/mod1/index.php)

$headerSection = $this->doc->getHeader("pages",$this->pageinfo,$this->pageinfo["_thePath"])."
".$LANG->sL("LLL:EXT:lang/locallang_core.xml:labels.path").": ".t3lib_div::fixed_lgd_cs($this->pageinfo["_thePath"], -50);

Note:

t3lib_div::fixed_lgd_pre() - since TYPO3 4.1, will be removed in TYPO3 4.6 - Use t3lib_div::fixed_lgd_cs() instead (with negative input value for $chars) - require#5

Nach dem Speichern der Konfiguration solltet ihr sicherheitshalber die rkhunter-Eigenschaften aktualisieren und den Scan erneut durchführen.
Im folgenden Beispiel wird ein Property-Update (--propupd) ohne Ausgabe (--sk) ausgeführt.

 
sudo rkhunter --update
sudo rkhunter --propupd --sk

Bei der Konfiguration von rkhunter solltet ihr dennoch vorsichtig vorgehen, denn gerade beim Erlauben von versteckten Ordnern wird grundsätzlich eine Sicherheitslücke erzeugt.
Erkundigt euch lieber vorher im Netz, was diese versteckten Ordner und Dateien ausführen, bevor ihr dem Rootkit Hunter mitteilt, dass diese Ordner und Dateien beim Scan ignoriert bzw. erlaubt werden dürfen.

[rkhunter] Warnings found for SERVER
Running Rootkit Hunter version 1.3.6
[12:53:44] Checking for hidden files and directories [ Warning ]
[12:53:44] Warning: Hidden directory found: /dev/.static
[12:53:44] Warning: Hidden directory found: /dev/.udev
[12:53:44] Warning: Hidden directory found: /dev/.initramfs