Beiträge von Welm

Falls einer von Euch mal dasselbe Problem hat...

Ich hatte auf einem PC mit 15.1 seit dem Umstieg von SuSEfirewall2 auf firewalld bei eth0 keine IPv6-Adresse mehr ("ip addr show eth0" lieferte nur eine "scope link" und keine "scope global" und "host xxx" lieferte nur IPv4). Beim Abschalten von firewalld verschwand das Problem obwohl eth0 in der Zone "trusted" lag.

Ursache war der Eintrag "DefaultZone=external" statt "DefaultZone=public" in /etc/firewalld/firewalld.conf. Verstanden hab ich es allerdings nicht ...

Zitat von hscJH

Im suse-Linux-shmat-manual ist von dem Flag SHM_EXEC keine Rede...

Sonderbar. Das oben zitierte stammt aus "man shmat" in suse 15.1...

Da steht auch, welche Werte man im Fehlerfall in "errno" findet.

Weiter kann ich nichts dazu sagen ... es ist ewig her, dass ich was mit C oder seinen Abkömmlingen gemacht habe. Da müsste jemand anders was zu sagen.

Das hört sich nach dem folgenden Teil aus "man shmat" an:

       In  addition  to  SHM_RND,  the following flags may be specified in the
       shmflg bit-mask argument:

       SHM_EXEC (Linux-specific; since Linux 2.6.9)
              Allow the contents of the segment to be  executed.   The  caller
              must have execute permission on the segment.

Die Dateinamen in der ".xfigrc" werden nicht beim "Open" sondern schon bei "File" angezeigt. Die könnten also etwas mit Abstürzen beim Klicken von "File" und nicht beim Klicken von "Open" zu tun haben. Probier mal:

cd
mkdir humtata
cd humtata
xfig

Wenn dieser xfig auch beim "Open" sofort abstürzt, dann hat das Problem nichts mit exotischen Dateinamen zu tun und wir können die Idee abhaken.

Zitat von denebe

Es ist immer mit dem 'root' Kennwort zu verwenden. Oder ?

"sudo" ist ja dazu da, einen Befehl mit einer anderen Identität auszuführen. Dazu brauchst Du normalerweise das Passwort dieser Identität:

sudo -u pelle ls

führt den Befehl "ls" als User "pelle" aus und Du wirst nach dem Passwort von "pelle" gefragt.

sudo ls

führt den Befehl "ls" als User "root" aus und Du wirst nach dem Passwort von "root" gefragt.

Der Systemverwalter kann aber für bestimmte Leute/Gruppen/Befehle Ausnahmen festlegen. Das macht man als Systemverwalter in der Datei "/etc/sudoers" oder im Verzeichnis "/etc/sudoers.d". Wenn root da festlegt, dass User "otto" den Befehl "hops3mhoch" als "root" ohne Passwort ausführen kann, dann darf "otto" das eben ohne Passwort. Mit diesen Dateien herumzuspielen ist aber hochgradig sicherheitsgefährlich ... da muss man wissen, was man tut!

Zitat von fredegar

Dass es abstürzt hat aber nichts mit filenamen zu tun.

Es stürzt schon ab, wenn ich den Menüpunkt open, oder irgend einen anderen Menüpunkt auswähle, da habe ich noch keinen Filenamen angegeben.

Es ging nicht um den später eingetippten Dateinamen. Sobald Du open machst zeigt xfig die Namen aller fig-Dateien und aller Unterverzeichnisse an.

Zitat von fredegar

unter 15.1 ist bei mir derzeit Xfig 3.2.7a installiert.

Es lässt sich zwar starten, sobald ich aber open aufrufe stürzt es ab.

Über Dolphin lässt sich xfig starten und lädt auch den File (mit 3.2.5c erstellt)

Ich habe auch 15.1 mit xfig 3.2.7a und kann Dateien öffnen ... auch mit 3.2.5c erstellte.

Ich habe allerdings auch Probleme mit Umlauten. Eventuell hängt beides zusammen: Hast Du Dateinamen mit Sonderzeichen, die xfig beim Open anzeigen will und nicht kann?

(xfig ist ein sehr altes Programm. Bei der Konzeption gab es noch keine mehrbytigen Zeichen. Seit mindestens 16 Jahren gibt es immer wieder Probleme mit der Zeichenkodierung und es wird dann repariert. Ich mag das Programm wirklich ... aber ich habe den Verdacht, dass ich es irgendwann aufgeben muss.)

Zitat von LinuxBeginner2020

Problem: Da der Drucker zu diesem Zeitpunkt gar nicht am Netzwerk ist (weil das LAN-Kabel bei mir nicht dazu geeignet ist), ist die von ihm ausgespuckte IP-Adresse gar keine IP-Adresse von meinem Netzwerk, sondern vermutlich noch eine vom Hersteller default voreingestellte (und somit keine private). Darum kann die Konfiguration unter Benutzung dieser IP-Adresse gar nicht funktionieren.

Das Problem liegt woanders. Der Drucker würde in keinem Fall eine IP-Adresse aus "Deinem Netzwerk" bekommen. Du hast bei der Kabellösung nicht ein Heimnetzwerk sondern zwei und der in beiden liegende PC reicht nichts automatisch durch. In dem einen Netzwerk mit dem Router vergibt der die IP-Adressen weil er auch noch DHCP-Server ist. In dem zweiten Netzwerk ist kein solcher DHCP-Server und die beteiligten Schnittstellen in PC und Drucker haben keine brauchbare IP-Adresse. Die einfachste Lösung liegt darin, dass der Admin hier z.B. im PC 172.16.1.1 als feste Adresse für die Ethernet-Buchse konfiguriert und im Drucker entsprechend 172.16.1.2. Dann können die beiden miteinander reden. (172.16 ist auch ein privates Netzwerk)

Diese beiden Heimnetze sind dann überhaupt nicht miteinander verbunden ... aber der PC kann beide benutzen. Wenn auf dem PC dann ein CUPS-Server läuft, dann kann der von überall Druckaufträge annehmen und dann den oder die Drucker ansteuern.

Zitat von Igel1954

Wenn der Drucker per Netzwerkkabel, ohne Router/Switch dazwischen, direkt am PC angeschlossen werden soll, dann hast du aber doch sicher ein gekreuztes Netzwerkkabel genommen?
Das ist doch genauso als würde ich 2 PC direkt miteinander über ein Netzwerkkabel verbinden wollen, dass funktioniert nämlich nur mit einem gekreuzten Netzwerkkabel.

Meistens geht es auch mit normalem Kabel. Seit 99 ist die automatische Umschaltung in der Buchse normiert und inzwischen weit verbreitet (für Gigabit-Ethernet sogar verpflichtend).

Zitat von Petert

n.b. :
> selbst in "scangearmp2-3.70-1-rpm.tar" ( Canon selbst) scheint der treiber nicht enthalten zu sein.
> sane-backends 1.0.29-lp151.135.1 waren von Anfang an mitinstalliert.

Der pixma-Treiber ist in den sane-backends.
Auch die Angabe, dass das USB-Gerät 04a9:1913 ein Scanner ist und dass der Treiber pixma ist ist da ... aber nur in
sane-backends-autoconfig-1.0.29 und noch nicht in 1.0.27. 1.0.27 ist normal für 15.1

Evtl. hattest Du also sane-backends-autoconfig noch auf dem normalen 15.1er Stand.

Im Endeffekt fehlte dann vielleicht nur die Zeile

ATTR{idVendor}=="04a9", ATTR{idProduct}=="1913", ENV{sane_backend_pixma}="yes"

in der Datei /usr/lib/udev/rules.d/56-sane-backends-autoconfig.rules