Locale für den Server insgesamt festlegen

SolarCatcher

Well-Known Member
Ich migriere gerade ein altes Typo3 von einem alten Suse-Server nach FreeBSD. Ich stoße auf ein Problem, das vermutlich mit Sonderzeichen zu tun hat. Daher will ich versuchen, die Locale erstmal so zu setzen, wie auf dem Ursprungsserver.

Der Ursprungs-Webserver sieht sie so (ausgelesen über phpshell):
Code:
$ locale
LANG=de_DE.UTF-8
LC_CTYPE="POSIX"
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=POSIX

Das gleiche auf meinem FreeBSD 11-Rechner:
Code:
$ locale
LANG=
LC_CTYPE="C"
LC_COLLATE="C"
LC_TIME="C"
LC_NUMERIC="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_ALL=

Ich finde im Handbuch nur Infos über Login-Shells etc. Ich hätte erwartet, dass man das aber auch generell über die /etc/rc.conf (oder so ähnlich) konfigurieren kann - finde ich aber nicht. Weiß jemand, wie ich es schaffe, dass der Webserver die Locales so sieht wie auf dem Suse-Server?
 
Sowas legt man pro Benutzerklasse in /etc/login.conf fest. Und dokumentiert ist L18N/I18N hier im Handbuch.

Jedoch würde ich davon abraten ein anderes Locale als "C" für root zu nehmen, da man damit auch u.U. World und Ports baut und Systemskripte ausführt.
 
Und aufpassen nichts zu übersehen. :)

Es gibt aber auch diverse Sachen, die Defaultconfigs oder einfach eigene Configs haben können. Postgres zum Beispiel. Beim Debuggen kann auch procstat -e behilflich sein um nachzusehen ob nicht vielleicht irgendwo Umgebungsvariablen überschrieben werden.

Ansonsten stimme ich zu. root generell so zu belassen wie es ist und wenn du was ändern willst einfach einen anderen privilegierten User nutzen kann jede Menge Ärger ersparen. Auch wenn's mal was kritischeres geben sollte, wo der Server Probleme hat will man sich keinesfalls auch noch mit Dingen wie locales, Shells aus den Ports oder ähnlichem rumschlagen müssen.

Wenn es absolut sein muss und du's nicht wirklich ändern kannst setze es explizit für den Prozess. Kann generell gut sein bei LOCALEs explizit vorzugehen, weil man potentiell Seiteneffekte reinbekommt, wenn irgendwas beginnt das zu unterstützen und dann irgendwas Timestamps in einem anderen Format parsen will.

Ist zwar dann meist miese Software, aber das kann man sich nicht immer aussuchen. Kurzum: Zum Testen oder für Systeme/Software eher Explizit (Pro Prozess/User), wenn es passt und gewünscht ist generell.

Wenn du mit Sonderzeichen kämpfst reicht meist das Umstellen des Charsets auf UTF-8 zum Beispiel, wenn du das eingrenzen magst.

Mein Vorschlag wäre die Locales mal als Umgebungsvariablen für in der Kommandozeile für die aktuelle Shell-Session zu setzen und den Prozess so starten. Dann siehst du gleich ob's grundsätzlich klappt. :)

EDIT: Bzw. im rc-Skript von Typo 3 oder je nachdem wo der Fehler ist in der Datenbank.
 
Danke für Eure Erläuterungen!

Am Ende stellte sich allerdings heraus, dass es mit den Umlauten gar nix zu tun hatte - nur manifestierte sich der Fehler exakt so, wie div. im Netz es beschrieben, wenn sich Typo3 an Umlauten verschluckt.
 
Ansonsten stimme ich zu. root generell so zu belassen wie es ist und wenn du was ändern willst einfach einen anderen privilegierten User nutzen kann jede Menge Ärger ersparen. Auch wenn's mal was kritischeres geben sollte, wo der Server Probleme hat will man sich keinesfalls auch noch mit Dingen wie locales, Shells aus den Ports oder ähnlichem rumschlagen müssen.
Für Notfälle gibt es doch auch den Nutzer "toor" :) Der bekommt bei mir z.B. keine Bash zugewiesen.
 
Ich fahre schon seit Ewigkeiten mit login.conf default auf de_DE.UTF8 und hatte damit noch nie Probleme. Ports werden eh in einer separaten Jail über poudriere gebaut.

Würde mich aber interessieren welcher Port nicht korrekt baut oder funktioniert, wenn man ihn mit UTF8 locale kompiliert.
 
Für Notfälle gibt es doch auch den Nutzer "toor" :) Der bekommt bei mir z.B. keine Bash zugewiesen.
Im Server-Betrieb einen Notfall zu haben und auf toor zurückfallen kann Situationen noch um noch ein Stück unangenehmer machen.

Wenn man einfachen physikalischen Zugriff hat und/oder es kein Server ist sind solche Themen ziemlich hinfällig. Aber in den Single User Mode gehen zu müssen, weil die Bash nach einem Update meckert oder man irgendwo mit Locales ein Problem hat ist ein grausiges Problem, das man vermeiden kann.

Ich mach mir wenn ich solche Dinge tu meist noch einen operator user, der eben noch etwas weniger darf als root. Ist aber auch eine Sache des Anwendungsfalls.

Das mit den Locales und Paketbau interessiert mich auch, wobei das eh Poudriere macht, was ziemlich sicher nicht extra die locale des Host-System-root rausfinden versucht.
 
Würde mich aber interessieren welcher Port nicht korrekt baut oder funktioniert, wenn man ihn mit UTF8 locale kompiliert.

Der Fehler, der mich stundenlang aufgehalten hat (in einem configure in Ports) war im Kommando: tr 'a-z' 'A-Z'. Korrektes Locale hat früher mal gesehen, dass im Deutschen zwischen s und t noch ein ß ist, aber zwischen S und T ist ein SS (korrekte Grammatikregel!). Ergebnis war, dass im Port alle Buchstaben ab t um eine Stelle verschoben waren. Und das obige tr hat jemand auf #defines im Code angewendet. Kannst Dir vorstellen, wo ich hin absteigen musste, damit ich das alles verstehe.

Jetzt ist das Locale de_DE übrigens "richtig" im Sinne von "kompatibel". Es ist aber falsch im Sinne der Collation und der Grammatik, natürlich. Es gibt nun auch Inkonsistenzen zwischen sort und tr. Dieser Zustand reicht mit, um die Finger von de_DE zu lassen. Abgesehen davon, dass ich zum Beispiel fast alle Entwicklerwerkzeuge lieber in Englisch haben möchte.
 
Ah. Das macht Sinn. Cool zu wissen. Danke! :)

Aber ja, irgendwo Dinge reproducible zu haben macht generell Sinn. Macht's schwieriger der Erste mit einem Bug zu sein, weil man mit jeder Änderung, die nicht wie mit Options explizit ist man sich ein Stück weiter von dem was die Anderen auch im Betrieb testen entfernt.

Wobei's wohl echt am Desktop nicht allzu viel machen würde, aber am Server will man halt eher alles verhindern, was root weniger brauchbar macht. Mal abgesehen davon, dass Sachen unter root laufen zu lassen vielleicht nicht immer so eine gut Idee ist.
 
Zurück
Oben