Nerd Notes

/dev/brain: no space left on device

Archive for October 2006

gpasswd and less +F

leave a comment »

Before I knew about gpasswd, I used to add and remove users from groups using a combination of “usermod -G” and some cut and paste in the terminal window. I was even using sed to automate the command. That is now a thing of the past.

Most modern linux distributions have a gpasswd command (at least Gentoo and Ubuntu do have it). Adding a user to a group is as easy as:

# gpasswd -a username groupname

Removing is just a matter of changing the -a switch (add) into -d (delete):

# gpasswd -d username groupname

Another useful thing I discovered recently is the “follow mode” of less, which works like a tail -f. If you want to launch less in “follow mode”, you just have to add the +F switch, as in:

# less +F /var/log/messages

If you want, at any time, to scroll back through the backlog, you just have to interrupt the follow mode typing C-c (that is: control+c). Also, you don’t need to start less in follow mode to use the follow mode: you can just press F at any time within less to turn the follow mode on.

Advertisements

Written by Mirko Caserta

October 31, 2006 at 11:10 am

Sun One Webserver 6.1SP3 on Ubuntu Edgy

with 3 comments

Okay, so, from time to time, I do pretty lame things too. I was trying to install Sun One Webserver 6.1SP3 on my Ubuntu Edgy laptop at work and, when launching the installer I got:

$ sh setup
/home/mcaserta/tmp/.setup: error while loading shared libraries: libstdc++-libc6.2-2.so.3: cannot open shared object file: No such file or directory

“This is an easy one”, I thought. I recalled the days when installing a recent Sun JDK on a Debian system required you to install a compatibility package such as libcompat-something or libstdc-something. So I fired up synaptic and made a search for both. I couldn’t find anything.

I said to myself: “If I make a couple symlinks, I can fool the system into thinking it’s got the library it requires and make it use the default one”. So, I did an:

$ sudo ln -s /usr/lib/libstdc++.so.6.0.8 /usr/lib/libstdc++-libc6.2-2.so.3

After this, the setup software started spitting out to me all sort of missing library files errors, which I tried fixing using the same principle as above.

After an hour of symlinking in pain, I went looking for the libcompat Ubuntu package and I found out it’s in Edgy in the universe repository. So, I went into synaptic, hit the repositories setup in the settings menu and enabled all available repositories. I had them all enabled before the Edgy upgrade but, apparently, the upgrade has disabled some of them.

I shut down synaptic and fired an:

$ sudo apt-get install libstdc++2.10-glibc2.2

and everything went fine since then, except that trying to launch the admin server results in a core dump and I’m looking into that right now.

Written by Mirko Caserta

October 30, 2006 at 11:54 am

Making vim syntax highlighting usable

with 13 comments

Someone says vi vi vi is the editor of the beast. He’s right. That’s why I use vim, which is a modern editor, backwards compatible with vi and full of bells and whistles. But, most of all, vim gets things done for me. I’m in love with vim.

On some modern linux distributions, vim comes with syntax highlighting enabled by default. Since you’re a die-hard nerd like me, your terminal window colors scheme is like god meant it to be: with a black background. And, if you really feel nostalgic like me, you may even have gone one step further and you’ve setup green as the foreground color. That’s great, but there’s one thing that makes vim syntax highlighting suck on such a color scheme: it was meant by default to work on a light (read white) background.

My colleagues hate vim’s default color highlighting and they’re tempted all the time to use the old beast: vi, just because it has no color syntax highlighting which makes comments unreadable to say the least. This should get fixed. Enter the gay world with: set background=dark That means, while in vim, enter command mode and type the above command.

Great! The world has suddenly become clearer and you feel an urge to dance to the rhythm of Village People’s YMCA. That is, until you close vim and open it again. Then you’re into Robert Smith mode again. Too bad. We’ve got to fix that too. The recipe is as easy as editing your ~/.vimrc or, better yet, making the change system wide by editing the /etc/vim/vimrc file and adding a couple lines:

syntax on
set background=dark

That’s it. Now, where’s my biker dress?

Written by Mirko Caserta

October 27, 2006 at 7:48 am

Configuring a BEA Weblogic 8.1 cluster address, more

with 3 comments

If you are lucky enough to start from scratch, the config wizard that comes with Weblogic 8.1 lets you specify a cluster address in one of its steps. If you instead happen to already have a configured Weblogic 8.1 cluster and you need to customize the cluster address, you’ll need to modify the config.xml file for your domain.

The default <Cluster … > element in the config.xml file looks like this:

<Cluster ClusterAddress="node1,node2" Name="myCluster"/>

but Weblogic really reads it as it would look like:

<Cluster ClusterAddress="node1,node2" Name="myCluster"
MulticastAddress="237.0.0.1" MulticastPort="7001" />

because that is the default ip address and port combination if you don’t specify one.

It should be pretty evident how to customize the address now.

As a sidenote, I noticed the freshly installed runner shell scripts that come with the default configuration template, do not embed the username and password needed to access the server administration console (which is a good thing from a security standpoint). Sometimes, because you are in a stage environment and you don’t really care too much about security, you want to embed the credentials in the scripts so that, when launching the server instances, you’re not going to be prompted for them. This can be done in the startManagedWebLogic.sh script that you can find in the domain directory. The variables you need to set to avoid being prompted for passwords are:

  • WLS_USER
  • WLS_PW

Another interesting variable you can tweak is MEM_ARGS in the $WL_HOME/common/bin/commEnv.sh file. What you specify here gets passed as an argument to the JVM interpreter which runs the server instances. Suppose you want to get a bigger heap size, say 1GB:

MEM_ARGS="-Xms1024m -Xmx1024m -XX:MaxPermSize=256m -XX:NewRatio=4 -XX:SurvivorRatio=4 -XX:TargetSurvivorRatio=80 -XX:+DisableExplicitGC"

The other VM options are pretty much ninja jargon to me right now so I’m not going to talk about them. But if you really need to dig in, do it here.

Written by Mirko Caserta

October 25, 2006 at 3:00 pm