Sun Type7 toetsenbord speciale toetsen

Het Sun Type7 toetsenbord dat ik gebruik op mijn werk heeft aan de linkerkant een aantal speciale toetsen. Deze hebben allemaal een keysym alleen doen ze nagenoeg niets. Heb ze nu met Openbox allemaal een functie gegeven.

    <keybind key="Help">
      <action name="Execute">
        <command>xdotool key F1</command>
      </action>
    </keybind>
    <keybind key="Cancel">
      <action name="Execute">
        <command>xkill</command>
      </action>
    </keybind>
    <keybind key="Redo">
      <action name="Execute">
        <command>xdotool key ctrl+y</command>
      </action>
    </keybind>
    <keybind key="SunProps">
      <action name="Execute">
        <command>xdotool key Menu</command>
      </action>
    </keybind>
    <keybind key="Undo">
      <action name="Execute">
        <command>xdotool key ctrl+z</command>
      </action>
    </keybind>
    <keybind key="SunFront">
      <action name="Execute">
        <command>xdotool keydown alt key Tab</command>
      </action>
    </keybind>
    <keybind key="XF86Copy">
      <action name="Execute">
        <command>xdotool key ctrl+c</command>
      </action>
    </keybind>
    <keybind key="SunOpen">
      <action name="Execute">
        <command>xdotool key ctrl+o</command>
      </action>
    </keybind>
    <keybind key="XF86Paste">
      <action name="Execute">
        <command>xdotool key ctrl+v</command>
      </action>
    </keybind>
    <keybind key="Find">
      <action name="Execute">
        <command>xdotool key ctrl+f</command>
      </action>
    </keybind>
    <keybind key="XF86Cut">
      <action name="Execute">
        <command>xdotool key ctrl+x</command>
      </action>
    </keybind>

Heb voor het sturen van de keystrokes xdotool gebruikt. Een sudo apt-get install xdotool volstaat om dat te installeren. De output van de speciale Sun toetsen heb ik achterhaald met xev wat als het goed is standaard al geïnstalleerd is. Bovenstaande code kun je gebruiken in het configuratiebestand van Openbox, in mijn geval is dat ~/.config/openbox/lubuntu-rc.xml. Daarna openbox --reconfigure draaien om de boel opnieuw in te laden.

Sun toets Functie
Help Help functie van applicatie (F1)
Stop Applicatie killen (xkill)
Again Opnieuw uitvoeren (Control+y)
Props Context menu (Menu)
Undo Ongedaan maken (Control+z)
Front Applicatielijst (Alt+Tab)
Copy Kopiëren (Control+c)
Open Openen bestand (Control+o)
Paste Plakken (Control+v)
Find Zoeken (Control+f)
Cut Knippen (Control+x)
Sun Type7 toetsenbord speciale toetsen

XFCE Power Manager

Lijkt een futiliteit maar kan toch frustrerend zijn: een niet werkend toetsje op je toetsenbord. Ik wilde per sé de Sleep toets op mijn Sun Type7 toetsenbord aan de praat krijgen, op de een of andere manier werkte die niet. Ben er uiteindelijk achter gekomen dat het aan het pakket xfce4-power-manager lag. Die ving kennelijk de keysym van de Sleep toets af (XF86PowerOff) om er vervolgens niets mee te doen. Na dit pakket gedeïnstalleerd te hebben en openbox --reconfigure te hebben gedraaid werkte de Sleep toets weer naar behoren.

Edit: ga nog wel uitzoeken waarom xfce4-power-manager het niet doet, als xfce4-power-manager namelijk wel draait en ik stel als actie Shutdown in als de Power knop wordt ingedrukt dan sluit het systeem af als ik de Sleep toets indruk. Stel ik als actie Ask in dan gebeurt er niks terwijl dan het Lubuntu uitlogscherm zou moeten verschijnen.

Edit 2: Bijbehorende bugreport gevonden:
https://bugs.launchpad.net/xfce4-power-manager/+bug/1008650
Staat ook een link in naar een workaround:
http://www.who.is.free.fr/wiki/doku.php?id=xfce#power_button_event_workaround

Het script op die pagina is wel erg uitgebreid, bij mij volstaat het volgende:

#!/bin/bash
xfce4-power-manager -q
openbox --reconfigure
xfce4-power-manager

Dit bestandje heb ik fix-power-button genoemd en start ik op via $HOME/.config/lxsession/Lubuntu/autostart

XFCE Power Manager

Openbox en Java

Als ik application title matching wilde doen met Openbox dan wilde bijna geen enkele Java applicatie meer opstarten. Bleek om deze bug te gaan.

$ apt-get source openbox
$ wget
https://github.com/danakj/openbox/commit/c5468fb6cf6341205c15603eb96130fa26bfaea3.patch
-O application-title-matching.patch
$ patch -d openbox-3.5.0 -p1 < application-title-matching.patch
$ cd openbox-3.5.0
$ dpkg-source --commit
$ dch -i # Optioneel
$ debuild -S
$ cd ..
$ pbuilder-dist precise build openbox_3.5.0-2ubuntu3~precise0.dsc
$ dpkg -i ~/pbuilder/precise_result/openbox_3.5.0-2ubuntu3~precise0_amd64.deb

Nu kan ik Thunderbird, Firefox en mijn terminals weer plaatsen waar ik wil terwijl mijn Java applicaties (zoals de OpenDJ Control Panel applicatie) ook weer gewoon opstarten.

Openbox en Java

Nieuwe FFADO versie op komst

Er zit een nieuwe FFADO release aan te komen, FFADO 2.1.0.

De laatste puntjes worden op de i gezet en hopelijk wordt de nieuwe versie begin volgende week gereleased. Naast dat er een sloot aan nieuwe devices ondersteund worden in deze versie zijn er ook een hoop bugs gefixed en is er de nodige aandacht besteed aan ffado-mixer om deze goed werkende te krijgen met bijvoorbeeld de nieuwere Focusrites (de PRO 14, 24 en 40).

Voor mij persoonlijk verandert er niet veel, mijn Focusrite Saffire PRO 40 werkt feilloos onder Ubuntu 12.04. Maar in de toekomst zou ik wel graag een RME Fireface 400 aan willen schaffen en die wordt ondersteund met de aankomende FFADO release. Een bandmaat heeft een tijdlang twee Focusrite Saffire Pro 10’s gehad en deze recentelijk omgeruild met een RME Fireface 800 en volgens hem zijn de A/D D/A convertors gewoon stukken beter dan die van Focusrite.

Nieuwe FFADO versie op komst

YubiKeys, SSH, PAM en LDAP

Hoe tweeweg authenticatie op te zetten voor SSH logins met behulp van YubiKeys, PAM en LDAP (via SSL) op een Ubuntu 12.04 installatie.

Benodigde pakketjes

sudo apt-get install ldap-auth-client libpam-yubico

Conflicterende pakketjes

Mocht het pakketje nscd geïnstalleerd zijn, deïnstalleer deze. Dit pakket verhindert een goede werking van de YubiKey-LDAP authenticatiemethode.

ldap-auth-config

Tijdens het installeren van het pakketje ldap-auth-client wordt er een aantal gegevens gevraagd. Doorloop de set-up als volgt:

  • LDAP server Uniform Resource Identifier: ldaps://fqdn.van.ldap.server:poortnummer
  • Distinguished name of the search base: dc=voorbeeld,dc=com
  • LDAP version to use: 3
  • Make local root Database admin: No
  • Does the LDAP database require login? No

/etc/ldap.conf

Dit bestand regelt de verbinding met je LDAP server. De setup van ldap-auth-client heeft de boel nu ingesteld maar eigenlijk heb je deze hele setup niet nodig want met een /etc/ldap.conf met de volgende drie regels ben je er ook:

base dc=voorbeeld,dc=com
uri ldaps://fqdn.ban.ldap.server:poortnummer
tls_cacertfile /etc/ssl/certs/cacert.org.pem

Je kunt dus een deel van wat de setup heeft aangemaakt laten staan, de rest kun je uithekken. Zoals je ziet heb ik voor de SSL kant van het verhaal voor CAcert.org gekozen als CA. Je moet dan ook expliciet verwijzen naar de root certificaten van CAcert.org anders kan er niet gebind worden met de LDAP server. De LDAP server, in mijn geval een OpenDJ directory server, maakt dus gebruik van door CAcert.org getekende certifcaten.

/etc/nsswitch.conf

Dit bestand regelt op welke manier en in welke volgorde de verschillende nameservices worden aangesproken. In ons geval gaat het om de entries password, shadow en groups in dit bestand. Standaard staan die in Ubuntu 12.04 op compat. Om Ubuntu eerst de fysieke bestanden en daarna LDAP te laten checken moet compat veranderd worden in files ldap. Dit gaat het snelst met een sed commando:

sudo sed -i 's/compat/files ldap/g' /etc/nsswitch.conf

Nu /etc/nsswitch.conf is ingesteld kun je gaan testen of je LDAP connectie goed is:

id ldapgebruiker
getent passwd
getent group

PAM

Nu is het zaak PAM zo in te stellen dat je zowel tegenover de Yubico servers authenticeert met je YubiKey als tegenover LDAP wanneer je SSH’t naar je machine. Dit regel je in /etc/pam.d/sshd:

# PAM configuration for the Secure Shell service

# Read environment variables from /etc/environment and
# /etc/security/pam_env.conf.
auth       required     pam_env.so # [1]
# In Debian 4.0 (etch), locale-related environment variables were moved to
# /etc/default/locale, so read that as well.
auth       required     pam_env.so envfile=/etc/default/locale

# Yubikey authentication
#
# Allow local accounts for the moment.
auth sufficient pam_unix.so

# Fetch LDAP password + OTP, verify OTP and move on ('required' control value).
# LDAP password is stripped and passed on.
auth required pam_yubico.so id=1234 ldap_uri=ldaps://fqdn.van.ldap.server:poortnummer [ldapdn=ou=People,DC=voorbeeld,DC=com] user_attr=uid yubi_attr=yubikeyid

# LDAP authentication
#
# Verify the LDAP password that has been passed on ('use_first_password' argument)
# and grant access when password gets accepted ('sufficient' control value).
auth sufficient pam_ldap.so use_first_pass

# Standard Un*x authentication.
@include common-auth

# Disallow non-root logins when /etc/nologin exists.
account    required     pam_nologin.so

# Uncomment and edit /etc/security/access.conf if you need to set complex
# access limits that are hard to express in sshd_config.
# account  required     pam_access.so

# Standard Un*x authorization.
@include common-account

# LDAP session
#
# Create homedir for LDAP user if it doesn't exist yet.
session required pam_mkhomedir.so skel=/etc/skel/ umask=0022

# Standard Un*x session setup and teardown.
@include common-session

# Print the message of the day upon successful login.
session    optional     pam_motd.so # [1]

# Print the status of the user's mailbox upon successful login.
session    optional     pam_mail.so standard noenv # [1]

# Set up user limits from /etc/security/limits.conf.
session    required     pam_limits.so

# Set up SELinux capabilities (need modified pam)
# session  required     pam_selinux.so multiple

# Standard Un*x password updating.
@include common-password

De dikgedrukte gedeeltes zijn toegevoegd. Het id wat is toegevoegd bij de pam_yubico.so module kun je aanvragen via Yubico. Dit id is de zgn. API Key. Ook heb ik een extra opties toegevoegd:

yubi_attr=yubikeyid

Wat dit doet is de mapping gebruiker – YubiKey Public ID checken op de LDAP server, dus niet op de machine zelf. Het gros van de handleidingen gaat ervan uit dat je de mappings op de machine zelf maakt in platte bestandjes. Maar dat wil je helemaal niet, daar heb je nou juist je LDAP server voor, zodat je dit soort dingen als mappings centraal kan regelen. Wat ik heb gedaan is een objectclass yubikey toegevoegd aan de OpenDJ configuratie en deze een attribute yubikeyid meegegeven. Hoe ik dit heb gedaan komt nog wel aan bod in een latere entry waarin ik ook zal uitleggen hoe je users die in moeten kunnen loggen op je machine moet aanmaken in OpenDJ. De objectclass yubikey heb ik op zijn beurt weer toegevoegd als auxiliary objectclass bij de gebruikers die een YubiKey hebben. Vervolgens kan ik dan in het veld yubikeyid het Public ID ingeven van de YubiKey die bij een bepaalde gebruiker hoort. Het Public ID bestaat uit de eerste 12 tekens van de OTP die een YubiKey genereert. Je kan ook een bestaande attribute gebruiken, Zarafa gebruikt bijvoorbeeld het carLicense attribute. Maar dit gaat er bij mij niet in, een YubiKey Public ID is geen rijbewijs, dus krijgt het een eigen attribute.

Als je nu via SSH inlogt met je LDAP wachtwoord meteen gevolgd door je YubiKey OTP op dezelfde regel zou je keurig geauthenticeerd moeten worden. Eerst tegenover de Yubico Cloud, vervolgens stript de pam_yubico.so module het wachtwoord en haalt het YubiKey OTP eraf en geeft de rest door aan pam_ldap.so die je nu met het overgebleven wachtwoord authenticeert tegenover je LDAP server. En mocht je nog geen home directory hebben dan wordt deze aangemaakt door pam_mkhomedir.so.

YubiKeys, SSH, PAM en LDAP

YubiKeys

De afgelopen tijd zijn de nodige bedrijven gehackt waaronder ook wat telecombedrijven. M’n baas kreeg daar de kriebels van en heeft een zak met YubiKeys aangeschaft. Of ik de authenticatie met die dingen even kon implementeren voor het hele netwerk.

Met YubiKeys kun je tweeweg authenticatie opzetten, in ons geval LDAP authenticatie in combinatie met de YubiKeys. Maar een LDAP server was er ook nog niet. SSH’en bijvoorbeeld ging met lokale accounts en ik werk wel met keys maar mijn collega’s niet. Vragen om moeilijkheden dus eigenlijk.

Van LDAP had ik weinig kaas gegeten maar uiteindelijk kwam ik na wat tips van mijn chef uit bij OpenDJ, een op Java gebaseerde LDAP directory server. OpenDJ installeren is redelijk eenvoudig, alleen staat nergens beschreven hoe je dit echt veilig moet doen. Het viel me al op dat er in de installatiehandleiding niet-standaard LDAP poorten gebruikt werden hoger dan 1024. Dit zijn unprivileged poorten die geopend mogen worden door gewone gebruikers dus heb het ook zo opgezet, dus dat OpenDJ draait onder een systeemuseraccount wat verder niks mag.

Volgende stap was het opzetten van een RADIUS server voor de YubiKeys. Je kan natuurlijk ook direct tegen de Yubico servers authenticeren maar die kun je voor zover ik weet niet koppelen aan je eigen LDAP server en ook niet goed beheren qua gebruikers. Ik ben degene die bepaalt aan wie welke YubiKey wordt toegewezen die toegang krijgt tot ons netwerk, niet de collega’s zelf. Voor het opzetten van een dergelijke server heb ik de YubiRADIUS Virtual Appliance gebruikt, een VMware image dat ik gedeployed heb op onze ESXi server. Dat is een Debian 6 installatie die ik nog wel wat heb moeten tweaken, ik ga bijvoorbeeld echt geen netwerkinstellingen op een server configureren via Network Manager.

Wat users opgevoerd in LDAP, YubiKeys toegewezen op de YubiRADIUS server, maar hoe nu verder? Hoe zet ik de tweeweg authenticatie op voor bijvoorbeeld SSH toegang? De beschikbare documentatie is summier en wat betreft het opzetten van tweeweg authenticatie met behulp van LDAP en YubiKeys onder Linux is er eigenlijk helemaal geen documentatie beschikbaar. Dit moet je met PAM doen en er is een YubiKey PAM module beschikbaar maar hoe je de authenticatie uiteindelijk moet implementeren wordt nergens beschreven.

Uiteindelijk heb ik het goed werkend gekregen en ik zal proberen om de werkende configuratie om via SSH in te loggen met behulp van YubiKeys en LDAP authenticatie te beschrijven in een vervolgentry.

YubiKeys

Yoshimi 1.0.0

Op 2 juli is Yoshimi 1.0.0 uitgekomen ter nagedachtenis van Alan “Cal” Calvert die op die dag precies een jaar geleden overleden is. Naast wat kleine aanpassingen en patches is het vooral een eerbetoon aan Alan Calvert. En Yoshimi is stabiel genoeg voor een 1.0.0 release. De planning is nu dat ik ga werken aan het aanpassen van de sources om Yoshimi 1.x.x weer dichter bij ZynAddSubFX te brengen zodat op de lange duur de projecten samen zouden kunnen smelten. De ontwikkelbranch (nu 0.062.x) zal wel blijven bestaan.

Yoshimi 1.0.0

Zelf een real-time kernel bouwen voor Ubuntu 12.04

De real-time kernel uit de PPA van Alessio Bogani liep bij mij nog wel eens vast dus heb ik er zelf een gebouwd met de meest recente 3.2 kernel en bijbehorende RT patchset. En dit draait een stuk stabieler, nog geen lockups gehad.

Een eigen kernel bouwen is gelukkig nog steeds niet zo heel moeilijk, met Ubuntu kun je zelfs heel gemakkelijk pakketten maken met behulp van de make-kpkg utility. Na wat googlen kwam ik onderstaande handleiding tegen en simpeler kan het bijna niet.

Installeer de benodigde pakketten:

sudo apt-get install kernel-package fakeroot build-essential libncurses5-dev

Download de kernel sources en de RT patchset:

mkdir -p ~/tmp/linux-rt
cd ~/tmp/linux-rt
wget -c http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.2.28.tar.bz2
wget -c
http://www.kernel.org/pub/linux/kernel/projects/rt/3.2/patch-3.2.28-rt42.patch.bz2

Pak de kernel sources uit en patch deze met de RT patchset:

tar xjvf linux-3.2.28.tar.bz2
cd linux-3.2.28
patch -p1 < <(bunzip2 -c ../patch-3.2.28-rt42.patch.bz2)

Nu moet je de kernel nog configureren. De gemakkelijkste manier is om een bestaande kernel config te nemen, deze staan in de /boot directory van je systeem. Kopieer een config naar je werkdirectory en gebruik deze als uitgangspunt:

cp /boot/config-$(uname -r) .config

Dit commando kopieert de kernel config van de kernel die je op dat moment gebruikt. Je kunt ook de config van een andere kernel gebruiken, bijv. die van de Ubuntu lowlatency kernel aangezien deze al geoptimaliseerd is voor Linux audio toepassingen. De volgende stap is om een kernel config aan te maken met full preemption ingeschakeld aan de hand van de gekopieerde kernel config:

make oldconfig

Je kunt alle prompts wegklikken met Enter, behalve de prompt welk Preemption Model je wilt gebruiken. Selecteer daar 5 (Fully Preemtible Kernel):

Preemption Model
> 1. No Forced Preemption (Server) (PREEMPT_NONE)
  2. Voluntary Kernel Preemption (Desktop) (PREEMPT_VOLUNTARY)
  3. Preemptible Kernel (Low-Latency Desktop) (PREEMPT__LL) (NEW)
  4. Preemptible Kernel (Basic RT) (PREEMPT_RTB) (NEW)
  5. Fully Preemptible Kernel (RT) (PREEMPT_RT_FULL) (NEW)
choice[1-5]: 5 <Enter>

Workaround voor https://bugs.launchpad.net/ubuntu/+source/kernel-package/+bug/602405:

sed -rie 's/echo "+"/#echo "+"/' scripts/setlocalversion

Nu kun je de kernel gaan bouwen:

make-kpkg clean
CONCURRENCY_LEVEL=$(getconf _NPROCESSORS_ONLN) fakeroot make-kpkg
--initrd --revision=0 kernel_image kernel_headers

Als het bouwen klaar is (kan een tijd duren) kun je de kernel pakketjes installeren:

cd ..
sudo dpkg -i linux-{headers,image}-3.2.28-rt42_0_*.deb

Rebooten, nieuwe real-time kernel selecteren in je bootloader (GRUB) en je systeem zou nu moeten booten met de net gebouwde real-time kernel.

Zelf een real-time kernel bouwen voor Ubuntu 12.04

Homestudio migratie

Migratie voorloopt voorspoedig. Bijna alles draait weer en het systeem voelt weer lekker fris en fruitig aan. Enige echte lastpost is de real-time kernel die ik heb geïnstalleerd, die wil nog wel eens vastlopen (kernel panics). Maar dat komt waarschijnlijk omdat het al een oudere versie is (zo te zien 3.2.14-rt24, recentste versie is 3.2.19-rt30). Zal dus de lowlatency kernel moeten gebruiken, nog niet uitgebreid getest maar ik denk dat dat wel goed komt. Dan kan ik ook zonder problemen de plug-ins gebruiken van het Distrho project. Die maken bijna allemaal gebuik van het Juce framework en dat framework is voor zover ik het heb begrepen niet helemaal real-time safe zoals dat heet. Oftewel, plug-ins gebaseerd op dat framework doen het niet goed met een real-time kernel en kunnen zelfs je systeem laten crashen.

Homestudio migratie