Ervaringen met openSUSE 13.1
Op mijn laptop, die ik als test- en reserve computer gebruik, heb ik al sedert het verschijnen van openSUSE 13.1 de laatste openSUSE distributie in gebruik. Tijdens de kerstvakantie heb ik de computer waarop ik werk en het backupsysteem naar openSUSE 13.1 overgezet. Zoals we gewoon zijn van openSUSE verliepen de installaties zonder problemen. Toch ondervond ik hier en daar wat probleempjes en het goede nieuws is dat deze bijna allemaal met updates zijn opgelost. Ook de mij opgevallen verschillen (lees verbeteringen) met openSUSE 12.3 komen aan bod.
Steam en games
Na de klassieke installatie heb ik de drivers voor de NVIDIA grafisch kaart van mijn computer geïnstalleerd. Deze van NVIDIA zelf afkomstige drivers werken namelijk efficiënter dan de open source drivers en zeker bij games. Na de installatie en het opstarten van STEAM verscheen een melding dat games wegens fouten in het grafisch systeem niet op volle snelheid zouden draaien. Daar heb ik niets van ondervonden. Wel had ik geen geluid (ook bij openSUSE 12.3 was dit het geval), de oplossing bestaat uit het installeren van een 32 bits geluidsbibliotheek en de systeem identificatiecode in twee locaties op elkaar af te stemmen:
sudo zypper install alsa-plugins-pulse-32bit
sudo mv /var/lib/dbus/machine-id /var/lib/dbus/machine-id.ori
sudo ln -s /etc/machine-id /var/lib/dbus/machine-idToch bleek één van mijn favoriete spellen (Anomaly 2) bij sommige reproduceerbare spelfases te crashen.
Bij het afsluiten bleef Anomaly 2 als een onafgesloten programma in het geheugen actief, waardoor de gamedata niet met de servers van STEAM gesynchroniseerd werden.
Daardoor kon je STEAM enkel geforceerd afsluiten, STEAM had de indruk dat je nog aan het spelen was.
Gelukkig kwamen in de kerstvakantie nieuwe updates binnen voor zowel het grafische systeem en STEAM.
Alles werk nu precies zoals het hoort.
Soms moet je Anomaly 2 nog zelf afsluiten (met de opdracht killall Anomaly2Linux).
Ondertussen heb ik via STEAM een spel aangekocht (is me in openSUSE 12.3 nooit gelukt) en heb ik geprofiteerd van het STEAM kerstgeschenk Left 4 Dead 2.
Hoe irriterend zulke fouten ook zijn, waarschijnlijk zijn ze moeilijk te vermijden.
Je kunt als ontwikkelaar namelijk niet alles voorzien.
Vraag het maar eens aan Windows gamers bij het verschijnen van een nieuwe Windows versie en/of het spelen van een pas verschenen spel.
Ook zij lopen tegen verschillende vervelende bugs.
Starten via het Bureaublad
Velen gebruiken Commando uitvoeren om programma's te starten, documenten te zoeken, enz. Bij openSUSE 12.3 moest je daarvoor eerst de sneltoets Alt+F2 drukken (werkt nog steeds). Bij openSUSE 13.1 (KDE 4.11) kan je Commando uitvoeren activeren door gewoon te typen op het Bureaublad. Dit werkt een stuk sneller (Windows 8.1, kijk hoe KDE het gebruiksvriendelijk zoeken en opstarten van om het even wat heeft opgelost).
Mediaspeler VLC
Het afspelen van video en muziek blijft voor problemen zorgen in open source middens. Vandaar dat de meeste distributies (waaronder openSUSE 13.1) zeer voorzichtig omspringen met patenten en copyright's. Door deze voorzichtige aanpak kan je standaard geen veel gebruikte video- en muziekformaten afspelen. Gelukkig lost de installatie van VLC deze problemen op:
sudo zypper ar http://download.videolan.org/pub/vlc/SuSE/13.1 VLC
sudo zypper mr -r VLC
sudo zypper in vlcNa de installatie van VLC blijkt nog steeds de openSUSE 13.1 afspeelbibliotheek gebruikt te worden. Om de VLC afspeelbibliotheek te installeren voer je volgende extra opdracht uit (wordt ook aanbevolen bij een update opdracht):
dany@linux-att3:~>sudo zypper updateGegevens van installatiebron laden... Lezen van geïnstalleerde pakketten... De volgende pakketten zijn gesuggereerd, maar zullen niet worden geïnstalleerd: libavutil52 libvlc5 libvlccore7 Niets te doen. dany@linux-att3:~>sudo zypper install VLC:libavutil52Gegevens van installatiebron laden... Lezen van geïnstalleerde pakketten... Afhankelijkheden tussen pakketten oplossen... Het volgende pakket zal worden opgewaardeerd: libavutil52 Het volgende pakket zal de leverancier wijzigen: libavutil52 openSUSE -> VideoLAN Project (http://www.videolan.org) 1 op te waarderen pakket, 1 te wijzigen van leverancier. Totale downloadgrootte: 107,5 KiB Na de operatie zal 42,4 KiB worden vrijgemaakt. Doorgaan? [j/n/? alle opties tonen] (j): pakket libavutil52-2.1.1-2.1.x86_64 wordt opgehaald (1/1), 107,5 KiB (262,9 KiB uitgepakt) Ophalen: libavutil52-2.1.1-2.1.x86_64.rpm ...............................[klaar] (1/1) Installeert: libavutil52-2.1.1-2.1 ................................[klaar] Er zijn actieve programma's die bestanden gebruiken die recent zijn opgewaardeerd. U zou enige van deze mogelijk willen herstarten. Draai 'zypper ps' om een lijst te verkrijgen van deze programma's.
Thunderbird en Lightning kalender
Om mijn e-mail's en nieuwsberichten te beheren, gebruik ik Thunderbird.
Dit van Mozilla afkomstige programma kan je uitbreiden met add-on's waardoor je functionaliteit kunt toevoegen.
Om mijn agenda in Thunderbird op te nemen, gebruik ik de add-on Lightning.
Tot mijn grote verbazing vond ik bij het zoeken naar de Thunderbird Lightning add-on niets.
Na wat speurwerk vond ik dat enkel de recentste versie van Lightning als add-on beschikbaar wordt gesteld.
En deze werkt enkel met Thunderbird versie 24.1.1 en hoger.
Ik heb dus een oudere versie van Lightning moeten zoeken, downloaden en installeren.
De volgende dag reeds zat bij de openSUSE updates de laatste Thunderbird versie.
M.a.w. had ik een dag gewacht, dan had de update het probleem automatisch oplost.
Nu de Lightning kalender werkt, weet ik weer wanneer ik moet gaan werken.
Einde Linux ondersteuning Acrobat Reader
De ontwikkeling van Acrobat Reader voor Linux lag al een tijd stil (recenste versie 9.4.7 van 16 januari 2012).
Maar nu besliste Adobe niet verder veiligheidsupdates voor Linux te leveren.
En dit was voor openSUSE een brug te ver.
De standaard softwarebronnen van openSUSE bevatten geen Acrobat Reader meer.
Er zijn echter genoeg alternatieven.
Het standaard met KDE meegeleverde Okular kan als vervanger dienst doen.
De enige Acrobat Reader functie die ik mis is het opzoeken van een PDF document aan de hand van een zoekwoord. Acrobat Reader was bij mijn weten de enige PDF lezer die dit kon. Het volgende script lost dit echter op:
#! /bin/bash
#
# findPDF.sh Version 13.11
# 2013 Dany Pinoy <pindanet.be>
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
#
# Selecteer de te doorzoeken map
map=`kdialog --getexistingdirectory ~ --title "Selecteer een te doorzoeken map"`
# Voer de zoektekst in
zoek=`kdialog --inputbox "Zoek in $map in PDF bestanden naar:"`
# find zoekt naar PDF bestanden in de opgegeven map
# pdftotext zet te gevonden PDF bestanden om naar tekst
# de tekst wordt op het zoekwoord doorzocht met grep
uitvoer=$(find "${map}" -name '*.pdf' -exec sh -c "pdftotext \"{}\" - | grep -i --with-filename --label=\"{}\" \"${zoek}\"" \;)
kdialog --msgbox "${uitvoer}"Dit wordt het resultaat:
Na het zoeken (kan wat duren), verschijnt een venster met de resultaten:
Samba gedeelde mappen
OpenSUSE 13.1 gebruikt de gloednieuwe Samba versie 4. In de vakliteratuur niets dan lovende woorden. Maar in openSUSE bleek deze niet in staat te zijn een eenvoudige map te delen. De Samba server bleek niet eens op te willen starten:
dany@linux-bnqi:~>sudo systemctl start smbroot's password: Job for smb.service failed. See 'systemctl status smb.service' and 'journalctl -xn' for details. dany@linux-bnqi:~>sudo systemctl status -l smbsmb.service - Samba SMB Daemon Loaded: loaded (/usr/lib/systemd/system/smb.service; enabled) Active: failed (Result: resources) since vr 2013-12-27 20:22:10 CET; 35s ago Process: 1748 ExecStart=/usr/sbin/smbd $SMBDOPTIONS (code=exited, status=0/SUCCESS) dec 27 20:22:10 linux-bnqi.site systemd[1]: Starting Samba SMB Daemon... dec 27 20:22:10 linux-bnqi.site smbd[1748]: [2013/12/27 20:22:10.455050, 0] ../source3/smbd/server.c:1278(main) dec 27 20:22:10 linux-bnqi.site smbd[1749]: [2013/12/27 20:22:10.455983, 0] ../lib/util/pidfile.c:117(pidfile_create) dec 27 20:22:10 linux-bnqi.site smbd[1749]: ERROR: can't open /var/run/samba/smbd.pid: Error was No such file or directory dec 27 20:22:10 linux-bnqi.site systemd[1]: PID file /run/samba/smbd.pid not readable (yet?) after start. dec 27 20:22:10 linux-bnqi.site systemd[1]: smb.service never wrote its PID file. Failing. dec 27 20:22:10 linux-bnqi.site systemd[1]: Failed to start Samba SMB Daemon. dec 27 20:22:10 linux-bnqi.site systemd[1]: Unit smb.service entered failed state.
De oorzaak is een te strenge AppArmor beveiliging die smb de toegang tot bepaalde mappen blokkeert. Daar we geprobeerd hebben de smb daemon te starten, staan de AppArmor tussenkomsten in het logboek. Met behulp van de volgende opdracht, passen we aan de hand van de logboek meldingen de AppArmor regels aan:
dany@linux-bnqi:~>sudo /usr/sbin/logprofroot's password: Reading log entries from /var/log/messages. Updating AppArmor profiles in /etc/apparmor.d. Enforce-mode changes: Profile: /usr/sbin/smbd Path: /var/run/samba/ Mode: w Severity: unknown [1 - /var/run/samba/] (A)llow / [(D)eny] / (G)lob / Glob w/(E)xt / (N)ew / Abo(r)t / (F)inish / (O)pts Adding /var/run/samba/ w to profile. = Changed Local Profiles = The following local profiles were changed. Would you like to save them? [1 - /usr/sbin/smbd] (S)ave Changes / [(V)iew Changes] / Abo(r)t Writing updated profile for /usr/sbin/smbd. dany@linux-bnqi:~>sudo systemctl start smbroot's password: dany@linux-bnqi:~>sudo systemctl status -l smbsmb.service - Samba SMB Daemon Loaded: loaded (/usr/lib/systemd/system/smb.service; enabled) Active: active (running) since vr 2013-12-27 20:40:10 CET; 2min 25s ago Process: 1790 ExecStart=/usr/sbin/smbd $SMBDOPTIONS (code=exited, status=0/SUCCESS) Main PID: 1791 (smbd) CGroup: /system.slice/smb.service ├─1791 /usr/sbin/smbd ├─1792 /usr/sbin/smbd └─1795 /usr/sbin/smbd dec 27 20:40:10 linux-bnqi.site smbd[1790]: [2013/12/27 20:40:10.884395, 0] ../source3/smbd/server.c:1278(main) dec 27 20:40:10 linux-bnqi.site systemd[1]: Started Samba SMB Daemon.
Daarbij moeten we de voorgestelde regel goedkeuren door a te drukken (Allow).
En daarna de aanpassing op te slaan door s te drukken (Save).
Na een nieuwe poging om de smb daemon te starten, merken we dat deze werkt.
Maar bij het gebruik van een gedeelde map, bleek deze niet te willen openen.
Ook daarvoor moet AppArmor de toelating aan de smb daemon geven.
Dit kan als volgt: Start in YaST in de categorie Beveiliging en gebruikers de module AppArmor-configuratie.
Start de module Bestaande profielen beheren.
Selecteer het profiel /usr/sbin/smbd en klik op de knop Bewerken.
Voor elke gedeelde map voeg je twee nieuwe items van het type map toe.
Eén om toegang te krijgen tot de map zelf (zonder ** op het einde) en één om toegang te krijgen tot alle onderliggende mappen en bestanden (** na de mapnaam).
In het voorbeeld (afbeelding) dus voor de map /usr/home/Documents/ en alle onderliggende items (/usr/home/Documents).
Telkens activeer je de gewenste Permisssies.
Indien correct geconfigureerd is deze manier van beveiliging zeer efficiënt.
AppArmor zorgt er zo voor dat zelfs indien iemand erin slaagt de smb daemon over te nemen, AppArmor zorgt dat de aanval binnen de krijtlijnen van de AppArmor beveiliging blijft.
Waardoor het grootste gedeelte van het systeem voor de aanvaller onbereikbaar blijft.
SELinux werkt op een gelijkaardige manier.
Virtuele computers in het OVF formaat in VMware Player importeren
Bij de laatste versie van de VMware Player (versie 6.0.1) blijkt het niet meer mogelijk om virtuele computers in het OVF formaat te importeren. Dit heeft natuurlijk niets te maken met openSUSE 13.1, maar alles met een bug in de VMware software. Met de volgende opdracht lukt het wel om een virtuele computer in het OVF formaat om te zetten naar een VMware virtuele computer:
dany@linux-att3:~> ovftool Downloads/Webserver/Webserver.ovf vmware/Webserver/Webserver.vmx
Opening OVF source: Downloads/Webserver/Webserver.ovf
The manifest validates
Opening VMX target: vmware/Webserver/Webserver.vmx
Writing VMX file: vmware/Webserver/Webserver/Webserver.vmx
Transfer Completed
Completed successfully