Title photo
frugal technology, simple living and guerrilla large-appliance repair
Wed, 17 May 2017

Fedora, SUSE and easier installation coming to Windows Subsystem for Linux

Microsoft is ticking all of the right boxes with the Windows Subsystem for Linux, announcing that it will be bringing Fedora and OpenSUSE to the WSL as well as offering installation via the Windows Store.

There will also be the option of installing the Ubuntu, Fedora and SUSE version of the WSL at the same time, though it is unclear if they will have separate filesystems, and/or the option of sharing a single Linux filesystem.

I'm not a SUSE user but am a longtime Fedora user, and having the option of Fedora is a very attractive one because it's that much easier to get newer versions of things like Node, Ruby, Java, etc., in this developer-centric distribution that is a lot more stable than you'd think.

As far as installation goes, the current way you get the Ubuntu-powered WSL on your Windows 10 system is more than a little bit hacky, and the use of the Windows Store will make it easier and more inviting for new developers as well as "new" Windows "power users" coming over from years of desktop Linux (like me).

There isn't much in the way of announcements on adding graphical capabilities to the Windows Subsystem for Linux, though Microsoft isn't discouraging those who are already adding an X server to their WSL, but I figure official support for Linux GUI software in the WSL is somewhere on the roadmap.

For now I'm happy to be using a Ubuntu-based system for the first time in a long time (after the aforementioned years of Fedora). As I've written previously, the move from 14.04 to 16.04 was pretty crucial because I was able to get away from the super-old Node.js in 14.04, though the newer Unison required me to pin the old Unison from 14.04 to maintain compatibility with the Unison on my server.

While I've been happy to learn that you can pretty much download a Ubuntu package from the archive and install it with dpkg, I haven't yet experimented with PPAs in the WSL. Might be time for that.

Changing the directory: Since the WSL is rapidly going from a Ubuntu-only offering to one that will offer Fedora and SUSE, I'm changing this directory's name from ubuntu_on_windows to linux_on_windows.

Tue, 18 Apr 2017

How to 'hold' a package in Ubuntu and prevent it from being updated

I am using the unison in Ubuntu 14.04 (Unison 2.40) in my Windows Subsystem for Linux-supplied Ubuntu 16.04 (which updated the package to Unison 2.48) because my server is running Unison 2.40, and I forgot that an apt upgrade will replace the .deb I downloaded from the 14.04 repository with whatever is in 16.04.

When I tried to do a unison sync, I got an error.

How do you put a package "on hold" in Ubuntu? It's easy.

First I removed the "new" unison:

$ sudo apt remove unison

Then I installed my "old" one (which I had previously downloaded from the Ubuntu archive):

$ sudo dpkg -i unison_2.40.102-2ubuntu1_amd64.deb

Now I put the package "on hold":

$ sudo apt-mark hold unison

That's it.

Here is the output now for sudo apt update:

$ sudo apt upgrade
[sudo] password for steven:
Reading package lists... Done
[sudo] password for steven:
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
  unison
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
Mon, 17 Apr 2017

I reinstalled the Windows Subsystem for Linux, got a new Ubuntu LTS and now have my scripts back

After a Windows 10 update hosed my laptop and took the Ubuntu/Bash command line (aka the Windows Subsystem for Linux) and all of my scripts along with it, I restored Windows 10 from the laptop's backup partition, and activated the Windows Subsystem for Linux (aka WSL).

This time around I got Ubuntu 16.04 rather than 14.04, which is overall better because there are some really, really old packages in 14.04, including a super-old nodejs. Unfortunately, the old unison in 14.04 matched what is on my server (and unison versions across computers must match, or they don't work).

Luckily I was able to download a 14.04 package from the Ubuntu archive and install it in the 16.04-powered WSL. I restored my scripts, including one I made that is very WSL-specific: It takes all of the files in a Windows directory (usually images, sometimes text documents, but it could be anything), copies them into a working directory in the WSL and uses chmod to change their permissions to 644. That way I can download images while in the web browsers of the Windows world, create text files, working on all of them with Windows tools, and then transfer those files into the Linux side, where I can sync them to the server's filesystem with unison.

Aside: It's not impossible to get a Unix-style ssh program that works from the Windows command line, but it's not at all easy, either. That makes the Windows version of Unison less than useful for working with remote servers.

Now I have scripts in the WSL to:

  • Transfer and apply proper permissions to image and text files from Windows to the WSL
  • Update this Ode blog using unison to sync files and then reindex the blog via Ode's Indexette
  • Create [a static blog archive[(http://stevenrosenberg.net/documents/archive.html) by using a custom Ode theme and a query to return all posts, using curl to bring the html down to the laptop, then copying it into the local Ode filesystem, and then syncing with the server via unison.

I have a feeling I've written about most of these scripts before, and if/when I find those entries, I will link them here. If not (or if there have been updates), I will write them up in the near future.

Why Unison? Unison is a file-synchronization tool. While files can be synced from one system to another with rsync, which I use for backups, the situation with this Ode blog is different. Anthor way to synchronize two filesystem is to use git, the version-control tool.

What unison enables me to do is make changes locally, or on the server, and then reconcile those changes across both systems. So if I write or edit a post on my local filesystem, or make any kind of change on the server, running unison ensures that I have the latest files (and versions of files) on both filesystems. If I used rsync, making changes on the server but running rsync on the client wouldn't work. Git would be great, except that it only reconciles changes in the filesystem that have been checked in. Changes on the server are generally not checked in, and even if I scripted that on the server, Ode (through its Indexette and EditEdit addins) itself makes changes to the filesystem and doesn't check them in. So git wouldn't work.

I came up with unison because it's the easiest. Another alternative csync2 looks a lot harder to figure out. But I do recommend csync2 if you're doing something heavy-duty with more than 2 servers.

When I started looking for this kind of tool, I knew what I needed was a kind of Dropbox for servers. I'm sure there are people who have hacked Dropbox to work on a non-GUI server. Actually that would be a pretty good solution.

The difference with unison is that you have to "consciously" run it to sync the two filesystems. You could run it as a cron job, or somehow set it up as a daemon (which might be how Dropbox works), but for the purposes of this particular blog, syncing when needed works fine.

Using the WSL has provided me the opportunity for the first time in quite a while, to set up unison. It's a great thing to run unison -batch and have the entire blog filesystem copied to an empty directory on my laptop in about a minute. (And then any changes I make on either laptop or server can be synced with another unison -batch, or just unison for a more interactive session. Plus, never underestimate software you can install yourself, on your own computers, and use as you wish. I pay for my shared-hosting service, but otherwise I run whatever software I wish without paying any monthly fees for any of it.

Are there other ways to keep two or more filesystems in sync? I'd sure like to know if there were.

Sun, 16 Apr 2017

Sharpening my Vim skills in the Windows Subsystem for Linux

I've always been able to get around in Vim, and before that vi. But it hasn't been my primary editor (except in college, where it was my only editor).

In my Linux systems over the last many years, I've gravitated toward Geany and Gedit, mostly using Geany, and using the terrific Notepad++ on Windows.

Now that I am using the Windows Subsystem for Linux (aka Bash command line supplied by Ubuntu), I have the full range of editors available in the Linux console. For whatever reason or reasons, I'm not an emacs person, and I'm not afraid of modal editing, so Vim it is.

This gives me the opportunity to really learn Vim. Already I'm figuring out things in Vim's command mode, like w taking you from word to word and stopping on the first letter of each word, with e doing the same except stopping on the last letter.

Typing gg in command mode gets you to the top of a file, and G (and also L) gets you to the top of the final line. G$ gets you to the end of the final line.

x deletes a single character, dw deletes a word, dd deletes an entire line and d$ deletes from the cursor to the end of the line.

It's nothing like a "standard" GUI editor, but a lot of it falls right under the fingers. While I have used an adm3a terminal, it's been long enough that I didn't know the reason for using the esc key to change from insert to command mode was the placement of the esc key on the adm3a -- where the "modern" tab would be.

To make it easier to change modes, I don't want to remap tab as esc but could try remapping caps lock as esc, or using ctrl-[, ctrl-c or alt-space as esc alternatives. Thus far it doesn't look like remapping caps-lock in the WSL is all that easy.

Fri, 07 Apr 2017

This is what happens when you create a file in the Windows Subsystem for Linux and try to edit it with a Windows application

As I experiment with the Windows Subsystem for Linux (aka the Bash shell provided by Ubuntu for Windows 10), I am trying to figure exactly what I can and can't do.

To that end, I created a file with Vim in the WSL. Then I tried to open it with a text editor in Windows. I get this popup that says I can't do it:

In case you're not seeing the image above (and because Google), the Error dialog reads:

Error saving file. Error renaming temporary file: Permission denied

The file on disk may not be truncated!

I also tried to use the Windows file manager to drop the above image, created in Windows, into the WSL portion of the disk. That file "shows" in the Windows file manager, but it doesn't appear at all in the Bash shell. I had to use Bash to copy it from the Windows side to the WSL/Linux side: That's what works, in case you were wondering.

I really need an easy drag/drop between Windows and the WSL ...

Update: This issue is addressed in a very interesting bug report with a lot of links I need to explore.

Also, in the image file I copied from Windows into Bash on Windows (as Microsoft seems to like to call it), the .jpg file was too wide open on permissions. It was 777, and I wanted 644. I made the change in Bash and am syncing with the server.

Wed, 05 Apr 2017

Managing Ode with Unison via the Windows Subsystem for Linux

Update: While it seems fairly easy and routine to create and edit files on the Windows side of the filesystem using both Windows and WSL/Linux applications, when I tried to use the WSL-based Unison to sync files onto the Windows filesystem, I got a ton of permission errors and a failed sync. So the "dream" of maintaining a Windows system with WSL utilities probably won't happen. The two solutions for this particular problem are a) use Windows utilities on the Windows side and b) use Linux utilities on the WSL side.

The original entry begins here:

Now that I have my new HP Envy 15-as133cl laptop running Windows 10 and have added the Windows Subsystem for Linux, I'm exploring just how many of my regular Linux tasks I can do in this Ubuntu-supplied Bash shell, what I can do with similar programs compiled for Windows, and what really needs a dedicated Linux partition (or full computer).

Chief among these tasks is updating/syncing/backing up my Ode-generated blog (the one you're reading right now).

The first thing I learned about the Windows Subsystem for Linux (WSL for short) is that you can access the files you create in the WSL via the Windows file manager, but any modifications you make on the Windows side will not, I repeat WILL NOT be reflected in what you can see on the Linux side.

Read the rest of this post