A Step-by-Step Guide to Prepare Amazon WorkSpaces for Linux Images

This guide also lists best practices for image preparation of WorkSpaces for Linux

Key Takeaways:

• Before proceeding to the actual customization process, make sure you have all the prerequisites in place
• The first step in preparing Amazon WorkSpaces for Linux Image is to set the proper custom environment settings
• The second step is to create a set of default settings
• The third step is to apply those default settings to the image
• The fourth and final step entails controlling access to customization, after which you can create a custom bundle using the image

Including desktop experience settings while creating a custom bundle for Amazon Workspaces deployment doesn’t only work for Windows — Linux admins can also use this option. 

Amazon Linux WorkSpaces uses the Mate Desktop Environment based on the Mate framework that can be configured for a consistent user experience. To achieve this, you have to customize the default Amazon Linux image and copy that to user profiles for a customized environment. 

Let’s have a look at the image customization process and what you need to know to do it yourself.

Prerequisites

You must have an Amazon Linux WorkSpace deployed for a template user. You can create your first Amazon WorkSpaces environment by following the guidelines here. 

You should have an Amazon WorkSpaces directory service, which can be an AWS Managed Active Directory domain. 

You also need two users — one for configuring the custom bundle and the other for doing the testing and validation. 

Amazon Linux image customization

Take the default Linux Amazon Machine Image and make sure it’s up to date. 

Launch a terminal session in your Amazon Linux WorkSpace for the template user and make sure you are current by typing: sudo yum update.

Now save the user environment’s default Mate configuration before proceeding to customize it. Use deconf in watch mode to take screenshots of all the settings as they are changed, so you can easily find them when required.

Now start a terminal and enter the given command: gsettings list-recursively | sort > gsettings.before.

Keep the terminal window open because it will be needed later.

Now comes the step of defining the keyboard settings for developers and enabling thumbnails for all images.

Access the toolbar and choose System, Preferences, Keyboard. Click on the Layout tab and add in the UK keyboard or any language other than the default US keyboard. After adding your preferred keyboard, save the option and close the window. 

For enabling thumbnails, go to the toolbar and choose System, Preferences, File Management. Click on the Preview tab and for Other Previewable Files, set Show Thumbnails to Always. Now close the File Management window.

Change the default background of the desktop to a corporate standard and reduce the idle time for the screen saver.

You can change the desktop background by opening the right-click menu for the desktop. 

You can change the screensaver idle time to 2 minutes by accessing the toolbar and going to Systems, Preferences, Screensaver.

Create a set of default settings

The customized environment you created has a default Mate configuration. Save this configuration by entering: gsettings list-recursively | sort > gsettings.after.

To understand what settings you changed, you will have to compare before and after changes, which can be done by using the given command: Diff –U0 gsettings . {before.after}.

Here is a summary of the list of settings that you must change and lockdown for the customized user experience:

• org.mate.background color-shading-type ‘solid’
• org.mate.background picture-options ‘wallpaper’
• org.mate.background primary-color ‘rgb(245,121,0)’
• org.mate.peripherals-keyboard-xkb.kbd layouts [‘gb’, ‘us’]
• org.mate.caja.preferences show-image-thumbnails ‘always’
• org.mate.session idle-delay 2

Apply the default settings to the image

To create a customized environment, take a copy of the dconf database of the template user on the system partition and copy it to the user profiles on startup.

You also have the option to have granular control of the settings to be applied and limit the user’s ability to change these settings once they are applied. 

For more granular control, you can create deconf keyfiles under: /etc/deconf/db/local.d/.

The creation of these deconf files is similar to Window. ini files. In the keyfiles, the section name refers to the schema path, not the schema name. 

By using the appropriate .gshema.xml, get the schema path. To get the background schema path, open a terminal window and type: grep -F path= /usr/share/glib-2.0/schemas/org.mate.background.gschema.xml.

This gives the given output: schema id=”org.mate.background” path=”/org/mate/desktop/background/”>.

This means that org.mate.background has a schema path of /org/mate/desktop/background/.

You can repeat the above method to find other schema paths for the newly configured settings. 

Apply the settings by updating dconf. This can be done by typing the following in the terminal window: Sudo deconf update.

Customization access control

For making sure standard usage is followed and users don’t change settings, you can use lockdown mode.

Once you have made sure a setting is configured according to your preference, lock the setting by using the following steps:

• 1. Create a file in the etc/dconf/db/local.d/locks/directory and to lock per line list one subpath or key: Sudo pluma etc/dconf/db/local.d/locks/00-desktop-control.
• 2. Put the control setting in the lockdown file and close the pluma editor after saving the file. This is an example file:
  
  #Lockdown settings for desktop appearance
  org/mate/desktop/background/color-shading-type
  org/mate/desktop/background/picture-filename = ”
  org/mate/desktop/background/primary-color     
• 3. Now using the terminal window, update the deconf file to apply the setting: Sudo deconf update.
• 4. Validate the update settings by trying to change the desktop background. You’ll notice the option to change the background is still available but it doesn’t work.

The image that you have successfully customized and locked can be used to create a custom bundle. You can find more information about creating a custom WorkSpaces bundle here. When a new WorkSpace is deployed for a test user, the user will have the desktop customization applied when they log in. 

Configuration files management

The configuration settings for the new users’ desktop experience are collated as text files. The management of these files can be done through your custom bundle management process. These files can also be managed by employing configuration tools such as Chef, Puppet, or AWS system manager.

Best Practices for image preparation of Linux WorkSpaces

Here are some best practices you should consider while creating a Linux WorkSpaces image:

• Do not embed private keys, passwords, or other sensitive information in the image. 
• Do not hardcode application license details in the image, so when you deploy a WorkSpace, it doesn’t breach your application license requirement. 
• Having a consistent strategy for tagging images will let you have better organization of the images. 
• Use different tools to document and automate the image creation and update process.
• You can create a library of reusable scripts and modular application packages that can be programmatically assembled to create different WorkSpace images.
• Enable standard bootstrapping for the images so they have an instance to reference runtime information when they are launched. 

CloudHesive, an Amazon Managed Service Partner organization, can help you with all your Amazon Workspace queries. Contact us for leveraging the benefits of cloud-based ecosystems and transforming your business.