The First File

This was more work than I thought it would be.

You'd think that someone who has been doing software as long as I have would know better but nooo!  I thought that the first few classes would write themselves.

It took me several hours.

And the worst thing is that it's still not done.

I meant for this blog to be a kind of developer's diary.  And it's already shaping up to be a catalog of my erm challeges

Miranda

After a 7 year hiatus I'm back with a new project...Miranda.

Miranda will provide a "call back" service to the web by saving HTTP POST/GET/PUT/DELETE events and forwarding them to subscribers.  Calls are more reliable because messages get persisted to a cluster of machines, so even when the service is down Miranda will record messages in its behalf and then play them back later.

You can get the source for it here though there isn't much there, yet.  Miranda is still in the design stages.  I will (hopefully) post updates here.

Openfire Admin Login

How to change Openfire's admin login when using Windows Vista and an embedded database:

1. Shut down Openfire
2. As the Windows Administrator,
   Edit
   
   C:\Program Files (x86)\Openfire\embedded-db\openfire.script
   
   
3. Change the line that looks something like this
   
   INSERT INTO OFUSER VALUES('admin',NULL,'<hex string>', 'Administrator','admin','0','0')
   
   to
   
   INSERT INTO OFUSER VALUES('admin','<new password>',NULL, 'Administrator','admin','0','0')
   
   
4. Save the file, exit the editor
   
5. Restart Openfire

Here are the same instructions in a more annoying format:

Maybe this is just me but...well...I'd actually rather not deal with that alternative so I'm assuming that this is Openfire's problem problem and not mine.

OK, so for the upteenth time*, I lost the admin password on my Openfire installation.  Openfire is like the most user friendly XMPP server out there...that I know of...and I know of like 2 others so this one must be really, like, user friendly.  Anyhow, so I lost my admin login...again...and I tried to figure out how I could change that password without having to reinstall Openfire.

This applies to the Windows installation with an embedded database.  If you are using a real operating system and a real database, you probably don't have this problem.  If you do then it's because of you...not me.**

At any rate, if you're really unfortunate (read, me), then you are running on the the very interesting and very secure operating system that is Microsoft Vista.  In that case, you may find that Openfire is squatting in the following directory:

C:\Program Files (x86)\Openfire

Yes, it uses that font rather than courier.  Really.

What's more, the embedded database lives in

C:\Program Files (x86)\Openfire\embedded-db

Note that Vista took out the blank in just about everywhere except for the programs directory.

This makes it more secure.

I mean, why else would they have done it?

At this point, a stand-up comic would make an observation about how they recently had a child and wait politely for the audience to applaud.  The idea is to get the audience on your side by a) pointing out that you recently had a child and b) that you have been without sleep and c) are running Microsoft Vista and d) are on the edge and e) that not applauding could very well push you over the edge and f) whatever.

Now then, the embedded database does everything in memory except that it loads everything at startup.  Actually, I'm not sure if that's what it does at all, but it looks that way; and, since I'm the sort of person who forgets their admin login at the drop of a hat, I'm obviously the sort of person that you should listen to.***

The file

openfire.script

Has the various logins and passwords for the system.  In a bold move to ensure security, the passwords are encrypted.  Or rather, there is a field for the users table that contains a field called "encryptedpassword."  There is another password called "plainpassword."  Except both fields do not contain a period in the name.  I hate punctuation.

Now I know what you're thinking: "HA HA!  I shall just change the field that says 'email' to the new password and then the system shall let me in!"  This is why I make $300 an hour and you don't.****

What you actually need to do is change the "plainpassword" to the new password, and then change the "encryptedpassword" to "NULL!"******.

Except it doesn't work.

This is because the very interesting and extremely secure operating system, Windows Vista, will not let you save the file to that directory!  Instead you have to use the extremely secure step of editing the file as the administrator.

OK, so you do all the above and it still doesn't work.   At this point, if you are like me, you are saying Why is this clown using italics so much******* In addition you would not******** think to edit this file after shutting down Openfire, since that program rewrites the startup file every time it shuts down.

And then, only then, after all this enjoyable fun, would you be able to log onto Openfire.

* = which is, by the way, not because of me.
** = this has been verified by ltsllc.com.  Which is affiliated with me.  So therefore it's probably not objective.
*** = if you believe this and have a lot of money to waste on consultants, please contact me.
**** = if you believe or even if you don't, but you are willing to pay this amount for at least a year and you don't expect to get anything useful out of it, please contact me.*****
***** = P.S. to the previous note, you are also required to actually have that much money and be willing to give it to me in advance before contacting me.
****** = except that you leave off the exclamation point.  See, there really is a reason to pay me lots of money.
******* = except you were probably able to spell "italics" correctly on the first try.  Teacher's pet.
******** = see points above about giving me lots of money.
********* = does anyone else actually read footnotes?

CLIPC SMFIFOs

I posted some ideas for a new CLIPC feature that I am currently calling "shared memory FIFOs". For those who are interested, please take a look at the posting on the SourceForge site and post any thoughts, concerns, etc.

The link is:

http://sourceforge.net/apps/wordpress/clipc/2009/06/29/smfifos/

(Note: this link previously pointed to a page that asked you for a password. It has been updated so that it no longer does that.)

New CLIPC Site

I am gradually going to be moving all things CLIPC to the SourceForge site. In particular I am hoping to create some basic documentation on how to use CLIPC and its various components to the blog associated with that project.

The CLIPC site is at http://clipc.sourceforge.net
The CLIPC blog is at https://sourceforge.net/apps/wordpress/clipc/

CLIPC 0.2 up on SourceForge

The new and improved version of CLIPC is now available on SourceForge. This new version includes, among other things, non-blocking FIFOs.

Xming Locks!

Short Story

Starting up the gnome session manager from within a gnome-terminal avoids the annoying "Not Responding" problem that I get when going from Vista to Linux via XMing.

Long Story

Briefly, here is what I did to get it to work:

• Start Xming without access control
• SSH to the Linux system and set DISPLAY
• Start a gnome-terminal
• From within the gnome-terminal, start a gnome-session

Background

This is using XMing 6.9.0.31 to display something from Fedora Core 10 (2.6.27.19-170.2.35.fc10.i686) on Vista Home Permium.

For reasons unknown (anyone here with info, please comment), XMing seems to lock up on Vista frequently. After as little as 10 seconds, the main window stops responding to requests.

I would set up XMing using the configuration that I outlined in a previous post.

Xming after a few seconds

Start Xming without access control

I'm not exactly fond of this, but unfortunately I did not find a way around this. If I do, I will post this info in a followup.

XLaunch dialog

This results in the rather...blank Xming display:

Blank and not very useful

SSH to the Linux system and set DISPLAY

Using putty or whatever, log onto the Linux system. Note that this is using SSH, telnet, but not with something graphical like an xterm.

Next set the X-Windows environment variable, DISPLAY, to point back to the Vista system. I'm sure there's some way of doing this with a script, but I'm too lazy to figure it out.

Setup the DISPLAY variable

Start a gnome-terminal

I expect that xterm or kdeterm or others would do just as well, but my system only seems to have "gnome-terminal." This should result in an unadorned, ugly, terminal appearing on the Vista system:

Note the lack of border and resize.

From within the gnome-terminal, start a gnome-session

Emphasis on from within the gnome-terminal! I've tried doing this from the SSH session and it does not seem to work. Don't ask me why... it's just Linux!

Once again, perhaps this may work using the KDE equivalent, but this is what I use.

After starting up a session, the Xming display changes from the ugly default to something better looking:

Note the window now has a window bar, border and the background has changed.

gnome-session also spouts about a page and a half of scary-looking gibberish. The thing seems to work despite all this.

Conclusion

Using this approach, Xming is much more responsive than with the other approaches I've tried. It is somewhat cryptic, and various steps may not even be necessary. If you find other approaches that work, please post them.