Repeatable Deployments 4 – Variables and Samba
The previous post, Adding NVMe Drive Automatically used Ansible to automatically add and format a SSD drive mounted on the Pimironi NVMe Base to a Raspberry Pi. This post will extend the work by using Ansible variables and configuration files to allow the following:
- Control the name of the mount point for the SSD
- Determine if the SSD should be formatted before mounting
- Add configuration to simplify the command line
Additionally, this post covers the installation of Samba to allow the contents of the mounted drive available to an eternal computer.
The code for this this post is available on GitHub with the code for this article available tagged as Repeatable Deployments 4.
Configuration
Ansible has a number of options for configuration files and the one being used here is the ansible.cfg file in the base directory for the ansible scripts. In this simple case, the ansible.cfg file contains the following:
[defaults]
inventory = ./hosts.ini
These two lines allow the simplification of the command line and also the Ansible scripts.
hosts = ./hosts.ini
Name of the file containing the list of host systems being targetted. In the previous post this was inventory.yml. This has been changed here to hosts.ini to fit in with more conventional Ansible usage. Adding this line to the file allows us to remove the -i inventory.ini from the command line.
The hosts.ini contents remain the same as the inventory.ini file in the previous post.
Variables
The group_vars/all.yml file contains the variable definitions that will be applied to all of the scripts. The variables are as follows:
--- default_user: clusteruser nvmebase_mount_point: nvme0 format_nvmebase: false
default_user
Name of the default user for the device. This is used as part of the Samba installation. This should match the user name used to install and update the operating system on the Raspberry Pi.
Default: clusteruser
nvmebase_mount_point
Name of the mount point for the NVMe drive.
Default: nvme0
format_nvmebase
This determines if the NVMe drive should be formatted (have a new file system created on the drive) as part of the installation process.
Set this to true for new drives (or drives where the data is to be discarded). Set this to false to preserve the contents of the drive. Note that setting format_nvmebase to false for an unformatted (new) drive will cause the ConfigureNVMeBase.yml script to fail.
Default: false
Install Samba
The next addition is the installation of Samba allowing sharing of files on the Pi to the local network.
- name: Samba hosts: raspberrypi tasks: - name: Install Samba become: yes apt: pkg: - samba - samba-common-bin - cifs-utils state: present update_cache: true - name: Set up Samba configuration become: yes blockinfile: path: /etc/samba/smb.conf block: | [share] path = /mnt/{{ nvmebase_mount_point }} read only = no public = yes writable = yes force user={{ default_user }}
This breaks down to two steps:
- Install Samba
- Configure Samba
The configuration puts the Samba share on the drive connected to the NVMe Base board. This allows for the USB system drive to be reflashed whilst preserving any data that has been created on the NVMe Base drive.
The share will be a writable share accessible to any users on the network. Normally this is not desirable but it is acceptable for a device on a small restricted network.
Lessons Learned
One issue initially encountered with the Samba share was accessibility. The share was visible over the local network but only in read-only mode. Adding the following to the configuration corrected this issue:
force user={{ default_user }}
Where default_user is defined in the global_vars/all.yml file.
This script is run in the same manner as the other Ansible scripts, ansible-playbook InstallSamba.yml.
Conclusion
Using variables allows flexibility in the installation of the NVMe drive, namely, data preservation across installations. This makes the system ideal for use as a monitoring system gathering data from devices on the network while allowing the Raspberry Pi to be updated with new software configurations while still preserving the ability to setup a new system.
Tags: Ansible, Raspberry Pi
Monday, October 14th, 2024 at 12:42 pm • Ansible, Raspberry Pi • RSS 2.0 feed Both comments and pings are currently closed.