Tag Archives: Open Source

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
//  "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
//  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.
//
// ------ EVERYTHING THAT FOLLOWS IS THE 'LOCAL' POLICY FOR YOUR WIKI ------

// 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.

Advertisements

Creating a GlassFish service on Mac OS X

Quick post – when installing GlassFish 3.1.2.2 on Mac OS X (10.8.3 in my case) a GlassFish service won’t be created by the GlassFish installer (whereas Windows and Solaris platforms do get the ability to manage GlassFish as a service).

I came across a handy blog post by a former Sun Microsystems staffer which takes us most of the way there:

http://lowbittest.wordpress.com/2007/11/06/running-glassfish-on-mac-os-x-using-launchd/

The original blog entry was pertaining to Mac OS 10.4 but applies to 10.8 with one exception (in my case). When attempting to load the service the GlassFish process would immediately be killed by launchd. This is alluded to in the blog comments above.

The solution can be found at https://discussions.apple.com/thread/1744853?start=0&tstart=0 and consists of adding the following entry to your GlassFish plist file:

<key>AbandonProcessGroup</key>
<true/>

 

My quick procedure for creating a GlassFish service based on the above information follows. Note that I am not covering the details of how services are created and managed for Mac OS, so this is basically to get up and running quickly.

1) Create a plist file

Simlar to Solaris SMF, the plist file is an XML service descriptor file. These are the contents of my file:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.sun.glassfish</string>
<key>Disabled</key>
<false/>
<key>UserName</key>
<string>davek</string>
<key>GroupName</key>
<string>staff</string>
<key>ProgramArguments</key>
<array>
<string>/Users/davek/glassfish3/bin/asadmin</string>
<string>start-domain</string>
<string>domain1</string>
</array>
<key>RunAtLoad</key>
<true/>
<key>AbandonProcessGroup</key>
<true/>
</dict>
</plist>

Replace the UserName and GroupName values with the user and group you wish to launch GlassFish as. Also, GlassFish in my case has been installed to /Users/davek/glassfish3 – alter this path in your plist file accordingly.

Save the file for example as GlassFish.plist and copy it to /Library/LaunchDaemons.

 

2) Set ownership on the GlassFish domain

We are running the GlassFish service as davek:staff so be sure to change ownership on the relevant GlassFish domain (domain1 in this example) to match.

 

3) Import the service

Run the following command:

sudo launchctl load /Library/LaunchDaemons/GlassFish.plist

The service starts automatically after importing, so you should be able to browse to the administrative interface for the domain. If you reboot the system, the domain should also start on boot automatically.

pdf.js support in Thunderbird

Recent releases of Firefox have included built-in support for the pdf.js Javascript PDF rendering engine, enabling fast, plug-in-free previewing of PDF content right in the browser. What’s perhaps less-known is that with the help of an add-on Thunderbird can also do the same.

The Thunderbird Conversations add-on by Jonathan Protzenko enables a sophisticated conversation view in Thunderbird plus a whole raft of other goodies. You can read more about the story behind the add-on here and download it from here. It’s a fantastic option for email power users and for those wishing to directly preview PDF content in Thunderbird:

Thunderbird Conversations add-on.

PDF Preview directly in Thunderbird.

When Mozilla make the tagline of Thunderbird “Reclaim your inbox”, they’re not kidding. If you don’t want to have a conversation-based interface like Gmail’s rammed down your throat, then you can use the stock standard interface. But if you want a conversation view par excellence, this is an add-on that will fit the bill, and then some.

Thunderbird Conversations add-on conversation view.

The curious case of Postbox

Whilst working through some Gmail/IMAP/Thunderbird issues a while back, a reader left a comment with a recommendation to check out Postbox, an email client which amongst other things bills itself as “an awesome alternative to Thunderbird”.

As far as I can tell, Postbox is actually a Thunderbird fork, wrapped up in a non-free license with attendant commercial licensing terms and a fraction of the platform support. You get Mac and Windows, and some vague mutterings about demand potentially influencing a future Linux version. UI prettiness aside, a fair number of the advertised goodies seem to have their origins in recent Thunderbird releases, such as improved Gmail support and cloud storage service provider integration. So that’s some of the uniqueness of Postbox already gone.

Regarding the licensing, one of their blog entries entices users to switch to Postbox, highlighting Google’s purchase and subsequent shutdown of the much loved Sparrow email client. Considering Google could just as well purchase Postbox any day of the week they choose, Postbox users depending on proprietary functionality offered by the application would be just as much up shit creek, with no community support in the case of an acquisition and closure.

Licensing and duplication of features compared to Thunderbird notwithstanding, you’d probably expect to get some premium support for the cash shelled out for Postbox, right? Actually, you don’t get any support. That’s right, none. If you look at the Postbox support FAQ, they’ll tell you to read the manual, read Mozilla’s support forums (what?), Google the issue (what the hell??), and at the end of all that:

“Please note that we do not offer one-on-one support offerings to new users at this time. All support efforts are currently dedicated towards providing better documentation and self-help solutions so that our users can more quickly find the answers they need.”

You’d think personalised support would be close to the top of the list of desirable features for any commercial deployment, but apparently the folks at Postbox see it differently…

To recap: proprietary license and associated risks, not free, limited to two operating systems, most features already present in Thunderbird, and no actual support. What are the advantages of this application again? And is Postbox just hanging around in the hope of cashing in with an acquisition itself?

Installing the Oracle Java 7 plugin in Firefox on Ubuntu 12.04

We are briefly describing here how to install the Java plugin for Oracle JDK/SE 7 in Firefox. This is a manual procedure, and in this case we are wanting to install the plugin for Java 7 update 10 to enable running of JavaFX apps in Firefox 17.01 on Ubuntu 12.04 x86.

Assuming we are using the full Oracle JDK and have installed it to /opt, then the Firefox/browser plugin is located at at /opt/jdk1.7.0_06/jre/lib/i386, and is the file named libnpjp2.so:

davek@mymachine:/opt/jdk1.7.0_06/jre/lib/i386$ pwd
/opt/jdk1.7.0_06/jre/lib/i386
davek@mymachine:/opt/jdk1.7.0_06/jre/lib/i386$ ls -al libnpjp2.so 
-rwxr-xr-x 1 root root 169420 2012-08-10 15:20 libnpjp2.so

At /usr/lib/firefox/plugins create a symbolic link to this file:

davek@mymachine:/usr/lib/firefox/plugins$ pwd
/usr/lib/firefox/plugins
davek@mymachine:/usr/lib/firefox/plugins$ sudo ln -s /opt/jdk1.7.0_06/jre/lib/i386/libnpjp2.so .
davek@mymachine:/usr/lib/firefox/plugins$ ls -al
total 8
drwxr-xr-x 2 root root 4096 2012-08-15 22:19 .
drwxr-xr-x 6 root root 4096 2012-05-03 00:09 ..
lrwxrwxrwx 1 root root   41 2012-08-15 22:19 libnpjp2.so -> /opt/jdk1.7.0_06/jre/lib/i386/libnpjp2.so

After restarting Firefox, the Java plugin should now be available (and can be enabled and disabled accordingly):

Java plugin in Firefox.

SmartMachine SSH public key authentication from a non-root account

This has been documented for Joyent SmartMachines, in particular for allowing users other than root to use SSH public key authentication, but is just as applicable for getting SSH public key authentication to work in general. SmartMachine reference: http://wiki.joyent.com/wiki/display/jpc2/Managing+SSH+Keys#ManagingSSHKeys-MultipleSSHKeys

 

First create the Unix account on the server, e.g.

[root@im ~]# useradd -g staff -d /home/davek -m davek
128 blocks
[root@im ~]# passwd davek
New Password: 
Re-enter new Password: 
passwd: password successfully changed for davek

On the server, create the authorized_keys file in the user’s ~/.ssh directory.

On the client, generate an SSH public/private key pair in the ~/.ssh directory of the user you wish to connect as:

davek@mymachine:~/.ssh$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/davek/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/davek/.ssh/id_rsa.
Your public key has been saved in /home/davek/.ssh/id_rsa.pub.
The key fingerprint is:
davek@mymachine:~/.ssh$ 

Copy the SSH public key up to the server:

davek@mymachine:~/.ssh# scp id_rsa.pub root@xxx.xxx.xxx.xxx:/home/davek/.ssh
id_rsa.pub           100% |*****************************************************************************************************|   401       00:00    
davek@mymachine:~/.ssh# 

On the server, copy the public key into the target user’s ~/.ssh/authorized_keys file:

[davek@im /home/davek/.ssh]$ cat id_rsa.pub > authorized_keys 

On server, change file modes for ~/.ssh/authorized_keys to 600, and to the ~/.ssh directory to 700.

On the client, change file modes for the ~/.ssh directory to 700, and check that file modes on the private key are set to 600.

Test SSH public key authentication:

davek@mymachine:~/.ssh$ ssh davek@xxx.xxx.xxx.xxx
Last login: Mon Dec 10 02:41:18 2012 from xxx.xxx.xxx.xxx
   __        .                   .
 _|  |_      | .-. .  . .-. :--. |-
|_    _|     ;|   ||  |(.-' |  | |
  |__|   `--'  `-' `;-| `-' '  ' `-'
                   /  ; SmartMachine base 1.8.1
                   `-'  http://wiki.joyent.com/jpc2/SmartMachine+Base

heliod web server: fast then, still fast today

Quick post – as an update to my post here, Jyri Virkki has published a comprehensive set of benchmarks, comparing heliod’s out-of-the-box performance to all the other current popular HTTP servers out there. Considering the last public comparison I could find of what was then Sun Java System Web server vs Apache was in 2007, these new results are highly interesting:

“heliod had the highest throughput at every point tested in these runs. It is slightly faster than nginx at sequential requests (one client) and then pulls away.

“heliod is also quite efficient in CPU consumption. Up to four concurrent clients it is the lightest user of CPU cycles even though it produced higher throughput than all the others. At higher concurrencies, it used slightly more CPU than nginx/lighttpd although it makes up for it with far higher throughput.

“heliod was also the only server able to saturate the gigabit connection (at over 97% utilization). Given that there is 62% idle CPU left at that point, I suspect if I had more bandwidth heliod might be able to score even higher on this machine.

“These results should not be much of a surprise… after all heliod is not new, it is the same code that has been setting benchmark records for over ten years (it just wasn’t open source back then). Fast then, still fast today.

You can read the total run of tests plus information graphs at Jyri’s blog entry: http://173.255.252.27/jyri/articles/.

 

Incidentally, I came across a blog post from someone who was also apparently on the Sun Java System Web Server group at Sun, who states:

“Since Oracle no longer offers updates to individual users, and refuses to respond to requests for information about how an individual can acquire the updates, I have elected to stop writing about the server. If the moribund Open Web Server gets branched I will happily contribute to the pool of knowledge that exists for it.”

Hmm, maybe someone should give him a heads-up about heliod…

System hard freezes with the AMD FX-8350

As an update to my post here, I observed seemingly random freezes on my system upgraded with the AMD FX-8350. The behaviour encountered was a total freeze of the desktop environment, no response to local keyboard nor mouse, no response to attempting to launch a virtual console, no reponse to pings over the network, and no ability to log in remotely. The only way to restore system operation was to perform a hard reset. Interestingly I could also consistently crash the system running a GraphicsMagick benchmark. Additionally, the freezes were OS-agnostic, occurring under both OpenIndiana and Ubuntu Linux.

Looking around online you can find several posts from folks on AMD Bulldozer rigs with very similar issues (such as detailed here), including a few from people who have rather alarmingly downgraded to a Phenom or Intel CPU as a “fix”, after having received advice to alternately update the motherboard BIOS, faff around with multiple BIOS settings, test and replace the RAM, power supply and hard disk, RMA-ing the new CPU (!?), and on and on and on. Most of this didn’t really add up, and similarly my problems were encountered on a system that was hitherto generally stable using an older-generation CPU (the Phenom II X6 in my case).

To cut a long story short, this quite simply turned out to be the motherboard not stably supporting the FX-8350. Although the ASRock 870iCafe 2.0 is an AM3+ compatible part and advertised as being “8 Core Ready” (to the point of specifically claiming compatibility with the FX-8350), the reality is that the latest BIOS release was in December of 2011 – a major red flag. After upgrading my motherboard to a Gigabyte GA-990FXA-UD3 with the recent F9 BIOS, the system is now stable. And yes, this is using the original PSU, RAM, graphics card etc.

For the OpenIndiana readers, the GA-990FXA-UD3 works fine, although don’t expect USB3.0 support:

Gigabyte GA-990FX-UD3 driver support on OpenIndiana

HP ProLiant ML110 G7 server – a short review

I’ve recently acquired an HP ProLiant ML110 G7 tower server for evaluating for use in a small business environment, specifically running OpenIndiana. Following are a few short notes regarding my impressions of the box.

Pros:

Price-wise, for the base spec model, in my case with the Intel Xeon E3-1220 CPU, it’s an incredible bargain (and even more so bearing in the mind the below pros). Consider that even with an 8GB RAM upgrade and dual 1TB drives it’s not that much more than say a well-specced Dell business desktop PC.

It’s built like a tank. Nothing chintzy about the materials, nothing flexes, wobbles, rattles. In short, it oozes build quality.

Access to user-expandable options is super easy, as you’d expect.

There is ECC RAM support – ideal for extra peace of mind when using ZFS storage arrays. On that note, OpenIndiana oi_151a7 installs and runs just fine, with no driver nor hardware issues out of the box. Installing KVM on OpenIndiana, and installing and booting guest VMs poses no problem – it “just works”.

Dual Gigabit Ethernet ports are standard.

A Lights Out Manager is also included as standard. Sadly, the remote console functionality is a paid extra, but the included remote power management and monitoring functionality is quite impressive.

HP Lights Out Management interface

Cons:

Remote console, remote virtual media and other LOM options are sadly licensed extras. Unless you pay extra for this expect to potentially be making site visits from time to time. Kinda wish HP would just throw this in with the LOM as standard – Sun did, for instance.

There is nothing much in the way of physical redundancy for the server in its base spec.

One review made mention of the ML110’s quiet operation and how it would not be noticed in an office environment. Well, unless your office happens to be on the factory floor of an air conditioning manufacturing plant, you’re going to notice this thing…

Maximum physical RAM capacity is 16GB, which is a tad on the small size.

And although I haven’t checked, extending the warranty out from the standard one year period would probably cost a fair bit.

heliod – Oracle iPlanet Web Server forked as open source

Prior to the Oracle acquisition, I used to be a fan of Sun Microsystems’ web server product, Sun Java System Web Server. It had serious enterprise lineage, a terrific web admin BUI which beat the pants off Apache, and was free, free, freeeee. Needless to say, that all changed once Oracle bungled onto the scene, along with a whole bunch of other stuff.

A little known fact however is that Sun had open-sourced the core of their web server prior to Oracle taking over, releasing it as the Sun Open Web Server. But other than a few headlines at the time of the announcement (such as here) everything went very quiet shortly after – and no doubt I am sure due to Oracle not wanting to advertise the zero-cost availability of the guts of their “re-branded” megabucks flagship web server, now known as Oracle iPlanet Web Server.

So, imagine my surprise to find that one of the original engineers behind Sun Open Web Server (Jyri Virkki) has forked the code open-sourced those three or so years ago and is now actively developing it. Yes, it lives, and is known as heliod web server:

http://173.255.252.27/jyri/articles/index.php/web-server/

Francois Dion has a great write-up here as well:

http://solarisdesktop.blogspot.co.nz/2012/09/netscape-sun-oracle-no-heliod-web-server.html

Attempting to launch heliod on OpenIndiana oi_151a x86, I was met with the following error:

$ ./bin/startserv 
ld.so.1: parsexml: fatal: libicui18n.so.3: open failed: No such file or directory
./bin/startserv: line 63: 12686: Killed
failure: temporary directory  is not writable by user root

This is due to the library/icu package not being present – so install it if it’s missing and it’ll start up fine:

Installing the ICU package on OpenIndiana

$ ./bin/startserv &
[1]	3692
dave@mymachine:/opt/heliod/https-testserver$ heliod Web Server 0.1 B03/08/2011 21:59
info: CORE3016: daemon is running
info: HTTP3072: http-listener-1: http://mymachine:80 ready to accept requests
info: CORE3274: successful server startup