I Love You, Daddy

1 Jul 2009

Nadia has been able to say, “love you,” for well over a year now. Of course, it’s always a great feeling when she tells you that she loves you, even though it’s usually said in return. Last night, when they arrived at home, I could hear Nadia on the other side of the door calling, “Daddy? Daddy?”. I opened the door and Nadia walked in. She smiled and reached up to hug me. I lifted her up for a hug and she said, “I love you,” as she threw her arms round my neck. No prompting, no suggestions; just a daughter wanting her Daddy to know how she feels.

I’m still smiling.

An Auspicious Datetime in UNIX History

13 Feb 2009

Today, the UNIX timestamp will be 1234567890. You can see for yourself:

$ date -d '@1234567890'
Fri Feb 13 16:31:30 MST 2009


openSUSE 11.0, KDE3 and lib64/

5 Jul 2008

After installing openSUSE 11.0 on my HP Compaq 6715b notebook, of course, I wanted to be able to use my bluetooth mouse. I setup the installation with KDE4 and without KDE3 support. Logging in via KDM and using KDE4 wasn’t a problem, but the KDE4 version of the bluetooth integration and configuration tools are not quite ready yet. It would appear that Novell hasn’t included it in their release. Not to worry, the KDE3 tools can still be used successfully to configure bluetooth devices and/or connections.

But, kinputwizard wouldn’t run. I would get:

# kinputwizard
kinputwizard: error while loading shared libraries: libkbluetooth.so.0: cannot open shared object file: No such file or directory

So, I thought I’d try it under KDE3. After installing KDE3 support that I had omitted from the original installation selection, I tried to log in with KDE3. No go. It wouldn’t run KDE3. Needless to say, this could be frustrating, but I thought of it as another clue.

I found the “missing” library in the kdebluetooth RPM:

# rpm -ql kdebluetooth | grep libkbluetooth.so

So I took a look at the /etc/ld.so.conf file:

include /etc/ld.so.conf.d/*.conf

Ah, the /opt/kde3/lib64/ directory is missing from the list, so I added it and ran ldconfig (as root, of course). I then tried to run kinputwizard again and it works. I haven’t tried logging in under KDE3 (I’m in KDE4 as I write this), but I’m sure it’ll be much happier, now. Still, I’m going to remove as much of KDE3 from the system as I can.

DNS Server Problems with Cisco 675/678 NAT

21 Jun 2008

While working on some DNS and web server configurations today, I discovered a bug (in my opinion) in he way that NAT is implemented in the Cisco 678 DSL router. From what I’ve read, it occurs in the 675 as well. I suspect that this bug would be found in all CBOS based devices.

My Cisco 678 is connected to a Linux server which provides firewall, proxy, DNS, DHCP and a bunch of other services to my internal network. There’s not much more than DNS which is visible to the outside world. I found that DNS requests for A records (address lookups) from the outside world coming through the Cisco 678 to my DNS server would always get the IP address of my DSL link and a TTL of 0. Other record types seemed unaffected (though, I never tested most RR types).

After some fiddling around with my DNS server, I realized that it was returning the right information. In other words, the data was being alteredchanged in transit. Since I am using NAT on the Cisco 678, I decided to look into the possibility that something was wrong there.

It turns out that the CBOS NAT implementation does not just translate IP addresses in the IP header, but will look at the entire payload of an IP packet, substituting it’s IP everywhere. Since the format of the IP address in a DNS response is the same as what is found in a nIP header, they were being translated on the way to the outside of my network.

A quick Google Search yielded a workaround, which I’ll describe here.

The Cisco 67x CBOS NAT implementation will not translate payload addresses if the packets are not on port 53. So, simple change the port to something else (like 5300) in a NAT entry, and your DNS lookup responses won’t be messed with. The syntax of the CBOS command to do just that is:

cbos#set nat entry add 5300 53 udp

In the workaround I found online, they never address the use of DNS over TCP. It doesn’t happen much, but it is possible for DNS requests to come over TCP rather than UDP (this usually only occurs for zone transfers and when a request produces such a large response that a single UDP datagram is too small to carry the answer back).So, I also ran:

cbos#set nat entry add 5300 53 tcp

After implementing the workaround, it didn’t work. I deleted the NAT entries from my Cisco 678, re-created them, wrote the memory, rebooted it at which point it started working for me. During this process, I also kept tcpdump monitoring for the traffic I wanted to see between the DSL router and my firewall box.


10 Jun 2008

Lamont’s Monitored Network Objects Protocol (a.k.a. LMNOP). Has a nice ring to it, don’t you think? OK … I’ve been thinking about the sucky things with SNMP, the Simple Network Management Protocol. One of the bigger problems, in my not so humble opinion, is the compleet lack of any security. I know, you can use the Community Strings to specify what people have access to. Several problems abound with this approach, but it boils down to a complete lack of basic security:

  1. No encryption; you just can’t do it.
  2. No authentication; you couldn’t do it securly, anyhow.
  3. Access control via publicly visible group-shared, non-credentialed ID; In other words, anyone on the network can detect the community names that are in use and then use them and there’s never going to be any way to stop them.
  4. In some cases, the ability to manage can not be disabled; this is a huge security hole.

Now, in defense of SNMP, one could use your firewalls to control packet flows and funnel them only towards the workstations you want. Though this can work in fixed environments, our network are becoming more and more fluid, dynamic and mobile every day, making this approach extremely difficult to maintain, at best. Another approach, often used in the real world, is to confine SNMP traffic to an issolated "management network", a physically separate network segment that is not interconnected with the rest of the network. One problem with this approach is that not all devices that one might want to monitor/manage have the ability to confine their SNMP activity to a particular port, especially those devices that aren’t network switches. SNMPv3, does have a user based access control mechanism (see RFC3414 (Standard 62) — User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)), which does include provision to encrypt authentication related messages and an ACL mechanism RFC3415 (Standard 62) — View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)). These security features are an improvement, however, only DES (in CBC mode, which is good for DES) is available for encryption. There is no cryptographically strong message integrity, either. Nowhere in the rest of the SNMPv3 RFCs RFC3411(, RFC3412, RFC3413, RFC3416, RFC3417, RFC3418 and RFC3584), is there any mention of any better encryption or cryptographic protections. At the very least, the lack of adequate protection in the user authentication process is a security hole so large as to render all security mechanisms in its design useless. At worst, people using RFC3414 authentication could have a false sense of security and expose extensive details about the operations (as well as full administrative control) of their infrastructures to anyone who can transfer packets in their network. The long and short of all this? I simply avoid SNMP in almost all situations. You can’t make it secure for managing anything and most of the benefits of SNMP, except one, can be acheived in other ways with most devices. The one exception is that SNMP is one, central way of dealing with lots of stuff. The protocol has been around for a long time and, of the top of my head, I don’t know of any vendor’s SNMP capable device that is not compatible in some way. Thus, I’ve often thought a little about how we might improve SNMP. In the past, I’ve decided that it would have been much better if SNMP had originally stood for Simple Network Monitoring Protocol. Most of the security concerns would simply disappear. If we "remove" the management or write capabilities from the SNMP specification, then we would have just such a monitoring protocol. But that will still leave us with some pretty ugly security concerns, not to mention confusing people if we still called it SNMP. So, here’s my list of desirable features:

  • Encryptable
  • Authentication & Authorization Service
  • Monitoring Output Configuration
  • Multicast and/or Unicast
  • Mixed use of TCP and UDP

Once a protocol like this is standardized, we could build upon it to create SNMPS (or SSNMP?), a secured form of SNMP for management operations. I think it shouldn’t have the monitoring elements, as LMNOP would cover monitoring. In that case, devices and applications which want to use both monitoring and management features should implement support for both LMNOP and SNMPS. There might be a new RFC to write for this idea. I’ve never done that before. Perhaps I will. Whether I do or not, I thought the acronym was worth writing down.

‘leet’ Mail Server

28 May 2008

I thought it was a little bit funny to find this in today’s logwatch email from one of my servers:

——————— postfix Begin ————————

7118055 bytes transferred
1337 messages sent
1337 messages removed from queue

When maildrop Fills a Log File

30 Apr 2008

I hadn’t bothered looking at my personal email accounts since last Saturday. This evening, I was surprised to see that it looked like I wasn’t receiving emails for my OpenBrainstem or lamontpeterson.org addresses. The last messages had come in sometime late Sunday morning.

First thing I did was to log into the mail server via SSH and run:

# mailq | grep '^[0-9A-F]' | wc -l

Well, that’s a wee bit of email. So I tried running this command (sorry, I didn’t capture that whole output):

# mailq | head
. . . output omitted . . .

The message I saw over and over again showed “(temporary failure. Command output: maildrop: signal 0x19)“. A quick Google search and the first link told me what I needed to know; when the log file that maildrop is writing into reaches over 50 million bytes (not 50MB, but 50MiB), it stops processing requests. Though the link Google found for me indicated a setup with one central log file, I’ve discovered that the same thing happens when you have per user log files, like I do. This line from my /etc/maildroprc file shows what I mean:

logfile "$HOME/mail/.maildrop.log"

So, I fixed it by truncating (or, in other words, emptying) my own user’s log file. Of course, I first checked to make sure that it was the culprit:

# ls -l ~lamontp/mail/.maildrop.log
-rw-------  1 lamontp lamontp 714630 Apr 30 20:37 /home/lamontp/mail/.maildrop.log
# >~lamontp/mail/.maildroprc

Sweet Kisses

24 Apr 2008

For the past two evenings, Nadia has laid on my shoulder while rocking just before placing her in her bed for the night. I asked her for a kiss and she has obliged by sitting up, looking right at me, then beding down to place her lips right on mine.

Her mother, however, is a little frustrated (not really) that she isn’t getting kisses from Nadia when asking for them. Six weeks ago, when Nadia first started kissing us on the lips regularly and of her own volition, it was Mom who would get the kisses and Dad who was left, “out in the cold.”

Another reason this is particularly nice, is that Nadia has been sick for the past few days. This is partly because about 5 teeth decided to push in all together, of which, I think 3 are molars. Today was about the worst it’s been for her, too. However, she is still so very sweet and understands that going to bed is a good thing for her. She has points to her bed to let us know she is ready. We still have to rock her completely to sleep for naps, but at night, she willingly falls asleep on her own.

Davis County Convention

12 Apr 2008

The 2008 Davis County Republican Party Convention is over. Of the eight candidates (including myself) who were running for the Senate District 23 seat, only two remain, and will face each other in a primary election. Those two cadidates are Dan Liljenquist and Ronald Mortensen. You read that right, I’m out of the race.

It was a lot of fun for me. I regret that there was so little time (merely 17 days) between the caucauses and the convention. This made it nigh on impossible to speak with the bulk of the 270+ delegates who voted in my race. It didn’t help that I fell ill and lost a little over a week’s worth of working time to it. Several friends were trying to put together “Meet the Candidate” events for the delegates in their areas, but with so many people getting sick and everyones’ busy lives, they were never able to get things together.

I met many good people, made associations that I will treasure for years to come and thouroughly enjoyed talking with people about a wide variety of issues.

One question that many have asked me, of course, is, “When and where will you run again?” The answer is that I will probably run again. Exactly where and when I do not, yet, know. I learned a lot from this first experience and will, hopefully, be able to better prepare for a future race.

It was certainly a worthwhile experience. Many, many people have expressed their appreciate for my speeches and discussions. I know that even though I am no longer in the running, that I had a profound effect on the race and on a great many persons’ viewpoints. That is a very rewarding and humbling feeling for me. I am very grateful to all those who have supported my effort.


26 Mar 2008

First of all, we must always keep in mind that there is no such thing as a free lunch.

Taxes are necessary. It is, however, the responsibility of the Government to ensure that taxes do not over-burden the taxed, whether individual or business.

I believe that there are far too many taxes in Utah. It costs money to collect the vast array of different taxes. It is a burnden to business where the costs of ensuring that proper compliance and payments have been made often exceed the amount of tax paid.

Our Government needs to reduce and simplify the tax system to something comprehensible, economical to administer and fair to all.