bryans-list 3.0 Blogs are the new mailing lists

IIS7 URL Rewrite module – things to know

Things not immediately obvious that you should know about the IIS7 URL Rewrite module, based on our experience at $work and the results of the support call we put in to Microsoft.

1. There have been different packages of version 1.1 of the module over time, all with the same name. The only way to know which one you have is to check the DLL version. The most current DLL version in the URL Rewrite 1.1 package is 7.1.490.43. It is unclear at this point if Microsoft will do the same with v2.0 of the module, as it is still a Release Candidate. We have asked if they can properly identify the packages so we'll know when one contains a new DLL.
2. URL Rewrite has a memory leak, which appears to be something related to caching URLs. The leak is very bad in v1.1 of the module, and significantly improved but seems still present in v2.0 of the module. If you use URL Rewrite with many rules on a high traffic site you will see memory usage on IIS worker processes (w3wp.exe) grow. If you are using 32-bit worker processes performance will start to degrade after passing about 3Gb in size. Until we could find a solution to the memory leak, we worked around it by forcing a recycle of the application at 2Gb allocated.
3. Microsoft recommends that a work-around for the memory leak in version 1.1 of the module is to use version 2.0 of the module. Although version 2.0 is not yet released (still Release Candidate), they indicate it is supported as production code (ie, you can open support tickets about it). We have found version 2.0 does seem to still have a slower leak, but our worker processes now recycle based on our normal time windows instead of allocated memory size. We are still testing v2.0, so have not yet revisited the memory leak issue with Microsoft.
4. URL Rewrite rules set at the server-level (ie, top level, not in an individual site) are copied to every worker process. This means any requests for a given site must go through all server-level and then all site-level rules you have defined, even if they don't match any server-level rules. Keep this in mind when defining server-level rules, especially on a server handling multiple high-traffic sites.

That's enough for now, maybe more later.

Ubuntu – rssh – sftp only, with chroot

Here's how to setup rssh on Ubuntu, to allow sftp only with a chroot directory. Note that these instructions are for Ubuntu Server 9.04 x64, other versions may require changes.

First, add the rssh package.

sudo apt-get install rssh


Second, edit /etc/rssh.conf. Uncomment the #allowsftp line and one of the #chrootpath lines, and set the chrootpath to wherever you want your top-level chroot directory.

Third, modify or add whichever users you want to access using sftp and set their shell to /usr/bin/rssh.

Fourth, setup the chroot environment, which includes copying the following from the main system into your chroot directory:

./etc/ld.so.cache
./etc/resolv.conf
./etc/ld.so.conf.d/x86_64-linux-gnu.conf
./etc/ld.so.conf.d/libc.conf
./etc/ld.so.conf
./etc/passwd
./etc/group
./etc/nsswitch.conf
./etc/rssh.conf
./usr/bin/rssh
./usr/lib/libgssapi_krb5.so.2.2
./usr/lib/rssh/rssh_chroot_helper
./usr/lib/openssh/sftp-server
./usr/lib/libk5crypto.so.3.1
./usr/lib/libkrb5support.so.0.1
./usr/lib/libkrb5.so.3.3
./lib/libutil-2.9.so
./lib/libz.so.1.2.3.3
./lib/libpthread-2.9.so
./lib/libdl-2.9.so
./lib/libnsl-2.9.so
./lib/libcrypt-2.9.so
./lib/ld-2.9.so
./lib/libresolv-2.9.so
./lib/libnss_files-2.9.so
./lib/libc-2.9.so
./lib/libkeyutils-1.2.so
./lib/libcom_err.so.2.1
./lib/libnss_compat-2.9.so
./lib/libcrypto.so.0.9.8

Additionally, setup these links, again copying what's setup in the main system.

./usr/lib/libkrb5support.so.0
./usr/lib/libgssapi_krb5.so.2
./usr/lib/libk5crypto.so.3
./usr/lib/libkrb5.so.3
./lib/ld-linux-x86-64.so.2
./lib/libutil.so.1
./lib/libkeyutils.so.1
./lib/libnss_files.so.2
./lib/libnsl.so.1
./lib/libcom_err.so.2
./lib/libdl.so.2
./lib/libc.so.6
./lib/libz.so.1
./lib/libresolv.so.2
./lib/libpthread.so.0
./lib/libnss_compat.so.2
./lib/libcrypt.so.1
./lib64


You may want to strip out users/groups you don't want visible from the etc/passwd and etc/group files.

Fifth, create a dev directory in your chroot directory, then create a /dev/null in it as follows.

mknod -m 666 dev/null c 1 3


Sixth, edit /etc/default/syslogd and update the SYSLOGD="" line as follows.

SYSLOGD="-a /[chroot dir]/dev/log"

Then restart syslogd.

sudo /etc/init.d/sysklogd restart


Finally, test.

Note that if you add users/groups to the system /etc/passwd and /etc/group files they will need to be copied again (possibly just the new lines) into the appropriate files in the chroot directory's etc.

References:
Linux Configure rssh Chroot Jail To Lock Users To Their Home Directories Only

OpenNMS and WMI – Part 2, adding more monitors

In the last post about OpenNMS and WMI I covered how to get the WMI monitors included with OpenNMS up and running. Now I'll cover adding new monitors.

I'll provide an example that I setup to pull HTTP request data from the W3SVC counters and graph it. Step by step, here we go.

First step is to figure out which WMI objects you want to monitor. I'm mostly interested in performance counters, because that's my primary need for WMI, but you could also just monitor the value of any WMI object. As I posted recently, Powershell can be a great tool for digging into WMI and finding the class names and available values.

Second, if whatever monitor you're collecting has multiple entries per server, you'll need to setup a resourceType entry in datacollection-config.xml. This basically creates a hierarchy for the data you're collecting that can be retreived when graphing, I'll discuss more about this below. Here's my example config chunk. Note that the resourceLabel is populated from the data you collect.

OpenNMS and WMI – Part 1, getting started

I've setup and used OpenNMS at my last job and my current job, and it works very nicely. One thing I haven't done until last week, though, is get WMI monitoring/graphing working properly. WMI is the Windows Management Instrumentation API, and it gives you access to all sorts of internals on a Windows box. In my case, I want to access performance counters, particularly for IIS and ASP.NET.

Support for WMI is added in OpenNMS 1.7, which is still technically the unstable version -- but it should be released as 1.8 any day now. I'd put it as late beta quality at worst, and if you've found this post via Google the final 1.8 version has probably already been released.

However, as 1.7 is still unstable, the documentation for all the new features, like WMI, is a bit sketchy. The OpenNMS wiki page is here, and it'll get you about 80% through turning on WMI, but doesn't really tell you what to do from there to actually start collecting data and setting up your own checks. Admittedly a lot of the OpenNMS documentation is like that, you have to rely a lot more on the examples and mailing list discussion than the formal documentation.