2 ms·

Purely Functional System Configuration Management – (Eelco Dolstra / NixOS)

peter_d_sherman 5y ago
>"In this paper we argue that existing configuration management tools --- ranging from package managers such as RPM [7] to configuration tools such as Cfengine [2] --- have an imperative model in a sense analogous to imperative programming languages such as C. That is, configuration actions such as upgrading a package or modifying a configuration file are stateful: they depend on and transform the state of the system. Statefulness has a number of serious consequences: No traceability: if a configuration is the result of a sequence of imperative actions over time (some of which may have been performed manually), then there may not be a record of these actions that allows the configuration to be recreated on an empty machine. As a result, it is hard to reproduce configurations. No predictability: if a configuration action depends on an ill-defined initial state, then the end result may be unpredictable. This is why upgrading an operating system is so much more error-prone than reinstalling it: the upgrade action transforms a poorly defined initial state, the result often being equally poorly defined, while the installation action starts from a well-defined initial state. Inability to run multiple configurations side-by-side. For instance, if we want to test some modification to the Apache server in Figure 1, then we could of course modify the httpd.conf of the production instance to run on a different port. But this would affect the production instance as well. Instead, we should copy httpd.conf, but this propagates through the dependency graph; for instance, we also would have to copy the Apache service script to refer to the new httpd.conf. A special instance of the previous problem is the inability to roll back the system to a previous configuration. For instance, if we upgrade a set of RPM packages and the upgrade turns out to be less than desirable, then undoing the change is hard: we would have to revert to backups (but it may not be clear which files to restore) or install the previous RPM packages (if we know which ones!). Likewise, if we make a bad modification to a configuration file, we'd better have the file under version control to revert the change." [...] >"With regard to software, NixOS has no /usr, /sbin, or /lib. There is only one file in /bin: namely, a symlink /bin/sh to a Bash instance in the Nix store. This is because many programs (such as Glibc's system() function) hard-code the location of the shell. Of course, we could patch all those programs, but instead we took the pragmatic route --- a slight concession to the purely functional model. Apart from the symlink /bin/sh, all packages resides in the Nix store, and have no dependencies on packages outside of the store. For example, once we had NixOS bootstrapped with just the single /bin/sh compromise, we were able to build Mozilla Firefox and all its dependencies all the way to Glibc and GCC purely. (Details of the NixOS bootstrap can be found in [9].)" [...] Footnote [9]: "A. Hemel. NixOS: the Nix based operating system. Master's thesis, Dept. of Information and Computing Sciences, Utrecht University, Aug. 2006. INF/SCR-2005-091."

>"In this paper we argue that existing configuration management tools --- ranging from package managers such as RPM [7] to configuration tools such as Cfengine [2] --- have an imperative model in a sense analogous to imperative programming languages such as C. That is, configuration actions such as upgrading a package or modifying a configuration file are stateful: they depend on and transform the state of the system. Statefulness has a number of serious consequences: No traceability: if a configuration is the result of a sequence of imperative actions over time (some of which may have been performed manually), then there may not be a record of these actions that allows the configuration to be recreated on an empty machine. As a result, it is hard to reproduce configurations. No predictability: if a configuration action depends on an ill-defined initial state, then the end result may be unpredictable. This is why upgrading an operating system is so much more error-prone than reinstalling it: the upgrade action transforms a poorly defined initial state, the result often being equally poorly defined, while the installation action starts from a well-defined initial state. Inability to run multiple configurations side-by-side. For instance, if we want to test some modification to the Apache server in Figure 1, then we could of course modify the httpd.conf of the production instance to run on a different port. But this would affect the production instance as well. Instead, we should copy httpd.conf, but this propagates through the dependency graph; for instance, we also would have to copy the Apache service script to refer to the new httpd.conf. A special instance of the previous problem is the inability to roll back the system to a previous configuration. For instance, if we upgrade a set of RPM packages and the upgrade turns out to be less than desirable, then undoing the change is hard: we would have to revert to backups (but it may not be clear which files to restore) or install the previous RPM packages (if we know which ones!). Likewise, if we make a bad modification to a configuration file, we'd better have the file under version control to revert the change." [...] >"With regard to software, NixOS has no /usr, /sbin, or /lib. There is only one file in /bin: namely, a symlink /bin/sh to a Bash instance in the Nix store. This is because many programs (such as Glibc's system() function) hard-code the location of the shell. Of course, we could patch all those programs, but instead we took the pragmatic route --- a slight concession to the purely functional model. Apart from the symlink /bin/sh, all packages resides in the Nix store, and have no dependencies on packages outside of the store. For example, once we had NixOS bootstrapped with just the single /bin/sh compromise, we were able to build Mozilla Firefox and all its dependencies all the way to Glibc and GCC purely. (Details of the NixOS bootstrap can be found in [9].)" [...] Footnote [9]: "A. Hemel. NixOS: the Nix based operating system. Master's thesis, Dept. of Information and Computing Sciences, Utrecht University, Aug. 2006. INF/SCR-2005-091."