Not quite as straight forward as it should be from Ubuntu land. Following on from this other blog...
First job is to get it on the wireless network, I had to use winxp and the bundled client to poke the right values in the printer for WEP config. Printing from XP was flawless, naturally.
For Ubuntu printing, we need to build cups-bjnp but with 8.04 there is a snag. Just doing:
apt-get install libcupsys2-dev
.. results in all dependencies bar 1 file, 'sidechannel.h', which can be extracted from upstream 1.3.8 (cups/sidechannel.h) and copied into /usr/include/cups.
Making cups-bjnp was straight forward 'make', followed by 'make install' which adds 'bjnp' as a printer back-end in cups.
In the Printer Configuration wizard, setting up the MP620 was just a case of selecting the Canon610 being the closest relative, and adding the IP address of the printer.
The next stumble was finding test pages would be processed by the printer but never printed. This was simply a useless default setting for media source, picking 'automatic paper source switching' fixed that, and prints come forth.
If printing doesn't start almost immediately, the paper source/sizes are probably incorrect, check print options in the application used to print.
Close but no cigar, so far. I can print to the MP620 but test pages come out 'split' with almost 1 for 1 white lines horizontally, cutting off an A4 print at just after the Magenta text. Plain text prints suffer the same issues. Gah, its like looking at an ancient green screen Commodore PET! Its not the printer, can print XP test pages fine, can copy XP test pages fine. CUPS and/or printer settings not quiet right. Will post more details when I figure it out.
Friday 19 December 2008
Thursday 16 October 2008
Am I an Atlassian Lassie?
WTF? Once upon a time I wrote applications, I wrote web-apps, I created databases. Times change. I seem to be spending much time in the Atlassian eco-sphere, slowly sinking deeper and deeper into the API's but do I have the time!
The recent Jira 3.13 upgrade bust my previously unpublished email interoperability fixes to plug the gap between Jira inbound email support for issue creation and my companies nefarious Exchange server and user email configurations. Why care? Well, Confluence has no 'nice' way to interface Jira, its either one webapp or another. Confluence has nice macros like {jiraissues} and {jiraportlet} which rock (ok, we forgive almost current IE6 CSS problems in the macro), there is just no nice 'form' to create issues. It is however possible to email issues into Jira. But.
The problem is that we have multiple email formats, some of which are 'aliases' and not the 'one' that is in the mail attribute. Oh, and depending on which email client you use, it can change from that too. So basically, the Jira function was useless unless I could fix this. Rather than just patch my code and move on, this time, I decided to do it a little more 'properly' and create a framework that fixed all my problems, allowed extensions for other formats of inbound mail and kept such tweakery separate from the issue creation code. This got published Extendable Mail Handler. Currently, it only has an implementation that makes it compatible with Form Mail Ng, if only that worked with the current 2.[8,9] releases, 2.10m3 seemed to work fine, so fingers crossed. Here is a FormMail Ng example form for interest.
As the EMH integrates with LDAP, I've been continuing to work on and around the LDAP Util library, making great use of the Beanshell plugin to embed a few SQL queries and LDAP lookups, combining with the fabulous Run macro to do parameter replacement. The result is a fully interactive series of pages allowing users to easily search for an LDAP user, Confluence group, Jira group. I need to add a few screen-shots to do it justice. As I've almost entirely delegated Confluence Space management to users (thanks to CSUM) this last piece gives them the solution that thorny question 'who is in group X' how do I give access to user Y. Keeping the solution in the Confluence bubble should help.
A while back I tried to import a Twiki site from another area of the company using the Universal Wiki Translator for Twiki. As with most online translators, YMMV. In this case I managed to hit a a bug preventing upload from the off (seems to be a talent of mine), some pages got uploaded seamlessly, others were complete dross, all told 3500 pages got loaded, only later did I discern that some data was cruft and broke the XML export (I think). Man that was a couple of days of delete from ... INNER JOIN ... WHERE hell. I think I finally got down to the last 7 rows of data but got bored, well, scared, I think I finally had to remove foreign key constraints in order to remove circular referencing data. I'm not quite brave enough to try that live :) Anyway, back to the point. So we have a twiki system, its works well for those guys, and I have to say, it has one killer feature that Confluence is still scratching around for, forms. So simple, so elegant, so killer-feature. If you don't know about this, imagine a form on a Page, set some values through radio buttons, select drop-downs with images etc, hit 'save', the data gets saved, fine, but in a database from which tabular data can be extracted at a higher level. OK so, there is Scaffolding and Meta data2. Its getting there, just lacking maturity if compared to Twiki. Soooo:
Integrating Twiki data with Confluence? Hmmm, {html-include} would appear a useful ally but there's a problem, Twiki, like other sites uses relative URL's extensively, and guess what happens when you import from twiki.server.net to confluence.server.net? all the twiki links point to non-existent URLS on the confluence server. The solution seemed straight forward, and thanks to readily available source code I wrote my first non-library Confluence plugin, taking just a few hours to rewrite the URLs of relative links. Its not posted anywhere yet in its own right, but it got posted under CONF-13365. As ever with such things, it works out much better if someone else is always maintaining the code!
Continuing the LDAP theme. Having had my appetite whetted by how easy my first macro was, I fancy something UI'ish, and am mid hack converting the 'livesearch' macro into a 'liveldapsearch' macro. The original authors have done all the hard work, theoretically its just a slice and integration dice with the LDAP Util library and voila, useful dynamic ldap lookup (hrm, with no Beanshell).
Oh and then there is the ongoing grief associated with having to setup per-space inbound email account details. That sucks. Having written tooling (using The Confluence SOAP library to automate most of this) there is little payback to 'fix' this, however, the Confluence Mail Utilities Plugin fixes this in a neat way by essentially writing the bit of code that Confluence should have already to pull in all mail and deal with it once rather than have one config per Space. For info, my mail server is polled Continualy thanks to 60+ space email configs. A single poll is actually all thats required if you are smart about it. As usual that Confluence Mail Utilities Plugin wont work for me, so once again Im picking up a scalpel for some LDAP surgery.
And again speaking of LDAP, For a good while now I've been irked at the non-availability of the enterprise feature that is LDAP server failover. Goddammitalltohell, single points of failure should be avoided. In my org, stuff gets turned off. 'ping ping ping' goes my inbox. truly, how hard is it to add such a feature? I don't half feel stupid explaining that the Enterprise system we use can be configured for multiple LDAP repositories but isn't bright enough to identify them as failovers and people have to deal with seeing multiple instances of each other in the People Browser? Gah. One small vote for an issue, one even smaller step for an implemented feature!
That said, I love the products, its the overhead that gets you, we seem to now have all but 2 of them, any month now I'm gonna shout H O U S E !.
And finally to the title, with all this stuff going on, I seem to be spending all day every day doing this stuff, making me officially, my companies Atlassian Lassie :)
The recent Jira 3.13 upgrade bust my previously unpublished email interoperability fixes to plug the gap between Jira inbound email support for issue creation and my companies nefarious Exchange server and user email configurations. Why care? Well, Confluence has no 'nice' way to interface Jira, its either one webapp or another. Confluence has nice macros like {jiraissues} and {jiraportlet} which rock (ok, we forgive almost current IE6 CSS problems in the macro), there is just no nice 'form' to create issues. It is however possible to email issues into Jira. But.
The problem is that we have multiple email formats, some of which are 'aliases' and not the 'one' that is in the mail attribute. Oh, and depending on which email client you use, it can change from that too. So basically, the Jira function was useless unless I could fix this. Rather than just patch my code and move on, this time, I decided to do it a little more 'properly' and create a framework that fixed all my problems, allowed extensions for other formats of inbound mail and kept such tweakery separate from the issue creation code. This got published Extendable Mail Handler. Currently, it only has an implementation that makes it compatible with Form Mail Ng, if only that worked with the current 2.[8,9] releases, 2.10m3 seemed to work fine, so fingers crossed. Here is a FormMail Ng example form for interest.
As the EMH integrates with LDAP, I've been continuing to work on and around the LDAP Util library, making great use of the Beanshell plugin to embed a few SQL queries and LDAP lookups, combining with the fabulous Run macro to do parameter replacement. The result is a fully interactive series of pages allowing users to easily search for an LDAP user, Confluence group, Jira group. I need to add a few screen-shots to do it justice. As I've almost entirely delegated Confluence Space management to users (thanks to CSUM) this last piece gives them the solution that thorny question 'who is in group X' how do I give access to user Y. Keeping the solution in the Confluence bubble should help.
A while back I tried to import a Twiki site from another area of the company using the Universal Wiki Translator for Twiki. As with most online translators, YMMV. In this case I managed to hit a a bug preventing upload from the off (seems to be a talent of mine), some pages got uploaded seamlessly, others were complete dross, all told 3500 pages got loaded, only later did I discern that some data was cruft and broke the XML export (I think). Man that was a couple of days of delete from ... INNER JOIN ... WHERE hell. I think I finally got down to the last 7 rows of data but got bored, well, scared, I think I finally had to remove foreign key constraints in order to remove circular referencing data. I'm not quite brave enough to try that live :) Anyway, back to the point. So we have a twiki system, its works well for those guys, and I have to say, it has one killer feature that Confluence is still scratching around for, forms. So simple, so elegant, so killer-feature. If you don't know about this, imagine a form on a Page, set some values through radio buttons, select drop-downs with images etc, hit 'save', the data gets saved, fine, but in a database from which tabular data can be extracted at a higher level. OK so, there is Scaffolding and Meta data2. Its getting there, just lacking maturity if compared to Twiki. Soooo:
Integrating Twiki data with Confluence? Hmmm, {html-include} would appear a useful ally but there's a problem, Twiki, like other sites uses relative URL's extensively, and guess what happens when you import from twiki.server.net to confluence.server.net? all the twiki links point to non-existent URLS on the confluence server. The solution seemed straight forward, and thanks to readily available source code I wrote my first non-library Confluence plugin, taking just a few hours to rewrite the URLs of relative links. Its not posted anywhere yet in its own right, but it got posted under CONF-13365. As ever with such things, it works out much better if someone else is always maintaining the code!
Continuing the LDAP theme. Having had my appetite whetted by how easy my first macro was, I fancy something UI'ish, and am mid hack converting the 'livesearch' macro into a 'liveldapsearch' macro. The original authors have done all the hard work, theoretically its just a slice and integration dice with the LDAP Util library and voila, useful dynamic ldap lookup (hrm, with no Beanshell).
Oh and then there is the ongoing grief associated with having to setup per-space inbound email account details. That sucks. Having written tooling (using The Confluence SOAP library to automate most of this) there is little payback to 'fix' this, however, the Confluence Mail Utilities Plugin fixes this in a neat way by essentially writing the bit of code that Confluence should have already to pull in all mail and deal with it once rather than have one config per Space. For info, my mail server is polled Continualy thanks to 60+ space email configs. A single poll is actually all thats required if you are smart about it. As usual that Confluence Mail Utilities Plugin wont work for me, so once again Im picking up a scalpel for some LDAP surgery.
And again speaking of LDAP, For a good while now I've been irked at the non-availability of the enterprise feature that is LDAP server failover. Goddammitalltohell, single points of failure should be avoided. In my org, stuff gets turned off. 'ping ping ping' goes my inbox. truly, how hard is it to add such a feature? I don't half feel stupid explaining that the Enterprise system we use can be configured for multiple LDAP repositories but isn't bright enough to identify them as failovers and people have to deal with seeing multiple instances of each other in the People Browser? Gah. One small vote for an issue, one even smaller step for an implemented feature!
That said, I love the products, its the overhead that gets you, we seem to now have all but 2 of them, any month now I'm gonna shout H O U S E !.
And finally to the title, with all this stuff going on, I seem to be spending all day every day doing this stuff, making me officially, my companies Atlassian Lassie :)
Tuesday 26 August 2008
Another day in the life of a Confluence administrator
More builds
Those guys at Atlassian sure crank out the builds. Half of me is impressed that new fixes come in bite sized chunks, but the down side is having to manage that change, repeatedly. Take Confluence for example, our corporate system has oh 60 or so third party plugins giving it that extra whiz-bang, but every release I have to go through a time consuming verification process for each. What would be great in the future-vapourware tense is a way to script or otherwise define behaviour, almost like runtime JUnit tests.
Anyway back to the update cycle. Being a little behind the curve is a useful thing, sure as god made little green apples there will be bugs. Being behind lets other people fix find them first, sometimes I feel like a rampant RC tester, not just limited to Atlassian, but I seem to be gifted to find those ridiculously obscure bugs/problems that no-one else does, like X windows mouse acceleration being bust and having to do a manual xset, but I digress.
Upgrade/degrade
With the ever increasing visibility of Confluence in our company yours truly wants it all running nicely with as little foobar as possible. The use of 3rd party libs is both a benefit and a curse. With 2.8x and the new hover-menus I found that the MailformNG email integration I'd just spent a week or so fixing to get issues into Jira via a nice Form (and fixing Jira email handler to deal with multiple aliases for the same 'id'). Classic scenario, do I upgrade and void the work or upgrade to gain platform whiz-bang. In this scenario I went for the update/degrade, and am patiently sitting on the side waiting for a fix to FMNG-44. I suppose this could be my queue to get the source and figure out what needs to be done. Gah, another project, more email :/
MailformNG 'client' for Jira issue entry
Speaking of the Jira mail handler, I hear that Jira 3.13 is coming along nicely. I should probably create another project for this particular beast, which is a modified create or comment handler. The driver for me is that depending on where a user is and what email client they use, their email address may be different that their registered email address in ldap. Jira currently insists on a direct match, I needed an 'indirect match' which I posted under JRA-14973 including an implementation for our Active Directory server. I did hear that Jira4 may have improved email management, but I have no clue as to whether or not this will be API breaking. To create another project, more email :/
NTLM and LDAPutil
I'm still chugging away on the Confluence NTLM, recent fixes included extending the LDAP library code to parse multiple nodes in either atlassian-user.xml or osuser.xml, doing this enables the NTLM hash 'token' that a client offers to a Confluence instance with the NTLM authenticator to be passed around to all the configured Domain Controllers to see if its valid. For a single domain this seems to work well, and should work for multiple domains, but perhaps not. I don't know if there is some weird stuff going on when mulitple DC's are defined with duplicate content, time will tell. The current approach isn't terribly scalable, as each server config is tested in turn (my only get out for this approach is that if it actually works properly I can go and fix it, honest, one day.
LDAP filters
I have great fun with LDAP filters, as Im limited to working with Active Directory I've had enough time to come up with some funky filters. Whilst going into the NTLM side of things and figuring out I didn't have enough Domain Controllers defined I wanted to get a list of Domain Controllers.... Where to find... it dawned on me that I could create an LDAP filter to list the 'machine' entries in AD itself. It all revolves around the UAC (User Access Control) value, which has a bitwise representation for various magic properties including SERVER_TRUST_ACCOUNT and TRUSTED_FOR_DELEGATION. Using a filter: (userAccountControl:1.2.840.113556.1.4.803:=532480) its possible to list the underlying machines, and to categorically list all DC's that are in a replicated cluster.
Jira wishlist
I've just come back from another branch office after doing a tripple demo of Jira,Confluence and Bamboo. One of the main features asked for from Jira was the ability to create Sub-Projects in a Project. Some things are just hard to do.
Twiki -> Confluence ?
One of our offices has a Twiki instance, consisting of some 3600 pages. I started looking at the Universal Wiki Converter but ran into an annoying infinite loop bug but actually chewed through all pages. My mileage, as the saying goes, varied. Twiki has an awsome feature that as yet Confluence cannot match. Forms. Twiki forms allow live form value modification, typed fields etc, but the power comes from being able to refer to those values and to perform queries over those values. Today you can accomplish bits of this with MetaData but for typed values the only thing that comes in close is Scaffolding. Documentation is scant on scaffolding, and there are bugs (yet another victim of aggressive product releases I think).
Where does the time go
Its funny, in today's climate of that administrative utility device, the timesheet, its sometimes difficult to chalk up a few days to investigate really promising work like the plugins or just go fix the mailformNg plugin for 2.8.x, If only there were jobs doing good Samaritan open source development :) But then again, many projects, much email :/
Did I say I get too much email?
Its funny, after a couple of years of using Linux as a development environment by default (finally kicking the dualboot must-have-word habit) the only thing that keeps me meddling with 'Doze is email. In theory yes, Evolution, in practice, no. damn thing keeps dying on me. I was using VMwareServerfor a while but had a nasty experience when lo, my beta version expireth. Greaaaat. Would the new beta beta+1 build on my machine, would it heck. Feet.getInstance().march(); I saw OpenBox and finally plucked up the courage to commit time to setting it up. It works a treat and as an added bonus and at the click of CTRL-L (I think) I get native window integration (I forgive the authors for the occasional 'Doze background blit bleedthrough). Outlook running native-ish. Until that is, the Evolution connector manages to really get hooked up with Exchange.
I must go, there is a life out there just waiting for me to find it.
Those guys at Atlassian sure crank out the builds. Half of me is impressed that new fixes come in bite sized chunks, but the down side is having to manage that change, repeatedly. Take Confluence for example, our corporate system has oh 60 or so third party plugins giving it that extra whiz-bang, but every release I have to go through a time consuming verification process for each. What would be great in the future-vapourware tense is a way to script or otherwise define behaviour, almost like runtime JUnit tests.
Anyway back to the update cycle. Being a little behind the curve is a useful thing, sure as god made little green apples there will be bugs. Being behind lets other people fix find them first, sometimes I feel like a rampant RC tester, not just limited to Atlassian, but I seem to be gifted to find those ridiculously obscure bugs/problems that no-one else does, like X windows mouse acceleration being bust and having to do a manual xset, but I digress.
Upgrade/degrade
With the ever increasing visibility of Confluence in our company yours truly wants it all running nicely with as little foobar as possible. The use of 3rd party libs is both a benefit and a curse. With 2.8x and the new hover-menus I found that the MailformNG email integration I'd just spent a week or so fixing to get issues into Jira via a nice Form (and fixing Jira email handler to deal with multiple aliases for the same 'id'). Classic scenario, do I upgrade and void the work or upgrade to gain platform whiz-bang. In this scenario I went for the update/degrade, and am patiently sitting on the side waiting for a fix to FMNG-44. I suppose this could be my queue to get the source and figure out what needs to be done. Gah, another project, more email :/
MailformNG 'client' for Jira issue entry
Speaking of the Jira mail handler, I hear that Jira 3.13 is coming along nicely. I should probably create another project for this particular beast, which is a modified create or comment handler. The driver for me is that depending on where a user is and what email client they use, their email address may be different that their registered email address in ldap. Jira currently insists on a direct match, I needed an 'indirect match' which I posted under JRA-14973 including an implementation for our Active Directory server. I did hear that Jira4 may have improved email management, but I have no clue as to whether or not this will be API breaking. To create another project, more email :/
NTLM and LDAPutil
I'm still chugging away on the Confluence NTLM, recent fixes included extending the LDAP library code to parse multiple nodes in either atlassian-user.xml or osuser.xml, doing this enables the NTLM hash 'token' that a client offers to a Confluence instance with the NTLM authenticator to be passed around to all the configured Domain Controllers to see if its valid. For a single domain this seems to work well, and should work for multiple domains, but perhaps not. I don't know if there is some weird stuff going on when mulitple DC's are defined with duplicate content, time will tell. The current approach isn't terribly scalable, as each server config is tested in turn (my only get out for this approach is that if it actually works properly I can go and fix it, honest, one day.
LDAP filters
I have great fun with LDAP filters, as Im limited to working with Active Directory I've had enough time to come up with some funky filters. Whilst going into the NTLM side of things and figuring out I didn't have enough Domain Controllers defined I wanted to get a list of Domain Controllers.... Where to find... it dawned on me that I could create an LDAP filter to list the 'machine' entries in AD itself. It all revolves around the UAC (User Access Control) value, which has a bitwise representation for various magic properties including SERVER_TRUST_ACCOUNT and TRUSTED_FOR_DELEGATION. Using a filter: (userAccountControl:1.2.840.113556.1.4.803:=532480) its possible to list the underlying machines, and to categorically list all DC's that are in a replicated cluster.
Jira wishlist
I've just come back from another branch office after doing a tripple demo of Jira,Confluence and Bamboo. One of the main features asked for from Jira was the ability to create Sub-Projects in a Project. Some things are just hard to do.
Twiki -> Confluence ?
One of our offices has a Twiki instance, consisting of some 3600 pages. I started looking at the Universal Wiki Converter but ran into an annoying infinite loop bug but actually chewed through all pages. My mileage, as the saying goes, varied. Twiki has an awsome feature that as yet Confluence cannot match. Forms. Twiki forms allow live form value modification, typed fields etc, but the power comes from being able to refer to those values and to perform queries over those values. Today you can accomplish bits of this with MetaData but for typed values the only thing that comes in close is Scaffolding. Documentation is scant on scaffolding, and there are bugs (yet another victim of aggressive product releases I think).
Where does the time go
Its funny, in today's climate of that administrative utility device, the timesheet, its sometimes difficult to chalk up a few days to investigate really promising work like the plugins or just go fix the mailformNg plugin for 2.8.x, If only there were jobs doing good Samaritan open source development :) But then again, many projects, much email :/
Did I say I get too much email?
Its funny, after a couple of years of using Linux as a development environment by default (finally kicking the dualboot must-have-word habit) the only thing that keeps me meddling with 'Doze is email. In theory yes, Evolution, in practice, no. damn thing keeps dying on me. I was using VMwareServerfor a while but had a nasty experience when lo, my beta version expireth. Greaaaat. Would the new beta beta+1 build on my machine, would it heck. Feet.getInstance().march(); I saw OpenBox and finally plucked up the courage to commit time to setting it up. It works a treat and as an added bonus and at the click of CTRL-L (I think) I get native window integration (I forgive the authors for the occasional 'Doze background blit bleedthrough). Outlook running native-ish. Until that is, the Evolution connector manages to really get hooked up with Exchange.
I must go, there is a life out there just waiting for me to find it.
Subscribe to:
Posts (Atom)
