Windows Server 2008 R2 Server Core as a Print Server

I had to setup a new print server today, and though Windows Server Core would be appropriate. As I typically administer Linux boxes, it seemed like a good idea.

I was able to get the server installed, setup, and joined to AD in a relatively short amount of time. In fact I only had to issue 9 commands before I was finished. This is on par with what I need to setup Linux servers. It gave me a warm fuzzy feeling I hadn't had since the days of MS DOS 6.22.

Then it came time to manage this server using Microsoft's Print Management Server. My setup is a 64-bit Enterprise Windows 7 workstation, and my Windows Server 2008 r2 box was also 64-bit. I was able to connect to the print server, install a handful of 64-bit printer drivers and install the TCP/IP printer ports.

I hit a wall while trying to add a printer. Why? It appears that the "Add Printer" wizard in the Print Management MMC console only knows how to list 32-bit drivers! This was very very annoying. I had to setup and install an entirely separate 32-bit Windows 7 Enterprise workstation, join it to the domain, and install 32-bit drivers via Print Management console before I was able to "Use an existing printer driver on the computer".

Come on Microsoft, 64 bit operating systems have been around for over 10 years! Why do you have to continue to force 32-bit requirements down our throat?

Moral of the story. Use a 32-bit machine for the Print Management console. 64-bit just isn't up to spec yet.

Multiple Grails Apps on a single App Server

Background

Historically I've used Glassfish v2 for hosting many of my Java Web Apps. Lately I've been developing in Grails When it comes to deploying these applications on a production server, the memory requirements are a bit higher than simple JSF applications. Once I had deployed a half dozen or so Grails apps to my production server strange things started to occur such as applications suddenly stopping. I eventually tracked these down to Perm Gen, and Heap memory errors. Through this process I learned that I hate Glassfish's log files (or lack there of).

Goals

A dedicated Tomcat 6 server to host my Grails apps.

The "Hardware"

This server will be a multi-core machine with 4GB of RAM. I'm running it as a VMware virtual host, but a physical machine won't be too different.

The Operating System

Start with the Ubuntu Server 9.10 64-bit install ISO
For most of setup, the standard answers apply except where noted.
Because the host is a virtual machine, at the boot loader screen I choose to hit 'F4', and selected "Install a minimal virtual machine" as the setup type.
For disk partitioning, I always use LVM.
When the installer gets to the "Software Selection" screen, enable OpenSSH Server, and Tomcat Java Server

Tomcat Settings

Pay close attention to this section. This is where you need to configure your memory setting appropriately. Most grails applications need at 64 MB of PermGen space each, and somewhere around 64-128MB of

Add the following options to /etc/defaults/tomcat6

# change the default garbage collector
TOMCAT6_SECURITY=no
# Tell the JVM we're "headless"
JAVA_OPTS="-Djava.awt.headless=true"
# Set the Memory Pool Size
JAVA_OPTS="$JAVA_OPTS -Xms2048m -Xmx2048m"
# Set the PermGen Size
JAVA_OPTS="$JAVA_OPTS -XX:PermSize=1024m -XX:MaxPermSize=1024m"
# change the default garbage collector to
# The "recommended" garbage collector for Web Servers
JAVA_OPTS="$JAVA_OPTS -XX:+UseConcMarkSweepGC"

Remote Management

Setup Tomcat Users so you can use the manager app by editing /etc/tomcat6/tomcat-users.xml

<tomcat-users>
   <role rolename="admin">
   <role rolename="manager">
   <user username="yourusername" password="SecretPassword" roles="admin,manager">
</tomcat-users>

Grails and MS-SQL Server

When using Microsoft SQL Server as the back-end database for a Grails project, the default hibernate mappings create primary key id columns of type numeric (which can be annoying).

This is because the MSSQL server Dialect is designed to support MSSQL Server versions older than 2000. MSSQL Server 2000 and later has support for BIGINTs, and therefor doesn't need to store it's primary keys in numeric columns.

The fix for this is to create a new SQL Server Dialect for SQL Server 2000 and later. We do this by creating the following file in our Grails project

src/java/org/hibernate/dialect/SQLServer2000Dialect.java

Containing the following code

package org.hibernate.dialect;
import java.sql.Types;

public class SQLServer2000Dialect extends SQLServerDialect {
 public SQLServer2000Dialect() {
  super();
  registerColumnType(Types.BIGINT, "bigint");
  registerColumnType(Types.BIT, "bit");
 }
}

Then we edit our DataSource.groovy that's located under grails-app/conf so that it uses our new dialect.

dialect = "org.hibernate.dialect.SQLServer2000Dialect"

And wala! Our primary keys are bigints!

What this also means is that grails will also set the primary key to be identity columns rather than the not quite as useful hilo algorithm.

Grails and Date Inputs

I've been rather frustrated with the datePicker input tag for grails lately. For anyone who writes software for people who do data entry 8 hours a day, 5 days a week, you know that picking a date from pull-down menus, or via a calendar navigation such as the calendar plugin for grails is a huge waste of time and very slow.

To resolve this I've taken the approach of using textInput tags for the dates

<g:textfield name="birthDate" size="12" maxlength="10" value="${personInstance?.birthDate?.format('MM/dd/yyyy')}" class="datePicker" />

And using jQuery UI to add a calendar control to the inputs so that if the user wanted to, they can use a datePicker

// Turn all textFields of class 'datePicker' into jQuery.UI.calendar controls
jQuery(document).ready(function(){
 jQuery('.datePicker').datepicker({
  showOn: 'button',
  buttonImage: '/myapp/images/calendar.gif',
  buttonImageOnly: true });
});

Then, because the default date format for text inputs in grails is yyyy-mm-dd hh:mm:ss, which is not the most common format entered for dates in my demographic (US), I added a customPropertyEditorRegistrar in grails-app/conf/spring/resources.groovy

beans = {
 customPropertyEditorRegistrar(util.CustomPropertyEditorRegistrar)
}

and then in src/groovy/util/CustomPropertyEditorRegistrar.groovy

package util

import java.util.Date
import java.text.SimpleDateFormat
import org.springframework.beans.propertyeditors.CustomDateEditor
import org.springframework.beans.PropertyEditorRegistrar
import org.springframework.beans.PropertyEditorRegistry

public class CustomPropertyEditorRegistrar implements PropertyEditorRegistrar {
 public void registerCustomEditors(PropertyEditorRegistry registry) {
  registry.registerCustomEditor(Date.class, 
   new CustomDateEditor(new SimpleDateFormat("MM/dd/yyyy"), true));
 } 
}

And then I'm happier, and the data entry staff that need to use my applications are happy.

Dell's OptiPlex 160 - Not that great for linux

The idea of a silent, dual-core, 64 bit solid state workstation seemed brilliant to me at first. I ordered up one of these little machines along with a 16 GB solid state drive and two 2GB DIMMS. I install Ubuntu Workstation 8.10 on it, and away I went.

These one drawback of this machine, which is why I'm not recommending it for use as a Linux workstation, is the video chipset. It comes with a proprietary SiS AVG 771 chipset that has very poor linux support. I've only been able to get basic 2D working at 1600x1200, and only through the VGA port. The DVI port refuses to run at anything higher than 800x600. 3D and 2D acceleration refuse to work.

I have since upgraded the machine to Ubuntu 9.10, but the graphics chip shortcomings still apply.

Next time I go looking for a solid state machine such as this, I'll ensure it has an Intel GPU in it, or at the very least an nVidia or ATI chip.