Tuesday 3 July 2018

Preparing a Raspberry Pi for AWS Greengrass

This article refers to a Raspberry Pi 3 B+. What follows are just some notes taken by me as I progressed through the steps described here:

https://docs.aws.amazon.com/greengrass/latest/developerguide/module1.html

For details of the process please refer to the document above.

One issue I did encounter was when running the Greengrass dependency checker. On my Raspberry Pi I struggled to get the memory cgroup configured correctly. The solution is included below (see Step 5).

Step 1

Initial setup of the Raspberry Pi and access via SSH was simply a normal setup process. Once connected I needed to start the first steps specific to AWS Greengrass starting with adding users.

Step 2

Basically this is Module 1: Step 9 in the document linked to above.

SNAGHTML850b3e0

Step 3

Module 1: item10 calls for an upgrade to the Linux kernel. I chose to ignore this step for now. It will be interesting to see if there are any issues.

SNAGHTML852ee7e

The kernel version of my OS was 4.14.50 although the Greengrass instructions suggest 4.9.30.

Step 4

Module 1: item11 is locking down security. No real issues encountered.

SNAGHTML8556fab

image

SNAGHTML856523b

Step 5

So now I was at Module 1: item 12 and ready to check dependencies. This was where the only significant issue was encountered. The initial steps all progressed well until I ran the AWS Greengrass dependency checker. This showed an issue with the memory cgroup dependency.

SNAGHTML858dbd3

SNAGHTML859e40c

SNAGHTML85b4a34

The dependency checker showed the following message regarding a missing required dependency:

1. The ‘memory’ cgroup is not enabled on the device.
Greengrass will fail to set the memory limit of user lambdas.

For details about cgroups refer to the following document (although not specific to Raspian the information should still apply):

https://sysadmincasts.com/episodes/14-introduction-to-linux-control-groups-cgroups

Solution

Running “cat /proc/cgroups” initially showed that memory subsys_name was not enabled (set to 0). So, I edited the “cmdline.txt” file located in “/boot” with the nano text editor.

SNAGHTML8696d58

I added the following items to the line in that file:

cgroup_memory=1 cgroup_enable=memory

NB: Both cgroup_memory and cgroup_enable were required to make this work.

The total line from my cmdline.txt file ended up looking like this:

dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 cgroup_memory=1 cgroup_enable=memory root=PARTUUID=c20ec4c3-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

I did a reboot and checked /proc/cgroups to see if the change had taken effect. It had with the enabled flag set to 1.

SNAGHTML86e9941

Time to recheck the AWS Greengrass dependencies.

SNAGHTML86fcc24

No issues this time.

I did however note the following message:

Note :
1. It looks like the kernel uses ‘systemd’ as the init process. Be sure to set the ‘useSystemd’ field in the file ‘config.json’ to ‘yes’ when configuring Greengrass core.

Note to self: Don’t forget to do that!

This left me ready to install the Greengrass core software:

https://docs.aws.amazon.com/greengrass/latest/developerguide/module2.html

Sunday 1 July 2018

Mount a network drive for CrashPlan

I was having issues with getting CrashPlan to backup to network storage (a Western Digital MyBookLive). In short, the drive was not always mapped. I fixed it using advice given in this article:

https://support.code42.com/CrashPlan/4/Backup/Back_up_files_from_a_Windows_network_drive

The batch file looked like this:

net use Z: /DELETE
net use Z: "\\192.168.0.13\Andy" "password here" /USER:"username here" >>E:\mount_drive_for_crashplan.log

And I created a scheduled task to run it as instructed in the article.