- Konzept/Druckkontingent

Druckkontingent

Anforderungen Druckkontingent

• Das Durckkontingent wird zentral gespeichert
• Das Druckkontingent wird im LDAP gespeichert
• Das Druckkontingent wird nur einmal fuer einen User gespeichert
• Das Druckkontingent wird als unsigned Integer gespeichert
  • (Weil Floating Point Values Rundungsfehler und Darstellungsfehler auf Rechner aufweisen)
• Die Waehrungssystemeinheit wird nicht mit dem Value gespeichert
• Die Waehrungssystemeinheit gilt fuer alle Konten des Systems
• Der Nutzer ist auch ohne Software ueber Probleme zu informieren
• Der Nutzer ist auch ohne Software ueber Kontostand zu informieren
• Jeder Druckjob muss eine Bannerpage haben.

Konzept 1: Umsetzung mit LPRng

Es gibt mit CipUX 1.0 und CipUX 2.0 bereits eine Umsetzung eines Accounting Systems unter LPRng.

Genauere Beschreibung siehe CipUX Handbuch 1.0

Vorteile

• Echter Hardwarecounter
• Robust, zuverlaessig
• Bereits implementiert
• Lauft seit 8 Jahren stoerungsfrei

Nachteile

• LPRng ist nicht Teil der Standard DebianEdu Distribution

• LPRng wird von fast keiner grossen Distribution mehr verwendet
• Die Wahl des Druckers haengt von der Existenz eines Hardware Counters ab
• Drucker ohne Hardware Counter werden nicht unterstuetzt
• Uebernahme der alten Implementierung bedarf eines dezidierten Printservers

Fazit

Die aktuelle LPRng Implementation ist in die Jahre gekommen und der Support von LPRng steht auch in Frage. Zudem ist die Ausrichtung nur auf Hardware Counter ein limitierender Faktor, der gerade im Schulumfeld, wo billige Drucker eingesetzt werden, zum tragen kommt.

Daraus folgt das eine Neuimplementierung ratsam ist.

Ein wichtiger Hinweis: Wenn eine neue Implementation auf Software Countern basiert, kann sie technisch nicht so gut werden wie eine auf Hardware Countern basierte Loesung. Dafuer kann sie aber flexibler und guenstiger in der Hardwareanforderungen sein.

Konzept 2: Umsetzung mit CUPS und Software Seitenzaehlung

Hier eine grobe Skizzierung der Funktion:

• Auf allen Systemen wird ein Postscripttreiber installiert, falls das
  • nicht sowieso der Fall ist.
• Der Druckjob wird auf dem Client generiert und in Empfang genommen,
  • wo er an einen zentralen Printserver weitergeleitet wird. (z.B. Tjener)
• Auf dem zentralen Server wird mittels post-Filters weitergeleitet
• Der Filter nimmt den Job entgegen und zaehlt seine Seiten
• Er ermittelt anhand eines zentralen Seitenpreises die voraussichtlichen
  • Kosten.
• Er schaut auf dem Konto des Nutzers nach ob genuegend Deckung vorhanden ist
• Ist genuegend Deckung vorhanden ...
  • ... er loescht ggf. den Fehlereintrag in dem Konto des Benutzers
  • ... bucht er die zu erwartenden Kosten vom Konto ab
  • ... und beendet sich ohne Fehler
• Ist nicht genuegend Deckung vorhanden ...
  • ... schreibt er eine Fehlermeldung in das Konto des Benutzers
  • ... beendet sich mit Fehler (Folge, das Druckjob bricht ab)
• Dann wird eine Bannerpage gedrucket (durch ein Skript)
  • Der Name wird gedruckt
  • Der Kontostand wird gedruckt
  • Das Fehlerfeld des Benutzerkontos wird gedurckt
    • (Entweder leer oder Meldung) Hierhaus kann der Benutzer erkennen, warum evtl nur eine Bannerpage herauskommt.
• Dann wirf ggf. der Job gedruckt oder an den entsprechenden
  • ausfuehrenden Printserver weitergeleitet.

Konzept 2a: Wie 2 nur mit verschiedenen Seitenpreisen pro Schule

Konzept 2 laesst sich erweitern indem man eine Matrix verwaltet, die unterschiedlichen Drucker unterschiedliche Seitenpreise zuordnet.

Anforderungen

• Ein Drucker hat einen Seitenpreis
• Ein anderer Drucker hat einen andern Seitenpreis
• Der Seitenpreises pro Drucker bleibt gleich

Wenn das gewuenscht wird, bedarf es

• Einer Geraeteklasse Drucker im LDA
• Einer einfachen LDAP Objekt Klasse "cipuxPrinter"
• Einiger weniger spezifischer LDAP Attribute fuer diese Klasse: "cipuxPagePrize"
• Eines Drucker-Registrierungs-Benutzer-Werkzeuges
• Eines Mechanismus der das beim Filter umsetzt.

Konzept 2b: Wie 2 nur mit verschiedenen Druckern in verschiedenen Raeumen.

Dieses Konzept wurde schon einmal als Einzelloesung umgesetzt und muesste nachimplementiert werden.

Anforderungen

• Ein Drucker pro Raum
• Der Job eines Nutzer soll automatisch in dem Raum gedruckt werden in dem
  • er sich gerade befindet

Umsetzung

• Der Filter sollte anhand des Computer Client Namens erkennen, welcher
  • Drucker in dem Raum steht und dort drucken.
• Steht kein Drucker im Raum sollte ein Zentraler Drucker als Druckernamen verwendet
  • werdent

Voraussichtlich werden die Computer Clients fuer Imageloesungen registert. D.h. es wird eine Benutzeroberflaeche fuer das Registrieren eines Computers geben. Entweder sind nun schon alle Computer registriert, oder man kann dieses CGI nehmen um Computer fuer gewisse Raeume zu registrieren.

Das Raumkonzept existiert bereits in CipUX.

Beispielsweise:

• Lege Raum R100 an
• Lege Drucker HP4100NT an
• Fuege Drucker dem Raum R100 hinzu
• Registriere die 16 Computer fuer Raum R100
• Schalte die globale Option "Auf dem naechstgelegenen Drucker drucken" ein

Dann gibt es im LDAP:

• Liste aller Raeume (ObjectClass cipuxRoom) (ObjectClass existiert bereits)

• Liste aller Drucker (objectClass cipuxPrinter) (ObjectClass existiert noch nicht)

• Liste aller Computer (objectClass cipuxMachine) (ObjectClass existiert bereits)

Der Druckertreiber auf dem Client kann fuer einen beliebigen Postscriptprinter installiert sein der auf den zentralen Printserver (Tjener) verweist, der Filter kann dann aus der obigen 3D Matrix den richtigen Drucker Namen erkennen.

Das hat den Vorteil:

• Man kann den Computer von einem Raum zum anderen Raum tragen und braucht
  • sich nicht um den Treiber oder die Druckerzugehoerigkeit zu kuemmern, weil das zentral dispatched wird.

Konzept 2c: Konzept 2a + Konzept 2b