Cricalix.Net

Going sane since 1978

Browsing Posts in $work

I’ve been working with Glassfish recently, from the system administration point of view.  First task, after getting a good build with Maven (doing it with basic rpm methods netted me a massive dependency list, including things like Firefox!), was to write an init script so that Glassfish can be integrated into the CentOS boot sequence.

Because we might have multiple domains set up inside of Glassfish, I opted for a setup similar to the Tomcat5 init script – check the basename of $0, and use that to determine which domain to boot up.  The fiddling in start() gets around the fact that Glassfish doesn’t seem to write a PID file out where we need one.

So, just in case anyone else needs to do this:

#!/bin/bash
# chkconfig: 2345 85 15
# description: GlassFish is a Java Application Server.
# processname: glassfish
# pidfile: /var/run/glassfish.pid
 
# source function library
. /etc/init.d/functions
 
RETVAL=0
GLASSFISH_BIN="/var/lib/glassfish/bin"
 
# Basename works with symbolic links.
NAME="$(basename $0)"
unset ISBOOT
# Trim off the Sxx/Kxx prefix
if [ "${NAME:0:1}" = "S" -o "${NAME:0:1}" = "K" ]; then
    NAME="${NAME:3}"
    ISBOOT="1"
fi
# Trim off the glassfish- prefix
NAME=${NAME:10}
 
# /etc/init.d/glassfish should never be called directly.
if [ -z $NAME ]; then
        echo -n $"Cannot start Glassfish without specifying a domain."
        failure
        echo
        exit 1
fi
 
start() {
        echo -n $"Starting Glassfish V2 domain $NAME: "
        daemon --user glassfish --pidfile /var/run/glassfish-$NAME.pid "$GLASSFISH_BIN/asadmin start-domain $NAME >/dev/null 2>&1"
        RETVAL=$?
        if [ $RETVAL -eq 0 ]; then
                PID=`ps U glassfish | grep $NAME | awk '{ print $1}'`
                echo $PID > /var/run/glassfish-$NAME.pid
                touch /var/lock/subsys/glassfish-$NAME
        fi
        echo
}
stop() {
        echo -n $"Shutting down Glassfish V2 domain $NAME: "
        $GLASSFISH_BIN/asadmin stop-domain $NAME >/dev/null 2>&1
        RETVAL=$?
        [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/glassfish-$NAME && rm -f /var/run/glassfish-$NAME  && success || failure
        echo
}
 
case "$1" in
  start)
        start
        ;;
  stop)
        stop
        ;;
  restart|reload)
        stop
        start
        ;;
  condrestart)
        if [ -f /var/lock/subsys/glassfish-$NAME ]; then
            stop
            start
        fi
        ;;
  status)
        status glassfish-$NAME
        RETVAL=$?
        ;;
  *)
        echo $"Usage: $0 {start|stop|restart|condrestart|status}"
        exit 1
esac
 
exit $RETVAL

The alternative is to define a /etc/sysconfig/glassfish file, and insert a variable with the list of domains to boot, in sequence.  This is a little harder to manage automatically in Puppet, but might be a better solution if precise boot sequences are required (this method will boot in sequence based on the S numbers in the base script, and then the alphabetical ordering of the names).

I have a work-supplied laptop.  Until this week, whenever I activated the PPTP VPN to work, I was able to resolve all of our internal servers by DNS name.  This is good, it means I can navigate our network at work without remembering IP addresses.

This week I’m on call.  I had to VPN in to check out a failed Internet connection, and found to my horror that DNS resolution no longer worked.  I pondered for a moment, and then hard-coded the DNS server for the underlying network device to the work DNS servers and was able to get on with the job.

I’ve just been looking for what the heck has gone wrong; my home PC is able to open up the same VPN connection (I checked every single setting) and DNS resolution works.  What I found was a page describing a registry edit that fixes the problem.  Did said regedit, and presto, the VPN from the laptop works again.  The thing that bugs me is I don’t know how that setting got changed.  Mindboggling.

For the record, in case that page goes away, edit HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage, double-click Bind and move the NdisWanIp entry to the top of the list.

Windows.  Feh.

It came to my attention today that when a Catalyst running CatOS reports

Port  Status     Channel   Channel     Neighbor                  Neighbor
                 mode      status      device                    port
----- ---------- --------- ----------- ------------------------- ----------
8/7  connected   on        channel
8/8  connected   on        channel

it means the two ports are bonded together.  This poses distinct problems when the server isn’t aware that the two connections are bonded.  A CentOS installation process that takes 5 minutes normally was still running 3 hours later, and it wasn’t even half-way.  What was even more interesting was that the repository server showed files being downloaded, but Anaconda swore blind that nothing was happening.

Live and learn.

One of the recent fun challenges at work has been to get the developer R61i laptops running CentOS 5.1 to talk to our wireless AP (or their home AP). I’ve gone through 3 different drivers in an effort to get it working, and it’s come down to the one I really didn’t want to use – NDISwrapper. Unfortunately, even NDISwrapper doesn’t work properly.

continue reading…

One of my long-term tickets at work is to provide LDAP or Kerberos integration for our servers at a minimum, and all Linux workstations and laptops if possible.  I poked it a bit today, and made a disappointing discovery.  Unlike Windows, a CentOS machine running LDAP as the primary authentication method is unable to cache the password hash.  So, if I enable it on a laptop, then disconnect that laptop from the network, I am unable to log in as any user that has previously logged in with LDAP credentials.

Bummer.

I doubt Kerberos is going to solve this either, as the caching is performed by nscd, and it’s nscd that doesn’t cache the hashes.  I suppose I could work on a custom PAM module that hooks in to pam_ldap, and on successful authentication, stores a new MD5 password for the account in /etc/passwd.  This way, a machine going off-line would have accurate local password hashes, and authentication would still work.

That sounds like way too much work though, and outside the scope of my job.

In the current job, I’m dealing with Microsoft-based administrator more than I ever have before. I don’t mind too much, it gives me a few more skills, and another bullet point or three on the resume. Today, however, Exchange has been driving me batty.

We have Exchange 2003 – it’s not bad once it’s had all of the service packs applied. We also, until today, managed our meeting rooms on a bit of paper. This morning, the request came through to investigate the use of Exchange as a meeting room management tool; shouldn’t be too hard to do really, and it isn’t.

  1. Create a new Active Directory user, and stick it in a service account OU.
  2. Assign the user a rather long password, it’s only going to be used on occasion.
  3. Create a mail profile for Outlook, and log in to the meeting room account.
  4. Configure the account to automatically accept meetings and cancellations, and also provide conflict detection. Oh, don’t forget the rights for Authors and Editors (create/edit own and edit all respectively).
  5. Log back in to a regular Exchange account, and schedule a meeting, with the meeting room as an invited attendee.
  6. Remember to throw the flag that says the meeting room user is actually a resource. Every. Single. Time.

It’s step 6 that gets me – why can’t I tell Active Directory, and thus Exchange, that I want a new object of type resource, rather than new object of type user? Why do I have to remember to change that flag for that user every time?

Argh.

As I work on the current big project at $work, I’m getting more exposure to ISDN (otherwise called It Still Does Nothing by my boss), and the tools used to diagnose ISDN connectivity issues. We’ve got a few bits of kit lying around here, including handsets that can emulate a PBX or monitor an ISDN channel, and something called a Siemens K1197 ISDN Protocol Tester. No longer made, and around 20 years old, it just fired up and ran today. Dan hooked it up, tapped on the keyboard a few times, and I made a test call. We were all amazed to see it displaying call information – right first time.

Well, almost right. The information we were after wasn’t displaying, and no amount of fiddling with short vs comprehensive output would show it. There was a slight smell of smoke, and then Dan tapped in a few more instructions, and I made another test call. Hey presto, full ISDN session setup information, flags indicating the type of call and number types and all sorts of other information.

Very, very nice tool. Quite expensive too.

Now to run a series of test calls to get the information I need, and then contact our ISDN supplier to see if they can’t sort a few things out for us.

ISDN protocol tester

Powered by WordPress Web Design by SRS Solutions © 2010 Cricalix.Net Design by SRS Solutions