[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Änderung von Namen und/oder IP-Adressen



Peter Bounin schrieb:

Patrick Willam schrieb:

Peter Bounin schrieb:

In einem Eintrag (Jan-Aug 2005) hatte ich die Bemrkung
aufgeschnappt, daß irgendwer an einem Skript arbeiten
würde die IP-Adresse - dann "im Batch" - zu ändern.
Gibt es das Skript mittlwerweile?

Ich hab' ein kleines Skript beigefügt, daß dennoch sehr zuverlässig
entsprechende Änderungen im gesamten /etc durchführt (hat 'ne usage
und gibt ohnedies erst 'ne Warnung aus, bevor es losläuft.)

Einen herzlichen Dank fuer deinen Einsatz.

Hm, jein: mit der nur formalen Änderung (z.B. durch das Skript oder
von Hand) erreicht man für einen Skolelinux {Haupt-|Kombi-|Terminals-}
Server 95-98%. Aber es sind z.B. nur für den Namen des Servers (tjener)
23 Dateien unterhalb /etc zu ändern - da lohnt sich dann ein verläss-
lichliches Skript allemal:

Richtig. Hat aber nichts mit meiner Aussage zu tun; ich sagte:
| Um <zitat>die IP-Adresse</zitat> zu aendern, ist Handarbeit einfacher,
Und ich glaube weiterhin daran, denn das trifft fuer auch fuer 95-98%
der IPs zu. Was anderes ist zum Beispiel das Aendern der tjener-IP.

> Und genau deshalb hatte ich nach Hilfsmitteln für Änderungen gefragt.

Die hattest nach _einem_ Hilfsmittel fuer _eine_ Aenderung gefragt, und
dabei ziemlich offen gelassen, was /genau/ denn geaendert werden sollte.
Meine Ausfuehrungen bezogen sich auf ebendiese deine Frage.

Deine Ausfuehrungen, die ich nichtsdestotrotz sehr begruesze, beziehen
sich auf _mehrere_ Aenderungen an _Rechnernamen_, _Subnetzadressen_ und
_Netznamen_.

Danach hattest du initial nicht gefragt; und weil ich wie beschrieben
soetwas vermutete, wuenschte ich mir mehr Info deinerseits:

>> Schlussendlich kann ich nur erstmal zurueckfragen: ..........
>
> Er sollte halt die IP-Adressen für die Skolelinux- (Sub-) Netze ändern.
> Wirklich genau das.

Das war am Anfang so direkt leider nicht klar.


>> http://www.lugbz.org/documents/smart-questions_de.html#beprecise   (s.u.)
>>
>> Nur so koennen auch _konkret_ Skripte geschrieben und getestet werden.
>> Anderenfalls bleibt nur die Moeglichkeit ein Dutzend Skripte ins Blaue
>> hinein zu schreiben, und die dann halbgar unters Volk zu werfen; ggf.
>> mit der Resonanz, dasz die bereitstehenden Skripte gar nicht fuer die
>> Faelle sind, die Skolelinux-Tester/-Einrichter haben wollen.
>
> Ich seh' das ein klein wenig anders: entweder derjenige der die
> Skole-Netze
> betreibt hat von IP-Netzen so gut wie keine Ahnung (muß er auch nicht!),
> dann bleiben die Netze so, wie die Installation dies anlegt.
> Hat er aber 'ne Ahnung, dann weiß er auch (einigermaßen) was er tut und
> braucht dann weniger ein möglichst umfassendes Schema, denn die
> Möglichkeit
> dies zu ändern (verlässlich und vielseitig, aber halt ohne Schema).

Fuer mich schliessen sich diese beiden Ansichten keinesfalls aus.

Allein dadurch, dasz du nun geschildert hast, welche Aenderungen denn
von dir gewuenscht waren/sind, hast du einen wesentlichen Beitrag geleistet.
Denn nun wissen wir von konkret einer Installation die ebendiese konkreten
Aenderungen als Anforderung an Skolelinux stellt. Womit wir dann auch bei
ebenjenen konkreten Skripten waeren.

Dasz du darueberhinaus ein solches Skript erstellt und dann auch noch hier
zur Verfuegung gestellt hast, ist umso wertvoller.


Die Domain "intern" würde ich - sorry - als etwas unglücklich
bezeichnen, da die Zeichenfolge in vielerlei Kombinationen
auch noch anderweitig verwendet wird, habe ich also mit dem
selben Skript in 10 Sekunden mal zum Spaß in "edu.myskole.tld"
umbenannt:

Kann man natuerlich zum Spasz machen. Solange alle den Spasz mitmachen
ist auch alles prima.

Aber im Ernst sind TLD-Namen fuer die lokale/interne Verwendung nicht
sehr beliebig, falls man Komplikationen aus dem Weg gehen will. Und als
maszgeschneiderte Distribution koennen wir uns da keine Willkuerlichkeiten
erlauben, sondern muessen uns an entsprechende Vorgaben/Standards halten,
falls wir eine verlaeszliche Funktionsweise fuer jetzt und in Zukunft
gewaehrleisten wollen. Die Auswahl ist diesbezgl. halt begrenzt.

Und "intern" halte ich bis jetzt nicht fuer die schlechteste Wahl, da bei
der URL-Eingabe *unmiszverstaendlich* zum Ausdruck kommt, dasz man sich
*nicht* moeglicherweise im Internet bewegt.
So ist fuer die Nutzer von vorneweg klar unterscheidbar, ob ihre Aktionen
im 'sicheren'/'guten' lokalen Netz, oder im 'unsicheren'/'boesen' Internet
stattfinden.

Falls du brauchbares Lehrmaterial fuer Drittklaessler hast, mit dem dieser
Zielgruppe die Unterscheidung zwischen der Ungueltigkeit von "tld" als TLD
einerseits und der Gueltigkeit von "cx", "com", "user", "info" und
[demnaechst|schon] "sex", "senior", "book" und wer-weisz-was-noch-alles
andererseits eingaengig und memorabel vermittelt werden kann, dann bitte
immer nur her damit.

Was ich damit [auch] sagen will: die Entscheidungen fuer viele Vorgabewerte
bei Skolelinux haben nicht immer aber zumindest i. d. R. mehrere Gruende.
Das heiszt keinesfalls, dasz alles so bleiben musz, wie es ist.
Aber es heiszt eben auch, dasz vieles aus einem bestimmten Blickwinkel
unpraktisch, vielleicht sogar hinderlich, erscheint, und von anderen Seiten
her ggf. umso mehr Sinn macht.

Fuer Vieles muessen daher gute und tragfaehige Kompromisse gefunden werden,
bei denen so manches bedacht werden will:
 *  Mehrsprachigkeit; kulturelle Hintergruende
 *  Altersgruppen
 *  Sicherheitserwaegungen/-anforderungen vs. Funktionalitaet & Ease-of-Use
 *  Einfachheit oder zumindest Klarheit im Umgang/ i. d. Benutzung
 *  Vorwissen und Erwartungen der verschiedenen Benutzergruppen
 *  techn. Vorgaben   a) vor Ort   b) allg. Standards
 *  rechtl. Vorgaben   a) Debian, Lizenzen   b) Schule, Kommune, Land(!)
 *  mehrstufiges, hochskalierbares Netzwerkkonzept
 *  Nachhaltigkeit
 *  Komplexitaet vs. Funktionalitaet & Ease-of-Use
...um _nur_einige_ zu nennen.

Daher koennen wir als Distributionsbauer nicht so einfach hergehen und
Sachen, wo selbst wir ohne Umschweife sagen: "Toll, dasz das bei dir auch
so-und-so geht; mach das ruhig, wenn es so bei dir besser paszt.", ohne
Weiteres _als_Vorgabe_ in die Distri mit einbauen.

Manche dieser grade aufgefuehrten Punkte unterscheiden Skolelinux von
anderen EDV-Loesungen (auch nicht-Linux-basierten) fuer Schulen.
Ebendiese Punkte sind gleichermaszen Chance, Krise und Herausforderung
sowohl fuer die Nutzer/Anwender als auch fuer die Entwickler!

Davon bleiben zwei Aspekte natuerlich unberuehrt:
 1. Die Eroerterung ueber Aenderungen und Verbesserungen der eingebauten
    Vorgaben ist stets erwuenscht.
 2. Die Luecke, optionale oder alternative Moeglichkeiten nicht genuegend
    mit zusaetzlichem Material zu unterstuetzen, ist noch viel zu grosz.


Wie gesagt, wir sprechen hier als System- und/oder Netzwerkadminstratoren;
deshalb meine ich, daß das (Skript) gar nie die "richtige" Netzwerkstruktur
kennen würde und deshalb - IMHO - Skolelinux eher die Möglichkeit zur
Änderungen der zugrundezulegenden Struktur, denn eine "richtige" Struktur
bereitstellen sollte.

ACK. Vgl. Punkt 2 darueber.


Beste Gruesze,
  Patrick



Reply to: