Category: Fedora

Fedora related posts

Complex setup with Nvidia Optimus / Nouveau Prime on Fedora 19

slaanesh 22 Comments

First of all I would like to say some thanks to the X.org community. Their work is awesome, and the fact I can make my setup work on entirely X.org components it’s something I never thought possible when XFree86 was still around. I personally think that looking at an Optimus laptop with Intel and Nouveau running is a tremendous achievement.

optimus_technology_badgeNow, back to the topic.

My laptop at work is a Dell Latitude E6430. Comes loaded with features and I really like it. Among the various features there’s the fact that this is an Nvidia Optimus enabled laptop, sporting both an Intel video card and an Nvidia one:

$ lspci | grep -i vga
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09)
01:00.0 VGA compatible controller: NVIDIA Corporation GF108GLM [NVS 5200M] (rev a1)

This one is a muxless laptop of the worst kind: video outputs are connected only to specific chips!

LVDS (Internal panel)Intel
VGA (not usable along with the docking station one)Intel
VGA (Docking station)Intel
DVINvidia
DVI (Docking station)Nvidia
DisplayPort (Docking station)Nvidia
HDMINvidia

So to use an external HDMI connection at home you need to drive it through the Nvidia card, it doesn’t matter if Optimus is enabled or not. I regularly use it docked with the lid closed, external keyboard and mouse and 2 external monitors connected to the VGA and DVI outputs of the docking station. Basically while I’m at the office it looks like a normal desktop computer; but sometime I need to disconnect it to go on a meeting; and sometimes I use it at home to play games as well.

Guess what? Free drivers, proprietary drivers, UEFI, UEFI secure boot, multi monitor, outputs changing on the fly… all sorts of fun! I’m impressed by the fact that it all works together.

There are four modes on which I can operate the system:

  • Optimus enabled, free drivers for both Intel and Nvidia cards
  • Optimus enabled, free driver for Intel and proprietary driver for the Nvidia card
  • Optimus disabled, free driver for the Nvidia card
  • Optimus disabled, proprietary driver for the Nvidia card

Each one has its drawbacks, so let’s explain each setup a bit. At the end of the post I’ve made a table with all the pros and cons of each solution.

My current setup is:

  • Fedora 19 x86_64
  • Kernel 3.11.1 (stock Fedora)
  • Nouveau DDX 1.0.9 (stock Fedora)
  • Intel DDX 2.21.12 (stock Fedora)
  • Nvidia proprietary drivers 325.15 (from my repository)
  • VDPAU library 0.7 (stock Fedora)
  • Mesa libraries 9.2 (20130919 prerelease, stock Fedora)

UEFI / legacy bios

If secure boot is enabled; there’s no way to use the proprietary Nvidia driver without fiddling with UEFI keys. The module is built separately from the kernel package; so there’s no way for it to have the same signature as the kernel.

When UEFI is enabled, the free drivers work fine and replace the efifb framebuffer driver with their own; thus giving proper modesetting at the correct resolution and a speedy and responsive terminal.

With the proprietary Nvidia driver, the efifb is not replaced; so the console still operates with it and the Nvidia driver only operates the X part. Unfortunately, using this method, the framebuffer console is slow as hell, the resolution is not optimal, and the EFI framebuffer is never exposed onto external monitors. In my case, pressing CTRL+ALT+Fx jumps me to the console that is shown in the closed laptop lid on the docking station; making it pretty useless.

So if you’re going to use the proprietary driver and you often use the console; make sure you’re using Bios mode and not UEFI. What UEFI could bring you is the Intel Rapid Start Technology which has been included in kernel 3.11; so make your choices depending on what you need.

Optimus disabled

When Optimus is disabled, I can freely use the proprietary Nvidia driver or the free Nouveau driver.

Both solution work; unfortunately performance and feature wise Nouveau cannot compete with the proprietary Nvidia driver.

My main issue is power management; with the Nvidia driver the battery lasts a lot more and the performance difference is abysmal. Nouveau performance is really poor with 3D games (especially Steam commercial ones, with Doom 3 it works fine) and there’s absolutely no power management; at least on my laptop. By playing with performance levels I was only able to overheat the card!

Another thing that does not work with Nouveau is the docking station removal. With the Nvidia proprietary driver I’m able to do the following:

– Disconnect from the docking station: output goes from the external VGA and DVI monitors to the internal LVDS display.

– Reconnect to the docking station: internal LVDS display gets shut off and output goes to VGA and DVI monitors as they were before; one next to the other. I can even close the lid and the computer doesn’t go in standby.

With Nouveau, I’m able to disconnect from the docking station but when reconnecting I need to reconfigure the monitors in their place; and after this, when closing the lid I need to wake up again the computer because it goes on standby.

With the recent Xrandr support to the proprietary drivers I don’t even need to edit che X.org configuration file. Whether I use nvidia-settings or Gnome Displays panel the result is reflected in both implementations and preserved across boots.

Optimus with proprietary Nvidia drivers

To configure Optimus with proprietary drivers perform the following. First of all install the proprietary driver as normal. Now edit the /etc/grub2.cfg file and remove some parameters from the kernel command line. This is required because the Intel driver still need to operate with its KMS driver. So, from this:

nouveau.modeset=0 rd.driver.blacklist=nouveau nomodeset gfxpayload=vga=normal

you should go to this:

nouveau.modeset=0 rd.driver.blacklist=nouveau

After this, edit/recreate the /etc/X11/xorg.conf file with the following contents:

Section "ServerLayout"
    Identifier "layout"
    Screen 0 "nvidia"
    Inactive "intel"
EndSection

Section "Device"
    Identifier "intel"
    Driver "intel"
EndSection

Section "Screen"
    Identifier "intel"
    Device "intel"
EndSection

Section "Device"
    Option "ConstrainCursor" "no"
    Identifier "nvidia"
    Driver "nvidia"
    BusID "PCI:1:0:0"
EndSection

Section "Screen"
    Identifier "nvidia"
    Device "nvidia"
    #Option "UseDisplayDevice" "none"
EndSection

Make sure to set the correct bus ID for the Nvidia card; for instructions look in the Nvidia documentation. Contrary to what’s written in the Nvidia documentation I had to use the intel DDX driver for the Intel card instead of the modesetting one. With modesetting I’m not able to get any output on the Intel card.

Upon reboot, you will see KMS running for the Intel card (Plymouth screen) and then the login manager appears on the Nvidia attached panels, while the Intel outputs shut off.

After logging in, you can also check that both drivers are running with the following commands:

$ lsmod | egrep "i915|nvidia"
nvidia               9365874  51 
i915                  651861  2 
i2c_algo_bit           13257  1 i915
drm_kms_helper         50239  1 i915
drm                   274480  5 i915,drm_kms_helper,nvidia
i2c_core               34242  7 drm,i915,i2c_i801,drm_kms_helper,i2c_algo_bit,nvidia,videodev
video                  19104  1 i915
$ dmesg | egrep -i "i915|nvidia"
[    4.589447] nvidia: module license 'NVIDIA' taints kernel.
[    4.595759] nvidia: module verification failed: signature and/or required key missing - tainting kernel
[    4.601728] nvidia 0000:01:00.0: enabling device (0004 -> 0007)
[    4.613153] [drm] Initialized nvidia-drm 0.0.0 20130102 for 0000:01:00.0 on minor 0
[    4.613159] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  325.15  Wed Jul 31 18:50:56 PDT 2013
[    4.738199] i915 0000:00:02.0: setting latency timer to 64
[    4.768878] i915 0000:00:02.0: irq 48 for MSI/MSI-X
[    5.088964] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
[    5.088966] i915 0000:00:02.0: registered panic notifier
[    5.088982] i915: No ACPI video bus found
[    5.420554] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 1
[    5.966583] nvidia 0000:01:00.0: irq 50 for MSI/MSI-X
[  198.017862] nvidia 0000:01:00.0: irq 50 for MSI/MSI-X

To light up the other display some xrandr command is required (to enable these at boot add them in /etc/X11/xinit/xinitrc.d):

$ xrandr --setprovideroutputsource Intel NVIDIA-0
$ xrandr --auto
$ xrandr --output VGA1 --left-of DP-1

Your Intel monitor should now have an extended desktop managed by the Nvidia card. Move windows around, and launch some commands to see that wherever you go you’re using the Nvidia accelerated driver:

$ glxinfo| grep "OpenGL version string"
OpenGL version string: 4.3.0 NVIDIA 325.15
$ vdpauinfo | grep -i string
Information string: NVIDIA VDPAU Driver Shared Library  325.15  Wed Jul 31 18:14:57 PDT 2013

Everything seems to work, except output manipulation. Xrandr, Gnome and Nvidia drivers have a different view.

Xrandr view:

$ xrandr -q | grep conn
VGA-0 connected primary 1680x1050+0+0 (normal left inverted right x axis y axis) 474mm x 296mm
LVDS-0 connected (normal left inverted right x axis y axis)
DP-0 disconnected (normal left inverted right x axis y axis)
DP-1 connected 1680x1050+1680+0 (normal left inverted right x axis y axis) 474mm x 296mm
HDMI-0 disconnected (normal left inverted right x axis y axis)
DP-2 disconnected (normal left inverted right x axis y axis)
DP-3 disconnected (normal left inverted right x axis y axis)

This is what I have in the Nvidia settings panel and in the Gnome Displays panel for the monitors; in one case I don’t see any monitor, in another one I have the internal LVDS display shown as enabled while in reality is not and with the button locked in the “On” position:

gnome-optimus

Primary monitor assignment does not work as well. I usally have the Gnome panel on the left monitor. If I try to move it from the Nvidia output I get this feedback:

$ xrandr --output VGA1 --primary
X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  139 (RANDR)
  Minor opcode of failed request:  30 (RRSetOutputPrimary)
  Serial number of failed request:  53
  Current serial number in output stream:  55

Putting monitor problems aside, running in this mode does not really give any benefit compared to running it with Optimus disabled and the proprietary Nvidia driver installed. Both cards are running with power management, but the Nvidia card is never shut off, so it doesn’t use less power than when running standalone.

There’s no way to turn off the card with vga_switcheroo, all 3d libraries come from the Nvidia drivers and your desktop is being rendered by the Nvidia card.

Prime (Optimus) with free Nouveau drivers

Here comes the juicy part. With enough maturity on the Nouveau side this would be the perfect setup. To start with this implementation; nothing is required, just install Fedora and everything should be already set up. Booting it shows the Plymouth logo on both outputs.

Login in the system, and check that both drivers are running:

$ lsmod | egrep "i915|nouveau"
nouveau               943445  1 
i915                  651861  4 
mxm_wmi                12865  1 nouveau
ttm                    79865  1 nouveau
i2c_algo_bit           13257  2 i915,nouveau
drm_kms_helper         50239  2 i915,nouveau
drm                   274480  8 ttm,i915,drm_kms_helper,nouveau
i2c_core               34242  7 drm,i915,i2c_i801,drm_kms_helper,i2c_algo_bit,nouveau,videodev
wmi                    18697  3 dell_wmi,mxm_wmi,nouveau
video                  19104  2 i915,nouveau
$ dmesg | egrep "i915|nouveau"
[    3.155259] i915 0000:00:02.0: setting latency timer to 64
[    3.163318] nouveau 0000:01:00.0: enabling device (0004 -> 0007)
[    3.185671] i915 0000:00:02.0: irq 45 for MSI/MSI-X
[    3.517135] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
[    3.517136] i915 0000:00:02.0: registered panic notifier
[    3.517156] i915: No ACPI video bus found
[    3.774151] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
[    3.774654] nouveau  [  DEVICE][0000:01:00.0] BOOT0  : 0x0c1e00a1
[    3.774659] nouveau  [  DEVICE][0000:01:00.0] Chipset: GF108 (NVC1)
[    3.774663] nouveau  [  DEVICE][0000:01:00.0] Family : NVC0
[    3.778240] nouveau  [   VBIOS][0000:01:00.0] checking PRAMIN for image...
[    3.787999] nouveau  [   VBIOS][0000:01:00.0] ... signature not found
[    3.788002] nouveau  [   VBIOS][0000:01:00.0] checking PROM for image...
[    3.788086] nouveau  [   VBIOS][0000:01:00.0] ... signature not found
[    3.788087] nouveau  [   VBIOS][0000:01:00.0] checking ACPI for image...
[    4.624674] nouveau  [   VBIOS][0000:01:00.0] ... appears to be valid
[    4.624679] nouveau  [   VBIOS][0000:01:00.0] using image from ACPI
[    4.624845] nouveau  [   VBIOS][0000:01:00.0] BIT signature found
[    4.624850] nouveau  [   VBIOS][0000:01:00.0] version 70.08.a8.00.8d
[    4.625140] nouveau  [ DEVINIT][0000:01:00.0] adaptor not initialised
[    4.625144] nouveau  [   VBIOS][0000:01:00.0] running init tables
[    4.753512] nouveau  [     PFB][0000:01:00.0] RAM type: GDDR5
[    4.753514] nouveau  [     PFB][0000:01:00.0] RAM size: 1024 MiB
[    4.753515] nouveau  [     PFB][0000:01:00.0]    ZCOMP: 0 tags
[    4.779859] nouveau  [  PTHERM][0000:01:00.0] FAN control: none / external
[    4.779863] nouveau  [  PTHERM][0000:01:00.0] fan management: disabled
[    4.779867] nouveau  [  PTHERM][0000:01:00.0] internal sensor: yes
[    4.783179] nouveau  [     DRM] VRAM: 1024 MiB
[    4.783180] nouveau  [     DRM] GART: 1048576 MiB
[    4.783184] nouveau  [     DRM] TMDS table version 2.0
[    4.783185] nouveau  [     DRM] DCB version 4.0
[    4.783199] nouveau  [     DRM] DCB outp 00: 01000323 00010034
[    4.783201] nouveau  [     DRM] DCB outp 01: 020323a6 0f220010
[    4.783202] nouveau  [     DRM] DCB outp 02: 040433b6 0f220010
[    4.783203] nouveau  [     DRM] DCB outp 03: 08024382 00020010
[    4.783204] nouveau  [     DRM] DCB outp 04: 02032362 00020010
[    4.783205] nouveau  [     DRM] DCB outp 05: 04043372 00020010
[    4.783206] nouveau  [     DRM] DCB outp 06: 02011300 00000000
[    4.783207] nouveau  [     DRM] DCB conn 00: 00000041
[    4.783209] nouveau  [     DRM] DCB conn 01: 00000100
[    4.783210] nouveau  [     DRM] DCB conn 02: 00001246
[    4.783211] nouveau  [     DRM] DCB conn 03: 00002346
[    4.783212] nouveau  [     DRM] DCB conn 04: 00010461
[    4.783213] nouveau  [     DRM] DCB conn 05: 00000500
[    4.783878] nouveau  [     DRM] ACPI backlight interface available, not registering our own
[    4.784072] nouveau  [     DRM] 3 available performance level(s)
[    4.784075] nouveau  [     DRM] 0: core 50MHz shader 101MHz memory 135MHz voltage 830mV
[    4.784076] nouveau  [     DRM] 1: core 202MHz shader 405MHz memory 324MHz voltage 830mV
[    4.784078] nouveau  [     DRM] 3: core 672MHz shader 1344MHz memory 1569MHz voltage 980mV
[    4.784079] nouveau  [     DRM] c: core 202MHz shader 405MHz memory 324MHz
[    4.789392] nouveau  [     DRM] MM: using COPY0 for buffer copies
[    4.925967] nouveau  [     DRM] allocated 1680x1050 fb: 0x60000, bo ffff88021fc21400
[    4.926065] nouveau 0000:01:00.0: fb1: nouveaufb frame buffer device
[    4.926068] [drm] Initialized nouveau 1.1.1 20120801 for 0000:01:00.0 on minor 1

Poking around with xrandr will give you totally different outputs from the Nvidia driver:

$ xrandr -q | grep conn
LVDS1 connected (normal left inverted right x axis y axis)
VGA1 connected primary 1680x1050+0+0 (normal left inverted right x axis y axis) 474mm x 296mm
LVDS-2 disconnected (normal left inverted right x axis y axis)
DP-1 disconnected (normal left inverted right x axis y axis)
DP-2 connected 1680x1050+1680+0 (normal left inverted right x axis y axis) 474mm x 296mm
HDMI-1 disconnected (normal left inverted right x axis y axis)
VGA-2 disconnected (normal left inverted right x axis y axis)

But at least they’re consistent with the Gnome Displays panel:

gnome-prime

For reasons I don’t understand the Nvidia card appears twice in 2 different but identical providers:

$ xrandr --listproviders
Providers: number : 3
Provider 0: id: 0x96 cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 3 outputs: 2 associated providers: 2 name:Intel
Provider 1: id: 0x66 cap: 0x7, Source Output, Sink Output, Source Offload crtcs: 2 outputs: 5 associated providers: 2 name:nouveau
Provider 2: id: 0x66 cap: 0x7, Source Output, Sink Output, Source Offload crtcs: 2 outputs: 5 associated providers: 2 name:nouveau

With the tests I made, there’s no apparent difference when using one or the other. Usage of one card or the other is driven by the DRI_PRIME environment variable. If it’s set to 0, commands run on the Intel card, if it’s set to 1 they will run on the Nvidia card. For example:

$ DRI_PRIME=1 vdpauinfo | grep -i string
Information string: G3DVL VDPAU Driver Shared Library version 1.0

Or even better, to check OpenGL status:

$ glxinfo | grep -e 'OpenGL.*string.*'
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile 
OpenGL core profile version string: 3.1 (Core Profile) Mesa 9.2.0
OpenGL core profile shading language version string: 1.40
OpenGL version string: 3.0 Mesa 9.2.0
OpenGL shading language version string: 1.30
$ DRI_PRIME=1 glxinfo | grep -e 'OpenGL.*string.*'
OpenGL vendor string: nouveau
OpenGL renderer string: Gallium 0.4 on NVC1
OpenGL core profile version string: 3.1 (Core Profile) Mesa 9.2.0
OpenGL core profile shading language version string: 1.40
OpenGL version string: 3.0 Mesa 9.2.0
OpenGL shading language version string: 1.30

Unfortunately the desktop is very slow, it’s rendered by the Intel driver and put on the Nvidia card for display. I’ve tried changing priority in vga_switcheroo prior to starting X, setting the DRI_PRIME=1 variable at boot, use xrandr to change the provider output source etc. to no avail; the desktop can run only on the first card or it doesn’t work. Usually I get a black screen upon GDM start.

There’s no power management as well, so the Intel card runs normally but the Nvidia one is always on and stuck in an intermediate performance level.

When docking it; I get cloned outputs on all external displays at a very low resolution. Same issue with the Optimus disabled Nouveau driver; the outputs need to be rearranged, the lid closed and the computer needs to be woken up from standby.

Optimus cards power operation

Dual cards can be shut down on demand through vga_switcheroo. For example, login in your system as root without X running. Look at the card status with the following command:

# cat /sys/kernel/debug/vgaswitcheroo/switch
0:IGD:+:Pwr:0000:00:02.0
1:DIS: :Pwr:0000:01:00.0

This will tell you that the Integrated Graphics Display (IGD) is powered up (Pwr) and that is the primary display (+). To shut off the secondary video card, a single command is required:

# echo OFF > /sys/kernel/debug/vgaswitcheroo/switch
# cat /sys/kernel/debug/vgaswitcheroo/switch
0:IGD:+:Pwr:0000:00:02.0
1:DIS: :Off:0000:01:00.0

This will shutdown the Nvidia card. A look at the battery will tell you now that you have twice the power because the Intel card sucks very little power compared to the Nvidia one.

Turn the card on again, and switch the framebuffer console to it:

# echo ON > /sys/kernel/debug/vgaswitcheroo/switch
# cat /sys/kernel/debug/vgaswitcheroo/switch
0:IGD:+:Pwr:0000:00:02.0
1:DIS: :Pwr:0000:01:00.0
# echo DDIS > /sys/kernel/debug/vgaswitcheroo/switch
[  879.436727] i915: switched off
# cat /sys/kernel/debug/vgaswitcheroo/switch
0:IGD: :Off:0000:00:02.0
1:DIS:+:Pwr:0000:01:00.0

This will move the framebuffer and your shell to the other Nvidia driven monitor and shut down the Intel card. Sweet, isn’t it?

Power management for automatic powerup/shutdown of cards in Optimus systems and runtime management will come in kernel 3.12; I’ve tested it by using the Fedora Rawhide kernel repository and the situation improves a lot:

# cat /sys/kernel/debug/vgaswitcheroo/switch 
0:IGD:+:Pwr:0000:00:02.0
1:DIS: :DynPwr:0000:01:00.0

As you can see the second card is dynamically powered. Try to undock the system and check the status again: the second output is no longer needed so the second card shuts off:

# cat /sys/kernel/debug/vgaswitcheroo/switch 
0:IGD:+:Pwr:0000:00:02.0
1:DIS: :DynOff:0000:01:00.0

Now, with the laptop undocked, launch a command on the second card:

# DRI_PRIME=1 vdpauinfo | grep -i string
Information string: G3DVL VDPAU Driver Shared Library version 1.0
# cat /sys/kernel/debug/vgaswitcheroo/switch 
0:IGD:+:Pwr:0000:00:02.0
1:DIS: :DynPwr:0000:01:00.0

You will notice a slight delay before the command output is returned, but the card is powered on again! This is awesome. Now, after 1 or 2 seconds look again at the card:

# cat /sys/kernel/debug/vgaswitcheroo/switch 
0:IGD:+:Pwr:0000:00:02.0
1:DIS: :DynOff:0000:01:00.0

It’s shut off! Dock the laptop again and the monitor should come up again.

Keep in mind that powering up and down cards is a totally different things than power managing and adjusting clocks etc. for a running card. This make the Nvidia card shutdown automatically, not regulate its power levels during usage.

Summary

A Prime enabled laptop does not have any configuration and does not require any manual configuration. The fact that the Nvidia card can power down itself is great and doubles my battery duration! On the screen I have KMS consoles without huge fonts and can have UEFI secure boot enabled! This is really awesome.

Unfortunately though, without proper Nouveau power management and performance improvements added to the fact that I need to reconfigure monitors everytime I move (sometime the output gets all black as well when docking); the experience is not that great. I don’t know why, but when I’m undocked and using only the LVDS internal panel, the Intel performance is fantastic. Problems arise only when it’s docked and Nouveau is enabled as well.

My old laptop was working flawlessly with Nouveau. I didn’t play games on it, it was not Optimus based and the driver was generally working better.

OptimusDisabledDisabledEnabledEnabled (Prime)
DriverNvidiaNouveauIntel/NvidiaIntel/Nouveau
ConfigurationVery easy.Already set up.Very complexAlready set up.
Card power
management		Perfect!Poor performance, no power management.Nvidia card always powered up, renders for all screens.Dynamic video card switching works fine, Nouveau performance not.
Optimus card
power management		N.A.N.A.Nvidia card can't power down.Perfect!
Docking / UndockingPerfect!Manual intervention requiredManual intervention required, unreliableManual intervention required
PerformancePerfect!Pretty bad.Very good, some tearing when moving windows.Bad when using the Nvidia card for output, otherwise perfect!
Bios ConsoleVGA, no KMS.Perfect (KMS)!Perfect (KMS on Intel).Perfect (KMS)!
UEFI ConsoleUses efifb. Somewhat slow.Perfect (KMS)!Perfect (KMS on Intel).Perfect (KMS)!
UEFI secure bootCan't work.Perfect!Can't work.Perfect!

Summing up, my current choice is for the Optimus disabled setup with Nvidia drivers. I can play games, dock, undock, power management works ok and I can drive all outputs easily. And if I need to go in a meeting I don’t need to be extra cautious in shutting down virtual machines, because the system might not go up again. It’s kinda retro style when booting with the text console and battery does not last more than 3 hours, but I can bear it.

I’m impressed by the current X.org improvements of the last years and really looking forward to new developments. Sometimes just for fun I often switch back to the free drivers to check the status; like the new dynamic power management in kernel 3.12.

Let’s hope Nvidia collaboration becomes better and the new documentation does not simply stop to what has been announced.

Using OpenConnect with RSA Software Tokens in Fedora / RHEL / CentOS

slaanesh 3 Comments

OpenConnect is the Open Source alternative for the proprietary Cisco AnyConnect client. Our company is using the Cisco AnyConnect client along with PIN protected RSA Software Tokens for the authentication.

Looks like a complicated solution if you don’t have your corporate Windows client around; there’s no Cisco AnyConnect client for Linux with RSA Software Token support and the RSA application itself it’s only for Windows.

Guess what? It is not complicated at all and does not require WINE or any other tool to run the Windows app. It does not require the broken Cisco AnyConnect client either.

Update 10th June 2014: New instructions for new RSA Token Converter 3.0.
Update 10th October 2014: RSA Token Converter no longer needed.

Installation

Install the required software to import the token and the OpenConnect client itself:

# yum -y install NetworkManager-openconnect stoken-cli stoken-gui

If you’re using RHEL or CentOS up to 6.3 please reboot your system as the bundled NetworkManager is not able to reload plugins through dbus; otherwise if you’re running Fedora or RHEL/CentOS 6.4 or later you can directly proceed.

Token manipulation

Use stoken to import your token, choosing between the various options:

$ stoken import --token 2000123456...
$ stoken import --token com.rsa.securid.iphone://ctf?ctfData=2000123456...
$ stoken import --file mytoken.sdtid

Leave blank for the password request if you don’t want to password protect your token. Launch the command line program or the graphical program to get the passcode. The pin must be identical to the one you’ve set when first connecting to the VPN; otherwise the generated passcode will not match with the one generated on the VPN server:

$ stoken
Enter PIN: 1234
32031342

Alternatively you can use the GTK based stoken-gui program:

Stoken

Remove token PIN

To further speed up things; you can issue the following command to remove the pin request when opening the token (both command line and graphical):

$ stoken setpin
Enter new PIN: 1234
Confirm new PIN: 1234
$ stoken
32031342

Configuration

Create a new OpenConnect VPN through the VPN wizard of NetworkManager; the only required parameter is the server name.

If you have at least Fedora 20 or (probably) RHEL 7 with NetworkManager-openconnect 0.9.8 you can also paste the RSA Soft Token in the text box or use the Stoken file for passcode generation.

Openconnect1

Connection

Upon connection, you will be asked your username and RSA passcode. If you have enabled Soft Token integration with the PIN saved in ~/.stokenrc you will be asked only the username.

Openconnect2

Initiating the connection from the command line can be used as well. This method also enables you to avoid entering the PIN; offering the same functionality as NetworkManager-openconnect 9.8.0 on all Fedora releases and CentOS/RHEL 6:

sudo cp ~/.stokenrc /root
sudo openconnect --token-mode=rsa vpn.example.com

Pretty easy, huh?

Enabling Cisco WebEx in Fedora 19/20

slaanesh 49 Comments

Enabling Cisco WebEx on a Fedora system is actually a lot easier than it looks by searching on Google. Pretty usual uh? Every time you look for something Linux related, a plethora of posts tell you that you need to compile, download, hack and modify.

This was probably true 10 years ago, but now setting up everything is much more easier than it sounds and usually involves a couple of settings and a couple of packages.

These are the steps required to setup Cisco WebEx on a Fedora 19 system; whether it be x86_64 or i686:

# yum install icedtea-web java-1.8.0-openjdk \
    pangox-compat.i686 libXmu.i686  libgcj.i686 mesa-libEGL.i686 \
    gtk2.i686 libpng2.i686
# setsebool -P unconfined_mozilla_plugin_transition=off mmap_low_allowed=on

The first packages are by good chance already installed on your system and should be the same of your system architecture; while the others need always to be the i686 variant as the WebEx program is compiled for 32 bit processors.

webex

30th October 2013:

Updated information with additional packages for latest WebEX update.

8th January 2014:

As reported in the comments, due to recent Mesa updates, if you don’t have Mesa’s libEGL installed you have to add it. Added to the list of packages required for installation.

No more secondary architectures

slaanesh Leave a comment

I was notified I can not use Fedora Koji builders for doing personal builds of Fedora forbidden items. This means I have to drop the following architectures from the repositories:

  • CentOS/RHEL 5 – ppc
  • CentOS/RHEL 5 – ppc64
  • Fedora 20 – armv7hl

I don’t have any hardware (or access) to any system like those; so my only chance is to drop support for them. All those architectures are bound to disappear from the repositories with the next round of updates.

CDRtools repository updated

slaanesh Leave a comment

New version 3.01a17 has been released. Starting from this version packages are built with all architectures enabled; this means that Fedora 20 has inherited armv7hl support and CentOS/RHEL 6 and CentOS/RHEL 5 have now respectively ppc64 and ppc support.

Along with the update, all Fedora 17 packages have been removed now that the distribution has gone EOL.

ARM builds available for Nvidia driver

slaanesh Leave a comment

Nvidia repository has finally received the armv7hl builds and patches for kernel 3.10. I’ve added a new table that depicts the supported functionalities by distribution.

Operating systemCentOS / RHELFedorarawhide
Driver branchLong LivedShort Lived
Long Lived		Short Lived
Long Lived
Beta
Video Codec SDKYesYesYes
Architectures:

x86_64
aarch64		YesYesYes
Basic nvidia driver:

nvidia-driver
nvidia-driver-libs
nvidia-libXNVCtrl
nvidia-kmod-common		YesYesYes
CUDA libraries and tools:

libnvidia-ml
nvidia-driver-cuda
nvidia-driver-cuda-libs
nvidia-persistenced		YesYesYes
OpenGL Framebuffer Capture:

libnvidia-fbc		YesYesYes
Nvidia tools:

nvidia-modprobe
nvidia-settings
nvidia-xconfig
YesYesYes
Binary kernel
modules (kABI):

kmod-nvidia		YesNoNo
DKMS kernel
modules:

dkms-nvidia		YesYesYes
aKMOD kernel
modules:

akmod-nvidia		NoYesYes
32 bit compatibility on x86_64:

libnvidia-ml
nvidia-libXNVCtrl
nvidia-driver-libs
nvidia-driver-cuda-libs
YesYesYes
VDPAU librariesYesYesYes
EGLStream-based Wayland external platformYesYesYes
GBM EGL external platform libraryYesYesYes

Guacamole on Fedora and CentOS/RHEL 6

slaanesh 26 Comments

Guacamole is an HTML5 remote desktop gateway. Guacamole provides access to desktop environments using remote desktop protocols like VNC and RDP. A centralized server acts as a tunnel and proxy, allowing access to multiple desktops through a web browser.

No browser plugins are needed, and no client software needs to be installed. The client requires nothing more than a web browser supporting HTML5 and AJAX.

More information at the Guacamole homepage.

Components

There are two parts of which the Guacamole suite is made of; the native server components that should go on the system making the connections to the target machines and the client component (the web interface) that can reside on the same system of the server components or on a separate system.

The proxy required by the web application, guacd, is part of guacamole-server and built along with libguac and all protocol support by the guacamole-server package.

When a user connects to the Guacamole web application using their browser, they are served the JavaScript client for Guacamole.

Both guacamole-server and guacamole-client must be installed for Guacamole to work. No software needs to be installed on any client machine.

RHEL/CentOS and Fedora package status

All Guacamole components are already available in the main Fedora repositories and can be easily installed without any additional repository.

RHEL/CentOS needs the EPEL repository to be enabled and only contain the server components as the full Maven stack required to build the web application is not available in Fedora. For this reason, installing on RHEL/CentOS requires you to put the war package in the appropriate folder on the system.

Supported disitribution summary:

  • Proxy daemon (CentOS/RHEL 6 and Fedora)
  • SSH plugin (CentOS/RHEL 6 and Fedora)
  • RDP plugin with sound and printing support (CentOS/RHEL 6 and Fedora)
  • VNC plugin (CentOS/RHEL 6) with VNC repeater support (Fedora)
  • Web application (CentOS/RHEL 6 from the upstream provided war file, Fedora from the repositories)

All supported desktop protocols can be installed all together or separate from each other. Examples below assume you want to install all Guacamole software (client & server) on the same system with all the protocols available.

Installing the server components

This applies to both Fedora and CentOS/RHEL. Launch the following commands to install the server components; this will pull in all server components:

yum -y install guacd libguac-client-*

Do not forget to enable the services. On Fedora:

systemctl enable guacd

On CentOS/RHEL:

chkconfig guacd on

Installing the client components (web application)

Fedora

In Fedora, launch the following commands to install the main Guacamole web application. This will pull in Tomcat and all the required Java dependencies:

yum -y install guacamole

Enable it at boot:

systemctl enable tomcat

And then configure it. In Fedora, all configuration files are stored in the /etc/guacamole/ path. Just edit those files following the explanation in the configuring Guacamole manual section.

CentOS/RHEL

Launch the following commands to install Tomcat. This will pull in all the required Java dependencies:

yum -y install tomcat6

Enable it at boot:

chkconfig tomcat6 on

Then you need to download the main Guacamole web application archive from the Guacamole homepage. Place the downloaded war file in /var/libt/tomcat6/webapps for Tomcat consumption.

mv guacamole-0.8.3.war /var/lib/tomcat6/webapps/guacamole.war

Then you need to find a place to put the configuration files according to the configuring Guacamole manual section. This can be time consuming and quite tricky until you get the configuration right; but after a while it’s very easy.

My personal preference would be to put the files guacamole.properties and user-mapping.xml in /etc/guacamole/ like in Fedora and make sure that the Tomcat service can find the files according to the manual. To do so; issue the following commands:

mkdir -p /etc/guacamole
echo "export GUACAMOLE_HOME=/etc/guacamole" > /etc/profile.d/guacamole.sh
echo "setenv GUACAMOLE_HOME /etc/guacamole" > /etc/profile.d/guacamole.csh
chcon system_u:object_r:bin_t:s0 /etc/profile.d/guacamole.*

Running Guacamole

Once all it’s configured, running it it’s pretty simple. First of all, start all the services.

In Fedora:

systemctl start guacd
systemctl start tomcat

In CentOS/RHEL:

service guacd start
service tomcat6 start

Then point your browser to the Tomcat deployed application. If you’ve not modified Tomcat default configuration the URL is:

http://localhost:8080/guacamole/

Try to login; if you get an “Invalid user” error just look at the Tomcat logs. From my experience it’s usually a configuration problem.