Tag Archives: Open Source

Watermarks template for LibreOffice Writer

For folks wanting a LibreOffice Writer template with a default set of high-quality, vector-based watermarks good to go, head on over to www.apertura.co.nz/libreofficewatermarks and download/share away. Any feedback or suggestions, let me know.


Let’s *not* let them (NZ government workers) use Chromebooks

Technology journalist Bill Bennett muses in a post from a year ago titled “Let them (NZ government workers) use Chromebooks” about the potential cost savings and productivity gains to theoretically be had from deploying the Google office productivity stack for NZ government workers. Some excerpts:

“Put aside for a moment the security risks and the NZ$2 million paid to Microsoft for extra [Windows XP] support… One solution would be to write off all the existing computers and replace them with Chromebooks… There would be immediate savings. Chromebooks can’t run Microsoft Office. Government departments can shift to Google Apps… Getting all government employees and applications into the cloud means there will never again be a situation like 40,000 computers using out of date software.”

The security risks and $2 million dollar figure can be viewed as part of the exit cost of adopting the Microsoft platform to begin with. 13 years ago there may have been a reasonable case for Windows XP being an adequate desktop solution, which is clearly no longer the case in 2015. However, suggesting that NZ government trades one proprietary ecosystem (Microsoft) for one even more closed is not an advance at all. From a technology perspective, Google Apps for instance is completely welded shut – with a non-standard and entirely Google-secret document format at its core.

Yes, there’s a strong case to be made for the combined benefits of moving computing services off the Microsoft desktop platform and onto a Linux-based OS (Chrome OS is but one example, Ubuntu is another), replacing full desktop computers with thin clients, and adopting cloud-hosted applications. However, I would seriously question the wisdom of government migrating to a platform so tightly controlled by a single vendor – not to mention one that derives ~90 percent of its total global revenue from advertising, or that has a long track record of startlingly short product lifespans. It would drastically curtail competitive supplier choice, and in the case of Google Apps (and to an extent Chrome OS), eliminate the freedom to self-host the technology in-house or via a third party as and when the situation or requirement arises.

The $2 million dollar figure for Microsoft’s extended Windows XP support might well pale in comparison to migrating off a proprietary, cloud-only solution 13 years from now. The point being, any serious discussion must take into account exit costs, and not simply the superficial low cost of entry, be it Office 365, Chrome OS, Chromebooks, and so forth. This is an aspect Bill Bennett’s article omits, much like most other opinion pieces on the matter.

Apropos of this, in the time since the source article was written, the reasons for the UK government mandating ODF for document interchange (to the detriment of both Microsoft and Google) makes for worthwhile reading.

On Microsoft killing the Internet Explorer brand

The problem is, Internet Explorer – while a simply awful piece of technology – will forever be associated with being tied to an equally mediocre OS (Microsoft Windows). Open source it already, and kill off its dependency on Windows. Not rocket science.

Microsoft is killing off the Internet Explorer brand (The Verge)

Endpoint-encrypted email with Thunderbird and Enigmail

Thanks to Thunderbird and Enigmail, anyone wanting to securely contact me over email can now do so.

Regarding Enigmail, setup is reasonably quick and easy (thanks to Enigmail’s wizard), but it’s definitely something most folks would need help with from someone with technical know-how. Anyone local who would like to claw back a little of their privacy in the post-Snowden era is welcome to drop me a line for assistance.

Forking GlassFish Redux: Payara Server

In the time since I last wrote about the need for a fork of Oracle’s GlassFish Server, Oracle have effectively removed the viability of GlassFish as a production system by killing off professional support in favour of their megabucks closed-source WebLogic product. This was a completely unsurprising move, and simply added to the mountain of orphaned and abandoned techhnology inherited from Oracle’s Sun acquisition (to which we can add some more recent additions).

Fortunately, and largely due to the wisdom of Sun to originally open source the product, a new player in the Java app server scene has appeared with what is to all intents and purposes the GlassFish fork we’ve been waiting for: Payara Server.

You can check out their website at: http://www.payara.co.uk/home. As mentioned on their site: “We take GlassFish upstream. We support it, fix it, enhance it. We release it as open source Payara Server.”

Do I have funds or a current use case to pay for professional support for an app server yet? No. Do I want to use the same product I’ll eventually be using in production while I’m in the startup/setup phase, easily and without restriction? Yes. Will I pay for support if the use case requires it, and if it guarantees a healthy product/project down the line in the best spirit of open source? Happily, and especially if it’s from the same vendor offering the product to begin with. Not rocket science, and when a vendor throws too many obstacles in my path I’ll simply switch to an alternative which does afford me these freedoms.

Looking forward to trying this out.

Android’s better browser?

Folks using Android aren’t in much doubt about which is the better browser:

Firefox for Android vs Google Chrome Play Store ratings

Custom Firefox Sync servers now supported again for Firefox for Android

Around the Firefox v29 timeline, Mozilla changed the authentication mechanism for Firefox Sync to use Firefox Accounts. Consequently, the setup method for custom self-hosted Firefox Sync servers changed (note that my guide has yet to be updated), and for a few releases Firefox for Android did not support the new model.

Fortunately, custom Sync server connectivity has been restored as of Firefox for Android version 33. The full guide (including an add-on which enables custom sync server addresses) can be found on Nick Alexander’s blog.

Note that if you’re using a “non-standard” port for either your custom Sync or Firefox Account servers, you’ll run into the bug described at https://bugzilla.mozilla.org/show_bug.cgi?id=1046020, which as Nick says manifests itself as an authentication error. The workaround suggested is to use Firefox Beta, which works for me.

It’s terrific that Mozilla continues to offer its users the choice of self-hosting their solutions.

Firefox Sync on Android

RSS feed reader improvements in Thunderbird

Short and sweet: a cute improvement made to the RSS feed reader capability in later Thunderbird releases – feeds now display with the favicon of the source feed:

Favicon in Thunderbird RSS feeds

Apache OpenOffice for OpenIndiana (Hipster)

It’s been a long while since I’ve blogged anything on the OpenIndiana front – just a quick update regarding the recent announcement of an Apache OpenOffice package for the OpenIndiana rapid development branch, a.k.a. Hipster.

Installation from the current Hipster repository is straightforward, and aside from a rather long launch time (in the order of tens of seconds, something which definitely needs to be looked at), it opens an existing LibreOffice Writer document with absolutely no problems, retaining the customised footers, background images, and the proprietary PostScript fonts (once installed):

OpenOffice running on OpenIndiana

OpenOffice running on OpenIndiana

Great work from the various contributing developers to make this happen, and an important component of building a Nuxeo DM server based on illumos.

(EDIT: It appears there are issues with being able to save newly-created ODT-format files, whereas editing and saving existing files appears to be okay. Stay tuned.)

Configuring a public JSPWiki instance for private use

Been a tad quiet on this blog for a while I realise – time to freshen thing up a bit.

In this blog post we’re going to quickly cover how to configure a JSPWiki instance such that wiki content cannot be viewed without being authenticated with a login account. For example, you may wish to deploy JSPWiki in the cloud for convenient access anywhere, but also use it to host company-sensitive documentation. In this case you probably don’t want the general public even having read-only access to the wiki content.

It turns out this is very straightforward to achieve and merely consists of making the desired changes in the jspwiki.policy file. The function of each policy block within jspwiki.policy is also clearly documented in the same file, so everything is pretty self explanatory.

JSPWiki setup and configuration is outside the scope of this post, so I’m assuming you’ve set up JSPWiki to use container-managed authentication similar to some of my previous articles here. Also note that in recent releases of JSPWiki (certainly v2.10.x) the location of various configurations files has changed – again, outside the scope of this post. All this considered, the following full excerpt of my jspwiki.policy file achieves the following:

  • All public users are prevented from being able to view the wiki.
  • Anonymous users have no permissions.
  • Users authenticated via a browser cookie have no permissions.
  • Users authenticated with a JSPWiki login account (configured in our application server, e.g. GlassFish) have a set of standard permissions for viewing, editing, and modifying content.
  • Admin users have full permissions.

Note that I’ve left the original policy blocks in place commented out so you can see the exact settings I’ve made.

//  Licensed to the Apache Software Foundation (ASF) under one
//  or more contributor license agreements.  See the NOTICE file
//  distributed with this work for additional information
//  regarding copyright ownership.  The ASF licenses this file
//  to you under the Apache License, Version 2.0 (the
//  "License"); you may not use this file except in compliance
//  with the License.  You may obtain a copy of the License at
//    http://www.apache.org/licenses/LICENSE-2.0
//  Unless required by applicable law or agreed to in writing,
//  software distributed under the License is distributed on an
//  KIND, either express or implied.  See the License for the
//  specific language governing permissions and limitations
//  under the License.

// $Id: jspwiki.policy,v 1.23 2007-07-06 10:36:36 jalkanen Exp $
// This file contains the local security policy for JSPWiki.
// It provides the permissions rules for the JSPWiki
// environment, and should be suitable for most purposes.
// JSPWiki will load this policy when the wiki webapp starts.
// As noted, this is the 'local' policy for this instance of JSPWiki.
// You can also use the standard Java 2 security policy mechanisms
// to create a consolidated 'global policy' (JVM-wide) that will be checked first,
// before this local policy. This is ideal for situations in which you are
// running multiple instances of JSPWiki in your web container.
// To set a global security policy for all running instances of JSPWiki,
// you will need to specify the location of the global policy by setting the
// JVM system property 'java.security.policy' in the command line script
// you use to start your web container. See the documentation
// pages at http://doc.jspwiki.org/2.4/wiki/InstallingJSPWiki. If you
// don't know what this means, don't worry about it.
// Also, if you are running JSPWiki with a security policy, you will probably
// want to copy the contents of the file jspwiki-container.policy into your
// container's policy. See that file for more details.

// The first policy block grants privileges that all users need, regardless of
// the roles or groups they belong to. Everyone can register with the wiki and
// log in. Everyone can edit their profile after they authenticate.
// Everyone can also view all wiki pages unless otherwise protected by an ACL.
// If that seems too loose for your needs, you can restrict page-viewing
// privileges by moving the PagePermission 'view' grant to one of the other blocks.

//grant principal org.apache.wiki.auth.authorize.Role "All" {
//    permission org.apache.wiki.auth.permissions.PagePermission "*:*", "view";
//    permission org.apache.wiki.auth.permissions.WikiPermission "*", "editPreferences";
//    permission org.apache.wiki.auth.permissions.WikiPermission "*", "editProfile";
//    permission org.apache.wiki.auth.permissions.WikiPermission "*", "login";

grant principal org.apache.wiki.auth.authorize.Role "All" {
    permission org.apache.wiki.auth.permissions.WikiPermission "*", "editPreferences";
    permission org.apache.wiki.auth.permissions.WikiPermission "*", "editProfile";
    permission org.apache.wiki.auth.permissions.WikiPermission "*", "login";

// The second policy block is extremely loose, and unsuited for public-facing wikis.
// Anonymous users are allowed to create, edit and comment on all pages.
// Note: For Internet-facing wikis, you are strongly advised to remove the
// lines containing the "modify" and "createPages" permissions; this will make
// the wiki read-only for anonymous users.

// Note that "modify" implies *both* "edit" and "upload", so if you wish to
// allow editing only, then replace "modify" with "edit".

//grant principal org.apache.wiki.auth.authorize.Role "Anonymous" {
//    permission org.apache.wiki.auth.permissions.PagePermission "*:*", "modify";
//    permission org.apache.wiki.auth.permissions.WikiPermission "*", "createPages";

grant principal org.apache.wiki.auth.authorize.Role "Anonymous" {

// This next policy block is also pretty loose. It allows users who claim to
// be someone (via their cookie) to create, edit and comment on all pages,
// as well as upload files.
// They can also view the membership list of groups.

//grant principal org.apache.wiki.auth.authorize.Role "Asserted" {
//    permission org.apache.wiki.auth.permissions.PagePermission "*:*", "modify";
//    permission org.apache.wiki.auth.permissions.WikiPermission "*", "createPages";
//    permission org.apache.wiki.auth.permissions.GroupPermission "*:*", "view";

grant principal org.apache.wiki.auth.authorize.Role "Asserted" {

// Authenticated users can do most things: view, create, edit and
// comment on all pages; upload files to existing ones; create and edit
// wiki groups; and rename existing pages. Authenticated users can also
// edit groups they are members of.

grant principal org.apache.wiki.auth.authorize.Role "Authenticated" {
    permission org.apache.wiki.auth.permissions.PagePermission "*:*", "modify,rename";
    permission org.apache.wiki.auth.permissions.GroupPermission "*:*", "view";
    permission org.apache.wiki.auth.permissions.GroupPermission "*:<groupmember>", "edit";
    permission org.apache.wiki.auth.permissions.WikiPermission "*", "createPages,createGroups";

// Administrators (principals or roles possessing AllPermission)
// are allowed to delete any page, and can edit, rename and delete
// groups. You should match the permission target (here, 'JSPWiki')
// with the value of the 'jspwiki.applicationName' property in
// jspwiki.properties. Two administative groups are set up below:
// the wiki group "Admin" (stored by default in wiki page GroupAdmin)
// and the container role "Admin" (managed by the web container).

grant principal org.apache.wiki.auth.GroupPrincipal "Admin" {
    permission org.apache.wiki.auth.permissions.AllPermission "*";
grant principal org.apache.wiki.auth.authorize.Role "Admin" {
    permission org.apache.wiki.auth.permissions.AllPermission "*";

After applying this and restarting the application server domain, one can now see that we need to authenticate even to view any of the wiki content.

JSPWiki now requires authentication to view.

Enjoy, and if you have any problems please leave a comment.