Archiv für Juni 2009

Stale NFS file handle

Dienstag, 30. Juni 2009

…taucht beim mounten eines NFS-Shares auf. Ursache kann sein: War beim unexport auf dem NFS-Server auf einem Client gemounted. Dann funktioniert das direkte Neumounten auf dem Client nach dem Reexport nicht. Abhilfe war: Unexport, Export again:
nano /etc/exports && exportfs -arv && nano /etc/exports && exportfs -arv

Windows-Share mounten mit Umlauten in Dateinamen

Montag, 15. Juni 2009

Seit einer bestimmten Version mag smbmount die Option codepage=… nicht mehr, um die Kodierung der zu mountenden Quelle anzugeben. (deprecated..) Ohne die sind jedoch Umlaute teils falsch. Beim Mounten per cifs gibt es jedoch kein Problem, hier reicht es sogar nur den lokalen Zeichensatz anzugeben (in dem Fall utf8):

mount -t cifs //windowsserver/freigabe /mnt/freigabe -o user=benutzername,iocharset=utf8

Realtek 1Gbit onboard-Karte (Kernelmodul r8169) stinkt zum Himmel

Donnerstag, 11. Juni 2009

Betrifft: Ubuntu 9.04, Kernel 2.6.28-11-server

Diese verdammte Realtek onboard-Netzwerkkarte schafft mit dem r8169-Modul, das Ubuntu standardmäßig lädt, gerade einmal vom Samba 500 kB in der Sekunde, davon abgesehen, dass aus dem Quellnetzwerk ein Ping auf den Server jedes 10. Mal nicht ankommt und Dateien von mehr als ein paar kilobyte überhaupt nicht auf einem Samba-Share landen. Es gibt zwar neue Treiber auf der Realtek-Seite, die man sich zusammenkompilieren kann, mit denen ist es aber auch nicht besser. Hilft alles nichts, andere PCI-Netzwerkkarte rein und alles läuft wunderbar.

Bug ist bekannt:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/76489

Bei der Gelegenheit mal /etc/udev/rules.d/… angeschaut, um Interface-Namen zu ändern. So kann die neue Netzwerkkarte wieder eth0 werden und den onboard-Schrott ablösen.

EDIT: Mit einer Intel Gigabit-PCI-Karte (Modul e1000) keinerlei Probleme. Die Sis900 (100Mbit) dagegen hatte pro Sekunde etwa 5 corrupted package Meldungen in den Logs erzeugt. Bei viel Traffic auf dem Interface wurde z.B. das Routing dadurch sehr langsam. Gelernt: Onboard pfui, Marke hui.

Ubuntu als DSL-Router / Mini-Iptables-Howto / Kleine feine Firewall / …

Donnerstag, 11. Juni 2009

Die Konfiguration der DSL-Leitung ist mit pppoeconf leicht. Wenn der Rechner selbst darüber ins Netz kommt und Domainnamen auflöst (pppoeconf richtet das automatisch mit ein), sind die Iptables anzupassen. Es gibt Pakete ipmasq oder ufw (uncomplicated firewall – die aber gar nicht so uncomplicated ist), mit denen man direkt nach der Installation schon ein Masquerading hinbekommt, aber wofür 5 Tonnen Script-Salat für ein paar einfach Rules.

Hier ein Dump meiner Konfiguration – transparent und simpel integriert. Der Router hat die IP 10.0.0.1 an eth0, DSL hängt am Interface ppp0.

Skript /etc/iptables.sh

#! /bin/sh

echo „1“ > /proc/sys/net/ipv4/ip_forward # Initialisierung des Forwardings
##################################
# Flushen, Loeschen,
##################################
iptables -F
iptables -F -t nat
iptables -F -t mangle

iptables -X
iptables -t mangle -X
iptables -t nat -X

################
# INPUT Firewall
#################

iptables -A INPUT -i lo -j ACCEPT
#Loopback immer akzeptieren

iptables -A INPUT -i eth0 -s ! 10.0.0.0/255.255.255.0 -j DROP
# Alles aus dem lan ohne passende IP wegwerfen

iptables -A INPUT -i eth0 -j ACCEPT
# Sonst alles von eth0 erlauben

iptables -A INPUT -i ppp0 -s 10.0.0.0/255.255.255.0 -j DROP
# Alles aus dem Inet mit meinen IPs werwerfen

# Antworten zulassen
iptables -A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT

# Alles andere abweisen
iptables -P INPUT DROP

#####################
# Forward-Chain
#####################

iptables -A FORWARD -i lo -j ACCEPT
# Loopback wieder erlauben

iptables -A FORWARD -s 10.0.0.0/24 -i eth0 -j ACCEPT
# Traffic aus dem lokalen Netz ist ok

iptables -A FORWARD -d 10.0.0.0/24 -m state –state RELATED,ESTABLISHED -o eth0 -j ACCEPT
# Traffic in das lokale Netz ist bei bekannten Verbindungen ok

iptables -P FORWARD DROP
# Der Rest ist boese

###################
# Output-Chain
###################

iptables -P OUTPUT ACCEPT # output immer annehmen
iptables -P OUTPUT ACCEPT -t nat

######
# NAT
#######
iptables -A POSTROUTING -t nat -s 10.0.0.0/24 -j MASQUERADE # was rausgeht wird maskiert
##################
# User Config
#################
# Folgende Ports sollen nach ppp0 offen sein
iptables -A INPUT -p tcp –dport 22 -j ACCEPT # ssh erlauben
iptables -A INPUT -p tcp –dport 443 -j ACCEPT # https erlauben
iptables -A INPUT -p tcp –dport 3389 -j ACCEPT # RDP erlauben
################
# Portforwarding
###############

# Auch unbekannte Verbindungen muessen weitergeleitet werden
iptables -A FORWARD -p tcp -d 10.0.0.10 –dport 443 -j ACCEPT
iptables -A FORWARD -p tcp -d 10.0.0.10 –dport 3389 -j ACCEPT

# Zuletzt sollen die Pakete ge-DNAT-ted werden
iptables -A PREROUTING -t nat -i ppp0 -p tcp –dport 443 -j DNAT –to 10.0.0.10         # OWA auf Windows-Server
iptables -A PREROUTING -t nat -i ppp0 -p tcp –dport 3389 -j DNAT –to 10.0.0.10        # RDP auf Windows-Server

 

echo “ [Iptables set]“

Enthalten ist hier auch ein „Portforwarding“ auf einen zweiten Rechner 10.0.0.10. Ist die Iptable zunächst leer, so bekommt man nach dem Ausführen dieses Scripts schon eine fertige Firewall mit NAT. Mit UFW und Ipmasq entsteht hingegen ein Wust an Chains. Mal eben ein DNAT machen ist mir damit nicht gelungen.

Damit man die Firewall noch schön ins System integriert noch folgendes Hilfsskript /etc/iptables_flush.sh

#!/bin/sh

#
# Set the default policy
#
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

#
# Set the default policy for the NAT table
#
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT

#
# Delete all rules
#
iptables -F
iptables -t nat -F

#
# Delete all chains
#

iptables -X
iptables -t nat -X

# End message
echo “ [End of flush]“

Hier werden die Policies alle auf ACCEPT gesetzt, also aufgepasst, das ist kein Dauerzustand; hat aber den Vorteil, dass man noch z.B. per SSH Zugriff hat, sonst geht das Gerenne zum Server los :-)

Schließlich noch ein Initscript gebastelt – /etc/init.d/firewall

#!/bin/bash

RETVAL=0

# To start the firewall
start() {
  echo -n „Iptables rules creation: “
  /etc/iptables.sh
  RETVAL=0
}

# To stop the firewall
stop() {
  echo -n „Removing all iptables rules: “
  /etc/iptables_flush.sh
  RETVAL=0
}

case $1 in
  start)
    start
    ;;
  stop)
    stop
    ;;
  restart)
    stop
    start
    ;;
  status)
    /sbin/iptables -L
    /sbin/iptables -t nat -L
    RETVAL=0
    ;;
  *)
    echo „Usage: firewall {start|stop|restart|status}“
    RETVAL=1
esac

exit

Nun mit update-rc.d firewall defaults das Init-Script in die /etc/rcX.d eintragen lassen. Sobald man an der /etc/iptables.sh Änderungen macht, sind sie somit nach einem /etc/init.d/firewall restart da.

Inspiriert von:
http://ubuntuforums.org/showthread.php?t=159661
https://help.ubuntu.com/community/IptablesHowTo
und anderen einschlägigen Google-Such-Stichworten

Ubuntu DHCP3 und Bind9 mit DDNS

Mittwoch, 10. Juni 2009

Damit der dhcp3-server automatische Dns-Updates in Bind macht ist folgendes nötig. In diesem Beispiel laufen beide Server auf dem selben Rechner mit Ip 10.0.0.1, der in der privaten Domäne home.local sitzt.

Bind

named.conf hinzufügen:

//localhost updates erlauben
controls {
inet 127.0.0.1 allow {localhost; } keys { „rndc-key“; };
};

named.conf.local enthält die lokalen Zonen:

zone „home.local“ {
type master;
file „/var/cache/bind/db.home“;
allow-update { key „rndc-key“; };
notify yes;
};

zone „0.0.10.in-addr.arpa“ {
type master;
file „/var/cache/bind/db.10.0.0“;
allow-update { key „rndc-key“; };
notify yes;
};

include „/etc/bind/rndc.key“;

Das File /etc/bind/rndc.key enthält einen Key, mit dem sich dann der DHCP an Bind für Updates authentifizieren kann. Die Dateien db.home für den Vorwärts- und db.10.0.0 für Reverse-Lookup liegen original in /etc/bind (durch kopieren und sinngemäßem Anpassen einer bestehenden, z.b: db.empty, erzeugen). In /var/cache/bind werden Symlinks angelegt. Grund: Bind will temporäre Dateien erstellen, was ihm nur dort erlaubt ist.

DHCP

Zunächst muss die /etc/bind/rndc.key nach /etc/dhcp3 kopiert werden und dhcpd zum Owner gemacht werden, damit der DHCP-Daemon die Datei lesen kann. Ihm wird folgendermaßen noch beigebracht, dynamische DNS-Updates zu machen.

In der dhcpd.conf:

ddns-updates    on;
ddns-update-style interim;
ddns-rev-domainname     „in-addr.arpa.“;
ignore  client-updates;
include „/etc/dhcp3/rndc.key“;

interim scheint der einzige sinnvolle Modus zu sein. Client-Updates werden nicht zugelassen, nur der DHCP soll die Einträge vornehmen. Durch Einbinden der kopierten rndc.key kann sich der DHCP nun bei Bind einschmeicheln.

Im weiteren Teil der Config muss in dem Subnet (so wie folgend, oder auch global) die zu aktualisierende Zone angegeben werden. Hier beispielhaft für eine Adressvergabe von 10.0.0.100 bis 10.0.0.200 und den Zonen, die identisch lauten wie die in Bind definierten. (Hier ist der Server 10.0.0.1 zugleich auch Gateway)

subnet 10.0.0.0 netmask 255.255.255.0 {
range 10.0.0.100 10.0.0.200;
option subnet-mask 255.255.255.0;
option routers 10.0.0.1;
option broadcast-address 10.0.0.255;
option domain-name-servers 10.0.0.1;

zone 0.0.10.in-addr.arpa. {
primary 10.0.0.1;
key     „rndc-key“;
}

zone home.local. {
primary 10.0.0.1;
key     „rndc-key“;
}
}