Wednesday, February 14, 2007

first impression of Bestpractical's RT, an open source ticketing system

I heard quite a bit of good things about RT, an open source ticketing system.  Here is the first impression I had after retrieving the source tarball off bestpractical.com's web site.

The current stable version is 3.6.1.

Per README in the source tarball,
  • "RT is an enterprise-grade issue tracking system. It allows organizations to keep track of what needs to get done, who is working on which tasks, what's already been done, and when tasks were (or weren't) completed."
  • GPLv2
  • commercial support is available including training and such: sales@bestpractical.com .

The installation seems a little too involving, even for a professional UNIX/linux system engineer.
  • it requires Perl >5.8.3 with a lot of CPAN modules. To the developer's credit, a RT util tool is built to help get CPAN modules and compile them in place.
  • It support a few RDBMS as its backend: MySQL/Postgres/Oracle/SQLite
  • Apache with mod_perl (or FastCGI)

Tuesday, February 13, 2007

linttylog hang my Linux system on a Dell PowerEdge 6850 at first run

When troubleshooting a Dell PowerEdge 6850 server, I read on Dell's linux-poweredge mailing list that a small utility named linttylog may be useful to dump log from the PERC raid controller.  The function sounded a lot like what action=exportlog does using OMSA's srvadmin services. However, I was desperate enough to try anything reportedly working. So, without much ado, I downloaded the utility. It came in as an RPM and was a bit aged (probably out-of-date too).

syb04:/# rpm -ivh linttylog-1.00-0.i386.rpm
Preparing...                ########################################### [100%]
   1:linttylog              ########################################### [100%]

syb04:/# linttylog


        Serial Port Output History Handling Application 1.00 (Date 10/01/2003)
                Copyright (c) 2003 LSI Logic Corp.

Depending on the buffer size, it may take several minutes...Please wait...

        TTY History Updated in the file tty.log.

Exiting.
syb04:/# ls -ltr
====================================
The ssh shell session got disconnected from here. I couldn't log back in either. No response on serial console either. Nothing on the console screen. Nothing logged onto the remote syslogd server either, even though all kernel.* and all *.warn are redirected via /etc/syslogd.conf and verified to be working.

I had to power cycle the server to get it back online again. Once the server was back, I re-ran the utility successfully without any problem. What the ... The moral of this post is not to run linttylog on your mission critical system in production.

Wednesday, February 07, 2007

lay off ~= business strategy ~= choked by your own success

Four weeks ago, I called in to a meeting from home. In that meeting, John, my manager was let go, because the business strategy has renewed. The rest of us were assured in a later company-wide town-hall meeting, that "this is the team we are going forward with." John wasn't present. I was told later that he was asked not come in at all and his employment terminated that day. Why the rush? We were just about to roll out a major release on the ASP platform our team work on for the first third of our customer base. John was a hands-on manager, so the big void caused by his departure was apparent. 

Three weeks ago, Stevie, Matt, and Prakash, three more team members, were let go. Their positions were eliminated, because the management is confident that the latest release on the ASP platform is "feature-rich and robust enough to go forward without new development, for years to come". Again, my team or the left half of it were assured that "this is the team we are going forward with." Why the rush? We were yet to roll out the major release to the rest two thirds of our customer base. 

Does this second layoff justification suggest that our team choked by our own success? If less feature were rushed in by John and squeezed in by Sales/marketing and we didn't work days and nights and weekends to smooth the edges, we'd all still have jobs? I couldn't help wondering whether this why ISVs release bug-ridden code or QA/test inadequately. 

At any rate, the red PANIC button has been pounded on. Seasoned professionals as we are, we instantly hit the floor. Calling recruiters, line up old friends and contacts, update resumes and post them. It pretty much resembles a scene where rats rush off a sinking boat. 

Various news starts to tickle in through the cubicle walls. Hallway meetings anytime. Then, Matt's sense of humor struck me. He said, "Yes they were a bit clumsy firing people. It could only be a good thing. At least they are not used to this kind of thing or hadn't do it often enough to become proficient and smooth." I don't think I am thinking straight right now. I probably will add a few more comments when I have leisure to reflect, after I find my new job somewhere else.