Tag Archives: fedora

Fedora 24: Wenn Automount nicht mehr geht

Posted on by

Wenn man einen USB-Stick in seinen Rechner steckt, erwartet man eigentlich, daß er als Laufwerk auftaucht. Seitdem Update auf Fedora 24 passierte das bei mir nicht mehr.

Schuld dürfte das unterbrochene Upgrade von F23 auf F24 sein, aber wer weiß.  Erstmal die Lage feststellen…

Werden die Drives gefunden ?

Als erstens schauen wir ins .. ups.. das gibt bei Euch nicht ja gar nicht mehr… /var/log/messages (Pech, ich habs noch 🙂 ) Wenn Ihr /v/l/m nicht mehr habt, dann könnt Ihr z.B. „dmesg“ befragen.

Steckt man einen USB Stick rein, muß sowas im Log erscheinen:

Nov  2 15:51:07 eve kernel: usb-storage 3-2:1.0: USB Mass Storage device detected
Nov  2 15:51:07 eve kernel: scsi host4: usb-storage 3-2:1.0
Nov  2 15:51:08 eve kernel: scsi 4:0:0:0: Direct-Access     Intenso  Rainbow Line     8.07 PQ: 0 ANSI: 4
Nov  2 15:51:08 eve kernel: sd 4:0:0:0: Attached scsi generic sg4 type 0
Nov  2 15:51:08 eve kernel: sd 4:0:0:0: [sdd] 7907328 512-byte logical blocks: (4.05 GB/3.77 GiB)
Nov  2 15:51:08 eve kernel: sd 4:0:0:0: [sdd] Write Protect is off
Nov  2 15:51:08 eve kernel: sd 4:0:0:0: [sdd] Write cache: disabled, read cache: enabled, doesn’t support DPO or FUA
Nov  2 15:51:08 eve kernel: sdd: sdd1
Nov  2 15:51:08 eve kernel: sd 4:0:0:0: [sdd] Attached SCSI removable disk

Merkt GVFS, daß ein Gerät angeschlossen wurde ?

In einer Bash als normaler User führt Ihr mal „gvfs-mount -o -i“ aus:

Da müßte dann sowas stehen :

Drive changed:      'Intenso Rainbow Line'
  Drive(0): Intenso Rainbow Line
    Type: GProxyDrive (GProxyVolumeMonitorUDisks2)
    ids:
     unix-device: '/dev/sdd'
    themed icons:  [drive-removable-media-usb]  [drive-removable-media]  [drive-removable]  [drive]
    symbolic themed icons:  [drive-removable-media-usb-symbolic]  [drive-removable-media-symbolic]  [drive-removable-symbolic]  [drive-symbolic]  [drive-removable-media-usb]  [drive-removable-media]  [drive-removable]  [drive]
    is_media_removable=1
    has_media=1
    is_media_check_automatic=1
    can_poll_for_media=0
    can_eject=1
    can_start=0
    can_stop=0
    start_stop_type=shutdown
    sort_key=01hotplug/1478096885644198

Volume added:       'Daten'
  Volume(0): Daten
    Type: GProxyVolume (GProxyVolumeMonitorUDisks2)
    ids:
     class: 'device'
     unix-device: '/dev/sdd1'
     uuid: '227C9F0E7E06FAF9'
     label: 'Daten'
    themed icons:  [drive-removable-media-usb]  [drive-removable-media]  [drive-removable]  [drive]
    symbolic themed icons:  [drive-removable-media-usb-symbolic]  [drive-removable-media-symbolic]  [drive-removable-symbolic]  [drive-symbolic]  [drive-removable-media-usb]  [drive-removable-media]  [drive-removable]  [drive]
    can_mount=1
    can_eject=1
    should_automount=1
    sort_key=gvfs.time_detected_usec.1478096885851240

d.b. das GVFS Kenntnis von dem neuen Gerät hat und nun an den Filemanager melden kann, daß DER es einhängen soll.

Wieso werden die dann nicht gemountet ?

Um das zu beantworten muß man etwas über Prozesskommunikation wissen. Die im OS dafür zuständige Komponente heißt D-BUS . Über den D-BUS kann Anwendung A Informationen an Anwendung B senden. Damit das auch bei Desktopanwendungen funktioniert, braucht es eine Spezialversion D-BUS X11 .

Die hatte es wohl bei meinem unterbrochenen Upgrade nicht sauber installiert, also holen wir das nach:

dnf reinstall dbus-x11

Reinstall simuliert das Entfernen und erneute Installieren in einem Rutsch. Danach noch Nautilus oder Nemo neu starten:

killall nautilus; nautilus --force-desktop

und schon tauchen die Laufwerke auch wieder auf dem Desktop und im Nautilus auf.

So leicht das hier auch klingt, in Realität hat es Stunden gedauert, bis ich das gefunden hatte.

Fedora 24: Mousegeschwindigkeit justieren

Posted on by

Wie schon in Fedora 22 und 23, geht mal wieder die Mauseinstellung im Gnome Einstellungsfenster nicht. Das ist aber kein Beinbruch, denn das läßt sich ganz einfach beheben.

Zunächst öffnet man die Datei „.bashrc“ im eigenen Homeverzeichnis:

# .bashrc

# Source global definitions
if [ -f /etc/bashrc ]; then
    . /etc/bashrc
fi

# User specific aliases and functions

Unter den User spezifischen Anpassungen tragen wir das ein :

cd ~/
xinput set-prop DEVICEID PROPID 1.6 2>/dev/null

Aber woher bekommen wir die nötigen Werte ?

Zunächst listen wir mal alle möglichen Eingabegeräte auf, die unser System so gefunden hat:

$ xinput list
⎡ Virtual core pointer                        id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                  id=4    [slave  pointer  (2)]
⎜   ↳ ImPS/2 BYD TouchPad                         id=11    [slave  pointer  (2)]
⎣ Virtual core keyboard                       id=3    [master keyboard (2)]
    ↳ Virtual core XTEST keyboard                 id=5    [slave  keyboard (3)]
    ↳ Power Button                                id=6    [slave  keyboard (3)]
    ↳ Power Button                                id=7    [slave  keyboard (3)]
    ↳ UVC Camera (046d:081b)                      id=8    [slave  keyboard (3)]
    ↳ Eee PC WMI hotkeys                          id=9    [slave  keyboard (3)]
    ↳ AT Translated Set 2 keyboard                id=10    [slave  keyboard (3)

Wie man sehen kann, ist alles dabei: das Keyboard/Tastatur, Kamera, Gehäusetasten und unsere Maus (Pointer), hier vermeindlich als ImPS/2 BYD TouchPad bezeichnet. Da es nicht „Virtual“ also virtuell ist, muß es das reale Zeigersystem sein. Damit haben wir unsere DEVICEID :  11 .

Jetzt schauen wir mal welche Eigenschaften das Device 11 hat:

$ xinput list-props 11
Device 'ImPS/2 BYD TouchPad':
    Device Enabled (151):    1
    Coordinate Transformation Matrix (153):    1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
    Device Accel Profile (278):    0
    Device Accel Constant Deceleration (279):    1.600000
    Device Accel Adaptive Deceleration (280):    1.000000
    Device Accel Velocity Scaling (281):    10.000000
    Device Product ID (273):    2, 5
    Device Node (274):    "/dev/input/event3"
    Evdev Axis Inversion (282):    0, 0
    Evdev Axes Swap (284):    0
    Axis Labels (285):    "Rel X" (161), "Rel Y" (162), "Rel Vert Wheel" (277)
    Button Labels (286):    "Button Left" (154), "Button Middle" (155), "Button Right" (156), "Button Wheel Up" (157), "Button Wheel Down" (158), "Button Horiz Wheel Left" (159), "Button Horiz Wheel Right" (160)
    Evdev Scrolling Distance (287):    1, 1, 1
    Evdev Middle Button Emulation (288):    0
    Evdev Middle Button Timeout (289):    50
    Evdev Third Button Emulation (290):    0
    Evdev Third Button Emulation Timeout (291):    1000
    Evdev Third Button Emulation Button (292):    3
    Evdev Third Button Emulation Threshold (293):    20
    Evdev Wheel Emulation (294):    0
    Evdev Wheel Emulation Axes (295):    0, 0, 4, 5
    Evdev Wheel Emulation Inertia (296):    10
    Evdev Wheel Emulation Timeout (297):    200
    Evdev Wheel Emulation Button (298):    4
    Evdev Drag Lock Buttons (299):    0

Das Property „Device Accel Constant Deceleration“ hat die ID 279 bekommen. Unter Fedora 23 war es noch die ID 268, weswegen mein kleiner Hack nicht mehr funktioniert hat. Setzen wir das mal ein :

cd ~/
xinput set-prop 11 279 1.6 2>/dev/null

Was macht das jetzt genau ?

Normalerweise hat diese Eigenschaft den Wert 1.0000. Das entspricht einer Dämpfung der Geschwindigkeit von : „gar nicht“. Erhöhen wir den Wert langsam, merkt man, das die Mausbewegung immer langsamer wird. Jetzt liegt es an Euch selbst herauszufinden, was für Euch der passende Wert ist. Ihr könnt den Befehl auch direkt in der Bash ausführen und so ganz leicht ausprobieren, was Euch gefällt. Was anderes macht der Einsteller im Einstellungsfenster am Ende auch nicht.

Update: Fedora OpenSSH Alarm: Nicht updaten auf 7.2p2-6 !

Posted on by

Wie gestern schon berichtet, ist die openssh Version 7.2p2-6 für Fedora defekt,

Wer keinen Zugang zu seiner Monitor Konsole hat und trotzdem das Downgrade einspielen muß, kann nun auf diesen Weg zurückgreifen:

Workaround V2.0: Downgrade auf 7.2p2-3

Über den Kojilink lädt man die drei Pakete runter:

Koji :  http://koji.fedoraproject.org/koji/buildinfo?buildID=756836

dann loggt man sich via defektem SSHD ein und  downgraded die Files für einen oneshot CronJob:

echo „59 16 * * * root /usr/bin/rpm -U –force /tmp/openssh*rpm > /tmp/log; rm -f /etc/cron.d/onetime“ > /etc/cron.d/onetime

Die Uhrzeit muß man natürlich an seine aktuelle Zeit anpassen 😉

Dann Ausloggen und nach der Zeit wieder einloggen. Der Befehl „rpm -qa | grep openssh“ sollte dann 7.2p2-3 anzeigen, welches die letzte funktionierende Version war.  Danach in /etc/dnf/dnf.conf einfügen:

exclude=openssh*

erst dann zieht das nächste Update nicht wieder die defekte Version auf den Server.

Das ganze klappt, weil der crond als „echter“ Root außerhalb der SSH Session läuft und nicht über sshd angetriggert wird.

Erste Hinweise zu den Ursachen des Problems

Wie im Bugtracker von RedHat einsehbar ist, kristallisieren sich grade Probleme mit der Chroot-Funktion vom SSHD heraus. Ist die Chroot aktiviert, was man tun sollte um Benutzer den Zugang zum System zu verweigern, so daß diese keine lokalen Angriffe fahren können, sondern in einer eigenen Umgebung arbeiten können. werden die für Root nötigen Capabilities nicht mehr gesetzt.

Capabilities sind die Eigenschaften eines Users, die erweiterte Rechte im Linuxsystem beinhalten, wie z.b. das Recht sich mit PTRACE in Prozessen einzuklinken, um diese zu belauschen oder zu verändern. Diese Capabilities machen Root erst aus und fehlen in der aktuellen sshd version:

# capsh --print
Current: =
Bounding set =
Securebits: 00/0x0/1'b0
 secure-noroot: no (unlocked)
 secure-no-suid-fixup: no (unlocked)
 secure-keep-caps: no (unlocked)
uid=0(root)
gid=0(root)
groups=

Meine Vermutung: Da hat wer zuviel weggepatcht 😉