Ob nun gerade Anfänger damit klar kommen, wage ich aber zu bezweifeln.
Jo, kommt auf die Kunden an. 
Zitat
wget http://foo -O /dev/null > /dev/null
vs.
cmd -t http -r https://foo
Eine vorübergehende halbe Lösung ist mir in diesem Fall lieber als gar keine (wget & verschd. PHP-Binpaths).
irgendwie stehe ich auf dem Schlauch, erklär doch bitte knapp, was der Vorteil gegenüber der "üblichen" Vorgehensweise ist
Abstraktes Interface/ Wrapper für Kunden, die bei wget vergessen den Parameter "-O /dev/null" u.ä. zu setzen. Kunden die die PHP-Version via Parameter statt Binary-Pfad definieren möchten/ sollen. Man könnte das weiter treiben und in der UI integrieren. Niemand ist gezwungen das zu verwenden.
ZitatOMG, der Matchbit mal wieder... total gaga
Don't feed the trolls...
... Beitrag gemeldet.
Ich denke daher, dass wir Backtraces daher zwischenspeichern und auf der "Dashboard-Seite" (Übersichts-Seite bei der Anmeldung) einen sichtbaren Hinweis einbauen á la "Es ist ein Fehler aufgetreten - dürfen wir folgende Daten senden? [...(Daten)...]". Mit einem Klick auf "ok" geht das dann raus - eventuell mit einer Checkbox "[ ] künftig automatisch senden".
Provider die ihren Kunden LiveConfig-Admin-Zugang zu Managed-Server u.ä. geben werden dann komische Fragen stellen. Ich als Admin würde das Dashboard dann auch nicht als Applikationsmonitoring nutzen/ missbrauchen. Daher würde ich nach vor die von mir vorgeschlagene Variante bevorzugen.
Ich werde ohnehin demnächst versuchen die HTTP(S) Requests die zu license.liveconfig.com und update.liveconfig.com gehen über einen Proxy zu tunneln, damit ich die Internetverbindung bei den MySQL-Servern endlich kappen kann. Mal sehen wie weit ich komme.
Das automatische "Raustelefonieren" mit optionalem Opt-Out finde ich bedenklich. Die Brisanz der o.g. Daten inkl. der Metadaten (IP-Adresse u.a.) mag vielleicht gering sein, doch möchte ich festlegen wann welche Daten zu irgendeinem Unternehmen gesendet werden. Schon allein wg. der aktuellen SSL/TLS-Konfiguration (!!!): https://www.ssllabs.com/ssltes…config.com&hideResults=on (cert self signed = kein Problem)
Ich möchte euch liebend gerne die Traces inkl. der o.g. Daten zur Produktverbesserung schicken, aber kontrolliert. Akzeptabel wäre es wenn LiveConfig die Dumps im lokalen Dateisystem ablegt. Dann kann ich das Verzeichnis über neue Dumps überwachen lassen und sie dann nach manuellem Review automatisiert via HTTPS einsenden.
Es haben ohnehin nicht alle Server direkten unbeschränkten Zugriff ins Internet. Wenn LiveConfig dann die Timeouts (wg. IP DROP) nicht richtig abfängt steht ein neues Problem vor der Tür.
Also:
Opt-In für A) automatischen Upload B) oder Opt-In für automatische Ablage im Dateisystem (Benachrichtigung des Admins mit Bordmitteln ist ganz einfach umsetzbar)
ZitatWir wissen also nicht, bei welchem Kunden, welchem Server, welcher Lizenz oder welcher Domain usw. der Fehler aufgetreten ist - uns interessiert lediglich der Ort innerhalb des Programms.
Ein Profil über Kunde und Server lässt sich bspw. mit der (statischen) Server IP-Adresse erstellen.
Die vorgesehene optionale Opt-Out Variante ist für mich ein Hinderungsgrund LiveConfig auf eine neuere Version zu aktualisieren.
Ausführen von PHP-Scripts:
cmd-wrapper.py -t php -r ~/htdocs/current/scripts/jobs.php 1>/dev/null
cmd-wrapper.py -t php -p 5.4 -r ~/htdocs/current/scripts/jobs.php 1>/dev/null
cmd-wrapper.py -t php -p 5.6 -r ~/htdocs/current/scripts/jobs.php 1>/dev/nullWird keine Version mit dem Schalter -p angegeben, wird standardmäßig PHP 5.5 verwendet.
Abruf von HTTP-Ressourcen/ -Adressen:
cmd-wrapper.py -t http -r https://foo/scripts/jobs.php 1>/dev/nullDie Pfade für das PHP-Binary und die php.ini-Pfade werden noch konfigurierbar gemacht.
Einen Patch habe ich hier im Forum diesbezüglich schonmal bereitgestellt. Wenn es das angekündigte offizielle LUA Repo geben würde könnte man das per Pull-Request auch in Upstream einfließen lassen.
(Workaround: https://github.com/bechtoldt/liveconfig-lua/tree/1.7.5-r3127)
Zudem wurde angeregt, die Lua-Scripte auf Github zu pflegen. Wir haben nach kurzer Besprechung beschlossen, das einfach mal auszuprobieren. Unsere eigene Versionsverwaltung wird unabhängig davon weiter gepflegt werden, der Stand dann aber regelmäßig mit Github abgeglichen. Aus Zeitgründen werden wir das aber erst nach der Freigabe von LiveConfig v1.8 angehen.
Gibt es inzwischen hierzu konkrete (Zeit-)Pläne?
You can do this by configuring postfix to discard mails by a specific rule (envelop sender/ recipient). This requires a manual modification of the main.cf config file.
But as kk said: Don't do this as long as you _REALLY_ know what you're doing.
Just bounce unwanted messages.
I think you mean rejecting the mail during the SMTP dialog instead of bouncing the mail after accepting it. 
Aus zeitlichen Gründen werde ich nicht schauen, was passiert, wenn ich hinter das Backslash ein wenig mehr SQL schreibe
Keine Sorge, es besteht keine Gefahr für die Bevölkerung.
ZitatJede einzelne Formulareingabe auf der Weboberfläche wird durch LiveConfig untersucht, bevor die Daten weiterverarbeitet werden. XSS und SQL-Injections haben somit keine Chance.
In den Postfix-Einstellungen kann der Servername für Auto-Discovery gesetzt werden. Dieser wird bei der Beantwortung der Auto-Discovery-Anfrage vom Client dann auch als IMAP-Servername genutzt.
In gewissen Fällen laufen MTA und MDA nicht auf dem gleichen System. Es ist daher notwendig für den MDA-Teil einen dedizierten Servername festlegen zu können.
Besten Dank && Guten Rutsch
MySQL User sollten die MySQL Grant Privs CREATE und DROP bei der zugewiesenen Datenbank nicht bekommen. Bei den User Standard Grant Privs ist das bereits der Fall.
An der 1.7 planen wir keine Änderungen mehr, die 1.8 befindet sich dafür in den letzten Zügen
Das ist schade. Die Releases der letzten Monate haben gezeigt das man den Minor-Releases vor der Verwendung ein wenig Zeit zur Reifung geben muss. Ich hoffe also das ich in den nächsten 4-8 Wochen nicht auf gravierende Sicherheitslücken o.ä. stoßen werde und muss wohl bis dahin auf Bugfixes verzichten können.
es wird eben die Version standardmäßig ausgewählt, die auf dem Server standarmäßig installiert ist.
Das ist aber nicht die Version die der Benutzer als zu verwendende Version ausgewählt hat! Was nutzt einem Benutzer der Dialog wenn er nicht funktioniert?
Ich kann mich entscheiden: Setze ich in der custom.lua eine Standardversion (prio=0) wird das zwar in der GUI korrekt dargestellt, jedoch wird dann wahlweise ein funktionierendes, defektes oder nicht vorhandenes PHP der Distri verwendet. Setze ich keine Standardversion (gemäß offizieller Doku) wird wegen alphanumerischer/ numerischer Sortierung die kleinste PHP-Version als erste <option> im <select>-Menü, also als Standard vorausgewählt.
ZitatIst auch kein Fehler, sondern durchaus so beabsichtigt: damit "markiert" LC die Standard-PHP-Version.
Nochmal: Wenn LC die Benutzerwahl anhand eines value-Attributs mit leerem Inhalt verifiziert dann wird HTML einfach falsch generiert und verarbeitet. Im HTML wird doch bereits das selected-Attribut eingefügt.
http://www.w3.org/TR/2012/WD-h…5/the-option-element.html
Nun kann man natürlich als Standard bzw. erste <option> etwas nehmen wie "Bitte wählen" und hoffen das der Benutzer eine Wahl trifft. Erstens ist das in Sachen Usability so richtig ungünstig und zweitens wird nicht jeder Benutzer wissen welche Version die geeignete ist. Ich als Admin möchte das die Benutzer die jüngste stabile PHP-Version verwenden, also möchte ich eine Version als Standard vorgegeben.
Um es auf den Punkt zu bringen:
Das Setzen einer Standardversion ist aktuell weder offiziell supportet noch technisch implementiert worden (siehe LUA-Patch). Möchte man aber dem Benutzer zusätzliche PHP-Versionen anbieten, jedoch nicht die distributionseigene weil diese bspw. gar nicht existiert (!), hat man ein dickes Problem.
Es würde mich freuen wenn LiveConfig den Standard <option>-Knoten auch mit gefülltem value-Attribut generiert damit _jede_ der auswählbaren PHP-Versionen benutzbar ist.
Schönen Abend.
Ich werde in den kommenden Tagen einige Hundert Domains in LiveConfig anlegen. Durch die Sache mit der Auswahlliste wird standardmäßig PHP 5.3 ausgewählt.
Foreman 1.8 mit der neuen Template-Engine werde ich ich vor den ersten Bugfix/ Maintenance Releases noch nicht ausrollen.
Ich schätze in 1.7 wird an der Auswahlliste nicht mehr gearbeitet?
Aber ich glaub ich krieg hier keine Vernünftige Antworten. Hab gedacht das ist ne Anständige Community...
Erfolgreich disqualifiziert. Danke, mach's gut.
Eine MySQL Replica mit so vielen HOPs dazwischen wird wahrscheinlich nicht gut gehen.
Ohnehin kann ich nur davon abraten MySQL-Datenbanken zu replizieren die bspw. von LiveConfig verwaltet (create, delete, etc.) wird. Das macht das ganze nur komplizierter.
Das Konzept mit MySQL Slave und LiveConfig Slave verstehe ich nicht - will ich vielleicht auch gar nicht.
Warum willst du zwei halb funktionierende Server die bei unterschiedlichen Anbietern stehen benutzen statt einen funktionierenden bei einem zuverlässig(ere)en Anbieter? Wenn dir dein Piwik so wichtig ist kannst du beim gleichen Anbieter einen zweiten Server nehmen und dann beide replizieren lassen.
Etwas anderes wäre es, wenn man die Dropdown-Box zur PHP-Auswahl bei neuen Subdomain dann einfach auf z.B. PHP 5.4 voreinstellt.
Ja das habe ich gemeint, daher auch der HTML-Quelltext-Auszug.
Bugfixing:
Ich würde z.B. gerne eine andere Standard PHP-Version statt die lange nicht mehr von PHP unterstützte Version 5.3 definieren. Soll wohl nicht passieren.
ZitatLiveConfig setzt bewusst keine error_reporting-Einstellung, sondern kopiert standardmäßig nur die Werte aus der Standard-php.ini.
Gut, error_reporting zählt für mich (bzw. Kunden) zu einem der wichtigsten Einstellungen warum der Kunde/ Admin PHP-Einstellungen ändern können müsste.
Zu None:
Gut möglich das ich da was verwechselt habe, sorry. In der PHP-Doku wird die Wahrheit stehen. Werde ich noch einmal testen müssen.
Zu der HTML-Sache:
Nach einer Korrektur in meinem LUA-Patch sehe ich das LC nun folgenden Code generiert:
<select name="phpversion">
<option value="" selected="selected">Standard (5.5)</option>
<option value="cBiy9BRyTGsa">5.3</option>
<option value="cM5ura3E.fyW">5.4</option>
<option value="cGf2YBaQMBtD">5.6</option>
</select>ZitatIst auch kein Fehler, sondern durchaus so beabsichtigt: damit "markiert" LC die Standard-PHP-Version.
Kann ich als Außenstehender nicht nachvollziehen. Ist dafür nicht das selected-Attribut zuständig?
Kann das jemand verifizieren?
Update: Verwendet man den beschrieben Patch für die PHP-Versionsliste wird ein ziemlich unangenehmer Effekt in LC bemerkbar. Siehe 3) http://www.liveconfig.com/de/forum/threads/1560-PHP-Schwerwiegende-Bugs-innerhalb-von-Configs-in-speziellen-Fällen.