Diskussionsthread zur Konfiguration von sarge-amd64
- Ersteller Nero24
- Erstellt am
Was die ganze Administration angeht, würde ich folgendes vorschlagen.
Nach außen offen ist nur das, was wirklich offen sein muss (sprich http, mail).
Dazu läuft eine VPN-Lösung, entweder über ipsec oder openvpn, um sich in ein internes Netz einzuklinken.
Alles, was administrativ genutzt werden soll, ist nur über dieses interne Netz zu erreichen (mit Ausnahme von ssh vielleicht, damit man sich nicht aus Versehen selber aussperrt).
Darüber kann man dann auch ftp usw. ohne Bedenken nutzen. openvpn und ipsec sind auch unter windows gut unterstützt, so dass die Admins mit Windows da keine Probleme haben sollten.
X509-Zertifikate für alle zu erstellen, die in das lokale Netz reindürfen, ist kein Problem. Und selbst wenn man dann in dem Netz drin ist braucht man ja immer noch die login-Daten, um sich auf dem Server einzuloggen.
Wenn es gewünscht ist kann ich da auch mal eine konkretere Lösung skizzieren und hier posten.
Nach außen offen ist nur das, was wirklich offen sein muss (sprich http, mail).
Dazu läuft eine VPN-Lösung, entweder über ipsec oder openvpn, um sich in ein internes Netz einzuklinken.
Alles, was administrativ genutzt werden soll, ist nur über dieses interne Netz zu erreichen (mit Ausnahme von ssh vielleicht, damit man sich nicht aus Versehen selber aussperrt).
Darüber kann man dann auch ftp usw. ohne Bedenken nutzen. openvpn und ipsec sind auch unter windows gut unterstützt, so dass die Admins mit Windows da keine Probleme haben sollten.
X509-Zertifikate für alle zu erstellen, die in das lokale Netz reindürfen, ist kein Problem. Und selbst wenn man dann in dem Netz drin ist braucht man ja immer noch die login-Daten, um sich auf dem Server einzuloggen.
Wenn es gewünscht ist kann ich da auch mal eine konkretere Lösung skizzieren und hier posten.
Also du empfiehlst ssh durch Portknocking zu schützen und willst gleichzeitig Webmin einsetzen.
Webmin ist eine der größten Sicherheitslücken überhaupt. Außerdem will ich doch gerne selbst wissen welche Einträge in welcher config gemacht werden.
Anstatt Portknocking reicht es imho aus einen root-Login via ssh zu unterbinden, (denn der ist default erlaubt, PermitRootLogin auf no) und den Login via Username: Password abzuschalten (UsePAM auf no setzen) und nur noch Logins mit ssh-keys (rsa oder dsa) zu gestatten. Somit laufen sämtliche Passwortattacken, die ich täglich dutzendfach auf den ssh Login habe ins Leere.
cu(lix)
Tom24
Grand Admiral Special
- Mitglied seit
- 14.01.2001
- Beiträge
- 5.401
- Renomée
- 7
...unter jedem BSD per default verboten.
Das Portknocking ist genauso toll wie, auf ICMP nicht anworten, gefaehrdet im Grunde nur wichtige Funktionalitaet und bringt nichts weiter als Verschleierung, weniger Sicherheit.
Etwas anderes waere IMHO nicht besonders klug. Generell wird RSA empfohlen, weil die Sicherheit von DSA stark von der Implementation, genauer dem Zufallsgenerator, abhaengt.
Ein anderer Vorteil ist, dass man IP Adressen von denen Loginversuche mit Passwort kommen, da gibt es ja viele Bots und Zombiehosts, sofort aussperren kann, hab da mal so kleines Tool geschrieben.
Jetzt erstmal Spaß beiseite und zu wichtigeren Themen.
Wie gesagt, BSD gibt es nicht, ich hätte auch lieber ein gentoo gesehen, aber solche Gespräche gehen jetzt daran vorbei. Mit Linux kennen sich einfach mehr aus und es ist auch von der Geschwindigkeit mindestens genausogut, wenn nicht noch schneller (habe letztens mal einen Vergleich von fefe gesehen, da ist linux 2.6 fast überall die Nr. 1 gewesen, war aber schon etwas älter, der Vergleich)
Man sollte erstmal top-down vorgehen:
Anforderungen anschauen, welche Programme erfüllen das wie gut, welche Versionen der Programme, allgemeine Konzepte usw.
Diese Details sollte man dann vielleicht später aufsplitten in Betriebssystem-Konfiguration (inkl. Sicherheit), http-Server-Konfiguration, datenbank-Konfiguration usw.
Vielleicht baut da mal jemand ein Basiskonzept auf und das kann dann diskutiert und verfeinert werden (und da soll nicht rein, welche Version von vim oder emacs da drauf soll
)
(btw: Portknocking würde ich auch nicht empfehlen - das täuscht nur falsche Sicherheit vor - ich bevorzuge einen VPN-Ansatz)
Wie gesagt, BSD gibt es nicht, ich hätte auch lieber ein gentoo gesehen, aber solche Gespräche gehen jetzt daran vorbei. Mit Linux kennen sich einfach mehr aus und es ist auch von der Geschwindigkeit mindestens genausogut, wenn nicht noch schneller (habe letztens mal einen Vergleich von fefe gesehen, da ist linux 2.6 fast überall die Nr. 1 gewesen, war aber schon etwas älter, der Vergleich)
Man sollte erstmal top-down vorgehen:
Anforderungen anschauen, welche Programme erfüllen das wie gut, welche Versionen der Programme, allgemeine Konzepte usw.
Diese Details sollte man dann vielleicht später aufsplitten in Betriebssystem-Konfiguration (inkl. Sicherheit), http-Server-Konfiguration, datenbank-Konfiguration usw.
Vielleicht baut da mal jemand ein Basiskonzept auf und das kann dann diskutiert und verfeinert werden (und da soll nicht rein, welche Version von vim oder emacs da drauf soll
)(btw: Portknocking würde ich auch nicht empfehlen - das täuscht nur falsche Sicherheit vor - ich bevorzuge einen VPN-Ansatz)
feelx
Grand Admiral Special
Zu Webmin sage ich nichts mehr - ich habe bereits selbst erwähnt, dass ich es, wenn überhaupt schützen würde. Wenn es geschützt ist (und zwar mehrfach - durch Konfiguration von Webmin selbst und durch entsprechende Einstellungen im apache und eben durch Portknocking), dann sind die risiken nicht so gross, wie hier behauptet wird - Aber egal...
@Tom24: Du hast recht - in erster Linie ist Portknocking eine Art Verschleierung (oder eben "Obscurity" ). Und natürlich - auch das habe ich mehrfach geschrieben - ersetzt es nicht die sonst üblichen Vorkehrungen zu treffen, entsprechende Daemons zu schützen. Die Diskussion wird mir langsam zu mühsam, denn (ich wiederhole mich) - niemand würde sein Haus nicht mehr abschliessen, nur weil er eine Alarmanlage hat. Aber umgekehrt: Jemand der sein Haus immer abschliesst, dem bringt eine Alarmanlage möglicherweise zusätzliche Sicherheit. Im Falle von Portknocking hält es eben beispielsweise zusätzliche Diebe ab, die auf einen "schnellen Bruch" aus sind.
Aber was rede ich da ... über dieses Thema diskutieren ganz andere Leute als wir hier sind. Und natürlich gibt's da mehrere Meinungen - Lest den Artikel von Bastille-Linux (speziell Tom24 )
"The most misunderstood statement in the computer security field has got to be "security through obscurity is bad." As security professionals, many of us try to teach a few simple lessons to help system administrators become more security-conscious. Unfortunately, the simplicity of our lessons has backfired. In this article, I'll talk about how obscurity can aid security -- hopefully, I can clear up some of this confusion." .... [mehr]
Was Portknocking betrifft - bin ich der Meinung, dass es eine Technik ist, die einen hervorragenden zusätzlichen Schutz bietet und zudem in ca. 5 Minuten implementiert ist. Weshalb also darauf zu verzichten? Wer würde eine einfach installierende und kostenlose Alarmanlage zu Hause ausschlagen, wenn sie keinesfalls zusätzliche Risiken birgt und auf einer anderen Ebene als die üblichen Vorkehrungsweisen aber zusätzlichen Schutz birgt? Oder wer glaubt, dass man im Auto auf Gurten verzichten kann, nur weil man einen Airbag hat
Die Diskussion scheint mir ehrlich gesagt auf dieselbe Art und Weise widersinnig und weltfremd, wie das Argument auf Portknocking zu verzichten, weil es Sicherheit vortäusche - natürlich reicht das alleine nicht aus... aber wer hat das denn behauptet?
PS:; noch was: Selbstverständlich ist ein permitRootLogin auch bei jedem Debian-System per default verboten. Wobei egal wie euer ssh geschützt wird - euer Schutz setzt immer voraus, dass er nicht bereits im daemon selbst durch Ausnützen einer Lücke ausgehebelt werden kann. Somit täuscht imho das eher falsche Sicherheit vor, egal wieviele Passwörter rsa-Schlüssel, Zertifikate etc. ihr aufstellt. Und da ist eben ein zusätzliches Portknocking überlegen, weil der Schutz auf einer völlig unabhängigen Ebene läuft. In Kombination beider Möglichkeiten wird die Sicherheit maximiert. Das betrifft auch VPN - Die Kombination auf verschiedenen Ebenen ist nicht zu übertreffen. Vgl. Sicherheit im Auto: Gute Bremsen und Airbag einerseits - aber umsichtiges Fahren und anschnallen andererseits...
@Tom24: Du hast recht - in erster Linie ist Portknocking eine Art Verschleierung (oder eben "Obscurity" ). Und natürlich - auch das habe ich mehrfach geschrieben - ersetzt es nicht die sonst üblichen Vorkehrungen zu treffen, entsprechende Daemons zu schützen. Die Diskussion wird mir langsam zu mühsam, denn (ich wiederhole mich) - niemand würde sein Haus nicht mehr abschliessen, nur weil er eine Alarmanlage hat. Aber umgekehrt: Jemand der sein Haus immer abschliesst, dem bringt eine Alarmanlage möglicherweise zusätzliche Sicherheit. Im Falle von Portknocking hält es eben beispielsweise zusätzliche Diebe ab, die auf einen "schnellen Bruch" aus sind.
Aber was rede ich da ... über dieses Thema diskutieren ganz andere Leute als wir hier sind. Und natürlich gibt's da mehrere Meinungen - Lest den Artikel von Bastille-Linux (speziell Tom24
)"The most misunderstood statement in the computer security field has got to be "security through obscurity is bad." As security professionals, many of us try to teach a few simple lessons to help system administrators become more security-conscious. Unfortunately, the simplicity of our lessons has backfired. In this article, I'll talk about how obscurity can aid security -- hopefully, I can clear up some of this confusion." .... [mehr]
Was Portknocking betrifft - bin ich der Meinung, dass es eine Technik ist, die einen hervorragenden zusätzlichen Schutz bietet und zudem in ca. 5 Minuten implementiert ist. Weshalb also darauf zu verzichten? Wer würde eine einfach installierende und kostenlose Alarmanlage zu Hause ausschlagen, wenn sie keinesfalls zusätzliche Risiken birgt und auf einer anderen Ebene als die üblichen Vorkehrungsweisen aber zusätzlichen Schutz birgt? Oder wer glaubt, dass man im Auto auf Gurten verzichten kann, nur weil man einen Airbag hat
Die Diskussion scheint mir ehrlich gesagt auf dieselbe Art und Weise widersinnig und weltfremd, wie das Argument auf Portknocking zu verzichten, weil es Sicherheit vortäusche - natürlich reicht das alleine nicht aus... aber wer hat das denn behauptet?PS:; noch was: Selbstverständlich ist ein permitRootLogin auch bei jedem Debian-System per default verboten. Wobei egal wie euer ssh geschützt wird - euer Schutz setzt immer voraus, dass er nicht bereits im daemon selbst durch Ausnützen einer Lücke ausgehebelt werden kann. Somit täuscht imho das eher falsche Sicherheit vor, egal wieviele Passwörter rsa-Schlüssel, Zertifikate etc. ihr aufstellt. Und da ist eben ein zusätzliches Portknocking überlegen, weil der Schutz auf einer völlig unabhängigen Ebene läuft. In Kombination beider Möglichkeiten wird die Sicherheit maximiert. Das betrifft auch VPN - Die Kombination auf verschiedenen Ebenen ist nicht zu übertreffen. Vgl. Sicherheit im Auto: Gute Bremsen und Airbag einerseits - aber umsichtiges Fahren und anschnallen andererseits...
Zuletzt bearbeitet:
Es wäre mit Sicherheit auch interessant, wenn ihr auf dem Server mal
rrdtool
einsetzen würdet, um die Belastung des Systems (CPU, RAM, HDD, Temps, User u. Prozesse, ...) grafisch zu ermessen.
Lasse auf meinem kleinen Serverchen auch diverse Graphen zeichnen, die mir u.A. auch schon mal verraten haben, dass ich vergessen habe ein NFS-Verzeichnis zu unmounten (ca. 10% mehr Load, da er versucht hat die Verbindung wieder herzustellen).
Die meissten Graphen lasse ich alle 3 Minuten aktualisieren - das erzeugt schätzungsweise 1-5 % (max.) CPU-Last auf die Dauer gesehen, zumindest auf meinem System, was allerdings ein recht altes ist. Denke mal, die zusätzliche Last ist vorerst zu vernachlässigen.
Die Ergebnisse kann man schön als PNG-File ausgeben und in eine HTML-Seite einarbeiten - sicherlich auch für die User hier interessant.
Wenn ihr Konfigurationshilfen benötigt, kann ich euch auch gerne mal meine Konfigurationsscripts geben (Die Farben lassen sich auch schön im P3D-Style anpassen
)
Gruß,
MFR2000
rrdtool
einsetzen würdet, um die Belastung des Systems (CPU, RAM, HDD, Temps, User u. Prozesse, ...) grafisch zu ermessen.
Lasse auf meinem kleinen Serverchen auch diverse Graphen zeichnen, die mir u.A. auch schon mal verraten haben, dass ich vergessen habe ein NFS-Verzeichnis zu unmounten (ca. 10% mehr Load, da er versucht hat die Verbindung wieder herzustellen).
Die meissten Graphen lasse ich alle 3 Minuten aktualisieren - das erzeugt schätzungsweise 1-5 % (max.) CPU-Last auf die Dauer gesehen, zumindest auf meinem System, was allerdings ein recht altes ist. Denke mal, die zusätzliche Last ist vorerst zu vernachlässigen.
Die Ergebnisse kann man schön als PNG-File ausgeben und in eine HTML-Seite einarbeiten - sicherlich auch für die User hier interessant.
Wenn ihr Konfigurationshilfen benötigt, kann ich euch auch gerne mal meine Konfigurationsscripts geben (Die Farben lassen sich auch schön im P3D-Style anpassen
)Gruß,
MFR2000
Zuletzt bearbeitet:
Tom24
Grand Admiral Special
- Mitglied seit
- 14.01.2001
- Beiträge
- 5.401
- Renomée
- 7
Hey feelx,
hast ja ne Menge geschrieben, verstehe dich auch, jedoch hab ich da noch ein paar Sachen im Hinterkopf die es zu beachten gilt, wenn man mit etablierten Verfahren experimentiert. Ich merke allerdings auch, dass wir uns hier im Kreis drehen, ich versuch mal ein bischen forsch zu sein.
...here it goes.
Zusaetzlich sollte man dort jede Aendernung der Konfiguration mitloggen.
Thema Portknocking
Ich hab deinen verlinkten Text gelesen und moechte ein paar Einwaende zum Portknocking einwerfen.
Sofern ich das richtig verstanden hab, laeuft der TCP Handshake bei Portknocking nichtmehr wie in RFC793 ab (syn, syn ack, syn) sondern syn, ack. Ganz spontan kommen mir da ein paar die ueblichen Bedenken, wenn man mit etablierten Standards rumspielt, in den Kopf.
Sie widmet sich einem ganz aehnlichen Thema.
Ist ein Paper von Richard van den Berg und Phil Dibowitz - Proceedings of LISA ’02 (Usenix).
Titel: Over-Zealous Security Administrators Are Breaking the Internet
http://tom.ruegen-grafik.de/files/docs/vanderberg.pdf
hast ja ne Menge geschrieben, verstehe dich auch, jedoch hab ich da noch ein paar Sachen im Hinterkopf die es zu beachten gilt, wenn man mit etablierten Verfahren experimentiert. Ich merke allerdings auch, dass wir uns hier im Kreis drehen, ich versuch mal ein bischen forsch zu sein.
...here it goes.
Webmin ist schon ein heisses Eisen und ich wuerde es schon als besonders gefaehrlich einstufen, weil alle Prozesse von webmin als root laufen, jedoch neige ich dazu es hin und wieder bereitzustellen, sofern der webmin-webserver ausschlieslich auf dem loopback Interface lauscht und man daher nur ueber einen ssh-Tunnel Zugang bekommt und ueber kein anderes Interface.
Zusaetzlich sollte man dort jede Aendernung der Konfiguration mitloggen.
Thema Portknocking
Ich hab deinen verlinkten Text gelesen und moechte ein paar Einwaende zum Portknocking einwerfen.
Sofern ich das richtig verstanden hab, laeuft der TCP Handshake bei Portknocking nichtmehr wie in RFC793 ab (syn, syn ack, syn) sondern syn, ack. Ganz spontan kommen mir da ein paar die ueblichen Bedenken, wenn man mit etablierten Standards rumspielt, in den Kopf.
- Man bricht einen Standard, ueber die Konsequenzen muss man sich bewusst sein, das gilt insbesondere fuer die Clients (welche kann ich jetzt noch benutzen? usw.)
- Wie finden das die Router dazwischen wenn dort staendig Verbindungen etabliert werden, die nicht vernuenftig ausgehandelt wurden? Sind unterwegs Geraete anzutreffen die das nicht so leicht nehmen? IMHO ein unkontrollierbar hohes Risiko.
- Stateful Inspection Firewalls werden bei sowas aufmerksam, und wenn man Pech hat, muss man Firewallregeln anpassen und spaet. dort hoert der Spass auf, weil exaktes Matching nichtmehr stattfinden kann.
Sie widmet sich einem ganz aehnlichen Thema.Ist ein Paper von Richard van den Berg und Phil Dibowitz - Proceedings of LISA ’02 (Usenix).
Titel: Over-Zealous Security Administrators Are Breaking the Internet
http://tom.ruegen-grafik.de/files/docs/vanderberg.pdf
Muss neu sein und ich bestreite das mal pauschal, kontrolliere aber mal mit einer sarge cd, sofern ich eine in die Finger bekomme.
Bei Debian Sarge stable 3.1 (frische Installation) ist die Option auf "yes", also nicht verboten:
Code:
PermitRootLogin yesJetzt mal zu den einzelnen Komponenten:
Ich empfehle:
Nero - kannst du mal noch schreiben, auf was du speziell noch Wert legst - was es noch zu klären gibt und wie die Planungen aussehen.
Ich empfehle:
- apache2
- mysql ist ja gesetzt, bei den Versionen 4.x oder 5.0 weiß ich nicht, was die Anforderungen sind und wie groß der Unterschied ist (ich halte ja postgresql hoch) - generell würde ich die aktuelle 5.0 nehmen
- PHP 5.x
- FTP - ich empfehle vsftpd: klein, schnell, sicher
- Zur Sicherung der managementports (ssh, ggf. ftp, usw.) empfehle ich ein VPN - mit OpenVPN oder IPSEC - damit erübrigt sich die Nebendiskussion über Portknocking und ssh-Standardeinstellungen (nur gut, dass man die Standardeinstellungen nicht ändern kann, oder )
Nero - kannst du mal noch schreiben, auf was du speziell noch Wert legst - was es noch zu klären gibt und wie die Planungen aussehen.
PuckPoltergeist
Grand Admiral Special
Um mal nochwas zu einem grundlegenden Detail zu sagen: Als Dateisystem würde ich euch XFS empfehlen. Ist sehr schnell, stabil, hat einen umfassenden Satz an Werkzeugen und gehört mit zu den ältesten und damit erprobtesten Dateisystemen. Solltet ihr euch dagegen entscheiden, wäre der nächste Kandidat aus meiner Sicht ext3. Zu Reiser solltet ihr aber auf keinen Fall greifen.
- Mitglied seit
- 01.07.2000
- Beiträge
- 24.058
- Renomée
- 10.440
Nachdem nun eigentlich alles läuft außer dem E-Mail Server wollte ich - nachdem ich inzwischen einiges darüber gelesen habe - XMail auf dem Server installieren. Nach Debian-Manier wollte ich das über apt-get machen. Allerdings erhalte ich nun auf einmal folgende Fehlermeldung:
Hab auch schon probiert mit dpkg-reconfigure localeconf manuell auf ISO-8859-15 oder ISO-8859-1 zu schalten. Aber immer wieder die gleiche Fehlermeldung. localeconf ist installiert und mit dpkg-reconfigure locales erreiche ich gar nichts.
Mit Google finde ich massenhaft solche Probleme mit Debian, allerdings keine wirklich hilfreichen Posts. Die meisten schreiben "irgendwann ging es dann wieder"
Aber das kann ja nicht die Lösung sein.
Kann mir jemand helfen?
Hab auch schon probiert mit dpkg-reconfigure localeconf manuell auf ISO-8859-15 oder ISO-8859-1 zu schalten. Aber immer wieder die gleiche Fehlermeldung. localeconf ist installiert und mit dpkg-reconfigure locales erreiche ich gar nichts.
Mit Google finde ich massenhaft solche Probleme mit Debian, allerdings keine wirklich hilfreichen Posts. Die meisten schreiben "irgendwann ging es dann wieder"
Aber das kann ja nicht die Lösung sein.Kann mir jemand helfen?
Tom24
Grand Admiral Special
- Mitglied seit
- 14.01.2001
- Beiträge
- 5.401
- Renomée
- 7
Hallo,
waehrend deine LANGUAGE und LC_ALL Variablen nicht gesetzt sind, ist der Wert von LANG unvollstaendig.
In die /etc/profile, oder bei Debian glaub ich /etc/environment, ich weiss nicht wie's bei Debian da gerade steht.
Das sollte reichen.
Weil bei DragonFly seit einiger Zeit WideCharacter unterstuetzt wird, hab ich meine locales auf UTF8 stehen.
waehrend deine LANGUAGE und LC_ALL Variablen nicht gesetzt sind, ist der Wert von LANG unvollstaendig.
Code:
export LC_ALL=de_DE.ISO-8859-1
export LANGUAGE=de_DEDas sollte reichen.
Weil bei DragonFly seit einiger Zeit WideCharacter unterstuetzt wird, hab ich meine locales auf UTF8 stehen.
Code:
export LANG=de_DE.UTF-8
export LC_ALL=de_DE.UTF-8
export LANGUAGE=de_DEPuckPoltergeist
Grand Admiral Special
LC_ALL sollte man auf keinen Fall setzen. Da kommen einige Programme bei durcheinander.
- Mitglied seit
- 01.07.2000
- Beiträge
- 24.058
- Renomée
- 10.440
Hi,
vielen Dank - aber sooo einfach ist es leider nicht Das hab ich schon probiert. Bei Debian heißt die Datei in der Tat environment und liegt in /etc. Aber egal was ich dort eintrage, Debian beschwert sich immer "cannot set BLABLA xy: no such file or directory".
Nach dieser Anleitung
http://www.ubuntuusers.de/viewtopic.php?t=1432
wo es auch um das Problem geht, habe ich auch folgende Werte eingetragen:
LANG=de_DE@euro
LC_CTYPE="de_DE@euro"
LC_NUMERIC="de_DE@euro"
LC_TIME="de_DE@euro"
LC_COLLATE="de_DE@euro"
LC_MONETARY="de_DE@euro"
LC_MESSAGES="de_DE@euro"
LC_PAPER="de_DE@euro"
LC_NAME="de_DE@euro"
LC_ADDRESS="de_DE@euro"
LC_TELEPHONE="de_DE@euro"
LC_MEASUREMENT="de_DE@euro"
LC_IDENTIFICATION="de_DE@euro"
LC_ALL=de_DE@euro
Aber es ist vollkommen egal. Die Fehlermeldungen bleiben
vielen Dank - aber sooo einfach ist es leider nicht
Das hab ich schon probiert. Bei Debian heißt die Datei in der Tat environment und liegt in /etc. Aber egal was ich dort eintrage, Debian beschwert sich immer "cannot set BLABLA xy: no such file or directory".Nach dieser Anleitung
http://www.ubuntuusers.de/viewtopic.php?t=1432
wo es auch um das Problem geht, habe ich auch folgende Werte eingetragen:
LANG=de_DE@euro
LC_CTYPE="de_DE@euro"
LC_NUMERIC="de_DE@euro"
LC_TIME="de_DE@euro"
LC_COLLATE="de_DE@euro"
LC_MONETARY="de_DE@euro"
LC_MESSAGES="de_DE@euro"
LC_PAPER="de_DE@euro"
LC_NAME="de_DE@euro"
LC_ADDRESS="de_DE@euro"
LC_TELEPHONE="de_DE@euro"
LC_MEASUREMENT="de_DE@euro"
LC_IDENTIFICATION="de_DE@euro"
LC_ALL=de_DE@euro
Aber es ist vollkommen egal. Die Fehlermeldungen bleiben
PuckPoltergeist
Grand Admiral Special
Zum einen, wie ich oben schon geschrieben habe, setze LC_ALL nicht, das kann einige Programme aus dem Tritt bringen.
Zum anderen, was passiert, wenn du auf der console "export LANG=de_DE@euro" eingibst? Welche Fehlermeldung spuckt er dir dann aus?
Zum anderen, was passiert, wenn du auf der console "export LANG=de_DE@euro" eingibst? Welche Fehlermeldung spuckt er dir dann aus?
Tom24
Grand Admiral Special
- Mitglied seit
- 14.01.2001
- Beiträge
- 5.401
- Renomée
- 7
Welches Programm kommt bei LC_ALL denn durcheinander?
LC_ALL zwingt doch bloss alle LC_* Variablen auf einen Wert, waehrend LANGUAGE sie setzt wenn eine Variable noch keinen Wert hat. ...IIRC
de_DE@euro ist doch kein vernuenftiger Wert fuer LANG, IMHO benoetigt LANG auch das Charset. Symbolisiert @euro unter Debian ein Charset? Ehrlich gesagt halte ich das fuer unwarscheinlich.
LC_ALL zwingt doch bloss alle LC_* Variablen auf einen Wert, waehrend LANGUAGE sie setzt wenn eine Variable noch keinen Wert hat. ...IIRC
de_DE@euro ist doch kein vernuenftiger Wert fuer LANG, IMHO benoetigt LANG auch das Charset. Symbolisiert @euro unter Debian ein Charset? Ehrlich gesagt halte ich das fuer unwarscheinlich.
PuckPoltergeist
Grand Admiral Special
Welches Programm kommt bei LC_ALL denn durcheinander?
Zum Beispiel scripte, die bestimmte LC-Variablen für sich umdefinieren, z.B. auf C (Posix).
LC_ALL zwingt doch bloss alle LC_* Variablen auf einen Wert, waehrend LANGUAGE sie setzt wenn eine Variable noch keinen Wert hat. ...IIRC
Eben, das Umdefinieren anderer LC-Variablen funktioniert dann nicht mehr, weil LC_ALL die überlagert. Es reicht normalerweise aus, LANG zu setzen, welches dann alle anderen LC-Variablen auch setzt, abgesehen von LC_ALL.
Doch, der steht für latin15, sprich Deutsch mit Euro-Symbol.
Tom24
Grand Admiral Special
- Mitglied seit
- 14.01.2001
- Beiträge
- 5.401
- Renomée
- 7
Klingt irgendwie boese, aber naja, was soll's.
Du meinst sicher latin9?
Ist es sicher, dass Debian das korrekt versteht? Ich wuerde eher ISO-8859-15 im Namen verwenden.
PuckPoltergeist
Grand Admiral Special
Du meinst sicher latin9?
Jupp, ISO-8859-15 bzw. lat9.
Deshalb auch meine Frage, was bei "export LANG=de_DE@euro" passiert. Gentoo versteht das, und Debian meines Wissens nach auch. Ganz sicher bin ich mir da aber nicht. Außerdem ist es auch noch möglich, dass ein notwendiges Paket fehlt.
Ja, Debian versteht de_DE@euro
Just my 2 cents
![:]](https://www.planet3dnow.de/vbulletin/images/smilies/rolleyes.gif "Augen rollen (sarkastisch) :]")
PuckPoltergeist
Grand Admiral Special
Konvention ist
Code:
[language[_territory][.codeset][@modifier]]PuckPoltergeist
Grand Admiral Special
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?
tomturbo
Technische Administration, Dinosaurier
@Nero
mach doch mal:
# locale -a
da siehst Du welche locales bei Dir installiert sind.
Und anschließend reicht, wie PuckPoltergeist schon sagte, ein
# export LANG="de_DE@euro"
wenn's denn das locale -a zeigt.
Das kannst Du dann in /etc/profile oder in /etc/bash/bashrc (je nach Version) /etc/bashrc
eintragen und alle Tools solltens dann verstehen.
lg
mach doch mal:
# locale -a
da siehst Du welche locales bei Dir installiert sind.
Und anschließend reicht, wie PuckPoltergeist schon sagte, ein
# export LANG="de_DE@euro"
wenn's denn das locale -a zeigt.
Das kannst Du dann in /etc/profile oder in /etc/bash/bashrc (je nach Version) /etc/bashrc
eintragen und alle Tools solltens dann verstehen.
lg
Ähnliche Themen
