Quickly test FreeBSD 11 with KMS/VT (NewCons) support, hald and your keyboard layout

This is my super short how to install the latest X.org on FreeBSD 11 with KMS, hald enabled and a particular keyboard layout. Want to make a quick test on KVM/virt-manager or on your spare system with Intel or Radeon graphics? Here you go.

First of all, if you haven’t done it already, install the latest FreeBSD 11 image that contains VT (NewCons) support already built in. It rockes. The images are downloadable from here, just make sure to choose the image that has “VT” in the name.

ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/amd64/amd64/ISO-IMAGES/11.0/

From FreeBSD 11 we will have everything required to run on the latest and greatest platforms, that is:

* VirtIO drivers (network, block devices, PCI and memory ballooning) for KVM/libvirt/virt-manager on Linux already integrated in the kernel
* Intel KMS drivers for Intel chipsets (loadable as modules)
* Radeon KMS drivers for discrete and AMD APU integrated Radeon chipsets (loadable as modules)

Install the latest X.org

Use PKGNG and install the latest and greatest xorg meta package. This will pull in all additional requirements:

# pkg install xorg

After installing, add the proper startup lines for DBus and Hald. People tend to disable Hald to set different keyboard layouts, but it’s not actually true. By disabling Hald and the option to auto add devices you lose the ability to dock and undock your laptop and things like that.

To start the services at boot add the following two lines in /etc/rc.conf:

dbus_enable="YES"
hald_enable="YES"

Then start the services:

service dbus start
service hald start

Now you can plug and unplug your devices while the system is running.

Load your appropriate KMS driver

The examples here use both Intel and Radeon drivers, just use the one for the hardware you have, or add them both, it makes no harm. Simply the driver will not be used.

Type one the following commands in a root shell to load the appropriate drivers:

kldload i915kms
kldload radeonkms

Your screen should change and you should have now a nice prompt on the native resolution of your monitor. To load the module at boot, edit the file /boot/loader.conf and add these lines:

i915kms_load="YES"
radeonkms_load="YES"

Configure your keyboard layout

By googling around I could not find an easy yet clean solution for having hot plug capabilities in X and at the same time set my keyboard layout. By looking at a Fedora system, I discovered that is actually very simple. Just create an /etc/X11/xorg.conf file with the following content (set the XkbLayout option to your desired language):

Section "InputClass"
        Identifier "system-keyboard"
        MatchIsKeyboard "on"
        Option "XkbLayout" "it"
EndSection

This will create a rule to match all keyboards attached to the system and set the appropriate layout. Easy, isn’t it?

Now start X in your preferred way, xinit, startx or whatever.

Samba 4 Active Directory with Bind DLZ zones, dynamic DNS updates, Windows static RPC (update)

samba_logo_4cThis is a follow up to my previous post on how to install a Samba 4 enabled Active Directory system with Bind DLZ dynamic zones, dynamic DNS updates from Windows clients and how to assign a static RPC port to Windows services.

As of today, the Bind rebuild requirement to enable back ISC SPNEGO is not required anymore. With the help & time of Simo Sorce from Redhat the fix was pushed to the base Kerberos 5 libraries. You can now use the stock Bind to enable dynamic updates in all the current Fedora releases (19, 20 and Rawhide). Just make sure to have the Kerberos 5 libraries equal or greater than these versions:

* krb5-1.12.1-5.fc21
* krb5-1.11.5-4.fc20
* krb5-1.11.3-21.fc19

You can download these from here, if they are not yet in the repositories. Then, to re-align the Bind version to your current Fedora release just issue a yum distro-sync bind*, restart all services and you’re good to go.

Thank you very much to Simo Sorce for helping on this.

Samba 4 Active Directory with Bind DLZ zones, dynamic DNS updates, Windows static RPC

Fedora enablement

Fedora currently needs a patched Samba package to enable the missing Domain Controller functionality. This guide is written against Samba 4.1.3 and Fedora 19, but later versions will work.

Hopefully this change will make it into official packages when Samba will be built with the system’s MIT Kerberos implementation. You can grab the latest Samba source packages from Koji.

The first patch is for disabling MIT Kerberos integration and enabling Heimdal Kerberos with Domain Controller functionality in the Redhat/Fedora package. This has also been reported upstream:

--- samba.spec    2014-02-10 10:00:52.000000000 +0100
+++ samba.spec.dc    2014-02-11 10:43:35.038262193 +0100
@@ -38,8 +38,8 @@
 %endif
 %endif
 
-%global with_mitkrb5 1
-%global with_dc 0
+%global with_mitkrb5 0
+%global with_dc 1
 
 %if %{with testsuite}
 # The testsuite only works with a full build right now.
@@ -81,6 +81,7 @@
 Source4: smb.conf.default
 Source5: pam_winbind.conf
 Source6: samba.pamd
+Source7: samba.service
 
 Source200: README.dc
 Source201: README.downgrade
@@ -245,6 +246,13 @@
 Group: Applications/System
 Requires: %{name}-common = %{samba_depver}
 Requires: %{name}-libs = %{samba_depver}
+Requires: tdb-tools >= %{libtdb_version}
+
+%if %with_dc
+Requires(post): systemd
+Requires(preun): systemd
+Requires(postun): systemd
+%endif
 
 Provides: samba4-dc-libs = %{samba_depver}
 Obsoletes: samba4-dc-libs < %{samba_depver}
@@ -631,6 +639,9 @@
 %if ! %with_dc
 install -m 0644 %{SOURCE200} packaging/README.dc
 install -m 0644 %{SOURCE200} packaging/README.dc-libs
+%else
+# Systemd unit files
+install -p -m 644 -D %{SOURCE7} %{buildroot}%{_unitdir}/samba.service
 %endif
 
 install -d -m 0755 %{buildroot}%{_unitdir}
@@ -693,6 +704,16 @@
 %post dc-libs -p /sbin/ldconfig
 
 %postun dc-libs -p /sbin/ldconfig
+
+%post dc
+%systemd_post samba.service
+
+%preun dc
+%systemd_preun samba.service
+
+%postun dc
+%systemd_postun_with_restart samba.service
+
 %endif # with_dc
 
 %post libs -p /sbin/ldconfig
@@ -1054,6 +1075,7 @@
 %{_datadir}/samba/setup
 %{_mandir}/man8/samba.8*
 %{_mandir}/man8/samba-tool.8*
+%{_unitdir}/samba.service
 %else # with_dc
 %doc packaging/README.dc
 %exclude %{_mandir}/man8/samba.8*

The second patch is for BIND, and is used to re-enable the ISC SPN negotiation when enabling GSS authentication, see samba-technical mailing post and CentOS bug 6526 for details. This patch is required only if you don’t have Kerberos 5 packages installed with at least the following versions/revisions:

* krb5-1.12.1-5.fc21
* krb5-1.11.5-4.fc20
* krb5-1.11.3-21.fc19

Note that to enable you actually have to disable the –disable-isc-spnego parameter.

--- bind.spec.old	2014-02-11 11:12:59.762770598 +0100
+++ bind.spec	2014-02-11 11:12:40.219951833 +0100
@@ -394,7 +394,6 @@
 %endif
 %if %{GSSTSIG}
   --with-gssapi=yes \
-  --disable-isc-spnego \
 %endif
   --enable-fixed-rrset \
   --with-docbook-xsl=%{_datadir}/sgml/docbook/xsl-stylesheets \

Version change

Do not forget to bump the Epoch in the RPM spec file so packages do not conflict and are not overwritten by official packages with a lower epoch.

After patching, rebuild the packages with your favorite tools, rpmbuild, mock or koji, whatever your preference is.

Software installation

Install BIND server (required also for other optional domains), the NTP server, the Samba suite and some additional tools used by our environment on the selected server. For servers; replace also firewalld with the base iptables service:

rpm -e firewalld
yum install iptables-services bind bind-utils ntp samba-dc samba-client tdb-tools \
    krb5-workstation policycoreutils-devel libselinux-utils cups
systemctl enable iptables
systemctl start cups
systemctl enable named
systemctl stop chronyd
systemctl disable chronyd
systemctl enable ntpd
systemctl enable samba

Networking

Disable IPv6

I had to disable IPv6 for my internal network, you might need to have it enabled. Do the following to permanently disable IPv6:

sysctl -w net.ipv6.conf.all.disable_ipv6=1
 
echo "net.ipv6.conf.all.disable_ipv6=1" > /etc/sysctl.conf

Firewall configuration

The following ports need to be opened on the firewall:

* TCP: 53, 88, 135, 445, 464, 1024-5000, 3268
* UDP: 53, 88, 123, 389, 464

Ports 1024-5000 are for the RPC services used by Samba, while port tcp/53 is used by Bind to receive DNS GSS record updates (they use TCP, not UDP).

Create the file /etc/sysconfig/iptables and insert the following contents:

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp -d 192.168.23.8 --dport 5666 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp -d 192.168.23.8 --dport 22 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp -d 192.168.23.8 --dport 53 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp -d 192.168.23.8 --dport 53 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp -d 192.168.23.8 --dport 88 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp -d 192.168.23.8 --dport 88 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp -d 192.168.23.8 --dport 123 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp -d 192.168.23.8 --dport 135 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp -d 192.168.23.8 --dport 389 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp -d 192.168.23.8 --dport 389 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp -d 192.168.23.8 --dport 445 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp -d 192.168.23.8 --dport 464 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp -d 192.168.23.8 --dport 464 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp -d 192.168.23.8 -m multiport --ports 1024:5000 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp -d 192.168.23.8 --dport 3268 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT

Then start the firewall:

systemctl start iptables

Provisioning the domain

First setup and provisioning can be executed with SELinux disabled to be later re-enabled. This helps debugging issues that are not otherwise present with DAC permissions. Execute the following commands as root to start the provisioning:

setenforce 0
rm -f /etc/samba/smb.conf
samba-tool domain provision --dns-backend=BIND9_DLZ --realm=EXAMPLE.COM \
    --domain=EXAMPLE --server-role=dc --function-level=2008_R2 \
    --adminpass=Password01

Alternatively it can be run without parameters and the installation will be interactive. An output like the following will be returned:

Looking up IPv4 addresses
Looking up IPv6 addresses
No IPv6 address will be assigned
Setting up secrets.ldb
Setting up the registry
Setting up the privileges database
Setting up idmap db
Setting up SAM db
Setting up sam.ldb partitions and settings
Setting up sam.ldb rootDSE
Pre-loading the Samba 4 and AD schema
Adding DomainDN: DC=example,DC=com
Adding configuration container
Setting up sam.ldb schema
Setting up sam.ldb configuration data
Setting up display specifiers
Modifying display specifiers
Adding users container
Modifying users container
Adding computers container
Modifying computers container
Setting up sam.ldb data
Setting up well known security principals
Setting up sam.ldb users and groups
Setting up self join
Adding DNS accounts
Creating CN=MicrosoftDNS,CN=System,DC=example,DC=com
Creating DomainDnsZones and ForestDnsZones partitions
Populating DomainDnsZones and ForestDnsZones partitions
See /var/lib/samba/private/named.conf for an example configuration include file for BIND
and /var/lib/samba/private/named.txt for further documentation required for secure DNS updates
Setting up sam.ldb rootDSE marking as synchronized
Fixing provision GUIDs
A Kerberos configuration suitable for Samba 4 has been generated at /var/lib/samba/private/krb5.conf
Once the above files are installed, your Samba4 server will be ready to use
Server Role:           active directory domain controller
Hostname:              samba
NetBIOS Domain:        EXAMPLE
DNS Domain:            example.com
DOMAIN SID:            S-1-5-21-1504993763-4098306314-3392174306

Disable NetBIOS

Edit the file /etc/samba/smb.conf and make sure that the [global] section contains the following lines (in addition to the others) to disable NetBIOS support:

[global]
    server services = -dns, -nbt
    smb ports = 445

Windows 2000 and later systems setup two connections simultaniously to a server one on port 445 and one on port 139. If it gets a response from port 445 it will reset (RST) the port 139 connection. If it only gets a response from port 139, that one is used. If you disable NBT (NetBIOS over TCP/IP) on your client only port 445 is being tried. Pre-Windows 2000 clients only use port 139.

Configure Kerberos

Copy the provision generated Kerberos file to the default system location:

cp /var/lib/samba/private/krb5.conf /etc/krb5.conf

Make sure the Kerberos configuration file contains the check-ticket-addresses directive; as it is required for clients connecting through a NAT; which is the case for our IIMs / Remote PCs.

--- /etc/krb5.conf.old	2013-04-08 15:49:33.310944976 +0200
+++ /etc/krb5.conf	2013-04-08 15:49:57.989473099 +0200
@@ -2,3 +2,6 @@
 	default_realm = EXAMPLE.COM
 	dns_lookup_realm = false
 	dns_lookup_kdc = true
+
+[kdc]
+	check-ticket-addresses = false

Configure NTP server

Change the NTP configuration file to enable Microsoft signed time queries:

--- /etc/ntp.conf.default	2013-08-09 10:10:07.362235547 +0200
+++ /etc/ntp.conf	2013-08-19 12:31:44.356572515 +0200
@@ -5,8 +5,8 @@
 
 # Permit time synchronization with our time source, but do not
 # permit the source to query or modify the service on this system.
-restrict default kod nomodify notrap nopeer noquery
-restrict -6 default kod nomodify notrap nopeer noquery
+restrict default kod nomodify notrap nopeer noquery mssntp
+restrict -6 default kod nomodify notrap nopeer noquery mssntp
 
 # Permit all access over the loopback interface.  This could
 # be tightened as well, but to do so would effect some of
@@ -51,3 +51,5 @@
 
 # Enable writing of statistics records.
 #statistics clockstats cryptostats loopstats peerstats
+
+ntpsigndsocket /var/lib/samba/ntp_signd/

Change permissions of the NTP folders which should be accessible by the NTP daemon:

chgrp ntp /var/lib/samba/ntp_signd/

Configure DNS server

Look at the hints in the previous output regarding Bind and modify the file /etc/named.conf and remember to fill appropriately the zone files with the correct records. Replace my addresses with yours, of course.

--- named.conf.rpmnew	2013-10-30 12:35:25.000000000 +0100
+++ named.conf	2014-02-11 10:19:13.361403985 +0100
@@ -8,29 +8,24 @@
 //
 
 options {
-	listen-on port 53 { 127.0.0.1; };
+	listen-on port 53 { 127.0.0.1; 192.168.1.8; };
 	listen-on-v6 port 53 { ::1; };
 	directory 	"/var/named";
 	dump-file 	"/var/named/data/cache_dump.db";
 	statistics-file "/var/named/data/named_stats.txt";
 	memstatistics-file "/var/named/data/named_mem_stats.txt";
-	allow-query     { localhost; };
+	// forwarders  { 192.168.1.54; 192.168.1.55; };
+	allow-query { any; };
 
-	/* 
-	 - If you are building an AUTHORITATIVE DNS server, do NOT enable recursion.
-	 - If you are building a RECURSIVE (caching) DNS server, you need to enable 
-	   recursion. 
-	 - If your recursive DNS server has a public IP address, you MUST enable access 
-	   control to limit queries to your legitimate users. Failing to do so will
-	   cause your server to become part of large scale DNS amplification 
-	   attacks. Implementing BCP38 within your network would greatly
-	   reduce such attack surface 
-	*/
-	recursion yes;
-
-	dnssec-enable yes;
-	dnssec-validation yes;
-	dnssec-lookaside auto;
+	/* Allow recursion from Samba server itself and its Windows management system */
+	allow-recursion {
+        	192.168.1.8;
+        	192.168.1.11;
+	};
+
+	dnssec-enable no;
+	dnssec-validation no;
+	// dnssec-lookaside auto;
 
 	/* Path to ISC DLV key */
 	bindkeys-file "/etc/named.iscdlv.key";
@@ -38,7 +33,8 @@
 	managed-keys-directory "/var/named/dynamic";
 
 	pid-file "/run/named/named.pid";
-	session-keyfile "/run/named/session.key";
+
+	tkey-gssapi-keytab "/var/lib/samba/private/dns.keytab";
 };
 
 logging {
@@ -56,3 +52,6 @@
 include "/etc/named.rfc1912.zones";
 include "/etc/named.root.key";
 
+dlz "example.com" {
+	database "dlopen /usr/lib64/samba/bind9/dlz_bind9_9.so";
+};

The DNS server can also to be authoritative for additional stub zones hosted in the same BIND instance, as an example:

// Additional zones required for EXAMPLE
zone "swisslos.ch" IN {
	type master;
	file "/var/named/swisslos.ch.zone";
};

Change permissions to reach the folders containing the dynamic zones which should be accessible by Bind:

chgrp named /var/lib/samba/private /etc/krb5.conf
chmod g+rx /var/lib/samba/private

Disable IPv6 also on Bind, to avoid flooding the logs with unwanted messages. Add the following line to /etc/sysconfig/named:

OPTIONS="-4"

Starting services

Make the Samba system use its Bind recursive DNS server as primary DNS. This is required for proper Samba 4 operation of the Domain Controller. Any external request made by the server will be forwarded through the POP DNS servers.

Edit /etc/sysconfig/network-scripts/ifcfg- and change the DNS1 line to read as follows:

DNS1=192.168.1.8

Then delete all other DNS* lines from the file. Afterwards restart the network:

systemctl restart NetworkManager

Finally start Bind, NTP server and Samba:

systemctl start named
systemctl start samba
systemctl start ntpd

Troubleshooting

For debugging, launch Bind, the NTP server and Samba with the following options to start them in the foreground:

named -u named -f -g -d 2
ntpd -u ntp:ntp -g -I 192.168.23.08 -D 3
samba -i -M single -d 3

MS-SNTP troubleshooting

To troubleshoot NTP settings, perform the following command on the Windows clients to check the Windows Time Service settings and status:

w32tm /query /status /verbose

You should obtain an output like the following:

Leap Indicator: 0(no warning)
Stratum: 4 (secondary reference - syncd by (S)NTP)
Precision: -6 (15.625ms per tick)
Root Delay: 0.0458527s
Root Dispersion: 7.9058500s
ReferenceId: 0xC0A81708 (source IP:  192.168.1.8)
Last Successful Sync Time: 8/19/2013 2:33:08 PM
Source: samba.example.com
Poll Interval: 10 (1024s)
 
Phase Offset: -0.0377036s
ClockRate: 0.0156007s
State Machine: 1 (Hold)
Time Source Flags: 2 (Authenticated )
Server Role: 0 (None)
Last Sync Error: 0 (The command completed successfully.)
Time since Last Good Sync Time: 34.8648825s

It identifies the last succesful sync time; the fact that the client / server communication is using MS-SNTP to communicate (Time Source Flags: 2 (Authenticated )) and that the last command was executed successfully.

In case it doesn’t work; to manually set Windows Time Service configuration to read NTP settings from the domain perform the following commands to reset the configuration and to sync again the client to the server:

w32tm /config /update /syncfromflags:DOMHIER
w32tm /resync

Then check again the status with the previous command.

If the time server specified in the Windows client is a normal NTP server, then the Windows client will not ask for MS-SNTP signed responses. The command to synchronize the clock is as follows:

w32tm /config /update /syncfromflags:MANUAL
w32tm /resync

This is the output of the query:

Leap Indicator: 0(no warning)
Stratum: 5 (secondary reference - syncd by (S)NTP)
Precision: -6 (15.625ms per tick)
Root Delay: 0.0853119s
Root Dispersion: 7.8537712s
ReferenceId: 0xC0A80101 (source IP:  192.168.1.1)
Last Successful Sync Time: 1/28/2014 3:47:02 PM
Source: 192.168.1.1
Poll Interval: 10 (1024s)
 
Phase Offset: 0.3340008s
ClockRate: 0.0156001s
State Machine: 1 (Hold)
Time Source Flags: 0 (None)
Server Role: 0 (None)
Last Sync Error: 0 (The command completed successfully.)
Time since Last Good Sync Time: 3.3566832s

Please note that the Time Source Flags do not list the sync as Authenticated.

Kerberos authentication

Test the Active Directory Administrator password and check that the Kerberos ticket and password policies are valid:

$ kinit administrator@EXAMPLE.COM
Password for administrator@EXAMPLE.COM: 
Warning: Your password will expire in 41 days on Mon 20 May 2013 02:19:04 PM CEST
$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: administrator@EXAMPLE.COM
 
Valid starting       Expires              Service principal
04/08/2013 15:45:14  04/09/2013 01:45:14  krbtgt/EXAMPLE.COM@EXAMPLE.COM
	renew until 04/09/2013 15:45:10

SMB/CIFS file sharing

You should now see all your local default shares by browsing:

$ smbclient -L localhost -U%

To test that authentication is working, you should try to connect to the netlogon share using the Administrator password you set earlier:

$ smbclient //localhost/netlogon -UAdministrator%'Password01' -c 'ls'

To see that all the required DNS records are exposed in the DNS, launch the following commands:

$ host -t SRV _ldap._tcp.example.com.
_ldap._tcp.example.com has SRV record 0 100 389 samba.example.com.
$ host -t SRV _kerberos._udp.example.com.
_kerberos._udp.example.com has SRV record 0 100 88 samba.example.com.
$ host -t A samba.example.com.
samba.example.com has address 192.168.1.8

DNS and GSSEC records insertion/deletion

To test DNS dynamic updates perform the following command on the Windows client:

ipconfig /registerdns

This will create a DNS record for the system in the Active Directory DNS zone using a secure Kerberos authenticated update.

If the record does not appear start debugging on the server for DNS records availability and proper functioning of the DLZ zone. To proceed launch the following command with both Samba and Bind running:

samba_dnsupdate --verbose --all-names
samba_dnsupdate --verbose

This will fetch all the minimum required DNS records for Active Directory from the Samba database and try to re-insert them into the zone using a kerberized (GSSEC) DNS update to the Bind server.

In case you obtain the following message while trying to run the above command:

dns_tkey_negotiategss: TKEY is unacceptable

This means you have some problems with your current Bind Kerberos keytab file. Perform the following command to check that the service principals are contained in the file:

# klist -k -K -t /var/lib/samba/private/dns.keytab
Keytab name: FILE:/var/lib/samba/private/dns.keytab
KVNO Timestamp           Principal
---- ------------------- ------------------------------------------------------

If you obtain an empty list like the one above, extra the DNS service principal with the following command.

samba-tool domain exportkeytab --principal=DNS/samba.example.com \
    /var/lib/samba/private/dns.keytab

After generation, make sure to check again its contents. If the file is totally corrupt, regenerate it and apply permissions again. You should have some contents like the following:

# klist -k -K -t /var/lib/samba/private/dns.keytab
 
Keytab name: FILE:/var/lib/samba/private/dns.keytab
KVNO Timestamp           Principal
---- ------------------- ------------------------------------------------------
   1 15/04/2013 14:08:56 DNS/samba.example.com@EXAMPLE.COM (0xd95bd6c789b30d0d)
   1 15/04/2013 14:08:56 DNS/samba.example.com@EXAMPLE.COM (0xd95bd6c789b30d0d)
   1 15/04/2013 14:08:56 DNS/samba.example.com@EXAMPLE.COM (0x9208e7dd4029fe8bdaa18dee16ffb8fc)
   1 15/04/2013 14:08:56 DNS/samba.example.com@EXAMPLE.COM (0x79c8d7df152f3a7d5c42a3fe64248caa4faf854579b66453bea9af7c155286f9)
   1 15/04/2013 14:08:56 DNS/samba.example.com@EXAMPLE.COM (0x5ab2a4df523518d47d3b8f6be79faa2f)

In case you’re guessing what are those weird record types (like RT) you see queried in Samba’s DNS by Windows Clients, please look at the following links:

* http://www.iana.org/assignments/dns-parameters/dns-parameters.xml
* http://technet.microsoft.com/en-us/library/cc758321%28v=ws.10%29.aspx

Windows client networking adjustments

Disable NetBios over TCP/IP

To make the necessary tests; make sure that the Windows system has NetBIOS over TCP/IP disabled in the Advanced TCP/IP settings configuration pane.

Disable-netbios

Windows 2000 and later systems setup two connections simultaniously to a server one on port 445 and one on port 139. If it gets a response from port 445 it will reset (RST) the port 139 connection. If it only gets a response from port 139, that one is used. If you disable NBT (NetBIOS over TCP/IP) on your client only port 445 is being tried. Pre-Windows 2000 clients only use port 139.

Disable Teredo IPv6 Tunneling

To disable Teredo IPv6 Tunnelling execute the following command in an Administrator Windows command prompt:

netsh interface teredo set state disabled

Disable NCSI testing

To disable Network Connectivity Status Indicator checking on Microsoft servers for internet connectivity, start the Group Policy Editor (gpedit.msc); navigate to the correct tree and set “Turn off Windows Network Connectivity Status Indicator active tests” to Enable.

Disable-ncsi

Windows firewall integration

For Windows 7, the following ports need to be enabled in the firewall; all the other rules should be disabled. This is a subset of the ones listed in Microsoft’s Active Directory required ports:

* TCP: 135, 445, 3268, 1024-5000, 49154
* UDP: 123
* TCP/UDP: 53, 88, 389, 464

To make the RPC server listen only on port 49154; the following registry file needs to be applied and the system rebooted:

Windows Registry Editor Version 5.00
 
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\Internet]
"Ports"=hex(7):34,00,39,00,31,00,35,00,34,00,00,00,00,00
"PortsInternetAvailable"="Y"
"UseInternetPorts"="Y"

Commands to add the Windows Firewall rules from the command line:

netsh advfirewall firewall add rule name="Samba-TCP-In" protocol=TCP localport="88,135,445,49154" action=allow dir=IN remoteip=192.168.1.8
netsh advfirewall firewall add rule name="Samba-UDP-In" protocol=UDP localport="88" action=allow dir=IN remoteip=192.168.1.8
netsh advfirewall firewall add rule name="Samba-TCP-Out" protocol=TCP localport="53,88,135,389,445,464,1024-5000,3268" action=allow dir=OUT remoteip=192.168.1.8
netsh advfirewall firewall add rule name="Samba-UDP-Out" protocol=UDP localport="53,88,389,464" action=allow dir=OUT remoteip=192.168.1.8

To debug connections, use the PortQueryUI command that you can download from the Microsoft website:

* http://www.microsoft.com/en-us/download/details.aspx?id=24009

Updated repositories for Steam, Nvidia, HandBrake/MakeMKV, CDRtools

Another batch of updates to the repositories:

  • MakeMKV has finally been updated to version 1.8.7-2, which contains a small tweak as suggested in MakeMKV‘s forums to re-enable internal SSL support. This should solve all SCSI errors when decrypting BluRay discs on recent Fedora OpenSSL releases that do not ship all EC curves.
  • The HandBrake build with some of the bundled libraries removed in favour of system libraries (~50% of them) has been pushed as the supported build.
  • The nvidia-settings package now builds the external libXNVCtrl.so library that can be used to control the graphic cards through the NV-CONTROL extension. This library updates the old and obsolete one in Fedora based on drivers version 165.
  • The CDRtools suite has been updated to version 3.01a21.
  • The Steam package now produces an additional steam-noruntime subpackage that contains all the library requirements for running Steam without using the Steam Runtime. More details on the Steam repository page. This build has also been pushed to RPMFusion and will become the next update; so users which have the Steam package installed from the RPMFusion repositories will still have a Valve supported configuration with the Runtime enabled.

New and updated repositories

In the past few days, I’ve updated most of the repositories:

  • The Flash plugin repository does now contain separate control center packages (so an x86_64 system can have both i686 and x86_64 plugins but one control center) and has been updated to version 11.2.202.332.
  • MakeMKV has finally been updated to version 1.8.7, solving all the bugs that have been introduced by upstream in version 1.8.6.
  • Steam has been updated to version 1.0.0.45.
  • All the repository pages now contain updated instructions and information.

As a latest addition, a repository for the Spotify client (upon a colleague request) and for the RAR archiver have been added.

MakeMKV beta registration key

MakeMKV has been updated to version 1.8.6; which requires FFMpeg version 2.x to compile succesfully. Unfortunately FFMpeg is available only in Fedora 20; so at the moment there’s no way to push MakeMKV 1.8.6 to the repositories.

If you are already running Fedora 20; you should receive MakeMKV version 1.8.6 along with the updates; otherwise please use the provided beta registration key published by the developers:

http://www.makemkv.com/forum2/viewtopic.php?f=5&t=1053

After starting MakeMKV just press the “Register” button and paste the provided code:

makemkv_register

I’ve added a note on the repository page with the registration details.

Steam is now in RPMFusion!

steamThe Steam package is now available in the RPMFusion repositories. It is currently in the updates-testing repository, but it can be installed anyway directly if you have the RPMFusion repositories enabled.

http://download1.rpmfusion.org/nonfree/fedora/updates/testing/19/i386/

The package is currently 32 bit only, but it can be installed easily also on a 64 bit system. In fact, I’m currently running nearly 70 games on my 64 bit system. For details on the package, look at my now-obsolete Steam repository page.

To perform the installation today, make sure to have both RPMFusion free and non free repositories enabled and perform the following command as root:

yum -y --enablerepo=rpmfusion-nonfree-updates-testing install steam

The Steam package has some profiles enabled to avoid using the Ubuntu Steam Runtime, which produces graphical artifacts and sound issues when run in Fedora. To avoid any problems, please log out and login again or reboot the system prior to using Steam for the first time!

Steam games require the S3 Texture compression library for running on Open Source drivers, and the package already takes care of installing it for you.

Complex setup with Nvidia Optimus / Nouveau Prime on Fedora 19

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.

FreeBSD 10; new X.org, KMS, PKGNG, poudriere…

freebsdLately I’ve been playing with FreeBSD and its new technologies; PKGNG & poudriere and the new KMS/X.org stack that has been pushed to HEAD.

This is just my short how to for updating a FreeBSD CURRENT installation (10.0 at the moment of writing) with the new source code available on the FreeBSD servers.

Starting from FreeBSD 10.0 updating the base system through sources is performed with Subversion; and a lite version of it is shipped in the base system.

Get the source

First of all we must proceed in downloading the full sources from the FreeBSD servers:

svnlite checkout svn://svn0.eu.FreeBSD.org/base/head /usr/src
svnlite checkout svn://svn0.eu.FreeBSD.org/ports/head /usr/ports
svnlite checkout svn://svn0.eu.FreeBSD.org/doc/head /usr/doc

The ports directory; which is quite large; can also be downloaded and put in place with the following commands:

portsnap fetch
portsnap extract

This will populate all the directories with the required source code.

Define configuration for binaries

After getting the sources; we need to define some variables in the /etc/make.conf file to play with the new technologies being introduced.

Many things like PKGNG, CLANG, etc. have been enabled by default in recent builds, so the list is quite small:

# These lines are required to make sure that the make update command works
SVN=/usr/bin/svnlite
SVN_UPDATE=yes
 
# These lines enable the new X.org server (1.12.4) new Mesa libraries, KMS support, etc.
WITH_NEW_XORG=yes
WITH_KMS=yes
WITH_GALLIUM=yes
 
# Line for custom kernel configuration
KERNCONF=CUSTOM

FreeBSD still ships by default with X.org server 1.7; Mesa 7.x and a lot of outdated components. The new X.org components have not been switched yet to default; so specific lines need to be put in place for compiling the required port versions.

After this file, we need to create the kernel configuration file that is specified by the KERNCONF variable. I’m happy with the GENERIC kernel as I run it on multiple systems; so I will not change any option inside the configuration. What I do is turn off debugging support that is enabled by default on unrealeased FreeBSD versions.

So let’s create /usr/src/sys/amd64/conf/CUSTOM and put the following content inside:

include GENERIC
ident CUSTOM
 
# Disable debugging options
nooptions DDB
nooptions GDB
nooptions DEADLKRES
nooptions INVARIANTS
nooptions INVARIANT_SUPPORT
nooptions WITNESS
nooptions WITNESS_SKIPSPIN
nooptions MALLOC_DEBUG_MAXZONES

This kernel configuration file does nothing except specifying a new name and disabling the debugging options already enabled by default in the FreeBSD kernel. This way, when I update the sources; I don’t need to pay attention at which features are new or change in the GENERIC kernel. Pretty smart system.

Update the base system

To update the system, launch the following commands as root (you can of course build the system without being root, but for this short how to this is much clear):

cd /usr/src
make -s update
make -s -j5 buildworld
make -s -j5 buildkernel

The various make commands will make sure that you update the system with the latest sources and build all the toolchain required to compile the system and all the system commands and libraries. After this we’re good to go to install the new kernel and reboot the system:

make -s installkernel
shutdown -r now

When rebooting, choose “Boot in single user mode” (boot -s at the prompt) and perform the following commands to mount the root system in read/write mode:

mount -u /
mount -a -t ufs

Then check for conflicting configuration files that are to be updated (in my case 90% of the time I just need to press “i” to install the new configuration file); install the updated binaries and reboot.

mergemaster -p
cd /usr/src
make -s installworld
mergemaster
reboot

Configure poudriere for generating packages

FreeBSD 10 does not ship anymore with legacy package management tools but only with PKGNG; so the old way of building ports feels “obsolete” after you’ve been using a Linux distribution with package management for years. Thanks, poudriere comes to the rescue.

First of all we install the bleeding edge poudriere package (hey, we’re on 10.0-CURRENT; so we are already bleeding!). To install the package, go to the ports directory and install it:

cd /usr/ports/ports-mgmt/poudriere-devel
make install

After installing, we need to configure it and create a FreeBSD jail for building packages and some variables in poudriere’s configuration file.

cd /usr/local/etc/
cp poudriere.conf.sample poudriere.conf

Personally, this is what I have in my configuration file:

NO_ZFS=yes
FREEBSD_HOST=ftp://ftp.freebsd.org
RESOLV_CONF=/etc/resolv.conf
BASEFS=/share
USE_PORTLINT=no
USE_TMPFS=yes
DISTFILES_CACHE=/usr/ports/distfiles
CHECK_CHANGED_OPTIONS=yes
CHECK_CHANGED_DEPS=yes
NOLINUX=yes

As you can see I don’t have a ZFS filesystem, I’m not interested in Linux support and I’m sharing the downloaded source tarball directory with the ports system.

The /share directory is a separate mount point in my system where I link the base FreeBSD source folder, the ports directory, the documentation source directory and all the poudriere jails, work queues and package repositories. Make sure to have plenty of space!

We need to replicate the /etc/make.conf of our base system inside the jail to make sure all the packages get the correct settings. Create the file /usr/local/etc/poudriere.d/10-amd64-make.conf with the following contents:

WITH_NEW_XORG="yes"
WITH_KMS="yes"

Now we’re ready to start with poudriere. Issue the following commands:

poudriere ports -c
poudriere jail -c -m ftp -v 10.0-CURRENT -j 10-amd64

This will download a recent copy of the ports tree and create a FreeBSD jail taking the most recent snapshot of 10.0-CURRENT directly from the FreeBSD ftp servers! Awesome.

To update the ports tree, just issue the following command:

poudriere ports -u

Now that we’re ready to go, it’s time to list what ports we would like to build. Create a text file and put the list of ports you want to build inside of it; for example:

x11/xorg
x11/xorg-minimal
x11/nvidia-driver
x11/nvidia-settings
ports-mgmt/poudriere-devel

If you want some additional specific per-port configuration options, you can use the options subcommand. For example; to disable Linux support in the Nvidia driver, perform the following command:

poudriere options x11/nvidia-driver

and deselect Linux; much like you would do using standard ports.

Generate package repositories from the ports collection

Now that all is in place it’s time to trigger the builds. Perform the following command:

poudriere bulk -f portslist.txt -j 10-amd64

Poudriere will take care of setting a parallel task for each cpu you have and make sure all the dependencies are built in the correct order.

After munching for a long time (better go hack some Ingress portals or leave it running night long…) you will have a repository ready for use on your system. Depending on the paths/names you’ve chosen for the FreeBSD jail and for the configuration file you will have something like the following:
# cd /share/data/packages/10-amd64-default
# ls -l
total 176
drwxr-xr-x  2 root  wheel   8704 Sep 13 18:35 All
drwxr-xr-x  2 root  wheel    512 Sep 13 11:51 Latest
-rw-r--r--  1 root  wheel  12508 Sep 13 18:35 digests.txz
-rw-r--r--  1 root  wheel  46344 Sep 13 18:35 packagesite.txz
-rw-r--r--  1 root  wheel  97092 Sep 13 18:35 repo.txz

You just need to add the repository to your system and you’re ready to install packages! The repository also contains the latest pkg package for distribution.

This folder can be published on the web, left locally or wherever you choose. The only thing you need to do is enable the repository on your system(s) through the /usr/local/etc/pkg.conf file.

As an example, if you want to use the current package repository directly on the system where you’ve built everything just leave the following line in the configuration file:

packagesite: file:///share/data/packages/10-amd64-default

Using package repositories

Finally a great package management for FreeBSD. First of all update the repository definition:

pkg update

and then install the packages you want! For example:

pkg install xorg nvidia-driver

PKGNG will take care of everything.

Updating packages

To update packages, just re-update the ports tree with poudriere, rebuild with the bulk command (only the changed packages or the packages with changed dependencies will be rebuilt!) and upgrade your system!

poudriere ports -u
poudriere bulk -f portslist.txt -j 10-amd64
pkg update
pkg upgrade

Awesome.

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

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?