I don't mean to exclude Gnome or any other desktop in this little tip, but KDE is the desktop I use most so this is one of those activities I do often, but mostly in KDE.

The problem: quite a few applications I use quite very frequently save in common file formats (plain text to be precise) but with unique file extensions (.scp and .qtr, for example). This means, therefore, that when I click on one of these files, a desktop naturally detects the plain text filetype and opens the files in a text editor like emacs or kate, rather than in the application that really wants to use them.

In other words, the desktop is doing it right. I just need to override it and tell it to do something different.

The solution:

Open the System Settings in KDE4 and either click the icon labeled File Associations, or simply search for the string File and it'll pop up in the results.

The File Associations control panel lists all known filetypes and, if you select one, the actions that will be executed if the user clicks on that filetype.

A simple example:

In the AUDIO section of my File Assocations, there is a listing for .ogg

If I click on the ogg listing, I see that the filename patterns to match this filetype are .oga, .ogg, and .spx and the applications, in order or preference, to open that filetype in is Audacious, Amarok, XMMS, Mplayer.

I think you see where I'm going with this.

If I click the ADD button in the lower left of the File Association panel, I can, yes, create my own filestypes.

So for Qtractor, which saves plain text files as .qtr, I create a new filetype called qtr in the AUDIO group. It creates a listing for me, and then I am able to go in and change the icon that will represent those filetypes, the possible extensions (*.qtr), and what application to open it in (Qtractor).

And that's how to define filetypes in KDE.

JBoss 6 can make use of a centralised java keystore to save all the passwords needed in configuration files in a single place thereby making them easier to manage and protect. No more worrying about clear-text passwords in xml files! This feature is only available to services that make use of the microcontainer for service instantiation as it uses the microcontainer annotations.

Unfortunately, although this all sounds great, there are very few service configuration files, requiring passwords, that make use of the microcontainer directly and so this cannot be used in those cases. In particular the *-ds.xml file, and the tomcat server.xml file do not use this format and a different approach is needed to protect those passwords.

How to setup centralised keystore in JBoss and setup config files to use it.

The steps to setup your keystore with JBoss and then configure services to use it are as follows:

1. Create a keystore using keytool. This will store the passwords needed by JBoss services,
2. Use <jboss-home>/bin/password_tool.sh to encrypt the keystore password in a file that JBoss can read to allow access to the password stored in the keystore. This file needs to be protected because it holds the master key
3. Add the password required by your services, such as data sources and message services to the keystore using the <jboss-home>/bin/password.sh utility.
4. Edit your service config files to refer to the keystore for its required passwords.

1 Create a JBoss keystore

First using the standard keytool from Java you create your keystore. When creating the keystore you will setup the keystore password, this is the password you will need to encrypt later for JBoss to use in step 2. By default JBoss expects:

1. the keystore to be called password.keystore,
2. located in a directory called password under <jboss-home>/bin/.
3. and that the security credentials it will use to be aliased to "jboss".

The defaults expected by JBoss can be changed by editing the property settings of the JBossSecurityPasswordMaskManagement bean defined in the <jboss-home>/server/<config>/delpoy/security/security-jboss-beans.xml file/. The command to create the password.keystore is:

keytool -genkey -alias jboss -keystore password.keystore

NB: You must use the same password for the keystore and for the jboss aliased certificate you create.

2 Encypt the keystore password for JBoss

For JBoss to be able to access the key store it needs the password for the JBoss certificate we just created. To create the encrypted file used by JBoss to store the password you use the password_tool.sh. Running <jboss-home>/bin/password.sh will bring up a text menu. It will aslo warn that the encrypted password file it expects to find does not exist. Thats ok because we are about to create it. The menu is as follows

0: Encrypt Keystore Password 1:Specify KeyStore 2:Create Password  3: Remove a domain 4:Enquire Domain 5:Exit

The first step is to create the encrypted password file so choose 0 and follow the prompts. The utility will ask for the password to encypt, this is the same as the one you used creating the JBoss certificate above. It will then create the file jboss_keystore_pass.dat under the password directory. This is the file referenced in the JBossSecurityPasswordMaskManagement bean defined in the <jboss-home>/server/<config>/delpoy/security/security-jboss-beans.xml file/.

3 Add service passwords

Now we need to create the passwords used by our services. The  password, to a service, is TOPSECRET. To add this to the keystore we can use the password.sh utility again. This time we use option 2 from the menu.

0: Encrypt Keystore Password 1:Specify KeyStore 2:Create Password  3: Remove a domain 4:Enquire Domain 5:Exit

You will be asked for the password, i.e TOPSECRET, and a domain. The domain is the alias you will use in your service files to access the correct password.

4 Update your service configuration file

Now we update the microcontainer bean file. The procedure is to replace the password property or prameter with a microcontainer annotation like

<annotation>@org.jboss.security.integration.password.Password(securityDomain=<alias you specified in step 3 above>,methodName=<propery name from the method you are replacing)</annotation>

JBoss Password Protection 

Lets hope as more services move to the microcontainer this all changes and more service make use of a centralised keystore.

One thing that UNIX historically assumes is that there are multiple users on one system. That of course has been one of its strengths for years and in fact the concept of "users", whether they are processes to be launched by the computer (like apache or backuppc or whatever) or real live human beings, has really helped define some of the power for which UNIX is best known.

For a very long time, I ran a Linux laptop and only dreamt of what a real live multi-user setup would be like. As people in my life have slowly switched over to Linux (at least part-time), and as I have started working as a Linux administrator type person, I've actually been doing the real live, serious, no-kidding this is the real deal, multi user system.

One typical situation I face is the need for some kind of shared folder on someone's computer. The situation is usually that I'll ssh into someone's home Linux computer, and drop something off for them. Could be an art file we're collaborating on, could be a #SOPA pirated movie #PIPA, a document...whatever. But we want some file that we can both access.

It's easy, of course.

First, I make a common group for us to both be in. Some systems do this already; in Slackware, you've got the users group that everyone is added to. So you can either take advantage of a pre-existing group or create a new one. They're free, so do as you please.


# groupadd trolls


Then add group membership to the users you want to share files.


# usermod -G trolls -a klaatu
# usermod -G trolls -a gort


Personally, I tend to make a special folder in an easy-to-find place, like /home/shared. Mostly I do this for the other users in my life, because I just think it's easy to get to /home and easy to describe over support calls or IM sessions, and so on. But you can make a folder anywhere:


# mkdir /home/shared


Now chown and chmod that folder so the users involved can read and write to and from it:


# chown klaatu:trolls /home/shared
# chmod 770 /home/shared


And now you've got a nice shared folder for you and your other user. I usually have the other person, assuming they're noobs, drag the shared folder to their side panel in Dolphin or Nautilus or whatever they are using, give it a nice icon, and it's like magic to them. They put stuff in there, and you get it, make changes, replace it, and they're pleased as punch. It's little touches like that, sometimes, that makes Linux feel a lot more appealing and "professional" to the noob.

I was sitting around musing about how great one of the features in GNU Linux was, and I thought "I should write a little blog post about this."

And then I thought, "But this is such a small thing...does it warrant a post about it?

And then I saw an online ad in which a major computing company was making a really big deal about how their users could now resize windows from any edge(!) and even log in and have their applications open in the state in which they last left them(!)....both features, obviously, that GNU Linux has had for Idon'tknowhowlong.

Ergo, this post.

So... Notifications.

It was even within my Linux Lifetime that this has gotten FIXED in a major way. Major enough to be called Progressive. It's a tiny thing. A really small "insignificant" feature....that makes a WORLD of difference.

I remember a while back when I would talk about this in posts and on podcasts, about how I hated when a system notification popped up on screen and you had to hunt around for it. Did it pop up under a window? hidden off in a corner? dead center screen? off to the left? to the right? Where the heck is it??

That still is the status quo for some operating systems, but in the Gnome3 and KDE4 environments, this has pretty much been solved. You don't notice it until you have to go back to another OS and have to suffer through the old style of notifications; pop up notices that come at you from all sides at random. In Gnome3 and KDE4, the notifications almost always appear in a standard location; Gnome has side-on notices at the bottom of the screen, and KDE has a notification widget that sits at the ready in your little...widget...place in the kicker.

Other OS's are presumably attempting to find the same level of finesse. Best of luck to them. Growl on my old OS is making strides, and that does help, but for the most part every application just does notifications however they choose. Meaning that the user suffers.

There are a few exceptions even in GNU Linux, which personally I'd love to see wrapped up into that centralized notification area, but every little (or big) bit helps. It is so rare now for me to be sitting in front of a GNU Linux system and be surprised by a sniper notification. They pop up where I expect them to be, they are easy to find and easy to dismiss or deal with. It makes my work seamless and efficient. Worst case scenario, a popup notification hits me by surprise but its parent window dims, making it super-obvious that a notification requires my attention before proceeding. Thank you!