homespun

eDirectory segmentation faults

We have a virtual machine running OES Linux, it's been very reliable for over a year. But yesterday, the VMware host experienced some sort of communication errors and apparently corrupted some of the eDirectory files.

The problem showed itself in a failure of eDirectory to start. Instead, the boot.msg file had errors like

Starting Novell eDirectory server done
Executing customized settings after starting the Novell eDirectory server...
/etc/init.d/nldap: line 146: 4691 Segmentation fault $sbindir/nldap -c >/dev/null 2>&1

There didn't seem to be anything that I could do. nldap was broken and I couldn't seem to get any further.

oes-lx1:~ # ndsstat
segmentation fault

oes-lx1:~ # rcndsd status
/usr/sbin/rcndsd: line 351: 14649 Segmentation fault $bindir/ndsstat >/tmp/nds.stat.$$ 2>&1
/usr/sbin/rcndsd: line 351: 14652 Segmentation fault $bindir/ndsstat -h `hostname` >/tmp/nds.stat.$$ 2>&1

I tried to upgrade eDirectory from 8.7.3 to 8.8 using rug (look here ) and the upgrade seemed to work. But in fact, it didn't. When I tried to configure eDirectory from YaST, it found the previous version DIBs (the eDir database files), but then failed on the upgrade.

Well, as the most practical solution, I've decided to build a new OES2 SP1 server. Replacement of the older OES server was on the roadmap; we just seem to have gotten to that crossroads a little sooner than planned.

Windows system uptime

In linux, I can type "uptime" at a command prompt and see how long it's been since I rebooted. In Windows, it's not that easy. However, it can be done by using two command line tools. Simply open a command prompt and type the following:

C:\>systeminfo | findstr /c:"Up Time"
System Up Time: 42 Days, 20 Hours, 36 Minutes, 45 Seconds

wget and cron behind a proxy server

Issue: wget runs fine from the command line, but fails when in a cron job. My system: SuSE Linux Enterprise Server 9 (SLES9), behind a corporate proxy firewall.

Resolution:
The man page for crontab(5) on my system says:

······ Several environment variables are set up automatically by
the cron(8) daemon. SHELL is set to /bin/sh, and LOGNAME
and HOME are set from the /etc/passwd line of the
crontab's owner. HOME and SHELL may be overridden by set­
tings in the crontab; LOGNAME may not.

In addition to LOGNAME, HOME, and SHELL, cron(8) will look
at MAILTO if it has any reason to send mail as a result of
running commands in ââthis'' crontab. If MAILTO is
defined (and non-empty), mail is sent to the user so
named. If MAILTO is defined but empty (MAILTO=""), no
mail will be sent. Otherwise mail is sent to the owner of
the crontab. This option is useful if you decide on
/bin/mail instead of /usr/lib/sendmail as your mailer when
you install cron -- /bin/mail doesn't do aliasing, and
UUCP usually doesn't read its mail.

From the wget man at gnu.org, I read:

Wget supports proxies for both http and ftp retrievals. The standard way to specify proxy location, which Wget recognizes, is using the following environment variables:

http_proxy
https_proxy

If set, the http_proxy and https_proxy variables should contain the urls of the proxies for http and https connections respectively.

Of course, I knew that I was behind a corporate proxy server, and "echo $http_proxy" returned the correct URL for the proxy server. So, for my purposes, I created a simple script named wget.sh


#!/bin/sh
export http_proxy="http://your.server.here:8080"
wget ...etc, etc.


Then I put a crontab entry in place, calling my wget script. Works like a charm!

HP Smart Array P400 and SLES10 issue

My boss recently dropped an HP ProLiant DL385 G2 on my desk (Literally, he walked in with the thing under one arm!) and asked me to install OES 2 on it. So, I fired up the server and pressed F8 after the Smart Array P400 initialized to configure the array. I set it up as RAID 5 with one logical volume. The server doesn't have a floppy of CD/DVD drive, but I have an external USB CD/DVD, so I put the SLES10 SP1 disk in the drive and rebooted the server. The Installation screen came up and selected Installation, hit Next, etc, etc. All was well for a few moments until I accepted the license agreement. Then the hardware scan came back and reported that there were no hard drives available for installation!

Cutting to the chase - creating the array and logical volume from the SmartStart CD Release 8.10 resolved the issue and the installation completed successfully. Creating the array and logical volumes from the Option ROM utility accessible during boot caused the installation to fail.

The Long version, a litany of things that failed:

• Not what I wanted to see. All the lights on the drives were green, so I shut down the server and reseated the P400 (PCI Express) card and all of the cables. Started up again and failed at the same point. The installer couldn't detect the array.


• Booted up again, deleted and recreated the array. Installation failed.


• Downloaded and installed Smart Array Firmware Maintenance Release 8.20. Install failed.


• Thought it might be the external USB drive, but the CD booted OK, also the HP SmartStart CD booted OK (and recognized the array). There is no SmartStart CD for Linux installations, anyway.


• Downloaded the latest cciss driver for the P400 array card. Copied the files to a USB stick and tried to add the new drivers during Installation. It didn't make a difference.


• Finally, I was browsing the HP Support Forums. There are lots of reports of similar issues when installing RHEL with the P400 smart array card, but one replier mentioned the need to create the array from the ACU (Array Configuration Utility) on the Smart Start CD. I popped in the CD, Release 8.10, deleted and recreated the RAID 5 array, then created a logical volume. Suddenly the Installer could "see" the hard drive and installation was a piece of cake after that.

.NET 3.0 Service Pack 1 adventures

[Listening to: Heartbeats - The Knife - Deep Cuts (03:51)]

I manage a few servers that do not have internet access for security reasons. So, I had documented some time ago how to use Microsoft Baseline Security Analyzer (MBSA) in an offline mode. Recently, I ran into two problems during a security scan.

I had installed .NET 3.0 framework on an isolated server, so when I ran the MBSA security scan recently, it told me I needed .NET 3.0 SP1. No problem I thought. After moving the security scan files back to an internet-connected PC, I clicked on the download link for that file. Well, it directed me to a MSXML6 download instead. That's the 1st time that ever happened! So, I went to the download page for .NET 3.0 SP1. But, there's only a stub executable there. Very nice for minimizing the size of the download to only those components needed by the target machine. Very diasterous for an offline PC!! I needed the full redistributable package, but there was no link to it on that page. The only reference I found on the MS support site was for .NET Framework 3.5, whiich contains the 3.0 SP1. I didn't need that, so I kept looking.

Finally I ran into this article on MSDN blogs. SUCCESS! I downloaded the 3.0 SP1 x86 redistributable.

So, then I went to install it, and got a big disappointment. The installer failed and told me that I needed XPSEPSC installed 1st. So what the heck is that? I found this helpful post which described exactly the same problem. And therein is a link to XPSEPSC.

Installed the XPSEPSC package, followed by SP1 without any further incident.

The Many Faces of Proxy in SuSE Linux SLES

[Listening to: Air Tap! - Erik Mongrain - Fates (03:46)]

Perhaps this will save some other Linux sysadmin some time and frustration...

The first few times I installed SLES9 and OES servers in our environment, I clicked on "Check for Updates" during the installation. Of course the service always failed to connect to Novell's update site, but I didn't know why at first. I soon realized that it was because we were behind a proxy server, preventing the installer from connecting.

Some of the OES servers were configured to use iManager 2.5 or 2.6, but since we still use ConsoleOne for so many management tasks, I didn't realize that the proxy settings for tomcat4 were "broken".

So, I took to configuring the proxy addresses during the installation. Remember, this is SLES9. The updater still couldn't connect because there was no configuration for https:// proxy, which is what the updater actually needs in order to do its work.

Then, SLES9 SP1 (and SP2, etc) came out. The installation program was smarter and now I could put in an https:// proxy setting. However, Novell started to use "rug" to update my OES servers. OK, I had learned how to set the https:// proxy, but rug actually doesn't use those settings. Grrr. So I found a TID that showed how to set the rug proxy.

Eventually, SLES10 comes out and proxy configuration is much more behaved. In fact, it works very well. I installed OES2 as an add-on package for SLES10 recently. Along with that, I installed iManager 2.7. I spent a little more time reading the docs with iman2.7 and so I was pleased to see that it would automatically connect to Novell and download new plugins. Although this was possible in iman 2.6, as I said before, I didn't realize my proxy settings were wrong - actually, they didn't exist. So, here's a variety of proxy settings.

For SLES9/OES:

GUI - use YAST2. Click on Networks Services, then click on Proxy.
Check the box to "Enable Proxy" then fill in your http:// ftp:// and https:// proxy values. Make sure that "localhost" without the quotes is included in the No Proxy Domains box. Click OK. SLES9 before SP1 did not include the https:// proxy setting, if I recall correctly. To configure the SLES9 proxy settings via the command line, using vi, for example:

#vi /etc/sysconfig/proxy

make sure the following lines are present or add them if they're not:
PROXY_ENABLED="yes"
HTTP_PROXY="http://your.proxy.server:8080" (or whatever port is apprpriate)
HTTPS_PROXY="http://your.proxy.server:8080" (or whatever port is apprpriate, add this line if it is not present)
FTP_PROXY="http://your.proxy.server:8080" (or whatever port is apprpriate)
NO_PROXY="localhost"

For rug, at the command-line type:
#rug set-prefs proxy-url "http://your.proxy.server:8080" (or the appropriate port number)

For tomcat4, you have to edit the tomcat4.conf file and add the following lines:

# vi /opt/novell/tomcat4/bin/dtomcat4

CATALINA_OPTS="$CATALINA_OPTS -Dhttp.proxyHost=your.proxy.host"
CATALINA_OPTS="$CATALINA_OPTS -Dhttp.proxyPort=8080"
CATALINA_OPTS="$CATALINA_OPTS -Dhttp.nonProxyHosts=*.mydomain.com|localhost"

and then restart tomcat4 (# rcnovell-tomcat4 restart)

For tomcat5 (iman 2.7), edit this file and add the same three lines:
# vi /etc/sysconfig/j2ee

some references:
Getting the SLES 10 / SLED 10 Software Updater to work if you use a Proxy Server
Configuring Tomcat to use a Proxy server
Novell Doc: OES 1 - Preparing the Server for Patching - actually read section 6.2 for the rug command-line switches.