Big update to the Nvidia driver repository (346.xx, 340.xx compat, CUDA)

My personal Nvidia repository has seen quite a few updates on versions, CUDA enablements, legacy drivers and Delta RPMS.

Long Lived branch

Version 346.35 is now the new Long Lived branch release, this, plus the fact that is the newest made it to all supported distributions (CentOS/RHEL 6/7, Fedora 20/21/rawhide).

Here is the table that lists the current versions:

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

CUDA stack

A complete packaged CUDA stack has been added for all supported distributions. This now includes all CUDA libraries and tools at version 6.5.19 (includes NVML / GPU deployment kit). You can easily install CUDA 6.5 on CentOS/RHEL 6/7 and Fedora 20/21/rawhide!

All the packages provide/require/obsolete the relevant driver packages in the RPMFusion repository and all the CUDA packages in the Nvidia repository; so you can enable this repository along with the official Nvidia CUDA one and RPMFusion at the same time. Packages will get upgraded accordingly.

Nvidia is slowly fading out 32 bit support from CUDA, and you can see it reflected in the various packages. The Unified Video Memory kernel module (nvidia-uvm.ko has been removed in version 346.16, CUDA graphical programs are 64 bit only, many libraries and compilers are available in 64 bit only, etc.

Feedback from users has been integrated, where possible.

List of components by distribution:

Operating systemCentOS / RHELFedorarawhide
CUDA cuDNNYesYesYes
GCC compatibility
(if needed)
-cuda-gcccuda-gcc
Basic CUDA libraries/tools:

cuda
cuda-libs
cuda-cuda
cuda-cli-tools
cuda-cublas
cuda-cudart
cuda-cufft
cuda-cupti
cuda-curand
cuda-cusolver
cuda-cusparse
cuda-extra-libs
cuda-libs
cuda-npp
cuda-nvjpeg
cuda-nvrtc
cuda-nvtx
cuda-nvvp
cuda-samples
cuda-sanitizer
YesYesYes
CUDA development:

cuda-cccl-devel
cuda-cudart-devel
cuda-cudnn-devel
cuda-cupti-devel
cuda-cuxxfilt-devel
cuda-devel
cuda-nvml-devel
cuda-nvprof-devel
cuda-nvrtc-devel
cuda-nvtx-devel
cuda-profiler-devel
cuda-sanitizer-devel
YesYesYes
GUI programs:

cuda-nsight
cuda-nvvp
cuda-nsight-compute
cuda-nsight-systems
YesYesYes

Legacy drivers 340.xx

A compatibility repository for drivers on 340.x, the new legacy release for cards up to 9xxx chipsets has been introduced. It’s in the same place, just follow the instructions by appending -340 to the repository file. This repository does not include the CUDA packages, just the enablement on the drivers.

The repository itself it’s not guaranteed to stay online forever; the GTX 9xxx series are from 2008 and I don’t guarantee I will maintain it for long.

Delta RPMS

Delta RPMS have been introduced, to reduce the time and data required for upgrades. Driver packages can reach 90 mb and CUDA packages can span even 650 mb. This would save you a lot of time into upgrading them. For now, delta RPMS have been generated for the new 346.35 drivers, and this reduced nearly 80% the download size on Fedora 21.

We’ll see some real gain when updating the CUDA packages.

Ending words

Along this, there is the usual assortment of packages refinement (syntax, RPMLint, optimizations, etc.). For additional details, please see the Nvidia driver page.

As time permits, new CUDA enabled packages will be added to the repository, namely Blender, ccMiner, NVENC enabled ffmpeg, etc.

As usual, any feedback is much appreciated!

Converting system between RHEL and CentOS

rhel2centosHave you ever had the need to switch a CentOS system to a valid Red Hat Enterprise Linux subscription and viceversa?

I had this need quite a few times, with the most simple case being to transform an evaluation environment based on CentOS that has been used to convince a boss, into a fully supported Red Hat subscription at the end of the evaluation.

On the other hand, it could prove very useful to create an exact copy of an installed system that is currently attached to a Red Hat subscription on an image in your laptop for development purposes. Or simply because the Red Hat subscription has expired and we don’t need any kind of paid support from Red Hat.

As an example for this conversion tutorial, we’re using a CentOS/RHEL 6.6 system. The procedure is the same even if we are also switching minor release during the conversion; for example upgrading from 6.3 to 6.6.

From Red Hat Enterprise Linux to CentOS

This is the most simple case, mainly for two reasons. First of all, we can fetch the packages we need for the installation on the web (we don’t need a valid Red Hat subscription) and basically we are reducing the number of packages that are installed on the sytem in comparison with a pristine Red Hat Enterprise Linux system.

As the first step we must remove the -release package from the system and switch it with the one we’re interested in. This way the yum commands will be able to expand the necessary variables and fetch the correct packages.

rpm -e --nodeps redhat-release-server-6Server
yum -y install http://mirror.centos.org/centos/6/os/x86_64/Packages/centos-release-6-6.el6.centos.12.2.x86_64.rpm

Also, with CentOS and Fedora, the package that defines the system release contains also the yum repository definitions, speeding up conversion considerably.

Now, the only thing we need to do is to start the package syncing process. Yum will take care of the rest.

yum -y distro-sync
reboot

If during the upgrade we performed quite a significant jump of release (for example from 6.3 to 6.6) it’s good practice to also reset the SELinux contexts on the filesystem during the first reboot:

fixfiles onboot

System cleanup after the conversion

Before restarting the system, we can also take care of a few simple finishing touches; for example we can remove the Red Hat network support packages that we will never use again:

yum -y remove rhn\* subscription\* yum-rhn-plugin

Erase packages that are no longer available in any repository:

package-cleanup --orphans

Or we can also replace the initial Firefox starting page that suggests us to register our system with Red Hat Network:

rpm -e --nodeps redhat-indexhtml
yum -y install http://mirror.centos.org/centos-6/6.6/os/x86_64/Packages/centos-indexhtml-6-2.el6.centos.noarch.rpm

To remove the leftover kernels on the system (including packages containing kernel headers, modules, etc.) we can run this command that will clean the system for us from all kernels except the one we’re running:

package-clenup -y --oldkernels --count=1

From CentOS to Red Hat Enterprise Linux

The opposite procedure is slightly different. It’s a bit simpler as the commands we require to type are reduced (quite a few packages from CentOS keep providing the old Red Hat package name in the Provides: tags. It’s otherwise a bit longer as we need a valid account to download by hand the required packages for the conversion; as the yum repositories (or channels) are not available.

After getting access to the Red Hat customer portal, we need to download the following packages to register the system (in our example we’re targeting a Server subscription):

redhat-release-server
rhn-check
rhn-client-tools
rhn-setup
rhn-setup-gnome
rhnlib
rhnsd
subscription-manager
subscription-manager-firstboot
subscription-manager-gnome
yum-rhn-plugin

Now we can proceed with the system conversion, as yum will behave like running on a Red Hat system:

rpm -e --nodeps centos-release
yum install *rpm

Then we can register our host to the channels we want:

subscription-manager --register

And finally proceed with the package synchronization:

yum -y distro-sync
reboot

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

samba_logo_4cA guide on how to run a tightly secured Samba 4 based Active Directory Domain Controller to serve Windows 2000+ clients. This setup has the following advantages:

  • Static RPC ports, so you can have a firewall between your clients and Domain Controller
  • Bind DLZ zones (dynamic LDAP zones), that can be managed through standard Windows Remote Services Administration Tools
  • Dynamic DNS updates (clients register themselves in DNS)
  • No insecure LANMAN, NetBIOS, SMB1 enabled. Security is higher, performance is much better!

This makes the installation much hardened and secure than the default Microsoft setup.

This is an update to my old post for the new stuff that has changed during the past year and the introduction of CentOS/RHEL 7.

System enablement

This guide is written against Samba 4.x for Fedora and CentOS/RHEL 7 and a minimum Samba version of 4.1.6, as it’s the first Samba release that includes systemd support. You can grab the latest Samba source packages from Koji.

Both require a patched Samba package to enable the missing Domain Controller functionality. Hopefully this change will make it into official packages when Samba will be built with the system’s MIT Kerberos implementation.

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

--- /dev/null
+++ b/samba-4.1.12-unit.patch
@@ -0,0 +1,12 @@
+diff -Naur samba-4.1.12.old/packaging/systemd/samba.service samba-4.1.12/packaging/systemd/samba.service
+--- samba-4.1.12.old/packaging/systemd/samba.service   2015-02-05 14:25:54.981110990 +0100
++++ samba-4.1.12/packaging/systemd/samba.service   2015-02-05 14:31:36.109654120 +0100
+@@ -8,7 +8,7 @@
+ PIDFile=/run/samba.pid
+ LimitNOFILE=16384
+ EnvironmentFile=-/etc/sysconfig/samba
+-ExecStart=/usr/sbin/samba $SAMBAOPTIONS
++ExecStart=/usr/sbin/samba -i $SAMBAOPTIONS
+ ExecReload=/usr/bin/kill -HUP $MAINPID
+ 
+ [Install]
diff --git a/samba.spec b/samba.spec
index 549e5d4..ee630e0 100644
--- a/samba.spec
+++ b/samba.spec
@@ -100,6 +100,7 @@ Source200: README.dc
 Source201: README.downgrade
 
 Patch0: samba-4.1.15-fix_auth_with_long_hostnames.patch
+Patch1: samba-4.1.12-unit.patch
 
 BuildRoot:      %(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX)
 
@@ -255,6 +256,13 @@ Requires: %{name}-python = %{samba_depver}
 Provides: samba4-dc = %{samba_depver}
 Obsoletes: samba4-dc < %{samba_depver}
 
+%if %with_dc
+Requires: tdb-tools >= %{libtdb_version}
+Requires(post): systemd
+Requires(preun): systemd
+Requires(postun): systemd
+%endif
+
 %description dc
 The samba-dc package provides AD Domain Controller functionality
 
@@ -521,6 +529,7 @@ module necessary to communicate to the Winbind Daemon
 %setup -q -n samba-%{version}%{pre_release}
 
 %patch0 -p1 -b .samba-4.1.15-fix_auth_with_long_hostnames.patch
+%patch1 -p1
 
 %build
 %global _talloc_lib ,talloc,pytalloc,pytalloc-util
@@ -665,7 +674,7 @@ install -m 0644 %{SOURCE200} packaging/README.dc-libs
 %endif
 
 install -d -m 0755 %{buildroot}%{_unitdir}
-for i in nmb smb winbind ; do
+for i in nmb smb winbind %{?with_dc:samba}; do
     cat packaging/systemd/$i.service | sed -e 's@\[Service\]@[Service]\nEnvironment=KRB5CCNAME=FILE:/run/samba/krb5cc_samba@g' >tmp$i.service
     install -m 0644 tmp$i.service %{buildroot}%{_unitdir}/$i.service
 done
@@ -716,6 +725,15 @@ fi
 %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
@@ -1049,6 +1067,7 @@ rm -rf %{buildroot}
 %{_libdir}/mit_samba.so
 %{_libdir}/samba/auth/samba4.so
 %{_libdir}/samba/bind9/dlz_bind9.so
+%{_libdir}/samba/bind9/dlz_bind9_10.so
 %{_libdir}/samba/libheimntlm-samba4.so.1
 %{_libdir}/samba/libheimntlm-samba4.so.1.0.1
 %{_libdir}/samba/libkdc-samba4.so.2
@@ -1100,6 +1119,7 @@ rm -rf %{buildroot}
 %{_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*

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 (the rpms you just rebuilt) 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 server firewall:

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

Ports 1024-5000 are for the RPC services used by Samba, and can be further reduced in case you don’t have many clients. Port tcp/53 is used by Bind to receive DNS GSS record updates (they use TCP, not UDP). It is also used for large zone transfers, but this is not our case.

Create the file /etc/sysconfig/iptables and insert the following contents (we are assuming the server has an IP address of 192.168.0.17):

*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.0.17 --dport 22 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp -d 192.168.0.17 --dport 53 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp -d 192.168.0.17 --dport 53 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp -d 192.168.0.17 --dport 88 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp -d 192.168.0.17 --dport 88 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp -d 192.168.0.17 --dport 123 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp -d 192.168.0.17 --dport 135 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp -d 192.168.0.17 --dport 389 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp -d 192.168.0.17 --dport 389 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp -d 192.168.0.17 --dport 445 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp -d 192.168.0.17 --dport 464 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp -d 192.168.0.17 --dport 464 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp -d 192.168.0.17 -m multiport --ports 1024:5000 -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 and then later re-enabled. This helps debugging issues that are not otherwise present with DAC permissions. Since the domain controller functionality has not been enabled yet in the official packages; SELinux policies have not been updated yet. 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 the provisioning command 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

When requesting a resource, Windows 2000 and later systems start two connections simultaneously to a server. One is on port 445 and one on port 139. If the client gets a response from port 445 it will reset (RST) the connection on port 139. 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 (such as windows NT) 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.

--- /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 daemon:

chgrp ntp /var/lib/samba/ntp_signd/

Configure DNS server

Look at the hints in the previous provisioning output regarding BIND and modify the file /etc/named.conf. 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.0.17; };
    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.0.17;
+           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 in flat files. For 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

If you disabled IPv6 for the system, disable IPv6 as well for BIND, this prevents 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.0.17

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.0.17)
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

The output 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 will be 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'

Required DNS records

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.0.17

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 message dns_tkey_negotiategss: TKEY is unacceptable while trying to run the command; tis 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, extract the DNS service principal into the file 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)

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

When requesting a resource, Windows 2000 and later systems start two connections simultaneously to a server. One is on port 445 and one on port 139. If the client gets a response from port 445 it will reset (RST) the connection on port 139. 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 (such as windows NT) only use port 139.

Disable Teredo IPv6 Tunneling

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

netsh interface teredo set state disabled
netsh int ipv6 isatap set state disabled
netsh int ipv6 6to4 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:

Communications from the Windows client towards the domain controller:

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

Communications from the domain controller towards the Windows clients:

  • TCP: 135, 445, 1024-1048

TLS support for LDAP (local domain on 389 and Global Catalogue on 3268) is disabled because connections are made with SASL, using GSS-API and thus employing Kerberos and session-level encryption. For details on message integrity (signing) and message confidentiality (sealing) please see this nice article from the University of Washington that explains authentication in a simple way.

RPC ports can be as low as one, but in this case you lose a lot of the functionality. For example, running a scheduled task on Windows will open an additional RPC port (yes, that’s true), and if the system does not have any one that can be used, the process fails miserably. From my test in our office, 24 ports should be enough for domain management plus normal day to day desktop use.

To make the RPC server listen on port range 1024-1048; 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):31,00,30,00,32,00,34,00,2d,00,31,00,30,00,34,00,38,00,00,00,00,\
  00
"PortsInternetAvailable"="Y"
"UseInternetPorts"="Y"

Please note, the following Windows commands will still return the full list of RPC ports for Windows services:

netsh int ipv4 show dynamicport udp
netsh int ipv4 show dynamicport tcp

These are the commands required to add the Windows Firewall rules from the command line; they assume you want to enable the full 192.168.0.0/24 network where the Domain Controller will reside:

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

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

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

Experimental CUDA packages

nv-cuda-2014header-updated

I’ve created experimental CUDA packages that try to follow Fedora packaging guidelines as close as possible. Those have been updated to the Nvidia Fedora 20 repository, and are installable through normal yum commands.

To install them, you need to use my repository that contains the latest drivers.

32 bit support

Nvidia is slowly fading out 32 bit support from CUDA, and you can see it reflected in the various packages. The Unified Video Memory kernel module (nvidia-uvm.ko has been removed in version 346.16, CUDA graphical programs are 64 bit only, many libraries and compilers are available in 64 bit only, etc.

Package testing

I’ve uploaded packages only to the Fedora 20 repository, as they are very big and this is what I’m using at the moment as my main desktop. To help test these, I’ve also added a package for ccminer, a CUDA cryptocurrency miner that links to the packages and requires them to be built. By installing it, all required CUDA runtime libraries should be installed as well.

If all goes well, my plan is to enable CUDA packages for all supported Fedora/CentOS/RHEL distributions and add also package software that in the current form do not use the Nvidia libraries.

As an example, the Blender package in Fedora does not (obviously) link to the CUDA libraries, so no CUDA rendering. On the contrary, the binary that you can download from the Blender website is linked statically to the CUDA libraries at compile time.

After some feedback I will enable them for all the other distributions. So if you need them, please test them.

Packages available

A brief recap on the packages, here we have the full list of drivers and CUDA packages that are available inside the repository folder:

$ ls -1 *nvidia* *cuda*
akmod-nvidia-343.22-2.fc20.x86_64.rpm
cuda-6.5.19-2.fc20.x86_64.rpm
cuda-cli-tools-6.5.19-2.fc20.x86_64.rpm
cuda-devel-6.5.19-2.fc20.i686.rpm
cuda-devel-6.5.19-2.fc20.x86_64.rpm
cuda-docs-6.5.19-2.fc20.noarch.rpm
cuda-extra-libs-6.5.19-2.fc20.i686.rpm
cuda-extra-libs-6.5.19-2.fc20.x86_64.rpm
cuda-libs-6.5.19-2.fc20.i686.rpm
cuda-libs-6.5.19-2.fc20.x86_64.rpm
cuda-nsight-6.5.19-2.fc20.x86_64.rpm
cuda-nvvp-6.5.19-2.fc20.x86_64.rpm
dkms-nvidia-343.22-2.fc20.x86_64.rpm
kmod-nvidia-343.22-2.fc20.x86_64.rpm
nvidia-driver-343.22-1.fc20.x86_64.rpm
nvidia-driver-cuda-343.22-1.fc20.x86_64.rpm
nvidia-driver-cuda-libs-343.22-1.fc20.i686.rpm
nvidia-driver-cuda-libs-343.22-1.fc20.x86_64.rpm
nvidia-driver-devel-343.22-1.fc20.i686.rpm
nvidia-driver-devel-343.22-1.fc20.x86_64.rpm
nvidia-driver-libs-343.22-1.fc20.i686.rpm
nvidia-driver-libs-343.22-1.fc20.x86_64.rpm
nvidia-driver-NvFBCOpenGL-343.22-1.fc20.i686.rpm
nvidia-driver-NvFBCOpenGL-343.22-1.fc20.x86_64.rpm
nvidia-driver-NVML-343.22-1.fc20.i686.rpm
nvidia-driver-NVML-343.22-1.fc20.x86_64.rpm
nvidia-driver-NVML-devel-340.29-1.fc20.i686.rpm
nvidia-driver-NVML-devel-340.29-1.fc20.x86_64.rpm
nvidia-healthmon-340.29-1.fc20.x86_64.rpm
nvidia-libXNVCtrl-343.22-1.fc20.i686.rpm
nvidia-libXNVCtrl-343.22-1.fc20.x86_64.rpm
nvidia-libXNVCtrl-devel-343.22-1.fc20.i686.rpm
nvidia-libXNVCtrl-devel-343.22-1.fc20.x86_64.rpm
nvidia-modprobe-343.22-1.fc20.x86_64.rpm
nvidia-persistenced-343.22-2.fc20.x86_64.rpm
nvidia-settings-343.22-1.fc20.x86_64.rpm
nvidia-xconfig-343.22-1.fc20.x86_64.rpm

Package bundles

From the above list, packages can be grouped as follows for an x86_64 system. For additional details, please see the repository page.

Kernel modules, in both akmod and dkms variants. Instantiated kernel modules are available as rebuild in both by enabling the appropriate configuration on your system.

akmod-nvidia
dkms-nvidia
kmod-nvidia

These are the basic driver packages, they are what is required along the kernel module packages to have accelerated drivers and full OpenGL support for a normal desktop. That is gaming, office use, etc. But no CUDA support.

nvidia-driver
nvidia-driver-libs.i686
nvidia-driver-libs
nvidia-libXNVCtrl
nvidia-libXNVCtrl.i686
nvidia-settings

Then we have the CUDA libraries and tools that are part of the drivers and not of the full CUDA toolkit, as they are closely tied to the drivers:

nvidia-driver-cuda
nvidia-driver-cuda-libs.i686
nvidia-driver-cuda-libs
nvidia-persistenced

Then there are extra tools and libraries, like Framebuffer Compression OpenGL libraries, GPU Deployment Kit (NVML, also called Nvidia Management Library), command line configuration for very specific X.org setups and a tool that leverages the NVML library to perform health checks on GPU clusters.

Please note that the Nvidia Management Library headers and tools do not follow the same versioning of the main driver set as they are provided by Nvidia in a separate bundle that is compatible across multiple releases of the drivers. For example, at the time of writing this, we have 340.58 (long lived), 343.22 (short lived) and 346.18 (beta) drivers available.

All works with version 340.29 of the NVML libraries.

nvidia-driver-NvFBCOpenGL.i686
nvidia-driver-NvFBCOpenGL
nvidia-driver-NVML.i686
nvidia-driver-NVML
nvidia-healthmon
nvidia-modprobe
nvidia-xconfig

Lastly, we have all the development files (unversioned library symlinks, headers and documentation) for compiling programs that link to the above driver libraries.

nvidia-driver-devel.i686
nvidia-driver-devel
nvidia-driver-NVML-devel.i686
nvidia-driver-NVML-devel

After those, that have been provided here for more than a year, I’ve now added CUDA packages. These can be splitted into multiple components as well; first group contains most runtime components for simply running CUDA enabled programs:

cuda-libs.i686
cuda-libs
cuda-extra-libs.i686
cuda-extra-libs

Then we have development files (headers, stub libraries, documentation, compilers, etc.) for compiling programs that link to the CUDA libraries:

cuda
cuda-cli-tools
cuda-devel.i686
cuda-devel
cuda-docs.noarch

And then finally, we have Java GUI programs (debuggers, etc.):

cuda-nsight
cuda-nvvp

Official Nvidia repositories

All the packages provide/require/obsolete the relevant driver packages in the RPMFusion repository and all the CUDA packages in the Nvidia repository; so you can enable this repository along with the official Nvidia CUDA one and RPMFusion at the same time. Packages will get upgraded accordingly.

All DKMS patches merged upstream

All Fedora/CentOS/RHEL patches that were in the DKMS build in Fedora/EPEL are now merged upstream; along with additional patches from Debian and Ubuntu.

Additions are many:

  • Inter-dependency logic between modules (spl, zfs, etc.)
  • Additional parameters for skipping creation of ram disks, running depmod, etc
  • Fix templates for package generation
  • Systemd unit file
  • Tons of fixes, especially with dkms parameters, cleanup of remaining folders and recent bash shells

There are test builds available, if you happen to use DKMS please leave some feedback. These need some testing on all supported distributions (that is RHEL/CentOS 5, 6 and 7; and Fedora 19, 20, 21), so it will stay in the testing repositories for quite some time until I get some feedback.

End of summer updates

Just came back from holiday and work travel; just in time for another batch of changes for the repositories:

  • MakeMKV has been updated to version 1.8.12.
  • HandBrake has been updated to the current development version for Fedora 20, 21 and 22. It enables now x265 by default and uses even less bundled libraries. It also uses the system libappindicator for notifications.
  • Flash plugin package has been updated to version 11.2.202.400.
  • Spotify it’s now at version 0.9.11.27.g2b1a638.81-1. As announced previously in another post, the original i386 build was reverted by upstream to 0.9.4 without even notifying and it stayed locked at this version for months. As such, I completely removed i386 support for it. I’ve changed the repository page to reflect it.
  • The Nvidia Management library header and man pages (alias GPU Deployment Kit) it’s now at version 340.21, the bundled version in CUDA 6.5. It works with drivers version 340.x and up.

Most of the repositories now support both Fedora 21 and 22, including HandBrake & friends.

Also, I’m building CUDA 6.5 packages now that it has been released. Testers welcome as usual.

Fedora Nvidia drivers: OutputClass for X server 1.16, GPU deployment kit, CUDA enablement, RHEL7 kABI modules

The Nvidia repository has been updated; here is the table that lists the current versions:

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

Quite a few things have changed, the packages are going towards providing the complete packaged CUDA stack. So far, only the GPU deployment kit has been inclued; and the packages allow for parallel installation with the Nvidia CUDA repositories by osboleting/updating packages as required. Here is some details on the things that have been implemented.

X.org configuration

  • Starting from Fedora 21, all driver X.org configuration can be managed by simply adding/removing X.org configuration snippets in /etc/X11/xorg.conf.d.
  • Use new OutputClass directive on Fedora 21 X.org server 1.16 (and later) to load the driver and do not rely on an edited /etc/X11/xorg.conf file. This also removes editing of the xorg.conf file from the package scriptlets.
  • Add the IgnoreABI directive by default on Fedora rawhide builds.

Kernel modules

  • Add a new UDev rule in nvidia-driver-cuda for the nvidia-uvm module and make X.org NVIDIA Files section to be loaded latest in case there are other packages providing a custom Files section (thanks Jan P. Springer for spotting these).
  • The binary nvidia-modprobe is now SETUID, but its package is no longer a mandatory requirement for the drivers, so it will not get installed by default.
  • Now that both Redhat Enterprise Linux 7 and CentOS 7 have been released, binary modules (kABI) are now provided for these distributions.

CUDA support

  • Added the GPU Deployment kit to the repository. This is constructed with NVML (NVIDIA Management Library) included with the drivers plus headers, docs and samples from a separate tarball. The separate tarball is using a different version number than the drivers. This is packaged in the nvidia-driver-NVML and nvidia-driver-NVML-devel packages. Installing these, the gpu-deployment-kit dependency provided by the CUDA repositories is preserved.
  • Along with NVML, the nvidia-healthmon package is provided to monitor TESLA GPU clusters.

Along this, there is the usual assortment of packages refinement (syntax, RPMLint, optimizations, etc.). For additional details, please see the Nvidia driver page.

If you would like to test the CUDA packages please contact me and I will point you to a repository hosting the CUDA packages.

Another batch of big updates for the repositories (Nvidia, HandBrake, Steam, etc…)

Another batch of changes for the repositories. The HandBrake repository has seen some updates:

  • MakeMKV has been updated to version 1.8.11.
  • HandBrake has been updated to the current development version for Fedora 21. It contains additional/different bundled libraries, but the situation is not that bad.
  • libdvdnav is now based on a 5.0.0 snapshot that contains all the fixes required to avoid the HandBrake crash while opening a DVD for scanning with the default settings. Removal of the flag “Use dvdnav (instead of libdvdread)” in the preferences panel is no longer required.

Please test it, I found it much more stable than the previous version. If it works, I might build it also for current Fedora releases.

handbrake-svn

Regarding the other updates:

  • The Nvidia driver is now at version 340.24 for all CentOS/RHEL and Fedora variants.
  • Nvidia Fedora 21 packages have now aKMOD support
  • Nvidia CentOS/RHEL 7 packages have now binary kABI modules, so you can install the binaries directly without relying on DKMS.
  • The CDRtools suite has been updated to version 3.01a24.
  • The Steam package has been updated to version 1.0.0.48-2, the same build has been pushed to RPMFusion. The repository hosted here still contains other SteamOS packages.
  • The Flash plugin package has been updated to version 11.2.202.378 and Skype has been updated to version 4.3.0.37. Both versions have also been pushed to RPMFusion in the form of lpf packages.
  • Spotify it’s still at version 0.9.10; as the x86_64 and i386 builds share the same data package. Upstream has updated the x86_64 build to 0.9.11 but at the same time has reverted the i386 build to 0.9.4, so all Ubuntu users will not get the update anymore. Until this is sorted out, I’m going to leave the current package versions as 0.9.10 for systems that are both 32 and 64 bit. RHEL/CentOS 7 (which is 64 bit only) has the new 0.9.11 version.

As always, any issue just let me know.