Irgendwas in meinen Netzwerk hängt neuerdings an den Hostnamen meines Cups-Printserver das suffix ".local" hinten dran so das die Namensauflösung nicht mehr klappt. Ich kann das manuell in der printers.conf auf den clients ändern, was aber nicht von dauer ist. Ein reboot des servers oder client und schon ist es wieder da. Ich könnte in der config meines Nameserver das suffix eintragen und das Problem ist gelöst, weiss dann aber immer noch nicht wer mich da ärgert. Ich bin völlig ratlos wer da wo was macht. Habe cups auch schon ganz neu aufgesetzt, der erfolg war nur kurzfristig.
Jemand ne Ahnung was da los ist?
http://blogs.fsfe.org/the_unconventional/2013/08/27/cups-1-6-x-and-remote-queues/
Tja, da verstehe ich nur die Hälfte von oder noch weniger.
...
technisch oder sprachlich?
Hi hsp,
was sagt den "hostname -d" und "hostname -f". Wie sieht deine /etc/network/interfaces aus?
Quote from: "michaa7"technisch oder sprachlich?
sprachlich :)
Vielleicht ist Bluelupo hier der kompetentere, seine fragen hören sich jedenfalls so an.
apple, denen ja cups mittlerweile gehört hat in der 1.6.3 linux funktionalität herausgeschmissen die für macOS nicht benötig werden. Der user und blogautor mag kein Zeroconf, Avahi, mDNS, sondern lieber alles von hand, allerdings hat seine methode den nachteil, dass damit kein cups webinterface genutzt werden kann. In soweit stellt das vielleicht doch nicht eine brauchbare lösung da was er da zusammengefrickelt hat.
Vertrau dein problem mal Bluelupo an ...
hostname -d ==> localhost
hostname -f ==> hsp1.localhost
Nochmal gesagt, es ist neu das Problem. Bisher flutschte alles prima. Plötzlich malt da einer .local dazu.
...
Die änderungen die du in deiner printers.conf vorgenommen hast sind wohl deswegen nur temporär weil (?) zur zeit der änderung cupsd lief? Den mußt du ausschalten ( /etc/init.d/cups stop ). Allerdings behebt das nicht den grund deines dilemmas, hilft lediglich für den workaround.
Ich weiß, die printers.conf wird bei jedem start von cups neu geschrieben. Darum ist das nur temporär. Dieser .local suffix tauch immer wieder auf.
...
Hi hsp,
ich glaube nicht das dies etwas mit CUPS zu tun hat, sondern mit der Namensauflösung. Welche 127er IP-Adressen hast du denn in der hosts stehen?
Garnix, ich hab oben geschreibselt das ich ein Nameserver in Betrieb habe (dd-wrt). Hat alles immer bestens funktioniert. Ich vermute das da bei irgendeinem d-u was passiert ist. Meine hostsdateien sind jungfräulich.
...
.local klingt sehr nach link-local von IPv6. Neighbor-Discovery lautet das Stichwort. Wenn Du ein avahi-browse auf das Netz los läßt, wirst Du viele deiner Geräte mit einem solchen .local sehen, zumindest bei denen die IPv6 nutzen können und keiner Domain angehören.
erm, ich versteh nur Bahnhof, was und wo kann ich denn da schrauben? Es muss irgendwas in letzter Zeit passiert sein hier.
...
Wenn ein Rechner keinen Domain-Anteil hat, wird zur lokalen Auflösung der Domainname local verwendet. Wenn dann noch kein vernünftiger Hostname dazu kommt, kann etliches schief gehen mit zeroconf.
Dein erster Schritt sollte sein deinen Rechnern vernünftige Hostname zu geben. Gut wäre es wenn Du auch noch einen Domainname vergeben könntest. Da solltest Du aber sinnvoller Weise etwas nehmen was auch dir gehört, sonst kann da auch wieder was schief gehen. Optimal wäre natürlich ein Nameserver, aber auch passende Einträge in den /etc/hosts deiner Rechner hilft schon echt weiter. Ich denke aber das schon die Vergabe von Hostnamen hilft.
Du scheinst was überlesen zu haben. Nameserver, Hostnamen, static IP alles vorhanden. Und ich sags nochmal, bis vor ca. 2-3 Wochen funktionierte das alles bestens. Mit irgend einem update muss da was passiert sein.
...
Quote from: "hsp"hostname -d ==> localhost
hostname -f ==> hsp1.localhost
sieht für mich nach irgendwas aus aber nicht nach wirklicher Absicht. Oder hast Du ernsthaft deine Domain "localhost" genannt? Ohne toplevel-domain Anteil? Und auch für avahi wird das merkwürdig aussehen und deshalb zu einer link-local erweitert. Daher dann das .local was angehängt wird. Ein "avahi-browse -avrt" von einem deiner anderen Rechner aus wird dir zeigen welcher Dienst wo wie von wem angeboten wird. Da darfst Du dann auch mal ein "-d localhost" anhängen, was aber wohl einen Fehler liefert. Wenn ja, wird deine merkwürdige Domain nicht aufgelöst und mDNS/DNS-SD lößt auf .local auf. "man avahi-browse" wird dich auf weitere Fährten bringen, bzw Stichwörter für weitere Suchbemühungen liefern.
Mein Verdacht bezüglich "letzte Woche ging es noch" geht in die Richtung das bei cups jetzt endgültig auf avahi bzw zeroconf umgestellt wurde. Da darfst Du aber selber mal in den changelogs vom Paket gucken.
[Edit] Da ich das Thema spannend fand, hab ich noch mal ein bißchen geschaut. Im Archlinux-wiki (https://wiki.archlinux.de/title/Drucker) findet sich ein interessanter Hinweis: avahi muß seit der 1.6.x Version von Cups zwingend vor cups gestartet werden. Evtl. hakt es da ja schon bei dir. Auf jeden Fall wird avahi der Schuldige für das .local suffix sein. [/Edit]
Ich denke nicht dass das dazu eine TLD notwendig ist (ok, wenn man eine zuhase ansprechbare hat, ist das sichelich ok).
Ich habe für meine rechner eine workgoup, deren name bei mir "localhost" *ersetzt*.
Dementsprechend habe ich folgenden output:
Quotehostname -d ==> <workgroup>
hostname -f ==> <rechnername>.<workgroup>
Jetzt fragt mich wo ich diese workgroup definiert habe ... :?
Workgroup ist eigentlich ein typisches Windows-Konstrukt. Evtl durch samba eingerichtet? Ansonsten mal in der hosts oder resolv.conf gucken, avahi-daemon.conf könnte auch ein Kandidat sein, ist aber unwahrscheinlich
Quote from: "Geier0815"Workgroup ist eigentlich ein typisches Windows-Konstrukt.
Da hab ich mich auch dran erinnert als ich mein posting geschrieben habe.
QuoteEvtl durch samba eingerichtet?
Nee 8-) her nicht, samba habe ich noch nie eingerichtet
QuoteAnsonsten mal in der hosts oder resolv.conf gucken, avahi-daemon.conf könnte auch ein Kandidat sein, ist aber unwahrscheinlich
Ich glaube und bin mir eigentlich ziehmlich, aber nicht ganz sicher, dass bei der exim4 mailservereinrichtung soetwas abgefragt wurde.
Ich muss das nochmal aufwärmen.
Ich kanns nicht glauben, jetzt ist das Problem mit dem .local suffix wieder da. Beim remote drucken hab ich es wieder und die Namensauflösung klappt mit meinem Nameserver wieder nicht. Also irgendwas ist da mit cups und browsing nicht im Guten, anders kann ich mir das nicht erklären.
Ich glaub ich fress bald nen Besen...
Ich hab nur ruhe, wenn in der /etc/cups/cups-browsed.conf entweder
BrowsePoll IP.des.Servers:631 oder
BrowsePoll server.domain.tld:631 setze
dabei braucht es für 2. Lösung einen localen NameServer der die namenszuordnung macht, oder die passenden einträge in der /ets/hosts des Clients.
Alles andere führt immer zu dem Mist .local und nix mehr mit drucken :twisted:
nicht vergessen /etc/init.d/cups-browsed restart zu machen.
Das bedeutet, das ich jeden siduction client manuell konfigurieren muss :(
LinuxMint macht zwar auch diesen Mist, so das der automatisch gefundene Drucker im Browser nicht zu warten/verändern ist, aber die Druckjobs von z.B. Libreoffice gehen durch und es wird gedruckt, im Gegensatz zu siduction. Auch nicht perfekt, aber immerhin.
Die cups Integration ist durchaus unterschiedlich gegenüber Debian.
Da gibt es ein paar Pakete die es unter Debian nicht gibt.
Frust an:
Absolut ärgerlich ist, das etwas was Jahre perfekt funktionierte (einmal den Server einrichten und alle clients hatten automatisch die Drucker eingerichtet) jetzt vermacwindosenschlimmbessert worden ist, wo es ja scheinbar normal ist das man auf jedem client die Drucker neu einrichten muss.
Frust immer noch an:
Jetzt hab ich endlich was gefunden was die Sache mit dem suffix .local mit avahi halbwegs erklärt. Und zwar im Ubuntu-Wiki, dort steht was es ist und noch viel wichtiger... man kann es abschalten.
Hier der Link.
http://wiki.ubuntuusers.de/Avahi
...