Often I find myself in the position of setting up a Linux-based service (like an Apache-based service, for instance) that needs to make LDAP calls to somebody’s AD userbase.  And um… “…plaintext is bad, m’kay…?”

So setting up a Linux-based service to make LDAPS calls (that means encrypted LDAP, by the way) to an AD server has a kind-of strange “gotcha” at first, since AD itself is not actually set up out of the box to service LDAP over SSL/TLS correctly in the first place. You have to make it work before you can query it.

To that end, herein I will provide the steps necessary to get that encrypted LDAPS working on AD; and since this is a Linuxy blog, we’ll call to it and test it from my Opensuse laptop.  However, these are pretty standard commands that should work on any distro.  Let’s get to it….

First, you must get the AD Root CA cert.  If you’re like most people, the AD CA is a private/internal one (not a public one from a big-time vendor like Verisign, Thawte, etc.).

Verify/install the Certificate Server “Role” in AD on the DC if it is not there already.  If you have to install the role/service for the first time, a reboot will be necessary (mandatory actually, though it does not tell you) to cause server certificate to be requested/generated/installed.  Then, you need to export the Root CA certificate.  Here’s how to do that:

1. Click Start, Administrative Tools, Certification Authority
2. Right-click on your CA, and select Properties
3. In the CA Properties window, click on View Certificate
4. In the Certificate window, click the Details tab and click Copy to File
5. In the Certificate Export Wizard window, click Next
6. Select Base-64 encoded X.509 (.CER), and click Next
7. Enter the export name (e.g., c:\corpRootCa.cer), and click Next
8. Click Finish
9. Now copy certificate to the Linux server using whatever method you please (samba share, filezilla, etc.), for example to /home/jpavlov/RootCerts/corpRootCa.cer

Second, you have to edit the ldap configuration file on your Linux box, so the ldapsearch tool knows how to behave:

vi /etc/openldap/ldap.conf

…and add this line to match where you stored the CA cert in step 9 above:

TLS_CACERT /home/jpavlov/RootCerts/corpRootCa.cer

…there are other lines/options you can add, but this is all you need to get it working.  Also, you can only have one active TLS_CACERT statement in the file at a time, so if you plan to use it with other CAs, make sure to comment the others out for now.

Third, make sure the LDAP server name is resolvable.  The hostname presented in the subject certificate must MATCH the name you use in the query; therefore, it obviously must be resolvable in order to work.  If you have all the relevant hostnames in DNS (as you might in a standard AD environment), you can move on to the next step.  For me, I’m not using DNS in this case, so I edit the hosts file.  For example:

vi /etc/hosts
10.1.2.3 dc01.corp.com

Finally, make the query!  Remember, I repeat, that the hostname you query *must* match the certificate subject. Here’s an example:

ldapsearch -x -H ldaps://dc01.corp.com -b dc=corp,dc=com -D "cn=Administrator,cn=Users,dc=corp,dc=com" -W "mail=*" mail

…and that should do it.  That’s enough to get you started.  But I think that in the coming weeks I’ll toss in a few more caveats and goodies about making LDAP/LDAPS calls to AD, since I can almost read your mind right now and anticipate the next questions you have, and the next limits/problems you’ll run into…

So now, I’ve put together a modernized version of that post.  This time, I’m using the latest version of Opensuse (11.3) and the freely-available Tripwire from SourceForge (2.4.2) at the time of this writing, to make it a little more universal; since this should basically work on many distros and versions.  Other than that however, I’m pretty much following the same style, method, and simplicity as my afore-mentioned earlier post;  I’m going for crude, fast, quick setup, without any in-depth Tripwire administration…  a “cheat-sheet”!  Let’s get to it…

Install software

Get supporting software from the distro:

zypper in gcc make libstlport_gcc4-devel gcc45-c++ gcc-c++

Get tripwire:

mkdir /tmp/tripwire
cd /tmp/tripwire/
wget http://downloads.sourceforge.net/project/tripwire/tripwire-src/tripwire-2.4.2-src/tripwire-2.4.2-src.tar.bz2?use_mirror=iweb&ts=1280546281
tar -jxvf tripwire-2.4.2-src.tar.bz2
cd tripwire-2.4.2-src

…now, compile and install to /usr/local (this is the default, which can be changed), according to the INSTALL instructions:

./configure
make

…Edit the settings as needed in install/install.cfg and run:

make install

…It will prompt you to create and use your “site” and “local” password.

Configure Tripwire

At this point, it has built keys for you, and created sample files for you in /usr/local/etc.  You need a “config” file and a “policy” file to use tripwire.

To build the configuration file, you can make a default plain-text configuration file, and just edit it to taste and move forward (you can change it later if needed).

vi /usr/local/etc/twcfg.txt

Then encode and sign the plain-text file and install it as the new configuration file:

/usr/local/sbin/twadmin --create-cfgfile --site-keyfile /usr/local/etc/site.key /usr/local/etc/twcfg.txt

A default policy text file is provided for you as well, and you’ll need to edit that to tune it to your system:

vi /usr/local/etc/twpol.txt

To encode that text policy file and install it as a working policy file for your system, build it like this:

/usr/local/sbin/twadmin --create-polfile /usr/local/etc/twpol.txt

Rock Linux Policy Generator (optional)

However, if you wish to use the “rock linux” policy generator:

mv /usr/local/etc/twpol.txt /usr/local/etc/twpol.txt.bak
cd /tmp/tripwire/
wget http://rocklinux.net/people/pjotr/package/tools/tripwire/mktrippol.pl
wget http://rocklinux.net/people/pjotr/package/tools/tripwire/rockadm.pl
wget http://rocklinux.net/people/pjotr/package/tools/tripwire/rockbasepolicy.txt
wget http://rocklinux.net/people/pjotr/package/tools/tripwire/twinit.sh
wget http://rocklinux.net/people/pjotr/package/tools/tripwire/twsite.pl

I had to modify the paths in the “Standard settings” section of the mktrippol.pl file to match my /usr/local installation.  It looked like this in the end:

my $security = 'normal';
my $basefn   = 'rockbasepolicy.txt';
my $twetc    = '/usr/local/etc';
my $twsbin   = '/usr/local/sbin';
my $twvar    = '/usr/local/lib/tripwire';
my $policyfn = "$twetc/twpol.txt";
my $prefix   = undef;

…Then, execute the mktrippol.pl perl script and it builds the policy file for you.  Again, edit it to make sure it is what you want.

Complete the configuration

Now, since you customized the policy, you need to re-bundle it:

/usr/local/sbin/twadmin --create-polfile /usr/local/etc/twpol.txt

To configure email settings, add:

emailto = "root",

…to each section after the “rulename” line…

Test your e-mail capability:

/usr/local/sbin/tripwire --test --email jpavlov@yourlinuxguy.com

Now, build the database file:

/usr/local/sbin/tripwire --init

…and it writes the db file here:

/usr/local/lib/tripwire/*.twd

If you get any errors, you can edit your policy update the db.  To tweak the policy file, open the plain-text policy file and edit to taste.  Then update your existing policy file and database file with your changes:

/usr/local/sbin/tripwire --update-policy --secure-mode low /usr/local/etc/twpol.txt

Now, run an initial integrity check:

/usr/local/sbin/tripwire --check --interactive

…and note that when you “save” at the end of the report viewing, you are acknowledging the notifications in that report, so that they will be silenced for the future.

There will likely be some false positives and other misc things that don’t match up.  If so, you’ll need to update the Tripwire policy text file (twpol.txt) again, and rebuild the policy file (you may need to repeat this a few times until you have it just right):

/usr/local/sbin/tripwire --update-policy --secure-mode low /usr/local/etc/twpol.txt

Then run a (hopefully) final integrity check:

/usr/local/sbin/tripwire --check --interactive

…which will catch the policy file change (if you made any in the previous step), then you’re done.

Create cron job (for example):

crontab -e

…and add something like this:

0 */5 * * * /usr/local/sbin/tripwire --check --email-report --email-report-level 1

…of course, since you’re modifying the crontab, you need to do an interactive check yet again, or you’ll get flagged on it…

…and that should do it!  You now have a functioning Tripwire setup on your system, that will email you every time a change is detected… You certainly will need to continually tweak the policy a bit as you go forward, as it will likely catch some logs and such.  But you are on your way !

A little while ago, I had to get a quick lab up with two redundant LDAP servers for application testing.  I had some Opensuse 11.1 32-bit VM images lying around, and I chose eDirectory, for ease of administration and setup in my short time available.  This is a quick way to get a high-quality, fault-tolerant free directory server on a free OS…

Of course, I happened to take notes (as I usually do), and thought I’d post them here for anyone who might be interested in doing the same.

In the following example environment, the two servers are “node1″ (192.168.6.11) and “node2″ (192.168.6.12), in the eDirectory tree called “NODETREE”.  The rest should be obvious…

First, install the required supporting library:

zypper in libstdc++33

Get the eDirectory files from Novell:
eDirectory_88SP5_Linux_i586.tar.gz

…and unzip it, and run setup:

cd /tmp/eDirectory/setup
./nds-install

Ignore this “unsupported” warning. If we could enter “Of course!”, we would, but we can’t. Just enter “y”….
%%% Warning: This is not a supported platform for eDirectory 8.8.5. Please refer to NOVELL Documentation for information on supported platforms. Do you want to Continue  '[y/n/q] ? '

You are prompted to agree to the license… …yes, you agree to the license….
Press “q” to quit viewing, and “y” to agree.

You are prompted to “Select the components you wish to install..”
Choose option 1 to install the server (or 1,2 for all). It will install needed packages.

Reboot.

Now edit the eDirectry “hosts” config file, since it is a closed environment.  I’m starting on node2 for some strange reason, so I add that as the address of the tree here:

vi /etc/opt/novell/eDirectory/conf/hosts.nds

…and create the following entry:

NODETREE       192.168.6.12

If you’re not using DNS in your lab, you might want to make sure all eDir servers are in the hosts file.  Either way, just make sure they are resolvable:

vi /etc/hosts

…and create the following entries:

node1       192.168.6.11
node2       192.168.6.12

Now run ndsconfig with the required parameters.  Here is my example to build a new tree with the first of two servers (again, mine happens to use node2 first, but either server is fine to build the tree):

/opt/novell/eDirectory/bin/ndsconfig new -t nodetree -n ou=Services.o=CORP -a cn=admin.o=CORP -i -S node2 -B 192.168.6.12

…and you will be asked for the new Admin password and the NDS (whoops, eDirectory) instance and DIB location.

Add the other server to that previously-created tree (after repeating the install procedures on the second server):

/opt/novell/eDirectory/bin/ndsconfig add -S node1 -t nodetree -n ou=Services.o=CORP -a cn=admin.o=CORP -B 192.168.6.11 -p 192.168.6.12

…and that’s it! You’re up and running, and ready for LDAP requests. Of course, you might want to create an OU for users (perhaps ou=users,o=CORP), and some users, etc., etc., etc…

But I do want to say from the outset:  It really is beautiful.

I had been running the 32 bit version of the “Release Candidate 1″ on a Lenovo R60 for a week or so, and was blown away.  When it was officially released, I put the 64 bit version on a Lenovo T500 and am even more amazed.

For the most part, it has the bones and muscles of Opensuse 11.2 underneath…  But at the surface of the skin, everything seems smoother, faster, quicker, prettier, easier… just better.

You see, I’ve been running Opensuse for years as a laptop OS, and my laptop is a mission-critical tool to my work as a consultant.  And pretty much on the day of each new release, I download and load up the Opensuse OS, try to figure out how to make iFolder and Jungledisk work, pull back my data, and then try to make the rest of my favorite apps work.  This time, the iFolder3.8 client (part of the distro these days) and Jungledisk installed and worked so easily, I was up in no time flat.

It looks like VMware Server 2x is going to be more of a problem though, given the new kernel version 2.6.34.x….  Maybe we can get Radu interested, although maybe not, since he seems pretty fed up with having to support all his awesome previous work.  Well, since it looks like VMware doesn’t seem to be releasing updates to VMware Server 2x anymore (or at least that’s the rumors I hear), maybe it’s time for me to move over to KVM for good this time…

In these steps outlined by Novell, you are required to manually retrieve the values from /etc/products.d/*.prod and individually install the special upgrade/migration packages for each listed product definition.  And that’s fine in a lab, but with a farm of servers and potentially more than one upgrade/migration type each (in my situation they were cluster/HA servers, so each had two items), this can be a bit of a bother.  So for added convenience, I wrote a little “for” loop tweak to take care of those manual steps.

Without further ado, here are the modified steps for the upgrade to SLES11 sp1 using zypper with my tweak (thanks again Novell, and please see the caveats below):

zypper ref -s
zypper up -t patch
zypper up -t patch
for item in `cat /etc/products.d/*.prod|grep '<product>'|sed s/\<*.product\>//g |sed s/" "//g`; do zypper in -t product $item;done
suse_register -d 2 -L /root/.suse_register.log
zypper ref -s
zypper lr
zypper dup

…and there are a few very important points to be made about the above steps:

• Do not run those steps as a continuous script;  step through it line-by-line, watching the results at each step.
• Make sure your registration keys are all up to date and your repositories are in good shape before starting!  This is especially important and complex if you are using the HA extension or other custom add-on products that require registrations and repositories.
• In my experience, I sometimes needed to re-check and repair my repositories after the first or second “patch” statement, and sometimes before the “dup” statement; I do not know why.  Even Novell’s doc suggests that there may be complications.
• Afterward, you might want to go in and run the yast customer center registration tool, and allow it to clean itself up.

I hope that helps!

I needed to monitor a network device (an appliance, actually) constantly and rapidly, to see if the interface was flapping up / down.  So, we settled on one ping per second, with a one-time email notification when it drops, and a one-time notification when it returns.

Below is that script;  all you have to do is copy the contents into a text file (watch out for line wrapping), change the “PINGDEST” and “EMAILADDRESSES” variables, flag it as executable (chmod 700 <scriptname>) , and you should be good to go!

#!/bin/bash

PINGDEST="192.168.1.12"
EMAILADDRESSES="jpavlov@yourLinuxGuy.com,questions@yourLinuxGuy.com"
BITFLAG=0
SENTMAIL=0

while true
do
   /bin/ping -q -c1 -W1 $PINGDEST > /dev/null 2>&1
   PINGRESULT="$?"
   if [ "$PINGRESULT" != "0" ]; then
      BITFLAG=1
   else
      BITFLAG=0
      sleep 1
   fi
   if [ "$BITFLAG" == "1" ] && [ "$SENTMAIL" == "0" ]; then
      echo "Ping to $PINGDEST FAILED! Generated by $0 on $HOSTNAME" |mailx -s "Ping failure to $PINGDEST"  $EMAILADDRESSES
      SENTMAIL=1
   elif [ "$BITFLAG" == "0" ] && [ "$SENTMAIL" == "1" ]; then
      echo "Ping to $PINGDEST resumed. Generated by $0 on $HOSTNAME" |mailx -s "Ping responding again on $PINGDEST"  $EMAILADDRESSES
      SENTMAIL=0
   fi
done

A goofy, single-purpose script, to be sure; but you never know, maybe it will help someone…

I don’t know about you, but the last thing I want to have to do during a server OS upgrade is drive all around the state to go hit “enter” on a console or something.  If I can’t do it remotely, I don’t want to do it!  So my intention here is just to document a possible remote upgrade method, clean up some typos, and so forth.  Please note that I have followed this procedure a good handful of times, and have had great success with it so far.  If you follow this procedure, make sure to drop a comment and let me know how it went.

And for heaven’s sake, if you don’t know what you’re doing, don’t do this!  Read it all through first, maybe test on a demo machine, etc…  Also, I hope it goes without saying that you’ll probably want to make use of the “screen” utility to do all this work…  More on screen another time…

Anyway, back to the task at hand…

First, patch your OES2-SP1 system completely up-to-date with this:

rug up -t patch -g security -g recommended OES2-SP1-Updates SLES10-SP2-Updates

…but watch out for being prompted for the move-to-sles10-sp3 issue !!  Reboot as needed.

Now a quick aside or two, right in the midst of things… If you have a crazy, complicated admin password, change it temporarily for this process.  Set it to “changeme”, or “temp123″, or anything without special characters.  You’ll thank me for it later, and it will work better when you create the “answer” file.  Also, please remember that if you have an SMT server, make sure to prepare the new channels you’ll need.  Oh, and if you have custom installation sources (like and ftp server or webserver with ISOs mounted on it or something), they’ll be useless in a few minutes anyway, so you may want to delete them now…

Then, assuming all patches are up to date, your server codes are valid, etc., etc., the first step of the process is to get the “update” patch in place:

rug in -t patch move-to-oes2-sp2

…you should not need to reboot here.

Now the box is mid-way between versions.  We can see that it needs its versioning and control packages (those that define what version it is to be) with this command:

rug lu -t patch

So now we need to continue to turn it into an extremely un-patched OES2sp2 server, with this command:

rug up -t patch -g recommended

…and DO NOT REBOOT when prompted!  Because if you reboot now, you will need to physically be at the console screen to enter the eDirectory tree Admin password when prompted.  We don’t want that (unless you have HP Lights-out boards or something).  So, in order to create an answer file to automatically stuff the the Admin password in (remember, you changed it to something simple, right?), do the following:  In a shell session, as root,

cd /root

…to ensure the answer file is away from other users, since it will be created in your working directory.  Now create the answer file like this:

yast create-answer-file [adminpassword]

…of course, replacing “[adminpassword]” with your eDirectory Admin password.  Unfortunately, you must enter the password on the command line, then it re-displays it to you, so:

1. make sure there are no eyes on the monitor other than yours while doing this, and
2. I strongly recommend that when you finish this session, you log back in and vi /root/.bash_history and remove the line with the admin password (so other users don’t see it later!)

Now, copy it to where it needs to be:

cp answer /opt/novell/oes-install/

Now reboot:

init 6

When the server is back up and running, it will complete the update of all the OES-related services; this takes some time.  Once that’s done, you need to do a final round of patching with our brand-new updated channels:

rug up -t patch -g security -g recommended OES2-SP2-Updates SLES10-SP3-Updates

…and reboot if needed.  Oh, and some cleanup…  Delete the temp answer file:

rm /opt/novell/oes-install/answer

…And don’t forget to remove the answer file password line from your /root/.bash_history…  And change your Admin password again…

And as a final step, clean up your installation sources (yast inst_source) if you had custom ones. And you’ll also need to re-add your “Add-On” source for the OES software;  it’s a requirement.  So one way to do it would be to run “yast add-on” , and walk through the steps of adding the URL to the source, ensuring all the patterns are listed (they should all be set to “Reconfigure is Disabled”).

And that’s it!  If all went well, you should now have a fully upgraded server.  Enjoy!

Now I know that the first image in your mind when you read that is a blend of disaffected/bored and hyper/reckless teens running through the hall, or lighting stuff on fire, etc., right?  Wrong.  These students were well-behaved and attentive, and more importantly, inquisitive.  Of course, the bummer of the visit was that it was very brief (we *do* try to earn a living here );  and even though they were watched and guarded closely, we could not take them to where the really cool stuff is, due to security concerns.

Unfortunately, I could not attend the entire mini-tour since I was busy on other things.  But I managed to join the group at the end when summaries were being given and questions were being taken.  And to me, that was probably the coolest part anyway;  because once the students relaxed a bit and starting asking questions, we all started to get the sense that this group was really absorbing what they saw, and was truly interested in what they are doing.

They asked questions that ran the gamut; about the validity of technical certifications, resume writing, the prevalence of older technology still in the workplace as tech generations change, honesty, human networking, volunteering, and so on.  The small group of Cavalier employees clearly got a kick out of it, and it was over all-too-soon.

After they all left, I was left with a strange feeling…  I clearly did not realize how much I would enjoy interacting with students that are interested, and I was left thinking I’d like to do it more.  Hmm.  Maybe volunteer to be a guest lecturer in school technical classes?  Maybe get involved in community technology groups?  Hmm.  Hmm……

I want to thank Kelly R. and Terri W.  for bringing the kids… er… young adults… out for the visit.  And I want to thank the students for interacting, and making it fun;  remember gang, we all started somewhere, and you’ll all be well on your way if you apply focus and diligence.

It was a kick, and I really enjoyed it.

Of course, if the user *knows* his or her own password, he or she can use the “settings” link in the iFolder Web Access page, or the “Security” menu item in the client interface.

But if the password is UNknown, then you really have no choice but to do it on the command line of the iFolder server.  The problem with that, however, is that in order to do that on the command line, you’ll need to enter both the admin credentials and the user’s new credentials as well… which is never a good idea to do, since that will sit in the command history by default, etc.  Besides, who wants to memorize that crazy string anyway?

So, here’s a tiny little favor for you…  I stuffed it all into a tiny little helper script that you can have.  Just paste these contents into a script, do a chmod +x to make it executable, and away you go.  it will prompt you for admin password, username to change, and the new password for that user.

I hope it helps!  Here you go…

#!/bin/bash
clear
echo ""
echo "This is the user password change tool for iF3..."
echo ""
echo "Please enter the admin password: "
echo ""
read ADMINPW
clear
echo ""
echo "Please enter the username for which you are changing the password: "
echo ""
read USERNAME
clear
echo ""
echo "Please enter the new password for $USERNAME (careful with crazy special characters): "
echo ""
read USERPW
clear
echo ""
echo "Processing..."
echo ""
# For 32 bit...
/usr/bin/mono /usr/lib/simias/bin/UserCmd.exe setpwd --url http://localhost --admin-name admin --admin-password $ADMINPW --user $USERNAME --password $USERPW
# For 64 bit...
#/usr/bin/mono /usr/lib64/simias/bin/UserCmd.exe setpwd --url http://localhost --admin-name admin --admin-password $ADMINPW --user $USERNAME --password $USERPW
echo ""
# I know the exit codes from mono are of no real value, but oh well...
if [ "$?" -eq "0" ];then
echo "If the exit message reads: \"Failed - Invalid admin credentials\", the password for $USERNAME was not changed. "
echo "If the exit message reads: \"SetPassord for $USERNAME - False\", then $USERNAME might not exist in the system. "
echo "If the exit message reads: \"SetPassord for $USERNAME - True\", then the password for $USERNAME is now changed!"
else
echo "...The script encountered a problem! Exiting..."
exit 0
fi
echo ""
echo "...Done!"

I achieved the LPI Level 1 certification on 2004-01-30.

When I took the LPI-1 tests back in early 2004, they had a promise of perpetual certification.  They were the only certification I had heard of doing that.  Perhaps they later thought better of it, because they eventually removed that standard, and instead set time limits on all new certifications, and imposed an expiry (of 5 years after last certification) on all existing ones.  Of course, I do not begrudge them any of those later actions;  it is arguable that the highly relaxed initial standard was more than a bit short-sighted, and the result of an eager new organization.

I achieved the LPI Level 2 on 2005-04-09.

The LPI-3 didn’t exist back when I got the LPI-2…  back when I had lots of time on my hands.  When the LPI-3 was formulated, I watched it evolve, monitoring the news when I could, trying to hatch a plan when I could go get it.  It was released to the public in 2007.  I had heard the news that they were going to remove the “lifetime” certification, but then time just went by too fast for me to prepare for the LPI-3.  Life happens.  I’m not looking for sympathy, my life is great;  busy, and great…

During that window, it would not have made logical sense (in fact, it seems wasteful) for me to have re-taken one of the tests for an LPI level for which I was already certified in order to re-certify.  I figured there would be plenty of time.  But as the window was closing, I looked much more closely into the requirements, and realized I was un-prepared to take the LPI-3 test.  And due to the limited re-take policy, my limited resources, and the fact that I’m not the type to do things un-prepared, I declined to take the LPI-3 test(s) as the last days of my window passed.

My LPI-1 and LPI-2 certifications have been moved to an “inactive” state on 2010-04-09.

This is because of that aforementioned expiry, and the fact that I have taken not taken any LPI test (to re-certify) since I achieved my LPI-2 certification in 2005.  Again, I can’t blame them a bit.  It’s been a while, and they would like to maintain current, fresh standards.

But here’s the problem:  By rule (and yes, I confirmed with an LPI official), because I didn’t get completely certified as an LPI-3 before the threatened expiry, in order to achieve the the LPI-3 at this point I must re-certify at ALL LEVELS of the LPI.  This means that in order to be permitted to take and pass the tests for the LPI-3, I must re-take and re-pass all the tests necessary to re-acquire the LPI-1 (two passed tests) and the LPI-2 (two more passed tests), just to arrive right back where I was before 2010-04-09.

There is no tiered “grandfather” type clause.  There’s no “refresher”.  There is no “catch-up” or “make-up”.  Apparently, there is no sympathy for the additional effort, just time from the last certification…

As a result, it seems to me that the more time and money you invest in the LPI, the more you stand to lose in the event of expiry.

That’s not just dis-incentivization, it’s a smack-down.

Now I think I’m glad I didn’t get the LPI-3, because since there’s no LPI-4 now, my LPI-3 would be expiring shortly anyway, then I’d just have to do it all over again if they ever did make the LPI-4…

8|

The email message read like the following (names have been changed):

################# SSL Certificate Warning ################

Certificate for hostname 'www.yourlinuxguy.com', in file:
/etc/pki/tls/certs/www.yourlinuxguy.com.cert

The certificate needs to be renewed; this can be done
using the 'genkey' program.

Browsers will not be able to correctly connect to this
web site using SSL until the certificate is renewed.

##########################################################
Generated by certwatch(1)

The administrator had searched the Internet, and found mostly impolite messages from youngsters about reading the docs. Accurate, perhaps, but not too helpful.  This person’s server was not using a public Certificate Authority (CA); just a local one on the box itself (as is common practice in development environments).  If you don’t understand all that, it will make more sense as we go on…

First I want to clarify a couple things.  When you run the genkey tool, you are actually doing what the name suggests;  generating a new key pair (public/private), from which the certificate is formulated.  Technically, you are not *renewing* the certificate as the certwatch warning message implies, but that’s okay (it *is* possible in some situations to “renew” a certificate based on an existing key pair, but that’s not important right now). The genkey tool makes it so easy and convenient that it is just easier this way. Remember that a certificate is nothing but a public key that is “stamped” with approval by a CA.  In this case, the CA is you, too.  Not exactly a trusted hierarchy, but there you go…

So to cut to the chase, it’s really easy.  Here’s basically what you need to do:  1.) run the tool, and  2.) validate your SSL settings in your httpd.conf.

Run The Tool

At this point, you may or may not want to make a backup of your cert files…  This is up to you…  You can do that with something like this command (of course, your mileage may vary):

cp -av /etc/pki/tls /etc/pki/tls.bak

If you just run the genkey tool without specifying the certificate lifetime, it defaults to something like 30 days.  Let’s try something a little longer; like 4 years.  Now just specify your hostname on the command line:

genkey --days 1460 www.yourlinuxguy.com

…this will launch an interactive tool to do things like generate the random data, make the key pair, and walk you through specifying the content of the certificate (Country, Location, etc.).  It will place the new stuff in some default location, and at the end of the process, tell you where it all is.  You should take note of the location, but it will likely be what I mentioned above for the backup.

Validate Your SSL Settings

Now, theoretically, you should be able to restart your Apache daemon.  However, you might have used custom names or locations for your certificate files in the past, so you might want to check to be sure they match the SSL settings in your Apache config files.  Of course it’s hard for me to tell you where those settings are, since it’s so easy to customize Apache; but here’s a good way to find the two most important values:

cd /etc/httpd
egrep -R -e "SSLCertificateKeyFile" -e "SSLCertificateFile" *

…and that will likely return results from a file called “ssl.conf” or something like that.  Edit the config file if necessary; just make sure the values match the place that the genkey tool placed the new private key and cert file, and you should be good.

Now, you can restart Apache…

/etc/init.d/httpd restart

…and you’re done!  I hope that helps…

So first, I had to find those that are in the reverse DNS zone… So I simply made sure my PC points to the correct internal DNS server that is authoritative for the forward and reverse DNS zones, and then ran a sweep with some filtering:

nmap -sP 192.168.1.0/24 |grep -v "^Host 192\.168\.1"|grep "^Host"|awk '{ print $2,$3 }'

Then, in order to get the local netbios name for Windows computers that aren’t in reverse dns , I came up with this:

for item in `nmap -sP 192.168.1.0/24|awk '{ print $2 }'|grep "^192\.168\.1"`;do thingy=`nmblookup -A $item|grep "<20>"|awk '{ print $1 }'`;echo $thingy \($item\);done

…of course, non-Windows computers and devices without netbios will simply not respond to the query. It might be neater to dump the output to file and such if you wish, but I didn’t bother. I’m just keeping it simple here.

Note that the above does not take in to account if there are multiple reverse DNS entries per PC. If you need to know that, you could do something like this:

for item in `nmap -sP 192.168.1.0/24 |grep -v "^Host 192\.168\.1" |grep "^Host"|awk '{ print $3 }'|sed s/[\(,\)]//g`; do nslookup $item|grep "name =";echo "";done

…and so on.  You could really go crazy with this sort of thing… It can also be handy if you are in an environment where you don’t have access to the DNS/DHCP administration tools, but want to see what’s out there…. Now wasn’t that fun?

First, let’s back it up!  Let’s grab the whole tree:

ndsbackup cvf /tmp/ndsbackup-treeRoot.bak [Root]

…note that you will be prompted for the admin user credentials, and by specifying the “[Root]” object, it will grab every single object in the tree and put it in the specified file.

Now, let’s get a little fancier:

ndsbackup cvf /tmp/ndsbackup.`date +%Y%m%d%H%M`.bak -a admin.corp [Root]

…here we are adding a date stamp to the output file, and giving it the admin username.  It will still prompt for the admin password, of course.  There are tricks to handle that, too, but this is good enough to get the point across.

If you want to see what’s in your backup file:

ndsbackup tf /tmp/ndsbackup.201003051421.bak

Make sure to copy that backup file off the server somewhere, somehow.  In reality, you might actually be writing the result directly to an nfs or samba share or something anyway, but the point is to get the data off the box for safety.

So let’s imagine a week goes by, and whoops… you deleted someone accidentally.  Don’t worry!  Because all you have to do to restore that user object is to put the file back on the filesystem where you can reach it, and do something like this…

To restore just that user you deleted:

ndsbackup wxvf /tmp/ndsbackup.201003051421.bak -a admin.corp cn=duser.ou=Users.o=corp

Or, plow in the whole container if you accidentally wiped it all out:

ndsbackup wxvf /tmp/ndsbackup.201003051421.bak -a admin.corp ou=Users.o=corp

…If you wish, you can remove the “w” from the above restore examples if you don’t want to be prompted to confirm for each object.  However, I tend to think the “w” is a good idea…

That’s all for now.  Of course, there are tons more options for ndsbackup if you look in the man page, but I’m not going in to that, because after all, this *is* a cheat sheet…

First, su to root, and check to see if the support utilities and sysstat package are installed:

zypper se sysstat supportutils 

…if the result for each has an “i” (for “installed”) at the far left of the package, it is already installed.  Otherwise, if the package(s) are not already installed, run this to install the sysstat package and the support utilities included with your Suse distro:

zypper in sysstat supportutils

Or, if you wish to run the latest version of the supportutils package (see “comment” below about versions), run this to install/upgrade to the latest version at the time of this writing:

rpm -Uvh http://download.opensuse.org/repositories/Novell:/NTS/SLE_10/noarch/supportutils-1.20-1.1.noarch.rpm

(Please see the Supportutils project page at http://en.opensuse.org/Supportutils for the latest info and versions.)

COMMENT:  Unfortunately, I have discovered that the info collection part of some modules seems to be broken on some versions; I’m not sure why.  You’ll know they need to be skipped if you run the tool and it hangs for a long time.  I’ve seen the DNS module hang on most systems with the older package, the SYSFS module hang on Opensuse with the latest version, the NSS modules hang on OES servers, and so forth.  Personally, and take this for what it’s worth, I like the distro-provided supportutils package on OpenSuse, and the latest download-able on available for SLES10 and/or OES servers… all with the caveats, of course…

So, to get around the sticking/hanging problem, we need to modify the configuration file to skip the info collection for those modules that get stuck  (of course, it is also possible that you want to modify the config file to exclude certain things for other reasons, as well).  For this example, I disable the DNS info collection (which has since been repaired in newer versions).  You can do it interactively with vi or gedit like this:

vi /etc/supportconfig.conf

…(or via gui, gedit /etc/supportconfig.conf) and change this line:

OPTION_DNS=1

…to…

OPTION_DNS=0

…or do it non-interactively with this example command set:

mv /etc/supportconfig.conf /etc/supportconfig.conf.bak
sed s/OPTION_DNS\=1/OPTION_DNS\=0/ /etc/supportconfig.conf.bak > /etc/supportconfig.conf

Now back to the program; whether you upgraded, modified the config file, or not….

Next, create the output with this command:

supportconfig

When completed, it gives you a nice info summary.  One of the first lines in the summary is the resulting tar ball file size.  If it is reasonably small, like under 10MB, feel free to send it to me via email it to me this way (if it is larger than 10MB, I can provide an alternate method of delivery):

echo "See attached." | mailx -a /var/log/nts*`date +%y%m%d_%H`*.tbz -s "Support Config file from $HOSTNAME" jpavlov@yourLinuxGuy.com

…Note that the above command will send all of the result files that were generated in the current hour; you can take off the “%H” if the file you wish to send was generated in a different clock hour.

If you’re curious, when I get it, I download from my email and unzip it in a temp directory for review:

cd /tmp/support
tar -jxvf nts_lt1101010_100106_1010.tbz

And that’s it!  I hope it helps.  And, I hope I can help you…

It’s very true:  If you try to umount (unmount) a filesystem that is currently being accessed, it will not let you do it.  And it will tell you something like, “umount: /media/ncp: device is busy“.  What causes this?  Well, it’s likely to be one of two things:

1. You have (or someone else has) cd‘d onto the remote filesystem and are currently at or below the mount point root
2. You are running an application that has a file open on that mount point

To mitigate item #1 above (if you are the guilty party, not someone else), just cd to the filesystem root (like cd /), or some other place you know is not on the mount point (like cd /tmp).  Then you can run your umount command.

Solving item #2 above is perhaps a tad more tricky.  Of course, if you have a suspicion or direct knowledge of the guilty app, then you can just stop it.  Sometimes doing this:

ps -ef | grep
…or…
ps aux |grep

…will show the process and any files it accessed by the startup command.

Either way, my favorite way to check for both item #1 and #2 above is to use lsof.  This utility will list *every* file that the system has a hold on.  And this is essential because after all, we know that Linux is nothing but a bunch of files, right?

So here’s what I like to do, for example:

lsof| grep "/media"

… this will show you if anyone or anything is currently sitting on the mountpoint (of course, change your mountpoint to suit, be it /media, /mnt, /export, whatever).  If it shows anything, you can see who or what is at fault, and tell them to get off it, or kill them (I mean the app, jeez…).  If you really need to see the headers of the columns, you can do a double-run for cosmetic purposes that will run once for just the header, then again to grab your detail, like this:

lsof |head -1;lsof| grep "/media"

Another way is to use the fuser command, referencing your mount point. Here’s my favorite set of flags in an example:

fuser -uv /media/ncp

I hope that helps!

Of course, this is not a big deal to alot of people, but I’m a server guy.  I do terminal sessions to Sun/Solaris servers and Cisco routers and such;  I really can’t live without a serial port.  So I basically had 2 options:

1. Go back to my old latop (nope, no way, nahgahdah)
2. Get a USB attached serial port

…so after reading a ton of reviews at NewEgg.com, I finally settled on the CABLES UNLIMITED USB-2920 USB 2.0 to Serial DB9 Adapter.  At the time I bought it, it was on sale and had a shipping special.  But at the time of this writing it is $16.99.  …Still not bad, really.

First, Windows

As it happens, when I first bought it, I connected it to my laptop, and I fired up a Windows XP guest in VMWare Server 2 on my Opensuse 11.2, and “virtually” connected the USB to the XP guest (can’t do *that* in ESX… nyah, nyah).  The driver installation in Windows was a little weird,  since the driver installation was a little language-challenged…  But if you know what you’re doing, you can get it done.  Once it was all set up in Windows, it was easy to use in Hyper Terminal and Putty, and it really worked perfectly.

Then, Linux

A few days later, I needed to do a serial connection again.  This time I didn’t feel like firing up my VM guest, so decided to stop playing around, and configure it natively in Linux for use in minicom.  Here’s where it gets good…  It is sooooo easy to setup in Opensuse, and I hope/assume it is nearly as easy in other distros, though I’ve not tested it.  Here’s basically what I did:

Step 1:  Plug into adapter into USB port

Step 2:  Launch minicom -s (to enter configuration)

Step 3:  Configure the port as /dev/ttyUSB0  (that’s a zero, though it could be a 1 on yours if you have multiple), and save as “dfl” (default)

Step 4:  Enjoy!

I hope this helps…

The examples given here are assuming you are remote to the server.  Of course, you could do all of this locally on the console, or adapt my instructions to the gui “Yast2″, but I’m going non-gui here for simplicity.

First, shell into the box, and su to root.

Method 1:

Launch the Yast non-gui firewall module:
yast firewall

To change to startup setting to “Manually”:
“Alt + m”

Optionally, to stop the service right now if running:
“Alt + t”

To complete the change:
“Alt + n”

To accept and finish:
“Alt + a”

Method 2:

To disable the service at next startup:
chkconfig SuSEfirewall2_setup off

Optionally, to stop the service right now if running:
rcSuSEfirewall2 stop

I hope that helps!  Now, if you want to argue about how one should never disable the firewall, drop me a line…

It had been almost a year since I patched my Openfiler 2.3 server, and some significant updates had been released in that time.  So after planning an outage window, I set out to apply the queued batch of updates (including mkinitrd and a kernel or two, more on that later).  It seemed such a simple task….

After the patches were applied, the Openfiler server would not boot.  Instead, it spewed out more errors than I could read to the console, ending with a kernel panic.

So I booted to the Openfiler install cdrom, and entered rescue mode with “linux rescue“.  Fortunately, it discovered and mounted all my partitions, and I was able to run with networking in order to reach the package sources or other sources/destinations if I should need them.

I noticed that the errors I had seen on the console pointed me toward missing drivers in the initrd, so I started looking there.  While poking around, I think I noticed that the latest update bundle had re-compiled all my initrd‘s in /boot. I’m not actually 100% sure about that now in hindsight, but it’s not important now.  Anyway, I de-constructed one of the initrd‘s this way to see what was up:

mkdir /tmp/temp
cd /tmp/temp
cp /boot/initrd-2.6.29.6-0.15.smp.gcc3.4.x86_64.img initrd-2.6.29.6-0.15.smp.gcc3.4.x86_64.img.gz
gunzip initrd-2.6.29.6-0.15.smp.gcc3.4.x86_64.img.gz
cpio -i --make-directories < initrd-2.6.29.6-0.15.smp.gcc3.4.x86_64.img
ls -l
ls -l lib/

Hmm.  No drivers there.  Should be a bunch of *.ko files…  Hmm…

I decided to roll back;  so I ran conary to revert to the state before the update  (Run “conary rblist” to figure out the number of the point-in-time to which to roll back, then “conary rollback (number)” to actually do it.  See this wiki page for details).

For some reason, this did not repair all my initrd‘s, but it did seem to give me a working mkinitrd script (in hindsight, I did not think to analyze it or keep a copy of it… drat).  So I was now able to hand-build a working initrd for one of the kernels (the most recent before the update) with this command:

mv /boot/initrd-2.6.29.3-0.3.smp.gcc3.4.x86_64.img initrd-2.6.29.3-0.3.smp.gcc3.4.x86_64.img.bad
mkinitrd /boot/initrd-2.6.29.3-0.3.smp.gcc3.4.x86_64.img 2.6.29.3-0.3.smp.gcc3.4.x86_64

And now, I was able to reboot into this kernel with my new working initrd…. and this time I made backups of it in my /home directory!

So I proceeded to re-apply the patches bit by bit.  I quickly realized that the dreaded kernel update was a requirement as part of the major Openfiler update, so it came back with the re-run of the last few updates anyway.  But this time, I was ready.  I modified the /boot/grub/menu.lst to use my old trusty kernel and initrd, (default=1), and make sure my hand-made initrd was in place.  Ok, good.  Reboot.  Right.

Back up in my older kernel (phew!), but with my newer kernel installed, I troubleshot…  I tried to build my own initrd against the new kernel, but I kept getting errors like this for each needed module:

/usr/bin/strip: /lib/modules/2.6.29.6-0.15.smp.gcc3.4.x86_64/./kernel/drivers/rtc/rtc-lib.ko: File format not recognized

I dove in to the /sbin/mkinitrd and found the cause.  There are some lines in an “if” block that optionally call “strip” if present, and that is where it seems to err out.  If “strip” is not present, it just copies the module, like I want.  Hmm.  I don’t know if strip was there before or not, or if the mkinitrd suddenly has this new “if” block, and I don’t care.  I commented it out to look like this:

for MODULE in $MODULES; do
#    if [ -x /usr/bin/strip ]; then
#        /usr/bin/strip -g $verbose /lib/modules/$kernel/$MODULE -o $MNTIMAGE/lib/$(basename $MODULE)
#    else
cp $verbose -a /lib/modules/$kernel/$MODULE $MNTIMAGE/lib
#    fi
done

…and re-built my initrd for the latest kernel like this:

mv /boot/initrd-2.6.29.6-0.15.smp.gcc3.4.x86_64.img initrd-2.6.29.6-0.15.smp.gcc3.4.x86_64.img.bad
mkinitrd -f -v /boot/initrd-2.6.29.6-0.15.smp.gcc3.4.x86_64.img 2.6.29.6-0.15.smp.gcc3.4.x86_64

…and no more errors!  Yay!  I modified the /boot/grub/menu.lst back to use my new kernel and initrd, (default=0), and I re-booted into it with no kernel panic! Yay!

And that’s my story.  I really hope this helps someone out there…

UPDATE, 20100127, evening:  On the Openfiler forums, there is talk of a fix.  To quote a Rafiu, “This was due to a strange situation where 64-bit version of binutils was not built and the group update succeeded regardless.

We have now resolved this issue. Apologies to all that were affected by it. “

I have not yet tested this, but I do see that the latest binutils is in the update list now.  More to come…

UPDATE, 20100128, morning:  Yes.  The latest set of updates at this time, *including* the correct set of binutils (2.17.50.0.6-7-0.0.2) for 64-bit, worked perfectly, and my server is still running as smoothly as ever after rebooting.  Hooray.  Though I will never get that Saturday night back that I spent chasing my initrd all over the place, but there you go…

So I replied, but then I thought of alot more stuff… so much more in fact, that I thought it deserved its own post…  So here you go, an “extended play” version of my reply…

For OpenSuse servers…

Please see this post:  http://yourlinuxguy.com/?p=324

That is exactly what I was going for in the post linked above.  If you download that script I mention there in that post, then change it to executable (for instance, chmod 700 filename), then run it, it will generate a comparison and dump the results to screen and output file, and tell you where the file is.

The script will not actually update your system (in the current state); it will only report about potential updates. But, if you get more brave, you can go in the file and un-comment the zypper lines I commented out that actually update the system…  Or change them to rug lines…  Which leads me to…

For SLES/OES servers…

Just do this:
rug lu > /tmp/lu.txt

…then go look at the file with:
less /tmp/lu.txt

…Or, you could have it emailed to yourself like this:
rug lu |mailx -s "Updates from $HOSTNAME" root

…of course, that assumes that you are having root mail sent off the box (see this if you’re not).  Otherwise you use your email address instead of root.

But what if you want to limit the updates list?  Perhaps something more specific; to report only that in which you are interested in updating?  See these examples (note that you can change the rug catalog to taste, of course, depending on your version):

rug lu -t patch SLES10-SP3-Updates OES2-SP2-Updates |mailx -s "Updates from $HOSTNAME" root

By adding a grep statement to block out the “optional” lines, the result is even cleaner.  Here’s an example:

rug lu -t patch SLES10-SP3-Updates OES2-SP2-Updates |grep -v optional|mailx -s "Updates from $HOSTNAME" root

On the other hand, by only *including* the lines you want (instead of excluding those you don’t), you lose the headers and separators, and only get the lines in which you’re interested (if any).  Here’s an example:

rug lu -t patch SLES10-SP3-Updates OES2-SP2-Updates |grep -e security -e recommended|mailx -s "Updates from $HOSTNAME" root

Or if you were to be running this in a mass-batch (hmm… future post…) to a bunch of servers or a cron job, and just don’t want an email at all if there are no results (and you *do* want an email if there *are* results):

RESULT=`rug lu -t patch SLES10-SP3-Updates OES2-SP2-Updates |grep -e security -e recommended`;if [ "XX$RESULT" != "XX" ];then echo "optional updates:" $RESULT |mailx -s "Updates from $HOSTNAME" root;fi

Okay now, that’s good; but here’s a prettier version of the same…  Okay, the command itself is uglier, but the resulting email is prettier at least.  The above one doesn’t format the results as nicely as I like (losing all the line returns), so I had to make use of a temp file to maintain the output formatted with returns:

rug lu -t patch SLES10-SP3-Updates OES2-SP2-Updates |grep -e security -e recommended>/tmp/ruglu.txt;RESULT=`cat /tmp/ruglu.txt`;if [ "XX$RESULT" != "XX" ];then cat /tmp/ruglu.txt|mailx -s "Updates from $HOSTNAME" root;fi

And that’s about it, with a couple closing thoughts:  Remember, it’s definitely a good idea to do a “rug ping” before doing this, to wake it all up, so you’re not waiting in silence for each command to run while it wakes up.  Then if you actually need updates, do this:

rug up -y -t patch -g security -g recommended SLES10-SP3-Updates OES2-SP2-Updates

Do you feel updated?  I do.

Seriously, folks.  I know there are others of you out there, like me, who upgraded to Opensuse 11.2 (the latest at the  time of this writing), without concern that VMware Server 2.0.2 (also the latest at this writing) may or may not run on it.  Well guess what: it doesn’t.  Well, not without help, that is.

To cut to the chase, as I write this, the problem is that VMware Server 2.0.2 will not work with the newest kernel and libraries that are shipped with Opensuse 11.2, version 2.6.31.x.and.so.forth.  So I found some work-arounds while Googlin’, that I wanted to record for posterity.  Here’s what I did:

1. Go to this post from Radu Cotescu.  Read up.  Note that Radu’s post, problem, and fixes are all about Ubuntu.  Do not fear.  (Post-publish update, 20100119:  See http://radu.cotescu.com/2010/01/19/how-to-install-vmware-server-ubuntu-fedora-opensuse/ for a new version that I have not tested yet.)
2. As he instructs in his step 1, download the VMware 2.0.2 tgz file from VMware themselves (version 2.0.2-203138 at this time), and drop it in a directory like /tmp/vmware.  DO NOT decompress the tgz file!  The script will do it for you.
3. Get Radu’s script, and as instructed in his step 2, drop it in the same folder as the VMware tgz file, for instance, /tmp/vmware.
4. Here is where we slightly vary from the plan… open the script up in a text editor (vi, gedit, emacs, etc.), go down to the “install” section around line 76, and comment out all the “dpkg-query” checks from line 77 to line 95.  Save, and quit.  Funny… but I don’t remember those checks being there a month or so ago, so he may be changing them from day to day.  Tread carefully, and don’t necessarily trust my indicated line numbers.
5. Make sure we have the necessary script support software installed;  you need your kernel version “devel” package (for me, since I have kernel-pae, I need kernel-pae-devel), kernel-source, linux-kernel-headers, gcc, and make.  Use zypper in <package-name> to get them installed.
6. Now return back to Radu’s step 3, and complete his commands as listed.
7. If all goes well, when you follow his instructions, it will compile everything, and launch you right into to the VMware installation, and continue into the configuration.  Make sure you have your VMware registration code handy.  Oh, and of course, ignore that GCC version mis-match warning… And you may want to do a chkconfig vmware off when you’re done, I always do.

So there you go.  That’s the only way I could get it all to work together.  But if you know of a better way, or if I missed something, please share it with the group!  I assume that VMware will get a corrected version out in the near future that will mitigate this issue, but in the meantime, it’s a real life-saver.  And many, many thanks to Radu and any others involved….