Dieses Horror-Szenario stellte uns gestern die Tagesschau in Aussicht. Die ICANN wolle ihre Root-Server abschalten, um vom IPv4-Protokoll auf das modernere IPv6-Protokoll umzuschalten. Der Grund: IPv4-Adressen neigen sich dem Ende zu, IPv6-Adressen gäbe es mehr als genug. Der “langsame Wechsel” habe nicht funktioniert, also müsse man zu dieser radikalen Lösung greifen.

Das Ergebnis: weltweites Chaos. Welche Bank arbeitet mit Systemen, die IPv6 komplett unterstützen? Welcher Flughafen wäre auf diese Veränderung eingestellt? Das sind nur zwei Beispiele – von vielen.

Zur Beruhigung: Gestern war der 1. April. Der Artikel war ein – wenn auch gut erarbeiteter – Scherz. Dazu kam es natürlich zu einigen Kommentaren der Leser, wovon die Tagesschau wenige exemplarisch zitiert. Einer davon soll auch hier zitiert werden:

S.M. aus Jena schrieb uns: “Geiles Ding, hab´s echt geglaubt und das, obwohl ich im Nebenfach Informatik studiere. Hab mich zwar gewundert, weil das Internet doch eigentlich dezentral angelegt ist, aber der Artikel war fast schon zu gut recherchiert für einen Aprilscherz.”

Gut, Informatik im Nebenfach ist löblich. Das bedeutet allerdings im Zweifel nur, dass die ersten beiden Vorlesungen des Informatikstudiums belegt werden müssen. Da wird das Internet nicht allzu umfangreich behandelt. Sonst wüsste man wohl, dass dieses zwar dezentral angelegt ist, insbesondere die DNS-Rootserver, um deren Abschaltung es im Artikel ging, dass diese Root-Server zwar von verschiedenen Institutionen betrieben, jedoch von der ICANN koordiniert werden. Wenn die ICANN jetzt also die Möglichkeit (und den Willen) hätte, die 13 Root-Server abzuschalten, die es gibt, so hätten wir ein Problem. Oder?

Welcher Idiot hat sich das denn einfallen lassen? Es müssen lediglich 13 Rechner ausgeschaltet werden, damit das Internet nicht mehr funktioniert?

Nicht ganz. Zunächst handelt es sich zwar um 13 Server, diese bestehen aber insgesamt aus 123 Rechnern, die zu logischen Servern zusammengeschlossen sind. Diese 123 Rechner sind weltweit verteilt und vermutlich nicht jedem Touristen frei zugänglich.

Fällt einer dieser Rechner aus, ist das Internet noch lange nicht lahm gelegt. Natürlich gab es auch schon Angriffe auf dieses System. Der erfolgreichste verhinderte zu 9 der 13 Server einen Verbindungsaufbau – zumindest einen Verbindungsaufbau in normaler Geschwindigkeit. Trotzdem funktionierte das Internet weiter, doch warum?

Zum einen wird bei Root-Servern mit Redundanz gearbeitet. Jeder der 13 Server hält alle Informationen bereit, die auf den übrigen 12 Servern verfügbar sind. Doch einer alleine käme mit der Menge der Anfragen nicht zurecht. Allerdings ist das System so aufgebaut, dass zwei Drittel der Server ausfallen könnten und die übrigen vier bis fünf Server alle Anfragen beantworten könnten.

Zum anderen wird eine DNS-Anfrage nicht direkt vom Benutzer an einen Root-Server geschickt. Vielmehr schickt ein Benutzer die Anfrage an den DNS-Server seines Providers. Dieser erkundigt sich dann, welcher DNS-Server z.B. für die Top-Level-Domain .de zuständig ist. Diese Information gibt es beim Root-Server. Nur ändert sich die Information nicht im Minutentakt. Also speichert der DNS-Server des Providers das Ergebnis dieser Anfrage in seinem Cache. Bei der nächsten Anfrage des Benutzers wird der Root-Server schon nicht mehr gefragt. So wäre selbst ein Tag ohne Root-Server noch kein völliger Untergang des Internts.

Vieles von dem, was gesprochen wird, klingt dabei furchtbar wenig informiert – oder gar desinformiert. So kommt es zu Aussagen wie

Die Rektorin des [Wertinger]Gymnasiums denkt, dass die Türkei durchaus in die Europäische Union beitreten könne, da sie ja ein Land in Europa sei.

Quelle: Augsburger Allgemeine

Ich gebe zu: Wenn eine Blume zu 90 Prozent aus einer Vase heraus steht, behaupte ich trotzdem, sie stünde in der Vase. Dagegen wird beim Fußball ein Tor erst als solches anerkannt, wenn der Ball zu 50 Prozent die Torlinie überquert hat.

Zu den Fakten

• Ein Teil der türkischen Bevölkerung lebt in Europa, ein anderer Teil lebt in Asien. Zu Europa gehören dabei Teile Istanbuls und ein paar kleinere Großstädte. Insgesamt leben dort ca. 9 Millionen Menschen (siehe hier und hier). In der Türkei leben insgesamt etwa 72 Millionen Menschen. Es handelt sich also um ca. 12,5 Prozent der Bevölkerung.
• Man könnte neben der Bevölkerung natürlich auch das Staatsgebiet vergleichen. Da ist das Verhältnis noch ein wenig deutlicher: Nur 3% der Landesfläche des türkischen Staatsgebiets liegen in Europa, also westlich des Bosporus (siehe hier).

Problematisch ist in dem Zusammenhang, das die EU selbst zurzeit noch nicht weiß, ob sie überhaupt geographische Grenzen besitzen will, oder eine Art offenes Projekt sein möchte, dem jeder Beitreten kann, der sich genügend anpasst. Also bleibt die Frage nach dem Beitritt der Türkei zur EU vorläufig unbeantwortet.

Ein aktuelleres Thema sind dagegen die Menschen türkischer Abstammung, die in Deutschland leben. Zum einen muss darüber nicht erst verhandelt werden, zum anderen wird sich daran auch nichts ändern. So wurde also in den letzten Tagen heiß über die Frage diskutiert, ob es in Deutschland türkische Schulen geben soll oder nicht.

Befürworter argumentieren zum einen mit der Existenz deutscher Schulen in der Türkei, zum anderen mit besseren Chancen zur Integration. Gegner bezweifeln genau diese bessere Integration, sagen sogar eine schlechtere Integration voraus (wie die eingangs zitierte Rektorin) und führen an, dass es bereits Schulen in Deutschland gibt, in denen Türkisch unterrichtet wird.

Zeit für noch mehr Fakten

Es gibt laut einer Auflistung www.antalya.de fünf Deutsche Schulen in der Türkei. Die Liste deckt sich mit weiteren Quellen im Internet, so dass eine gewisse Zuverlässigkeit gegeben sein dürfte. Genau handelt es sich dabei um

• die Privatschule der Deutschen Botschaft Ankara, mit einer weiteren Zweigstelle in Ankara und einer Zweigstelle in Izmir
• die Özel Alman Lisesi Deutsche Schule Istanbul (privates Gymnasium mit mathematisch-naturwissenschaftlichen Profil)
• das Gymnasium Istanbul Lisesi

Diese fünf Schulen haben mindestens zwei gemeinsamkeiten:

1. Der Unterricht wird in deutscher Sprache gehalten.
2. Der Besuch der Schule ist nicht kostenlos (bis auf das Gymnasium Istanbul Lisesi).

Es gibt also vier private und eine staatliche deutsche Schule/n in der Türkei.

In Deutschland gibt es dagegen keine türkische Schule. Es gibt Schulen, wo Türkisch gelehrt wird, allerdings werden die anderen Fächer trotzdem in deutscher Sprache unterrichtet.

Pro und Contra

Mit der Existenz der deutschen Schulen in der Türkei zu argumentieren ist schwach. So könnte man auch mit der Existenz ganz anderer Einwanderungsbedingungen in anderen Staaten existieren – ebenso schwach. “Was ihr dürft, müssen wir auch dürfen”, darf also nicht das ausschlaggebende Argument sein. Es bleibt die Integration und die Wahrung der türkischen Kultur.

Die türkische Kultur ist – wie jede fremde Kultur – in erster Linie eine Bereicherung für Deutschland. Die Integration ist gleichzeitig eine Berechtigte Forderung der Deutschen und ein ebenso berechtigter Wunsch der Türken. Doch woran scheitert Integration?

Bei einigen fehlt sicher der Wille. Jetzt allen Türken zu unterstellen, sie wollten sich gar nicht in die deutsche Gesellschaft einbringen, gleicht der Unterstellung, alle Arbeitslosen seien nur zu faul zum Arbeiten – auf einige trifft das dennoch zu.

Andere sind kriminell. Da werden verschiedene Zahlen angegeben, manchmal sind es 15.000 türkisch-stämmige Einwohner, die im deutschen Strafvollzug sind. Die Zahl dürfte etwas älter sein, wenn sie denn stimmt, also bezieht sie sich auch auf etwas mehr Strafgefangene insgesamt (zzt. ca. 60.000). Trotzdem wäre es eine stolze Zahl. Andererseits bei 2,5 Millionen Türken in Deutschland auch nicht mehr so viel. Einer der Hauptgründe für die Kriminalität dürfte dennoch die fehlende Bildung sein. Genau in dem Punkt würden türkische Schulen also vermutlich helfen.

Ausgehend davon, dass der größte Teil der Türken in Deutschland sich aber einerseits integrieren möchte und andererseits nicht kriminell ist, die Integration trotzdem allzu oft nicht funktioniert, muss es also andere Gründe geben.

Der wohl wichtigste: die Sprachbarriere. Wie kann man jemandem helfen, der die eigene Sprache nicht versteht. Entweder lernt man sein Sprache oder hilft ihm, die eigene zu lernen. Es wird niemand ernsthaft von fast 70 Millionen menschen erwarten, plötzlich türkisch und – aus gründen der Fairness – italienisch, polnisch und chinesisch sprechen und verstehen zu können. Also muss jeder Mensch in Deutschland auch die deutsche Sprache beherrschen. Dass dies durch türkische Schulen in Deutschland gefördert wird, darf bezweifelt werden.

Dann bleibt noch immer die ablehnende Haltung der Deutschen. Auch die existiert wieder nicht bei allen, aber sie existiert. Leider ist es keine Hilfe, wenn eine Minderheit der Türken das Bild einer ganzen Bevölkerungsgruppe bestimmt, indem sie allzu oft allzu negativ auffallen. Was bleibt, ist dann nur der Gedanke: “Willst du die integrieren, dann erwarte nicht mehr Veränderung, als wenn du e^x integrierst – erwarte nur weniger Erfolg.”

Von der BILD lernt man, toll klingende Wörter in der Überschrift unterzubringen. Wie weit das hier gelungen ist, muss jeder selbst beurteilen. Ebenfalls aus der BILD stammt die Taktik, Thesen mit absurden Grafiken zu belegen. Hier also diejenige, die zur Überschrift passt:

Im Moment wächst der Teil der deutschen Bevölkerung, der einen türkischen Migrationshintergrund hat, mit 2,5% im Jahr. Das Diagramm zeigt die Anzahl dieser Menschen in den nächsten 100 Jahrne.

]]> http://www.jediblog.de/allgemein/integration-exponentiell-wachsender-minderheiten/feed 0 http://www.jediblog.de/allgemein/lte-schneller-als-das-licht http://www.jediblog.de/allgemein/lte-schneller-als-das-licht#comments Sat, 27 Mar 2010 10:58:25 +0000 jedi http://www.jediblog.de/?p=69 “Liebe Freunde, es ist mal wieder so weit, ich hab ‘n’ dicken Hals!”, könnte ich Professor Harald Lesch von der Ludwig-Maximilians-Universität München zitieren – oder direkt Dieter Nuhr: “Wenn man keine Ahnung hat, einfach mal Fresse halten.”

Doch was ist passiert?

Wieder einmal wurde von der Redaktion der BILD ein Bericht zu einem Thema veröffentlicht, von dem der Autor offensichtlich nicht allzu viel versteht. Es geht um LTE (Long Term Evolution), also die Technik, die das jetzige UMTS ablösen soll.

LTE soll laut BILD schon 2010 in Deutschland starten. Das mag sein. Wann der “normale” Mobilfunkbenutzer in den Genuss kommen wird, steht aber vermutlich noch in den Sternen.

Es geht hier aber gar nicht um die prognostizierte Verfügbarkeit, viel wichtiger sind die Fortschritte, die wir mit LTE erleben werden. Wer die Fortschritte beurteilen können will, benötigt zunächst Informationen über den jetzigen Stand der Technik. Also bitte:

Die [!] Übertragungsstandard UMTS, auch als 3G bekannt, ist zur Zeit die gängige Datenübertragung für Mobiltelefone. Die schnellste Variante ist HSDPA+. Damit ist das Herunterladen von Daten mit einer Geschwindigkeit von 40 MB pro Sekunde möglich.

Nun findet man im Internet lediglich sehr alte Artikel zum Thema HSDPA+. Gemeinsam haben diese, dass von einer maximalen Datenrate von 28,8 Mbit pro Sekunde berichtet wird. Das kann also nicht gemeint sein. Viel eher wird meint der Artikel eine der vielen Varianten von HSDPA, die man z.B. in der Wikipedia findet. Dort wird allerdings von einer physikalische Grenze gesprochen, die bei 84,4 Mbit pro Sekunde liegt – also gerade einem Fünftel der in Aussicht gestellten Geschwindigkeit. Dass selbst dies zurzeit von keinem Netzanbieter angeboten wird und selbst wenn, ein Benutzer auf der Anwendungsebene maximal 85 Prozent dieser Datenrate auch nutzen könnten (der Rest wird für Header benutzt) lassen wir dabei außen vor.

Wir sind also heute noch nicht ganz so weit, wie der Bericht uns glauben lässt. Ein weiterer Grund, sich auf LTE zu freuen, denn:

[LTE] bietet doppelt so hohe Übertragungsraten sowie modernste Glasfasernetze.

An dieser Stelle würde ich gerne aus dem Anhalter durch die Galaxis zitieren (“Der vorangehende Satz ist logisch, das ist nicht das Problem. [...] Lesen Sie ihn nochmal, und Sie werden ihn verstehen.”), doch der Satz ist leider nicht logisch. Gemeint war vermutlich eine doppelt so hohe Übertragungsrate wie modernste Glasfasernetze.

Modernste Glasfasernetze ermöglichen Übertragungsgeschwindigkeiten im Gigabit- oder sogar Terabit-Bereich. Meine Vorfreude auf LTE steigt beim Lesen des Artikels in jeder Zeile.

Dann ist leider doch nur die Rede von 170 MB pro Sekunde, was gerade einmal im unteren Gigabit-Bereich anzusiedeln wäre. Für den Upload sollen sogar nur 50 MB pro Sekunde erreicht werden. Na gut, auch damit will ich mich für mein Handy zufrieden geben, wo ich doch weiß, dass die Schreib- und Lesegeschwindigkeit der eingebauten SD-Karte viel niedriger sind und selbst der eventuell sehr schnelle interne Speicher lange nicht an diese Geschwindigkeit heran kommen dürfte.

Es bleibt also nur noch ein einziges Problem: mein angeborenes antrainiertes Misstrauen gegenüber allem, was die Bild veröffentlicht. Ein Blick in andere Quellen und vorbei ist es mit der Vorfreude. Da ist auf einmal von 326,4 Mbit pro Sekunde die Rede, wenn es um den Download geht. Für den Upload sollen sogar maximal 86,4 Mbit pro Sekunde erreicht werden. Das überfordert die meisten SD-Karten zwar immernoch, klingt aber für einen BILD-Bericht vermutlich viel zu realistisch.

Einige Gemeinsamkeiten mit der BILD muss ich mir allerdings eingestehen. Ich habe genauso wenig wie die BILD viele zuverlässige Informationen zum Thema LTE. Auch fehlt mir genauso wie den Redakteuren der BILD eine vernünftige journalistische Ausbildung. Eventuell findet man sogar in diesem Artikel Fehler in der Sprache, wie man es in den meisten BILD-Artikeln erwarten darf. Einen Unterschied möchte ich allerdings betonen:

Ich behaupte nicht das Gegenteil.

Long Term Evolution steckt noch in den Kinderschuhen. Konkrete Zahlen zu nennen, ist absurd. Der Name sagt auch, dass es sich um eine langfristige Entwicklung handelt, nicht um einen Standard, der jetzt eingeführt wird und dann nicht verbessert wird.

Vielleicht noch ein kleiner Hinweis am Rande:

NSN rechnet bis 2015 mit einer Zunahme des Datenverkehrs um 10 000 Prozent. Das wären 23 Exabytes pro Jahr!

Sehr informativ. Doch wer weiß, ohne lange nachzudenken, dass folgender Satz, die gleiche Aussage trifft:

NSN rechnet bis 2015 mit hunter mal so viel Datenverkehr wie heute (eigentlich 101 mal). Das wären  23 Millionen Terabyte pro Jahr.

Der Unterschied? Den Faktor 100 kann sich ein Mensch eventuell vorstellen, eine Zunahme um 10000 Prozent eher nicht. Mit Exabyte kann niemand etwas anfangen, selbst Terabyte sind für viele noch unbekannt. Aber man sollte wohl nicht davon ausgehen, dass bei der BILD die Absicht besteht, dass die Leser die Artikel auch verstehen.

Verstünden die Leser alles, so könnten sie schließlich nachrechnen, was es mit der folgenden Aussage auf sich hat:

Vergleich: Ein solches Datenaufkommen gäbe es, wenn 6,3 Milliarden Menschen ein Jahr lang täglich ein digitalisiertes Buch herunterladen würden.

23 Exabyte = 23.000 Petabyte = 23.000.000 Terabyte = 23.000.000.000 Gigabyte = 23.000.000.000.000 Megabyte

23.000.000.000.000 Megabyte / (6.300.000.000 * 365) = 10 Megabyte

Wir lernen: Ein digitalisiertes Buch ist 10 Megabyte groß. Es muss sich um ein Bilderbuch handeln. Selbst die Bibel ist digitalisiert kleiner als 5 Megabyte. Aber vielleicht dachte der Autor auch an die letzte abfotografierte Version eines noch unveröffentlichten Buches.

Man öffnet eine ssh-Verbindung, gibt seinen Benutzernamen ein, dann das Passwort und ist schließlich angemeldet. Aus Sicherheitsgründen hat das Passwort 18 Stellen oder mehr, oft genug kommt es vor, dass man sich vertippt, im schlimmsten Fall so oft hintereinander, dass die eigene IP-Adresse vom Server gesperrt wird. Zugegeben, das ist ein übertriebenes Horror-Szenario, aber ausschließen, dass es schon passiert ist, möchte ich nicht.

Warum also nicht ganz ohne Passwort anmelden?

Die Möglichkeit besteht durchaus, ist noch dazu sicherer als die Anmeldung per Passwort und natürlich gemütlicher. Die Rede ist von der Authentifizierung mit einem Schlüsselpaar (z.B. RSA). Dieses Schlüsselpaar muss für jeden Client einmal generiert werden. Der öffentliche Schlüssel wird dann auf dem Server abgelegt, damit er weiß, dass der Client sich anmelden darf. Nun ist der öffentliche Schlüssel des Clients aber, naja, öffentlich, also wird der Anmeldevorgang signiert. Dies geschieht mit dem privaten Schlüssel des Clients, der natürlich nur dem Client bekannt ist. Wie genau die Überprüfung funktioniert, weiß ich nicht, eine simple Möglichkeit wäre aber folgende (evtl. ist es auch die tatsächlich genutzte):

Der Server sendet eine zufällig generierte Zahl an den Client,  die auch nur einmal verwendet wird (nennt sich NONCE). Der Client verschlüsselt diese Zahl mit seinem privaten Schlüssel und schickt das Ergebnis wieder an den Server. Dieser versucht, die empfangene Nachricht mit dem öffentlichen Schlüssel des Clients zu entschlüsseln. Gelingt ihm dies, so ist es (nahezu) unmöglich, dass jemand anderes als der richtige Client gerade versucht, sich mit dem öffentlichen Schlüssel anzumelden.

Das Verfahren wird allgemein als sicher angesehen und wenn man sich die am häufigsten benutzten Passwörter ansieht, so ist dieses Verfahren im Gegensatz dazu die Definition von Sicherheit.

Zur Einrichtung begibt man sich zunächst an den Client. Hier wird mittels

ssh-keygen -t rsa

ein Schlüsselpaar generiert. Es ist vermutlich empfehlenswert, eine Passphrase für den Schlüssel zu vergeben, allerdings entfällt dann der Vorteil, dass man sich ohne Passwort anmelden kann. Vergibt man keine, so muss man sicherstellen, dass niemals der private Schlüssel öffentlich bekannt wird.

Es werden zwei Dateien erzeugt, eine mit dem privaten Schlüssel und eine mit dem öffentlichen. Letztere hat die Endung .pub (für public).  Der Inhalt dieser Datei muss auf dem Server an die Datei /home/[user]/.ssh/authorized_keys angefügt werden.

Dieses Vorgehen muss für jeden Client einmal wiederholt werden. Die Clients müssen, wie bereits erwähnt, entsprechend geschützt sein, damit der private Schlüssel nicht bekannt wird.

Unter Windows ist die Erzeugung des Schlüsselpaares etwas umständlicher. Will man diese Art der Authentifizierung z.B. mit PuTTY verwenden, so benötigt man zunächst das Programm PuTTYgen. Hier kann man als Typ SSH2-RSA mit 2048 Bits wählen. Klickt man auf Generate, so muss die Maus erst einige Zeit bewegt werden, damit der Schlüssel möglichst zufällig ist.

Anschließend muss der Inhalt des Textfeldes an die Datei /home/[user]/.ssh/authorized_keys angefügt werden. Dies ist der öffentliche Schlüssel. Den privaten Schlüssel speichert man (save private key), wo man ihn wieder findet.

In Putty muss diese Datei unter SSH->Auth als Private key file ausgewählt werden. Anschließend sollte die Verbindung ohne Passwort funktionieren.

Nach dieser Anleitung könnte man auf die Idee kommen, auch die Anmeldung an einem ssh-Server, der z.B. über cygwin unter Windows läuft, durch RSA zu ermöglichen. Vorab: Nein.

Warum das nicht so einfach möglich ist, wird schnell klar, wenn man verstanden hat, wie diese Anmeldung unter Linux überhaupt funktionieren kann. Wir melden uns an einem Rechner mit einem Benutzernamen aber ohne dessen Passwort an. Auch in den Dateien, die wir dafür angelegt oder geändert haben, ist das Passwort nirgends gespeichert.  Alles andere wäre auch irrsinnig.

Unter Linux ist das möglich, weil root eine Shell für einen beliebigen Benutzer öffnen kann – ohne Passwort. Nun läuft der ssh-Server unter dem Benutzer root, also hat der Server dieses Recht. Wir versichern dem Server durch unsere Authentifizierung, dass wir ein bestimmter Benutzer sind und er öffnet für uns die entsprechende Shell. Unter Windows ist es selbst dem Administrator nicht möglich, sich einfach als ein anderer Benutzer auszugeben. Eine Anmeldung ohne Passwort ist ohne weitere Eingriffe also nicht möglich. Natürlich darf der Administrator das Passwort eines Benutzers zurücksetzen und kennt dann das neue Passwort – aber das wollen wir wohl kaum als Anmeldeprozedur implementieren.

Falls doch jemand voreilig etwas in die authorized_keys eines Windows-Servers eingetragen hat, so ist die Anmeldung von dem eingetragenen Client aus nicht mehr möglich. Also entweder einen anderen Client benutzen oder lokal anmelden und den Eintrag aus der Datei wieder löschen.

Das Abhärten lässt sich vielleicht an einem Beispiel kurz erklären:

Eine junge Dame – geschätztes Alter Anfang 20 – telefoniert in der Bahn und telefoniert. Da dies in einer Lautstärke geschah, die es auch den Menschen am anderen Ende des Abteils erlaubte, jedes Wort zu verstehen, wird mit der anonymen Veröffentlichung an dieser Stelle wohl niemand ein Problem haben. Natürlich fehlt die Hälfte des Gesprächs.

Sie: Ey, bist du nicht Skihalle?
…
Sie: Hab ich voll geilen Film gekauft. Also glaub ich ist voll geil.
…
[Sie wühlt in ihrem für eine dreitägige Auslandsreise geeigneten Gepäckstück - ihrer Handtasche]
…
Sie: Buhrit aliefe. Da spielt der von Saw mit. Bestimmt voll cool.

Das Gespräch war zwar an dieser Stelle nicht zu Ende, doch alles hat Grenzen, auch mein Wille, so etwas mit anzuhören.

Präpositionen und Artikel sind etwas, womit sich vielleicht Anfänger beschäftigen. Der oder die wahre Deutsche geht davon aus, dass ein Gesprächspartner genauso versiert ist und lässt unnötigen Ballast einfach weg. Nun kann niemand erwarten, dass jemand, der die deutsche Sprache auf diesem hohen Niveau beherrscht, andere Sprachen auch nur im Ansatz versteht.

Gemeint war übrigens der Film Buried Alive, der es bisher nicht zu einem Artikel in der deutschen (oder englischen) Wikipedia geschafft hat, dafür aber in der Internet Movie Database mit 3,9 von 10 Punkten bewertet wird. Ob Tobin Bell, Darsteller des Jigsaw in der Horrorrheihe Saw den Film zu retten vermag, kann ich nicht beantworten.

Grundsätzliches

Ein Rechner, der an das Internet angeschlossen ist, insbesondere dann, wenn Ports im Router weitergeleitet werden, sollte kein Benutzerkonto ohne sicheres Passwort besitzen. Unter einem sicheren Passwort darf jetzt jeder verstehen, was er möchte. Kleiner Tipp: Der eigene Vorname ist ebenso unsicher wie ein 17-stellige Passwort, welches man sich nicht merken kann und unter die Tastatur schreibt. Ansosten gehe ich bei dieser Anleitung davon aus, dass man mit Windows einigermaßen umgehen kann. Getestet wurde alles unter Windows XP und Windows 7. Bei XP muss es sich um die Professional-Version handeln, bei Windows 7 könnte es auch mit anderen Versionen funktionieren, was ich aber nicht sicher weiß. Außerdem wäre ein zweiter Rechner von Vorteil, damit man alles jederzeit testen kann. Im Idealfall hat man bei dem zweiten Rechner die Wahl, ob er im selben lokalen Netz ist wie der Hauptrechner oder in einem ganz anderen.

Remotedesktopeinstellung

Zunächst wird der Rechner so konfiguriert, dass es möglich ist, von einem anderen Rechner im selben Netzwerk eine Remotedesktopverbindung aufzubauen. Mit einem Rechtsklick auf den Arbeitsplatz (Computer)  und dann auf Eigenschaften öffnen sich die Systemeigenschaften. Dort findet man die relevanten Einstellungen unter Remote (Remoteeinstellungen).

links: Windwos 7, rechts: Windows XP

Zum einen erlaubt man dort grundsätzlich, dass jemand eine Remotedesktopverbindung zu diesem Rechner aufbaut, zum anderen wählt man die dafür zulässigen Benutzer aus. Dabei sollte es sich nicht um ein Administratorkonto handeln und das Konto muss auf jeden Fall durch ein Kennwort geschützt sein. Die Windows-Firewall, so sie denn aktiviert ist, sollte automatisch so konfiguriert werden, dass Remotedesktop-Verbindungen akzeptiert werden. Falls eine andere Firewall installiert ist (z.B. ZoneAlarm oder Norton Internet Security) (beide dürfen mich gerne bezüglich einer Vergütung für die Werbung kontaktieren), so muss diese noch konfiguriert werden. Für den Moment reicht es, wenn Port 3389 freigeschaltet wird. Jetzt sollten die Einstellungen einmal getestet werden. Also führt man an einem zweiten Rechner, der sich im selben lokalen Netzwerk befindet das Programm mstcs aus (Start->Ausführen: mstsc). Dort gibt man den Computernamen oder die IP-Adresse des Rechners ein, auf dem die Einstellungen vorgenommen wurden. Beides kann man in Erfahrung bringen, indem man – natürlich wieder auf dem Rechner, den es betrifft – in der Eingabeaufforderung (Start->Ausführen: cmd) den Befehl “ipconfig /all” eingibt. Ganz oben steht hinter Hostname der Computername und darunter steht hinter IPv4-Adresse die IP-Adresse. Mit einem Klick auf Verbinden sollte man zur Anmeldemaske des Rechners gelangen, auf dem die Remotedesktopeinstellungen vorgenommen wurden.

ssh-Server installieren

Wenn bis hierhin alles geklappt hat, sollte sich der Rechner auf jeden Fall hinter einem Router befinden, so dass er aus dem Internet noch nicht erreicht werden kann. Jetzt könnte man im Router Port-Forwarding aktivieren und den Rechner so auch aus dem Internet zugänglich machen, allerdings rate ich davon ab. Zum einen ist die Remotedesktopverbindung nicht die sicherste und zum anderen möchte man nicht jedem Menschen seine Windows-Anmeldemaske im Internet anbieten. Deshalb wird als nächstes ein ssh-Server installiert, der es später erlauben wird, die Remotedesktopverbindung über ssh zu tunneln. Ein weiterer Vorteil des Tunnels ist, dass man sich den dafür verwendeten Port selbst aussuchen kann. So ist es z.B. in Firmennetzwerken oft üblich, fast alle Ports zu sperren, bis auf einige wenige, die das Surfen im Internet noch erlauben.

Der Port für RDP (Remotedesktop-Protocol) ist wie erwähnt 3389. ssh läuft über Port 22. Ein kostenloser ssh-Server für Windwos kann mit cygwin installiert werden. Dabei solltem an die Anweisungen während der Installation Schritt für Schritt durchlesen und befolgen. Irgendwann kommt man zu einer Auswahl der Pakete. Dort sollten folgende Pakete auf jeden Fall ausgewählt werden: Admin -> cygrunsrv Base -> alle Pakete Editors -> nano, vim Net -> autossh, openssh, openssl, Openssl097 Zur kurzen Erklärung: cygrunsrv ist der Dienst, der mit Windows gestartet wird, so dass cygwin immer in Hintergrund läuft. nano und vim sind Texteditoren, man benötigt nur einen von beiden, wenn man sich nicht sonderlich gut mit ihnen auskennt, ist vermutlich nano empfehlenswerter. autossh, openssh, openssl und Openssl097 sind die Pakete, die für die eigentliche ssh-Verbindung erforderlich sind (wobei ich mir den ssl-Paketen nicht sicher bin).

Nach erfolgreicher Installation startet man cygwin mit der Datei cygwin.bat (im Installationsverzeichnis von cygwin). Unter Windows 7 muss die Datei per Rechtsklick als Administrator ausgeführt werden. Jetzt kann die automatische ssh-Konfiguration mit dem Befehl “ssh-host-config” gestartet werden. Die Fragen, die während der Konfiguration beantwortet werden müssen, haben sich in den letzten Jahren geändert. Eines gilt nach wie vor: Frage durchlesen, verstehen und nach bestem Wissen und Gewissen beantworten. Für gewöhnlich antwortet man also mit der Default-Antwort, also dem, was voreingestellt ist. Nach der Konfiguration wird der ssh-Server mit dem Befehl “net start sshd” gestartet. Anschließend müssen etwaige Firewalls so eingestellt werden, dass Verbindungen auf Port 22 akzeptiert werden.

PuTTY konfigurieren

Zum Testen wird auf einem zweiten Rechner PuTTY ausgeführt.

Konfiguration von PuTTY

Bei Host Name gibt man wieder die IP-Adresse des fernzusteuernden Rechners ein. Klickt man auf Open, so kann man sich mit Benutzername und Passwort anmelden. Wenn die Anmeldung erfolgreich ist, kann PuTTY geschlossen und neu geöffnet werden. Die folgenden Einstellungen müssen auf jedem Rechner vorgenommen werden, von dem aus man sich zu seinem Rechner zu Hause verbinden möchte. Was bei Host Name tatsächlich eingegeben werden muss, darauf komme ich später zurück. Wichter ist zunächst der Tunnel. Im Menü unter SSH->Tunnels füllt man die Felder wie abgebildet aus:

ssh-Tunnel mit PuTTY

Der Source port gibt an, auf welchem Port der ssh-Server einen Socket aufmachen soll, auf dem er auf Verbindungen wartet. Eingehende Verbindungen auf diesem Port werden über die ssh-Verbindung zu dem Rechner, auf dem der Server läuft geleitet und dort an “Destination” geschickt. In diesem Fall also an den Server selbst (localhost) und zwar an Port 3389, also den Port, über den die Remotedesktopverbindung aufgebaut wird. Wichtig ist hier ein Klick auf Add, damit der Tunnel auf wirklich eingerichtet wird. Damit diese Einstellungen nicht verloren gehen, sollte man sie als Default speichern, also im Menü auf Session klicken, den Eintrag Default Settings markieren und auf Save klicken.

Remotedesktopverbindung über den Tunnel aufbauen

Hat man PuTTY konfiguriert und sich darüber mit dem Rechner verbunden, so kann man wieder die Datei mstsc ausführen, und als Ziel diesmal “localhost” eingeben.  Falls hier eine Fehlermeldung erscheint, kann es in manchen Fällen helfen, unter Putty->ssh->Tunnels als Source port nicht 3389 zu benutzen, sondern z.B. 3400. Die Destination wird auf keinen Fall geändert. Dann gibt man statt “localhost” einfach “localhost:3400″ ein.

Verbindung weltweit

Aus dem lokalen Netz sollte man nun die Verbindung zu seinem Rechner herstellen können. Über das Internet funktioniert dies noch nicht. Dafür gibt es zwei Gründe: Zum einen sollte sich der Rechner hinter einem Router befinden, auf welchem Port-Forwarding noch nicht eingerichtet ist, zum anderen ist die öffentliche IP-Adresse des Routers vermutlich unbekannt und ändert sich zu allem Überfluss auch noch alle 24 Stunden. Das erste Problem lässt sich schnell in der Routerkonfiguration beheben. Diese erreicht man meist über ein Web-Interface, indem man im Browser seiner Wahl die IP-Adresse des Routers einträgt. Also z.B. http://192.168.1.1 – falls dies denn die IP-Adresse des Routers ist. Eine schnelle Möglichkeit, die Adresse des Routers zu finden, ist folgender Befehl in der Eingabeaufforderung:

C:\>tracert jediblog.de

Routenverfolgung zu jediblog.de [188.40.132.68] über maximal 30 Abschnitte:

1    <1 ms    <1 ms    <1 ms  router [192.168.2.1]
2     5 ms     5 ms     5 ms

Der erste Abschnitt hat als Ziel für gewöhnlich den Router. Das Wort “router” steht dort im Normalfall allerdings nicht. In der Konfiguration sollte es einen Punkt “Port-Mapping” oder “Port-Forwarding” geben, evtl. auch unter dem Namen NAT (Network Address Translation). Dort muss eine neue Regel erstellt werden, die besagt, dass TCP-Verbindungen über Port 22 an den Rechner mit dem ssh-Server (vermutlich muss seine IP-Adresse eingegeben werden) und zwar an den gleichen Port geleitet werden. In manchen Netzwerken ist Port 22 gesperrt. In diesem Fall kann man als öffentlichen Port einen anderen Port wählen, der offen ist. Meistens ist z.B. Port 443 offen, da er für gesicherte http-Verbindungen benutzt wird (https). Es ist zu beachten, dass dieses Vorgehen in einem Firmennetzwerk zunächst mit dem Arbeitgeber (vermutlich der IT-Abteilung des Arbeitgebers) abzusprechen ist, da man ansonsten unter Umständen gegen Unternehmensvorschriften verstößt.

Die eingerichtete Regel besagt also, dass alles, was über den eingestellten Port am Router ankommt, an Port 22 des ssh-Servers geleitet wird. Es bleibt noch das Problem der unbekannten öffentlichen IP-Adresse. Ausgehend davon, dass der Router sich per DSL ins Internet einwählt und keine Standleitung gebucht wurde, so wird die Verbindung bei den meisten Providern einmal am Tag getrennt. Bei der Wiedereinwahl erhält man meistens eine unterschiedliche IP-Adresse. Hier ist nicht die Adresse gemeint, die mit 192 anfängt. Die richtige IP-Adresse sieht man z.b. hier oder hier. Das hilft nur nicht weiter, denn die Seite muss von dem Rechner aus aufgerufen werden, der erreicht werden soll. Die Lösung des Problems heißt DynDNS. DNS ist der Dienst, der Domain-Namen (z.B. google.de) in IP-Adressen übersetzt. DynDNS bietet die Möglichkeit, dies dynamisch zu gestalten (die IP-Adresse von Google bleibt dagegen mehr oder weniger fest).

Verschiedene Dienstleister bieten diesen Dienst zum Teil kostenlos an.  Einer dieser Dienstleister ist dyndns.com. Dort meldet man sich an, sucht sich einen Domain-Namen aus und ist fast fertig. Doch woher weiß dyndns.com, welche IP-Adresse zur gewählten Domain passt, wo sich diese doch täglich ändert? Im einfachen Fall bietet der Router in der Konfiguration auch den Punkt Dynamic DNS an. Dort wählt man üblicherweise den Dienstleister (dyndns.com) aus und gibt Domain und Passwort ein. Den Rest übernimmt dann der Router. Bei jeder Änderung der IP-Adresse übermittelt er die neue IP-Adresse an dyndns.com. Ältere Router bieten diese Möglichkeit nicht an. In diesem Fall kann man einen Update-Client auf seinem Rechner installieren (z.B. DynDNS Updater). Dieser übernimmt dann die Aufgabe der Aktualisierung an Stelle des Routers. Das Programm muss natürlich ständig ausgeführt werden, sich also am besten im Autostart befinden. Der Computer muss so oder so an sein, sonst gestaltet sich die Verbindung schwierig.

Erst war da eine Diskussion, die im August 2008 angestoßen wurde, die ein paar Monate später von Frau von der Leyen (CDU, damals Familienministerin) aufgegriffen wurde.

Im Januar 2009 wurde dann ein Lösungsvorschlag für die diskutierten Probleme vorgestellt. Der beinhaltete zum einen, dass der Gesetzgeber weniger, andere dafür mehr arbeit haben würden und zum anderen die obligatorische Begründung, anderswo würde das ähnlich gehandhabt.

Zunächst wurden im April 2008 freiwillige Partner gesucht (und gefunden: Deutsche Telekom, Vodafone/Arcor, HanseNet/Alice, Telefónica O2 Germany und Kabel Deutschland), in einem weiteren Schritt sollten unfreiwillige Partner per Gesetz zur Kooperation gezwungen werden. Der entsprechende Gesetzentwurf wurde ebenfalls im April vom Bundeskabinett gebilligt.

Inzwischen dürfte klar sein, dass es sich um das Zugangserschwerungsgesetz handelt.

Währenddessen diskutierte man im Internet schon heftig über das geplante Gesetz, richtete eine Online-Petition dagegen ein. Spätestens nachdem diese bereits innerhalb von wenigen Tagen die nötigen 50.000 Unterstützer erreichte, begannen auch die traditionellen Medien, über das Thema etwas ausführlicher zu berichten.

Befragte Experten rieten unisono zur Überarbeitung des Gesetentwurfs, äußerten Bedenken zur Umsetzbarkeit, Wirksamkeit und auch hinsichtlich der Motivation, dieses Gesetz auf den Weg zu bringen.

Politiker sind allerdings, so weiß man inzwischen sicher, resistent – in erster Linie: beratungsresistent. So wurde das Gesetz am 18. Juni 2009 im Bundestag beschlossen.

Das war dann auch der Freibrief zur Ehrlichkeit, so dass selbst ein Herr Schäuble im Oktober 2009 Fehler einräumen musste. Er bestätigte sogar, dass das Gesetz auch Mittel des Wahlkampfs war. Das hätte vorher natürlich niemand vermutet, bis zu diesem Zeitpunkt ging noch jeder davon aus, dass das Gesetz ausschließlich für den Wahlkampf entworfen wurde.

In den Koalitionsverhandlungen – nun war der Wahlkampf schließlich beendet, die Wahl gewonnen – beschlossen CDU und FDP dann auch konsequent, dass man das Gesetz nicht anwenden wolle. Auch Bundespräsident Köhler weigerte sich im November, das Gesetz zu unterzeichnen. Er wollte zunächst “ergänzende Informationen”.

Wenig später, Mitte Dezember wendete sich schließlich auch die SPD gegen das Gesetz, dass sie immerhin als stärkste Partei im Bundestag befürwortet hatte.

Endlich, so könnte man sagen, herrscht Einigkeit bei allen Parteien im Budestag. Keiner will das Gestz. Und was macht der Bundespräsident?

17. Februar 2010: Horst Köhler unterzeichnet das Gesetz.

Ausblick

Es muss sich trotzdem niemand sorgen, immerhin gibt es schon eine Dienstanweisung an das BKA, dass das Gesetz nicht umgesetzt werden soll. Vielleicht sollte man sich aber auch gerade deshalb Sorgen machen, denn:

“Eine Dienstanweisung an das BKA kann das Ministerium jederzeit rückgängig machen. Heimlich still und leise, ohne Aussprache im Bundestag, ohne Öffentlichkeit.” (ODEM.blog)

Willkommen in Deutschland.

Die Fakten

• Die in Deutschland erhobene Mehrwertsteuer (auf Mobiltelefone) beträgt 19 Prozent.
• In den USA gibt es keine einheitliche Mehrwertsteuer. Vergleichbar wäre die Sales Tax, die je nach Bundesstaat zwischen 0 und 10 Prozent beträgt.
• Es gibt keinen allzu großen Unterschied zwischen dem amerikanischen und dem deutschen Durchschnittseinkommen.
• Nokia ist ein finnisches Unternehmen.
• Finnland gehört nicht zu den Vereinigten Staaten von Amerika.

Der Preis

Will man in Deutschland das n900 kaufen, so zahlt man dafür zurzeit noch ca. 520 Euro. Bis vor einigen Tagen waren es noch 40 Euro mehr, was wohl daran lag, dass der Nokia-Shop und Amazon das Handy exklusiv im Angebot hatten. Ab morgen bekommt man es in unzähligen Shops.

Die Amerikaner dürften bei dem Preis leicht schmunzeln. Sie können das Handy für 529 Dollar kaufen. Beim aktuellen Wechselkurs sind das 385 Euro – oder auch 26 Prozent weniger.

Ein Erklärungsversuch

Zunächst könnte man versuchen, den Preisunterschied durch die unterschiedlichen Steuersätze zu erklären. Bei 6 Prozent Sales Tax liegt der Nettopreis in den USA bei 363 Euro. In Deutschland sind es immerhin noch 437 Euro. Der Unterschied ist also nicht mehr ganz so groß.

Das Mobilfunknetz könnte ein weiterer Grund für den Preisunterschied sein. Denn wer das n900 kauft, will auch online-Dienste nutzen. So ist eine vernünftige Internetverbindung zwingend erforderlich. In den USA ist UMTS noch immer nicht so weit wie bei uns. Die Netzabdeckung ist nicht überall gut und die Geschwindigkeit nicht vergleichbar mit dem, was wir über HSDPA erreichen. Andererseits ist man in puncto WLAN ein ganzes Stück weiter. In den Foren auf maemo.org äußerte sich ein Mitglied dazu mit “I don’t use 3G here in Canada or the US (it costs too much and Wifi is everywhere)”.

Jetzt den Flug buchen?

Für 144 Euro kommt man noch nicht in die USA. Alleine der Zeitaufwand wird durch den Preisunterschied schon nicht gerechtfertigt. Was aber, wenn man zufällig einen Urlaub dort geplant hat? Was, wenn man Besuch aus den Staaten erwartet?

Zunächst zur rechtlichen Situation: Elektronikartikel aus den USA nach Deutschland einzuführen kann teuer werden. Je nach Gerät werden bis zu 14 Prozent Zoll fällig. Auf den Zollpreis (Anschaffungskosten + Zoll) kommt dann noch die Einfuhrumsatzsteuer (EUSt) von 19 Prozent. Bei Mobiltelefonen wird allerdings kein Zoll erhoben, es bleibt also nur die EUSt. Handelt es sich um ein Gerät für den privaten Gebrauch oder um ein Geschenk und liegt der Warenwert unter 430 Euro, so entfällt selbst diese. Wer also bloß an ein Exemplar des n900 denkt, der dürfte keine weiteren Kosten erwarten.

Vor dem Kauf sollte man dennoch kurz innehalten. Die Tastatur der US-Version hat ein leicht verändertes Layout. Umlaute, sowie unser “ß” fehlen, dafür ist Platz für vier Pfeiltasten (in der deutschen Version werden die Tasten “links” und “rechts” erst duch einen Umschalter zu “hoch” und “runter”). Für Menschen, die auf Umlaute verzichten können, hat die US-Version also eher Vorteile.

Das Betriebssystem ist ebenfalls englisch. Da es sich aber um eine Linux-Distribution handelt, dürfte dies – wenn gewünscht – einfach zu beheben sein. Auch die WLAN-Kanäle (in den USA andere als in Europa) könnten Probleme verursachen, die aber ebenfalls durch Anpassungen an der Software lösbar sein sollten.

Fazit

Das n900 ist teuer. Bisher fehlte mir der Vergleich zu anderen Smartphones mit ähnlichen Fähigkeiten. Die Möglichkeiten scheinen durch das Betriebssystem unbegrenzt, was aber nicht heißt, dass Android und Co. da nicht mithalten können.

Für mich stellt sich bei der bevorstehenden Reise nach New York die Frage: Kaufe ich mir das n900, ohne zuvor etwas das Motorola Milestone selbst getestet zu haben, oder kaufe ich, wie ursprünglich geplant ein Netbook, bei dem ich ähnliche Preisvorteile erziele? Beides lässt der deutsche Zoll nicht zu.

Kurze Antwort: gar nicht.

Seit ein paar Monaten bin ich stolzer Besitzer eines Servers. Auf diesem laufen verschiedene Dienste, unter anderem ein WWW, E-Mail und FTP. Eingerichtet wird alles über die Kommandozeile, eine graphische Oberfläche existiert nicht.

Wie alles begann

In den ersten Tagen stand ich einem System gegenüber, mit dem ich auf diesem Weg noch nicht gearbeitet hatte. Ein entfernter Rechner, auf dem zunächst nur eine minmale Version von Debian installiert war. Mit verschiedenen Hilfsmitteln gelang es einfach, eine Version des Betriebssystems zu installieren, die schon alles beinhaltete. Der Nachteil: Ich hatte keine Ahnung, was da alles installiert war, wie man es richtig einrichten konnte und ob ich es überhaupt brauchte.

Der Nächste Schritt war also die Neuinstallation des Systems, diesmal wieder mit einer Minimalversion von Debian. Nach und nach installierte ich die benötigten Anwendungen, bis nach einigen Tagen mein Server in der Lage war, E-Mails zu empfangen, Internetseiten darzustellen und Dateien per ftp zu übertragen. Das alles ließ sich über eine einfache Web-Oberfläche bedienen. Doch dann kam Quassel.

Sind Sie sicher, dass Sie Ihr System zerstören möchten?

Da ich an verschiedenne Orten von verschiedenen Geräten aus im Internet surfe und auch über ICQ chatte, kam ich bisher nie in den Genuss einer vollständigen Historie. Einzelne Gesprächsfetzen waren auf verschiedenen Geräten verteilt. Meldet man sich auf einem Gerät an, wird man auf dem anderen automatisch abgemeldet. Meldet man sich wieder ab, so ist man offline. Offline funktioniert der Erhalt von Nachrichten allerdings nur unzuverlässig. Also suchte ich nach einer Alternative.

Quassel ist ein IRC-Client, bestehend aus einem Server und einem Client. Der Server baut die Verbindung zum IRC-Netz auf und beliebig viele Clients können sich am Server anmelden und diese Verbindung nutzen. Mit Bitlbee wird eien Verbindung zwischen Quassel und ICQ möglich, so dass dort dasselbe Prinzip angewendet werden kann.

Es war also naheliegend, den Quassel-Server und Bitlbee auf meinem Server zu installieren. Das Problem: In den den vordefinierten Paketquellen war Quassel nicht enthalten. So suchte ich nach einer anderen Quelle, fand sie, ergänzte die Paketquellen und installierte Quassel.

Während der Installation musste ich – wie das bei Linux üblich ist – bestätigen, dass einige weitere Pakete installiert oder aktualisiert werden. “Mach du mal, du wirst schon wissen, was du tust.”

Was für mich nicht ganz klar war: Die Frage nach der Aktualisierung eines Pakets war gleichzusetzen mit der Frage “Möchten Sie dieses Paket, welches bei Ihnen schon auf dem neuesten sicheren Stand ist, durch eine Version ersetzen, die sich zurzeit in der Entwicklung befindet, wodurch Probleme auftreten könnten, zukünftige Updates immer auf dieser unsicheren Version basieren und auch andere Pakete betroffen werden können?” oder eben “Sind Sie sicher, dass Sie Ihr System zerstören möchten?”.

Wenn man keine Ahnung hat…

Jetzt weiß ich nicht, ob mir die Gelben Seiten geholfen hätten, was allerdigns geholfen hat, war jemand, der sich mit Debian auskennt.  Nach ein paar Stunden Arbeit war der Server neu aufgesetzt. Diesmal mit einem 64-Bit-System (ein weiterer Anfängerfehler…), einer vernünftigen Konfiguration – und Quassel.

Es gibt also noch viel zu lernen. Diese Erfahrung hat jedenfalls bewirkt, dass ich immer dann, wenn ich nicht weiß, was ich da eigentlich bestätigen soll, zuerst in Erfahrung bringe, welche Folgen es hat.