Schlagwort-Archiv: Netzwerk

Domain Name System mit Bind9

Zur Zeit bereite ich mich wieder auf eine neue LPI-Prüfung vor, dieses Jahr steht Nummer 201 an. Darin geht es um Themen wie Linux Kernel kompilieren, patchen, Source kompilieren, Kernelmodule, Startup-Scripts, Grubshell, Filesystem, RAID und LVM oder Netzwerkkonfiguration und DNS.
Eigentlich alles gar nicht so schwer, wäre da nur nicht die Tatsache, dass keine Unterlagen verwendet werden dürfen!

Also will ich mich mal ans repetieren machen und beginne mit DNS, genauer Bind9 einrichten und konfigurieren. Später folgen dann nach und nach noch all die anderen Themen, wodurch eine Artikelserie daraus werden wird.

Doch zuerst zu DNS! Obwohl eigentlich sollte man es eher als Namensauflösung bezeichnen, denn es werden noch Dienste wie NIS oder Dateien wie /etc/hosts angesprochen.

Aber alles von vorne! Also die einfachste Möglichkeit zum eine IP-Adresse auflösen ist über die Hosts-Datei unter /etc/hosts. Diese könnte in etwa so aussehen:

root@master:/etc# cat /etc/hosts
127.0.0.1	localhost
127.0.1.1	master.encodingit.ch	master

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Jedoch wenn man mehr als nur ein, zwei Computer hat, so ist es relativ mühsam auf jedem diese Datei von Hand zu pflegen. Auch Sun bemerkte dies und entwickelte NIS (darüber habe ich schon mal geschrieben).
Doch als auch das nicht mehr reichte, kam man zu DNS.
Einfach gesagt ist es eine Hosts-Datei, welche an einem zentralen Ort verwaltet werden kann und von jeder Maschine bei Bedarf geladen wird. Komplizierter gesagt: dazu kommen wir noch

Die wichtigsten Dateien für die Namensauflösung auf einem Client wären dabei:

/etc/hosts > verantwortlich für die lokale Namensauflösung.
/etc/resolv.conf > gibt an, welche Nameserver angefragt und welche Domains durchsucht werden sollen.
/etc/nsswitch.conf > definiert die Reihenfolge ob zuerst der DNS, NIS oder die Hosts-Datei bei der Auflösung berücksichtigt werden soll.

Dies war alles auf dem Client – nun aber zu unserem DNS Server. Zuerst mal installieren:

apt-get install bind9

Weiterlesen →

Wenn man einfach abschreibt…

12 Antworten

Soeben bin ich auf diesen Beitrag gestossen.
Die News an sich interessiert nur zweitrangig, was mich aber ein bisschen stutzig macht, ist die folgende Hochrechnung:

[...] eine Internetgeschwindigkeit von 1,37 Gigabit pro Sekunde erreicht [...] Mit dieser Geschwindigkeit lässt sich beispielsweise ein HD-Film in weniger als 5 Sekunden herunterladen [...]

Ich mag irren, aber hier geht doch etwas nicht ganz auf…

1,37 Gigabit = 0.17125 Gigabyte

Geht man nun von einem sehr komprimierten HD-Film aus mit einer Grösse von etwa 4 Gigabyte so hätte man, um diesen zu übertragen, alleine schon über 20 Sekunden…

4 / 0.17125 = 23.357664234 Sekunden

Besonders lustig daran ist, dass viele IT-Magazine diese News anscheinend von der selben Quelle haben; welche genau das ist, versuche ich noch raus zu bekommen.

Aber eigentlich bin ich der Meinung, dass ein solch grober Schnitzer bei einer Fachzeitschrift nicht passieren darf…

Update 09:17
Wie es scheint, sitzt der Wurm direkt bei Cablecom. So taucht der Fehler schon in der offiziellen Pressemiteilung selbst auf.
Ich warte noch auf eine Stellungnahme von Cablecom!

Update 09:43
Klang heimlich hat man nun den offiziellen Pressetext angepasst. Zum Glück habe ich oben noch eine PDF-Version verlinkt
Eine Stellungnahme habe ich bisher aber immer noch nicht erhalten von Cablecom…

Aber so langsam frage ich mich echt über das Knowhow dieser Firma.
So hat man nun für die Ladezeit eines HD-Filmes einfach die von mir gemeldeten 20 Sekunden eingesetzt.

Das ich aber geschrieben habe “mehr als 20 Sekunden” hat man ignoriert.
So steht nun folgendes auf der Seite:

Mit dieser Geschwindigkeit lässt sich beispielsweise ein HD-Film in weniger als 20 Sekunden herunterladen oder mehr als 100 Lieblings-Songs in weniger als 1 Sekunde.

Stimmt also immer noch nicht!
Hätte der Zuständige beim Korrigieren nun noch seinen Kopf eingesetzt, so wären nämlich noch mehr Ungereimtheiten aufgetaucht!

100 Songs in 1 Sekunde
1 Song à 5 Megabyte

Das macht nach Adam Riese für alle Songs zusammen 500 Megabyte mit einem Durchsatz von 0.17125 Gigabyte / Sekunde eine Dauer von etwa 3 Sekunden…

Irgendwie armselig, wie wenig da mitgedacht wird! Hätte ich 10 Sekunden geschrieben, so würde in der Pressemitteilung nun sehr wahrscheinlich 10 Sekunden stehen…

Update 10:38

Soeben habe ich eine Nachricht von Cablecom erreicht! Vorweg möchte ich sagen, ein “Danke für den Hinweis” hätte gereicht, aber die Erklärungsversuche dieses netten Mitarbeiters machen alles nur noch schlimmer!

Ich zitiere einfach mal und fange beim ersten Satz an.

Wir sind für die Berechnung des Downloads von einer File-Grösse von rund 850Mb ausgegangen

Also den HD-Film mit 850 Megabyte möchte ich sehen…

Wir sind damit wohl etwas tief gelegen

Ach nee??

Wir haben daher neue Erkundigungen eingeholt und dabei den Grossteil der Filme (720p) auf Plattformen bei Dateigrössen zwischen 1 und 4 GB eingestuft

Was auch immer das für Plattformen sein mögen, lassen wir mal aussenvor. Aber HD ist bei mir im Normalfall zwischen 4 – 8 Gigabyte gross…

Ich frage mich gerade, ob ich dem geschätzten Mitarbeiter das wirklich noch erklären soll…

Update 11:05

Mittlerweile hat auch Swiss IT Magazine und Swiss IT Reseller ein kritisches Auge auf ihren Beitrag geworfen und diesen korrigiert.
Dieser Dachverband für viele IT-Fachseiten ist immerhin professionell genug ein Update zu veröffentlichen und nicht die Beiträge heimlich anzupassen!

Update 16.2.2011 16:45

Heise.de kommt wie die alte Fasnacht nach und kopiert den selben Fehler natürlich auch noch:

Letztere soll sich speziell für IP-Videoservices eignen. So wurde im Test denn auch ein kompletter HD-Film in nur fünf Sekunden übertragen.

Cisco running-config sichern

2 Antworten

Wer schon mal mit Cisco Geräten gearbeitet hat, wird das Problem kennen! Die Komponente wird nach langen Konfigurationen neu gestartet – Ups! Die running_config wurde nicht in den Speicher geschrieben… Der Aufwand von Stunden wurde somit innert Sekunden zerstört. Hätte man doch nur die Konfiguration vorweg mal gesichert…

Doch da kann Abhilfe geschaffen werden!
Um auf einfache Art und Weise die Konfiguration von einer Cisco Netzwerkkomponente zu sichern bietet sich TFTP an. Wer es etwas sicherer mag, der könnte natürlich auch FTP verwenden, jedoch wenn der Server nur für diese eine Funktion verwendet wird, so ist dies nicht zwingend nötig und verursacht nur mehr Aufwand.

Alles was ich dazu brauche ist neben meinen Netzwerkkomponenten ein TFTP-Server, wobei ich mich für Debian entschieden habe. Hierzu könnte aber auch Ubuntu, RedHat oder andere Distributionen verwendet werden. Mit TFTPD32 gibt es sogar eine Version für windowsbasierte Systeme.

Dazu muss zuerst der Server installiert werden:

1	apt-get install tftpd

Nun noch den Ordner für TFTP einstellen und schon fast fertig. Dazu kann in der Datei /etc/inetd.conf der letzte Punkt unter TFTP angepasst werden, auf was auch immer es euch beliebt :

1	tftp dgram udp wait nobody /usr/sbin/tcpd in.tftpd /tftpboot

Danach muss auf den entsprechenden Ordner noch die passenden Zugriffsrechte vergeben werden:

1	chmod -R 777 /usr/sbin/tcpd/

Nun kann auf dem Switch die Konfiguration übertragen werden:

Router#copy running-config tftp:
Address or name of remote host []? 192.168.1.1
Destination filename [Router-confg]? routerconf
 
Writing running-config...!!
[OK - 463 bytes]
 
463 bytes copied in 0.008 secs (57000 bytes/sec)
Router#

Damit aber das nicht immer manuell gemacht werden muss, wird der Befehl zeitgesteuert immer wieder ausgeführt.

Dafür kann Kron verwendet werden, welche seit IOS Version 12.3.1 integriert ist. Leider sind alle IOS im Packet Tracer noch mit älteren Versionen ausgestattet, wodurch dies ohne Hardware nicht so einfach getestet werden kann.

Eingerichtet wird Kron aber wie folgt:

1
2
3

kron policy-list backupconfig
cli copy running-config tftp://172.16.1.9
cli routerconf

Danach muss der Kron getimet werden. Wer das ganze tatsächlich als Ersatz für ein Vergessenes Write Memory einsetzen will, sollte natürlich einen kleineren Zeitabstand wählen:

1 2	kron occurrence week in 7:1:30 recurring policy-list backupconfig

Nun kann man sich die gespeicherten Kron-Jobs anzeigen lassen:

1	show kron schedule

Wenn nun etwas schief gehen soll oder sonst etwas, so kann eine Konfiguration wieder zurück gespielt werden:

Router#copy tftp: running-config
Address or name of remote host []? 192.168.1.1
Source filename []? routerconf
Destination filename [running-config]? 
 
Accessing tftp://192.168.1.1/routerconf...
Loading routerconf from 192.168.1.1: !
[OK - 463 bytes]
 
463 bytes copied in 0.006 secs (77166 bytes/sec)
Router#
%SYS-5-CONFIG_I: Configured from console by console
Router#

Ganz zum Schluss das Festschreiben der Konfiguration nicht vergessen

Ganz nützlich ist diese Funktion auch, wenn man mehrere gleiche oder ähnliche Netzwerkkomponenten mit gleicher oder nur leicht abgeänderter Konfiguration in Betrieb nehmen möchte.
Dazu muss lediglich die Konfiguration weg kopiert, mit einem Texteditor bearbeitet werden und dann auf die passenden Komponenten wieder aufgespielt werden.

Wer es gerne auch ausprobieren möchte, der kann dieses kurz mit dem Cisco Packet Tracer durchspielen:

Der (Ur-)Verzeichnisdienst NIS / YP

1 Antwort

Noch bevor LDAP oder Kerberos sich etablieren konnten, war ein Verzeichnisdienst mit dem Namen YP für Yellow Pages und später NIS für Network Information Service in aller Munde. Es war ein Produkt entwickelt von Sun, wodurch man Logininformationen über mehrere Computer hinweg verteilen konnte.

Auch wenn NIS als älter und unsicherer gilt als LDAP, hat es für mich ein klarer Vorteil: es ändert sich nicht immer komplett!
Wer schon mal ein LDAP auf einem Ubuntu Server 8.04 und 8.10 installiert hat, kann nachvollziehen was ich meine. So und damit genug, ich will hier nicht über LDAP herziehen, sondern NIS vorstellen

Ich habe mir also mit NIS und NFS innert wenigen Minuten eine zentrale Benutzerverwaltung mit zentralem Homeverzeichnis eingerichtet. Und wie das geht, folgt hier:

Ich habe mit dem NIS Server begonnen und dazu die Pakete für NFS und NIS aus den Paketquellen installiert.

1	apt-get install nfs-kernel-server nis

Während der Installation, nachdem man einen Namen für die Domäne eingegeben hat, versucht apt automatisch den NIS Daemon zu starten, was auf Grund mangelnden Einstellungen aber nie funktionieren wird. Also zurück lehnen, und auf den Fehler warten

Nun beginnt die Konfiguration. In der Datei /etc/default/nis wird die NIS-Installation von Client zum Server umgebogen:

# Are we a NIS server and if so what kind (values: false, slave, master)?
NISSERVER=true
# Are we a NIS client?
NISCLIENT=false

Dann geben wir in der Datei /etc/exports unser Homeverzeichnis frei:

1	/home *(rw,async,no_subtree_check)

Wer es gern sicherer hat, kann den Stern durch einen Computernamen oder eine IP mit Subnet ersetzen, wodurch dann nur der Zugriff von diesen Maschinen aus gestattet ist.

Nun kann man den Daemon neu starten:

1	/etc/init.d/nis restart

Und zum Abschluss muss man noch die Maps generieren lassen. Dazu ruft man folgenden Befehl auf: