Habe mich beim Apache/Nginx in die "configure"-Funktion eingeklinkt: ohne Domain macht ein Vertrag nur wenig Sinn. Dabei werden dann Dateien und Verzeichnisse erstellt.
Ein sauberer Hook wäre aber doch schön.
Beiträge von antondollmaier
-
-
Hier besteht meines Erachstens nach Handlungsbedarf!
Stimme zu.
Es macht aber keinen Sinn, jetzt stupide Plesk oder Confixx oder cPanel zu kopieren, nur weil "die Kunden das schon so kennen".
-
Dennoch meine Frage:
Gibt es in LiveConfig einen Schalter, den man nutzen kann, um auf einem neu aufgesetzten System sämtliche Configs mit einem Mal neu schreiben zu lassen?Aktuell nicht. Einzelne Einträge/Konfigurationen können neu geschrieben werden, allerdings bei weitem nicht alles (eben Passwd).
-
Der Server nimmt die Verbindung nicht an bzw. stürzt ab mit einem segfault:
Das nächste mal bitte "CODE"-Umgebung verwenden und den Backtrace nochmals per Mail an support@liveconfig.com mailen.
Die neueste Version kommt ja vermutlich sowieso zum Einsatz, oder?
-
Wenn ich nun den Kunden löschen will konnte der übliche Spruch: "Um diesen Kunden zu löschen müssen Sie erst alle ihm zugeordneten Verträge löschen."
Bitte Logs prüfen.Der Fehler kann auftreten, wenn es Probleme bei der Verbindung zur Datenbank, dem Mailserver oder dem FTP-Server gibt. Dann bleiben nämlich Objekte zurück, so dass der Vertrag niemals gelöscht wird (sondern nur als gelöscht markiert war).
-
Then I enabled the email in the hosting plan. This change did not propagate to the client account until I deleted the domain and recreated it. Now I don't know what is the expected behavior in this case. Should the change in the hosting plan propagate to the client domain? If so, then this could be considered another bug.
IMHO, no: E-Mail can be disabled by the enduser on a per-domain basis, so in theory it would be possible to not have this activated.Instead, the user can then manually (or you) activate email for a certain domain under "domains".
-
Okay, aber wieso ist dann auf dem Webspace kein PHP aktiviert und wie aktiviere ich es
FastCGI verwenden.Zitat/EDIT: apt-get install libapache2-mod-php7.0
und es geht
Ja, und damit gleich nen Haufen Sicherheitslücken - insbesondere kann Kunde A nun alle Daten von Kunde B lesen, die auch der Webserver lesen darf.Und nein, open_basedir nützt hier nichts.
-
aber im AWStats tauchen die vollständigen IP-Adressen auf. Da scheinen sich die Einstellungen nicht auszuwirken.
Die Einstellung wirkt sich auf das Log-File ab Änderung aus. Vorher geschriebene Einträge sind natürlich nicht anonymisiert, weshalb dann auch AWStats nichts anonymisiert verarbeiten kann.
-
gut:
CodeFeb 21 17:26:05 web postfix/smtp[15172]: 8812365F98: to=<info@webaccount.de>, relay=none, delay=0.1, delays=0.05/0/0.05/0, dsn=5.4.6, status=bounced (mail for webaccount.de loops back to myself)Damit kann man arbeiten.
Postfix kennt "webaccount.de" nicht, das passt also. Es wurde also in der Tat versucht, die Domain nach extern zuzustellen.
Allerdings hat Postfix im DNS einen MX/A-Record gefunden, der wieder auf sich selbst verwiesen hat: bitte daher auf dem Server(!) die DNS-Resolv-Konfiguration prüfen und schauen, was für die Domain ("webaccount.de") tatsächlich als Antwort zurück kommt.
-
Ist das Verhalten generell ungewöhnlich?
ja.Ich zitiere nochmal:
ZitatDas Problem besteht darin wenn man per php (Konktaktformular uä), eine Mail vom Webserver an seine eigene Domain schickt verlässt die Mail nicht den Webserver sondern wird auf dem Webserver angelegt wo sie natürlich keiner abrufen kann.
Ohne Logs kann man natürlich gar nichts prüfen, das ist hier also alles ganz allgemein gehalten.
- server A hat Postfix. Keine virtual_domains. Hostname: servera.example.com
- Server B dito (mit serverb.example.com), verwaltet aber auch virtuell die Mails der example.com.
- PHP verschickt nun auf Server Amit mail() bzw. /usr/sbin/sendmail eine Mail. Empfänger: info@example.com.
- wenn ServerA die "example.com" in mydestination hat, bleibt die Mail also lokal.
- existiert "info" irgendwo als Postfach, so wird diese Mail lokal zugestellt.
- existiert "info" nicht, so wird die Mail mit "unknown user" gebounced.Somit: Logs und konkrete Daten. Dann kann man genauer helfen.
Wie gesagt: Postfix behält Mails nur dann für "sich", wenn es dafür konfiguriert wurde.
-
Postfix an sich musste ich aber installieren die Webaccounts dürfen ja Mails verschicken.
Das Verhalten kann nur auftreten, wenn die Ziel-Domain auf Server B auch auf Server A im Postfix hinterlegt ist.Das kann viele Gründe haben - virtual_domains ist einer davon, myhostname/mydestination ein anderer.
Welcher davon, können wir so weder erraten noch tatsächlich bestimmen.
-
Einfach das PECL-Binary aufrufen, das zur PHP-Version gehört.
Ansonsten: PHP7 ist seit Stretch bzw. Ubuntu 16.04 Standard. Wäre da nicht ein allgemeines Upgrade angebracht?
-
Gab aber schonmal einen Fehler, da in irgendwelchen Sub-Abhängikeiten /usr/bin/php hart reingecodet wurde.
Dann wird "Kunde kann PHP-CLI-Version selbst wechseln" aber auch schwer, oder?
-
Klar, ich kann jedesmal /opt/php71/... schreiben, aber das ist auf Dauer lästig.
Codeecho "alias php=/opt/php71/bin/php" >> ~/.bashrc -
Um die Ausgangsfrage zu beantworten:
Ich muss mich auch mal hier reinhängen. Warum wird in dem Cronscript nicht zwischen PHP 7.0 und 7.1 etc. unterschieden? Es wird grundsätzlich die 7.0 php.ini geladen.
Das führt zu Fehlern, sobald man 7.1 als CLI eingebunden hat -> gerade mit ioncube.
Nein, tut es nicht.cron.php.sh macht nichts anderes, als die Session-Lifetime aus den vorhandenen php.inis auszulesen. Anhand dessen wird dann pro Kunde ein Find durchgeführt, um die Session-Dateien aufzuräumen.
Ich sehe hier keinerlei Referenz in irgendeiner Art und Weise, die auch nur ansatzweise einen Zusammenhang zu IonCube oder Zend benötigen würde.
Wenn ein Kunde(!) seine Cronjobs mit PHP-CLI benötigt, dann muss er so oder so den absoluten Pfad verwenden, der vom Provider vorgegeben wird. Diese Cronjobs, die der Kunde in der GUI konfigurieren kann, sind vollkommen unabhängig von einer Domain und somit auch unabhängig von der PHP-Version der CLI oder sonstwem.
-
Warum wird in dem Cronscript nicht zwischen PHP 7.0 und 7.1 etc. unterschieden? Es wird grundsätzlich die 7.0 php.ini geladen.
Es geht hier um die cron.php.sh von LiveConfig selbst, nicht um die Cronjobs der Verträge.ZitatDas führt zu Fehlern, sobald man 7.1 als CLI eingebunden hat -> gerade mit ioncube.
Die Cronjobs der Kunden/Nutzer müssen schon auch die richtige CLI-PHP-Version verwenden. LiveConfig ändert den Cron-Befehl nicht ab.Dieser ist auch unabhängig von jeglicher Domain-PHP-Konfiguration.
-
-
Präfixe werden derzeit nicht vererbt (es besteht die Gefahr dass diese zu lang werden - gerade bei Datenbanken wird das eng).
Gegenvorschlag:
Admin legt Prefix systemweit für alle fest, zumindest optional so festlegbar.
"%c" ist dann für alle gleich.
-
[quote='bash','https://forum.liveconfig.com/index.php?thread/&postID=15585#post15585']Ja soweit würde dieses gehen ja.. aber dann hab ich immer noch das Problem weil ich hier Geräte im Einsatz habe wo ich das nicht auswählen lassen kann ob IPv4 oder IPv6 (das Gerät nimmt automatisch die IPv4) und dann widerrum auch zwei Geräte die keinen Dyndns Client besitzen (sind normalerweise dafür nicht vorgesehen) diese kann ich dann nur via URL quasi ins Netz nach außen bringen./QUOTE]
- dyndns.example.com IN A/AAAA
- ipv6.dyndns.example.com IN AAAA
- ipv4.dyndns.example.com IN ADiese IP-Konfiguration lässt sich aber, zugegebenermaßen, über die LiveConfig-GUI schlecht abbilden.
-
Subdomain anlegen, die keinen IPv4-Record, sondern nur einen AAAA-Record aufweist. Dann kann nur IPv6 verwendet werden.
Auszug aus dem LiveConfig-Handbuch:
ZitatDen gewählten Benutzernamen und das Passwort müssen Sie anschließend in Ihrem Dynamic DNS Client angeben. Die Update-URL lautet standardmäßig http(s)://<LiveConfig-Server>(<:Port>)//liveconfig/hosting/dnsupdate?hostname=<domain>&myip=<ipaddr>
Viele DynamicDNS-Clients ersetzen übrigens automatisch die Platzhalter <domain> und <ipaddr>. Optional können Sie mit dem Parameter myip6=<ip6addr> auch eine IPv6-Adresse („AAAA-Record“) aktualisieren.
Hilft das?(nicht selbst getestet, sorry)
