This one is also quite easy, simply edit $TOMCAT/conf/server.xml, and for the <connector> element, add an attribute: allowTrace="false". Restart Tomcat and enjoy.

Popularity: 23%

Found this from Tomcat 5 on Linux Step by Step. Simply edit the server’s conf/web.xml, and change the DefaultFileServlets listing init parameter from true to false:

Popularity: 23%

You have tuned your PostgreSQL database, and you, of course, turned off query logging, but a problem has cropped up. How can you see the activity on your database at any slice of time?

Like me, you have probably turned on command stats to view pg_stat_activity, but that gives you only moment in time. You could use ethereal to capture the Postgres queriy packets, but then what? What if you don’t have X installed? tcpdump you say? What do you do with the dump?

Enter pgqueryspy.

Simply type pgqueryspy 2000 db0 to capture the next 2000 packets to the server named ‘db0′. pgqueryspy then prints out the queries that it intercepts in the packet stream for your consumption on the command line. It even tosses those pesky “BEGIN” and “END” queries for you.

Not too terribly invasive, no load on your database, and you find out NOW what is happening with your database. Code is available here: pgqueryspy.c.

I accept NO RESPONSIBILITY FOR YOUR USE OF THIS CODE. It could toss your database/network/server/grandma out the window. YMMV, caveat emptor, etc, etc.

I am putting this code out here for two reasons:

1. Like me, Google has not led you to any other solution to sniff packets of Postgres queries without making the database log (which requires a database restart).
2. As soon as I post this code, someone is going to come along and tell me that I could do it in a single command line, and that my 2 hours building this were for nothing. I say bring it on, prove me wrong. You know why? a) my C skills are non-existent, and b) I wish I knew how to do this on the command line

UPDATE: Forgot to give credit for the help. Thanks to Kris, as well as the libpcap packet capture tutorial.

Popularity: 88%

curl -O http://www.monkey.org/~provos/libevent-1.1a.tar.gz
tar zxf libevent-1.1a.tar.gz
cd libevent-1.1a
./configure
make
make install
cd ..
mv libevent-1.1a.tar.gz ../installed/
curl -O http://www.danga.com/memcached/dist/memcached-1.1.12.tar.gz
tar zxf memcached-1.1.12.tar.gz
cd memcached-1.1.12
./configure
make
make install
mv memcached-1.1.12.tar.gz ../installed

Then add /usr/local/lib to LD_LIBRARY_PATH in your .bash_profile
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib
export LD_LIBRARY_PATH

Then test:
memcached -m 512 -u nobody -vv

Popularity: 87%

• yum update
• turn off any services that you won’t use:/etc/init.d/cups stop
chkconfig --level 2345 cups off
• move sshd to another port (stops most scanning), as well as permit only version 2, and no ‘root’ login (all in /etc/ssh/sshd_config). Restart sshd after the changes
• Turn on the firewall (iptables). Note, that in my default install, it was “disabled”, which means it was running, but had no config in /etc/sysconfig/iptables. Just run system-config-securitylevel, and then restart it /etc/init.d/iptables restart
• set up your ssh key, as well as your authorized keys:ssh-keygen -t dsa
vi ~/.ssh/auhtorized_keys2
chmod 600 ~/.ssh/authorized_keys2

Popularity: 45%

Just a short piece to say: don’t do it!

I just re-imaged a machine after fighting for 3 days to do it. I know you can upgrade from 3.4 to 4.0 with a bit of a windy road, but it is impossible to go straight from 3.4 to 4.2

I recommend (in valid order for my situation):

1. Start over with a fresh 4.2 image
2. Go from 3.4 to 4.0, then 4.0 to 4.2
3. Stay in the 3 range, until you can do the first recommendation

Just my 2 cents.

Popularity: 40%

• ATI drivers
• Python 2.4.2
• Firefox 1.5
• Synergy
• Don’t forget to yum update after the install
• Postgres 8.1 (gotta have my unicode)
• psycopg2
• .emacs (Most important!)
• memcache
• daedalus
• nagios

Popularity: 35%

Tired of the constant nagging of the Anti-Virus, and MS Excel locking up on virus scan, as well as VMWare disabling sound entirely, and finally generally poor performance of the default Windows install on Dell boxes, I decided to switch to Linux as my primary environment for about the 8th time in my life.

I decided to go with CentOS 4.2, as CentOS is what I have installed on various servers that I admin. I backed up all the important data off the Windows box, and then started the adventure. First, download the DVD image from a torrent, which necessitates a BitTorrent client. Install the client, start the download, work on something else while it takes 6 hours to download. Burn the DVD, drop it into the PC, and reboot.

Try the graphical installer, but watch it fail from either the ATI X600 or the Dell 2405FPW. Try the text installer, installing everything, and reboot. No dice. Seems my RAID controller isn’t GRUB happy. So toss the RAID0 array, and re-install. Finally get it to boot, but into X, which is not working.

Reboot ‘linux single’ this time, editing /etc/inittab to start in runlevel 3. Then download the ATI drivers (never buy ATI if you want to use Linux out of the box), and try about 6 different ways to get it to work. Finally just hack the x config to tell it to use the native resolution, and finally everything seems to be working.

Now, just setting up my dev environment (svn, emacs, etc).

Linux is SO not ready for the desktop, at least as long as Dell is the number one vendor, and they ship mostly ATI, and ATI doesn’t open up their drivers. Holy Crap!

And yes, Steve, I did consider Ubuntu, but it is still downloading from the torrent, so CentOS won on sheer download speed. I am actually fairly impressed now that everything is working. The fonts don’t look bad, tabbed terminals, full firewall

More updates later, as I settle in.

Popularity: 25%

From padawan.info:

This made some data munging easy:

update tablename set field = replace(field,'search_for_this','replace_with_this');

Popularity: 20%

“You see, it’s a show about: Nothing”

http://dev.mysql.com/doc/refman/5.0/en/blackhole-storage-engine.html

Popularity: 21%

On the server

vi /etc/exports
add lines like:
/data1/sessions 192.168.0.0/255.255.0.0(rw) 10.0.0.0/255.0.0.0(rw)

vi /etc/hosts.allow
add lines like:
portmap: 192.168.0.0/255.255.0.0, 10.0.0.0/255.0.0.0

/etc/init.d/nfsd start

On the Client

vi /etc/fstab, adding the following line:
nfshostname:/data1/sessions /mnt nfs rw,hard,intr 0 0

make sure to mkdir /mnt/sessions, or it won’t work. To do it manually, just:
mount nfshostname:/data1/sessions /mnt/sessions

Helpful Links

• Setting up an NFS Server
• Optimizing NFS Performance

Popularity: 52%

I have been watching the new FeedLounge install with possibly too much attention today. Is that CPU spike a performance problem, or just a random spike? Where is that disk I/O going? Why is this machine loaded and that one mostly idle? You know the drill. Obsession to the point of losing a bit of the higher level picture.

As the obsession waned today, it seems that FeedLounge is back to an alive and usable state, and for that I am very happy. Now, however, is when the work really begins. In preparation for a larger (much larger, we hope) rollout in beta and beyond, I have to step back and start removing bottlenecks in the system. That is going to take quite a bit of measurement and design, and a lot of elbow grease to acclomplish correctly, lest we end up in the same position again, and very soon. I feel the pain of the Technoratis of the world.

I know where the current 80% problem(s) are in the architecture, and I will begin work of adding infrastructure, both in code and hardware, to alleviate the problem, so that I can then find the next 80%, and so on down the line. As FeedLounge continues to scale, I will also be putting into place key indicators to tell me when/where I may have a problem in the near future, rather than learn about yesterday’s scaling problem today.

Popularity: 38%

vi /etc/named.conf (adding master zone for newdomain.com)
cp /var/named/example.org.hosts /var/named/newdomain.com.hosts
vi /var/named/newdomain.com.hosts
kill -HUP pid-of-named

Popularity: 31%

Took all of the day, but the move was completed physically, now for all the configuration that is necessary to complete the move on the software level. Will post more on the FeedLounge blog.

Popularity: 28%

I am heading home today, and will return home late tonight to begin the second FeedLounge migration. Seems that we just did this last week, but it was actually almost 2 months ago. Wow.

The first migration was such a smashing success that we are going to be leaving the poor old alpha server melting down in a small pool of its own solder, and moving on to our own rack in a colo closer to home. Busy holiday weekend for the FeedLounge crew.

After stopping the server tonight, it goes down for one final backup, rsyncing that over to the new server. We will also be adding the DNS changes, so that the new servers are ready to go once we finish the install.

Then it is off to the colo in the morning, with a small truckload of hardware. Cabling and installation (don’t forget the cable ties) should take about 4-6 hours, and then we can stop and have a snack (dinner?).

After all the connectivity is sorted out, then it will be a sit down root-fest, making sure all the configuration is correct, nagios is all set up, etc.

Then for the test run. Start up the daemon to start working the queue, trying to catch up on the feed backlog (making sure to time it to get a feel for the new hardware).

Need to remember to take as many pictures as necessary to document the adventure, so I can share with everyone the joy that is a colo move.

Previous experience (moving the apache.org colo) tells me estimates are an impossibility to get right. One thing I did learn though: a smaller crew, or at least small crews focused on single tasks, get the job done faster than a big crew (too much concensus decision making).

Popularity: 52%

Quick Notes to self on Windows admin:

First, don’t run live virus scanners on production servers. Scheduled scans fine, but live???

Second, if you are running many production servers on VMWare, don’t run the same scheduled virus scan on every server at the same time every night. That begs for a beating from your common sense (you left it in the closet).

Third, production app servers on VMWare???? Nah, app servers don’t use that much CPU, they can share…

Popularity: 22%

InfoWorld recently talked about the TCO equation, and I was intrigued. The linux kernel (2.6) has had 19 updates in 2005, all of which would require a reboot of a Linux server. How many reboots would a windows server require in the same time period?

I navigated to the Microsoft Security Bulletin Search, searched for Important or Critical updates for Windows Server 2003 Enterprise Edition, within the last year, and the number of updates I received: 40!

Does that help the TCO equation? Not really, but at least you get answers for both sides, so you can determine the cost to you. I will make one small side note that since the last time I had to manage a set of Windows boxen, I was able to find what I needed within a minute on the Microsoft web site, so they are improving. The same search 4 years ago would have been fruitless, and I would have ended up waiting for the next service pack.

I do agree with the summary, do your own TCO calculation:

The upshot is that although you may not be able to convince your CFO to stop asking for TCO figures — and you certainly won’t stop the analysts and the software industry from serving them up — you can learn to live with TCO as a tool for justifying IT purchasing decisions. The key is to make sure that the TCO figures under consideration in your organization are your own, and not the vendors’, because only you can see the whole picture.

So, when a vendor offers you a TCO analysis, your job is not to accept it as the truth, but to find where your situation differs from the analysis that the vendor provided (never accept anything that says stuff like “on average, …”). Only then will you know how to guess TCO.

Popularity: 19%

So, you have some network infrastructure that you need to ‘keep an eye’ on, and you don’t really want to obsess over a terminal window 24×7, at least not after the first 3 weeks.

Give nagios a try. It may not be the easiest or most straightforward install on the planet, but the dividends on this particular investment are amazingly high.

I am now watching servers in 3 states and time zones, and not having to lift a finger, except when the phone wakes me up from a sound sleep with a page alert notifying me of an outage. Much better than your users letting you know via IM or email (those were the days, weren’t they, Geof?).

If there is one package that you install to increase your watchful eye over your hardware, nagios is the one I can now recommend, based on initial experience. Time will tell how that holds up.

Popularity: 26%

Say you have a case where you need to redirect all traffic from one site to some other site. For example, when your site is down temporarily for maintenance.

3 little lines is all the lighttpd config you need:
server.modules = ( "mod_redirect")
server.document-root = "/www/"
url.redirect = ( "^.*$" => "http://someotherhostname/dira/dirb/" )

The stop and start lighttpd, starting with the new config file:

lighttpd -f down.conf

Popularity: 18%

I needed IMAP support in PHP4, so I attempted to compile it in using the instructions here. I kept getting the error:

checking whether IMAP works... no
configure: error: build test failed. Please check the config.log for details.

In my configure.log, I was seeing this:

configure:43918: undefined reference to `auth_gssapi_valid'
collect2: ld returned 1 exit status

The problem was that I was trying to use imap2004e. When I found and download imap2001c as an rpm, and installed it, everything went fine. Just logging this for future frustrated sysadmins without a solution.

Popularity: 24%