Overrides With SSSD

LINUX has long been plagued with a rather lousy identity management scheme.  Beyond the limitations of POSIX's getent and related calls [which can be very inefficient] the attempts to stub in network-aware identity services such as LDAP have only piled onto the rough edges.  NSCD attempted to work around performance problems via caching - and did not do very well.  Then was NSLCD the next evolution of NSCD which was better, but still inflexible.  Identity management in more complex networks is a tedious business and what administrators need more than anything else is flexibility.
Finally we have SSSD - The System Security Services Daemon - which is an identity service that seems to have an answer for every basic issue - from caching, to Kerberos integration, to joining together multiple domains....  On top of all that essential goodness is the simple feature of local overrides for identity values.
As an administrator at a multiple platform enterprise this has always been a dilema - what value should get stored in certain user attributws such as "loginShell"?  Not all systems want/need the same thing.  Ugly solutions involve symbolic links and/or installing non-standard shells.  None of which can be described as "elegant" or even "correct".  Our AIX systems want to use "/bin/ksh", our LINUX systems want to use "/bin/bash" [or even "/usr/bin/bash"].  Ultimately I end up storing the attribute in user object for the most limited inflexible systems - generally that means AIX gets its way.

This means when I attempt to sign into an out-of-the-box LINUX installation it fails.

Jan 14 08:22:21 example sshd[24292]: User adam not allowed because shell /bin/ksh does not exist
Jan 14 08:22:21 example sshd[24293]: input_userauth_request: invalid user adam
Jan 14 08:22:29 example sshd[24292]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.1.257  user=adam

Bummer.  But now that systems are using SSSD to back the NSS service the solution is as simple as:

[nss]
override_shell = /bin/bash

And now my shell, and the shell for every user, on that host is "/bin/bash". 

Aside: How often would users on the same host actually use different shells? That sounds like an administrator’s nightmare.  At least on modern systems the loginShell seems much more appropriate as a host property than a user property;  the most shell the majority of users ever experience is the login script that starts their application or menu.

SSSD provides overrides for shell, home directory [override_homedir] and primary group [override_gid: make the primary group of all users from the network identity service the same].

Author: Adam Tauno Williams

Some Random xsltproc Tips

The xsltproc command allows the processing of an XML document with an XSLT template.

xsltproc rentalouts.xslt rentalouts.xml
Text 1: Perform the transform "rentalouts.xslt" on the document "rentalouts.xml".

A lesser known feature of xsltproc is the ability to pass parameters - these become XSLT variables - to the transformation.

xsltproc  --stringparam sales_id 15 DailyRentalOutNotice.xslt -
Text 2: Perform the "DailyRentalOutNotice.xslt" transform on the XML document read from standard input with a variable $sales_id having a value of "15".

Addition useful directives are --repeat (which runs the transform 20 times) and --timing (which outputs the run-time information of the transform).  These directives allow for much easier and more accurate performance testing/tuning of a transformation than running xsltproc under time, for example.

If you've ever been curious what XSLT extensions your xsltproc supports [this may vary by build] you can dump the known extension using the --dumpextensions parameter.

~> xsltproc --dumpextensions
Registered XSLT Extensions
--------------------------
Registered Extension Functions:
{http://exslt.org/crypto}md5
{http://exslt.org/math}random
{http://exslt.org/math}abs
...
Text 3: xsltproc reporting its supported extensions.

author: Adam Tauno Williams

Paramiko's SFTPFile.truncate()

Paramiko is the go-to module for utilizing SSH/SFTP in Python.  One one the best features of Paramiko is being able to being able to SFTPClient.open() a remote file and simply use it like you would use a local file.  SFTPClient's open() returns an SFTPFile which is a file-like object that implements theoretically the same behavior as Python's native file object.
But the catch here is file-like.  It is like a file, except when it is not like a file.
The non-likeness I encountered concern's SFTPFile's truncate method.  The native Python file object has a truncate method where the size is option, if not specified it will default to the current offset of the file.  However SFTPClient's truncate method requires the size to be specified.  Failure to specify an size value results in a TypeError exception concerning incorrect number of parameters.

Creating A CUPS Backend

I gave this presentation at the Grand Rapids Barcamp (August, 2014)

The presentation covers the basics for creating a print back-end on a CUPS print server.  The process is very straight forward and allows you to setup, essentially, print to anything - even your own application.  Printing to an application can have a surprising number of applications given that nearly everything no matter how old or basic can print.

Testing A WINS Server

On a CIFS/SMB domain the WINS service is critical for proper function [some things use WINS, some things use DNS, it is terribly confusing, but it is what it is].  DNS is relatively easy to test and you will likely know right away if it isn't working.  But before adding those new DCs to your dhcpd.conf file -

option netbios-name-servers 192.168.1.78, 192.168.1.79, 192.168.1.65;

 - it would be nice to be equally confident WINS is operating as expected.
To that end the Samba package provides a useful tool nmblookup which support querying of a WINS server much like host/nslookup does for DNS.

$ nmblookup --unicast=192.168.1.65 --recursion arabis-red
querying arabis-red on 192.168.1.65
192.168.1.58 arabis-red<00>
$ nmblookup --unicast=192.168.1.78 --recursion arabis-red
querying arabis-red on 192.168.1.78
192.168.1.58 arabis-red<00>
$ nmblookup --unicast=192.168.1.79 --recursion arabis-red
querying arabis-red on 192.168.1.79
192.168.1.58 arabis-red<00>

The --unicast option specifies the IP address of the WINS server; but this option is only effective in the expected way if used with the [oddly named] --recursion options. Without --recursion the --unicast will not cancel use of the NetBIOS name resolution logic.
One other useful feature of nmblookup is the --translate option.  This option invokes a reverse DNS search on the IP address returned by the WINS query - allowing one step verification that WINS and DNS are on the same page.

$ nmblookup --unicast=192.168.1.79 --translate --recursion arabis-red
querying arabis-red on 192.168.1.79
ARABIS-RED.example.com, 192.168.1.58 arabis-red<00>

Remotely Restarting The Management Agents On ESXi 5.x

The ESXi management agents can be restarted from the host's console -  which is not very convenient.  Fortunately they can also be restarted remotely using the SSH & ESXi Shell services - but these are not enabled by default.
In Virtual Center select the host, then the Configuration tab. In the security section select Services and Properties in order to enable "ESXi Shell" and "SSH". For both services perform a manuals start.
Once the SSH service is active you can SSH to the host as root and then restart the hostd and vpxa services like any standard LINUX System-V service.  This may cause the host to temporarily grey out in Virtual Center; it will come back automatically in a few moments.

awilliam@linux-86wr:~> ssh root@172.31.7.126
Password:
The time and date of this login have been sent to the system logs.

VMware offers supported, powerful system administration tools. Please
see www.vmware.com/go/sysadmintools for details.

The ESXi Shell can be disabled by an administrative user. See the
vSphere Security documentation for more information.
~ # /etc/init.d/hostd restart
watchdog-hostd: Terminating watchdog process with PID 9034
hostd stopped.
hostd started.
~ # /etc/init.d/vpxa restart
watchdog-vpxa: Terminating watchdog process with PID 9336
vpxa stopped.
~ # Connection to 172.31.7.126 closed.

After restarting the management agents the SSH and ESXi services should be stopped in the same manner they were started.
It would be nice if in VMware's "powerful system administration tools" they just had a button labeled "Restart Management Agents".

Uncoloring ls

By default on every recent shell the output of ls is colorized. This is a great feature - but it makes using terminals that use a non-standard [not(background==black)] color-scheme awkward.  Things just disappear;  try reading directory name displayed in yellow on a yellow background.  It is difficult.
How this colorization gets setup in openSUSE is that that the ls command is aliased to "ls --color=auto".  You can see this aliasing using the alias command.

[fred@example ~]# alias
alias cp='cp -i'
alias l.='ls -d .* --color=auto'
alias ll='ls -l --color=auto'
alias ls='ls --color=auto'
alias mv='mv -i'
alias rm='rm -i'
alias which='alias | /usr/bin/which --tty-only --read-alias --show-dot --show-tilde'

So a simple way to turn this off is: unlias ls
There you go - no more annoying colors!  But they will be back the next time you login. Is this alias created in ~/.bashrc  - nope. ~/.bash_profile - nope. /etc/bashrc - nope. /etc/profile - nope, errr.... well, sort of.  The script /etc/profile runs every script in /etc/profile.d which ends in .sh.  Within /etc/profile.d is ...drumroll... colorls.sh which indeed does alias ls='ls --color=auto'.
To disable colorization - the aliasing of ls upon login:

mv /etc/profile.d/colorls.sh /etc/profile.d/colorls.sh.x

Now that the script does not end in .sh /etc/profile will not run it.
When you start a new interactive login[*1] shell bash runs: /etc/profile, then ~/.bash_profile, ~/.bash_login, and then ~/.profile.   Generally ~/.bash_profile will run ~/.bashrc, and generally ~/.bashrc will run /etc/bashrc.  And, of course, when /etc/profile runs it runs each of the scripts which match /etc/profile.d/*.sh.  It is almost comical; who says UNIX can't dance?

[*1] The shell distinguishes between login and secondary shells - a secondary shell is invoked by an existing shell, whereas a login shell is the first shell.  It also distinguishes between interactive and non-interactive shells - like those running a script.