ntpdate service on Fedora 18 (Spherical Cow)

I had trouble getting ntp to sync time: starting the ntpdate service gave errors. Manually running ntpdate produced the error message "no server suitable for synchronization found". This answer at serverfault fixed it for me.

Made a change to /etc/sysconfig/ntpdate:

# Options for ntpdate
OPTIONS="-u -p 2"
# Number of retries before giving up
RETRIES=2
# Set to 'yes' to sync hw clock after successful ntpdate
SYNC_HWCLOCK=yes

Then, enable the service and start it:

$ sudo systemctl enable ntpdate.service
$ sudo systemctl start ntpdate.service

An annoyance: systemctl and sysctl are way too similar and do completely different things.

Writing a new SELinux policy module for a standard init daemon

This is going to be a summary of my experience writing new policy modules for Ganglia gmetad and gmond on RHEL5. Ganglia is a "scalable distributed monitoring system for high-performance computing systems." I downloaded the package source distribution, and built RPMs myself.

In case you are looking to apply this to something else, here are a couple of the underlying assumptions:

• the service is a standard init-launched daemon
• each service only has one executable, the daemon program

In the case of gmetad and gmond, the daemon programs are, respectively, /usr/sbin/gmetad and /usr/sbin/gmond.

I have written about creating new SELinux policies before, but I think this is better in that it wraps things up into a module that may be removed or updated more easily than a monolithic policy. Note, however, that rules governing network ports are not bundled into the module. (See below.)

This is going to be an iterative process. Before even starting, one needs to know which files/directories the daemons will write to, and if they run non-root. If the package one is working with is well-documented, this may be obtained from the documentation. If not, some trial and error will be needed. Also, for most programs, these file/directory locations are configurable.

We use the GUI Selinux Policy Generation tool, system-config-selinux. There is a good article on using this tool by Dan Walsh dating back to 2007.

We will start with gmetad. In the case of gmetad, the default location for the RRD files is /var/lib/ganglia/rrds. So, the policy should allow write access to /var/lib/ganglia.

In the Selinux Policy Generation tool, these are the entries used:

• Name: gmetad
• Executable: /usr/sbin/gmetad
• Standard Init Daemon
• Incoming network ports, both TCP and UDP: 8651,8652
• Common Application Traits
• Application uses syslog to log messages
• Application uses /tmp to Create/Manipulate temporary files
• Application uses nsswitch or translates UID's (daemons that run as non root)
• Add Directory: /var/lib/ganglia

This generates 4 files in whatever directory you specify at the end of the druid: gmetad.fc, gmetad,if, gmetad.sh, gmetad.te. If you examine gmetad.sh, you will see:

#!/bin/sh
make -f /usr/share/selinux/devel/Makefile
/usr/sbin/semodule -i gmetad.pp

/sbin/restorecon -F -R -v /usr/sbin/gmetad
/sbin/restorecon -F -R -v /var/lib/ganglia
/usr/sbin/semanage port -a -t gmetad_port_t -p tcp 8651
/usr/sbin/semanage port -a -t gmetad_port_t -p tcp 8652
/usr/sbin/semanage port -a -t gmetad_port_t -p udp 8651
/usr/sbin/semanage port -a -t gmetad_port_t -p udp 8652

Note that the ports are not bundled into the "compiled" module file, gmetad.pp. The port rules are added "manually". The module merely defines the type gmetad_port_t.

The gmetad.te file is what we will be editing in the iterative steps below.  The first line determines a version number, that allows you to update a policy using "semodule -u gmetad.te".

policy_module(gmetad,1.0.0)

Make sure the gmetad service is not running. Now, turn off the auditd service, and move away the audit log file to simplify finding incremental changes in policy that are needed:

# service gmetad stop
# service auditd stop
# cd /var/log/audit< # mv audit.log audit.log.20130313-1500

Then, start up the audit daemon, followed by gmetad. Wait for a few minutes (or much longer) for gmetad to do its thing, and for auditd to accumulate all or most of the AVC denials that would affect gmetad. Once a sufficient amount of time has passed:

# grep gmetad /var/log/audit/audit.log | audit2allow -R > audit.out

The output should look like:

require {
        type gmetad_t;
        class capability { setuid setgid };
}

#============= gmetad_t ==============
allow gmetad_t self:capability { setuid setgid };
kernel_read_kernel_sysctls(gmetad_t)

Next, edit gmetad.te, and increment the version number. Append to the end of gmetad.te the contents of audit.out. Then, generate the policy file, and load the updated policy:

# make -f /usr/share/selinux/devel/Makefile
# semodule -u gmetad.pp

Next, shut down gmetad, shut down auditd, move the audit log away, start auditd, and start gmetad. Wait a bit, and look for new denials in the audit log by doing

# grep gmetad /var/log/audit/audit.log | audit2allow -R > audit2.out

To append any new rules, you have to manually pick out the new unique lines from audit2.out and put them in the appropriate sections (the 'require' section, or the block of allows) of gmetad.te. For gmetad.te, I found there wasn't much change between iterations. For gmond, however, there were quite a few, mostly the addition of file getattr permissions. This involved changing many lines like:

allow gmond_t lvm_t:file read;  -->  allow gmond_t lvm_t:file { getattr read };

This iteration may have to include alternating gmond and gmetad since gmetad has to connect to the gmond port, which means something like:

allow gmetad_t gmond_port_t:tcp_socket name_connect;

Here at the Wake Forest University HPC facility, we have a combination of cfengine and Puppet to manage machine configurations: cfengine for the RHEL5 nodes, and Puppet for the RHEL6 nodes. The policy .pp file is distributed via cfengine, and a shellcommand is run by cfengine to load/update the module, and additional commands do the file system relabelling and the port rules. Basically, reproducing the .sh file that the Policy Generation Tool creates.

UPDATE 2013-03-22: If you have a cyclic dependency in your policy modules -- in this case, gmond refers to gmetad, and gmetad refers to gmond -- you will find that you can't load the modules individually. All you have to do is load them all in one command line:

semodule -i gmond.pp gmetad.pp

Web 2.0 made easy with IFTTT

Web 2.0 is about treating everything on the web as a datasource, and generating dynamic content based on one or more datasources. It used to be a fairly complex task: websites rarely presented their data in a structured form, much less provided APIs for access. So, one had to rely on a bunch of ugly screenscraping tricks which include pages of regular expressions.

Now, most sites publishing useful data also publish a machine-readable stream. Most will even provide APIs to access that data, e.g. Flickr (a Web 2.0 pioneer), Twitter, Facebook, etc.

The point of this post is to highlight ifttt.com (stands for "If This Then That"). It comes with many predefined "channels", which may be considered both sources of data and targets for publishing to. Personally, I use it to send myself a text message whenever the weather forecast predicts rain the following day. Recently, I just created a Tumblr (since there is a lot more social interaction between bloggers there than on Blogger), and wrote a recipe to duplicate posts in this blog to Tumblr. It reads the RSS feed for this blog, and every time there's a new item, a text post is created at Tumblr which links back to the post here.

I also have, for my personal use, a recipe that looks at Craigslist for listings of bicycles of a certain make, and emails me a link to the posting when one is found. For data sources which do not give legal RSS, one can use Yahoo! Pipes to preprocess the input and generate a clean RSS feed, which can then be used in an IFTTT recipe.

Cinnamon desktop for Ubuntu 12.10 Quantal

I wish I had discovered this sooner. I've been using Unity for months and never did get used to it very well. I installed the Cinnamon desktop over the weekend, and it works like an old-fashioned desktop.

sudo add-apt-repository ppa:gwendal-lebihan-dev/cinnamon-stable
sudo apt-get update
sudo apt-get install cinnamon

When logging in, click on the small Ubuntu logo, and select the desktop environment you want.

Wifi connectivity issues and TCP SACK

So, my Ubuntu 12.10 laptop recently developed an issue where it would not connect to the wifi access point at a local café. My iPhone had no trouble, nor the laptop when booting into Windows 7. Other people using Mac laptops seemed to have no trouble, either.

At a guess, since similar connectivity issues came up at work a few months ago, I decided to turn off TCP SACK (Selective ACKnowledgement), and that caused the wifi connection to start working. What's odd is that SACK is supposed to be negotiated at the start of a connection. Whatever. It works, now.

UPDATE: Well, maybe that wasn't it. Right after doing this, I turned SACK back on to see its effects, and was able to connect to the access point with no trouble.

UPDATE 2: Here's the commandline:

sysctl -w net.ipv4.tcp_sack=0

There was some discussion on ServerFault about TCP SACK, and also an in-depth article by Patrick McManus from 2008.

Changing the GNOME keyring password

I just changed my password yesterday -- we have a 180-day lifetime on passwords at Wake Forest -- and discovered that my GNOME keyring password still remained the same. The password is supposed to be the same as the login password so that the keyring is unlocked when you log in.

I had changed my password using the command line. Maybe the GUI tool would automatically update the keyring password, as well. (I have my doubts.)

A little googling turned up slightly outdated information. So, for posterity. One uses Seahorse which turns up as the "Passwords and Keys" application under Fedora. Just search for "seahorse":

Once you do, though, there is no obvious way to change the keyring password as this is the view first presented:

The trick is to go to the View menu, and check on "By keyring".

A left sidebar pops up showing you the three keyrings available: Passwords, PGP Keys, and Secure Shell. The Login keyring under Passwords should have a lock icon next to it:

Right click on "Login keyring", and select "Change Password", then change it to be the same as your login password. The next time you log in (even with KDE), the Login keyring will be unlocked.

Fixed-width fonts in Gmail

I keep having to search my email for instructions I mailed out to colleagues to get fixed-width fonts in Gmail under Firefox and Chrome. So, I'll make a post, instead. This is gleaned from various sources on the net.

First, for Firefox:

1. Install the Stylish extension. This allows injection of CSS into web pages.
2. In the Firefox Add-on management window, click on User Styles in the left hand column, and then click the Write New Style button.
3. Enter the following userstyle "script", and then give a name, and save and close:

@namespace url(http://www.w3.org/1999/xhtml);

@-moz-document domain("mail.google.com") {
    /* GMail messages and textarea should use fixed-width font */
    .gs .ii, .textarea, .editable {
    font-family: MonoSpace !important;
    }
}

If you use Firefox Sync to sync Firefox on different machines, you may want to install the Stylish Sync extension, which uses Firefox Sync to sync installed user styles.

If you don't want to write your own user style, you may be able to find one at userstyles.org.

For Chrome, I use a Greasemonkey script, i.e. injected Javascript. Chrome natively supports Greasemonkey userscripts. You could also use this on Firefox if you have Greasemonkey installed.