Läuft nicht bei All-inkl Shared-Hosting

[zonky2]

All-inkl hat Shared-Hosting trotz SSH-Konsole crontab nicht bereit gestellt, sondern macht die Cronjobs über Webaufruf...

... mit dem Webaufruf sind die Konsolenbefehle cat, ls und rm gesperrt :(

... damit läuft das Script nicht bzw. die DB-Sicherung geht nicht

[mlwebworker]

Hallo Andreas, mich hat ja auch jemand angesprochen weil, offensichtlich das Script eventuell nicht mehr bei All-Inkl. läuft. Ich habe festgestellt, dass ich zu mindestens bei zwei Kunden eine ältere Version des Scriptes im Einsatz habe und werde morgen mal die aktuellste Version bei All-Inkl. testen.

[mlwebworker]

Ich bekomme mit der neuesten Version des Scriptes folgende Fehlermeldung bei All-Inkl.

Returncode: 0
Ausgabe des Scripts:

Array
(
    [0] => starte Backup xxxx
    [1] => /www/htdocs/wxxx/xxx/contao_4_9_x/c4-backup.sh: line 226: /bin/cat: Permission denied
    [2] => mysqldump: Got error: 1045: Access denied for user 'xxx'@'localhost' (using password: NO) when trying to connect
    [3] => aktuell vorhandene Backups:
    [4] => /www/htdocs/wxxx/xxx/contao_4_9_x/c4-backup.sh: line 295: /bin/ls: Permission denied
    [5] => /www/htdocs/wxxx/xxx/contao_4_9_x/c4-backup.sh: line 297: /bin/rm: Permission denied
    [6] => konnte (temporäre) Passwortdatei nicht löschen
    [7] => Backup xxx beendet (gespeichert in /www/htdocs/wxxx/xxx)
)

Ich kann da gern etwas testen oder Dir auch Zugriff auf meinen Account geben. Zurückgestellt auf meine ältere Version (Download wahrscheinlich vom 20.03.2020) läuft das angestoßene Backup fehlerfrei durch. Lediglich zwei Warnings gibt es.

Returncode: 0
Ausgabe des Scripts:

Array
(
    [0] => mysqldump: [Warning] Using a password on the command line interface can be insecure.
    [1] => mysqldump: [Warning] Using a password on the command line interface can be insecure.
)

[fiedsch]

Sorry, daß das untergegangen ist. Ich gehe davon aus, daß All-Inkl den Server bis zur Unbrauchbarkeit abgesichert hat, indem sie diverse Befehle nicht erlauben.

Im konkreten Fall ist es /bin/cat, das das Passwort und den Benutzernamen in eine Datei schreibt, um sie mysqldump zu übergeben. Ich habe das eingebaut, um die „Using a password on the command line interface can be insecure.“ Warnung loszuwerden (und es sauber zu machen, da ein Passwort nichts auf der Kommandozeile zu suchen hat, denn so taucht es in Logs oder der „Befehlshistorie des Users“ auf).

Der MySQL-Fehler ist dann ein Folgefehler und die Fehler bei ls und rm sind dann wieder das Thema „All-Inkl. erlaubt vieles nicht“. Die sollten aber das Backup an sich nicht betreffen, denn das ist zu diesem Zeitpunkt bereits erstellt.

Spontane Idee: ich könnte mal probierend, diese Funktionalität in einem PHP-Skript zu implementieren. Ist zwar irgendwie etwas umständlich, aber vielleicht blocken sie das dann nicht.

Als Lösung für Dich für den Moment sehe ich leider nur, die Version vor dieser Änderung zu verwenden.

[fiedsch]

Alternatividee: Anstelle

# write credentials file so we don't have to specify the password as a command line argument
cat << EOF > ${TARGET_DIR}/my.cnf
[mysqldump]
user='${DBUSER}'
password='${DBPASSWORD}'
EOF

dies

# write credentials file so we don't have to specify the password as a command line argument
echo '[mysqldump]' > ${TARGET_DIR}/my.cnf
echo "user='${DBUSER}'" >> ${TARGET_DIR}/my.cnf
echo "password='${DBPASSWORD}' >> ${TARGET_DIR}/my.cnf

verwenden ("um cat nicht zu benötigen").

[fiedsch]

Funktioniert die Änderung in #bee2cde für euch? Damit wäre cat nicht mehr nötig. ls und rm sind (wie oben geschrieben) für das Backup nicht nötig. Sie werden nur für die Ausgabe des aktuellen Stands (ls) bzw. das Aufräumen (rm) benötigt.

[mlwebworker]

Ich habe mir gerade mal die Zeit genommen, die aktuellste Version des Scripts bei All-Inkl zu testen. Da ist die oben genannte Änderung ja schon drin, wenn ich das richtig sehe. Auf den neuen Fehler kann ich mir gar keinen Reim machen. Das sieht doch nach Fehlern beim Zeilenumbruch aus, aber eben nur an manchen Stellen. Außer den letzten beiden Ausgaben betrifft es auf jeden Fall immer eine Leerzeile.

Returncode: 2
Ausgabe des Scripts:
Array
(
    [0] => /www/htdocs/xxx/webdesign-marenlange.de/contao_4_13_x/c4-backup.sh: line 2: $'\r': command not found
    [1] => starte Backup webdesign-marenlange
    [2] => /www/htdocs/xxx/webdesign-marenlange.de/contao_4_13_x/c4-backup.sh: line 4: $'\r': command not found
    [3] => /www/htdocs/xxx/webdesign-marenlange.de/contao_4_13_x/c4-backup.sh: line 6: $'\r': command not found
    [4] => /www/htdocsxxxwebdesign-marenlange.de/contao_4_13_x/c4-backup.sh: line 8: $'\r': command not found
    [5] => /www/htdocs/xxx/webdesign-marenlange.de/contao_4_13_x/c4-backup.sh: line 30: syntax error near unexpected token `$'{\r''
    [6] => /www/htdocs/xxx/webdesign-marenlange.de/contao_4_13_x/c4-backup.sh: line 30: `function assert_command() {
'
)

[fiedsch]

Hallo Maren, ich habe mittlerweile selbst einen allinkl Account und dort läuft die aktuelle Version des Skripts ohne Fehler (solange ich die ls und rm Aufrufe am Ende deaktiviert habe). Diese beiden Befehle erzeugen nur einen Überblick der Vorhandenen Backup-Dateien bzw. räumen auf. Beides nichts, was für das eigentliche Backup relevant wäre.

Kannst Du mir Deine Skriptdateine zur Verfügung stelle!damit ich mir das genauer anschauen kann? Ggf. Auch als Slack-PM.

[mlwebworker]

Ich habe es gerade noch einmal heruntergeladen. Zuvor hatte ich meine Dateien nur mit dem neuen Inhalt überschrieben. Jetzt funktioniert alles. Danke