Tag Archives: Ubuntu

Run Docker in an LXD container

I’m a fan of Canonical’s LXD containers—which essentially copy the same approach to lightweight virtualisation enjoyed by Solaris Zones users (and by extension, any illumos-based distros such as SmartOS) for over ten years. One area however where Canoncial is playing catch-up compared to commercial UNIX is in incomplete documentation spread out absolutely everywhere—blog posts, articles, wikis, and so on. Trying to find consistent information on the level of support for Docker running in an LXD container is a perfect example of this. It’s a real mess.

At the time of writing, running Docker as installed from the official Docker repository will fail in an LXD container. This is noted in the following two bug reports:

The advice provided in both reports is to use Ubuntu’s Docker packages:

“Only Docker coming from Ubuntu (docker.io package) works inside LXD containers.

“The Docker coming from upstream is missing a number of patches to make it work, leading to the problem you describe above. We’ve been pushing for those changes to be merged upstream and some were, but we’re not yet at a point where the upstream packages work.”

Otherwise, the prerequisite for running Docker in LXD is that the container is launched with the docker profile applied, and is configured as a privileged container (by default, LXC containers are unprivileged). In the following example, the nextcloud-dev-1 container is created with the default and docker profiles applied, and its configuration is set to be privileged:

$ sudo lxc launch ubuntu:16.04 nextcloud-dev-1 -p default -p docker -c security.privileged=true

Post installation, log into the container and install the Ubuntu Docker package:

$ sudo apt install docker.io

From there, Docker should work as expected.

More on privileged containers is here:

 

Advertisements

ASUS & McAfee’s cringeworthy antivirus campaign

Exhibit A:

ASUS and McAfee antivirus campaign screengrab.

Oh, if only it was this much fun. Which – if you’re the poor sod who’s ever spent hours having to wrestle with antivirus software such as McAfee that’s proved to be completely useless in removing any number of infections from Microsoft’s godforsaken products – it’s really not.

Enough with the cutesy ads ASUS, do the right thing by your customers, and give us some laptops with Ubuntu preinstalled with first-class support, please.

(By the way, ASUS products from a hardware standpoint are generally incredibly well designed.)

Fixing TeamViewer on Ubuntu 64 bit (tvwine.dll.so)

Folks running older versions of TeamViewer (version 6 for Business in my case) on the 64 bit (i.e. the default download) release of Ubuntu may have run into the following error after installing and trying to launch it:

TeamViewer launch error on Ubuntu 64 bit

In short, the solution which worked for me is in this post:

http://ubuntuforums.org/showthread.php?t=1936044&page=2&p=11764595#post11764595

I’m still reasonably happy with TeamViewer – it works well, and they’ve as yet resisted the urge to railroad their customers into a rental-only model. It’s for this latter reason I’ll be sticking with the product come time to upgrade.

Setting up Gmail Calendar and Tasks sync in Thunderbird

Updated 29th June 2016: For folks landing here via search engines and the like, I recommend ditching Gmail as a mail service altogether – as I now have. The hoops one has to jump through to simply get Gmail to behave normally with an external mail client are no longer worth the effort in light of the better business email hosting services now available. FastMail in particular is a cinch to set up, is stable and affordable, has full calendaring, and just simply works with minimal setup on the Thunderbird side. Google clearly has zero interest or business reason to permit Gmail to work seamlessly with external clients, especially as it removes the vector for targeted advertising.


With the latest versions of Thunderbird, and the Lightning and Provider for Google Calendar add-ons, Thunderbird now supports full Gmail Calendar and Tasks synchronisation. As the setup has changed somewhat from previous versions of these add-ons we’re going to cover the current procedure in this blog post.

We are using Thunderbird 31.2.0 on Ubuntu 14.04.

If you’ve already installed these two add-ons and you’re synchronising your Gmail calendar, please delete the calendar from Thunderbird (this unsubscribes from the calendar only, and leaves all server-side data intact), and uninstall the add-ons. Restart Thunderbird to get back to a clean-slate state.

Now, using the Thunderbird Add-ons Manager, search for and install both the Lightning and Provider for Google Calendar add-ons:

Install the Lightining add-on

Install the Provider for Google Calendar add-on

Restart Thunderbird to complete the installation process.

Next, switch to the Calendar tab in Thunderbird. Right-click in the area where the default Thunderbird calendar is visible and create a new calendar:

Create a new calendar

We now work through the “Create New Calendar” wizard. In the first two screens that appear, we want to add a calendar on the network, and this should be a Google Calendar:

Add a calendar on the network

Add a Google Calendar

You’ll now be prompted to enter your email address: this should be the Gmail address of the associated calendar you wish to synchronise:

Enter your Gmail address

Thunderbird will then list the calendars and task lists available to be synced. Tick these as you need:

Adding Calendars and Tasks lists

If all goes well you’ll see a dialogue indicating the wizard has finished, and, after a brief delay (during which the interface might not be responsive) your Gmail Calendar and Tasks will be synchronised:

Dialogue indicating the wizard is finished

Google Calendar and Tasks synced

At the far right-hand-side of the above screengrab you can see our tasks lists (only containing a single task in this example). These are synced with your Gmail account.

Nice try, Windows…

…but, no thanks 😉

Ubuntu installation disk warning

The new Apple Mac mini makes even less sense

In the past we’ve noted Apple’s insane pricing for their (claimed) entry level Apple PC, the Mac mini. With the latest model released in the past couple of weeks, Apple adds another key reason to avoid the Mac mini, in the continued pointless eroding of customer-replaceable parts. In a rather detailed review from Ars Technica, special mention is made of Apple now sealing off easy access to the device’s innards and the hard-soldering of system memory to its motherboard:

“Older Minis had a round plastic cap on the bottom. Twisting it off would give easy access to the computer’s two RAM slots, and enterprising techies with a screwdriver and a little know-how could lift out the rest of the parts and perform further upgrades… The 2014 Mini still has the plastic hatch on the bottom, but it no longer twists off… now instead of seeing the Mini’s guts you see yet another metal shield, held in place with Torx Security screws. Remove that shield, and after you pull the entire motherboard out and flip it over you’ll finally see that the new Mac Mini’s RAM is soldered directly to the motherboard. It’s no longer user-upgradeable, so make sure you order all the RAM you need when you buy the computer in the first place.”

This continues the generally anti-consumer trend Apple has firmly established in their other products (iPhones, MacBook Pros, et al). The removal of easy access to customer-upgradeable parts is especially relevant to small businesses: unless your organisation is flush with cash, can afford to replace computers outright or can tolerate multi-week outages while your faulty Mac mini is sitting at an Apple service centre, there is little reason to consider the mini in its present incarnation.

If you’re not bound to Apple OS X for any mission-critical applications, then the Intel NUC running Ubuntu makes a more attractive proposition at an even more compact size – which we’ll be covering in a future post or two:

Intel NUC compared to Apple Mac mini

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

Mac OS X killed the Linux desktop? I must have missed the memo (and so did Google)…

Bizarre little opinion piece by Miguel de Icaza proclaiming the death of the Linux desktop. A little excerpt:

True story.

The hard disk that hosted my /home directory on my Linux machine failed so I had to replace it with a new one. Since this machine lives under my desk, I had to unplug all the cables, get it out, swap the hard drives and plug everything back again.

Pretty standard stuff. Plug AC, plug keyboard, plug mouse but when I got to the speakers cable, I just skipped it.

Why bother setting up the audio?

It will likely break again and will force me to go on a hunting expedition to find out more than I ever wanted to know about the new audio system and the driver technology we are using….”

Here’s my true story. I have a number of Ubuntu Linux desktops, and all are a joy to use. Ubuntu Linux has been fast and stable. The Unity interface is quite lovely (after some initial reservations). Software package installation is incredibly slick (and has been for years), and I couldn’t be happier with the quality of desktop applications. And I’ve never had a problem with audio support either for that matter. I switched from Mac OS late in 2007, partly because the money I was paying for the privilege wasn’t delivering in the areas where Ubuntu excels – and its ties to proprietary hardware (or beyond proprietary as Scott McNealy would say) generally make it a proposition for the well moneyed.

I’ve maintained hundreds and hundreds of desktop Windows and Mac OS computers in my time, so I’ve got a fairly good handle on the pros and cons of each, especially with regard to stability and ease of use. Is Ubuntu a superior desktop OS to Windows? No question. Even if Microsoft were to drop the price of Windows to zero (as if) it would still be an average product. Is Ubuntu comparable to Mac OS X, for common productivity and entertainment activities? Absolutely, especially in its current LTS incarnation.

So: I’m not sure where I’m going wrong, but Ubuntu has been nothing short of a fantastic desktop OS for me. The irony is that I don’t use it on the server, preferring Illumos/OpenIndiana due to a number of compelling advantages from its OpenSolaris roots. Why does the author feel the need to make negative comparisons to Mac OS? Why even bring up the old bugbear of Linux on the desktop at all?

I think I hear an axe being ground.

Incidentally, Google apparently didn’t get the author’s memo either…

http://www.zdnet.com/the-truth-about-goobuntu-googles-in-house-desktop-ubuntu-linux-7000003462/

Java 7 update 6 arrives, JavaFX now supported in the JRE for Linux

Quick post – the latest update to Oracle Java 7 features Mac OS supported as an equal peer to Windows and Linux – but perhaps more interestingly now includes full JavaFX runtime support in the JRE for Linux. Having cross platform support for Oracle’s next-generation Java UI does finally open up some interesting possibilities for better Java client interfaces than what we’ve generally seen so far.

Screengrab of the JavaFX Ensemble demo app running happily in Firefox on Ubuntu 10.04 x86:

JavaFX in Firefox on Ubuntu

LDAP secondary group memberships with OpenDJ and Ubuntu 12.04

As a follow-up to this post, let’s now configure OpenDJ and Ubuntu to use LDAP for assigning secondary groups to user accounts.

This is a quick guide intended for testing only, and we are assuming the setup here has been followed. One change is that we are using Ubuntu 12.04 x86 as the client system.

 

First, let’s create a new test group in OpenDJ. We assign it the structural object class namedObject, and the auxiliary object class posixGroup. The group GID number is 130, and we add a memberUid entry, with the UID of an existing LDAP account:

Adding a new group in OpenDJ

Now, on our test Ubuntu 12.04 x86 client, we modify /etc/ldap.conf, adding the following entry:

nss_schema rfc2307bis

This enables rfc2307bis LDAP schema support for PAM (OpenDJ uses the rfc2307bis schema by default).

 

Next, again in /etc/ldap.conf we uncomment the nss_base_group setting in the section headed with the comment “RFC2307bis naming contexts”, and give it the value as shown:

nss_base_group ou=Groups,dc=example,dc=co,dc=nz

Obviously you would modify the domain components to suit.

 

We now restart the nscd service, and verify that the secondary group information can be retrieved for an LDAP user:

itadmin@turrican2:/etc$ sudo /etc/init.d/nscd restart
 * Restarting Name Service Cache Daemon nscd                             [ OK ] 
itadmin@turrican2:/etc$ 
itadmin@turrican2:/etc$ id davek
uid=1004(davek) gid=50(staff) groups=130(testgroup),50(staff)

We can see that the secondary group testgroup with the GID number of 130 is successfully retrieved from LDAP for this user.