Systems Admin Simplified

The following procedure disables some caching features in Drupal 8 that prevent changes in the site from taking effect immediately. If  Drupal is chosen as the user interface , instances where its caching might be undesirable include (1) web-based Supervisory Control and Data Acquisition (SCADA) applications in engineering , and (2) real-time computational reports for scientific telemetry . ========== 1. In the Drupal folder, open the file that handles the Drupal settings. sites/default/settings.php 2. Scroll to the bottom of the file and add the lines marked "Drupal8" as follows. // BEGIN CODE // ... // Disable some Drupal caching. $settings['container_yamls'][] = DRUPAL_ROOT.'/sites/development.services.yml'; //Drupal8 $settings['cache']['bins']['render'] = 'cache.backend.null'; //Drupal8 $settings['cache']['bins']['dynamic_page_cache'] = 'cache.backend.null'; //Drupal8 // END

The following procedure shows how to make Home Assistant communicate periodically [ every thirty (30) seconds, by default ] with other endpoints like remote devices or web services. This is made possible by the polling mechanism of its REST "sensor" platform. By default, the "sensor" polls those endpoints for new data every thirty seconds. ========== 1. Log in as the system account (-u), with $HOME "bin" included in $PATH (-i). user@host: $ sudo -i -u homeassistant 2. Go to the directory containing the YAML configuration files. user@host: $ cd ~/.homeassistant 3. BACK UP the main YAML configuration file. user@host: $ cp configuration.yaml configuration_yaml.back 4. Open the main YAML configuration file. user@host: $ nano configuration.yaml 5. Add the following YAML lines and save the file. # BEGIN CODE # ... sensor:   - platform: rest     name: "Dyn Check IP"     resource: http://checkip.dyn.com     method: GET # ... # END

The following procedure activates HTTPS for the Home Assistant server. The secure protocol uses TLS/SSL certificates to encrypt the data transferred between user and server. Although it is possible to make this home automation system, whether in  Linux or  FreeBSD , accessible over the Internet, Home Assistant is usually operated within private networks, either physical or virtual. In this case, self-signed certificates may be acceptable to use and quicker to deploy. ========== 1. Log in as the system account. 1.1. Linux, with $HOME "bin" included in $PATH (-i) of system account (-u). user@host: $ sudo -i -u homeassistant 1.2. FreeBSD, coming from "root" superuser. root@host: # su - homeassistant 2. Go to the Home Assistant configuration directory. user@host: $ cd ~/.homeassistant 3. Make a directory for SSL certificates. user@host: $ mkdir ssl 4. Ensure that only the system account and members of its group can access the directory. user@host: $ chmod 7

Home Assistant is an open-source home automation system powered by Python, primarily intended to run on single-board computers like the Raspberry Pi. The following procedure shows how to run Home Assistant Core on common Debian-based Linux servers, in either physical or virtual machines. ========== 1. PREPARING THE SERVER 1.1. Update the package list and upgrade the existing packages. user@host: $ sudo apt-get update && sudo apt-get dist-upgrade -y 1.2. Install Python and required packages. user@host: $ sudo apt-get install python3 python3-dev python3-venv libffi-dev libssl-dev autoconf 1.3. Create a system account (-r) with a dedicated home directory (-m). user@host: $  sudo useradd -r -m homeassistant 1.3.1. If groups for hardware input/output are present, append the system account. Else, skip this step for now. user@host: $ sudo usermod -a -G dialout,gpio,i2c homeassistant 1.4. Ensure that only the system account and members of its group can access the dedicate

The following procedure enables Linux programs to start automatically after booting, without requiring users to log in first. This method is useful when automating custom daemons to act as servers with user-specific privileges. This can also be done on the FreeBSD crontab , with some slight changes to account for the behavior of other shells. ========== 1. Edit the user crontab file. user@host: $ crontab -e 2. Add the @reboot line with the desired command. # BEGIN CODE @reboot /myfolder/mydaemon.sh > /dev/null 2>&1 & # "> /dev/null" discards standard output by redirecting to the null device. # "2>&1" redirects standard error to standard output. # Terminating with "&" executes the command in the background. # END CODE 3. Save and exit crontab, then reboot the machine. ==========

If an existing Drupal 8 encounters the error "The provided host name is not valid for this server" when using a different domain name or IP address, then the following steps may help resolve the issue. ========== 1. In the Drupal folder, open the file that handles the Drupal settings. sites/default/settings.php 2. Find the "Trusted host configuration" section and add the lines marked "TRUSTED" as follows. // BEGIN CODE /**  * Trusted host configuration.  ...  */ $settings['trusted_host_patterns'] = [          '^localhost$', // TRUSTED loopback host name         '^localhost\:', // TRUSTED loopback port nums         '^127\.', // TRUSTED loopback IPv4 addresses          '^\[\:\:1\]', // TRUSTED loopback IPv6 address         '\.local$', // TRUSTED  mDNS  top-level domain name for  LAN          '\.local\:', // TRUSTED  mDNS  top-level domain port for  LAN         '^192\.168\.&#

The following procedure enables Linux machines to talk to each other using host names through zero-configuration (zeroconf) networking, made possible by the Multicast DNS (mDNS) protocol on link-local address IPv4 224.0.0.251 (or IPv6 ff02::fb) port 5353/UDP. This allows the ".local" top-level domain to be appended to the host name at run-time, turning it into a fully-qualified domain name (FQDN) accessible in the local area network (LAN). ========== 1. Update the package list and upgrade the existing packages. user@host: $ sudo apt-get update && sudo apt-get dist-upgrade -y 2. Install Avahi. user@host: $ sudo apt-get install avahi-daemon avahi-utils 3. Test the ".local" domain. user@host: $ ping hostname.local ========== This is particularly useful in a LAN environment where Linux servers and devices operate as an integrated computing cluster. Units can then be added or removed as needed and still communicate continuously since no manual IP