Monday, November 28, 2011

Troubleshooting Munin Plugins

A few things to try when the Munin plugin, that you just installed, doesn’t work.  Examples below involve the ejabberd plugin from the Munin Exchange.

1) Try running the plugin from the command line. It should look something like:  

root@uranus:~# /etc/munin/plugins/ejabberd_connections
s2s_connections_out.value 0
s2s_connections_in.value 0
root@uranus:~#

If it spits up an error, you likely have a scripting error.  Take a look at the code.

2) Try telnetting to port 4949 of the Munin box and fetching the data. If it runs properly, it should look something like:

root@uranus:~# telnet localhost 4949
Trying ::1…
Trying 127.0.0.1…
Connected to localhost.
Escape character is ‘^]’.
# munin node at uranus.joat
fetch ejabberd_connections
s2s_connections_out.value 0
s2s_connections_in.value 0
.
quit
Connection closed by foreign host.
root@uranus:~#

Note: In the above, you type in “telnet localhost 4949”, “fetch ejabberd_connections”, and “quit”.  If it doesn’t run properly, you’ll probably get a “Bad Exit” error. This means that something isn’t configured correctly or something isn’t where the script is looking for it. Take a look at the code.  Hopefully the author put comments in the script, explaining what's needed.

3) You might also try “munin-run ejabberd_connections”. Sometimes it’ll return a line number for where (or near where) the script is failing.  Again, you'll need to look at the code.

For info, the eJabberd plugin that was giving me fits (above) wasn’t working because I hadn’t made an env.vhosts entry, under [ejabberd*] in /etc/munin/plugin-conf/munin-node.

Thursday, November 24, 2011

Spectrum.IM oddness

Okay, it _is_ my fault that I get into these predicaments, but it's so much fun to find this stuff out... Notes will be in the wiki shortly. Just so's you know, my rig in the following discussion looks like:

 XChat2 -> Bitlbee -> Openfire or eJabberd -> Spectrum -> GTalk or IRC

I've been playing with the Spectrum.IM gateway, getting it to work with my rig. Spent most of my free time today in a futile attempt to get Spectrum to work with Openfire. It does show up in the External Connections sessions but it doesn't accept direction from Openfire (hint: if you want to see what Spectrum is doing, don't run it as a daemon. Instead, run "spectrum -n /etc/spectrum/xmpp.cfg").

Finally gave up on Openfire and switched to eJabberd. Spectrum started playing nicely with XMPP-to-XMPP traffic right away. I was able to log into GTalk and play with various bots.

Ran into trouble when playing with IRC. Took another couple hours before I realized that eJabberd has its own IRC modules. (Hint: if you want to use Spectrum's IRC capabiltities, you'll want to move mod_irc.beam and mod_irc_connection.beam out of the /usr/lib/ejabberd/ebin/ directory and restart eJabberd.)

Removing those two files from the eJabberd ebin directory cleared up the access to Spectrum but then I couldn't open the chat room in Bitlbee. I could use another client, connected directly to the IRC server, and see that Spectrum had connected. It just wasn't showing up in Bitlbee.

Here's what I was doing. In the &bitlbee command channel, I was running:

 chat add 9 #geeks%irc.757.org@irc.uranus.joat geeks2
 /join #geeks2

No additional window would open, though Spectrum and the second IRC client was showing proper access. Here's where the oddness creeps in: after playing with various commands, figured out that if I join the command channel for "geeks2", the chat window for "geeks2" also opens. In other words, if I run the following in &bitlbee:

 /join &geeks2

then two windows open: one for &geeks2 and the other for #geeks2. It's probably a Bitlbee feature but it's still odd.

One nice thing is that I can then close &geeks2 and #geeks2 will stay open. (Wonder if this is scriptable in XChat2.)  Another is that Spectrum doesn't require additional windows in XChat2. I can now monitor channels on different IRC servers without having to switch server tabs in XChat2 (i.e., they're all in one tab now).

The one drawback to all this fun is: I now have to go back and configure eJabberd to provide the services that used to be provided by Openfire (presence, Asterisk interface, etc.).

Sunday, November 20, 2011

Chrome not liking Alfresco?

Just in case anyone else is experiencing this...

I've been experimenting with Alfresco 4.0b and 4.0c. I've noticed an
issue that pops up when using the Google Chrome browser to access
Alfreso Share. Primarily, it occurs when moving files from the
desktop to the repository, using the drag and drop feature. After a
certain number of files, Chrome refuses to talk further with Alfresco
and whatever page I was on has the Alfresco equivalent of the Mac
beachball of death. The page never times out and the browser cannot
load any other Alfresco page.

At first, I'd thought that it was an Alfresco issue as Alfresco
appeared to be crashing. Restarting the service seemed to fix it.
Adding memory to the server also appeared to make the issue less
frequent. However, it didn't make it go away.

This morning, I watched the system load while the error shows up. The
issue showed up but the system load appears to be independent of the
stall. As a short test, I closed the browser, waited a few seconds,
and started a new browser. The login page appeared after a normal
delay.

So, the short version is that it appears that there's something that
makes Chrome ignore Alfresco after a certain amount of traffic. Is
anyone else experiencing this?