apt-get install firmware-bnx2

Die Voraussetzung ist natürlich, dass die non-free Paketquellen eingebunden sind.

Die Niederländer hatten auch schon vorherigen OMSA Versionen als dep-File bereit gestellt. Siehe hierzu:

• Dell Open Manage Server Agent 5.5 für Debian und Ubuntu
• Dell Open Manage Server Agent 5.4 für Debian und Ubuntu
• Dell Open Manage Server Agent 5.3 für Debian und Ubuntu
• Dell Open Manage Server Agent 5.2 für Debian und Ubuntu
• Dell Open Manage Server Agent 5.1 für Debian und Ubuntu

Datensicherung
Als erstes sollte das bestehende System mit einer Datensicherungssoftware gesichert werden. Dazu kommen eine ganze Reihe von Programmen wie cpio, tar, amanda oder rsnapshot infrage. Nähere Infos zu Backupsoftware unter Linux kann man in meinem Artikel Backup-Software für Linux nachlesen.

Danach sollte eine Liste der Installierten Software-Pakete erstellt werden, damit man im Notfall wieder ein System mit identischer Software installieren kann. Eine Anleitung dazu ist in meinem Artikel Ubuntu/Debian: Die gleiche Software auf einem neuen Computer installieren zu finden.

Einspielung aller Updates für das bestehende Debian
Bevor das eigentliche Upgrade auf die Version 5.0 gemacht wird sollten alle Updates für die alte Version eingespielt werden. Dazu muss zunächst die source-list aktualisiert werden:

aptitude update

Danach können die Updates installiert werden:

aptitude upgrade

Anpassen der sources-list
Damit die neuen Pakete gefunden werden, muss in der source-list das Wort etch gegen lenny getauschen werden. Die source-list befindet sich in der Datei /etc/apt/sources.list. Die Datei sollte nach den Änderungen etwa wie folgt aussehen:

deb http://ftp.de.debian.org/debian/ lenny main
deb http://ftp.de.debian.org/debian/ lenny contrib
deb http://ftp.de.debian.org/debian/ lenny non-free
deb-src http://ftp.de.debian.org/debian/ lenny main

# Security-Updates
deb http://security.debian.org/ lenny/updates main contrib
deb-src http://security.debian.org/ lenny/updates main contrib

Upgrade
Nun muss erneut die source-list aktualisiert werden:

aptitude update

Danach werden zuerst die Update-Werkzeuge aktualisiert:

aptitude install apt dpkg aptitude

Zum Schluss wird dann der Rest der Pakete aktualisiert:

aptitude full-upgrade

Während der Aktualisierung der einzelnen Software-Pakete wird dann ab und zu noch die ein oder andere Frage gestellt, bevor der abschließende Neustart fällig wird. Nach dem Neustart ist das Upgrade abgeschlossen.

1. Die Paketliste des alten Computer in eine Datei sichern

   dpkg --get-selections "*" > paketliste.txt

2. Die Pake aus der Datei bei dem neuen Computer auswählen

   dpkg --set-selections < paketliste.txt

3. Die Pakete auf dem neuen Computer installieren

   apt-get dselect-upgrade

Dabei ist zu beachten, dass das ganze natürlich nur mit Root-Rechten funktioniert!

Die Niederländer hatten auch schon die vorherigen OMSA Versionen als dep-File bereit gestellt. Zuletzt hatten sie am 28. April den OMSA 5.4 veröffentlicht. Zuvor wurden aber auch der OMSA 5.3, OMSA 5.2 und OMSA 5.1 als dep-File veröffentlicht.

Die Niederländer hatten auch schon die OMSA Version 5.3, OMSA Version 5.2 und die OMSA Version 5.1 als dep-File veröffentlicht.

Bei Debian bekommt man alle benötigten Pakete, wenn man mit aptitude die dep-Files samba, winbind und heimdal-clients installiert. Die restlichen Pakete werden dabei durch die Abhängigkeiten automatisch installiert.

Als erstes muss Kerberos eingerichtet werden. Dazu muss die Konfigurationsdatei /etc/krb5.conf angepasst werden. Sie sollte hinterher in etwa wie folgt aussehen:

[libdefaults]
        default_realm = BUTTERNET.BIZ
        krb4_config = /etc/krb.conf
        krb4_realms = /etc/krb.realms
        kdc_timesync = 1
        ccache_type = 4
        forwardable = true
        proxiable = true

        v4_instance_resolve = false
        v4_name_convert = {
                host = {
                        rcmd = host
                        ftp = ftp
                }
                plain = {
                        something = something-else
                }
        }
        fcc-mit-ticketflags = true

[realms]
        BUTTERNET.BIZ = {
                kdc = server01.butternet.biz
                kdc = server02.butternet.biz
                admin_server = server01.butternet.biz
        }

[domain_realm]

[login]
        krb4_convert = true
        krb4_get_tickets = false

Danach kann man mit kinit user und klist testen, ob man ein Ticket von dem Kerberos-Server (Windows Domain Controller) bekommen hat.

Nachdem Kerberos läuft muss Samba angepasst werden. Dazu müssen die globalen Parameter in der Konfigurationsdatei /etc/samba/smb.conf wie folgt angepasst werden:

# Global parameters
[global]
workgroup = BUTTERNET
netbios name = GARGOYLE
realm = BUTTERNET.BIZ
security = ADS
template shell = /bin/bash
idmap uid = 500-10000000
idmap gid = 500-10000000
winbind use default domain = Yes
winbind nested groups = Yes

Eine genaue Beschreibung der nötigen Parameter ist auf Webseite des Samba-Projektes zu finden.

Danach muss dem Linux-Server noch beigebracht werden winbind zu benutzen. Er soll ja nicht nur die lokalen User, Passworte und Gruppen kennen, sondern auch die des Active Directory. Dazu muss die Datei /etc/nsswitch.conf wie folgt angepaßt werden:

...
passwd: files winbind
shadow: files winbind
group:  files winbind
...
hosts:  files [dns] wins
...

Zum Schluss muss man mit dem Befehl net ads join -UAdministrator%passwort den Samba-Server der Windows Domäne beitreten lassen. Danach kann man mit dem Befehl net ads testjoin testen, ob der Server ein Mitglied der Domäne ist. Des weiteren sollte der Befehlt wbinfo -u alle Benutzer des AD anzeigen.

Nachdem die Konfiguration wie oben beschrieben getätigt ist, sollten Zugriffe von von Windows-Usern auf den Samba-Server möglich sein. Sie sollten z.B. auf die Freigabe testfreigabe zugreifen können, wenn in der Datei /etc/samba/smb.conf die folgende Freigabe konfiguriert wird:

[testfreigabe]
        comment = Testfreigabe
        inherit acls = Yes
        path = /home/irgendeinverzeichnis
        read only = No

Die Voraussetzung ist natürlich, dass es ein Verzeichnis /home/irgendeinverzeichnis gibt und der Benutzer die notwendigen Berechtigungen hat

Die Niederländer hatten auch schon die OMSA Version 5.2 und die OMSA Version 5.1 als dep-File veröffentlicht.

Aufgabenstellung
Es wird ein HTTP-Proxy für ca. 30 Benutzer benötigt. Die Benutzer sollen sich für Internetzugriffe authentifizieren und teilweise nur zugriff auf bestimmte Internetseiten bekommen. Die Anmeldenamen und Passwörter dafür sind in einem Active Directory hinterlegt. Bei jedem Zugriff soll der Squid also bei einem Windows Domain Controller nachfragen, ob der Benutzer existiert und ob er Internetseiten sehen darf.

Installation
Als Server habe ich einen IBM HS21 Blade mit einer 2 GHz Xeon Dual Core CPU, 1 GB Hauptspeicher und einem Debian Linux 4.0 (64 Bit) verwendet. Er hatte bereits einige andere Aufgaben, die ihn aber kaum auslasteten.
Bei Squid habe ich die PRE5-Version verwendet. Diese kann man bei Debian 4.0 mit dem Befehlt aptitude install squid3 installieren. Das STABLE2-Paket gibt es nur für den “testing-Zweig” von Debian und es ist wegen einigen Abhängigkeiten nicht so einfach zu installieren. Alle aktuellen Debian-Pakete von Squid 3.0 sind unter http://packages.debian.org/squid3 zu finden.

Konfiguration der Authentifizierung
Um die Anmeldenamen und Passwörter abzufragen, habe ich im Active Directory einen Benutzer SquidAuth und die Gruppe InternetZugang angelegt. Der Benutzer sollte aus Sicherheitsgründen keine vollen Admin-Rechte bekommen. Für das abfragen der Gruppenmitgliedschaft reicht es, wenn er Mitglied in der Gruppe RAS- IAS-Server ist. Falls man die Mitgliedschaften von Gruppen nicht braucht und nur den Benutzernamen und das Passwort gegen den Windows Domain Controller Authentifizieren möchte, reichen sogar normale Benutzerrechte!
Danach habe ich die Konfigurationsdatei des Squid (/etc/squid3/squid.conf) entsprechend erweitert. Wenn der befragte Windows Domain Controller ein Global Catalog Server ist, sollte der Port 3268 anstelle von Port 389 (wie eigentlich bei LDAP üblich) verwendet werden.
Falls sich ein Windows Domain Controller (der auch Global Catalog Server ist) mit der IP-Adresse 192.168.140.11 für die Domäne DOMAIN.local verantwortlich fühlt und das LAN den IP-Bereich 192.168.140.0/24 hat, könnte die Erweiterung etwa wie folgt aussehen:

# Authentifizierung an Active Directory
auth_param basic program /usr/lib/squid3/squid_ldap_auth -R -b "dc=DOMAIN,dc=local" -D "cn=SquidAuth,cn=Users,dc=DOMAIN,dc=local" -w "password" -f sAMAccountName=%s -h 192.168.140.11:3268
auth_param basic children 5
auth_param basic realm "Proxy Authentifizierung. Bitte geben Sie Ihren Benutzername und Ihr Passwort ein!"
auth_param credentialsttl 2 hours

external_acl_type InetGroup %LOGIN /usr/lib/squid3/squid_ldap_group -R -b "dc=DOMAIN,dc=local" -D "cn=SquidAuth,cn=Users,dc=DOMAIN,dc=local" -w "password" -f "(&(objectclass=person)(sAMAccountName=%v) (memberof=cn=%a,cn=Users,dc=DOMAIN,dc=local))" -h 192.168.140.11:3268

acl localnet proxy_auth REQUIRED
acl InetAccess external InetGroup InternetZugang
http_access allow InetAccess

Danach fragt Squid beim Aufruf einer Webseite nach einem Benutzernamen und Passwort. Des weiteren erhalten nur noch die Mitglieder der Gruppe InternetZugang Internetzugriff.

Fazit
Der Squid läuft jetzt seit 14 Tagen ohne Probleme. Bis jetzt habe ich keine Probleme mit Webseiten festgestellt. Sogar das Microsoft Windows Update läuft jetzt. Bei den alten Versionen von Squid funktionierte es meist nicht richtig.

Nachdem ich nach einer Suche im Internet auch nicht schlauer war, habe ich den Support von Avira angerufen. Dabei stellte sich heraus, dass AntiVir Unix Server bis jetzt nur mit 32 Bit läuft. Deshalb muss bei einer 64 Bit Installation von Debian 4.0 das Paket ia32-libs installiert sein. Nadem ich mit “aptitude install ia32-libs” das Paket installiert hatte, lief auch die das Installationsskript ohne Probleme.