Showing posts with label linux. Show all posts
Showing posts with label linux. Show all posts

2008-07-10

PostgreSQL and Grails

Just a few notes on setting up Grails with PostgreSQL and PostgreSQL accounts for JDBC connections.

First you need to have postgreSQL installed. The install varies per OS. I'll let you figure that out since there's plenty of documentation on that part.

Next you need to set up your grails application to connect to the database.

Download a PostgreSQL JDBC driver and copy it into your applications lib folder, for example: myProject/lib/pg74.216.jdbc3.jar in my set up. I don't really need to talk about setting up an application from scratch or anything do I? You've all seen that enough times right?

Next, set up your data-source for using your PostgreSQL driver...

dataSource {
pooled = false
dbCreate = "create-drop" // one of 'create', 'create-drop','update'
url = "jdbc:postgresql://localhost:5432/grails"
driverClassName = "org.postgresql.Driver"
username = "grails"
password = "grails"

// NOTE: both of these dialects have worked for me. But some people
// recommend using the net.sf version and not the org.hibernate version.
// dialect = org.hibernate.dialect.PostgreSQLDialect // honestly, not sure what
dialect = net.sf.hibernate.dialect.PostgreSQLDialect // the difference is.

}


Right now, this configuration will promptly fail. There is no grails database and no grails user. Setting one up requires a little thinking. Obviously, we need to make the grails database first. Let's get that out of the way and move to the slightly more ... confusing ... stuff.

Setting up a database and user on a fresh install requires you to be the postgres user. This is the username created by the postgres installer that the postgres daemon runs under. I have no idea what my postgres user password is so this is how I run the postgres commands to create the grails user and database...

$ sudo su
# su postgres
> createuser -P grails
> createdb grails

... as the user postgres still, we set the grails user's password ...

> psql grails
grails=# ALTER ROLE grails WITH PASSWORD 'grails' \g
grails=# \q

... and this would be ready to go except that when we try to login as grails we get an authentication error.

By default Postgres uses the authentication system of the OS for determining the identity of the user. This could be a problem if you plan on having users other than your own username or jetty/jboss/nobody use your databases. Most likely you'll want different users depending on application. So we need to modify the postgres configuration files to allow for users other than the console users to login.

The configuration files are found in /var/lib/pgsql/data or other data directory depending on your specific setup. The file for controlling authentication policies is pg_hba.conf. It is pretty well documented on its own and by default the "method" for authentication is set to ident meaning that if I am username "fred" then I can only use the database as "fred" even if I'm running the application "grails".

So for local and host users to login as a password authenticated user we need to set the "method" to password instead. I've set my pg_hba.conf to read...
# TYPE  DATABASE    USER        CIDR-ADDRESS          METHOD
# "local" is for Unix domain socket connections only
local all all password sameuser
# IPv4 local connections:
host all all 127.0.0.1/32 password sameuser
# IPv6 local connections:
host all all ::1/128 ident sameuser

... allowing a user from local host to login using a username and password pair. I restart postgres (as my own username not postgres)

$ sudo /etc/init.d/postgresql restart

... and now from my shell I can login as the grails user to the grails database...

$ psql -U grails grails
Password for user grails:

... and I supply the password grails and I'm logged in. That means this time when I start my grails project with grails run-app the grails user will authenticate and now my grails project can use postgres for development against the postgres database and we can work against postgres on our development machine.

EDIT:
Your whole Grails configuration file (as of Grails 1.1) should look like this

/**
* The top dataSource holds configuration options for ALL
* environments... I'm presuming you want PostgreSQL in all
* your environments but you may want to use the default
* Hypersonic database in development and testing instead.
*/
dataSource {
pooled = true
driverClassName = "org.postgresql.Driver"
// dialect = org.hibernate.dialect.PostgreSQLDialect
dialect = net.sf.hibernate.dialect.PostgreSQLDialect
}
hibernate {
cache.use_second_level_cache=true
cache.use_query_cache=true
cache.provider_class='com.opensymphony.oscache.hibernate.OSCacheProvider'
}
// environment specific settings
environments {
development {
dataSource {
// one of 'create', 'create-drop','update'
dbCreate = "create-drop"
url="jdbc:postgresql://localhost:5432/dev"
username = "dev"
password = "dev"
}
}
test {
dataSource {
dbCreate = "update"
url="jdbc:postgresql://localhost:5432/test"
driverClassName = "org.postgresql.Driver"
username = "tester"
password = "tester"
}
}
production {
dataSource {
dbCreate = "update"
url="jdbc:postgresql://localhost:5432/grails"
username = "grails"
password = "grails"
}
}
}

2008-01-16

Behold the Power of Pipe!

This is a repost of an article on pipe I posted several years ago. Pipe is a very powerful tool, behold:

tar -czf - [list of dirs and files] | \
ssh [user]@[server] "cd /path/to/place/files; tar -xzf -"


I learned this one from one of my bosses a few jobs back. There are a few unixy tricks in that command that took me a while to grasp. I've been using this trick for years now and I thought perhaps you would like to see it.

You create a tar archive and specify the file "-" which is your standard out. Then you list the dirs and files you wish to grab. Since the compressed tar is being sent to stdout you can catch it with a pipe "|" and send it to ssh (the "\" is just a way of breaking a command between lines).

With ssh we log into a server as a given user. Then we ask ssh to run a command for us. Since the ssh session will login to the machine at the user's home dir we ask the command session to change to a path, then run the tar command. This time we are extracting the tar archive we caught with pipe by specifying the file "-" to the tar command.

The result is that the files get tarred, compressed, and shot over the network to a remote machine which then immediately untarrs decompresses and drops the files in place. We let tar do all the work of error handling and handling non-regular files, compression is optional, and there are no archives left over.

If, however, we wanted to create a remote archive without ever consuming storage on the local machine we could instead do this:

tar -czf - [list of dirs and files] | \
ssh [user]@[server] "cat > /path/to/place/file.tar.gz"

If processing power was limited on the local machine then we could do this:

tar -cf - [list of dirs and files] | \
ssh [user]@[server] "gzip -c > /path/to/place/file.tar.gz"

2007-11-11

3D Linux Desktop

I use a 3D Linux desktop to do my work in. I have a dual monitor setup at work and a nice high-resolution single monitor (shown) at home. The 3D desktop doesn't just give my work a nice sheen of eye-candy it also gives me valuable feedback on the health and status of my OS.

For one thing a busy application gets dimmer and gray in my desktop. So if my browser is busy it doesn't just stop responding to my clicks, I'll know its working hard well before that... I'll see it dim and go gray. If something really bad happens it will burst into flames. A moving application wobbles as it refreshes itself making the move feel substantial.

The 3D cube is a more natural way to deal with multiple desktops. I've been using 4 desktops in KDE for about a decade. But, it was easy to get lost on the desktops since they had no real spatial relationship to each other. This same feature has been ported to Windows and OSX so I'm sure many people are now enjoying multiple desktops. As far as I know these are UI changes that appeared on Linux first.

If you haven't seen Beryl yet you should. I think Beryl and Compiz could revitalize Linux on the desktop.

2007-10-17

Linux Forgotten Root Password

Oh no, you've forgotten the root password to your laptop or other Linux desktop.

If they are set up with grub all is not lost. At the grub splash screen key in 'e' for edit. You'll now be able to edit the boot options. Select the line with the kernel on it and add the word 'single' as the last parameter. When you hit enter the edit mode will exit. Striking the 'b' for boot command will boot this configuration and your kernel will boot into the magical single user mode where you can type 'password' to change root's password without having to know what that forgotten original password was.

Now you can use the awesome power of root to change the other forgotten passwords on the system. If you think this presents a security hole and don't want to allow 'e' from the grub splash... you can secure grub with a password.

2007-09-17

Binding JBoss


$ /usr/local/jboss/bin/run.sh -b `hostname` 1>&2>/dev/null &


Binds JBoss to `hostname` on port 8080 and ignores the standard output and standard error.

2007-08-11

The rising star: SUSE

Deals like this one with AMD just highlight the business savvy that Novell has brought to the Linux playing field. This isn't nearly as big a deal as the Novell and Microsoft deal that made such a fuss in the community. But, it does play in nicely with my previous post about the SUSE distribution's future dominance.

Installing, administrating, and generally just living with SUSE is much easier than any other distribution. SUSE reproduces their custom GUI interface for system administration faithfully in an nCurses environment. That means that if you have neophyte system administrators you brought over from a Windows shop you can teach them the GUI administration techniques and everything stays the same even when the system is running headless. The same YAST administration tools are present on SLES, SLED, and OpenSUSE.

If redhat would learn one thing from SUSE it should be consistency of administration. Consistent easy administration for neophyte system administrators. Consistent easy administration through all their distributions. SUSE does this well, redhat does not.

I live thirty minutes from redhat's headquarters but I use SUSE.

2007-08-09

SLES10 hands down

In my mind SuSE wins hands down. OpenSuSE and SLES10 are the best enterprise Linux distributions our there and I don't even think about RHEL in production.

Why? No other distribution hits this sweet spot of utility properly:
  1. make cloneconfig - beautiful, make a kernel config exactly like your running config without any worries
  2. yast2 +/- gui - easy to learn sysadmin tasks... low training and pain threshold
  3. autoYast - easy to clone installs
  4. LDAP / ActiveDirectory integration - integrate and play nice with Windows domains so easy a newbie could do it!
  5. centralized patching - keep your systems patched from one patch repository
  6. "plays nice with VMware"
  7. profile.local - put your localized custom configurations in *.local files along side the distribution files... end the Gentoo configuration file merge nightmare by keeping your localized configuration files separate.
Linux is Linux, you can do all these things on any distribution you just have to figure out how. With SuSE you don't have to figure any of this practical system administration stuff out.

2007-08-08

My Linux Desktop

In order to get to work I set up the following custom software:

  1. java 1.6
  2. groovy 1.1
  3. grails
  4. eclipse 3.2
  5. jboss 4.2.1
  6. ie4linux
  7. crossover office
  8. beryl
  9. vmware player with a Windows XP image


Everything else I take as default from the distribution. I evaluated distributions and picked one where it was easiest to set up the distribution to work well in a windows dominated environment.

2007-07-29

Symbolic Link Joy

Let's say you have a server. It runs the frobnicate service. The problem is you have to upgrade the frobnicate service every so often. Sometimes you have to "roll back" to an old version.

What to do?

Lately I've been thinking like this:

$ cd /usr/local/
$ mkdir frobnicate-dist
$ cd frobnicate-dist
$ install frobnicate1
$ install frobnicate2
$ ln -s frobnicate2 current
$ cd /usr/local
$ ln -s frobnicate-dist/current frobnicate


The result is that /usr/local/frobnicate is our currently running frobnicate. If you need to change the currently running frobnicate... change the frobnicate-dist/current and all frobnicate versions are in the /usr/local/frobnicate-dist directory.

Perhaps frobnicate-versions?

Just a thought.

2007-07-13

Suse Java5 install notes

I wrote this tutorial a while ago for our services group to help them setup Java on our production servers.

If you are on OpenSuSE
:


Open yast2 (CLI or GUI), and choose Software -> Software Management, next you'll search for java. Find a version of java that is 1.5.0_06 or better and install it. If java version 1.5 is not in your list then you'll have to add on more software sources (see: AddingSoftwareSources) then try again.

If you are on SLES10:

Download the Java EE 5 SDK from java.sun.com and follow the install instructions. Install path should be /usr/lib/jvm/ you could have the installer drop the jvm in a temporary location and then move it to /usr/lib/jvm/ later.

Note: Just because Java 5 is installed does not mean it is active.

A Standard Java Directory


If you are manually working with distributions of Java without an installer, all versions of java should end up in the /usr/java directory. Then you create two symbolic links... the "default" and the "latest" link. When linking the java binaries make sure to use the link passing through the /usr/java/default symbolic path. That way you can change which java the system is using by default simply by changing the default link in /usr/java without following the rest of the instructions for /etc/alternatives

$ ls -l
total 1
lrwxrwxrwx 1 root root 11 2007-06-13 14:33 default -> jdk1.5.0_09
drwxr-xr-x 9 root root 376 2006-10-12 16:01 jdk1.5.0_09
drwxr-xr-x 10 root root 472 2007-04-23 15:29 jdk1.6.0_01
lrwxrwxrwx 1 root root 21 2007-04-23 15:29 latest -> /usr/java/jdk1.6.0_01
This advice only applies if you don't already have a /usr/lib/jvm directory or you aren't relying on RPMs to manage your java versions. I believe later versions of OpenSuse have started to ship with RPMs that set up this /usr/java directory structure. Either way I'll point you at either /usr/lib/jvm or /usr/java as standard directories to use.

Manipulating the Distro

Fortunately, the SuSE distribution maintainers at Novell have done a good job of separating out the symbolic links for various programs, java being one of them. To activate one version or another of java in the SuSE distributions we can take advantage of the /etc/alternatives directory. By changing the sym links in this directory you change the active version of these programs.

Try the following:

$ whereis java
java: /usr/bin/java /etc/java /usr/lib/java /usr/share/java /usr/share/man/man1/java.1.gz
$ ls -hal /usr/bin/java
lrwxrwxrwx 1 root root 22 2006-06-29 16:06 /usr/bin/java -> /etc/alternatives/java
$ cd /etc/alternatives/
$ ls -hal java*
lrwxrwxrwx 1 root root 35 2006-07-05 10:04 java -> /usr/lib/jvm/java-1_4_2-sun-1.4.2.11/bin/java
lrwxrwxrwx 1 root root 37 2006-08-25 09:53 javac -> /usr/lib/jvm/java-1_4_2-sun-1.4.2.11/bin/javac
lrwxrwxrwx 1 root root 39 2006-08-25 09:53 javadoc -> /usr/lib/jvm/java-1_4_2-sun-1.4.2.11/bin/javadoc
lrwxrwxrwx 1 root root 37 2006-08-25 09:53 javah -> /usr/lib/jvm/java-1_4_2-sun-1.4.2.11/bin/javah
lrwxrwxrwx 1 root root 37 2006-08-25 09:53 javap -> /usr/lib/jvm/java-1_4_2-sun-1.4.2.11/bin/javap
lrwxrwxrwx 1 root root 37 2006-07-05 10:04 javaws -> /usr/lib/jvm/java-1_4_2-sun-1.4.2.11/bin/javaws

Uh oh. We have the wrong version of java active. Is Java 5 even installed?

$ cd /usr/lib/jvm/
$ ls
java java-1.4.2-sun java-1.5.0-sun jre jre-1.4.2-sun jre-gcj
java-1.4.2 java-1_4_2-sun-1.4.2.11 java-1.5.0-sun-1.5.0_06 jre-1.4.2 jre-1.5.0 jre-sun
java-1.4.2-gcj-1.4.2.0 java-1.5.0 java-sun jre-1.4.2-gcj jre-1.5.0-sun

Yes it is. I see java-1.5.0-sun-1.5.0_06 and that's just the java we need. Let's see what binaries we have...

$ cd java-1.5.0-sun-1.5.0_06/bin
$ ls
appletviewer HtmlConverter java javap jdb jsadebugd keytool native2ascii rmic servertool
apt idlj javac java-rmi.cgi jinfo jstack kinit orbd rmid tnameserv
ControlPanel jar javadoc javaws jmap jstat klist pack200 rmiregistry unpack200
extcheck jarsigner javah jconsole jps jstatd ktab policytool serialver

... these are the binaries we're going to symbolically link in /etc/alternatives. But, there are already symbolic links in the way we'll need to remove them and then set come back here to recreate the links.

$ pushd .
/usr/lib/jvm/java-1.5.0-sun-1.5.0_06/bin /usr/lib/jvm/java-1.5.0-sun-1.5.0_06/bin
$ cd /etc/alternatives
$ sudo rm `ls /usr/lib/jvm/java-1.5.0-sun-1.5.0_06/bin`
password:
$ popd
$ pwd
/usr/lib/jvm/java-1.5.0-sun-1.5.0_06/bin
$ sudo ln -s * /etc/alternatives/
$ cd /etc/alternatives
$ ls -hal java*
lrwxrwxrwx 1 root root 35 2006-07-05 10:04 java -> /usr/lib/jvm/jre-1.5.0-sun/bin/java
lrwxrwxrwx 1 root root 37 2006-08-25 09:53 javac -> /usr/lib/jvm/java-1.5.0-sun/bin/javac
lrwxrwxrwx 1 root root 39 2006-08-25 09:53 javadoc -> /usr/lib/jvm/java-1.5.0-sun/bin/javadoc
lrwxrwxrwx 1 root root 37 2006-08-25 09:53 javah -> /usr/lib/jvm/java-1.5.0-sun/bin/javah
lrwxrwxrwx 1 root root 37 2006-08-25 09:53 javap -> /usr/lib/jvm/java-1.5.0-sun/bin/javap

And now we have the right symbolic links in place. Test the default version of java:


$ java -version
java version "1.5.0_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
Java HotSpot(TM) Server VM (build 1.5.0_06-b05, mixed mode)


good. Now we have the right version active.

NOTE: The Novell software that depends on Java 1.4 should be smart enough to pick out the right JVM for itself given the /usr/lib/jvm directory structure. We've just set the default java to 1.5.0_06 which works fine with our JBoss tools. If there is a problem in the future, knowing where the other JVM are located will be valuable. The word on the street is that Novell's QA couldn't finish their last round of testing in time for release.

NOTE: the environment variable $JAVA_HOME must point to the home directory of the Java install

2007-07-11

The joy of symbolic links

I'm working with different versions of JBoss. My company has standardized on /usr/local/jboss as the home directory for JBoss. All JBoss servers will find their homes under /usr/local/jboss but we upgrade JBoss servers about once a year. As a developer often I'm swapping between production and test environments switching between JBoss versions.

For example today we are going to production with JBoss 4.0.5 but we are moving forward on JBoss 4.2.0 and I need to swap between the different versions for different projects. Now we already use symbolic links in production. Let me show you how those work.

The directory /usr/local/jboss is actually a symbolic link made like this:

$ sudo ln -s /usr/local/jboss-4.0.5 /usr/local/jboss

If we upgrade to jboss-4.2.0 I can simply remove the symbolic link and point it at the new directory like this:

$ sudo rm /usr/local/jboss && sudo /usr/local/jboss-4.2.0 /usr/local/jboss

And now my server is upgraded and there is an easy way to "fall back" should I need to.

But what if I'm a developer?

For my developer set up I'll head off to my home directory and then I'll make a JBoss directory where I'll keep all the various versions of JBoss that I'm using. I'll have a ~/jboss/jboss-4.0.5 and a ~/jboss/jboss-4.2.0 for example.

Next I'll make a symbolic link...

$ ln -s ~/jboss/jboss-4.2.0 ~/jboss/current

... and then I'll make one more symbolic link ...

$ sudo ln -s ~/jboss/current /usr/local/jboss

Now when I need to change my current working version of jboss...

$ rm ~/jboss/current && ln -s ~/jboss/jboss-4.0.5 ~/jboss/current

2007-06-05

Path to Linux happiness: keep it tiny

The number one piece of advice I have for anyone trying to use Linux is: "Only install what you need to survive!" The reason is simple. The more packages you install the more likely it is you'll run into some kind of conflict. The more packages you install the more potential patches you'll need. The more you install the less drive space you'll have.

Keep your Linux install small. If you need that industrial strength hair dryer go ahead and pack it along, but be prepared to ditch something else. For example if you need Beryl you may need to avoid certain graphics packages.