The first thing to note here is that FFmpeg consists of a suite of libraries and codecs for handling A/V media, and, the ffmpeg command line utility itself. The latter is what we will be using to capture our screencast.

Our example system is running Ubuntu Linux 11.10 x86. Note that at this stage we are only capturing live video, not live audio.

First, use Ubuntu Software Center to install FFmpeg:

Once installed, launch a Terminal window: it’s time to enter a text command, but don’t worry, it’s straightforward and you can cut and paste the below example to get started. Simply enter the following command, noting that this will save a video recording of your live session to an example file named “testscreencast.mp4″ on your Desktop.

ffmpeg -f x11grab -r 25 -s 1280x1024 -i :0.0 -sameq ~/Desktop/testscreencast.mp4

To stop the recording, press Ctrl+C with the terminal window in focus. To view the video file, you can use VLC or a similar media player.

Let’s look at the various options and parameters of the above command in more detail:

• ffmpeg – this is the ffmpeg command itself being invoked
• -f – force the input or output file format (note – not the file itself). In this example, we are forcing the file input format to be the X11 display (see below)
• x11grab – use the X11 display
• -r – frame rate in frames per second. This defaults to 25 fps
• -s – set frame size. It can be set either as WidthxHeight pixels, (e.g. 1280×1024), or accepts a variety of preset abbreviations (e.g. sxga which corresponds to 1280×1024)
• -i – set the input file. This does not have to be a “file” per se, and indeed in this example the input file is the value :0.0, which corresponds to the value of the $DISPLAY environment variable (in display.screen format). See: http://ffmpeg.org/ffmpeg.html#X11-grabbing for more information
• -sameq – this option sets the transcoding quality to be the same as the source input.

The last portion of the command simply sets the location for the output file. Also, the default video codec for ffmpeg (you’ll note that we haven’t explicitly set a codec anywhere) is MPEG-4 (note, not MPEG-4 Part 10), which for screencasts is fine.

Once you’ve captured your screencast, you can use an application like OpenShot to perform the editing.

And seamless video playback (without stupid plugins) using Firefox…

Freedom rules.

It’s pretty much based on the iMovie paradigm, before Apple screwed too badly with it. Lots of advanced goodies which the competition doesn’t have, like fancy 3D animated and SVG titles via integration with Blender and Inkscape. Built-in support for insta-upload to YouTube. Even the documentation is great. Between Ubuntu, ffmpeg, and OpenShot (oh, and Audacity for the audio), it’s entirely possible to put together high-quality screencasts for zero software cost.

OpenShot is totally worthy of a donation, which I have happily made.

You can read what the VLC core developers thought of this issue in posts 8 and 9 here:

http://forum.videolan.org/viewtopic.php?f=2&t=94169

Frustrating that recordMyDesktop is so close to being perfect for my needs, but as it’s a defunct project I am forced to look elsewhere. Turns out that the ffmpeg command line utility can be used to capture a live desktop (loads of guides on the web on this topic), so in a follow up post I will outline my efforts to use this instead.

To cut a long story short, it seems OpenShot doesn’t like the Theora-encoded video produced by recordMyDesktop:

Numerous postings on the web finger recordMyDesktop as the problematic application – and because recordMyDesktop only outputs Ogg video (which is entirely fair enough), I’m kind of stuck without transcoding it to another format which OpenShot can use without trouble.

In a future post I’ll outline the settings I’m using in VLC Media Player to transcode files created by recordMyDesktop into H264-encoded video in MP4 container format, which can then be imported into OpenShot for editing – and subsequently exported back out as Ogg video (yes, because I actually want my users to be able to view the resulting screencasts in Firefox or Chrome without a bloody plug-in…). Some quality loss is inevitable, so it’s not ideal, but with the right settings it looks like something entirely acceptable is fairly easy to do.

The following add-on is therefore indispensable if you are using Firefox mobile with Firefox Sync:

https://addons.mozilla.org/en-US/mobile/addon/clear-mobile-history/

More information here.

Weird that it’s not included with Firefox, but hey, that’s what a plug-in ecosystem is for I guess :)

I am running JSPWiki version 2.8.3, deployed in GlassFish Open Source Edition 3.1.1 (build 12) on OpenIndiana oi_151 x86. OpenDJ is version 2.4.4, and I am using Java 6 update 26.

I am assuming prior basic familiarity with installing, configuring, and managing GlassFish and OpenDJ. Our starting point will be a freshly deployed instance of JSPWiki, for which the initial first-run setup procedure has taken place and without any configuration to the JSPWiki configuration files.

This is an insecure setup intended for testing purposes.

Create user and admin groups for JSPWiki in OpenDJ

I have created the Groups OU under my Base DN, and within it created the groups wiki-admin and wiki-users.

Members of the wiki-admin group will be authorized with full permissions in JSPWiki once authenticated. Members of the wiki-users group however will have a lesser set of permissions, suitable for regular day-to-day use of the wiki. You can use LDIF commands if you wish to create the directory entries, however, I just use OpenDJ’s super-easy GUI to do the work. For example:

Create an LDAP security realm in GlassFish

This can be performed in the GlassFish admin BUI. Note that we perform this step under the Configurations -> server-config node in the BUI (not the Configurations -> default-config node):

I have created the LDAP realm JSPWikiUsers with the following settings:

Some observations on the above can be noted here:

• The search-bind-dn and search-bind-password properties may be optional for your OpenDJ installation: they are required in my case because I have disabled anonymous access to my OpenDJ server
• The port used for access to your OpenDJ server may not necessarily be 1389 – change this as necessary.

Change the JACC provider from default to simple

I found that if this step is not performed, LDAP group lookup from GlassFish to OpenDJ will plain just not work.

Navigate to the Configurations -> server-config -> Security node of the GlassFish admin BUI and make the setting as illustrated:

This should be all the configuration needed in GlassFish using the admin BUI, so we can now proceed to making the required modifications to the following JSPWiki deployment descriptor and policy files:

• web.xml
• jspwiki.policy
• glassfish-web.xml

In the following steps, we are assuming that JSPWiki has been deployed to the domain1 domain, and the path to the deployment descriptor and policy configuration files is:

/opt/glassfishv3/glassfish/domains/domain1/applications/JSPWiki/WEB-INF

(Also, in my case no changes needed to be made at all to the jspwiki.properties file.)

Enable container based authentication in the web.xml file

In the web.xml file (in its unmodified state in JSPWiki v2.8.3), look for the section near the end of the file which begins with the following comment:

<!--  REMOVE ME TO ENABLE CONTAINER-MANAGED AUTH

Simply uncomment the section and replace it with the following:

<security-constraint>
       <web-resource-collection>
           <web-resource-name>Administrative Area</web-resource-name>
           <url-pattern>/Delete.jsp</url-pattern>
       </web-resource-collection>
       <auth-constraint>
           <role-name>wiki-admin</role-name>
       </auth-constraint>
   </security-constraint>
      
   <security-constraint>
       <web-resource-collection>
           <web-resource-name>Authenticated area</web-resource-name>
           <url-pattern>/Edit.jsp</url-pattern>
           <url-pattern>/Comment.jsp</url-pattern>
           <url-pattern>/Login.jsp</url-pattern>
           <url-pattern>/NewGroup.jsp</url-pattern>
           <url-pattern>/Rename.jsp</url-pattern>
           <url-pattern>/Upload.jsp</url-pattern>
           <http-method>DELETE</http-method>
           <http-method>GET</http-method>
           <http-method>HEAD</http-method>
           <http-method>POST</http-method>
           <http-method>PUT</http-method>
       </web-resource-collection>

       <web-resource-collection>
           <web-resource-name>Read-only Area</web-resource-name>
           <url-pattern>/attach</url-pattern>
           <http-method>DELETE</http-method>
           <http-method>POST</http-method>
           <http-method>PUT</http-method>
       </web-resource-collection>

       <auth-constraint>
           <role-name>wiki-admin</role-name>
           <role-name>wiki-users</role-name>
       </auth-constraint>
   </security-constraint>

   <login-config>
       <auth-method>FORM</auth-method>
       <realm-name>JSPWikiUsers</realm-name>
       <form-login-config>
           <form-login-page>/LoginForm.jsp</form-login-page>
           <form-error-page>/LoginForm.jsp</form-error-page>
       </form-login-config>
   </login-config>

   <security-role>
       <description>
           This logical role includes all authenticated users
       </description>
       <role-name>wiki-users</role-name>
   </security-role>

   <security-role>
       <description>
           This logical role includes all administrative users
       </description>
       <role-name>wiki-admin</role-name>
   </security-role>

Modify the jspwiki.policy file

This will allow users in the wiki-admin LDAP group to be granted full permissions upon authenticating to JSPWiki.

Look for the following section at the end of the jspwiki.policy file (in its unmodified state in a JSPWiki v2.8.3 installation):

// 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 com.ecyrd.jspwiki.auth.GroupPrincipal "Admin" {
    permission com.ecyrd.jspwiki.auth.permissions.AllPermission "*";
};
grant principal com.ecyrd.jspwiki.auth.authorize.Role "Admin" {
    permission com.ecyrd.jspwiki.auth.permissions.AllPermission "*";
};

And modify it to read:

// 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 com.ecyrd.jspwiki.auth.GroupPrincipal "Admin" {
//     permission com.ecyrd.jspwiki.auth.permissions.AllPermission "*";
// };
// grant principal com.ecyrd.jspwiki.auth.authorize.Role "Admin" {
//     permission com.ecyrd.jspwiki.auth.permissions.AllPermission "*";
// };
grant principal com.ecyrd.jspwiki.auth.authorize.Role "wiki-admin" {
    permission com.ecyrd.jspwiki.auth.permissions.AllPermission "*";
};

Create the glassfish-web.xml file

The primary purpose of this file will be to map the security roles we defined in the web.xml file to the JSPWiki groups we created in OpenDJ. The file should be created at:

/opt/glassfishv3/glassfish/domains/domain1/applications/JSPWiki/WEB-INF

The glassfish-web.xml file should contain the following only:

<!DOCTYPE glassfish-web-app PUBLIC "-//GlassFish.org//DTD GlassFish Application Server 3.1 Servlet 3.0//EN" "http://glassfish.org/dtds/glassfish-web-app_3_0-1.dtd">

<glassfish-web-app>
 <security-role-mapping>
        <role-name>wiki-admin</role-name>
        <group-name>wiki-admin</group-name>
 </security-role-mapping>
 <security-role-mapping>
        <role-name>wiki-users</role-name>
        <group-name>wiki-users</group-name>
 </security-role-mapping>
</glassfish-web-app>

Restart the GlassFish domain, and test LDAP logins to JSPWiki

First, restart the domain either using the asadmin utility or the GlassFish admin BUI. Then test LDAP logins to JSPWiki.

In my case, we can observe that logging in as a user that is a member of the wiki-admin group in OpenDJ, I do indeed have full permissions in JSPWiki:

Whereas logging in as a user that is a member of the wiki-users group in OpenDJ, I am restricted from certain destructive actions:

So, if you’d like to use Thunderbird with Gmail and be able to do the following:

• deal with a single copy of each mail item
• be able to sort that copy into a folder
• delete mail items and have them go into a Trash folder, which you can then empty
• just generally and basically have it work without it getting in the way…

Then read on!

I am using Thunderbird 9.0 on OpenIndiana oi_151a, and a Google Apps account for my Gmail. I am assuming you have first already enabled IMAP support in Gmail, but have yet to create an IMAP connection to it in Thunderbird.

First, let’s prevent Gmail’s new, “special” folders from appearing in Thunderbird. This a) reduces a great deal of interface confusion for Thunderbird users, and b) prevents a duplicate copy of every single email from being created in Thunderbird thanks to the “All Mail” folder. Don’t think too hard about it, just log into the Gmail web interface, go to Settings -> Labels, and apply the settings as highlighted in the following:

Next, configure an IMAP connection to your Gmail account in Thunderbird. Once the account is visible in your client, make particular note of the set of folders visible under the funny-looking “[Gmail]“ folder – it should look like the following:

Now let’s configure Thunderbird such that when you delete an email, it goes into the Gmail Trash folder, and from there if you empty the Trash folder, the message is permanently deleted. No, don’t ask why I am stating the bloody obvious, just observe the following settings for the Gmail account in Thunderbird (and note that this runs counter to the completely bizarre “recommended IMAP settings” Google would have you use). Make sure that the Trash folder you reference is the one that sits under the [Gmail] folder:

Test this by deleting a message from your Inbox or whatever – it should go into the [Gmail] -> Trash folder, and you should be able to right click on that folder and empty it to permanently delete items.

Disable Thunderbird’s junk email detection for the Gmail account:

Finally, and this is referenced in Google’s documentation, if you are sending mail out through Google’s SMTP server, then make sure that you are not also saving a copy in the Sent Mail folder for the account. Again confusing, because this is naturally what you would want to do for an IMAP account – but as it happens Gmail will save a copy automatically in the [Gmail] -> Sent Mail folder if you use their outbound server (which I do). I use the following settings for copies of sent mail, and any other copies:

Anyway, after having a sniff around I have found an application which on a basic level seems to work well enough – “Mobile Document Viewer”:

https://market.android.com/details?id=de.joergjahnke.documentviewer.android.free&feature=also_installed

Running it on an ASUS Eee Slider tablet, I loaded up one of my ODT files which I could open with no problems:

The application however converts the content to HTML and displays it in a browser window – so the formatting goes somewhat AWOL, but otherwise the content itself loads up fine. As a cute extra there is text-to-speech support, if you fancy having ODF files read aloud to you.

The free version is ad-supported (hence my message from “Elaine”…), but given the paltry fee for the full version this is a no-brainer purchase.