Brother HL-2030 Drucker einrichten unter OpenBSD / cups

Wenn nicht, wie kommst du auf den schmalen trichter hier mehr Kompetenz zu haben?

Nein, ich will nur keinen neuen Drucker kaufen...

Also nicht sicher im sinne von "ich habs irgendwo online gelesen" sondern im sinne von "ich hab das an irgend einer stelle in meinem System gesehen.

Ihr seid sehr sehr hilfsbereit, und trotzdem muß ich teilweise raten. Um einen Vergleich zu ziehen, ja wo das Gaspedal ist glaube ich zu wissen und vom Ölmessstab habe ich auch schon mal gehört.

Ich merke an mir selber immer wieder, daß grundlegendes Verständnis fehlt und mein Englisch ist auch eher bescheiden. Nur ich kann mir deswegen nicht gleich neue Hardware kaufen. Daß das Ding läuft und läuft und läuft darf ich nach 20 Jahren wohl behaupten.

Und ich bin kein Power-User, der jeden Tag was zu drucken hat.

Code:
ulpt0 at uhub5 port 2 configuration 1 interface 0 "Brother HL-2030 series" rev 2.00/1.00 addr 5
ulpt0: using bi-directional mode
ulpt0 detached
ulpt0 at uhub5 port 2 configuration 1 interface 0 "Brother HL-2030 series" rev 2.00/1.00 addr 5
ulpt0: using bi-directional mode
 
Die PPD-Datei (PPD=PostscriptPrinterDescription) enthält quasi eine Beschreibung des Druckers und sagt CUPS gegebenenfalls auch noch, was benötigt wird und wo ggf. externe Programme liegen ums in die native Druckersprache zu übersetzen.
ppd's zwischen Linux und OpenBSD austauschen hat bei mir nie funktioniert.
und hier stimmen dann ganz oft die Pfade einer "Linux" PPD nicht für BSD.

Es sind doch unter Linux vermutlich dieselben Treiber wie unter OBSD und ich habe auch das PPD-File schon importiert also wohl Sicherheit genau den selben Treiber benutzt. Geht nicht.
die Treiber alleine sind eben nicht genug.

Am liebsten ist mir allerdings, wenn es gar keine echten Treiber braucht und die Drucker PostScript oder PDF direkt verarbeiten können.
Diesen Weg hast du schon mal nicht gewählt.
Zu dem, was @Andy_m4 oben schon erklärte, musst nicht nur du, sondern auch dein Cups die HW erreichen und bedienen können. Zusätzlich eventuelle Spooler-Dienste, die mit den Übersetzern kommen können. Das alles ist recht kompliziert und ich arbeite mich immer nur höchst ungern da hinein und auch nur, wenn es wirklich brennt.
Dann ist es aber wichtig, nicht zu überstürzen und an allen Rädern gleichzeitig zu drehen.
Vollkommen ohne Cups muss dein Drucker erst mal absolut sicher als USB-Gerät zur Verfügung stehen. Das scheint mir bei dir nicht der Fall zu sein.

Du bekommst eine Fehlermeldung beim Drucken, die ich aus FreeBSD im Zusammenhang mit dem Gebrauch von foomatic-Treibern auch schon erlebte. Es ist für mich naheliegend, dass OpenBSD eventuell ähnliche Probleme hat.

Mal einen Ausrutscher zu Linux: wir sagen immer Linux, aber die unterschiedlichen Distributionen leisten hier sehr viel Arbeit, um das Drucken einfach zu machen. Das geht los bei zusätzlichen Kernel-Modulen und führt bis hin zu einem automatisierten Download fehlender Treiber. Es finden sich auch oft sowohl gutenprint als auch foomatic Treiber an Bord, ghostscript in passender Version (oder eben angepasst, so dass es geht) und unter Umständen eine ganze Reihe zusätzlicher Programme und Tools, die man auf Anhieb nicht sieht.
In the BSD-world muss man das alles alleine leisten, wenn man es vergleichbar haben möchte.
Nur die "gleichen" Treiber zu wählen, ist eben nicht ausreichend und klar, ich bin nur Endnutzer mit absolut geringen Kenntnissen, aber mir ist es noch nie gelungen, einen GDI-Drucker mit einem FreeBSD zu benutzen. Der gleiche Drucker in einem Ubuntu brauchte dann unter Umständen gar nichts an eigener Arbeit. Wie von Zauberhand stand er zur Verfügung. Schon regelrecht unheimlich.
 
Früher habe ich mal mit Apsfilter gedruckt.
Wenn man dem Problem ohne Cups "zu Leibe rücken" könnte, wäre schon toll.
APSFIlter ist in dem ganzen Konstrukt aber ne andere Geschichte. Diese Filter dienen dazu, aus der Datei die Du da hin schickst ein einheitliches Format (Postscript, PDF, whatever) zu machen. Dein Hauptproblem ist (so hab ich den Thread bisher verstanden) die Daten in die entsprechende Druckersprache zu übersetzen. Wenn Du herausgefunden hast, was der spricht, dann sind wir da schon ein ganzes Stück weiter.

Hier wird in dem ein oder anderen Posting erwähnt, das das wohl ein GDI-Drucker ist. Prinzipiell kann man auch auf dem drucken und es gibt sogar ein Generic-Driver. Man müsste halt gucken, ob man das unter OpenBSD hingefrickelt kriegt.
Und dann sind wir wieder bei dem, was ich bereits sagte: Es bedeutet Aufwand und der betriebene Aufwand garantiert keinen Erfolg.

Die grundsätzliche Frage, die Du da für Dich beantworten musst ist, ob Du bereit bist den Aufwand zu tragen.
Die wird das hier keiner abnehmen können. Und klar. Wenn es irgendwelche Probleme oder Fragen gibt, dann bin ich und auch andere sicher bereit darauf einzugehen.
Ich glaube aber es stößt nicht auf Gegenliebe wenn man hier Zeit aufwendet und Dinge erklärt und Du dann aber morgen irgendwie sagst: "Iss mir alles zu kompliziert. Da hab ich kein Bock drauf."

Insbesondere wenn Du dann so Sachen sagst wie "Ich druck nur ein paar Mal und eigentlich reicht es mir dafür dem Kram auf meinen Linux-Rechner zu kopieren" dann wirkt das halt nicht gerade so, als ob Du wirklich den Aufwand investieren willst und dann ist die Reaktion auf Fragen dazu - na ich sag mal vorsichtig/neutral - verhalten. Möglicherweise drückt sich das dann in Antworten wie "Iss ein Scheiß Drucker; kauf Dir mal einen Anderes" aus.

Mal davon abgesehen, das GDI-Drucker wirklich Scheiß-Drucker sind. :-) Unter Linux hats viele, viele Jahre gebraucht bis die da halbwegs liefen und man hat immer noch keine 100% Coverage. Und das alles bloß, weil die Hersteller ein paar Mark Fuffzig bei den Kosten sparen wollten.

und hier stimmen dann ganz oft die Pfade einer "Linux" PPD nicht für BSD.
Gut. Pfade ließen sich ja anpassen. Ein wirkliches Problem kommt ja erst auf, wenn dann irgendwelche Binaries ins Spiel kommen oder sich gewisse Dinge sich nicht kompilieren lassen.
 
Zuletzt bearbeitet:
Gut. Pfade ließen sich ja anpassen. Ein wirkliches Problem kommt ja erst auf, wenn dann irgendwelche Binaries ins Spiel kommen oder sich gewisse Dinge sich nicht kompilieren lassen.
vollkommen richtig, mich da zu verbessern. Ich hätte formulieren sollen: im besten Fall genügt es... oder so ähnlich.

Es wäre übrigens ganz schön, wenn jemand das Buch über Drucken mit Unix mal schreiben UND aktuell halten würde.
Das ist für mich immer wieder eine große Herausforderung, Informationen richtig zu deuten und etwas zu verstehen. Ich erinnere trübe, als ich letztens mal eine neuere Version von Ghostscript probieren wollte und nach einigen Stunden merkte, dass ich damit doch überfordert bin, weil nicht nur einfach Ghostscript neu zu bauen ist, sondern am Ende (leicht übertrieben) das halbe System erneuert werden musste und teilweise verlangte Ports sich gerade mal nicht bauen ließen.
Dabei benutze ich nur Netzwerkdrucker, die Postscript oder zumindest ein PCL können.

Hier haben wir es aber zusätzlich mit USB zu tun. Wenn ich an meinen (Uralt) Scanner denke: den muss ich manchmal fünf oder sechs mal auffordern, bis er sich endlich ins System einbindet. Ich vermute, dass das Laufzeit-Probleme sind, denn er benutzt noch USB2 und ich ändere zwischendurch ja nichts an der Konfiguration und plötzlich gehts dann doch. Hier rede ich übrigens von xsane.

Wenn ich mir nun ein ähnliches Verhalten für einen Drucker vorstelle, ist das doch sehr quälend, bei jedem Druckauftrag erst auf Fehlersuche zu gehen und wenn es dann flutscht, gleich mehrere Ausdrucke der gleichen Datei aus den Spoolern geliefert zu bekommen.


Was ich hier nicht ansprechen wollte, weil uns ja die HW-Thematik des TE hinreichend bekannt ist: eine VM (und ja, ich nutze noch immer VirtualBox) kann ebenfalls recht hilfreich bei der Fehlersuche sein. Ich will nicht alleine Windows nennen, das ich ehrlich gesagt eher grausam finde, was das Einrichten von Druckern angeht, aber eben so ein schillerndes und quietschendes Ubuntu zum Beispiel, kann sehr hilfreich sein. Erstens sieht man, ob die HW überhaupt stabil ist und funktioniert und zweitens kann man sich vielleicht was ab schauen, wie die HW behandelt wird.
Alternativ gilt das auch für ein Live-System oder generell zweites System, das auf der gleichen HW gebootet werden kann.
 
Es wäre übrigens ganz schön, wenn jemand das Buch über Drucken mit Unix mal schreiben UND aktuell halten würde.

Ehrlich gesagt, mein ehemaliger Drucker von 1998 den ich anfang der 2000er kostenlos aus dem Schrott hatte war immer wirklich einfach zu installieren - einfach beim Cups auf "hinzufügen" - Protokoll auswählen, IP eingeben, Modell, fertig - das war egal ob unter OpenBSD, Linux oder Windows (Na gut, da halt "Drucker hinzufügen" und kein Cups) nie ein Problem. Ein aufwand von ... 3 Minuten ... wenn überhaupt

Meinen "neuen" (so von 2017 oder 2018 tipp ich) hab ich noch nicht im Netzwerk, aber da er auf wunsch die gleichen Protokolle und Sprachen spricht, sollte das eher kein Problem sein - und wie hier schon mehrere schrieben, mit aktuellen, Treiberlosen Drucken, PDF-Druck etc ist das inzwischen alles nochmal deutlich einfacher geworden.

(Updates waren auch nie ein Problem, unter OpenBSD einfach ein pkg_add -u und eine aktuellere Ghostscript Version kam ganz automatisch)

Wenn ... ja wenn man darauf achtet einen Drucker zu kaufen oder zu beschaffen der gewisse Mindeststandards beherscht.
 
Der Thread ist aber halt auch schon 17 Jahre alt. Da halte ich es nicht für völlig ausgeschlossen, das sich in der Zwischenzeit was geändert hat. :-)

Das wird bei einem GDI-Schrott-Drucker nicht funktionieren - dafür brauchst du am besten ein Modell das selbst PS spricht
Halb offtopic, aber der Vollständigkeit halber: Praktisch alle Netzwerkdrucker an etwa 2018 unterstützen IPP Everywhere und funktionieren ohne Treiber. MacOS hat daher Druckertreiber schon eliminiert, Cups wird es dieses Jahr mit 3.0 tun und Windows fängt nun auch an. Oder anders gesagt einen Netzwerkdrucker kaufen und geht einfach, wenn avahi läuft sogar ohne irgendwas zu konfigurieren.
 
Es wäre übrigens ganz schön, wenn jemand das Buch über Drucken mit Unix mal schreiben UND aktuell halten würde.
Ja. Wobei das ja auch letztlich wieder auf die Frage hinausläuft: Muss irgendwer machen.
Wenn sich da niemand findet der das als wichtig genug erachtet und/oder man auch sich einfach mangels Manpower sagt: "Wir haben so viel zu tun; solche Sachen stehen daher irgendwo ganz hinten auf der Agenda", dann ist das halt schwierig.
Das muss man immer im Hinterkopf behalten. Das es da niemand mit Absicht irgendwie denkt: "Das lassen wir als Geheimwissen, um die ganzen Nicht-Nerds fernzuhalten".

PDF-Druck etc ist das inzwischen alles nochmal deutlich einfacher geworden.
In der Tat. Dann kann man tatsächlich nämlich einfach mit cat die Datei ans USB-Device (bzw. mit netcat an die IP-Adresse) schicken und der druckt das dann brav. Dann spart man sich ggf. auch das Geraffel da ein CUPS mitzuziehen. Meist schalt ich dann doch aber zumindest ein LPD dazwischen, weil man dann Spooling hat und außerdem trivial Filter dazwischen setzen kann, wenn man auch andere Formate als PDF reinwerfen können will.

Ansonsten und in Unterstützung zu meinen beiden Vorrednern: Beim Druckerkauf gucken, das IPP-Everywhere bzw. driverless-printing funktioniert. Dann hat man die wenigsten Probleme. Gerade die ganzen Mobildevices haben das sehr gepusht, so das man da auch nicht mehr nur auf exotische oder teure Modelle beschränkt ist.
Gibt da auch Datenbanken zu, die einem bei der Recherche helfen können, wie hier zum Beispiel von der Printer Working Group:
https://www.pwg.org/printers/
 
nd dann sind wir wieder bei dem, was ich bereits sagte: Es bedeutet Aufwand und der betriebene Aufwand garantiert keinen Erfolg.

Die grundsätzliche Frage, die Du da für Dich beantworten musst ist, ob Du bereit bist den Aufwand zu tragen.
Die wird das hier keiner abnehmen können. Und klar. Wenn es irgendwelche Probleme oder Fragen gibt, dann bin ich und auch andere sicher bereit darauf einzugehen.
Ich glaube aber es stößt nicht auf Gegenliebe wenn man hier Zeit aufwendet und Dinge erklärt und Du dann aber morgen irgendwie sagst: "Iss mir alles zu kompliziert. Da hab ich kein Bock drauf."

Es ist ja eher so, daß ich mich verzettel. Das ganze riecht ja förmlich danach, daß der Drucker letztendlich nicht laufen wird. Aber sich mal eben einen Tag damit um die Ohren zu hauen, geht ganz leicht. Wenn ich am Ende tatsächlich was gelernt habe, ist es ja gut. Aber auch das scheint mir nicht unbedingt der Fall zu sein.

Es fängt immer ganz harmlos an: Mal "eben schnell" den Drucker an's laufen bringen. Ok, es gibt ein paar Probleme, da kann man ja nachforschen.

Aber wenn Du zB etwas erarbeitest, was zwar mühsam ist, aber nach und nach schon klar wird, und man hat was dazugelernt und weiß im Hinterkopf, daß es geht und zuletzt nur eine Frage der Ausdauer ist, sich da durchzuwühlen, dann ist das etwas ganz anderes, weil irgendwie kalkulierbar.

Ist es das aber nicht, sondern nur ein Grab in das man nicht nur jede Menge Zeit sondern vor allem auch Motivation versenkt, ist das ja nichts Empfehlenswertes.

Ich muß dazu sagen, daß einer der Gründe, von Slackware nach BSD zu wechseln die außerordentlich nette und bemühte Community hier ist, auf die ich als mehr oder weniger Laie ja auch angewiesen bin.

Ich habe vor 15 Jahren nur gewusst, daß ein Computer einen Einschaltknopf hat und das war's. Wären nicht die Foren gewesen, ich hätte keine Chance gehabt. Und ich bin dankbar, überhaupt auf Linux (in der Folge BSD) gestoßen zu sein, was mehr oder weniger ein Zufall war (wenn man an sowas glaubt).

Darum, ich weiß Eure Mühe sehr zu schätzen!

Aber mir ist schon klar, daß es letztlich nicht möglich ist, alles unbedingt verstehen und ergründen zu wollen, das kann wohl keiner und ich schon erst recht nicht, abgesehen davon, daß das Ganze ja kein Selbstzweck ist.

Also wenn es möglich ist, der Sache systematisch auf den Grund zu gehen, dann gerne, aber ich weiß ehrlich gesagt nicht, wo ich da überhaupt anfangen soll. Ober der Drucker zB überhaupt ansprechbar ist.
 
ich will nicht irgendwie ironisch rüber kommen, aber es ist eben das, womit ich selbst immer anfange

außerdem finde ich aber einen Blick ins FreeBSD Handbuch immer erhellend, natürlich nicht wissend, wie weit das in OpenBSD helfen kann.
beide Einträge sind nicht mehr so ganz aktuell, können aber sinngemäß sicher auch für andere Systeme genommen werden.
 
1705234994.png

Ja äh nein lieber nicht.
Ich kann nicht gut genug englisch dafür. Und es sprengt den Rahmen.
Dann wäre es schon besser, ich würde es nach dem hier probieren:

basic-printing-on-openbsd

Da ist allerdings auch von einem Netzwerkdrucker die Rede.
Aber so könnte ich mal lernen, den Drucker direkt anzusprechen.

Ein simples cat ksh* | /dev/ulpt0 tut es jedenfalls nicht.
Erstens geraten und zweitens war das schon klar...
Zumindest gab's keine Rauchentwicklung, schon mal ganz gut für den Anfang.

Code:
First, I created the file /etc/printcap with the following content:

lp|brother:\
    :sh=:\
    :rm=192.168.178.52:\
    :sd=/var/spool/output/brother:\
    :lf=/var/log/lpd-errs:\
    :rp=brother

Diese existiert schon und wird von Cups verwaltet (Änderungen werden überschrieben).
 
Aber sich mal eben einen Tag damit um die Ohren zu hauen, geht ganz leicht. Wenn ich am Ende tatsächlich was gelernt habe, ist es ja gut. Aber auch das scheint mir nicht unbedingt der Fall zu sein.
Naja. Es gibt schon Lernpotential.
Und selbst wenn man sagt: "Ich weiß nicht, ob ich das eigentliche Ziel erreiche und kann sein, das ich zwischendurch abbreche aber wenigstens hab ich auf den Teilweg was gelernt" wäre ja ein nachvollziehbarer Punkt.

Darum, ich weiß Eure Mühe sehr zu schätzen!
An der Stelle möchte ich auch noch mal sagen, das es mir nicht darum geht das Du Dich irgendwie rechtfertigst oder Bemühungen glaubhaft versicherst. Es ging mir primär darum, das Du für Dich selbst klar wirst, ob Du das machen willst.

Und ja. Ich verstehe die Problematik dabei des nicht-abschätzen-könnens. Ich versuche Dir mal dazu eine Entscheidungshilfe zu geben.

Um so ne Sache anzugehen, muss man jetzt nicht der krasse Hacker sein oder so. Aber die ist schon ein bisschen anspruchsvoll.

Häufig, wenn man Probleme hat a-la "es druckt nicht" dann guckt man ja gerne mal in die Logfiles und dreht da ggf. die Verbosity noch ein bisschen nach oben und dann guckt man in Manpages und anderen Dokus und spielt an der Konfiguration rum und/oder tauscht den Treiber aus und dann kriegt man das schon irgendwie hin.

Das wird hier vermutlich nicht reichen. Da wird man vielleicht auch mal in die Verlegenheit kommen irgendwelche C Quellen anzupassen und zu kompilieren usw.

Und Du hast ja zwischenzeitlich mal das Problem genannt "Unter Linux druckt es aber wenn ich versuche von OpenBSD Remote via CUPS auf Linux zu drucken, dann geht das nicht". Das wäre eher so ein Problem aus Kategorie 1, was man mit "an der Konfiguration spielen" wahrscheinlich hinbekommt. Die Skills die man da braucht wird für direktes Drucken unter OpenBSD via USB eher nicht reichen.

Ein simples cat ksh* | /dev/ulpt0 tut es jedenfalls nicht.
Der Befehl wäre ja ohnehin falsch. Mal davon abgesehen, das man erst mal nachgucken sollte ob Device /dev/ulpt0 vorhanden ist und man auch die notwendigen Rechte hat und man natürlich nur Dateien hinschicken kann, die auch existieren, müsste der Befehl eher lauten:
cat mytestfile > /dev/ulpt0
Außerdem sollte für den Test kein Druckdienst laufen (also weder CUPS noch LPD), damit die da nicht ungewollt Einfluss auf das Device nehmen.
 
Grob noch der Tip, dass man mit https://translate.google.com/ mittlerweile ziemlich gute Übersetzungen bekommt. Man kann sogar bequem ganze Webseiten onthefly übersetzen lassen und Dokumente wie .pdf uploaden, die man dann übersetzt ebenfalls im gleichen Format wieder zurückbekommt, geht ratzfatz. Aber immer dran denken: keine geheimdienstlichen Dokumente hochzuladen, die google besser nicht sehen sollte. ;)

An der Stelle möchte ich auch noch mal sagen, das es mir nicht darum geht das Du Dich irgendwie rechtfertigst oder Bemühungen glaubhaft versicherst. Es ging mir primär darum, das Du für Dich selbst klar wirst, ob Du das machen willst.
Exakt. Zusätzlich habe ich im Hinterkopf, dass wenn der TE das Problem vielleicht durch die Hinweise und Tips nicht hinbekommt, es jemand anderem hilft, der irgendwann mal darauf stößt.
 
dass man mit https://translate.google.com/ mittlerweile ziemlich gute Übersetzungen bekommt.
Ja. Man muss aber ein bisschen aufpassen. Google-Translate neigt nämlich auch dazu Fachbegriffe oder Eigennamen zu übersetzen, die gar keiner Übersetzung bedürfen.
Aber ja. Es hilft einem ein grobes Verständnis zu bekommen, falls man gerade völlig im Wald steht.

... es jemand anderem hilft, der irgendwann mal darauf stößt.
Da sagste watt.
Mir passiert ja auch gelegentlich das ich irgendwie ein super spezielles Problem hab und dann im Internet nicht wirklich was finde und dann finde man doch mal in irgendeinem Forum/Mailingliste eine Frage dazu die exakt auf das Problem passt und freut sich dann endlich mal paar Hinweise zu bekommen und in Wirklichkeit wird aber im Diskussionsverlauf versucht dem das auszureden und warum er es nicht soundso macht. Und ich denk dann immer "Warum beantwortet ihr nicht einfach die Frage" :-)
 
Google-Translate neigt nämlich auch dazu Fachbegriffe oder Eigennamen zu übersetzen, die gar keiner Übersetzung bedürfen.
Die Übersetzungen von cornhub oder zighamster lassen mich regelmäßig kichern. Natürlich besuche ich solche düsteren Seiten nicht und klicke alles hastig weg, wenn ein popup erscheint. ;)

Warum beantwortet ihr nicht einfach die Frage
Ja. Auf solche Ideen/derailing käme ich gar nicht...
 
Ein simples cat ksh* | /dev/ulpt0 tut es jedenfalls nicht.
ich rate da nochmal zu der Seite aus dem FreeBSD Handbuch, die es sicher auch auf Deutsch gibt. Zusammen mit der OpenBSD-Seite zu einfachem Drucken erklärt das schon eine Menge, was im Vorfeld so alles getan werden kann.

Nur kann ich nicht umhin es zu wiederholen: ich habe selbst noch nie einen GDI-Drucker unter FreeBSD zum Arbeiten bewegen können.
Bei solchen Druckern wird es nicht genügen, ihnen einen ASCII Text oder ein PDF oder auch PS direkt auf die Schnittstelle, also das device zu senden. Und zwar unabhängig von allen Rechten, die natürlich auch erst mal stimmen müssen.
"Normale" Drucker können so etwas spielend verarbeiten. GDI-Drucker, zumindest die wenigen, die ich bisher verschrottet habe, können das nicht, ohne eine zugehörige Übersetzungsmaschine und die ist in aller Regel ein Binary, das es nur fix und fertig gibt und meist noch nicht mal für OpenSource Systeme und wenn, dann eben meist für Linux.

Ich zitiere mal aus dem FreeBSD-Handbuch:
Host-Based
Manufacturers can reduce the cost of a printer by giving it a simple processor and very little memory.These printers are not capable of printing plain text.Instead, bitmaps of text and graphics are drawn by a driver on the host computer and then sent to the printer.These are called host-based printers.
Communication between the driver and a host-based printer is often through proprietary or undocumented protocols, making them functional only on the most common operating systems.


Du verstehst mich?
Selbst dann, wenn du alles richtig machst und mit allen Rechten versehen einen Text direkt auf deinen Drucker sendest, wird er vermutlich nichts machen oder im günstigsten Fall irgendwelchen Mist, was immerhin ein gutes Zeichen wäre, weil dann ja schon mal was über die Schnittstelle läuft.

In deinem Fall wissen wir nun noch nicht,
-ob die HW sauber erkannt und eingebunden ist, also ein passendes USB-Gerät angelegt wird und auch verfügbar bleibt
-ob die Rechte auf dieses Gerät so vergeben sind, dass die Nutzer (wozu auch die Druckdienste gehören) ausreichend darauf zugreifen können
-ob der cupsd überhaupt richtig läuft, oder du alternativ andere Druck-Systeme aufsetzen und probieren willst (wobei cups auch einen lpd mitbringt)
-ob du überhaupt einen brauchbaren Treiber finden kannst, der unter OpenBSD funktioniert.

Man mag mich unterstützen und verbessern, wenn ich was vergessen habe.

Was wir oben gesehen haben ist eher, dass -
-das USB-Gerät nicht sauber (zumindest nicht dauerhaft) verfügbar ist
-der cupsd offenbar nicht wirklich korrekt läuft
-der foomatic-Treiber nicht funktioniert

Diese Dinge kann man teilweise zumindest recht einfach herausfinden und abklären, aber am Liebsten nicht alles zusammen auf einen Schlag.
Und am Ende bleibt die große Wahrscheinlichkeit, dass es eben unter OpenBSD gar nicht geht, aber dann weiß man zumindest, dass man alles richtig gemacht hat.

@Andy_m4 hat es ja schon angesprochen: das Drucken von einem cups-Client auf einen cups-Server ist nahezu trivial. Wenn du diese Möglichkeit in Betracht ziehst, brauchst du auf Server Seite die entsprechenden Drucker nur frei zu geben. Ich weiß jetzt nicht, ob OpenBSD hier eine Ausnahme macht, aber cups benutzt in der Regel das avahi Gedöns (übrigens ein Ding von Lennart Poettering) und das IPP-Protokoll, wodurch dann alles quasi wie von Geisterhand ausgehandelt wird und nur noch angeklickt werden muss.
Die Treiber liegen dabei (in der Regel) alleine auf dem Server, der Client sendet nur "rohe Daten".


übersetzen kann auch recht gut und vornehm von einer Sprache zur anderen https://www.deepl.com/translator und ich glaube, mittlerweile auch als Browser-Plugin verfügbar.
 
Bei solchen Druckern wird es nicht genügen, ihnen einen ASCII Text oder ein PDF oder auch PS direkt auf die Schnittstelle, also das device zu senden.
Im Prinzip gebe ich Dir recht.
Aber das das ein GDI-Drucker ist wurde zwar hier und da schon geäußert, aber als wirklich belegt sehe ich das noch nicht (korrigiere mich aber gerne, wenn ich falsch liege).
Wenn ich bei Openprinting zum Brother HL-2030 (aus Posting #4) gucke, sieht das für mich auf den ersten Blick aus das es eher Richtung PCL geht.
Und es geht bei dem Test auch gar nicht zwingend darum dann schon ein fertiges Druckergebnis zu bekommen, sondern ob so grundsätzliche Dinge laufen. Wenn dabei keine Fehler(meldungen) auftreten und der Drucker sogar noch wenigstens zuckt, dann weiß man schon mal, das auf der Ebene alles ok zu sein scheint (klar ist das keine Garantie das da alles sauber läuft, aber wenigstens die typischen Pitfalls sind schon mal weg).

Die Treiber liegen dabei (in der Regel) alleine auf dem Server, der Client sendet nur "rohe Daten".
Also nur noch mal kurz zur Präzisierung:
Driverless-Printing sagt jetzt nicht, das Du da irgendwelche Daten reinkippen kannst und dann wird kümmern sich der Drucker bzw. Druckserver um alles, sondern die Datenformate die da hingeschickt werden können sind standardisiert.
 
Hallo, was hat es denn hiermit auf sich ??

Code:
* WARNING *
ulpt(4) needs to be disabled in the kernel (see bsd.re-config(5)) or the printer
will not be available to libusb:
# echo 'disable ulpt' >>/etc/bsd.re-config
# reboot

Es ist doch ulpt0
Hast du es denn in der Zwischenzeit mal versucht? Es erinnert mich ein wenig an die Druckerfahrung eines Nuters hier mit seinem Samsung ML 1510 SW Laserdrucker:

@midnight, @pit234a, @zuhause,@boser , danke, hier der aktuelle Stand::)

Juchuuu, es funktioniert und der Drucker druckt....

Und das ist die Lösung:

Code:
pkg_add splix

rcct enable cupsd

rcct enable cups_browsed

als root

Code:
# printf 'disable ulpt\nquit' | config -ef /bsd

und

Code:
# chown _cups /dev/ugen0.* /dev/usb0

Rechner neu starten

CUPS Oberfläche starten mit http://localhost:631

Drucker hinzufügen

User: root

Passwort: xxxxxx

Der locale Drucker Samsung ML-1510 wird erkannt und ich kann ihn hinzufügen und konfigurieren.

Er druckt einwandfrei.

Danke nochmals an alle, die nicht locker gelassen und mich unterstützt haben.
Vielleicht wäre das ja auch die Richtung in die du schauen solltest? Ansonsten viel Glück und weiterhin viel Spaß beim Herumprobieren. ;-)
 
Ja soweit ich das sehe ist Splix für Samsung-Drucker, wir sprechen hier von Brother.
Nein, im Augenblick reicht's mir erstmal...
Ich werde mal in Ruhe irgendwann einen neuen Versuch starten.

Auf Openprinting sind eine ganze Reihe Treiber aufgeführt:

lj5gray (driver home page)
Type: Ghostscript built-in

Der ist bei Cups verfügbar, und zur Zeit auch eingestellt.
Ob das die Sache vereinfacht, vermag ich aber nicht zu beurteilen...
"Unable to send data to printer".

Wie gesagt läuft es im Augenblick darauf hinaus, mehr oder weniger blind herumzuprobieren ohne große Aussicht auf Erfolg. Ich bin da nicht kompetent genug für und habe den leisen Verdacht, daß es eher daran liegt, wie der Drucker angesprochen wird als am Treiber.

Was auch dafür spricht ist, daß er keinen Mucks sagt. Es wäre gut denkbar, daß er einmal kurz anläuft, selbst wenn er dann nicht drucken kann.

Das wäre ja die erste (systematische) Frage zu klären, ob er über USB anspricht, Cups hat ihn ja schließlich gefunden.

Aber das sprengt den Rahmen dessen, was ich kann.
 
Zuletzt bearbeitet:
Oh entschuldige, das war wohl ein wenig undeutlich. Ich meinte explizit:
ulpt deaktivieren und dann versuchen.
"# printf 'disable ulpt\nquit' | config -ef /bsd"

Oder hattest du es schon gemacht?
 
Code:
tom printf 'disable ulpt\nquit' | config -ef /bsd
OpenBSD 7.3 (GENERIC) #4: Sat Oct 21 23:43:06 MDT 2023
    root@syspatch-73-i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
Enter 'help' for information
ukc> disable ulpt
400 ulpt* disabled
ukc> quit
Saving modified kernel.

...und reboot

Ich habe den Drucker komplett neu hinzugefügt.
"Unable to send data to printer"

Warum ist oben in der Überschrift "PAUSED" ?
Ich bin aber wirklich ein Idiot, tschuldigung.

Habe jetzt auf "Resume Printer" gesetzt, jetzt meint er:
"Waiting for printer to become available"

Druckt aber nicht...
Printer ausgemacht und wieder an, jetzt ist er wieder auf "Paused"
 
Zuletzt bearbeitet:
Also nur noch mal kurz zur Präzisierung:
Driverless-Printing sagt jetzt nicht, das Du da irgendwelche Daten reinkippen kannst und dann wird kümmern sich der Drucker bzw. Druckserver um alles, sondern die Datenformate die da hingeschickt werden können sind standardisiert.
ich meinte nicht ohne Treiber, sondern vom Cups-Client zum Cups-Server. Das macht "man" meist so, dass die Treiber dann auf dem Server liegen und erst hier die Daten passend für die Druckersprache gewandelt werden. Also, altmodisch gesagt, das ps wird nicht auf dem Client gewandelt, sondern auf dem Server.

Ich habe allerdings auch schon andere Lösungen gesehen, so dass der Server im Grunde genommen ein entfernter Spooler war, die Daten auf dem Client schon aufbereitet werden mussten. Das würde in unserem Fall aber ja gar nicht weiter helfen.

Hierbei ist Cups in meinen Augen deshalb ziemlich einfach, weil es alle benötigten Programme schon mitbringt und keine weiteren Detail-Kenntnisse erfordert.
 
ich meinte nicht ohne Treiber, sondern vom Cups-Client zum Cups-Server. Das macht "man" meist so, dass die Treiber dann auf dem Server liegen und erst hier die Daten passend für die Druckersprache gewandelt werden.
Ja. Es ging mir auch nur um das "rohe Daten", weil das so ein bisschen suggeriert, das ob da alles mögliche einfach so hingeschickt werden kann.
 
Ich werde mal in Ruhe irgendwann einen neuen Versuch starten.
Noch ein Tipp bezüglich dem Brother HL-2030:

Bei OpenBSD befindet sich in den Ports unter /usr/ports/print/brlaser offenbar noch ein (CUPS)Treiber für Brother-Laserdrucker.
Dort steht zwar in der Desription nix vom HL 2030, aber der Port bezieht sich auf https://github.com/Owl-Maintain/brlaser
und dort ist der HL-2030 aufgeführt.

Ich denke, darüber könnte man es mal probieren. Erfolg ist zwar auch hiermit nicht garantiert, aber es ist schneller mal ausprobiert als irgendwelche anderen Frickeleien.
 
Ich habe in der Vergangenheit auch ab und an Brother gangbar mit cups gemacht, da hab ich viele ähnliche Treiber ausprobiert und etwas feingetunt, wenn nötig. Die .ppd kann man nämlich ganz normal öffnen und editieren, gerade bei den schon angesprochenen Auflösungen bzw. USletter vs. DINA4, wenn die .ppd stark rudimentär war und nicht aus einem gereiften pack.
Davon abgesehen, ob der Drucker sinnvolles ausspuckte...aber zumindest mal gezuckt hat er immer, ne rote Lampe ging an oder man konnte im cups-log was sehen. Allerdings war das alles unter FreeBSD, daher weiß ich nicht, ob nicht doch USB-seitig was krumm ist oder eben noch fehlt.
 
Zurück
Oben