May 2006 Archives

Chris Josephes

AddThis Social Bookmark Button

Related link: http://castlecops.com/t156126-Everyone_Please_Uninstall_your_Frog_Immediately.ht…

Since the BlueSecurity project has been shut down, users of the BlueFrog software are recommending that all other BlueFrog users shut down the application and remove it from their systems.

According to the annoucement, if an attacker could trick the clients into thinking it was the BlueFrog master server, that server could compromise all running clients.

I haven’t been able to find any specifics, such as what network ports BlueFrog uses, or how the protocol works. Some webpages for BlueFrog clients have already been taken offline. I’m assuming that if there is a threat to the client, then there was no encryption or host verification performed during normal BlueFrog communications.

Brian K. Jones

AddThis Social Bookmark Button

I’ve seen people describe LDAP as being a database enough times to get really annoyed, and finally, to blog about it. So here, in no particular order, are all of the reasons why LDAP is not a database (er, that I can think of):

* The “D” in “LDAP” stands for “directory”, not “database”
* The “P” in “LDAP” clearly indicates that LDAP is, in fact, a “protocol”.
* LDAP has no notion of rows, tables, or other database elements.
* LDAP has no notion of relational integrity (ie, foreign keys)
* SQL is useless when run against an LDAP server.
* LDAP data is a hierarchical collection of objects, not a linked collection of relations.
* There are no cascading deletes.
* You cannot write a stored procedure or trigger to help maintain LDAP data.
* Attributes of a given LDAP element can essentially be infinitely multi-valued without penalty.
* Individual attributes can be restricted in LDAP. You cannot do the equivalent (restricting access to a single field) in a database (to my knowledge. Post links if that’s wrong).
* LDAP, as a general rule, uses standardized schemas to describe objects. I have not seen a standardized database schema. Ever.
* LDAP objects and attributes are defined using ASN.1 syntax. Similar to SNMP (another protocol), and not similar to a database.
* Your email client is probably ready and willing to look at an LDAP directory to autopopulate its addressbook data. To my knowledge, the same cannot be said of a database.
* You can put “ldap” in your nsswitch.conf file. You can’t put “mysql”.
* Two words: “spin lock”

There are plenty of other examples to point to here. Also note that I’m not saying that things are technically impossible. You could probably develop standard data schemas for mysql, and then develop an nss_mysql module for your systems to use. However, this would not make LDAP any more similar to a database.

Tom Adelstein

AddThis Social Bookmark Button

I could consider a variety of titles for this short article. For example, we could call it “Stupid, the Internet isn’t the sum of all information technology”; or “Have you really stopped thinking about your Local Area Network?”; or “Have you ever heard of mainframes?”. I expect you get the gist of the topic.

My latest adventure with local networks came when I had to do a refresher on setting up and configuring OpenLDAP. I hadn’t done one since the publication of “LDAP System Administration” in 2003. Thank goodness for Gerald Cater. He did a splendid job of reminding me about installing and configuring directories.

Right now, I have the task of setting up an OpenLDAP directory. Since I have used Debian as the underlying OS, everything I need comes right off the default /etc/apt/sources.list. I don’t have to compile everything from source and I have the Debian applications database to help me maintain my “directory” of installed packages. I’ll leave off the discussion of the pros, cons and other ways of keeping track of what one has installed on his or her server.

I began working with LDAP directories around 1998 when the FAA contacted me about setting up several DEC’s Alta Vista directories servers around the US/Globe. The problem at the time dealt with distributing directory trees. We didn’t have LDAPv3 or the corresponding RFCs. We encountered some serious challenges at the time trying to bind different directory objects to one another on different servers.

Reacquainting myself with basic LDAP brought back a flood of memories. I even correlated relearning LDAP with such things as attempts to regain proficiency in some foreign languages I studied over the years. Truth be known, much of what we gather in the course of our work lives in our short-term memory. We study, get it down and move to the next subject. Once I installed and configured LDAP, I went on to something else. It reminds me of being in Cancun one time and while trying to remember the word for butter at breakfast, I told the waiter to bring me a butterfly.

Which brings me back to the central subject of this article. System administrators have to babysit servers and users. While we might wind up babysitting servers on the Internet, we can’t leave the many areas of our skill set in short-term memory. We should all remember that the bulk of our tasks usually involve users. We wouldn’t practice this profession without the internal clients.

In researching job ads for Linux administrators I noticed that NFS, LDAP, SAMBA, application and database servers, with an emphasis on automation and monitoring dominated the qualifications for many administrators with DNS, LDAP, FTP, SMTP, Postfix/Sendmail, etc. accompanying the requirements. While other requirements existed in those ads, most of them had to do with Soft skills like functioning as a liaison with other internal support groups such as Change Control, Application Development, Engineering, Databases Administrators, Web Services, Storage, Intel (Intelligence), Operations and Command Centers.

So, consider this a reminder. The Internet fascinates many of us. But, if we want to make a living in this business, we should remind ourselves of the cold hard reality of network troubleshooting, escalated service desk support, technical support, on-call consulting advice for the hardware and operating system environments, etc.

Anton Chuvakin

AddThis Social Bookmark Button

I wanted to highlight something very releavent for most sysadmins: SANS Log Management Summit, that will happen on July 12-13, 2006 in DC. The summit is subtitled “What Works in Log Management for Compliance, Operations and Security” and, from what I know, promises to be a very fun event!

Chris Josephes

AddThis Social Bookmark Button

Related link: http://www.visi.com/~cpj1/code/log_rp.html

One thing I’m working on this summer is finishing up a couple of personal coding projects I left dangling for the past few months. This week, I decided to release the mod_log_remote_port module for Apache.

It started out as a code patch to mod_log_config that I wrote about in an O’Reilly article. This week, I took it and turned it into a standalone module. It has been tested as both a static and shared library build, but I’ll admit that it’s been about 2 years since I’ve really had to crank out C code in significant quantities.

If you need it, test it out and let me know how it works. It might be better in the long run to submit this as a code patch to Apache, so I may convert the whole thing into a bug report.