Using Git with SSH key on Windows

Just a quick write up as reminder how to generate a SSH key on Windows and use it with Git. Git comes with OpenSSH which includes ssh-keygen. Of course you can use Putty to generate SSH keys, but why not do it the quick and easy way with Git? If you use Putty you need to convert the generated key from Putty format to the standard SSH format.

Okay lets get started. Follow along with the following steps.

1. Make Open SSH utilities accessible

Add the Git directory containing the OpenSSH command line utilities to the Windows Path. They are installed in the following location.

C:\Program Files\Git\usr\bin

You can do this the traditional way using Windows Control Panel executing the following steps.

  • Pressing the Windows key to open up the Start Menu
  • Search for “advanced system settings” (just start typing)

Alternatively you can browse through the Control Panel.

  • Select System and Security
  • System
  • Click on the Advanced system settings hyperlink in the left hand pane

Or do it the easy way if you have Rapid Environment Editor (RapidEE) installed. Use the following command line from a shell with administrative privileges to add it to the system wide path (for all users) or leave out the -M flag to add the variable to the user path.

rapidee -A -M Path "C:\Program Files\Git\usr\bin"

2. Generate the SSH key pair

NOTE: If you want Git to work with the generated SSH key pair without any further configuration then accept the default location and name of the SSH key pair.

An SSH key consists of a private and public key. The private key should be stored safely, the public key can be shared with others. Don’t forget to set a passphrase for your private key. The passphrase prevents unauthorised usage of the private key by protecting the key itself with a password. Although the directory holding the private keys should be inaccessible to other users, the root user of the system, or anyone who can access the private key can copy and use it if not protected by a passphrase.To add a passphrase to a key just type it when prompted during the key generation process. Keep in mind that the password must be at least 5 characters long. A good passphrase should be at least 10 characters long, and consist of random upper and lower case letters, numbers and symbols.

Generate the SSH key pair with the following command.

ssh-keygen -t rsa -b 4096 -C "nidkil-git-key"

The -t is the key type, -b is the key length (the higher the more secure) and -C is a comment that is added to the key which makes it easier to identify. The comment is added to the end of the key. Don’t believe me? Open the public key file and you will see your comment. Handy isn’t it?

3. Use the SSH public key

If you did not change the default location and name, the SSH key pair can be found in the directory .ssh in the users home directory.

That’s all fooks. Have fun.

Advertisements

Accessing home folders from Windows Subsystem for Linux in Explorer

Are you running Windows Subsystem for Linux (WSfL)? Ever wondered where the home folders are stored so that you can access them from Explorer? Seek no further for here is the answer.

Every distribution has it’s own location. They can be found under:

%LOCALAPPDATA%\Packages

For Ubuntu 18.04 you can find the home folders in the following location:

%LOCALAPPDATA%\Packages\CanonicalGroupLimited.Ubuntu18.04onWindows_79rhkp1fndgc\LocalState\rootfs\home

Enjoy!

Testing Mongoose plugin with Jest and shared data

Grrrr just spent the better half of 2 hours trying to figure out why my Jest tests were not working for a Mongoose plugin I’m developing. It turns out that the schema configuration I was sharing between the tests was the culprit.

let Mongoose = require('mongoose');
let Schema = Mongoose.Schema;
const _ = require('lodash');
var mongooseI18n = require('../src/mongoose/mongoose-i18n-localize');

Mongoose.set('debug', true);

const simpleSchemaConfig = {
  firstName: { type: String, i18n: true, required: true },
  lastName: { type: String, i18n: false, required: true }
};

describe('Mongoose i18n localize', () => {
  beforeEach(() => {
    // Clear compiled models to avoid OverwriteModelError
    Mongoose.models = {};
  });
  
  it('should throw an exception if the locales array is not defined', () => {
    const SimpleTestSchema = new Schema(simpleSchemaConfig);
    expect(() => {
      SimpleTestSchema.plugin(mongooseI18n, {
        defaultLocale: 'nl',
        allLocalesRequired: false
      });
    }).toThrow('The required option locales array not provided or empty');
  });

  it('should throw an exception if the locales array is an empty array', () => {
    const SimpleTestSchema = new Schema(simpleSchemaConfig);
    expect(() => {
      SimpleTestSchema.plugin(mongooseI18n, {
        locales: [],
        defaultLocale: 'nl',
        allLocalesRequired: false
      });
    }).toThrow('The required option locales array not provided or empty');
  });

  ...

});

The plugin makes changes to the schema configuration and these changes were made to the shared config. The fix I used was to make a copy of the shared config with lodash’s cloneDeep function. The only change I needed to make was the schema initialization.

const SimpleTestSchema = new Schema(_.cloneDeep(simpleSchemaConfig));

Now my tests run like a charm 🙂

Bonus

When I initially ran into the above problem, I was also initializing the schema globally. I thought that was the problem, so I moved the following statement to each test case.

const SimpleTestSchema = new Schema(simpleSchemaConfig);

That caused the exception OverwriteModelError, because I was trying to initialize a compiled model. The fix for this problem was to remove all models between test cases using beforeEach. The following code does the trick.

beforeEach(() => {
  // Clear compiled models to avoid OverwriteModelError
  Mongoose.models = {};
});

Hope this helps someone.

Change root password Windows Subsystem for Linux

Today I was setting up Windows Subsystem for Linux and wanted to change to the root user using the command:

su -

I was prompted for the password, but had no idea what it was. So I needed to figure out another way of switching to the root user instead of prefixing every command with sudo. Did I say switch and prefix and sudo? O yes, stupid me.

sudo su

Don’t forget to exit once you are done. And be careful not to wrech havoc while working under the root account. Have fun!

Adding fuzzy search to Feathers NeDB

Out of the box Feathers NeDB does not support fuzzy search. There is a hook that provides this functionality: feathers-nedb-fuzzy-search. It is really simple and straitforward to install and use.

  • Install
    npm install feathers-nedb-fuzzy-search --save
  • Configure
    Enable it for specifc services or alternatively enable it for all services in app.hooks.

    const search = require('feathers-nedb-fuzzy-search') 
    messages.hooks({
      before: {
        find: search()
      }
    })
  • Usage
    const messages = app.service('messages')
    messages.find({
      query: {
        $search: 'some string to search for'
      }
    })

    or

    http://mydomain.com/api/?search=Hello

Happy coding.

Adding hot reload to featherjs

Feathers is a very cool framework to quickly and easily setup API’s. Version 3 comes with a very cool CLI that generates all the scafolding code for you and makes it extremely easy to add services, hooks, etc. One thing that is missing is hot reloading to simplify the development proces. This is were nodemon comes to the rescue.

nodemon is a tool that helps developing node.js based applications by automatically restarting the node application when file changes in the directory are detected.

Setting nodemon up with Feather and Webpack si a simple two step proces.

  1. Install nodemon
    npm install --save-dev nodemon
  2. Add one line to the scripts section of Webpacks package.json file
    ...
      },
      "scripts": {
        "test": "npm run eslint && npm run mocha",
        "dev": "node ./node_modules/nodemon/bin/nodemon.js src/",
        "eslint": "eslint src/. test/. --config .eslintrc.json",
        "start": "node src/",
        "mocha": "mocha test/ --recursive"
      }
    ...

Now start Feathers using the following command.

npm run dev

That’s it, simple right?

Add Webpack alias using Quasar framework

Trying out Quasar Framework (QF) I ran into a minor challenge setting up the Webpack @ alias like Vue provides out of the box for imports.

import firebaseCfg from '@/firebase/config'

QF uses quasar.conf.js to simplify working with Webpack. So there is no Webpack config file that the alias can be added to directly.

Example of the Webpack resolve alias configuration that VUE provides out of the box.

  ...
  resolve: {
    extensions: ['.js', '.vue', '.json'],
    alias: {
      'vue$': 'vue/dist/vue.esm.js',
      '@': resolve('src'),
    }
  },
  ...

After some Googeling I found the solution. Add the following to quasar.conf.js file to get the @ alias to work.

At the top of the file.

let path = require('path')

To the build section.

  ...
  build: {
    scopeHoisting: true,
    vueRouterMode: 'history',
    // vueCompiler: true,
    // gzip: true,
    // analyze: true,
    // extractCSS: false,
    extendWebpack (cfg) {
      cfg.module.rules.push({
        enforce: 'pre',
        test: /\.(js|vue)$/,
        loader: 'eslint-loader',
        exclude: /(node_modules|quasar)/
      })
      // Create aliases for importing
      cfg.resolve.alias = {
        ...cfg.resolve.alias,
        '@': path.resolve(__dirname, 'src')
      }
    }
  },
  ...

Pretty straight forward ones you know how 🙂