Das Samba-Team will von nun an mit Volldampf an der Version 3.0 arbeiten, die zum Herbst erscheinen soll und u.a. vollständige Active Directory-Unterstützung (LDAP mit Kerberos und DNS kombiniert) enthalten wird.
Die 2.2.4 wird von vielen Administratoren bereits sehnlichst erwartet, falls sie die neuen Druckfunktionen für WinNT/2000-clients einsetzen. Diese sind in der letzten Version (2.2.3a) fehlerhaft. Diese Funktionen erlauben es, Drucker und Jobs über MS-RPC (Microsoft Remote Procedure Calls) zu administrieren.
Es ist möglich, Drucker-Treiber auf die Clients von einer speziellen Freigabe auf dem Samba-Server herunterzuladen. Diese Freigabe muss [print$] heissen. Wenn sie existiert und der Treiber dort korrekt "installiert" ist, kann sich jeder Client-Benutzer den Treiber bei Erstkontakt mit der entsprechenden Drucker-Share installieren. Dafür genügt eine einziger Mausklick.
Andererseits kann man (sofern man mit den entsprechenden Administrationsrechten ausgestattet ist), auch von einem WinNT/2K Client aus die Treiber für einen bereits installierten Drucker auf die Samba-[print$]-Share hochladen. Hierfür verwendet man ganz einfach den "Add Printer Wizard", wie er in der Netzwerkumgebung in der "Drucker"-Freigabe des Samba-Servers für Administratoren sichtbar ist. Der AWP heisst auf deutschen MS-Systemen "Druckerinstallations-Assistent" und verbirgt sich bei Win2K beispielsweise hinter dem Icon "Neuer Drucker".
Weitere "Goodies" sind:
ein Tool (tdbbackup), welches Samba-tdb's (interne Datenbankstrukuren zum Abspeichern von Benutzer-, Drucker- und anderen Informationen) sichern und wiederherstellen kann;
ein "Papierkorb" (zum "Löschen" von Dateien mit Wiederherstellungsmöglichkeit);
mehrere Bugfixes betreffend die MS-DFS (Distributed File System)-Unterstützung, Unterstützung von Datenbank-Files (Access und Foxpro).
Der bereits vorhandene CUPS-Support als "klassischer" Printserver wurde um eine zusätzliche Funktion ergänzt: Im "klassischen" Fall wird der Hersteller-Treiber für den Zieldrucker auf dem Client installiert; der Treiber läuft dort und generiert die "fertige" Druckdatei in der Sprache des Zieldruckers selbst, wobei der "Printserver" nur noch Spoolen muss (dieser Modus wird von CUPS natürlich nach wie vor unterstützt); in einem weiteren Anwendungsfall wird auf den Clients ein Adobe PostScript-Treiber installiert, ergänzt um die CUPS-PPD (die von CUPS selbst, oder von ESP PrintPro, Gimp-Print, PPD-O-Matic usw. stammen kann); die Clients schicken PostScript, welches der CUPS-Server automatisch durch seinen internen PostScript Interpreter (RIP) in das Format des Zieldrucker konvertiert. Beide Konfigurationen können problemlos parallel und gemischt betrieben werden. Die Methode "CUPS als PostScript-RIP" hat ihre besonderen Reize...
In Umgebungen mit Windows Terminal Servern (WTS), die unter notorischer Instabilität leiden, sobald darauf zu viele verschiedene Druckertreiber aktiviert sind -- diese können jetzt auf einen einzigen stabilen PostScript-Treiber konsolidieren, wobei alle Anwender-Optionen (Duplexdruck, Papierfach-Wahl, etc.) erhalten bleiben.
In Umgebungen, die ein zentrales Accounting mit Kostenstellen-Zuordnung erfordern - denn CUPS führt über jede gedruckte Seite ein Log, das nachträglich mit geeigneten Tools ausgewertet werden kann.
Um die Funktion "CUPS als PostScript-RIP für Windows-Clients" zu nutzen, muss lediglich der CUPS-Treiber mittels des CUPS-Utilities "cupsaddsmb" für Samba aktiviert werden. Bei KDEPrint-3.0 ist eine entsprechende Funktion ebenfalls bereits eingebaut. Das Samba-Team empfiehlt, diese 2.2.4 Release für alle Produktionssysteme zu verwenden, um bekannte Fehler zu beheben.
