[solved] zu Bug: no ssl virthosts with nginx (#1295)

devil65 · November 19, 2013

Hallo d00p,

hier die Diskusion zum Bug #1295.

zu Deinen Fragen

1) do you have ssl globally enabled?
2) do you have a ssl ip/port combination added (with "is ssl = yes")
3) do you have assigned this ssl ip/port to any domain?
4) what are the domains settings? (ssl-redirect yes/no, etc.etc.etc.)

zu 1.-3.: ja

zu 4. unterschiedlich, je nach Anforderungen der Domains

Ich wei? nicht, aber ob 0 oder NULL ist hier glaube ich egal, es wird nach ==1 abgefragt.

Das Ergebnis ist bei unserer PHP-Version (PHP 5.4.4-14+deb7u5) offensichtlich das selbe und keine Fehlermeldungen in den Logs.

(Wie erw?hnt, ich bin Java-Programmierer und kenne mich in PHP nicht so besonders aus)

Mein Kollege und ich glauben das evtl. zufall ist das es bei Dir geht. Das "GROUP BY" gibt bei uns jedenfals mit der Original-SQL immer die Daten des Nicht-SSL-Datensatzes aus.

Die Apache-conf ist denke ich auch ok. (siehe Anhang)

Anhang klappt leider nicht:

# 22_froxlor_normal_vhost_mydomainn.de.conf
# Created 19.11.2013 09:50
# Do NOT manually edit this file, all changes will be deleted after the next domain change at the panel.

# Domain ID: 13 - CustomerID: 1 - CustomerLogin: web1
<VirtualHost 144.76.0.0:80 [2a01:::::2]:80>
  ServerName mydomainn.de
  ServerAlias www.mydomainn.de
  ServerAdmin admin@mydomainn.de
  DocumentRoot "/var/customers/webs/web1/"
  # PHP is disabled for this vHost
  php_flag engine off
  Alias /awstats "/var/customers/webs/web1/awstats/mydomainn.de"
  Alias /awstats-icon "/usr/share/awstats/icon/"
  ErrorLog "/var/customers/logs/web1-mydomainn.de-error.log"
  CustomLog "/var/customers/logs/web1-mydomainn.de-access.log" combined

  Include /etc/apache2/tomcat1.conf
</VirtualHost>

Gr??e devil65

d00p · November 19, 2013

Es ist kein Zufall bei mir, bei anderen geht es genau so. Bei manuellem ausf?hren der query z.b. in phpmyadmin gibt mir auch die korrekte Liste mit Allen domains SSL und nicht SSL

devil65 · November 19, 2013

Hm, sehr eigenartig. Es gibt aber zumindes auch zwei bei denen es nicht geht

Ich kann mir nur noch vorstellen, da? das Handling bei MariaDB anders ist. Die innere SQL f?r die SSL-Infos gibt bei uns immer die Daten in der Reihenfolge Domain ohne SSL dann Domain mit SSL aus (wenn keine order), und GROUP BY nimmt den ohne SSL, egal ob mit oder ohne ORDER BY und egal ob ASC oder DESC.

devil65 · November 19, 2013

Wir haben uns das mal ein bischen angeschaut:

Die innserste SQL (SELECT `di`.`id_domain` , `p`.`ssl`, `p`.`ssl_cert_file`,...) f?r sich alleine funktioniert wunderbar.

Aber schon bei der umgebenden SQL fangen die Unterschide an. Bei MariaDB 5.5 ist dann die Reihenfolge ohne Gruppierung

immer "Datensatz ohne" dann "Datensatz mit" SSL, egal ob ohne, mit, mit ASC oder mit DESC.

Das Gruppieren sagt auch nicht, das die Daten aus den gef?llten Feldern genommen werden sollen, wenn die in anderen Datens?tzen leer sind.

Die w?rde man durch z.B. GROUP_CONCAT bekommen, aber das ist ja hier nicht Ziehlf?hrend.

Leider habe ich gerade keinen MySQL-Server online, nur MariaDB, so das ich das alles nicht vergleichen kann.

Aber nach dem Code wird ja mit dem Daten erst die non-ssl-vhost-Datei erzeugt, und wenn ssl=1 zus?tzlich die ssl-vhost-Datei.

Beide Funktionen gehen mit dem Ergebnis meiner SQL (f?r apache-conf zumindest) und werden durch null oder 0 nicht beeinflusst, soweit ich das bis jetzt sehe.

Zur Not kann man ja eine Abfrage nach null mit einf?gen.

Ich hoffe das kommt hier nicht Oberlehrerhaft r?ber, ich will nur helfen. Wir verwenden Froxlor nun schon seit glaube 2009 und finden es und vor allem Deine Arbeit Spitz.

Gr??e Jens

d00p · November 19, 2013

Ich werde das heute abend mal ausgiebig durchspielen. Danke schonmal f?r die umfangreiche Analyse.

d00p · November 20, 2013

W?rdest du mir von einer der betroffenen Domains mal einen SQL dump aus der panel_domains und der panel_domaintoip (mit id_domain = id-der-domain) geben? Am besten auch noch die entsprechenden IPs aus der panel_ipsandports.

Domainnamen und IP's k?nnen nat?rlich gerne verfremdet werden.

d00p · November 22, 2013

Also ich kann da bisher keine Fehler entdecken und es wurde nun von mehreren Leuten best?tigt, dass das problemlos funktioniert. Es w?re sch?n, wenn ihr die M?glichkeit habt, dass ggfls. mal mit MySQL statt mit MariaDB zu testen...scheint mir doch sehr daran zu liegen.

d00p · December 10, 2013

Hey devil65, die aktuelle Entwicklungversion (git-branch "0.9.31", nicht master) hat eine ?berarbeitete Version, w?rdest du das f?r uns unter MariaDB testen und uns sagen, ob die Problematik damit gel?st wurde? Gerne auch via IRC (irc.freenode.net/#froxlor).

devil65 · December 10, 2013

Hallo d00p,

funktioniert wunderbar, habe es gerade in der VM getestet. Configs sind alle da und ok.

Werde es in in den n?chsten Tagen auf den Server ?bernehmen, aber wie es aussieht sollte es keine Probleme geben.

?brigens patche ich mir froxlor immer f?r awstats, so das dynamische Statistiken erzeugt werden (Frameset, alle Monate/Jahre).

Hab ich mir mit der Zeit aus anderen offenen Systemen abgeschaut und f?r froxlor angepasst. Wenn Ihr interesse habt melde Dich einefach mal.

Dashboard ist ?brigens cool.

Danke und G??e

d00p · December 10, 2013

Perfekt.

Bzgl. dyn. awstats: genau das hatte froxlor fr?her und es ist performance technisch nich so der br?ller bei jedem aufruf via perl-script die stats zu erstellen (zumal daf?r perl erstmal gehen muss, das wiederrum bei fcgid/fpm bedeutend komplizierter wird, etc.etc.etc). Aber das ist ein anderes Thema.

devil65 · November 26, 2013

Hallo d00p,

hab mir mal die M?he gemacht und einiges durch getestet:

MySQL    5.5.31  wheezy  ok
MySQL    5.0.51a lenny5  ok
MariaDB  5.2.5   lenny   ok
MariaDB  5.5.34  wheezy  nicht ok
MariaDB  10.0.6  wheezy  nicht ok

Das Problem ist, dass beim SELECT des INNER JOIN das ORDER BY nicht mehr wirkt. Vermutlich wird beim Anlegen der tempor?ren Tabelle des innersten "SELECT `di`.`id_domain`..." das ORDER BY weg optimiert, so dass die Datens?tze bei der SQL

SELECT * FROM (
     SELECT `di`.`id_domain` , `p`.`ssl`, `p`.`ssl_cert_file`, `p`.`ssl_key_file`, `p`.`ssl_ca_file`, `p`.`ssl_cert_chainfile`
     FROM `panel_domaintoip` `di` , `panel_ipsandports` `p`
     WHERE `p`.`id` = `di`.`id_ipandports`
     ORDER BY `p`.`ssl` DESC
   ) AS my_table_tmp
#      GROUP BY `id_domain`

nicht mehr sortiert werden. Das ?u?ere "SELECT * FROM ( SELECT..." liest die temp. Tabelle wie sie ist, in dem Fall dann unsortiert, da das ORDER BY offensichtlich wegoptimiert wurde.

Prinzipell ist die SQL auch nicht ganz korrekt, da das "GROUP BY" nur Datens?tze mit gleicher "id_domain" gruppiert, und nicht garantiert das die anderen Daten der Datens?tze die sind, die man will. Es ist einfach nur zufall das die Daten mit den SSL-Infos kommen, weil sie in der temp. Tabelle bei den ?lteren DBs sortiert gespeichert wurden und beim gruppieren der erste gefundene Datensatz genommen wird.

Hab es gerade auch in den FAQs von MariaDB gefunden: https://mariadb.com/kb/en/why-is-order-by-in-a-from-subquery-ignored/

Ist also auch kein Bug, sondern kann auch in MySQL kommen, wenn Sie die Optimierung ?ndern.

Gr??e Jens

d00p · November 26, 2013

Das w?rde auch bedeuten, dass die Query von epek in http://redmine.froxlor.org/issues/1295#note-40 auch falsch ist, denn hier f?gt er nur ein weiteres Feld in die ORDER BY clause ein. Man m?sste das wohl komplett anders angehen, damit das auch zuk?nftig verl?sslich funktioniert.

devil65 · November 26, 2013

Ja, eigentlich ist die auch falsch, da nun f?r jede Domain, die auch SSL hat, jeweils ein Datensatz mit und ein Datensatz ohne SSL erzeugt wird. Durch das Script wird dann die normale (nicht SSL)Config zwei mal geschrieben.

Ist unsch?n, funktioniert aber, da die Config immer wieder ?berschrieben wird und hat dadurch halt keine negativen Auswirkungen auf die Funktion allgemein.

Gr??e Jens

devil65 · November 26, 2013

Ah, hatte nicht weiter gelesen: Durch seine ?nderungen am Script passt es ja wieder, dadurch werden die nicht zwei mal geschrieben.

d00p · November 26, 2013

Ja, dennoch ist die query wohl auch nicht update-sicher - vorallem was mariadb angeht

devil65 · November 26, 2013

Na ja, die Subquerry ist da nicht auf die Sortierung angewiesen, das l?st er ja per PHP. Deine SQL ansich finde ich schon eleganter, ich lass auch lieber die DB-Binaries als Interpreter f?r sowas arbeiten

Sign In

[solved] zu Bug: no ssl virthosts with nginx (#1295)

Question

Link to comment

Share on other sites

15 answers to this question

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Archived

Similar Content