2012-11-18

RPM-paket för BankID för 32- och 64-bitars Fedora 17

This is another post about the Swedish digital signing and identification program BankID. Its written in Swedish.

Inledning

Det här är en fortsättning på det tidigare inlägget om BankID. Nu är det dags att paketera BankID i en RPM för enkel installation/uppgradering/mm.

Paketeringen utgår från innehållet i den officiella filen, bisp-4.19.1.11663.tar.gz, men lägger filerna där de skall i Fedora. Paketeringen har också effekten att alla beroenden till andra bibliotek löses och kommer installeras automatiskt när man installerar RPM:en.

RPM:en kan installeras och användas på både 32- och 64-bitars Fedora 17.


Sätt upp byggmiljön för RPM

För att kunna bygga RPM-paket under Fedora så behöver man först installera paktet rpmdevtools:
 $ sudo yum install rpmdevtools
Nästa steg är att köra ett program för att sätta upp katalogstrukturen för RPM-byggena:
 $ rpmdev-setuptree
rpmdev-setuptree skapar katalogen ~/rpmbuild och ett antal kataloger därunder.

Nu är det dags att förbereda RPM-bygget.


Förbered bygget

Ladda ner den officiella tarbollen härifrån (klicka på Ubuntu/Linux): https://install.bankid.com/Download/All och lägg filen i katalogen ~/rpmbuild/SOURCES.

Man behöver även en så kallad spec-fil som beskriver hur RPM:en skall byggas. Nedan finns en sådan spec-fil för BankID. Spar innehållet och lägg det i filen ~/rpmbuild/SPECS/bisp.spec (ersätt versionsnumret på andra raden med det som gäller för den nedtankade filen):
Name:           bisp
Version:        4.19.1.11663
Release:        1%{?dist}
Summary:        BankID Security Application for Linux
Group:          Applications/Internet
License:        Other
URL:            https://install.bankid.com/Download/All
Source0:        https://install.bankid.com/Repository/BISP-%{version}.tar.gz
BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Requires:       mozilla-filesystem
BuildRequires:  /usr/bin/hexdump /usr/bin/xxd

# Put "fake" version numbers on the .so files to shut rpmlint up
Provides:      libai.so = %{version}, libbisp.so = %{version}, libtokenapi.so = %{version}  

# Enable possibility to override the default dependency checking
%define _use_internal_dependency_generator 0

# Don't use the build in "provides" since it will "provide" the plugins in /usr/lib/personal
%define __find_provides %{nil}

# We still want to have requirements automatically figured out
%define __find_requires /usr/lib/rpm/find-requires

# Do not strip the binaries
%define __os_install_post %{nil}


%description
BankID Security Application for Linux is a set of programs and a Firefox plugin
used for digital authentication and signing in bank environments.


%prep
%setup -q -n BISP-%{version}


%build
# BankID normally installs in /usr/local and have hard coded paths in the
# binaries that point out files under /usr/local.
#
# When packaging RPMs, you should not put files in /usr/local since that
# location is for locally installed files and not stuff that comes in
# RPM format.
#
# The script below will replace /usr/local with /usr in the files needed
# to be able to package BIPS "correctly".

# Change /usr/local to /usr in scripts and desktop files
sed -i 's/\/usr\/local/\/usr/g' personal.desktop
sed -i 's/\/usr\/local/\/usr/g' personal.sh
sed -i 's/\/usr\/local/\/usr/g' persadm.sh

# Function to replace strings in binary files
function patch_strings_in_file() {
    local FILE="$1"
    local PATTERN="$2"
    local REPLACEMENT="$3"

    # Find all unique strings in FILE that contain the pattern 
    STRINGS=$(strings ${FILE} | grep ${PATTERN} | sort -u -r)

    if [ "${STRINGS}" != "" ] ; then
        echo "File '${FILE}' contain strings with '${PATTERN}' in them:"

        for OLD_STRING in ${STRINGS} ; do
            # Create the new string with a simple bash-replacement
            NEW_STRING=${OLD_STRING//${PATTERN}/${REPLACEMENT}}

            # Create null terminated ASCII HEX representations of the strings
            OLD_STRING_HEX="$(echo -n ${OLD_STRING} | xxd -g 0 -u -ps -c 256)00"
            NEW_STRING_HEX="$(echo -n ${NEW_STRING} | xxd -g 0 -u -ps -c 256)00"

            if [ ${#NEW_STRING_HEX} -le ${#OLD_STRING_HEX} ] ; then
                # Pad the replacement string with null terminations so the
                # length matches the original string
                while [ ${#NEW_STRING_HEX} -lt ${#OLD_STRING_HEX} ] ; do
                    NEW_STRING_HEX="${NEW_STRING_HEX}00"
                done

                # Now, replace every occurrence of OLD_STRING with NEW_STRING 
                echo -n "Replacing ${OLD_STRING} with ${NEW_STRING}... "
                hexdump -ve '1/1 "%.2X"' ${FILE} | \
                sed "s/${OLD_STRING_HEX}/${NEW_STRING_HEX}/g" | \
                xxd -r -p > ${FILE}.tmp
                mv ${FILE}.tmp ${FILE}
                echo "Done!"
            else
                echo "New string '${NEW_STRING}' is longer than old" \
                     "string '${OLD_STRING}'. Skipping."
            fi
        done
    fi
}

# List binary files to patch
FILES=$(ls *.so personal.bin persadm)

OLD_LIB_BASE_PATH="/usr/local/lib/personal"
NEW_LIB_BASE_PATH="/usr/lib/personal"

OLD_BIN_BASE_PATH="/usr/local/bin"
NEW_BIN_BASE_PATH="/usr/bin"

# Replace /usr/local/lib/personal with /usr/lib/personal and
# /usr/local/bin with /usr/bin
for FILE in ${FILES} ; do
    patch_strings_in_file ${FILE} ${OLD_LIB_BASE_PATH} ${NEW_LIB_BASE_PATH}
    patch_strings_in_file ${FILE} ${OLD_BIN_BASE_PATH} ${NEW_BIN_BASE_PATH}
done


%install
rm -rf %{buildroot}

# Create install layout
install -m 755 -d %{buildroot}%{_bindir}
install -m 755 -d %{buildroot}%{_libdir}/personal
install -m 755 -d %{buildroot}%{_libdir}/personal/icons
install -m 755 -d %{buildroot}%{_libdir}/personal/config
install -m 755 -d %{buildroot}%{_libdir}/personal/lang
install -m 755 -d %{buildroot}%{_libdir}/mozilla/plugins
install -m 755 -d %{buildroot}%{_datadir}/applications
install -m 755 -d html

# Install files in the buildroot
# Install libplugins.so as libbisp.so to not conflict file wise with a manual install
install -m 755 libplugins.so %{buildroot}%{_libdir}/mozilla/plugins/libbisp.so
install -m 755 libai.so libtokenapi.so %{buildroot}%{_libdir}
install -m 755 libBranding.so libCardEdb.so libCardGTOClsc.so libCardOberthur.so \
               libCardPrisma.so libCardSetec.so libCardSiemens.so libP11.so persadm \
               personal.bin %{buildroot}%{_libdir}/personal
install -m 755 persadm.sh %{buildroot}%{_bindir}/persadm
install -m 755 personal.sh %{buildroot}%{_bindir}/personal
# Install personal.desktop as bisp-personal.desktop to not conflict whith a manual install
install -m 644 personal.desktop %{buildroot}%{_datadir}/applications/bisp-personal.desktop
install -m 644 nexus_logo_32x32.png %{buildroot}%{_libdir}/personal/icons
install -m 644 BankID_Security_Application_Help* html
install -m 644 Personal.cfg %{buildroot}%{_libdir}/personal/config
chmod 644 BankIDUbuntu_ReadMe*
for D in $(ls ../lang) ; do
    install -m 755 -d %{buildroot}%{_libdir}/personal/lang/${D}
    install -m 644 ../lang/${D}/*.mo %{buildroot}%{_libdir}/personal/lang/${D}
done


%post
/sbin/ldconfig


%postun
/sbin/ldconfig


%files
%defattr(-,root,root,-)
%doc Release.txt html BankIDUbuntu_ReadMe*
%dir %{_libdir}/personal
%{_libdir}/personal/*
%{_libdir}/*.so
%{_libdir}/mozilla/plugins/*.so
%{_bindir}/*
%{_datadir}/applications/*.desktop


%changelog
* Sun Nov 18 2012 Name - 4.19.1.11663-1
- Initial release
Under %build-sektionen så görs en del fixar i filerna som utgör BankID. Det som sker är att sökvägen /usr/local byts ut mot /usr på valda ställen. När man bygger "riktiga" RPM:er så bör filer installeras på sina korrekta platser och det ser spec-filen till. Filen libplugins.so installeras dessutom som libbisp.so och filen personal.desktop installeras som bisp-personal.desktop. Det här är för att inte krocka filnamnsmässigt med en installation gjord med det "officiella" installationsscriptet. Filnamnsbytena påverkar inte funktionen.

Förberedelsen är nu klar. Dags att bygga RPM:en.


Bygg RPM:en

Med förberedelserna enligt ovan så är byggsteget enkelt. Kör bara:
 $ rpmbuild -bb --target i386 ~/rpmbuild/SPEC/bisp.spec
Om allt går bra så har du nu fått en RPM: ~/rpmbuild/RPMS/i386/bisp-4.19.1.11663-1.fc17.i386.rpm.

Genom att ange växlen --target i386 så kan man bygga RPM:en i både 32- och 64-bitars Fedora och ändå få en 32-bitars RPM. Eftersom BankID är ett 32-bitars program så är detta vad vi vill ha.


Installera RPM:en

Nu när RPM:en är klar så installeras den enligt följande:
 $ sudo yum install ~/rpmbuild/RPMS/i386/bisp-4.19.1.11663-1.fc17.i386
Alla beroenden som krävs kommer nu installeras automatiskt.

Om du kör 64-bitars Fedora så behöver du även installera nspluginwrapper.i686, nspluginwrapper.x86_64 och eventuellt oxygen-gtk2.i686 (om du kör KDE) för att det skall fungera. Det här är samma beroenden som beskrevs i det tidigare inlägget om BankID.


Tag bort det originalinstallerade BankID

Om du redan har BankID installerat enligt det tidigare inlägget så måste du nu avinstallera det. RPM:en som du byggt krockar inte filmässigt med en manuell installation, men du kan möjligen få problem när båda är installerade samtidigt.

Alltså, kör följande för att avinstallera en installation gjord från den officiella "tarbollen" (byt ur versionsnumret till det som gäller för din installation):
 $ sudo /usr/local/lib/personal/install.4.19.1.11663.sh u
 $ sudo rm -f /usr/lib/mozilla/plugins/libplugins.so
Glöm inte bort att starta om Firefox efter installationen!

Om du är riktigt petig så tar du även bort raden /usr/local/lib från filen /etc/ld.so.conf. Raden läggs till av det officiella installationsscriptet men tas inte bort vid en avinstallation.


Sammanfattning

Efter att ha installerat BankID RPM:en så använder du BankID på samma sätt som tidigare. Samma förutsättningar gäller som om du hade installerat BankID med hjälp av det officiella scriptet, dvs du behöver starta personal innan du surfar till en sida som kräver BankID. Se det föregående inlägget för alla detaljer.

2012-11-04

Patch strings in binary files with sed

So, you have a binary file that you need to patch. Perhaps it is a pre compiled proprietary program or dynamic library that contains hard coded paths (text strings) that you need to change.

If the file had been a text file, then sed would probably come to your rescue. For binary files there are hex editors available, but they require manual handling and can't be scripted. Other binary patch programs are out there as well but might not be packaged in your favorite distribution and compiling things from source is boring. You could also have the need to do the patching in a packaging stage when building say an RPM.

So, how can you use sed then?

Well, it's quite simple. Just convert the binary file to ASCII HEX with hexdump, patch it with sed and the convert it back to binary with xxd:
hexdump -ve '1/1 "%.2X"' file.bin | \
sed "s/<pattern>/<replacement>/g" | \
xxd -r -p > file.bin.patched
Of course there are caveats to this approach. The most significant one is that you can't replace a string with a string that is longer then the original one. Shorter is OK though. Another one is that the strings must be null terminated, but this is almost always the case. You also have to create <pattern> and <replacement> yourself as the ASCII HEX representations of the null terminated strings with their null terminator present. Further, <replacement> must be padded to the same length as <pattern>.

Lets take a concrete example:

You have a binary named foo that uses some plugins. The plugins are assumed to be in /usr/local/lib/foo and this path is hard coded in foo. You want to package foo with its plugins using your distributions packaging system and use the file system layout that your distribution uses.

So you will put foo in /usr/bin and put all the plugins in /usr/lib/foo. But foo would look in /usr/local/lib/foo when trying to load plugins and will therefore fail.

But, if we could replace all occurrences of /usr/local/lib/foo in foo with /usr/lib/foo everything shold work. Since the length of /usr/lib/foo is shorter then /usr/local/lib/foo this is doable.

Here is an example script that does the replacement:
#!/bin/bash

function patch_strings_in_file() {
    local FILE="$1"
    local PATTERN="$2"
    local REPLACEMENT="$3"

    # Find all unique strings in FILE that contain the pattern 
    STRINGS=$(strings ${FILE} | grep ${PATTERN} | sort -u -r)

    if [ "${STRINGS}" != "" ] ; then
        echo "File '${FILE}' contain strings with '${PATTERN}' in them:"

        for OLD_STRING in ${STRINGS} ; do
            # Create the new string with a simple bash-replacement
            NEW_STRING=${OLD_STRING//${PATTERN}/${REPLACEMENT}}

            # Create null terminated ASCII HEX representations of the strings
            OLD_STRING_HEX="$(echo -n ${OLD_STRING} | xxd -g 0 -u -ps -c 256)00"
            NEW_STRING_HEX="$(echo -n ${NEW_STRING} | xxd -g 0 -u -ps -c 256)00"

            if [ ${#NEW_STRING_HEX} -le ${#OLD_STRING_HEX} ] ; then
                # Pad the replacement string with null terminations so the
                # length matches the original string
                while [ ${#NEW_STRING_HEX} -lt ${#OLD_STRING_HEX} ] ; do
                    NEW_STRING_HEX="${NEW_STRING_HEX}00"
                done

                # Now, replace every occurrence of OLD_STRING with NEW_STRING 
                echo -n "Replacing ${OLD_STRING} with ${NEW_STRING}... "
                hexdump -ve '1/1 "%.2X"' ${FILE} | \
                sed "s/${OLD_STRING_HEX}/${NEW_STRING_HEX}/g" | \
                xxd -r -p > ${FILE}.tmp
                chmod --reference ${FILE} ${FILE}.tmp
                mv ${FILE}.tmp ${FILE}
                echo "Done!"
            else
                echo "New string '${NEW_STRING}' is longer than old" \
                     "string '${OLD_STRING}'. Skipping."
            fi
        done
    fi
}

patch_strings_in_file foo "/usr/local/lib/foo" "/usr/lib/foo"
Please note that this way of replacing strings does not allow for full blown regexp usage. You could probably modify the script to be more versatile if you have more complex needs. 

As always, watch out when you patch binary files. There could be circumstances when a replacement as described above will break the binary. Test, test, test and test some more...

2012-10-29

BankID Säkerhetsprogram, BISP, i 32- och 64-bitars Fedora 17

This post is about BankID Säkerhetsprogram which is a Swedish digital signing and identification program used by many banks and other institutions. The post is written i Swedish.

BankID

BankID finns officiellt för Linux eller snarare specifikt för Ubuntu 10.10. BankID tillhandahålls av företaget Finansiell ID-Teknik BID AB men tekniken bakom kommer från företaget Technology Nexus AB och mer specifikt deras produkt Nexus Personal Security Client.

Av någon anledning vill man inte stödja 64-bitars Linux trots att det faktiskt är ganska enkelt att använda mycket av 32-bitars BankID under 64-bitars Linux.

BankID kan lagra certifikat som används för identifiering och underskrifter antingen "mjukt" i form av lösenordsskyddad fil på disk eller på ett smartcard. Beroende på vilken bank eller annan utfärdare av ett BankID man har så används antingen mjukt certifikat eller kort. I mitt fall så är det mjukt certifikat som gäller, så hur BankID med kort fungerar under Fedora 17 återstår att undersöka.

Så, för att vara övertydlig, det här inlägget handlar om hur man får BankID med mjuka certifikat att fungera under 32- och 64-bitars Fedora 17.

BankID verkar även kunna användas för att komma åt certifikat som skall användas för att etablera säker kommunikation via HTTPS och autentisering via Firefox egna certifikathantering. Jag har ingen aning om det här är någon som används. För "vanliga" bankärenden så används det inte i de fall jag behöver använda BankID. Det finns dock en sektion om PKCS#11 nedan för dem som är intresserad.


Hämta hem BISP

Om man surfar till bankid:s hemsida från 64-bitars Fedora så får man veta att ens operativsystem inte stöds. Man får klicka lite för att komma till nedladdningssidan för att kunna få hem BISP. Direktlänk för nedladdning är här: https://install.bankid.com/Download/All. Klicka på "Linux/Ubuntu"-knappen för att ladda hem BISP.


Installera BISP, steg ett

Packa först upp filen som du tankade hem och gå ner i den uppackade katalogen (observera att filnamnen kommer vara andra för senare versioner av BISP):
 $ tar xvzf BISP-4.19.1.11663.tar.gz
 $ cd BISP-4.19.1.11663
Kör nu installationsprogramet antingen som root eller via sudo beroende på hur du satt upp din dator:
 $ sudo ./install.4.19.1.11663.sh i
Installationsscriptet kommer fallera på slutet när det försöker installera pluginen till Firefox i en katalog som inte finns i Fedora. Installera i stället pluginen manuellt enligt följande:
 $ sudo cp libplugins.so /usr/lib/mozilla/plugins/.
Det du nu fått installerat är ett antal "libbar" och binärer i /usr/local/lib/personal, två libbar i /usr/local/lib, en plugin i /usr/lib/mozilla/plugins och två script, persadm och personal i /usr/local/bin. Installationsscriptet har även lagt in sökvägen /usr/local/lib i /etc/ld.so.conf och lagt till desktop-filen /usr/share/applications/personal.desktop som gör att programmet personal kan nås från menyn i Gnome och KDE.

Programmet persadm använder man för att lista sina certifikat samt för att exportera och importera dem mellan datorer. personal är själva programmet som hanterar dina certifikat och som är GUI:t som visar dialoger av typen "skriva under" mm.

Installationen är nu klar enligt vad som behövs "officiellt". Nu är det dags att installera det extra som behövs för att BISP skall fungera i Fedora.


Installera BISP, steg två (om du kör 32-bitars Fedora)

Det mesta som behövs för att köra de installerade programmen ovan brukar vara installerat. Det som kan saknas är följande:
  • libpng-compat
  • oxygen-gtk2 (om man kör KDE med Oxygen-temat)
som enkelt installeras såhär:
 $ sudo yum install libpng-compat oxygen-gtk2
Om övriga libbar saknas så finns en mer komplett lista på beroenden i 64-bitarsdelen nedan.


Installera BISP, steg två (om du kör 64-bitars Fedora)

Det du har fått installerat enligt stegen ovan är allt kompilerat för för 32-bitar. Det går alldeles utmärkt att köra 32-bitars program under 64-bitars Linux bara man installerar de 32-bitars paket som behövs.

För persadm behöver man följande paket:
  • glibc.i686
  • zlib.i686
  • libstdc++.i686
  • libidn.i686
  • libgcrypt.i686
och för personal behöver man dessutom:
  • libpng-compat.i686
  • glib2.i686
  • expat.i686
  • atk.i686
  • libX11.i686
  • libSM.i686
  • libXinerama.i686
  • gtk2.i686
  • oxygen-gtk2.i686 (om man kör KDE med Oxygen-temat)
allt det här installerar man snabbt och enkelt genom följande rad:
 $ sudo yum install glibc.i686 zlib.i686 libstdc++.i686 libidn.i686 \
   libgcrypt.i686 libpng-compat.i686 glib2.i686 expat.i686 atk.i686 \
   libX11.i686 libSM.i686 libXinerama.i686 gtk2.i686 oxygen-gtk2.i686
Vissa andra paket kommer också att installeras genom beroenden och det är helt ok. Firefoxpluginen, libplugins.so, har också beroenden till 32-bitars paket men i och med att man installerat det som behövs för persadm och personal ovan så är också libplugins.so nöjd.

För att kunna köra 32-bitars pluginer till Firefox under 64-bitar behöver man vidare paketet nspluginwrapper. Det här paketet erbjuder en 32-bitars miljö till 32-bitars pluginer som man vill använda i 64-bitars Firefox.

Man behöver installera både 32- och 64-bitarsvarianten av nspluginwrapper för att få funktionen att köra 32-bitars pluginer. Installera nspluginwrapper genom att köra följande:
 $ sudo yum install nspluginwrapper.i686 nspluginwrapper.x86_64
Beroende på vad du har installerat på datorn tidigare kan det tänkas att några beroenden också kommer installeras. Detta är helt ok.

BankID är nu klart att användas men det är några saker som man måste vara medveten om för att man inte skall hamna i problem. Allt detta tas upp nedan.


Starta blankt

BankID har lagrat certifikaten på olika stället genom åren. För äldre versioner av BankID så lagrades de i en katalog som hette ~/cbt men nu för tiden så lagras allt som har med BankID att göra under katalogen ~/.personal. Katalogen skapas första gången man startar personal.

Det kan eventuellt finnas problem med att ta med sig certifikat från det gamla sättet att lagra dem till det nya, så för att inte hamna i eventuella problem så blir rekommendationen att börja blankt och ta hem ett nytt BankID från din bank/utfärdare i stället för att försöka importera ett gammalt från andra datorer eller tidigare BankID-installationer.


Använda BISP under Fedora (både 32- och 64-bitars)

Den normala gången när man surfar till en sida som använder sig av BankID är att BankID-pluginen i Firefox aktiveras och kontrollerar om programmet personal är igång eller inte (genom att gissningsvis titta om det finns en unix-socket som heter ~/.personal/.wxsrv424 eller om pid-filen för personal, ~/.personal-<ditt_användarnamn> finns). Om pluginen bedömmer att programmet inte körs så försöker den starta personal.

Det här kommer normalt att fallera under Fedora eftersom SELinux-policyn för Firefox hindrar att allt för mycket kan ske som kan vara potentiellt farligt (som att tex starta godtyckliga program som skapar filer).

Det här kan man dock komma runt ganska enkelt och det är att starta personal först, innan man surfar till någon sida som kräver BankID. Du startar enklast personal genom att söka efter "bankid" i sökdialogen under startmenyn, eller direkt från kommandoraden:
 $ personal
Med personal igång så finns nu både pid-filen och unix-socket:en när libplugins.so laddas och allt fungerar som det skall. Det går att hämta certifikat, logga in på olika platser som kräver BankID och att signera olika saker.

En till sak man skall tänka på med BankID är att när du tex ombeds signera något genom att ange lösenordet till ditt certifikat så anser Firefox att scriptet på websidan "hänger" eftersom det väntar på svar från personal.

Om man väntar för länge kommer alltså Firefox att tycka att scriptet på sidan har hängt och en varningsdialog dyker upp där man får frågan om man vill avbryta exekveringen eller om man vill fortsätta. Normalt borde man bara behöva säga åt Firefox att fortsätta köra scriptet, men av någon anledning så är det så att säga "kört" när det här dialogen kommer upp och många gånger får man helt enkelt starta om Firefox för att kunna fortsätta använda BankID.

Rekommendationen från BankID:s support är att ställa upp den tillåtna tiden för hängande script. Ta upp en tom flik i Firefox och skriv about:config. Leta sedan upp dom.max_script_run_time och sätt den till ett värde > 80 eller hur många sekunder man nu tycker sig behöva för att skriva under saker.


PKCS#11 modulen

Precis som libplugins.so är en plugin som gör att webbsidor kan nå dina certifikat via JavaScript och personal, så är libP11.so som installeras i /usr/local/lib/personal en PKCS#11 plugin som gör att BankID certifikaten dyker upp i Firefox normala certifikathantering.

Installera libP11.so i Firefox genom att att ta upp dialogen för hantering av säkerhetstoken:  Edit -> Preferences -> Advanced -> Encryption -> Security Devices. Välj sedan Load, ange ett valfritt namn på "modulen", tex "BankID PKSC#11", och ange sedan sökvägen till modulen, dvs: /usr/local/lib/personal/libP11.so. Klicka sedan på Ok och stäng dialogen.

Nu kan man klicka på knappen "View Certificates" och sedan välja fliken "Your Certificates" för att se sina BankID certifikat. Det har även dykt upp två CA-cert under fliken "Authorities".

Den här modulen fungerar inte alls i 64-bitars Firefox, inte ens nspluginwrapper erbjuder någon hjälp här.

Men som nämndes i början av inlägget så är det okänt för mig om/när det här används. Vi får se det som kuriosa så länge. Det svenska Ubuntuwikin skriver lite om det här: http://ubuntu-se.org/wiki/NexusPersonal.


Mer SELinux

Det finns för närvarande en bugg i SELinux-policyn som rör nspluginwrapper. Den här buggen gör att man alltid får ett SELinux felmeddelande när man startar Firefox när nspluginwrapper är installerad. Det här är irriterande men nspluginwrapper verkar fungera som den skall.

Buggen är rapporterad här: https://bugzilla.redhat.com/show_bug.cgi?id=865328 och även åtgärdad i nästkommande bugfix för policyn. Uppdateringen lär dyka upp i närtid.

Ovanstående problem är numera åtgärdat.


Referenser


2012-10-28

ClickPad freezes on the NP900X4C with Fedora 17

I have observed temporary freezes of the ClickPad on the Samsung NP900X4C when running Fedora 17.

What happens is that the mouse cursor freezes for several seconds and you are unable to click on the ClickPad. The problem is temporary and after the "freeze period" everything works as normal again. The packages involved in this are:

  • kernel-3.6.2-4.fc17.x86_64
  • xorg-x11-server-Xorg-1.12.3-2.fc17.x86_64
  • xorg-x11-drv-synaptics-1.6.2-2.fc17.x86_64

According to this note on the ArchWiki, the problem seem to be related to CPU frequency scaling. The mouse driver loses sync when the CPU frequency changes.

There is no solution to this issue at the moment, only workarounds. See the ArchWiki for tips of what you can do to mitigate the problem.

2012-10-14

Adobe Flash Player Plugin on Fedora 17 64-bit

Adobe has a yum repository for their 64-bit version of Flash Player Plugin for Firefox. The repository is activated by running (as root or via sudo):
 # rpm -ivh http://linuxdownload.adobe.com/adobe-release/adobe-release-x86_64-1.0-1.noarch.rpm
and then running (as root or via sudo):
 # yum install flash-plugin
Done.

Samsung NP900X4C and Fedora 17

The Samsung NP900X4C is a ultra slim laptop with quite nice specifications. This post is about running Fedora 17 x86_64 on this laptop.

Specifications

Event though the specifications for this laptop is all over the net, here is a short list with the basics:
  • CPU: Intel Core i7 U3517U (1.9GHz dual core, "Ivy Bridge")
  • Chipset: Intel HM75
  • Graphics: Intel HD4000
  • Memory: 8GB RAM (DDR3 PC3-12800 CL11 204-pin SODIMM)
  • Storage: 128GB mSATA SSD disk (or apperently 256GB on some markets)
  • Wireless: Intel Centrino Advanced-N 6235
  • Wired network: Realtek RTL8111/8168B Gigabit Ethernet controller
  • Screen: 15" matte screen with 1600x900 resolution
  • Bluetooth 4.
  • Synaptics ClickPad
The number of connectors on this laptop is quite small due to its slim design, but at least you get the following:
  • Power connector
  • One USB2 port on the left side
  • Two USB3 ports on the right side
  • One MicroHDMI port
  • One "mini" VGA port that requires a special dongle from Samsung to get a normal VGA connector
  • One"mini" network connector that requires a special dongle from Samsung to get a RJ45. This dongle is included with the laptop
  • One 3.5mm combined headphone/microphone port
  • One built in SD-card reader


Upgradeability

The SSD and memory are "easily" upgradable on this laptop. The back cover is attached with ten small screws and with some plastic snap hooks. The screws are easy to remove with some gentle force (they are loctited) if you have a proper screwdriver. If not, you could easily damage them.

After removing the screws, you have to snap the back cover lose from the plastic hooks and this requires some very gentle force to not damage anything.

Once the cover is removed you can see the memory and SSD disk:



You can replace the 2x4GB SODIMM:s with 2x8GB SODIMM:s to get 16GB of RAM and replace the stock 128GB SSD with a 256GB SSD from Crucial to get more storage space. There is an instruction note on the battery that says that the battery should be disconnected before swapping SODIMM:s Just to be sure, I followed this instruction.

The laptop works just fine after the memory and drive upgrade but it could be that your warranty is void. Samsung says that 8GB RAM is maximum. Upgrade on your own risk.


Installation of Fedora 17

I installed Fedora 17 x86_64 fresh on the new 256GB SSD from a USB DVD-reader. I have no interest in Windows so I didn't bother trying to copy the content of the stock disk to the new one.

The laptop was connected to the net via the ethernet dongle so that I could get all the updates directly during the installation (by choosing to add additional repositories during installation). Wireless is not supported in the kernel that comes with the installation DVD, but is supported when all updates are installed. The installation was problem free.

The list below on what works and not assumes that you have a fully updated Fedora 17. Just installing from the install DVD is not enough!


Works, doesn't work and not tested

Here is a list of what works and not on a fully updated Fedora 17:
    • Graphics: Works including desktop effects. glxgears show 60fps
    • Wired network: Works
    • Wireless network: Works
    • USB2: Works
    • USB3: Works
    • Sound: Works
    • MicroHDMI: Works, including sound out through HDMI
    • "mini" VGA: Not tested
    • Webcam: Works
    • ClickPad: Works. Lot of settings in KDE System Settings, two finger scroll, tapping, clicking, three finger tapping, drag and drop etc.
    • Volume mute, down and up via Fn+F6, F7 and F8: Works
    • Controlling screen brightness via Fn+F2 and F3: Works
    • Controlling keyboard backlit: Works (see below)
    • Controlling keyboard backlit from function keys: Does not work (see below)
    • Toggle the ClickPad on/off with Fn+F5: Works
    • Suspend: Works although not extensively tested
    • Bluetooth: Works to play sound on Bluetooth speakers
    • SD-card reader: Works
    • Turn radio on/off (WLAN and Bluetooth): Works (see below)
    • Turn radio on/off from function keys: Does not work (see below)
    • Change performance levels: Works (see below)
    • Change performance levels via function key: Does not work (see below)
    • Enable/disable battery life extender: Works (see below)
    • Enable/disable USB-charge: Works (see below)


      Keyboard backlit

      The story with keyboard backlit is the following. The kernel support for controlling the keyboard backlit is there and you can control the backlit by doing the following in a terminal window (as root):
       # echo N > /sys/devices/platform/samsung/leds/samsung\:\:kbd_backlight/brightness
      where N should be replaced by a number between 0 (off) and 8 (full brightness).

      What is missing is some program that listens on the Fn+F9 and Fn+F10 keys and decreases or increases the brightness by writing to the above device node. Not sure whether such a program should be in KDE/Gnome or live somewhere under the hood.


      Turn radio on/off

      It is possible to turn the radios for WLAN and Bluetooth on and off from within the OS. This is done by writing to specific device nodes under /sys (like in the case for keyboard backlit).

      To switch the WLAN radio off, do the following (as root or via sudo):
       # echo 0 > /sys/devices/platform/samsung/rfkill/rfkill1/state
      To switch the WLAN on again, just write 1 instead of 0:
       # echo 1 > /sys/devices/platform/samsung/rfkill/rfkill1/state
      And, as you would guess, checking the state of the WLAN radio is done by:
       # cat /sys/devices/platform/samsung/rfkill/rfkill1/state
      The Bluetooth radio is controlled via rfkill2 so you just replace rfkill1 with rfkill2 in the commands above to do the same thing for Bluetooth.

      If you turn off both WLAN and Bluetooth, the blue LED on the F12 key will turn off to indicate that your laptop is in "flight mode".

      As with the keyboard backlit, there is no program that listens on the Fn+F12 key event and writes to the device nodes above. So, when you press Fn+F12 nothing will happen.


      Performance levels

      The NP900X4C has three "performance" levels, "silent", "normal" and "overclock" (or "speed"). As far as I understand they basically control the CPU frequency.

      To check the current performance level, just look at the value in the performance_level device node:
       # cat /sys/devices/platform/samsung/performance_level
      To change the performance level, echo the desired level to the device node:
       # echo LEVEL > /sys/devices/platform/samsung/performance_level
      where LEVEL is replaced by one of silent, normal or overclock.

      As with keyboard backlit and radio on/off, pressing the performance key (Fn+F11) key doesn't do anything.


      Battery life extender

      Battery life extender is a function that can be activated in BIOS or from within the OS. It extends the lifetime of the battery by only charge it to 80% instead of 100%.

      To check if the battery life extender function is activated, look at the value in the battery_life_extender device node:
       # cat /sys/devices/platform/samsung/battery_life_extender
      0 means that the function is deactivated and 1 means activated.

      To activate/deactivate, just write the appropriate value to the device node:
       # echo STATE > /sys/devices/platform/samsung/battery_life_extender
      where STATE is 0 for deactivate or 1 to activate.


      USB charge

      USB charge is a function that can be activated from BIOS or from within the OS. When activated, it allows you to charge your cellphone or other stuff from the USB2-port even when the laptop is switched off.

      To check if the USB charge function is activated, look at the value in the usb_charge device node:
       # cat /sys/devices/platform/samsung/usb_charge
      0 means that the function is deactivated and 1 means activated.

      To activate/deactivate, just write the appropriate value to the device node:
       # echo STATE > /sys/devices/platform/samsung/usb_charge
      where STATE is 0 for deactivate or 1 to activate.

      Some documentation about performance level, battery life extender and USB charge can be fond here.


      Function keys

      Some of the function keys does not have any mappings meaning that even if you press them, Linux will not recognise that. The function keys in question are:
      • Fn+F1 "Settings"
      • Fn+F9 "Keyboard backlit dim"
      • Fn+F10 "Keyboard backlit light up"
      • Fn+F11 "Fan controll"
      • Fn+F12 "Radio kill switch"
      You can verify that nothing is happening by starting xev from the command prompt, move the mouse pointer to be within the black square in the window that pops up and then press different keys. You will see output in the terminal when you press "known" keys, but if you press any of the Fn-keys above nothing will happen.

      To make Linux recognise these buttons you need to create two files and add two lines in two other files.

      To begin with, create the file /lib/udev/keymaps/samsung-900x4c with the following content:
       0x96 kbdillumup         # FN+F10 Keyboard backlight up
       0x97 kbdillumdown       # FN+F9 Keyboard backlight down
       0xB3 silentmode         # FN+F11 Silentmode
       0xCE prog1              # FN+F1 System Settings
       0xD5 wlan               # FN+F12 WiFi

      Second, create the file /lib/udev/keymaps/force-release/samsung-900x4c with the following content:
       0x96 # FN+F10 Keyboard backlight up
       0x97 # FN+F9 Keyboard backlight down
       0xB3 # FN+F11 Silentmode
       0xCE # FN+F1 System Settings
       0xD5 # FN+F12 WiFi

      Third, add the following line to the file /lib/udev/rules.d/95-keymap.rules:
        ENV{DMI_VENDOR}=="[sS][aA][mM][sS][uU][nN][gG]*", ATTR{[dmi/id]product_name}=="900X3C*", RUN+="keymap $name samsung-900x4c"
      The line should be added at the bottom of the block of lines that begin with:
       ENV{DMI_VENDOR}=="[sS][aA][mM][sS][uU][nN][gG]*"

      Fourth, add the following line to the file /lib/udev/rules.d/95-keyboard-force-release.rules:
        ENV{DMI_VENDOR}=="[sS][aA][mM][sS][uU][nN][gG]*", ATTR{[dmi/id]product_name}=="900X3C*", RUN+="keyboard-force-release.sh $devpath samsung-900x4c"
      The line should be added below the block of lines that begin with:
       ENV{DMI_VENDOR}=="[sS][aA][mM][sS][uU][nN][gG]*"

      The steps above will tell Linux to load the two mapping files if the value of the device node /sys/devices/virtual/dmi/id/product_name matches the regexp "900X3C*". Even though this is a 900X4C, the product_name node contains the string "900X3C/900X4C/900X4D" indicating that all these three laptops are about the same when it comes to Linux support.

      You have to reboot for the new configuration to take effect. Once up and running again, start xev on the command line and observe that things now happen when any of these five function keys are pressed. But, since there still are no program listening on these events and poking on all of the device nodes discussed above, you will not be able to use the function keys until you write some software/scripts that handles that.

      Also, any updates to the udev-system will probably overwrite your changes to /lib/udev/rules.d/95-keymap.rules and /lib/udev/rules.d/95-keyboard-force-release.rules.


      Conclusion

      The Samsung NP900X4C is a really nice laptop to running Linux on. It performs very well for doing "internet stuff", writing and development jobs. The hardware support "out of the box" is very good for such a new laptop.

      The laptop stays very cool during normal use and the fan hardly have to work. This will of course change if you do heavy compilations and stuff but that is expected.

      The finish is also top notch and the laptop looks really sleek and is easy to carry with you. The combination of 15" screen and 1600x900 resolution is also a very good match and looking at the screen feels "natural". Viewing angle is unfortunately a bit narrow but considering everything else, I think it is acceptable. 

      The battery seem to last for at least four-five hours when just surfing/writing with the screen on all the time.

      Do I need to add that I'm quite satisfied with this laptop :-)

      PrettyPrint