Philip Ratzsch: May 2008 Archives

Last week was the first Rackspace developers conference. While the majority of the people that attended were employed as software developers, a handful weren't. I was one of three people from network security who attended, and as the picture below shows, I apparently was fascinated.

Lessons learned:

• SyncML is really, really, REALLY clunky.


• Twisted Python tries WAAAAY to hard to be Erlang.


• Build your systems for scalability from day one.


• Stay the hell away from Courier when setting up mail.

Lessons Confirmed

• Nope, I still don't like Python.


• Keep the UI separate from the rest of the code.


• It has been confirmed once again that yes, Erlang rules.


• Ruby's method_missing is pretty bad-ass.


• People are terrified of things they don't understand.

After recently installing Ubuntu 8.04 on one of my boxes, I have only two complaints.

1) The laptop I have apparently has the only unsupported Atheros wireless chipset in history (AR242X).

2) Every two or three minutes, an error shows up in /var/log/auth.log (username removed):

May 13 21:26:03 neon sudo: username_removed : TTY=pts/3 ; PWD=/etc/pam.d ; USER=root ; COMMAND=/usr/bin/vi common-password
May 13 21:26:03 neon sudo: PAM unable to dlopen(/lib/security/pam_smbpass.so)
May 13 21:26:03 neon sudo: PAM [error: /lib/security/pam_smbpass.so: cannot open shared object file: No such file or directory]
May 13 21:26:03 neon sudo: PAM adding faulty module: /lib/security/pam_smbpass.so
May 13 21:26:03 neon sudo: pam_unix(sudo:session): session opened for user root by username_removed(uid=0)
May 13 21:26:03 neon sudo: pam_unix(sudo:session): session closed for user root

This message also appears whenever you sudo anything, filling up the auth log and making it virtually impossible to quickly skim through it and see meaningful messages. The error appears to be related to an auth mechanism that comes pre-enabled for SAMBA. Why that would come pre-enabled is beyond me, but the fix appears to be relatively simple.

In /etc/pam.d/common-password, find the line that says:

password optional pam_smbpass.so nullok use_authtok use_first_pass

...and comment it out. Next, find

auth optional pam_smbpass.so migrate

...in /etc/pam.d/common-auth and comment that out as well.

Done and done. Enjoy your minty-fresh auth log.

I'm studying for my CCNA and while reading a section dealing with how switches learn MAC addresses, a thought occured. The left 24 bits of a MAC is a code unique to each manufacturer while the right 24 bits is a series of bits that manufacturer has never used before (in theory - in large enough runs, you'll get some dups).

I had always assumed that if you connect two NICs with the same MAC to a port security-disabled switch the first one to be learned would be the one to receive all the traffic. My logic was that when the switch was checking it's lookup table to see to which port MAC "X" was connected, it would see the first entry, stop looking, and send it the data - X' I thought would never actually be seen in the lookup table, since presumably the switch would stop looking when it found X.

Which brings me to a tangential subject: I propose that people who use the phrase "It was in the last place I look" should be deported. It's yet another phrase with no actual meaning behind it; most people stop looking when they find something, so naturally it's going to be in the last place you look ("Honey, I found the keys but I'm going to check the couch and the front porch and make sure they're not there!"). Anyway...

The effect, I presumed, would be a 'ghost sender' throwing frames at the switch but never receiving a response. As it turns out, the switch is smarter than that (I didn't REALLY think the people at Cisco hadn't thought of that, it was just an idea).

Each time a frame is received by the switch, it apparently re-learns the MAC. When X sends something via port Fa0/1 the switch says 'Oh okay, you're on Fa0/1 - let me write that down'. Then when X' sends a frame via port Fa0/2 the switch snidely quips 'Wow, you get around, you port-hungry devil, you!' and re-learns the MAC. This is of course, assuming that switches are capable of 'quipping' (the latest research suggests they are - I know they can be snidely).

After that happens, let's assume that the traffic in response to the request X sent earlier shows up. The switch (being worried that the traffic was out that late) says "Where were you, Series Of Bits?! This is not a hotel! Go to your room it's right..." - the switch examines the lookup table - "...THERE!" and gestures angrily at port Fa0/2.

Series Of Bits, obediently goes to port Fa0/2 to find a very surprised X'. X' looks at Series Of Bits with a visage similar to when you haven't ordered a pizza and one shows up anyway. "Anybody order a series of bits??" it hollers. "Yeah, says Thomas J. Program, peaking head through the NIC's door. "But not THAT series of bits."

Meanwhile, poor, poor X is waiting for a Series Of Bits that never comes. We can only assume it begins to cry. The point of all that (other than that I'm CLEARLY single if I had the time to write all that) is that when two identical MACs are connected to the same switch bot experience seemingly abruptly random traffic as the switch learns and re-learns the MAC. Why the hell didn't I just SAY that? Because I was bored. But now I'm not.

Note: I was tempted to give the NICs a Brooklyn accent and make a "New York NICs" joke, but decided against it. You can thank me in US Dollars.

I mentioned in the last entry that Jan Lehnardt was also talking about gen_server, and his article is now up:
Read it here.