Useless forum comments

I just remembered that I wanted to gripe about something that always bugs me.  A few days ago when I was trying to find out why Telnet and LDAP weren’t playing nicely together, I came across a few forums where folks were asking questions regarding the same.  I never found any answers to those questions in the forums.  While some people actually tried to help, there were also the dolts that posted things like “Why are you running telnet?  Telnet’s not secure!”  REALLY?  Thanks, genius!  Now are you going to tell me drinking and driving is dangerous?  Please do, because I’m too stupid to figure it out for myself.  Look, if someone asks a question, what is so friggin’ hard about giving an answer if you have one, or keeping your trap shut if you don’t?  “You should be using SSH.  Telnet sucks.”  We all know that.  Jeez.  Why someone is using Telnet is no one’s business.

Telnet and LDAP on CentOS 5.2

Having trouble getting telnet to work with LDAP?  Getting errors like “login: pam_succeed_if(remote:auth): error retrieving information about user” and “User not known to the underlying authentication module” in your logs?  Are you able to connect and authenticate only to be greeted with “Connection closed by foreign host.”?  See what version of nss_ldap you have.  It seems that nss_ldap-253-12 doesn’t correctly work with LDAP/telnet.  I downgraded my CentOS 5.2 box to nss_ldap-253-5 and it worked like a charm.  Try that and see if it works for you.

My quest was clear

I had to set up IBM’s Rational ClearQuest for use with some of the Software Engineering courses. The most difficult part of the whole installation? The installation! I downloaded ClearQuest 7.0.1 from IBM’s web site and burned a DVD. They don’t provide an ISO, just a zip file. Unzip it and there you have the disc contents. So, I burned a disc and tried to install from the disc. About halfway into the install it would prompt for disc 2. Huh? What disc 2? Long story short, I finally got it to install by copying the files to a network share. Then I ran setup from the share. That worked, though I’m not really sure why that worked and installing from the disc didn’t.

After that, the installation was pretty straightforward (I followed the install doc). The only other problem I had was creating new users with the ClearQuest user manager. I created users with the admin account, but the users then were not able to log in. The databases were updating whenever I made changes to an account, so I couldn’t figure out what was going on. Turns out that, for some reason, if I gave the user a password when I created their account, the password didn’t work. However, if I gave them a blank password they were then able to log in and create their own password. I did not see that addressed in the documentation anywhere, so I don’t know if I had simply done something wrong, if it’s supposed to be like that, or if it was some other problem. I haven’t checked anywhere online to see if anyone else had the same problem. Now that I figured it out I don’t really care. :D

Downloader.Zlob.fa

I was working on a friend’s computer and came across this one. It also goes by Trojan.Zlob. Neither AVG Anti-Virus/Anti-Spyware could remove it correctly, nor could Ad-Aware. I finally had success with Symantec. The problem was a file called mscornet.exe. It this case it had been placed in %systemroot%\system32, and the following registry entry was executing it when Windows started: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\run “wininet.dll=mscornet.exe”

mscornet.exe also creates a .tmp file in system32. The name is randomly generated but seems to always follow this convention: ld*.tmp. Boot the computer to safe mode and delete these two files, along with the registry key and the problem should be eliminated.

Nagios

It turns out that the Nagios docs were right on about the quickstart being quick and easy. I have it monitoring three systems now, and will work on it some more on Monday. I didn’t really have any problems with anything. I had to diddle with commands.cfg a little, though. Seems that check_ldap is included with the distribution but it isn’t configured in commands.cfg. I also initially got a bind error. I use TLS for our LDAP server, and as usual, it was a certificate issue. You have to make sure that the $HOSTADDRESS$ check_ldap is using is identical to the host name in the certificate. I wasn’t using the FQDN of the host (just the short name) and it didn’t work. It was simple enough to fix: $USER1$/check_ldap -H fully.qualified.host.name -b dc=I,dc=won’t,dc=say -T $ARG1$. Alternatively, you can use the FQDN of the host in the host’s .cfg file when you define it. Then you can use the default $HOSTADDRESS$ after -H.

Here we go

This is my first post. I’m going to start working on a test installation of Nagios this evening. The docs claim that I can have it up and running on a local machine in 20 minutes. We’ll see how it goes.