Originally systemd was positioned by Lennart Poettering as a drop-in replacement for the System V init subsystem with the goal of speeding up system startup by parallelizing service startup where possible. An admirable objective! However, the scope of systemd has slowly increased to encompass the Linux kernel, system logging and lots more. This is craziness. It is now serious blotware with numerous binaries. Like a cancer, systemd is now spreading to more and more Linux subsystems. Worse, we now have apologists for systemd claiming that the old SysV init shell scripts were too complex to understand (actually they were easy
Once again Lennart Poettering and Kay Sievers have managed to complicate things and broken the simple model that served the Unix and Linux communities well for over 30 years, i.e. that details of filesystem mounts that should persist across a reboot are listed in /etc/(v)fstab. With systemd, mount units may either be configured via unit files, or via /etc/fstab. Mounts listed in /etc/fstab are converted into native units dynamically using systemd-fstab-generator at boot time or when the system manager configuration is reloaded. In general, configuring mount points through /etc/fstab is the preferred approach. A systemd unit configuration file whose name
NETCONF (Network Configuration Protocol) is a network management protocol developed and standardized by the IETF Netconf Working Group. It was first published in December 2006 as RFC 4741 with a revised version published in June 2011 as RFC 6241. It provides mechanisms to install, manipulate, and delete the configuration of network devices. The same IETF Working Group also produced supporting RFCs for various transport mappings, including: RFC 4742 – Using the NETCONF Configuration Protocol over Secure SHell (SSH). Obsoleted by RFC 6242 (2011) which introduced a new framing mechanism to address some potential security issues with the initial design RFC
SSH2 subsystems are a useful convenience feature to predefine remote commands for SSH clients to invoke easily. Subsystems provide a layer of abstraction for defining and invoking the remote commands. A subsystem need not be a separate program; it can invoke a function built into the SSH server itself. SFTP is the most common SSH subsystem that you are going to encounter. For example on Linux distributions, the default /etc/ssh/sshd_config file defines one subsystem, This is the configuration line on Fedora 20: # override default of no subsystems Subsystem sftp /usr/libexec/openssh/sftp-server Do not remove or comment out the above line.