openssl the command is amazing

There are lots of things you can do with the openssl command that I didn't know about:

Verify if numbers are prime:

$ openssl prime 119054759245460753
1A6F7AC39A53511 is not prime
$  

Encrypt a file with your favorite cipher:

openssl list-cipher-commands

base64 encode a file

openssl enc -base64 -in file.txt

Generate a shadow-style password hash:

$ openssl passwd -1 MySecret
$1$sXiKzkus$haDZ9JpVrRHBznY5OxB82.
$ 

Many others. I never knew it could do some much. Thanks madboa.com.

Also, I played around with openssl while updating certificates for about 30 web servers. I was able to check that the new cert was installed correctly on all of the hosts easily looking at that host's SSL finger prints as served from Apache:

echo EOF | openssl s_client -connect $host:443 -showcerts | openssl x509 -fingerprint -noout -md5

The above fits well into a bash loop which can be run before and after you replace the certs:

for x in `cat vhosts.txt`; do 
   echo "vhost: $x";echo EOF | openssl \
     s_client -connect $x:443 -showcerts \
     | openssl x509 -fingerprint -noout \
     -md5; 
done 
| egrep "vhost|Fingerprint" > finger_prints.txt

You can then diff the finger prints files to verify that they're what you're expecting them to be.

Android Development with Clojure

Android Development is now looking even more attractive: Clojure and Android with Emacs on Ubuntu.

FLOSS Smart Phones

Brad Kuhn wrote an article on the state of Smart Phones with respect to Free, Libre, and Open Source Software (FLOSS) and says:

HTC Dream currently gives the most software freedom among Android/Linux deployments. It is unlikely that Google wants anything besides their applications to be proprietary. While Google has been unresponsive when asked why these hardware interface libraries are proprietary, it is likely that HTC, the hardware maker with whom Google contracted, insisted that these components remain proprietary, and perhaps fear patent suits... no detailed analysis of the Nexus One is yet available, it's likely similar to the HTC Dream.

With regard to permission to run one's own software on the device -- something central to phone development -- Brad points out:

Google is our best ally in this regard. The HTC Dream developer models, called the Android Dev Phone 1 (aka ADP1). permit the user to install any operating system on the phone, and the purchase agreement extract no promises from the purchaser regarding what software runs on the device. Google has no interest in locking you to a single carrier, but only to a single Google experience application vendor. Offering a user “carrier freedom of choice”, while tying those users tighter to Google applications, is probably a central part of their marketing plans.

Other interesting quotes include:

• Community-oriented forks... [must] begin in the Android/Linux space.
• A traditional “get some volunteers together and write some code” approach can achieve great advancement toward community-oriented FLOSS systems on mobile devices. Developers could initially focus on applications for the existing “mostly FLOSS” platforms of MeeGo and Android/Linux.
• We need to identify the proprietary software that is important, and write free software replacements. It's catch-up work, but our community is usually successful at such tasks. So, let's get coding on mobile! (see FSF Bulletin, Issue 16, May 2010)

Brad has some additional blog entires on android and is a co-founder of the Replicant project. I'm curious about switching providers so I'm curious about the distinction between the Hero and Dream.

PostgreSQL has an IP address data type

• Network Address Types
• Network Address Functions and Operators

Goodbye EMC

I have been getting up around 2:30 every morning once a week for the last six weeks, to work during agreed upon maintenance windows, to migrate data from two EMC Clariions to two IBM XIVs. Today was the last migration. All of the production data on both EMCs has been moved. If it breaks tomorrow, it wouldn't be so bad, though we'd loose our new development storage system. I'm very happy to be rid of depending on EMC.

xwrits

todo: try xwrits.

"Linux Magazine" article on SSD file systems

"Linux Magazine" recently did an article (referenced but not included in link) on choosing a file system for your SSD. I am now running Fedora 13 on an Intel X25-M as mentioned earlier in SSD experiment. I'm using ext4 and mounting with the noatime,nodiratime options. Performance is snappy. The article had the following benchmark.

                                   MBps
test                     ext2  ext4  ext4 no jrnl   btrfs   btrfs(ssd_spread)
-----------------------------------------------------------------------------
dbench -D /test 10       520   407   428            347     347
bonnie++ /test -s 2048   38    58    72             64      67

The article also had some useful links.

• Linus' blog post his SSD
• SSD’s, Journaling, and noatime/relatime
• Theodore Ts'o on Trim Support for ext4
• btrfs discard function
• btrfs SSD optimizations
• DiskTRIM

Foot Pedals

I am looking for a USB Foot Pedal to act as a control key and an alt/meta key. Bill Clemson did this. I'll be looking around.

Multicast and Red Hat Cluster Suite

Getting members of a Red Hat Cluster Suite to communicate and get quorum can be difficult. This post documents how I verified that multicast was working as I step towards setting up a cluster.

After you start your cluster see which multicast address was assigned:

[root@vserver0 ~]# grep "default multicast" /var/log/messages
Dec 27 16:51:51 vserver0 openais[6953]: [MAIN ] Using default multicast address of 239.192.104.1 
Dec 27 18:26:33 vserver0 openais[3664]: [MAIN ] Using default multicast address of 239.192.104.1 
Dec 28 04:25:28 vserver0 openais[13028]: [MAIN ] Using default multicast address of 239.192.104.1 
Dec 30 14:02:35 vserver0 openais[9533]: [MAIN ] Using default multicast address of 239.192.104.1 
[root@vserver0 ~]# 

I also see that each node is listening on the same address:

[root@vserver0 ~]# netstat -an | grep 239
udp        0      0 239.192.104.1:5405          0.0.0.0:*
[root@vserver0 ~]# 

[root@vserver1 ~]# netstat -an | grep 239
udp        0      0 239.192.104.1:5405          0.0.0.0:*
[root@vserver1 ~]# 

[root@vserver2 ~]# netstat -an | grep 239
udp        0      0 239.192.104.1:5405          0.0.0.0:*
[root@vserver2 ~]# 

The cluster documentation talks about configuring multicast and implies that you might have to enable it on your router. You can verify if your router is passing multicast packets between nodes with tcpdump and iperf as described in taosecurity.blogspot.com. I can reproduce the results described in the taosecurity blog in my cluster as so:

wget ftp://ftp.pbone.net/mirror/ftp.freshrpms.net/pub/freshrpms/pub/dag/redhat/el5/en/x86_64/dries/RPMS/iperf-
2.0.4-1.el5.rf.x86_64.rpm
rpm -ivh iperf-2.0.4-1.el5.rf.x86_64.rpm 

I set up vserver0 as an iperf server listening on multicast address 239.192.104.1:

[root@vserver0 ~]# iperf -s -u -B 239.192.104.1 -i 1
------------------------------------------------------------
Server listening on UDP port 5001
Binding to local address 239.192.104.1
Joining multicast group  239.192.104.1
Receiving 1470 byte datagrams
UDP buffer size:   126 KByte (default)
------------------------------------------------------------

Now I generate multicast traffic from vserver1.

[root@vserver1 ~]# iperf -c 239.192.104.1 -u -T 32 -t 3 -i 1
------------------------------------------------------------
Client connecting to 239.192.104.1, UDP port 5001
Sending 1470 byte datagrams
Setting multicast TTL to 32
UDP buffer size:   126 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.129 port 48770 connected with 239.192.104.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 1.0 sec    129 KBytes  1.06 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  3]  1.0- 2.0 sec    128 KBytes  1.05 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  3]  2.0- 3.0 sec    128 KBytes  1.05 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 3.0 sec    386 KBytes  1.05 Mbits/sec
[  3] Sent 269 datagrams
[root@vserver1 ~]# 

Here is what vserver0 sees:

------------------------------------------------------------
[  3] local 239.192.104.1 port 5001 connected with 192.168.1.129 port 48770
[ ID] Interval       Transfer     Bandwidth       Jitter   Lost/Total Datagrams
[  3]  0.0- 1.0 sec    134 KBytes  1.09 Mbits/sec  1.109 ms    0/   93 (0%)
[ ID] Interval       Transfer     Bandwidth       Jitter   Lost/Total Datagrams
[  3]  1.0- 2.0 sec    128 KBytes  1.05 Mbits/sec  0.136 ms    0/   89 (0%)
[ ID] Interval       Transfer     Bandwidth       Jitter   Lost/Total Datagrams
[  3]  0.0- 3.0 sec    386 KBytes  1.07 Mbits/sec  0.957 ms    0/  269 (0%)

The traffic looks like this:

[root@vserver0 ~]# tcpdump -n -i eth0 -s 1515 udp | grep  239.192.104.1 > muticast.txt
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 1515 bytes
343 packets captured
343 packets received by filter
0 packets dropped by kernel

[root@vserver0 ~]# 

[root@vserver0 ~]# wc -l muticast.txt 
283 muticast.txt
[root@vserver0 ~]# head -5 muticast.txt 
15:09:23.364851 IP 192.168.1.129.5149 > 239.192.104.1.netsupport: UDP, length 118
15:09:23.760086 IP 192.168.1.129.5149 > 239.192.104.1.netsupport: UDP, length 118
15:09:24.156427 IP 192.168.1.129.5149 > 239.192.104.1.netsupport: UDP, length 118
15:09:24.555871 IP 192.168.1.129.5149 > 239.192.104.1.netsupport: UDP, length 118
15:09:24.956558 IP 192.168.1.129.5149 > 239.192.104.1.netsupport: UDP, length 118
[root@vserver0 ~]# 

So, I seem to have generated multicast traffic and ensured that a member of the multicast group actually received it.

According to RedHat (http://sources.redhat.com/cluster/doc/usage.txt): "CMAN can be configured to use multicast instead of broadcast (broadcast is used by default if no multicast parameters are given)." They also go on to say that you must enable it in /etc/cluster/cluster.conf:

<cman>
    <multicast addr="224.0.0.1"/>
</cman>
<clusternode name="nd1">
    <multicast addr="224.0.0.1" interface="eth0"/>
</clusternode>

SELinux: the basic idea and how to debug

SELinux stores file context as objects which you can see with the -Z flag to ls or ps. Try to cp '/etc/hosts /home/$USER' and then 'mv /home/$USE/hosts /var/www/html' after editing it. The home context will stop Apache from serving the file. You'll see an error in /var/log/messages with what sealert options to run to see exactly what was blocked and how to fix it with restorecon.

Update: 11/24/10

Correction: A lot of the time restorecon won't fix it. Instead you'll need to change it with chcon. A typical example is when SELinux and Apache have a disagreement because you want to serve from a directory besides /var/www/, say /mnt/webapps/subversion for example. Even if you configure your httpd.conf to tell it that /mnt/webapps/subversion is a valid web directory it doesn't seem to work for permissions related reasons. The way to check this is to run:

ls -Z /var/www/html/
ls -Z /mnt/webapps/subversion

and see if you notice a difference. One difference that might been seen is the following:

unconfined_u:object_r:httpd_sys_content_t:s0
unconfined_u:object_r:mnt_t:s0

An easy way to fix this with chcon is:

chcon -R -t httpd_sys_content_t /mnt/webapps/subversion/