MySQLDumper-Board Forum Index Follow me on Twitter

Portal  •   Forum  •  Downloads  •  Profile  •  Search   •  Register  •  Log in to check your private messages  •  Log in  •  


 all-inkl - Perl Cronjob Backup mit Email Benachrichtigung

Post new topicReply to topic
Author Message
Rizzo
knows MySQLDumper
knows MySQLDumper




Age: 45
Joined: 13 Mar 2008
Posts: 2
Location: Kaiserslautern


germany.gif

PostPosted: 2008-03-18, 05:38    all-inkl - Perl Cronjob Backup mit Email Benachrichtigung Reply with quoteBack to top

Hallo MSD-Freunde Smile

So genial all-inkl als Provider ist, so tricky kann das Einrichten eines Perl Cronjob bei diesem Verein sein. Grund dafür sind einige Eigenheiten, die nicht, bzw. sogar falsch bei all-inkl dokumentiert sind. Eine große Hilfe stellt diese sehr gute bebilderte Anleitung dar. Leider deckt das aber nicht alle Facetten ab, weil all-inkl ein sehr großer Provider ist und dementsprechend Vielfältig auch deren Server-Konfigurationen sind.

Bevor ich nun zeige wie ich den MSD Perl Cronjob an's Laufen brachte möchte ich noch darauf hinweisen, dass es auf anderen Servern mit anderer Konfiguration durchaus abweichende Einstellungen erfordern kann! Es gibt also nicht die Lösung für Alle, sondern testen ist angesagt.

Okay, die Einrichtung des MSD ist durch die gute Dokumentation sehr einfach und in 3 Minuten erledigt. Wer den MSD per Cronjob anweisen möchte Backups zu erstellen, soll erst mal die weiter oben erwähnte Anleitung ausprobieren. Läuft alles, ist die Arbeit schon getan. Funktioniert es nicht, wie das bei mir der Fall war, hilft vielleicht die Folgende Ergänzung zur Anleitung.

Hinweis:
Wer sich nicht näher mit dem Problem befassen möchte, sondern nur eine mögliche quick & dirty Lösung sucht, sollte direkt an's Ende dieses Beitrags springen, wo es eine Zusammenfassung / Quicklösung gibt.


Das cgi-bin Problem

Ich habe bei all-inkl ein Multi-Domain fahiges Paket, wie es sicherlich viele von Euch auch haben. Das bedeutet man hat 1 Webspace Paket, dass sich verschiedene Domains teilt. Damit sich da nichts in die Quere kommt, muß man im webroot (der obersten Ebene der Webpräsenz, also der Einstiegspunkt auf dem FTP) Unterverzeichnisse anlegen und dort die unterschiedlichen Domains drauf routen.
Das hat zur Folge, dass das von all-inkl vorinstallierte cgi-bin Verzeichnis im webroot nicht mehr über den Browser erreichbar ist, weil die neuen webroots jetzt in den zur jeweiligen Domain passenden Unterverzeichnissen liegen.

Folgt man nun der oben beschriebenen Anleitung soll man im Ordner, in dem man den MSD installiert hat, ein cgi-bin Verzeichnis anlegen, weil all-inkl Perl Scripts nur in einem cgi-bin Verzeichnis verarbeitet! Zur einfachereren Illustration habe ich das mit dem Multi-Domain, sowie dem MSD-Verzeichnis mal hier abgebildet:

document root (<-- FTP Einstiegspunkt)
|
|---- cgi-bin
|---- domain_A
|---- domain_B
|---- domain_C
|     |
|     |---- verzeichnis
|     |---- verzeichnis
|
|---- domain_D
      |
      |---- verzeichnis
            |
            |---- verzeichnis
            |     |
            |     |---- datei
            |     |---- datei
            |
            |---- MySQLDumper
                  |
                  |---- verzeichnis
                  |---- datei
                  |---- CGI-BIN (<-- cgi-bin im MSD Ordner)


Das sollte jedem soweit klar sein. Auch wenn ich hier von einem Multi-Domain Account ausgehe, sollten die Tipps auch auf "normale" Pakete anwendbar sein.

Okay, hat man das so weit erledigt und ist der Anleitung gefolgt, würde man erwarten das jetzt alles funktioniert. Macht es aber nicht, statt dessen bekommen wir eine "Permission denied..." Meldung! Hier wird man stutzig, überprüft mehrfach die Anleitung und schaut ob man nicht etwa vergessen hat, kontrolliert die Dateirechte, usw. Dann googelt und sucht man, bis man Hinweise findet, dass das cgi-bin Verzeichnis ausserhalb des MSD Ordners liegen sollte, also verlegt man das cgi-bin eine Ebene höher:

document root (<-- FTP Einstiegspunkt)
|
|---- cgi-bin
|---- domain_A
|---- domain_B
|---- domain_C
|     |
|     |---- verzeichnis
|     |---- verzeichnis
|
|---- domain_D
      |
      |---- verzeichnis
            |
            |---- verzeichnis
            |     |
            |     |---- datei
            |     |---- datei
            |
            |---- CGI-BIN (<-- cgi-bin eine Ebene höher)
            |---- MySQLDumper
                  |
                  |---- verzeichnis
                  |---- datei


An der Fehlermeldung ändert das aber nichts. Also noch eine Ebene rauf :

document root (<-- FTP Einstiegspunkt)
|
|---- cgi-bin
|---- domain_A
|---- domain_B
|---- domain_C
|     |
|     |---- verzeichnis
|     |---- verzeichnis
|
|---- domain_D
      |
      |---- CGI-BIN (<-- cgi-bin im webroot)
      |---- verzeichnis
            |
            |---- verzeichnis
            |     |
            |     |---- datei
            |     |---- datei
            |
            |---- MySQLDumper
                  |
                  |---- verzeichnis
                  |---- datei


Bingo! Hier funktioniert dann also das Perl Script. Ganz offensichtlich muß das cgi-bin Verzeichnis im webroot einer Domain liegen, da es sonst zu einer Zugriffsverletzung kommt.


Der Haken

Wenn wir also das cgi-bin Verzeichnis in das webroot verlegen funktioniert zwar das MSD Perl Script, aber leider ist dieses Verzeichnis öffentlich zugänglich und der Verzeichnisschutz den MSD anlegt greift hier nicht!
Es könnte also jeder, der durch raten oder sonstwie auf die Idee gekommen ist das hier ein MSD läuft, das Script manuell aufrufen und so ein (oder auch 25.000) Backup anlegen. Dadurch würden wir mit Benachrichtigungen per Mail gespammt werden und zusätzlich belegt das natürlich Webspace und belastet den Server.

Jetzt könnte man sagen das wir uns eben einfach einen eigenen Verzeichnisschutz anlegen, um so unser Script zu schützen. Leider funktioniert das nicht, denn das cgi-bin stellt etwas besonderes dar und wenn wir darin eine .htaccess/.htpasswd ablegen, hat das nicht den gewünschten Effekt. Um ein Verzeichnisschutz auf ein cgi-bin zu legen müssten wir entweder das webroot per .htaccess schützen (was Sitebesucher aussperrt) oder man müsste spezielle Einstellungen in der httpd.conf vornehmen. Letzteres ist nur auf eigenen Servern möglich und bei Miet-Webspace ausgeschlossen.
Dilemma, Dilemma... Zum Glück gibt es eine ebenso einfache, wie elegante Lösung für das Problem!


Per .htaccess das cgi-bin verlegen

Die beste und eleganteste Lösung ist es, dass wir dem Server mitteilen auch Perl Scripts ausserhalb des webroot ausführen zu lassen. Dazu stellen wir also doch wieder die ursprüngliche Ordner-Hierarchie her, wie sie in der eingangs erwähnten Anleitung beschrieben wurde:

document root (<-- FTP Einstiegspunkt)
|
|---- cgi-bin
|---- domain_A
|---- domain_B
|---- domain_C
|     |
|     |---- verzeichnis
|     |---- verzeichnis
|
|---- domain_D
      |
      |---- verzeichnis
            |
            |---- verzeichnis
            |     |
            |     |---- datei
            |     |---- datei
            |
            |---- MySQLDumper
                  |
                  |---- verzeichnis
                  |---- datei
                  |---- CGI-BIN (<-- cgi-bin im MSD Ordner)


Zusätzlich erzeugen wir eine .htaccess Datei mit dem Inhalt :

Options FollowSymLinks ExecCGI


und legen diese Datei in das webroot:

document root (<-- FTP Einstiegspunkt)
|
|---- cgi-bin
|---- domain_A
|---- domain_B
|---- domain_C
|     |
|     |---- verzeichnis
|     |---- verzeichnis
|
|---- domain_D
      |
      |---- .htaccess (<-- .htaccess im webroot)
      |---- verzeichnis
            |
            |---- verzeichnis
            |     |
            |     |---- datei
            |     |---- datei
            |
            |---- MySQLDumper
                  |
                  |---- verzeichnis
                  |---- datei
                  |---- CGI-BIN


Das war's, jetzt sollten die MSD Perl Scripts auch im cgi-bin direkt im MSD Ordner ausgeführt werden. Zusätzlich greift hier auch wieder der Verzeichnisschutz, so dass niemand ohne die Zugangsdaten das Script ausführen kann! Smile


Es werden keine Mails verschickt

Unser Backup per Cronjob läuft nun, aber leider kommen keine Emails mit dem Backup an. Das Perl Backup Script manuell aufgerufen zeigt immer einen "Mail ERROR" an. Hier sollte man das nicht verwechseln mit dem "normalen" Backup, dass per PHP durchgeführt wird. PHP benutzt die interne Funktion mail(), die immer verfügbar ist, während Perl extern konfiguriert werden muß um Emails zu verschicken. Und genau hier liegt das Problem - es gibt keinen einheitlichen Weg, wie Perl auf die benötigte Funktion sendmail zugreift. Das kann von Server zu Server unterschiedlich sein und hier heisst es testen und probieren, bis man eine funktionierende Lösung gefunden hat.
all-inkl ist hier leider auch keine große Hilfe, denn mir wird im KAS in den FAQ zu den Serverpfade etwas falsches angezeigt. Wenn das bei mir falsch in den FAQ steht, macht es das bei vielen anderen mit Sicherheit auch.
Bei mir im KAS steht, dass der Pfad zu sendmail folgender ist:

/usr/sbin/sendmail


Wenn ich dem MSD dies so in der Email Konfiguration mitteile, führt das zu besagtem Fehler und Mails werden nicht verschickt. Statt dessen ist bei mir korrekt:

/usr/sbin/sendmail -t (<-- den Parameter -t beachten!)


Verwende ich im MSD diesen Pfad, funktioniert alles perfekt und Mails kommen mit angehängter Backup Datei an.

Aber Achtung!
Nur weil es bei mir mit dem Parameter funktioniert, muss es das nicht auch automatisch bei Euch. Wenn es nicht funktioniert, testet mal der Reihe nach diese Angaben für den sendmail Pfad:

/usr/sbin/sendmail
/usr/sbin/sendmail -t
/usr/bin/sendmail
/usr/bin/sendmail -t
/usr/lib/sendmail
/usr/lib/sendmail -t


Funktioniert keine dieser Pfad-Angaben, bleibt Euch nichts anderes über als den all-inkl Support zu kontaktieren um nach dem korrekten Pfad auf Eurem Server zu fragen.


Zusammenfassung / Quicklösung

Um CGI im MSD Unterverzeichnis ausführen zu können muß im webroot eine .htaccess mit diesem Inhalt abgelegt werden:
Options FollowSymLinks ExecCGI


Wenn das Perl Backup keine Emails verschickt, sondern nur Fehlermeldungen ausgibt, einmal diese Alternativen sendmail Pfade ausprobieren:
/usr/sbin/sendmail
/usr/sbin/sendmail -t
/usr/bin/sendmail
/usr/bin/sendmail -t
/usr/lib/sendmail
/usr/lib/sendmail -t


Ich hoffe diese Erklärung war dem ein oder anderen all-inkl Kunde eine Hilfe.

Viele Grüße und Happy Dumping,
Andreas


p.s. Vielen Dank an Daniel, Steffen und alle anderen Macher rund um den MySQLDumper, für dieses großartige, unverzichtbare Tool!

_________________
Viele Grüße, Andreas

Meine kleine PHP Seite

OfflineView user's profileSend private messageVisit poster's website    
Anzeigen











Posted:    Anzeigen Back to top


    
Fauchi95
Moderator
Moderator





Joined: 30 Aug 2007
Posts: 241


germany.gif

PostPosted: 2008-03-18, 08:17    (No subject) Reply with quoteBack to top

Hallo Rizzo,

vielen Danke im Namen aller all-inkl User. clap

Gruss,
Daniel

_________________
Image

| Mein Blog | Datenbankservice |

OfflineView user's profileSend private messageVisit poster's websiteICQ Number    
Display posts from previous:      
Post new topicReply to topic


 Jump to:   


Show permissions
Similar topics
Topic Author Forum Replies Posted
No new posts Ext. Cronjob zum sichern einer Datenb... mdietrich Fehler / Probleme 0 2017-10-10, 10:19 View latest post
No new posts Backup nicht mehr möglich Jens_K Fehler / Probleme 2 2017-09-01, 19:11 View latest post
No new posts Backup: Eine Sicherung der Systemdate... ICM|Team Fehler / Probleme 0 2017-07-19, 11:36 View latest post
No new posts Mal wieder das leidige Problem Perl Lapje Gelöst/Erledigt 5 2017-07-02, 14:05 View latest post
No new posts Blank page during backup art99 Errors and questions 4 2017-05-23, 14:55 View latest post

 
CrackerTracker © 2004 - 2017 CBACK.de

Powered by Orion based on phpBB © 2001, 2002 phpBB Group
CBACK Orion Style based on FI Theme
All times are GMT + 2 Hours

phpBB SEO