summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorJoey Hess2020-05-01 15:21:05 -0400
committerJoey Hess2020-05-01 15:21:05 -0400
commit7859c8c02b422229fbcbc5c26dad378fca5c9e88 (patch)
treea1037135f35e1dd934fb8ab2462f011bf9d282e1 /doc
parentdc3a04ae10addd701cc5cce59b2ad8931fa656ba (diff)
parentcc3289f70f09d2fa061cc21e47ea44d4b374dadd (diff)
Merge branch 'master' into joeyconfig
Diffstat (limited to 'doc')
-rw-r--r--doc/forum/Bootstrapping_with_Cabal_on_Archlinux_fails.mdwn46
-rw-r--r--doc/forum/Bootstrapping_with_Cabal_on_Archlinux_fails/comment_1_80326b7fe6ea0f301872a02bb2462a5d._comment13
-rw-r--r--doc/forum/Bootstrapping_with_Cabal_on_Archlinux_fails/comment_2_ee81823a34396b98cda15282019dcafc._comment30
-rw-r--r--doc/forum/Bootstrapping_with_Cabal_on_Archlinux_fails/comment_3_41d73c97ed105aad773027d64e66cc38._comment13
-rw-r--r--doc/forum/Conceptual_:_HostName_vs._Domain.mdwn22
-rw-r--r--doc/forum/Conceptual_:_HostName_vs._Domain/comment_1_6a80853161714e19cdae006ec19097fb._comment21
-rw-r--r--doc/forum/Setting_altenative___63__.mdwn7
-rw-r--r--doc/forum/Setting_altenative___63__/comment_1_cc9f01e46e6cc2940382309cd17b3575._comment7
-rw-r--r--doc/forum/etckeeper_made_obsolete_by_propellor__63__.mdwn2
-rw-r--r--doc/forum/etckeeper_made_obsolete_by_propellor__63__/comment_1_008690e4e3828123a2c47a4b1abc413e._comment14
-rw-r--r--doc/forum/etckeeper_made_obsolete_by_propellor__63__/comment_2_41084ce268e4aa667b1c59f8352aa774._comment9
-rw-r--r--doc/forum/etckeeper_made_obsolete_by_propellor__63__/comment_3_ab42e31ff116bf56dca6cdff9bba2d29._comment10
-rw-r--r--doc/forum/installing_apt_packages_without_running_new_services/comment_2_b819efe3a4f00f1b9993d5a31e65f2e9._comment99
-rw-r--r--doc/forum/using_propellor_on_low_RAM_devices__63__.mdwn18
-rw-r--r--doc/forum/using_propellor_on_low_RAM_devices__63__/comment_1_fc192587233c3cda7d0f78f67311de49._comment12
-rw-r--r--doc/forum/using_propellor_on_low_RAM_devices__63__/comment_2_b58e57d9edb7c574ff8a72dbcd24d1b7._comment18
-rw-r--r--doc/news/version_5.10.1.mdwn15
-rw-r--r--doc/news/version_5.6.1.mdwn4
-rw-r--r--doc/todo/Debootstrap_module_should_respect_a_configured_Apt.proxy.mdwn2
-rw-r--r--doc/todo/spin_without_remote_compilation/comment_8_6a7a6a3acce0b0865e2a389e60c46179._comment8
20 files changed, 366 insertions, 4 deletions
diff --git a/doc/forum/Bootstrapping_with_Cabal_on_Archlinux_fails.mdwn b/doc/forum/Bootstrapping_with_Cabal_on_Archlinux_fails.mdwn
new file mode 100644
index 00000000..0ff23880
--- /dev/null
+++ b/doc/forum/Bootstrapping_with_Cabal_on_Archlinux_fails.mdwn
@@ -0,0 +1,46 @@
+Bootstrapping Propellor with Cabal is currently failing for me on Archlinux, for several reasons.
+
+## Dynamic linking
+
+The `ghc` package in Archlinux [uses dynamic linking](https://wiki.archlinux.org/index.php/Haskell#Problems_with_linking) for the GHC boot libraries. This means that the `cabal install` and `cabal build` steps in src/Propellor/Bootstrap.hs need the `--ghc-options=-dynamic` option added. I don't know if it's safe to do that for all OSes, or if this is something that Bootstrap.hs will need to do only on Arch.
+
+## GHC 8.8
+
+Archlinux, being a rolling-release distro, has version 8.8.1 of GHC available. This means that once I add the `--ghc-options=-dynamic` option to the `cabal install` and `cabal build` steps, Propellor now fails to build on my Archlinux system with the GHC compiler complaining about src/Propellor/Property/Installer/Target.hs. Specifically, the `UserInput i` line in the definition of `targetInstalled` produces an "Illegal polymorphic type" error:
+
+```
+src/Propellor/Property/Installer/Target.hs:137:12: error:
+ • Illegal polymorphic type:
+ forall metatypes.
+ (Combines
+ (RevertableProperty metatypes metatypes)
+ (RevertableProperty metatypes metatypes),
+ CombinedType
+ (RevertableProperty metatypes metatypes)
+ (RevertableProperty metatypes metatypes)
+ ~ RevertableProperty metatypes metatypes) =>
+ Propellor.Property.Versioned.VerSpec v metatypes
+ -> RevertableProperty metatypes metatypes
+ Perhaps you intended to use RankNTypes
+ • In the expansion of type synonym ‘Propellor.Property.Versioned.VersionedBy’
+ In the expansion of type synonym ‘Versioned’
+ In the type signature:
+ targetInstalled :: UserInput i =>
+ Versioned v Host
+ -> v
+ -> i
+ -> TargetPartTable
+ -> RevertableProperty (HasInfo + DebianLike) (HasInfo
+ + DebianLike)
+ |
+137 | :: UserInput i
+ | ^^^^^^^^^^^^...
+```
+
+This appears to be due to [stricter type synonym validity-checking in GHC 8.8](https://gitlab.haskell.org/ghc/ghc/wikis/migration/8.8#stricter-type-synonym-validity-checking). I had to add the `RankNTypes`, `TypeFamilies`, and `FlexibleContexts` extensions to Target.hs in order to make GHC 8.8 happy. (That's a minimal set: removing any one of those three produced one of three different compiler errors, which I won't reproduce here for brevity's safe). This appears to be safe on all OSes, since Propellor compiled happily on my laptop, which is running a Buntish variant called Linux Mint (where GHC 8.0.2 is what Apt gave me). (Though do note that I only tested that on Arch and Mint, and didn't do any testing on Debian to see whether GHC 7.x or earlier is still happy with those extensions being present in the source file).
+
+## New-style cabal
+
+Once I added the `--ghc-options=-dynamic` option to Cabal, and added those three extensions to the first line of Target.hs, I was then faced with another error: the `ln -sf` step failed because `dist/build/propellor-config/propellor-config` didn't exist. The version of Cabal that comes with Archlinux has apparently switched to [Nix-style local builds](https://cabal.readthedocs.io/en/latest/nix-local-build-overview.html) as the default action when you run `cabal build`, and the `propellor-config` binary ended up in `/usr/local/propellor/dist-newstyle/build/x86_64-linux/ghc-8.8.1/propellor-5.10.1/x/propellor-config/build/propellor-config/propellor-config`.
+
+This is the point where, not being a Haskell programmer myself, my ability to Google the problem was exhausted. I'm sure there's a way to get Cabal to tell you where it will put the files it's about to build (similar to `stack path --dist-dir`), but at this point, I needed to get back to working on other things. So I punted and just added `& bootstrapWith (Robustly Stack)` to the properties of my Archlinux host. :-) Bootstrapping with Stack was successful, BTW.
diff --git a/doc/forum/Bootstrapping_with_Cabal_on_Archlinux_fails/comment_1_80326b7fe6ea0f301872a02bb2462a5d._comment b/doc/forum/Bootstrapping_with_Cabal_on_Archlinux_fails/comment_1_80326b7fe6ea0f301872a02bb2462a5d._comment
new file mode 100644
index 00000000..5d1fab2d
--- /dev/null
+++ b/doc/forum/Bootstrapping_with_Cabal_on_Archlinux_fails/comment_1_80326b7fe6ea0f301872a02bb2462a5d._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="rmunn@24f62461074e9165181dd6ec6ac66473353a24e9"
+ nickname="rmunn"
+ avatar="http://cdn.libravatar.org/avatar/5fb7a86e278e5b3b427f3b9a3cda71e1"
+ subject="One more thing"
+ date="2020-02-18T04:50:58Z"
+ content="""
+I haven't yet prepared a patch for this, but in src/Propellor/Bootstrap.hs, the `archlinuxdeps Cabal` list of should have `\"haskell-type-errors\"` added to it. That's the name of the Archlinux package for [https://hackage.haskell.org/package/type-errors](https://hackage.haskell.org/package/type-errors). Without that package, Cabal has to download type-errors and its dependencies before building Propellor, but with that package added, Archlinux's package manager can manage that package (and keep it up-to-date) instead.
+
+With that one change, the `archlinuxdeps Cabal` list is complete (at least as of yesterday when I tested it).
+
+I'll prepare a patch for this and submit it to propellor@joeyh.name soon.
+"""]]
diff --git a/doc/forum/Bootstrapping_with_Cabal_on_Archlinux_fails/comment_2_ee81823a34396b98cda15282019dcafc._comment b/doc/forum/Bootstrapping_with_Cabal_on_Archlinux_fails/comment_2_ee81823a34396b98cda15282019dcafc._comment
new file mode 100644
index 00000000..c5b85e05
--- /dev/null
+++ b/doc/forum/Bootstrapping_with_Cabal_on_Archlinux_fails/comment_2_ee81823a34396b98cda15282019dcafc._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-02-20T17:47:46Z"
+ content="""
+Seems odd that the way Arch has installed ghc would
+make `cabal install` fail without additional options being added very time.
+That does not strike me as a good decision if it's the case. I guess that
+the -dynamic should only be set on Arch, since only it has inflicted this
+problem on itself.
+
+Would appreciate a patch with the ghc 8.8 fixes.
+
+I would not be surprised if cabal new-build does not provide any good way
+to find out where the executable was put, because after all cabal build
+doesn't either (just it's easier to guess there). Cabal expects a workflow
+where that's followed by cabal install, or cabal run.
+
+This might be one way: `cabal new-install --symlink-bindir=.`
+But with my older version of cabal, that seems to not actually work,
+indeed I can't get it to install the binaries anywhere. Maybe it does
+work with the newer cabal where new-install is the default.
+
+Needing to detect whether new-build was used or not is an added
+complication.
+
+Best way I've found:
+
+ find dist-newstyle/ -executable -type f |grep 'propellor$'
+"""]]
diff --git a/doc/forum/Bootstrapping_with_Cabal_on_Archlinux_fails/comment_3_41d73c97ed105aad773027d64e66cc38._comment b/doc/forum/Bootstrapping_with_Cabal_on_Archlinux_fails/comment_3_41d73c97ed105aad773027d64e66cc38._comment
new file mode 100644
index 00000000..f742280f
--- /dev/null
+++ b/doc/forum/Bootstrapping_with_Cabal_on_Archlinux_fails/comment_3_41d73c97ed105aad773027d64e66cc38._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-02-25T21:22:22Z"
+ content="""
+Ghc 8.8 is fixed thanks to your patch.
+
+I was curious how cabal build failed w/o -dynamic, and found
+this <https://bugs.archlinux.org/task/54563#comment158808>
+which includes a simple change that the archlinux maintainers
+could make if they didh't want this to be a self-inflicted wound
+on their users.
+"""]]
diff --git a/doc/forum/Conceptual_:_HostName_vs._Domain.mdwn b/doc/forum/Conceptual_:_HostName_vs._Domain.mdwn
new file mode 100644
index 00000000..334c9d82
--- /dev/null
+++ b/doc/forum/Conceptual_:_HostName_vs._Domain.mdwn
@@ -0,0 +1,22 @@
+Hello,
+
+Writing properties, I often hesitate between using types `HostName` or `Domain` for the FQDN of a machine.
+This is not 'very important' since both are "just" `String`, but the type carries semantics and I'd rather keep consistent (helps understanding the code better).
+
+Here are the docs :
+
+http://hackage.haskell.org/package/propellor-5.9.1/docs/Propellor-Types-OS.html#t:HostName
+http://hackage.haskell.org/package/propellor-5.9.1/docs/Propellor-Types-Dns.html#t:Domain
+
+So `HostName` documentation to me looks like really corresponding to a machine's FQDN, but may also be the IP of the machine.
+Conversely `Domain` is not documented (in its module) but it is used in the 'domain part of the FQDN' in some modules; eg. in Propellor/Property/Hostname.hs
+Even clearer is the `Propellor.Property.DNS` module in which I clearly understand the choice of `Domain` vs. `HostName`.
+
+Still it seems to me that sometimes one sees `Domain` where a `HostName` would be expected. One such example is in `LetsEncrypt`
+Maybe I am just to confused by a few places where `Domain` is used while I would (maybe wrongly) expect `HostName` ?
+
+What am I missing ?
+
+Cheers,
+
+Serge.
diff --git a/doc/forum/Conceptual_:_HostName_vs._Domain/comment_1_6a80853161714e19cdae006ec19097fb._comment b/doc/forum/Conceptual_:_HostName_vs._Domain/comment_1_6a80853161714e19cdae006ec19097fb._comment
new file mode 100644
index 00000000..86c38d79
--- /dev/null
+++ b/doc/forum/Conceptual_:_HostName_vs._Domain/comment_1_6a80853161714e19cdae006ec19097fb._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-11-11T17:26:24Z"
+ content="""
+I think LetsEncrypt's use of Domain is intentional; a certificate is for a
+domain and you can't get one for eg a bare IP address or an unqualified
+hostname.
+
+AFAICS, Domain is a FQDN.
+
+(Propellor.Property.Hostname has to deal with details of /etc/hosts,
+but it does not actually use the Domain type anywhere.)
+
+More generally, it's common for a propellor module to have some
+`type Foo = String` that's only used to make parameters more self-documenting
+and doesn't have any particular meaning beyond whatever string a Property might
+use. One shouldn't worry if two modules have data types that seem to
+overlap in content when that's all they're used for. Of course it's nicer to
+have less stringy data types, via ADTs or smart constructors, when possible.
+"""]]
diff --git a/doc/forum/Setting_altenative___63__.mdwn b/doc/forum/Setting_altenative___63__.mdwn
new file mode 100644
index 00000000..b40d1fe0
--- /dev/null
+++ b/doc/forum/Setting_altenative___63__.mdwn
@@ -0,0 +1,7 @@
+Everything is in the title : is there a property to ensure that the 'alternative' is set in a given way ?
+
+I guess the simplest otherwise would be to use a `Cmd` to do it (through usage of `update-alternative`), but I am wondering if there is already a property to do that…
+
+Thanks in advance,
+
+Serge
diff --git a/doc/forum/Setting_altenative___63__/comment_1_cc9f01e46e6cc2940382309cd17b3575._comment b/doc/forum/Setting_altenative___63__/comment_1_cc9f01e46e6cc2940382309cd17b3575._comment
new file mode 100644
index 00000000..741326f6
--- /dev/null
+++ b/doc/forum/Setting_altenative___63__/comment_1_cc9f01e46e6cc2940382309cd17b3575._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-11-11T17:23:24Z"
+ content="""
+There is not. I'd welcome a property submission.
+"""]]
diff --git a/doc/forum/etckeeper_made_obsolete_by_propellor__63__.mdwn b/doc/forum/etckeeper_made_obsolete_by_propellor__63__.mdwn
new file mode 100644
index 00000000..ea605ef4
--- /dev/null
+++ b/doc/forum/etckeeper_made_obsolete_by_propellor__63__.mdwn
@@ -0,0 +1,2 @@
+I'm still learning about these two programs. I haven't use them yet, but I will (at least propellor). It seems to me there exists a bit of functionality overlapping between them: propellor's config file might be enough to describe all your changes you want to /etc for a host..? In this case, etckeeper would appear to be useful just as a "change log".. What's your thoughts on this? Do you use both propellor and etckeeper?
+-- eugen
diff --git a/doc/forum/etckeeper_made_obsolete_by_propellor__63__/comment_1_008690e4e3828123a2c47a4b1abc413e._comment b/doc/forum/etckeeper_made_obsolete_by_propellor__63__/comment_1_008690e4e3828123a2c47a4b1abc413e._comment
new file mode 100644
index 00000000..752bbd01
--- /dev/null
+++ b/doc/forum/etckeeper_made_obsolete_by_propellor__63__/comment_1_008690e4e3828123a2c47a4b1abc413e._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-11-21T14:57:57Z"
+ content="""
+I use both. To be fully described by the propellor configuration, it would
+need to pin the system to a specific version of every package installed on
+it, and that's generally not practical because there are new security
+updates all the time. It's useful to have etckeeper keeping track of
+changes made to configuration during upgrades.
+
+I do find etckeeper generally less useful on those type of systems, but it
+still more than pays for itself.
+"""]]
diff --git a/doc/forum/etckeeper_made_obsolete_by_propellor__63__/comment_2_41084ce268e4aa667b1c59f8352aa774._comment b/doc/forum/etckeeper_made_obsolete_by_propellor__63__/comment_2_41084ce268e4aa667b1c59f8352aa774._comment
new file mode 100644
index 00000000..84c22a04
--- /dev/null
+++ b/doc/forum/etckeeper_made_obsolete_by_propellor__63__/comment_2_41084ce268e4aa667b1c59f8352aa774._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2019-11-21T15:16:36Z"
+ content="""
+Also, when the propellor configuration is changed, it's very useful to have
+a record of how that change affected the host. While etckeeper's record is
+limited to /etc, that does cover a large percentage of such changes.
+"""]]
diff --git a/doc/forum/etckeeper_made_obsolete_by_propellor__63__/comment_3_ab42e31ff116bf56dca6cdff9bba2d29._comment b/doc/forum/etckeeper_made_obsolete_by_propellor__63__/comment_3_ab42e31ff116bf56dca6cdff9bba2d29._comment
new file mode 100644
index 00000000..eb8abfb3
--- /dev/null
+++ b/doc/forum/etckeeper_made_obsolete_by_propellor__63__/comment_3_ab42e31ff116bf56dca6cdff9bba2d29._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="eugen"
+ avatar="http://cdn.libravatar.org/avatar/7e7e5700d7017735fd00c2dfcd3f91e4"
+ subject="comment 3"
+ date="2019-11-21T20:29:20Z"
+ content="""
+Indeed, I can see how etckeeper provides a very easy way to check exactly what has changed to /etc (also) after a propellor spin. When I'm manually editing an /etc file I know what the changes are, but not so when a tool does it for me. So, it's important to verify, for example, that propellor did indeed what I *thought* I told it to do (not sure if propellor has an option to report the /etc changes it did).
+
+By using both etckeeper and propellor, which one do you consider to have the authoritative status (power?) over /etc? Do you still manually edit /etc files?
+"""]]
diff --git a/doc/forum/installing_apt_packages_without_running_new_services/comment_2_b819efe3a4f00f1b9993d5a31e65f2e9._comment b/doc/forum/installing_apt_packages_without_running_new_services/comment_2_b819efe3a4f00f1b9993d5a31e65f2e9._comment
new file mode 100644
index 00000000..467e55cf
--- /dev/null
+++ b/doc/forum/installing_apt_packages_without_running_new_services/comment_2_b819efe3a4f00f1b9993d5a31e65f2e9._comment
@@ -0,0 +1,99 @@
+[[!comment format=mdwn
+ username="serge1cohen"
+ avatar="http://cdn.libravatar.org/avatar/df873622c2eeb5b34222b7af0d47abd0"
+ subject="Using noServices to configure apache before running it..."
+ date="2019-10-31T22:56:56Z"
+ content="""
+Hello there,
+
+I was typically in this situation : starting an apache server on a specific IP (the other IPs of the machine -on port 80- are used by other server processes), in particular to be able to get a certificate from let's encrypt.
+
+When using :
+
+ micro_apache :: Domain -> String -> FilePath -> Property DebianLike
+ micro_apache fqdn ip dr = combineProperties \"Setting a micro apache server running only for interface\" $ props
+ & Apache.installed
+ & File.hasContent \"/etc/apache2/ports.conf\" [(\"Listen \" ++ ip ++ \":80\")]
+ & Apache.siteDisabled \"000-default\"
+ & Apache.siteEnabled fqdn
+ [ \"<VirtualHost \" ++ ip ++ \":80>\"
+ , \"ServerName \" ++ fqdn ++ \":80\"
+ , \"DocumentRoot \" ++ dr
+ , \"ErrorLog /var/log/apache2/\" ++ fqdn ++ \"_error.log\"
+ , \"LogLevel warn\"
+ , \"CustomLog /var/log/apache2/\" ++ fqdn ++ \"_access.log combined\"
+ , \"ServerSignature On\"
+ , \"</VirtualHost>\"
+ ]
+ & Apache.restarted
+ & Apache.reloaded
+
+The property is problematic (the initial 'Apache.installed' starts the apache server listening to ALL IPs).
+But at least at the end it seems that I get a 'running' service :
+
+ root@d4:~# systemctl status apache2.service
+ ● apache2.service - The Apache HTTP Server
+ Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled)
+ Active: active (running) since Thu 2019-10-31 16:59:41 CET; 17min ago
+
+
+
+To avoid the transient service wrongly configured (it also messes up with the server serving port 80 on another IP) case I tried :
+
+ micro_apache :: Domain -> String -> FilePath -> Property (HasInfo + DebianLike)
+ micro_apache fqdn ip dr = combineProperties \"Setting a micro apache server running only for interface\" $ props
+ & ( Apache.installed `requires` Service.noServices ) -- => Needs to change type to Property (HasInfo + DebianLike)
+ & File.hasContent \"/etc/apache2/ports.conf\" [(\"Listen \" ++ ip ++ \":80\")]
+ & Apache.siteDisabled \"000-default\"
+ & Apache.siteEnabled fqdn
+ [ \"<VirtualHost \" ++ ip ++ \":80>\"
+ , \"ServerName \" ++ fqdn ++ \":80\"
+ , \"DocumentRoot \" ++ dr
+ , \"ErrorLog /var/log/apache2/\" ++ fqdn ++ \"_error.log\"
+ , \"LogLevel warn\"
+ , \"CustomLog /var/log/apache2/\" ++ fqdn ++ \"_access.log combined\"
+ , \"ServerSignature On\"
+ , \"</VirtualHost>\"
+ ]
+ & ( revert Service.noServices `before` Apache.restarted ) -- => Needs to change type to Property (HasInfo + DebianLike)
+
+But then the configuration leads to having apache in an \"ghost state\", neither started nor stopped :
+
+ root@d4:~# systemctl status apache2
+ ● apache2.service - The Apache HTTP Server
+ Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled)
+ Active: inactive (dead)
+ Docs: https://httpd.apache.org/docs/2.4/
+
+Which leads to an unavailable http service, and as a consequence to a failure in ACME / let's encrypt.
+Indeed it seems that the service is started using the 'old' Service system. The nice thing is that this makes it possible to use the 'noServices' property. The problem is that the systemd module is in a state not working anymore with 'Service'.
+
+Finally I had to mix the 'noServices' property with a couple of 'Systemd' properties so that the server is properly restarted once the configuration is correct. This leads to a bit longer property but at least it works :
+
+ micro_apache :: Domain -> String -> FilePath -> Property (HasInfo + DebianLike)
+ micro_apache fqdn ip dr = combineProperties \"Setting a micro apache server running only for interface\" $ props
+ & ( Apache.installed `requires` Service.noServices ) -- => Needs to change type to Property (HasInfo + DebianLike)
+ & Systemd.stopped \"apache2\" -- 'clean' of the systemd module
+ & File.hasContent \"/etc/apache2/ports.conf\" [(\"Listen \" ++ ip ++ \":80\")]
+ & Apache.siteDisabled \"000-default\"
+ & Apache.siteEnabled fqdn
+ [ \"<VirtualHost \" ++ ip ++ \":80>\"
+ , \"ServerName \" ++ fqdn ++ \":80\"
+ , \"DocumentRoot \" ++ dr
+ , \"ErrorLog /var/log/apache2/\" ++ fqdn ++ \"_error.log\"
+ , \"LogLevel warn\"
+ , \"CustomLog /var/log/apache2/\" ++ fqdn ++ \"_access.log combined\"
+ , \"ServerSignature On\"
+ , \"</VirtualHost>\"
+ ]
+ & ( revert Service.noServices -- => Needs to change type to Property (HasInfo + DebianLike)
+ `before` Systemd.running \"apache2\" ) -- restarting through systemd
+
+With this done, it seems to work.
+
+Notice, however, that if apache was completely avoiding the 'old service' system, then we could not even benefit from the 'noService' in the first place. Would there be another solution to reach the same result ?
+
+Hope this might help
+
+Serge.
+"""]]
diff --git a/doc/forum/using_propellor_on_low_RAM_devices__63__.mdwn b/doc/forum/using_propellor_on_low_RAM_devices__63__.mdwn
new file mode 100644
index 00000000..7bcbd0cc
--- /dev/null
+++ b/doc/forum/using_propellor_on_low_RAM_devices__63__.mdwn
@@ -0,0 +1,18 @@
+I'm trying to use propellor (and to learn haskell!) to manage my laptop and a small server, both running debian stable.
+
+The server is a lime2 soc [1], with only 1GiB of RAM, and no swap (I think this is the default setup from the freedombox image).
+
+propellor --spin failed when targeting the server: on the server, ghc got killed by the OOM killer.
+
+I then simplified my config.hs and successfully ran "cabal build -j1" from the server.
+At some point during the successful build, ghc was using 400MiB of memory.
+This is 40% of the whole memory, I fear the OOM killer will strike again if I don't change something.
+I'll probably try to enable swap.
+
+Propellor seems designed with embedded devices in mind (eg. with the image builder), I'm surprised it demands that much RAM.
+Am I missing something?
+Do people cross-compile propellor to avoid the issue?
+
+Cheers!
+
+[1] https://www.olimex.com/Products/OLinuXino/A20/A20-OLinuXino-LIME2
diff --git a/doc/forum/using_propellor_on_low_RAM_devices__63__/comment_1_fc192587233c3cda7d0f78f67311de49._comment b/doc/forum/using_propellor_on_low_RAM_devices__63__/comment_1_fc192587233c3cda7d0f78f67311de49._comment
new file mode 100644
index 00000000..af019cf6
--- /dev/null
+++ b/doc/forum/using_propellor_on_low_RAM_devices__63__/comment_1_fc192587233c3cda7d0f78f67311de49._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-01-04T19:02:08Z"
+ content="""
+500 mb seems a bit higher than typical; my own config.hs (500 lines)
+needs 416 mb to build, and the example config.hs included in propellor
+needs 245 mb.
+
+I typically install swapspace on systems with 1 gb or less and it works
+fine. I think the smallest system I've used propellor with was 500 mb.
+"""]]
diff --git a/doc/forum/using_propellor_on_low_RAM_devices__63__/comment_2_b58e57d9edb7c574ff8a72dbcd24d1b7._comment b/doc/forum/using_propellor_on_low_RAM_devices__63__/comment_2_b58e57d9edb7c574ff8a72dbcd24d1b7._comment
new file mode 100644
index 00000000..9356298b
--- /dev/null
+++ b/doc/forum/using_propellor_on_low_RAM_devices__63__/comment_2_b58e57d9edb7c574ff8a72dbcd24d1b7._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~barthelemy"
+ nickname="barthelemy"
+ avatar="http://cdn.libravatar.org/avatar/e99cb15f6029de3225721b3ebdd0233905eb69698e9b229a8c4cc510a4135438"
+ subject="comment 2"
+ date="2020-01-07T00:38:09Z"
+ content="""
+Hi Joey,
+
+thank you for the feedback. I'm glad to know it is supposed to work in those cases.
+It seems freedombox uses btrfs and swapfiles do not work on btrfs partitions. I thus tried with zram (apt get install zram-tools, which set up a 256 MiB swap).
+
+I could then run propellor --spin to the server, it passed.
+Then I rm -rf /usr/local/propellor on server and ran propellor --spin again.
+The build passed again (it took ~75 minute and at some point ghc took 570MiB but it succeedded).
+
+I'm back on track, thank you again!
+"""]]
diff --git a/doc/news/version_5.10.1.mdwn b/doc/news/version_5.10.1.mdwn
new file mode 100644
index 00000000..797664be
--- /dev/null
+++ b/doc/news/version_5.10.1.mdwn
@@ -0,0 +1,15 @@
+propellor 5.10.1 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+ * [ Joey Hess ]
+ * Localdir.hasOriginUrl: Depend on Git.installed.
+ * Localdir.hasOriginUrl: Type changed from UnixLike to DebianLike
+ because Git.installed is not implemented for other unixes.
+ (API change)
+ * Changed the ChrootBootstrapper type class's buildchroot method
+ to take a Info parameter, instead of Maybe System.
+ (The System can be extracted from the Info.)
+ (API change)
+ * [ Sean Whitton ]
+ * Chroot.{de,}bootstrapped uses the chroot's configured apt proxy and
+ mirror, if these exist, when debootstrapping the chroot.
+ * Rename Sbuild.useHostProxy -&gt; Chroot.useHostProxy. (API change)"""]] \ No newline at end of file
diff --git a/doc/news/version_5.6.1.mdwn b/doc/news/version_5.6.1.mdwn
deleted file mode 100644
index 739d49f7..00000000
--- a/doc/news/version_5.6.1.mdwn
+++ /dev/null
@@ -1,4 +0,0 @@
-propellor 5.6.1 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
- * fix Libvirt.hs haddock build
- Thanks, Sean Whitton"""]] \ No newline at end of file
diff --git a/doc/todo/Debootstrap_module_should_respect_a_configured_Apt.proxy.mdwn b/doc/todo/Debootstrap_module_should_respect_a_configured_Apt.proxy.mdwn
index 8887f438..fc817415 100644
--- a/doc/todo/Debootstrap_module_should_respect_a_configured_Apt.proxy.mdwn
+++ b/doc/todo/Debootstrap_module_should_respect_a_configured_Apt.proxy.mdwn
@@ -27,3 +27,5 @@ so tried on my own
to my opinion the schroot config file generated by Sbuild property does something wrong.
Cheers
+
+> [[done]]; I merged patches from spwhitton. --[[Joey]]
diff --git a/doc/todo/spin_without_remote_compilation/comment_8_6a7a6a3acce0b0865e2a389e60c46179._comment b/doc/todo/spin_without_remote_compilation/comment_8_6a7a6a3acce0b0865e2a389e60c46179._comment
new file mode 100644
index 00000000..1325399d
--- /dev/null
+++ b/doc/todo/spin_without_remote_compilation/comment_8_6a7a6a3acce0b0865e2a389e60c46179._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="balu"
+ avatar="http://cdn.libravatar.org/avatar/2ec9dd5a234ce82f117bd81d1e44f2cb"
+ subject="comment 8"
+ date="2019-11-27T16:28:41Z"
+ content="""
+I am very interested in having this feature in the debian package of propellor and would like to help. What is missing to accomplish that?
+"""]]