Image of Beginning Google Maps API 3
Image of RHCE Red Hat Certified Engineer Linux Study Guide (Exam RH302) (Certification Press)
Image of Android Wireless Application Development
Image of Linux Kernel Development (3rd Edition)

Systemd: The Cancer That Could Kill Linux As We Know It

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

Systemd and /etc/fstab

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

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.