Diskussionsthread zur Konfiguration von sarge-amd64

Die Angaben sind alle jeweils Optional, und können auch bei Eindeutigkeit weggelassen werden.



Der Rechner weiß das, weil de_DE@euro ein Synonym für latin9 ist, genauso wie de_DE synonym für latin1 steht. Wozu unnötige Redundanzen einbauen?
Das wird angenommen, aber IMHO stehen diese Dinge fuer unterschiedliche Informationen.

de_DE ist doch kein Synonym fuer latin9. Es sagt ueberhaupt nicht's darueber aus. Ich benutze z.B. de_DE.UTF8 bzw. frueher de_DE.ISO-8859-1. ISO-8859-15 gibt es auch ohne @euro dazu, in gd_GB ISO-8859-15 zum Beispiel.

Was ist eigentlich mit en_HK.GB2312?

Ich denke man sollte das schon vernuenftig machen.
 
Das wird angenommen, aber IMHO stehen diese Dinge fuer unterschiedliche Informationen.

de_DE ist doch kein Synonym fuer latin9. Es sagt ueberhaupt nicht's darueber aus. Ich benutze z.B. de_DE.UTF8 bzw. frueher de_DE.ISO-8859-1. ISO-8859-15 gibt es auch ohne @euro dazu, in gd_GB ISO-8859-15 zum Beispiel.

Was ist eigentlich mit en_HK.GB2312?

Ich denke man sollte das schon vernuenftig machen.

UTF ist kein Latin, und muss demzufolge extra angegeben werden. Und de_DE ist kein Synonym für latin1, sondern impliziert es. Da hatte ich vorhin Stuss geschrieben. 8859-15 ist zumindest nach meinem Kenntnisstand lediglich 8859-1 plus Euro-Symbol(e). Ob du nun @euro oder ISO-8859-15 angibst, ist dann wurschtegal.
Die 8859-Codierungen sind die Gebräuchlichsten, und wenn nix extra angegeben wird, wird implizit davon ausgegangen, dass latin gemeint ist. Wenn man eine andere Codierung nutzen will, muss man sie dann explizit angeben.
 
de_DE impliziert nicht ueberall latin! Wenn das nicht in der alias Tabelle steht, hast du ein Problem. Man hat auch ein Problem wenn dieses gleich angenommen wird.

Es hat schon Sinn, dass es mehrere Felder gibt, die unterschiedliche Informationen beinhalten, von einem Feld auf's andere schliessen, bringt nur wenig Luxus fuer die Probleme die auftreten koennen.

Schade, dass soviele Leute immer nur ihr Encoding und ihren Standort sehen, das hat I18N schon immer massiv aufgehalten.
 
Wenn explizit festgelegt ist (ich weiß nicht, ob das der Fall ist), dass ein nicht angegebenes Encoding gleich ISO-8859-1 bzw. ISO-8859-15 bei @euro ist, dann ist das überhaupt kein Problem. Dann treten auch keine Probleme auf.

Aber das gehört hier alles eh nicht hin, weil es beim neuen Server nicht weiterhilft. Debian versteht offenbar de_DE@euro, und wenn es da Probleme gibt, gibt es die auch bei de_DE.ISO-8859-15@euro.
 
Was streitet Ihr Euch hier um Details? Ich hab doch oben schon geschrieben dass es völlig egal ist was ich hier eintrage! Die Fehlermeldung ist immer die gleiche! Und wenn ich "seppl" eintrage, die Fehlermeldung bleibt die gleiche und das muss doch irgendeinen Grund haben. Das System meldet immer z.B: "locale: Cannot set CTYPE to default locale: no such file or directory"
 
Was streitet Ihr Euch hier um Details? Ich hab doch oben schon geschrieben dass es völlig egal ist was ich hier eintrage! Die Fehlermeldung ist immer die gleiche! Und wenn ich "seppl" eintrage, die Fehlermeldung bleibt die gleiche und das muss doch irgendeinen Grund haben. Das System meldet immer z.B: "locale: Cannot set CTYPE to default locale: no such file or directory"

Hast Du

locale -a

schon gemacht?
Das sollte alle installierten locales auflisten.

lg
 
Probier mal mit "strace command 2>&1 | grep ^open" zu schaun, welche Datei er da öffnen möchte (also command durch xmail oder was auch immer ersetzen).

Wenn das nicht klappt das "strace -f" - das verfolgt auch Forks.
 
Probier mal mit "strace command 2>&1 | grep ^open" zu schaun, welche Datei er da öffnen möchte (also command durch xmail oder was auch immer ersetzen).

Wenn das nicht klappt das "strace -f" - das verfolgt auch Forks.

Na, immer sachte mit den jungen Pferden. Sowas brauchts hier noch absolut nicht.

Nero: Halt dich erstmal an die beiden Vorschläge von tomturbo und mir. Was tomturbo angebracht hat, prüft generell und unabhängig einer Distribution, welche locales installiert sind, die Anweisung, die ich aufgeschrieben habe, prüft ob das passende Debian-Paket installiert ist. Schlussendlich werden wohl beide Varianten zum Ziel führen, aber ich halte es für sinnvoller, es hier nach dem Debian-Way zu machen.
 
Ich würde an der apache-Konfiguration noch was ändern.

Zur Zeit listet der Server alle Plugins auf, die laufen:

Server: Apache/2.0.54 (Debian GNU/Linux) PHP/4.3.10-16 mod_ssl/2.0.54 OpenSSL/0.9.7e mod_perl/1.999.21 Perl/v5.8.4

Das ist ein gefundenes Fressen für Leute, die das Netz nach bestimmten Modul-Versionen mit Sicherheitslücken absuchen.

In der httpd.conf kann man den String verkürzen mit der ServerTokens-Einstellung.

Hier eine Beschreibung für die Einstellungen aus der Apache-Dokumentation:

ServerTokens Prod[uctOnly]
Server sends (e.g.): Server: Apache
ServerTokens Major
Server sends (e.g.): Server: Apache/2
ServerTokens Minor
Server sends (e.g.): Server: Apache/2.0
ServerTokens Min[imal]
Server sends (e.g.): Server: Apache/2.0.41
ServerTokens OS
Server sends (e.g.): Server: Apache/2.0.41 (Unix)
ServerTokens Full (or not specified)
Server sends (e.g.): Server: Apache/2.0.41 (Unix) PHP/4.2.2 MyMod/1.2
 
Irgendwelche weiteren Ideen zur Optimierung? :) Vielleicht kann sich ja das mal jemand ansehen?
http://www.planet3dnow.de/vbulletin/showthread.php?t=250840

Der thread wurde leider geschlossen, daher gebe ich hier meine Anregung:

Nehmt lighttpd statt des ollen apache, mit php als fastcgi.

Der lighttpd ist in allen belangen schneller und effizienter als der apache bei gleichzeitig weniger Resourcenverbrauch.

Ich konnt's anfangs selbst nicht glauben, aber das merkte ich besonders bei typo3 und egroupware sofort selbst.

Php caching mit eaccelerator nicht vergessen !!! wichtig !!!

Sonst tu' ich mir ein bisschen schwer so ohne direkte Systembeobachtung was zu sagen. :-/

Wichtig ist es auch noch die MySQL Werte im Auge zu behalten, betreffend query cache usw. Hoffentlich nehmt ihr eine 4.1'er Version.

lg
-tom-
 
Der thread wurde leider geschlossen, daher gebe ich hier meine Anregung:

Nehmt lighttpd

Sonst tu' ich mir ein bisschen schwer so ohne direkte Systembeobachtung was zu sagen. :-/

Wichtig ist es auch noch die MySQL Werte im Auge zu behalten, betreffend query cache usw. Hoffentlich nehmt ihr eine 4.1'er Version.

lg
-tom-

mysql ist ne 4.0.24er , was hat die 4.1 fuer Vorteile bzw die 4.0 fuer Nachteile?
 
mysql ist ne 4.0.24er , was hat die 4.1 fuer Vorteile bzw die 4.0 fuer Nachteile?

Bei mir hat's was bei der Stabilität von INNODB gebracht. Ich hatte unter 4.0 einige mal total kaputte Datenbanken wenn ich mit mehreren 100tausen records hantierte (insert, reindexing, ...). Bei der 4.1 hatte ich noch nie DB-Serverabstürze.
Deswegen meine Empfehlung auf 4.1 zu gehen.

Zumindest lt. MySQL AB soll die 4.1 'schneller' sein. Kann aber auch 'jawdropping' sein.

Jedenfalls hat die 4.1 etliche features, die die 4.0 nicht hat und ist dzt. von MySQL AB als Produktionrelease empfohlen.

http://dev.mysql.com/doc/refman/4.1/en/nutshell-4-1-features.html

Dort sind dann auch detailierte release-notes mit den Unterschieden.

Ich werde vielleicht mal einen Test auf einer Maschine mit der mysql-test-suite machen (wenn mir gar arg fad ist ;) ) und evt. vorhandene Unterschiede dann posten.

lg
-tom-
 
Das dürfte jetzt nicht mehr so ganz einfach werden, nachdem der Server schon läuft. Egal welche MySQL-Version es nun ist, ich gehe mal davon aus, dass sie auf MyISAM läuft. Das müsste rüber gezogen werden, was wiederum einen Ausfall des Forums bedeutet.
 
Wir haben von allen Pakten das jeweils aktuellste genommen, das per apt-get update/upgrade angeboten wird. Diesen Upgrade-Pfad wollen wir eigentlich auch nicht verlassen, da es sonst bei jedem Update ein mords Gefrickel wird :(

Wäre lighttpd denn kompatibel mit den ganzen Sachen? Ich meine das in Anspielung etwa auf postgresql, das ja was man so hört auch besser sein soll als MySQL. Aber das bringt uns nichts, weil die vbulletin-Anbieter schwarz auf weiß schreiben, dass die Software nicht kompatibel ist mit postgresql. :P

Momentan haben wir auch noch den normalen MPM Apache2 drauf. Da soll es aber ja noch eine Worker-Version geben, die Dual-Prozessoren besser nutzt? Auch das PHP-Caching klingt interessant (ist momentan wohl noch nicht drauf).

Naja, ein paar Vergleichswerte aus diversen Tests wären schon nicht übel ;D

Und immer im Hinterkopf behalten: never touch a running system ;D
 
Wir haben von allen Pakten das jeweils aktuellste genommen, das per apt-get update/upgrade angeboten wird. Diesen Upgrade-Pfad wollen wir eigentlich auch nicht verlassen, da es sonst bei jedem Update ein mords Gefrickel wird :(

Wäre lighttpd denn kompatibel mit den ganzen Sachen? Ich meine das in Anspielung etwa auf postgresql, das ja was man so hört auch besser sein soll als MySQL. Aber das bringt uns nichts, weil die vbulletin-Anbieter schwarz auf weiß schreiben, dass die Software nicht kompatibel ist mit postgresql. :P

Lighttpd ist mit einiger Sicherheit kompatibel, weil's ja nur ein normaler Webserver ist.
Es gibt, gerade für Debian, wunderbare Anleitungen.
Durch seine Einfachheit gibt es auch nicht allzu viele Falltüren.

Die homepage ist, wie nicht besonders schwer zu erraten: www.lighttpd.net

lighttpd kommt feinerweise aus DE !!! von Jan Kneschke!

Ad postgres)

Postgres ist nicht generell schneller. Es kommt auf das Belastungsprofil an.
Der GROSSE Vorteil von MySQL ist ja gerade die Schlankheit, ohne mit unnötigen Features vollgestopft zu sein.
Das macht MySQL schnell.
Wo z.B. keine Transaktionen gebraucht werden schleppt sie den Code auch nicht mit.

Momentan haben wir auch noch den normalen MPM Apache2 drauf. Da soll es aber ja noch eine Worker-Version geben, die Dual-Prozessoren besser nutzt?
Da muß man beim mod_php aber immer verdammt aufpassen ob es threadclean ist.
Nicht jedes Worker Modul ist mit mod_php kompatibel!! Aufpassen! Prefork ist immer noch das sicherste Modul. (Gerade bei den 'älteren' Debian Versionen)

Hat euer Debian überhaupt das neue NPTL oder noch das älte Linux Threadmodell?
Wenn's das alte ist kannst Du gleich das Prefork modul nehmen, denn pro Thread startet der Kernel sowieso einen neuen Prozess. Threads werden da nur 'emuliert'.

Zu überprüfen durch ausführen der libc6 mit # /lib/libc.so.6

Auch das PHP-Caching klingt interessant (ist momentan wohl noch nicht drauf).
PHP Caching ist der absolute Bringer. Das vervielfacht die Performance.
Das funktioniert so:
Der php-interpreter übersetzt den Code nur 1x und legt ihn dann, je nach Speicherplatz und Anzahl der Verwendung, im Speicher, oder auf Platte ab.
Bei neuerlichem Aufruf des php-Codes wird nur mehr das Übersetzte ausgeführt.
Genial einfach!

Auch eine URL: www.eaccelerator.net

Mit dem ab bzw. ab2 programm vom Apache kannst Du selbst den Unterschied leicht feststellen.

Naja, ein paar Vergleichswerte aus diversen Tests wären schon nicht übel ;D

Auf den lighttpd Seiten sind Performancetests wo dir die Luft weg bleibt.

Und immer im Hinterkopf behalten: never touch a running system ;D
Klaro!

Du kannst den lighttpd auf z.B. port 81 parallel zum Apachen laufen lassen und selbst vergleichen, ohne das laufende System allzu sehr zu stören.

lg
__tom
 
Zuletzt bearbeitet:
Ich sag jetzt auch mal kurz etwas hierzu.

1) locales
Die Sache mit dem locales ist mittlerweile geklärt. Nero hätte machen können was er will, die locales waren ab Installation aus irgendeinem Grund defekt. locale-gen hat nur Fehlermeldungen ausgespuckt anstelle die locales zu generieren. Nach einigem rumgebastel hat hier der Windows-Weg geholfen: apt-get remove --purge locales und anschließende Neuinstallation, Konfiguration und locales-gen - Problem gelöst.

2) mailserver
Seit gestern Nacht, grob geschätzt 3 Uhr früh (good times Nero, good times...) läuft auch der E-Mail Server. War ein ziemliches Gefrickel und viel Lesen da keiner von uns die eigentlich notwendige Erfahrung hatte mit Mailservern. Ironischerweise hatte Nero den Mailserver bereits am laufen als der Rechner noch im LAN stand, wobei er hier nichts besonderes konfiguriert wurde und der Mailserver dann irgendwann plötzlich aufgehört hat zu funktionieren.
Wie dem auch sei, seit gestern Nacht läuft auch der (hoffentlich) mehr oder weniger problemlos ;)

3) apache vs. lighttpd
Ehrlich gesagt kommt ein anderer Webserver als apache2 (oder, falls hier Probleme aufgetreten wären, apache1) überhaupt nicht in Frage. Nicht nur, weil apache nun mal eben der Standard ist sondern auch, weil sich sehr viele Teammitglieder damit auskennen. Ein Server wie Planet 3DNow! der täglich mehrere tausend Anfragen zu bearbeiten hat und dies zuverlässig und schnell erledigen muss ist keine geeignete Testplattform für einen neuen, anderen, vielleicht besseren, vielleicht schlechteren Webserver.
Weiterhin ist apache nun mal so weit verbreitet, dass hier bei Bedarf am ehesten Hilfe zu finden ist.
Zum Thema mpm_worker vs. mpm_prefork: Installiert wird standardmäßig mpm_prefork. Wir haben uns mit Nero eingehendst mit der Thematik worker beschäftigt, viel gelesen und überlegt und sind zum Schluss gekommen, dass wir erstmal bei mpm_prefork bleiben - never change a running system. Vielerorts wird von Problemen von sowohl mpm_worker als auch mpm_perchild berichtet, nicht nur mit Drittplugins sondern beispielsweise auch mit php4. Daher haben wir uns entschieden lieber auf der sicheren Seite zu bleiben. Sollte eines Tages der apache2_prefork zum Problem werden was die doch recht üppigen Ressourcen angeht können und werden wir uns natürlich nochmals mit der Problematik beschäftigen. Aber Experimente werden hier logischerweise bei einem Server der bereits im Einsatz ist keine gemacht.

4) Warum Debian?
Einfach gesagt aus drei Gründen: Erstens, weil die Community sich dafür entschieden hat. Zweitens, weil es läuft. Und Drittens, weil sich sehr viele Teammitglieder damit sehr gut auskennen und es bereits seit Jahren nutzen.
Somit kann ich der Community nur für die weise Entscheidung danken - wäre BSD oder ein anderes Linux erste Wahl gewesen hätte die Installation mit Sicherheit deutlich länger gedauert da wir uns vor Ort erstmal hätten einarbeiten müssen.

5) php_caching
Was das php_caching angeht sind wir grade am überlegen und schauen. Die erste Problematik ist bereits, dass im Debian Sarge Repository kein php_caching Modul angeboten wird. Entweder, es hat einen anderen Namen bekommen oder ist eben nicht direkt verfügbar. Im letzteren Fall werden wir davon Abstand nehmen aus von Nero bereits erwähnten Gründen. Aber wir suchen noch ;)
 
Hi D'Espice,

ich habe keinerlei Begründungen von Dir oder sonst jemanden verlangt warum was wie usw. gemacht wurde. Also fühl Dich doch nicht angegriffen bitteschön!
Der Nero fragte was und ich gab ihm meine Antwort. Ist doch nicht schlimm oder?

Apache: Allerdings ein Argument wie "Millionen Fliegen können nicht irren, Sch... muss gut sein" ist meiner Meinung nach kein tolles Argument.
Gerade nicht so bekannte Produkte können eine umso bessere und qualifiziertere Community haben weil nicht 'jeder' glaubt er ist der Guru und mitreden will.

Zum Mailserver hatte ich übrigens Nero angeboten eine fix-fertige Konfiguration zur Verfügung zu stellen. Mehrere Tage zum konfigurieren wäre Euch vielleicht erspart geblieben...

Prefork: Na doch genau was ich meinte.

caching: Eben Debian, aber gottseidank kann man es sich noch selbst kompilieren.

Aber wie schon einmal geschrieben, ohne direkt am System etwas zu sehen ist es relativ schwer Aussagen so in der Raum zu stellen die genau passen. Das ist eher ein Raten, Abfragen und Tipp geben. Was ich auf keinen Fall will, ist jemanden ans Bein pinkeln oder besserwisserisch da stehen. Ich handelte in gutem Glauben und Griff die Fragen von Nero auf.

nichts für ungut
__tom
 
Was ich auf keinen Fall will, ist jemanden ans Bein pinkeln oder besserwisserisch da stehen. Ich handelte in gutem Glauben und Griff die Fragen von Nero auf.
...und genau dafür sind wir sehr dankbar :D Ich denke auch nicht, dass D'Espice sich in irgend einer Weise angegriffen fühlte (und ich weiß ehrlich gesagt auch nicht, woran man das festmachen könnte *noahnung*) Er hat lediglich unseren Standpunkt zum Thema exotische Lösungen auf dem P3D-Webserver dargelegt. Wenn man diskutiert, treffen logischerweise verschiedene Meinungen aufeinander. Im Endeffekt müssen wir aber eine Entscheidung für oder wider die ein oder andere Lösung treffen und selbstredend bleibt dabei die andere auf der Strecke. Das bedeutet aber nicht, dass wir diese Diskussion nicht wollen. Im Gegenteil: viele Anregungen und Verbesserungsvorschläge sind erst in diesem Thread entstanden.

PS: sie haben Post ;)
 
Zum Mailserver hatte ich übrigens Nero angeboten eine fix-fertige Konfiguration zur Verfügung zu stellen. Mehrere Tage zum konfigurieren wäre Euch vielleicht erspart geblieben...

...

Aber wie schon einmal geschrieben, ohne direkt am System etwas zu sehen ist es relativ schwer Aussagen so in der Raum zu stellen die genau passen. Das ist eher ein Raten, Abfragen und Tipp geben. Was ich auf keinen Fall will, ist jemanden ans Bein pinkeln oder besserwisserisch da stehen. Ich handelte in gutem Glauben und Griff die Fragen von Nero auf.

Irgendwie widersprechen sich da zwei Aussagen in meinen Augen. *buck*
 
Umm... ich fühl mich überhaupt nicht angegriffen und das war auch nicht als Verteidigung aufzufassen. Eigentlich wollte ich lediglich unsere Position darstellen und aufzeigen, wie weit wir sind, wie weit wir vorankommen und was an Arbeit bereits alles erledigt ist, bzw. noch ansteht. Ich wollte hier niemanden persönlich oder auch nicht persönlich angreifen, sollte dieser Eindruck entstanden sein bitte ich das zu entschuldigen ;)

Zum Thema Apache:
Ich drück's mal so aus: Ich will an dieser Stelle nicht anzweifeln, dass lighttpd besser ist als Apache. Ebenso wenig kann ich behaupten, dass lighttpd schlechter ist als Apache. Aber ich weiß eines: Apache ist Standard, alles ist darauf zugeschnitten. Apache ist bewährt und beliebt und das bestimmt nicht ohne Grund. Und Apache ist bekannt stabil und zuverlässig. Über lighttpd kann ich keinen der drei Punkte anführen da mir das Programm bis gestern spät nachts noch nicht einmal bekannt war. Ergo kann ich weder Partei dafür noch dagegen ergreifen, was ich jedoch machen kann ist Partei für Apache ergreifen - denn damit kenne ich mich aus, das hab ich schon öfters konfiguriert und von dessen Stabilität, Zuverlässigkeit und Performance konnte ich mich schon desöfteren persönlich überzeugen.
Mag vielleicht sein dass lighttpd dem Indianer in allen Belangen überlegen ist. Mag sein, dass es in einigen Belangen überlegen ist. Mag sein, dass es auf breiter Front unterlegen ist. Aber ein Webserver im Betrieb, der täglich zuverlässig mehrere Tausend Anfragen bearbeiten muss (die genauen Zahlen kann euch sicherlich Nero sagen) ist weiß Gott nicht der richtige Ort um sich auf Experimente einzulassen, das wirst du hoffentlich verstehen ;)

Zum Thema Debian und selber compilieren:
Mir scheint, du scheinst auf Debian nicht besonders gut zu sprechen zu sein. Persönliche Einstellung, sei dir gegönnt. Aber es wird schon einen Grund haben warum php_caching nicht in Sarge mit dabei ist. Den weiß weder ich noch du, aber irgendeinen Grund wird es schon geben ;)
Und zum selber kompilieren, da bin ich wie gesagt sehr vorsichtig und skeptisch, denn sollte ein Problem auftreten mit dem kompilierten Modul könnte es Schwierigkeiten geben. Nicht nur im Betrieb sondern insbesondere bei Updates oder sicherheitsrelevanten Updates. Da ist uns der Debian-Pfad doch deutlich lieber, Nero kann euch ein Lied davon singen wie kompliziert Serverwartung wird wenn man eigens gestrickte Lösungen verwendet. Wir fahren diesmal die Standardlösung, sie mag zwar ein paar Prozent an Leistung kosten - aber erstens merkt das hier niemand und zweitens sparen wir uns eine Menge Zeit, Ärger und graue Haare.
 
Zuletzt bearbeitet:
Aber es wird schon einen Grund haben warum php_caching nicht in Sarge mit dabei ist. Den weiß weder ich noch du, aber irgendeinen Grund wird es schon geben ;)
Oh, den weiss ich zufällig von eaccelerator, die Lizenz von eaccelerator ist debian nicht 'frei' genug. Wir kennen die religiosen Diskussionen darüber. ;)

Es gibt aber auf der eaccelerator Seite etliche angeführte Projekte die beispielhaft angeführt sind und unter Debian auch sehr gut funktionieren.
Weshalb es mich positiv stimmt das eaccelerator auch leicht auf Debian zu kompilieren ist.
( configure; make; make install)

lg
__tom
 
Oh, den weiss ich zufällig von eaccelerator, die Lizenz von eaccelerator ist debian nicht 'frei' genug. Wir kennen die religiosen Diskussionen darüber. ;)

Es gibt aber auf der eaccelerator Seite etliche angeführte Projekte die beispielhaft angeführt sind und unter Debian auch sehr gut funktionieren.
Weshalb es mich positiv stimmt das eaccelerator auch leicht auf Debian zu kompilieren ist.
( configure; make; make install)

lg
__tom
Den religiösen Grabenkrieg kenn ich zur Genüge... echt peinlich manchmal.
Ich werd mir das anschauen aber wie gesagt, beim selber kompilieren bin ich extrem zurückhaltend und vorsichtig geworden, denn das bedeutet einen Mehraufwand an Administration der in den meisten Fällen in keinem Verhältnis steht zur gewonnenen Leistung oder Funktionsumfang.
 
Zurück
Oben Unten