Hallo,
Hat jemand es geschafft Cronjob bei All-Inkl einzurichten? Dort gibt es kein Crontab, sondern es läuft über Http Befehl. Dafür wird eine .php dabei erstellt, was wiederum eine .sh Datei (beinhaltet CLI Befehl) anfeuert.
Es funktioniert mit Magento und Wordpress gut aber für Shopware schaffe ich irgendwie nicht.
Hat jemand Ahnung davon?
Grüße
Du legst Dir zwei php-Dateien in public an. Die eine ruft per CLI die messageque auf, die andere den scheduledtasks. Den Tip gab glaub ich shyim hier.
Meine
run-scheduledtasks.php:
<?php
exec("/usr/bin/php81 /www/htdocs/xxxx/xxx/SW6EA/bin/console scheduled-task:run --time-limit=60 --memory-limit=256M 2>&1", $out, $result);
echo "Returncode: " .$result ."<br>";
echo "Ausgabe des Scripts: " ."<br>";
echo "<pre>"; print_r($out);
?>
und
run-messageque.php
<?php
exec("/usr/bin/php81 /www/htdocs/xxx/xxx/SW6EA/bin/console messenger:consume default --time-limit=60 --memory-limit=256M 2>&1", $out, $result);
echo "Returncode: " .$result ."<br>";
echo "Ausgabe des Scripts: " ."<br>";
echo "<pre>"; print_r($out);
?>
Die Dateien rufst Du dann wie eine Seite über https auf.
Wenn Du nur „php“ und nicht „php81“ etc. aufrufen willst, muss php natürlich auf die passende Version linken.
Es hat funktoniert. Ich habe es erst mit cache:clear probiert und es geht.
Vielen Dank
Hallo zusammen,
ich habe gestern diese Kommunikation gefunden. Die passt ganz gut zu meinem aktuellen Problem.
Ich habe Shop auf Version 6.6.1.2 aktualisiert. Da habe ich gleich zwei Cronjobs eingerichtet. Ich musste erstmal ein paar mal mit All-Inkl kommunizieren und am Schluss sind zwei auf Shopware 6.6 angepasste PHP-Dateien mit Cronjobs entstanden. Alle beide laufen einwandfrei und bringen gute Ergebnisse. Hier sind die:
===================================================================
1. messenger-consume.php mit folgendem Inhalt
<?php
exec("/usr/bin/php82 ../bin/console messenger:consume async low_priority --time-limit=55 --memory-limit=512M 2>&1", $out, $result);
echo "Returncode: " .$result ."<br>";
echo "Ausgabe des Scripts: " ."<br>";
echo "<pre>"; print_r($out);
?>
===================================================================
2. run-scheduledtasks.php mit folgendem Inhalt
<?php
exec("/usr/bin/php82 ../bin/console scheduled-task:run --time-limit=55 --memory-limit=512M 2>&1", $out, $result);
echo "Returncode: " .$result ."<br>";
echo "Ausgabe des Scripts: " ."<br>";
echo "<pre>"; print_r($out);
?>
===================================================================
Die „Geplante Aufgaben“ sowie „Warteschlange“ unter „Tools“ Plugin werden jetzt abgearbeitet. Nur noch diese 3 Punkte laufen noch nicht wie gewünscht:
- in der Warteschlange steht „messenger.transport.scheduler_shopware = unknown“
- unter dem Reiter „System-Status > System-Status“ steigt Zeit bei Open Queues
- „messenger.transport.failed“ in der Warteschlange wird angeblich nicht abgearbeitet. Wenn man das zurücksetzt, dann geht Zeit bei Open Queues auf 0 und alles wieder im grünen Berech. Dann später fängt mit steigender Zeit bei Open Queues wieder von vorne an.
Vielleicht soll da noch ein Cronjob eingerichtet werden???
Ich freue mich auf die Hilfe!
Mit besten Grüßen
Lago
Hallo zusammen,
ein Nachtrag. Ich konnte 2 oben genannte Probleme lösen:
unter dem Reiter „System-Status > System-Status“ steigt Zeit bei Open Queues
„messenger.transport.failed“ in der Warteschlange wird angeblich nicht abgearbeitet.
Da musste ich ein wenig Datei „messenger-consume“ anpassen. Hier nochmal Inhalt:
<?php
exec("/usr/bin/php82 ../bin/console messenger:consume failed async low_priority --time-limit=55 --memory-limit=512M 2>&1", $out, $result);
echo "Returncode: " .$result ."<br>";
echo "Ausgabe des Scripts: " ."<br>";
echo "<pre>"; print_r($out);
?>
Jetzt läuft alles sauber. Nur diese Meldung leider weiterhin drin:
Weiß vielleicht jemand an wa es liegt???
Mit besten Grüßen
Lago
Das ist ein ganz schöner Angriffvektor - wenn jemand die Url zu diesem Script kennt kann er beliebig viele consumer auf eurem Server starten und legt eventuell das System lahm.
Ich würde raten da noch irgendeine Art Schlüssel abzufragen.
Grundsätzlich ein berechtigter Heinweis.
Also per get noch einen Parameter anhängen. Nur, wenn Angreifer meine Datei kennt, dürfte er auch den key / Parameter kennen.
Hier hing es um einen http cron bei all-inkl.
Also die IP ermitteln, mit der all-inkl den http-request macht, und im Script auf diese prüfen.