Hallo,
Passwort wäre dann 64 x die Raute
PlainMD5 dürfte ja nur 32 haben.
Ich hab mal im Setup des alten Mailserver / Postfixadmin geschaut.
$CONF['encrypt'] = 'dovecot:CRAM-MD5';
Kann man damit was anfangen?
Hallo,
Passwort wäre dann 64 x die Raute
PlainMD5 dürfte ja nur 32 haben.
Ich hab mal im Setup des alten Mailserver / Postfixadmin geschaut.
$CONF['encrypt'] = 'dovecot:CRAM-MD5';
Kann man damit was anfangen?
Guten Tag,
wir müssen für einen Kunden ein auf Postfixadmin basiertes Mailsystem nach LiveConfig migrieren. Allerdings haben wir nur MD5 Passwort Hashes die uns zur Verfügung stehen. (Also keine gesalzenen)
Welche Möglichkeiten gibt es diese (alten) Passwörter über die SOAP Api ins LiveConfig zu bekommen?
VG,
Torsten Walther
Da Fragen ggf. in anderen Threads untergegangen sind.
1) Wann wird den die PHP Versionswahl unter Nginx endlich funktionieren?
2) Wenn 1 nicht zeitnah behoben wird / werden kann, warum wird dann nicht wenigstens das Optionsfeld für die Versionswahl ausgeblendet, sofern man eine nginx IP Gruppe für die Domain / Subdomain auswählt?
3) Im Info Popup zu PHP Versionswahl wird auf http://www.liveconfig.com/de/h…torial.domains.phpversion verlinkt. den Artikel gibt es noch nicht.
Im Popup könnte man zumindest darauf hinweisen, dass es bei NGINX nicht funktioniert.
4) Wann könnten denn Nginx AccessLogfiles auf Vertragsebene verfügbar sein?
Bis auf das Nginx Thema, läuft LiveConfig ins Summe relativ "rund" (CentOS 6 & 7).
Wir setzen allerdings LiveConfig aktuell nur bei einigen ManagedServer Kunden ein, da es für den Massengebrauch (SharedHosting) meines Erachtens noch viel zu viele Unstimmigkeiten gibt, die wiederum für _UNS_ viel zu supportaufwendig wären. Schade eigentlich.
Vg,
Torsten Walther
Funktioniert den in der 1.8.2 dann auch endlich die Nginx PHP Versionswahl?
In der aktuellen Stable (1.8.1-r3397) funktioniert es nämlich noch nicht.
VG,
Torsten Walther
Ist es eigentlich auch möglich eine andere PHP Version als Standard auszuwählen?
Das wäre in der Tat eine recht sinnvolle Ergänzung.
Die existieren aber nur als Update variante leider nicht als zusätzliche...
Habe m&m's t dem Remi Repo schon experimentiert nur funktioniert das nicht wie gewünscht...
Entweder manuell einen "configure & make und make install" mit unterschiedlichen Präfixen auf dem Server laufen lassen, oder sich ein eigenes Repo bauen. Letztere Variante haben wir vor Jahren gewählt (ist auch nicht sooo schwierig). Das LiveConfig für einige Distros ein REPO mit verschiedenen PHP Versionen anbietet ist praktisch, mehr aber auch nicht.
Ist deine Distro nicht dabei, musst du halt als ADMIN tätig werden.
Nginx PHP Versionswahl ... Wann implementiert? so grob ![]()
Ursprüngliche Aussage vom 22.09. "voraussichtlich bis Ende kommender Woche"
Hallo,
könntest du mit dovecot-managesieve / dovecot-pigeonhole realisieren. Entsprechend die dovecot.lua anpassen, sodass
die Sieve Plugin / Parameter etc. auch in der dovecot.conf landen. (Zumindest hab ich das bei unseren Confixx Servern so
realisiert).
Hat dann auch den Vorteil, dass man bequem als Kunde via RoundCube (entsprechends Sieve Plugin gibt es) eigene Filterregeln definieren kann.
Die PHP Versionswahl funktioniert nicht für die Konfiguration einer Nginx Domains. (Im FCGI Starterskript ist der Pfad
zum Binary auch auf /usr/bin/php-cgi hartgecodet. Gibt es ein Workaround um einer NGINX Domain eine separate PHP Version zuzuweisen?
Bei Anlegen des Hostingvertrages über die API kann die Subscription ID Länger m.E. sein.
Zumindest war es vor 1-2 Monaten der Fall als wir einen Kunden einer Insellösung zu einem LiveConfig Hosts migriert haben.
Zitatich bezog mich auf das "zuverlässig"
Das war mit nicht ganz klar, dachte es ging um PFS allgemein. Sorry.
Lt. diff folgende Änderung:
< smtpd_tls_dh512_param_file = /etc/postfix/dh512.pem
< smtpd_tls_dh1024_param_file = /etc/postfix/dh2048.pem
< smtpd_tls_eecdh_grade = strong
Zitat von azieglerWas ist damit eigentlich genau gemeint? Dürfte ja ein paar Leute geben, die NOUPDATE für Postfix gesetzt haben und hier evtl. eine Änderung dann manuell machen wollen/müssen - ja, man könnte natürlich auch temporär das NOUPDATE entfernen und einen diff machen.
Auch in der v1.7.4-r3068 ist noch folgender Bug enthalten! Der übrigens ohne Anpassung der nginx lua
in einem nicht startenden Nginx führt.
http://www.liveconfig.com/de/f…ts-Conf-bei-301-Redirects
Benötigen Sie noch weitere Informationen? Im Bug/Fehlerforum ist zu diesem Thema bislang
keine Antwort von Ihnen erfolgt.
Funktionier bei dir die Proxyfunktion korrekt ?
Ich werde immer weitergeleitet ;S
Das Proxy Feature ist bei mir nicht im Einsatz. Keine Ahnung ![]()
Hallo,
bei den 301 Nginx Redirects schleicht sich wohl ein Fehler ein.
Generierter Nginx Code
server {
listen 127.0.0.1:80;
server_name domain.de
domain2.de;
rewrite ^/.* "http://www.domain3.de/abc[B][COLOR='#FF0000']\$[/COLOR][/B]" permanent;
}
Mit dieser Config startet der Nginx logischerweise nicht, da nur ein $ steht und keine Variable.
>[root@host]# /etc/init.d/nginx configtest
>nginx: [emerg] invalid variable name in /etc/nginx/vhosts.d/web1.conf:130
>nginx: configuration file /etc/nginx/nginx.conf test failed
In der Original nginx.lua schaut es wie folgt aus:
-- create server{} section for all domains with 301-redirects
if r301_count > 0 then
for key in pairs(r301) do
write_server(cfg, opts, fh, vhost, r301[key])
key = string.gsub(key, "\\", "\\\\")
key = string.gsub(key, "$", "\\$")
if string.sub(key, -2) == '/*' then
fh:write("\trewrite\t\t^(/.*)$ \"", string.sub(key, 1, string.len(key)-2), "/$1\" permanent;\n")
else
fh:write("\trewrite\t\t^/.* \"", key, "\" permanent;\n")
end
fh:write("}\n\n")
end
end
Alles anzeigen
Die Ziel URL hat übrigens kein "/*" dran.
Hallo Herr Keppler,
hab das neue init-Skript getestet, funktioniert bislang problemlos.
Besten Dank.
VG,
Torsten Walther
Kleiner Nachtrag, wenn ich im Init Skript /etc/init.d/nginx-php-fcgi in der restart Sektion ein "sleep 1" einfüge,
klappt es mit dem Restart.
ZitatAlles anzeigen
restart)
stop
sleep 1
start
;;
. Kann allerdings nicht im Sinne des Erfinders sein ![]()
Folgende Ausgabe (User lautet zconnect)
ZitatStopping PHP FastCGI for NGINX: zconnect - done.
Starting PHP FastCGI for NGINX: zconnect[ALREADY_RUNNING] - done.
Danach sind die entsprechende Prozesse _weg_
Führe ich den Befehl erneut aus, kommt
ZitatStopping PHP FastCGI for NGINX: zconnect - done.
- done. PHP FastCGI for NGINX: zconnect [ OK ]
Und die PHP Prozesse sind wieder da.
Hallo,
Der Fehler mit PHP Einstellungen eines NNGINX-FCGI Hosts besteht in der aktuellen Preview
immer noch:
Ändere ich eine PHP Einstellung -> Stirbt der php-cgi Prozess.
Ändere ich eine PHP Einstellungen erneut -> Wird der php-cgi PHP Prozess gestartet.
Dh. irgendwas mit dem Restart stimmt nicht. (Dafür startet er aber wenn der Prozess nicht vorhanden ist)
Es ist ein Vhost mit NGINX/PHP-FCGI vorhanden, OS Centos 6.
VG,
Torsten Walther
Kann nicht der Sinn sein, man sollte zumindest erwarten können, dass bei kommerzieller Software die Sachen die
man auswählen / konfigurieren kann auch tadellos funktionieren. Statt an diversen Stellen immer wieder etwas rumzubauen,
wäre es wesentlich wichtiger die BASICS erstmal sauber zu handeln.
Es ist schon nen Witz eine LAB Version zu veröffentlichen wenn die aktuelle Stable eigentlich die BETA Bezeichnung verdient hätte. Für die man nebenbei noch Lizenzgebühren zahlt. Nunja, ging vielversprechend los ... den Rest spare ich mir.