mkasik kindly pointed out how to make these notifications stop.

gsettings set org.gnome.settings-daemon.plugins.print-notifications active false

But this will also turn off “gsd-printer” which is used for installation of newly plugged printers.

At the time of writing this (2012-05-18) there is no finer grained control, so you have to choose which you prefer.

This post is password protected. To view it please enter your password below:

Password:

This post is password protected. To view it please enter your password below:

Password:

Never seen one of their Finnish made toys from up close.

See also Matt Domsch’s blog.

Those still running RHEL5/CentOS5, be sure to have rng-utils-2.0-4 or later and kernel-2.6.18-238.el5 or later.

Some of the following steps are specific to my HP ProLiant MicroServer, but most will apply to any modern linux and HW (one would prefer the TPM to be an integral part of the motherboard as opposed to a module).

Physical installation in HP ProLiant MicroServer

This step will not be necessary on boards which come with a built-in TPM. Security wise, built-in is much preferred but for RNG use it does not really matter. Other motherboards will have a similar procedure.

Follow HP’s instructions in the manual that came with the MicroServer. Remember to not only remove all cables before trying to pull the board out fully, but you also, on the back, remove the screw of any PCIe cards you installed before the tray can be moved at all.

Enabling in the BIOS

All this is done with BIOS 041. I did not test if older versions of the BIOS work.

# dmidecode |grep -A 3 ^BIOS
BIOS Information
	Vendor: HP
	Version: O41
	Release Date: 07/29/2011

enter BIOS with F10 during POST. Enable it under Advanced, Trusted Computing.

Next time you enter the BIOS, you should see the Status as ‘Enabled’. If not, power cycle your box (the documentation is not 100% clear on this being needed or not).
TPM Owner Status must be UnOwned when you get the TPM. After YOU took ownership, it will show up in the BIOS. If you are the owner of a machine, and just installed a TPM that shows it’s owned, you have other problems than getting your random number generator fed. Go find out what happened with the TPM you have before you. Keep in mind that on certain machines you will be the user but not the ownwer (e.g.: a machine supplied by your employer). If this is not clear to you, please read up on TPM.

taking onership of the TPM within linux

While I did all this under RHEL6, any modern distro should support this. FWIW, I did the same under Fedora a while ago on my ThinkPad x60.
Install needed software:

# yum install tpm-tools rng-tools

The vendor manual only speaks about Windows software and how to take ownership of the TPM with it. HP does recommend reading the HP Trusted Platform Module Best Practices White Paper, but I somehow fail to locate that document on HP’s site. Do leave a comment if you know where it can be obtained.

After the machine boots, you should see /dev/tpm0, if not, verify your BIOS settings.

It is imperative that you read and understand tpm_takeownership(8) before continuing.

# man tpm_takeownership

Now claim ownership of your TPM.

# service tcsd status
tcsd is stopped
# tpm_version
Tspi_Context_Connect failed: 0x00003011 - layer=tsp, code=0011 (17), Communication failure
# /etc/init.d/tcsd start
Starting tcsd:                                             [  OK  ]
# tpm_version
  TPM 1.2 Version Info:
  Chip Version:        1.2.3.17
  Spec Level:          2
  Errata Revision:     2
  TPM Vendor ID:       IFX
  Vendor Specific data: 03110008 00
  TPM Version:         01010000
  Manufacturer Info:   49465800
# tpm_takeownership
Enter owner password:
Confirm password:
Enter SRK password:
Confirm password:

For the aim of feeding /dev/random, we could also take the well known passwords. You did read the man page, right? But why set well known ones when you can have your own?

If you plan to use software that expects the passwords to be in unicode, use the --unicode flag. Read /usr/share/doc/trousers-*/README for details.

While we did activate tcsd to be able to take ownership, “tcsd is a user space daemon that should be (according to the TSS spec) the only portal to the TPM device driver.” from tcsd(8). As such, you have to choose between rngd and tcsd. We only use the TPM to feed the entropy pool and disable tcsd.

# chkconfig tcsd --list
tcsd           	0:off	1:off	2:off	3:off	4:off	5:off	6:off
# service tcsd stop
Stopping tcsd:                                             [  OK  ]

After taking ownership, your BIOS will show;

using the TPM to feed the RNG

Now, first get a baseline when rngd is not on.

# cat /dev/random | rngtest -c 1

As this will be very slow, we check only 1 block. But ideally you’d check 100.

Now manually launch rhgd (in background mode) and check the rngtest results against your baseline.

# /sbin/rngd -b -t 1
# cat /dev/random | rngtest -c 100

It’s OK to test 100 blocks now.
If you do not get dramatically better values for input channel speed, something went wrong.
to be sure rngd uses /dev/tpm0, strace it and look at the open calls with -etrace=open

Do keep in mind that a TPM is no speed daemon, expect to see an input channel speed in the Kibits/s range. Mine gives about 90

enabling at boot

Bug 215371 being closed, I just enabled this in rc.local. N.b. the init script attached to that bug is not TPM specific, so do not blindly use that.
Comment 8 in bug 130350 explains why this is not enabled by default.
Anyway, if your distro of choice also does not run rngd at boot, do something along these lines;

cat <<EOF >>/etc/rc.local
# rng-tools has no init script
# c.f. RHBZ 215371 and RHBZ 130350
#  launching now to feed the RNG via the TPM
/sbin/rngd -b -t 1
EOF

available entropy

You can check how much entropy is available with

# cat /proc/sys/kernel/random/entropy_avail

use for KVM guests

kernel 2.6.25 or later has virtio-rng.ko but all my guest machines run older kernels, so I can not test this. See here.

addendum

on the quality of the generated random numbers and the overall security assessment of TPMs

I got this from a colleague, who is more knowledgeable in this field than me, in response to the question “My only concern how is how secure these black boxes really are.. perhaps /dev/urandom is more secure, given it’s at least been peer-reviewed and scrutinised.”

As with all HSMs, its owner cannot directly check the HSM’s firmware and chip-design. BTW, the latter applies to almost all hardware, e.g. also all hardware-RNGs in CPUs or southbridges.

As manufacturer-documentation can be deemed to be not very trustworthy (even without any conspiracy-theory, it is clear that their marketing always intends to state that the delivered entropy is “perfect”), although some docu is quite extensive and comprehensible (e.g for VIA’s Padlock), that is what Common-Criteria evaluations are for:

1. A Protection-Profile (PP) is written, which defines …
1a. the Target-of-Evaluation (TOE): Which parts of the whole security-system are evaluated (here: the TPM, but not its hardware-interface or any host-side hardware or software, e.g. host-firmware or -driver talking to the TPM).
1b. the security targets: Which kind of attacks to protect against.
1c. the security functions: which specific functions of the TOE are inspected.
1d. the methods and depth of the evaluation by choosing an EAL-level defined by Common-Criteria.org (here: EAL4 with three additional methods from EAL5, hence EAL4+)

For the TPM 1.2 the TCG has written the PP and published it on their web-site, as it must be accesible for TPM-owners in order to comprehend the details of the security asessments provided by a CC-evaluation.

2. Manufacturers submit their TOE (here: a specific TPM-model) along with evaluation-documentation (at anything higher than EAL4, basically the complete hardware- and software-design) to an independent, CC-accredited test-lab, which evaluates the TOE according to the PP and writes an evaluation-report.

3. A certification-authority for CC-evaluations (e.g. NIST, the german BSI, the french ANSSI, chosen by the TOE-manufaturer) checks the evaluation-report for correctness (formal and technical) and results, and publishes a CC-certificate.

In short: Yes, the HW-RNG in a TPM 1.2 part of the TPM-PP’s TOE, and its security-target (i.e. quality of entropy) is defined there. There are CC-certified TPMs (with the TCG-PP, and in case of STM also with a different PP @EAL5+), e.g. by Infineon.

kudos

• dcleal for pointing out this feature
• Florian for explaining how the TPM works in depth
• Dell for writing the upstream patches that add tpm rng support to rngtools
• the unnamed colleague who provided more info on the security evaluation

to do

• find out how to get rngd to read via trousers’ tcsd

The good:

• tactile feel is very much to my liking.
• backlight is controlled directly on the keyboard, with a single button that switches through 100, 50, 25 and 0% light intensity.
• most of the FN keys work out of the box under a modern Linux distribution (e.g. F15′s gnome3 allows you reassigning easily under the System Settings, Keyboard, Shortcuts). While an entertaining feature, I have no use for it and did not bother investigating why FN-F4, FN-F5 and FN-F6 did not trigger in the reassign phase while the others worked fine, nor why FN-F9 reports as a key named Tools instead of some music related name (the icon is a note).

The bad:

• the USB cord could be 10 cm longer, then again my machine is further than usual from the keyboard.
• the last row of keys (ctrl, win key, alt, …) is less bright than the other keys. No biggie but at this price, for a wired keyboard, I expect even lighting.
• the block above the arrow keys has a layout unfamiliar to me.
• the F1-F12 keys have their FN function lit (e.g. Eject as opposed to F8), I’d like F1-F12 lit. But well, I know most buyers will not share my preference (no, SetPoint does not run on my OS of choice).

An old joke but I still like it. Write your text, apply a 30 pixel motion blur at 90°. Took me 3 minutes in GIMP. Print it, hang it on a wall, see people getting confused.

Note; this is a braindump, the examples below are taken from my bash history and then hand-edited. So do use your own brain when following these steps and leave a comment if you see any editing mistakes

It was about time to move my VCS to git. I bought Version control with Git: powerful techniques for centralized and distributed project management, ISBN 9780596520120, published by O'Reilly and went for it. A braindump of what I did on my RHEL6 server follows. (Big kudos to dgrift for helping me find the mess with git’s homedirectory being set to /var/lib/git, see RHBZ #732196 for the problems I had.)

Set up a centralised git server:

1. [root@server]# yum install git-daemon
2. [root@server]# useradd -U -Z git_shell_u mygituser -s /usr/libexec/git-core/git-shell git # do NOT set the homedirectory of this user to /var/lib/git if you want to be able to log in with ssh keys.
3. dump ~git/.ssh/authorized_keys with the usual chmod, chown and restorecon
4. make a test repo:
   • [root@server]# cd /var/lib/git
   • [root@server]# mkdir test.git
   • [root@server]# cd test.git
   • [root@server]# git init --bare
   • [root@server]# chown -R git:git /var/lib/git/test.git
   • [root@server]# restorecon -rv /var/lib/git/test.git
5. try working with with it from another box:
   • [user@machine]$ git clone git+ssh://git@server.example.com/var/lib/git/test.git
   • [user@machine]$ cd test/
   • [user@machine]$ vi README
   • [user@machine]$ git commit README
   • [user@machine]$ git push origin master

Migrate from cvs:

Read gitcvs-migration and repeat the steps below for all your CVS repos

• [user@server]$ mkdir -p ~/tmp/cvs/documents”
• [user@server]$ mkdir -p ~/tmp/git/documents”
• [user@server]$ cd ~/tmp/cvs/”
• [user@server]$ export CVSROOT=”:ext:oldcvsuser@old-server:/old/cvs/location/cvsroot”
• [user@server]$ export CVS_RSH=ssh #only if you also used ssh before
• [user@server]$ cvs -d $CVSROOT checkout documents
• [user@server]$ git cvsimport -C /home/pcfe/work/git/documents documents
• [root@server]# cd /var/lib/git
• [root@server]# mkdir documents-repo.git
• [root@server]# cd documents-repo.git
• [root@server]# git init --bare
• [root@server]# chown -R git:git /var/lib/git/documents-repo.git/
• [root@server]# restorecon -rv /var/lib/git/documents-repo.git
• [root@server]# git –bare fetch /home/user/tmp/git/documents/ master:master
• and now for each remaining repo
• [user@server]$ mkdir -p ~/tmp/cvs/documents”
• [user@server]$ mkdir -p ~/tmp/git/documents”
• [user@server]$ cd ~/tmp/cvs/”
• [user@server]$ cvs -d $CVSROOT checkout SPECS
• [user@server]$ git cvsimport -C /home/pcfe/work/git/SPECS SPECS
• [root@server]# cd /var/lib/git/
• [root@server]# mkdir SPECS-repo.git
• [root@server]# chown git.git SPECS-repo.git
• [root@server]# cd SPECS-repo.git
• [root@server]# git –bare fetch /home/pcfe/work/git/SPECS/ master:master
• [root@server]# restorecon -rv /var/lib/git

Verify your backups

Those who do not have a tested backup shall be laughed at. So take this moment to insert a break of a couple days and verify that all your newly created repos in /var/lib/git/ end up on your regular backups. And make sure you can successfully restore.

Work with the centralised git repo

Depending on your needs, you might want to Set Up a Git Server through SSH Connection.

To pull it all to your various work machines;

• [user@machine]$ mkdir -p ~/work/git/CentralisedRepo
• [user@machine]$ cd ~/work/git/CentralisedRepo
• [user@machine]$ git clone git+ssh://git@server.example.com/var/lib/git/documents-repo.git
• [user@machine]$ git clone git+ssh://git@server.example.com/var/lib/git/SPECS-repo.git
• clone for each repo in turn
• [user@machine]$ cd SPECS-repo.git
• [user@machine]$ vi somefile
• [user@machine]$ git commit somefile
• [user@machine]$ git push origin

Other things to do with your git server

Sparkleshare

Máirín Duffy has an excellent writeup on how to use Sparkleshare with Fedora. That the git server runs on RHEL6 is not relevant.

On the machine that has a USB connection to the UPS

Connect the UPS via USB to your server. Then install apcupsd

# yum install apcupsd

and adjust /etc/apcupsd/apcupsd.conf. I changed the following from defaults to be a bit more conservative;

BATTERYLEVEL 10
MINUTES 7

Be sure to set an email address you read often in the scripts that are run on events (e.g.: /etc/apcupsd/onbattery ), ideally using an email to SMS gateway. For USB based SMT series, no further changes are necessary as that type of connection is the default.

For the next step to work, you’ll want to allow access to the daemon through the local firewall. Something along the lines of

# iptables -I defaults 1 -i eth0 -p tcp -m tcp --dport 3551 -j ACCEPT

Or use system-config-firewall to allow 3551 TCP.

On machines that get power from the same UPS and can reach the main box over the network

Install and configure /etc/apcupsd/apcupsd.conf as before, but this time point it at a machine called server. Additionally, I shut down most of these boxes earlier.

UPSCABLE ether
DEVICE server:3551
BATTERYLEVEL 15
MINUTES 10

And you may want to take more drastic action in the /etc/acpupsd/commfailure script if you want to react to network outages.

All the other options are sane if all you want is your machines to shut down cleanly before the UPS runs fully out of juice.

Unimportant things (e.g. the WLAN AP) get plugged into the secondary ports (caveat the SMT750I does not have these) and the behaviour of these ports configured on the UPS front panel.

Mind bug 661304, as RHEL5 is still using SysV init, my /etc/init.d/halt reads near the bottom:

...
# Now halt or reboot.
echo $"$message"
if [ -f /fastboot ]; then
 echo $"On the next boot fsck will be skipped."
elif [ -f /forcefsck ]; then
 echo $"On the next boot fsck will be forced."
fi

if [ "$command" = /sbin/halt -a -r /etc/ups/upsmon.conf -a -f /etc/killpower -a -f /etc/sysconfig/ups ] ; then
        . /etc/sysconfig/ups
        if [ "$SERVER" = "yes" -a "$MODEL" = "upsdrvctl" ] ; then
                /sbin/upsdrvctl shutdown
        elif [ "$SERVER" = "yes" -a "$MODEL" != "NONE" -a -n "$MODEL" -a -n "$DEVICE" ] ; then
                $MODEL $OPTIONS_HALT -k $DEVICE
        fi
fi

# First, try kexec. If that fails, fall back to rebooting the old way.
[ -n "$kexec_command" ] && $kexec_command -e -x >& /dev/null
...

What follows are some very terse notes for RHEL5, highlighting steps not directly obvious from that howto.

name of the key

Whenever you need to choose a keyname, take the fqdn of the DHCP server, with a trainign dot! e.g dhcp-server.example.com.

allowing the dhcp server to not update more than expected

If my reading of DNS and BIND (5th Edition), ISBN 9780596100575, published by O'Reilly Media, Inc. was correct, then the following update policies are as tight as can be. Obviously, somewhere earlier in /etc/named.conf there is a section defining the key dhcp-server.example.com. which I will not paste here.
For the forward zone I used this

zone "wlan.example.com." {
    type master;
    file "named.wlan.example.com";
    update-policy {
        grant dhcp-server.example.com. wildcard *.wlan.example.com. A TXT;
    };
};

While for the reverse zone I used

zone "2.168.192.in-addr.arpa." {
    type master;
    file "named.192.168.2";
    update-policy {
        grant dhcp-server.example.com. wildcard *.2.168.192.in-addr.arpa. PTR;
    };
};

SELinux

As BIND will now be modifying it’s own files, you need to allow this

setsebool -P named_write_master_zones 1

see the RHEL6 documentation for more details.

logging

logfile should go to the data subdirectory

logging {
        // for logging see
        // from: http://www.netadmintools.com/part233.html
        // and:  http://www.netadmintools.com/html/5named.conf.man.html
        channel default_debug {
                file "data/named.run";
                severity dynamic;
        };
        category dnssec   { security_log; };
        category update   { security_log; };
        category security { security_log; };

        channel security_log {
            file "data/dns-security.log" versions 5 size 20m;
                // every time the log grows over 20 Mbyte, it will
                // backup and rollover. Maximum 5 backups will be kept.
            print-time yes;
            print-category yes;
            print-severity yes;
            severity info;
        };

Yes, all of the above is not sufficient for you to copypasta a config together, that is intended. Read the Secure dynamic DNS howto, it is much better written and has more depth than I could ever provide in a quick braindump.