summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
Diffstat (limited to 'doc')
-rw-r--r--doc/forum/--spin_tries_to_pull_from_central_repository__63__/comment_3_6f6485b10beb3e371c6f5371a9a9c2c4._comment10
-rw-r--r--doc/forum/--spin_tries_to_pull_from_central_repository__63__/comment_4_75a0a229527a7c0c1633b4bd8e461607._comment27
-rw-r--r--doc/forum/Adding_support_for_a_SQL_server/comment_4_22895a34904df9023fcdac0b3937a7c5._comment16
-rw-r--r--doc/forum/Adding_support_for_a_SQL_server/comment_5_10eb776b64b213ca8f8166aacfba9a4d._comment8
-rw-r--r--doc/forum/bind_mounting_in_Sbuild_chroots.mdwn2
-rw-r--r--doc/forum/bind_mounting_in_Sbuild_chroots/comment_1_0f41fc776bb0d595af239f087e5a1d35._comment12
-rw-r--r--doc/forum/can__39__t_get_Apt.trustsKey_to_work/comment_2_d5d1611896fa72bda22e5406285ade2e._comment9
-rw-r--r--doc/forum/can__39__t_get_Apt.trustsKey_to_work/comment_3_1aa2a2c87eab63305143768575c2f0d9._comment15
-rw-r--r--doc/forum/integration_with_gitolite.mdwn2
-rw-r--r--doc/forum/integration_with_gitolite/comment_1_b2989bbf9e980ceebf2f4cccd4d379e1._comment11
-rw-r--r--doc/forum/integration_with_gitolite/comment_2_42d3e861e2044479523609ff7b339f6b._comment29
-rw-r--r--doc/forum/integration_with_gitolite/comment_3_394a42544ad97e30a8e28ed10de7cd3c._comment8
-rw-r--r--doc/forum/integration_with_gitolite/comment_4_448d79859b2b35e1731adfaa460aa844._comment33
-rw-r--r--doc/forum/integration_with_gitolite/comment_5_1e71a38b32148228b94c7429e721685f._comment15
-rw-r--r--doc/forum/integration_with_gitolite/comment_6_232d8ab023d060d7d9c000e4c6783ef8._comment8
-rw-r--r--doc/forum/making_sure_a_package_is_at_the_latest_version.mdwn13
-rw-r--r--doc/forum/making_sure_a_package_is_at_the_latest_version/comment_1_6a73c8b0de1999f05af184bf63ad014a._comment8
-rw-r--r--doc/forum/making_sure_a_package_is_at_the_latest_version/comment_2_7a911c68e4c81031c98dbefce730ade8._comment8
-rw-r--r--doc/forum/making_sure_a_package_is_at_the_latest_version/comment_3_48fe0419c259c9555b6349c3221a80a0._comment10
-rw-r--r--doc/todo/Apt.trustsKey_should_not_invoke_apt-key.mdwn9
-rw-r--r--doc/todo/apt_mark_support.mdwn27
-rw-r--r--doc/todo/spin_failure_HEAD.mdwn2
-rw-r--r--doc/todo/spin_failure_HEAD/comment_1_9c7d9ae7860d9cfc28e7d015b015dc2e._comment9
-rw-r--r--doc/todo/spin_failure_HEAD/comment_2_a9b7013305a7f8d58175510b57bbadd2._comment8
-rw-r--r--doc/todo/spin_failure_HEAD/comment_3_952939a1333d6fc24ed288a80b76f168._comment8
-rw-r--r--doc/todo/spin_failure_HEAD/comment_4_684adfe4d134b4e27ed00db62f8e3372._comment43
26 files changed, 349 insertions, 1 deletions
diff --git a/doc/forum/--spin_tries_to_pull_from_central_repository__63__/comment_3_6f6485b10beb3e371c6f5371a9a9c2c4._comment b/doc/forum/--spin_tries_to_pull_from_central_repository__63__/comment_3_6f6485b10beb3e371c6f5371a9a9c2c4._comment
new file mode 100644
index 00000000..6b32f1bb
--- /dev/null
+++ b/doc/forum/--spin_tries_to_pull_from_central_repository__63__/comment_3_6f6485b10beb3e371c6f5371a9a9c2c4._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="david@1439a1cab13195a56248b6a8fd98a62028bcba8a"
+ nickname="david"
+ avatar="http://cdn.libravatar.org/avatar/22c2d800db6a7699139df604a67cb221"
+ subject="Still biting me"
+ date="2018-08-23T20:32:18Z"
+ content="""
+I have a similar problem with inaccessible central repo. This crash is still biting me when spinning from a Debian stable (stretch) host to itself.
+I could potentially make the central repo accessible via adding a key, but I think the pull is too early in the process for that work out. Any other ideas? Can I just turn off this pull for some hosts?
+"""]]
diff --git a/doc/forum/--spin_tries_to_pull_from_central_repository__63__/comment_4_75a0a229527a7c0c1633b4bd8e461607._comment b/doc/forum/--spin_tries_to_pull_from_central_repository__63__/comment_4_75a0a229527a7c0c1633b4bd8e461607._comment
new file mode 100644
index 00000000..e60cd5bb
--- /dev/null
+++ b/doc/forum/--spin_tries_to_pull_from_central_repository__63__/comment_4_75a0a229527a7c0c1633b4bd8e461607._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="david"
+ avatar="http://cdn.libravatar.org/avatar/22c2d800db6a7699139df604a67cb221"
+ subject="pulling from a central repo via ssh"
+ date="2018-08-25T18:50:39Z"
+ content="""
+I ended up updating to a more recent propellor for other reasons, but here's my hack to have propellor fetch over ssh:
+[[!format haskell \"\"\"
+rootSsh :: Property (HasInfo + UnixLike)
+rootSsh = propertyList \"ssh setup for root\" $ props
+ & Ssh.userKeyAt (Just keypath) (User \"root\") (Context \"propellor\") (SshRsa, Tethera.Keys.propellor_deploy_ssh)
+ & Ssh.knownHost hosts \"gitolite.tethera.net\" (User \"root\")
+ & File.containsBlock configpath [ \"Host propellor-deploy\"
+ , \" Hostname gitolite.tethera.net\"
+ , \" User git\"
+ , \" IdentityFile ~/.ssh/propellor_deploy\"
+ ]
+ where
+ keypath = \"/root/.ssh/propellor_deploy\"
+ configpath = \"/root/.ssh/config\"
+\"\"\"]]
+
+Propellor is used to initially deply a passwordless role key that can be used to pull from the central repo.
+One thing that surprised me a bit is that Ssh.userKeyAt expects an absolute path, or a path relative to /usr/local/propellor.
+
+
+"""]]
diff --git a/doc/forum/Adding_support_for_a_SQL_server/comment_4_22895a34904df9023fcdac0b3937a7c5._comment b/doc/forum/Adding_support_for_a_SQL_server/comment_4_22895a34904df9023fcdac0b3937a7c5._comment
new file mode 100644
index 00000000..786da77a
--- /dev/null
+++ b/doc/forum/Adding_support_for_a_SQL_server/comment_4_22895a34904df9023fcdac0b3937a7c5._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="Nicolas.Schodet"
+ avatar="http://cdn.libravatar.org/avatar/0d7ec808ec329d04ee9a93c0da3c0089"
+ subject="comment 4"
+ date="2018-08-30T21:14:32Z"
+ content="""
+Hello,
+
+I have made a first version to support MySQL databases and users for classic web applications.
+
+You can pull the mysql branch at http://git.ni.fr.eu.org/nicolas/propellor.git
+
+Can you have a look? I find userGrantedOnDatabase.setup' a little hard to read. Is it OK, or do you see a clearer way to write it?
+
+Thanks!
+"""]]
diff --git a/doc/forum/Adding_support_for_a_SQL_server/comment_5_10eb776b64b213ca8f8166aacfba9a4d._comment b/doc/forum/Adding_support_for_a_SQL_server/comment_5_10eb776b64b213ca8f8166aacfba9a4d._comment
new file mode 100644
index 00000000..df119fe7
--- /dev/null
+++ b/doc/forum/Adding_support_for_a_SQL_server/comment_5_10eb776b64b213ca8f8166aacfba9a4d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Nicolas.Schodet"
+ avatar="http://cdn.libravatar.org/avatar/0d7ec808ec329d04ee9a93c0da3c0089"
+ subject="comment 5"
+ date="2018-08-31T20:53:01Z"
+ content="""
+Also added a function to grant global privileges, useful for a backup user.
+"""]]
diff --git a/doc/forum/bind_mounting_in_Sbuild_chroots.mdwn b/doc/forum/bind_mounting_in_Sbuild_chroots.mdwn
new file mode 100644
index 00000000..f2fb8e11
--- /dev/null
+++ b/doc/forum/bind_mounting_in_Sbuild_chroots.mdwn
@@ -0,0 +1,2 @@
+I typically bind mount some user writable directory into an Sbuild chroot, so that I can e.g. access in a git repo or package to install.
+Is there a clean way to do this with propellor's Sbuild module, or is the intent maintain a seperate container / chroot of some kind for interactive debugging?
diff --git a/doc/forum/bind_mounting_in_Sbuild_chroots/comment_1_0f41fc776bb0d595af239f087e5a1d35._comment b/doc/forum/bind_mounting_in_Sbuild_chroots/comment_1_0f41fc776bb0d595af239f087e5a1d35._comment
new file mode 100644
index 00000000..71927311
--- /dev/null
+++ b/doc/forum/bind_mounting_in_Sbuild_chroots/comment_1_0f41fc776bb0d595af239f087e5a1d35._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ avatar="http://cdn.libravatar.org/avatar/9c3f08f80e67733fd506c353239569eb"
+ subject="comment 1"
+ date="2018-09-08T16:54:24Z"
+ content="""
+You could use
+
+ & File.containsLine \"/etc/schroot/sbuild/fstab\" \"...\"
+
+but yes, I think it's cleaner to use the sbuild chroots only for building, and for interactive use some other chroot.
+"""]]
diff --git a/doc/forum/can__39__t_get_Apt.trustsKey_to_work/comment_2_d5d1611896fa72bda22e5406285ade2e._comment b/doc/forum/can__39__t_get_Apt.trustsKey_to_work/comment_2_d5d1611896fa72bda22e5406285ade2e._comment
new file mode 100644
index 00000000..90151369
--- /dev/null
+++ b/doc/forum/can__39__t_get_Apt.trustsKey_to_work/comment_2_d5d1611896fa72bda22e5406285ade2e._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="david"
+ avatar="http://cdn.libravatar.org/avatar/22c2d800db6a7699139df604a67cb221"
+ subject=" GPG keybox database version 1"
+ date="2018-08-24T00:29:50Z"
+ content="""
+I have propellor 5.3.6 running on debian testing. If I spin to the testing host, trustsKey works fine. On stretch I get at 'GPG keybox database version 1' installed. I guess on stretch it's still building propellor from the old sources? In any case, gpg doesn't know what do do with that keybox file (i.e. gpg < file craps out). Weird but true. In any case this breaks apt-key on that host, which is unfortunate. I guess I'll try overriding the trustsKey function in my config.hs
+
+"""]]
diff --git a/doc/forum/can__39__t_get_Apt.trustsKey_to_work/comment_3_1aa2a2c87eab63305143768575c2f0d9._comment b/doc/forum/can__39__t_get_Apt.trustsKey_to_work/comment_3_1aa2a2c87eab63305143768575c2f0d9._comment
new file mode 100644
index 00000000..f76ac16c
--- /dev/null
+++ b/doc/forum/can__39__t_get_Apt.trustsKey_to_work/comment_3_1aa2a2c87eab63305143768575c2f0d9._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2018-08-26T14:34:18Z"
+ content="""
+@david, you might need to edit your config.cabal and specify a newer
+propellor version, although cabal usually picks the most recent version of
+a dependency. Propellor got the patch from this page in version 5.3.4.
+
+Anyway, I don't think the version of propellor matters, the error message
+you quote is related to
+<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844724>.
+I think that the apt key you're using has been generated on a newer system
+and won't work with older gpg.
+"""]]
diff --git a/doc/forum/integration_with_gitolite.mdwn b/doc/forum/integration_with_gitolite.mdwn
new file mode 100644
index 00000000..956d35c3
--- /dev/null
+++ b/doc/forum/integration_with_gitolite.mdwn
@@ -0,0 +1,2 @@
+Does anyone have any experience with integrating propellor and gitolite? I'd be happy with just ssh pubkey management.
+There seem to be two main options. The typical way of managing a gitolite site is by pushing a special git repository "gitolite-admin". There are also a script called [ukm](http://gitolite.com/gitolite/ukm.html). I'm not sure what will be the least hassle. Currently I have to manually commit and push various keys (including the keys needed for access to the propellor repos). Part of the problem could be solved by making the propellor repos available anonymously, but I still have my own ssh key(s) to manage.
diff --git a/doc/forum/integration_with_gitolite/comment_1_b2989bbf9e980ceebf2f4cccd4d379e1._comment b/doc/forum/integration_with_gitolite/comment_1_b2989bbf9e980ceebf2f4cccd4d379e1._comment
new file mode 100644
index 00000000..2432b063
--- /dev/null
+++ b/doc/forum/integration_with_gitolite/comment_1_b2989bbf9e980ceebf2f4cccd4d379e1._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="david@1439a1cab13195a56248b6a8fd98a62028bcba8a"
+ nickname="david"
+ avatar="http://cdn.libravatar.org/avatar/22c2d800db6a7699139df604a67cb221"
+ subject="&quot;For people who use puppet and similar systems&quot;"
+ date="2018-08-23T01:46:30Z"
+ content="""
+Probably the sane way is to [not use the gitolite-admin repo](http://gitolite.com/gitolite/odds-and-ends/#administering-gitolite-directly-on-the-server). Aside from being unfamiliar, that means I have to deal with a bunch small config files (say 50 - 100) in propellor. So far I'm not loving the idea of converting them all to Haskell, even with a script. But maybe I'll come around to it.
+
+
+"""]]
diff --git a/doc/forum/integration_with_gitolite/comment_2_42d3e861e2044479523609ff7b339f6b._comment b/doc/forum/integration_with_gitolite/comment_2_42d3e861e2044479523609ff7b339f6b._comment
new file mode 100644
index 00000000..ab7cc893
--- /dev/null
+++ b/doc/forum/integration_with_gitolite/comment_2_42d3e861e2044479523609ff7b339f6b._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="david@1439a1cab13195a56248b6a8fd98a62028bcba8a"
+ nickname="david"
+ avatar="http://cdn.libravatar.org/avatar/22c2d800db6a7699139df604a67cb221"
+ subject="first attempt"
+ date="2018-08-23T13:36:52Z"
+ content="""
+Here's my first attempt, so you can snicker at my clumsy Haskell.
+
+<pre>
+gitoliteKeys :: User -> Property UnixLike
+gitoliteKeys user@(User username) = property' (\"set up gitolite keys for \" ++ username) $ \w -> do
+ home <- liftIO (User.homedir user)
+ ensureProperty w $ go home
+ where
+ go :: FilePath -> Property UnixLike
+ go home = File.hasContent (home </> \".gitolite/keydir/zzz/propellor\" </> \"bremner@propellor.pub\")
+ [ Tethera.Keys.bremner_ssh ]
+ `before`
+ (Cmd.userScriptProperty user [ \"gitolite compile\", \"gitolite trigger POST_COMPILE\" ]
+ `changesFile` (home </> \"gitolite/.ssh/authorized_keys\"))
+</pre>
+
+
+I think the next step is something like
+<pre>
+Directory.hasContent :: FilePath -> [ (FilePath, [Line]) ] -> Property UnixLike
+</pre>
+"""]]
diff --git a/doc/forum/integration_with_gitolite/comment_3_394a42544ad97e30a8e28ed10de7cd3c._comment b/doc/forum/integration_with_gitolite/comment_3_394a42544ad97e30a8e28ed10de7cd3c._comment
new file mode 100644
index 00000000..1cab310c
--- /dev/null
+++ b/doc/forum/integration_with_gitolite/comment_3_394a42544ad97e30a8e28ed10de7cd3c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ avatar="http://cdn.libravatar.org/avatar/9c3f08f80e67733fd506c353239569eb"
+ subject="comment 3"
+ date="2018-08-23T19:59:13Z"
+ content="""
+It's not a proper module, but my gitolite setup is here: https://git.spwhitton.name/propellor/tree/src/Propellor/Property/SiteSpecific/SPW/Sites.hs#n200
+"""]]
diff --git a/doc/forum/integration_with_gitolite/comment_4_448d79859b2b35e1731adfaa460aa844._comment b/doc/forum/integration_with_gitolite/comment_4_448d79859b2b35e1731adfaa460aa844._comment
new file mode 100644
index 00000000..2aaacf0b
--- /dev/null
+++ b/doc/forum/integration_with_gitolite/comment_4_448d79859b2b35e1731adfaa460aa844._comment
@@ -0,0 +1,33 @@
+[[!comment format=mdwn
+ username="david"
+ avatar="http://cdn.libravatar.org/avatar/22c2d800db6a7699139df604a67cb221"
+ subject="version 2"
+ date="2018-08-25T17:25:03Z"
+ content="""
+I didn't see how you were handling keys, Sean. Did I miss something obvious or are you handling them outside propellor?
+
+Anyway, here's my second version
+[[!format haskell \"\"\"
+gitoliteKeys :: User -> [(FilePath, String)] -> Property UnixLike
+gitoliteKeys user@(User username) keys = property' (\"set up gitolite keys for \" ++ username) $ \w -> do
+ home <- liftIO (User.homedir user)
+ ensureProperty w $ go home
+ where
+ go :: FilePath -> Property UnixLike
+ go home = installKeys keys
+ `onChange` recompile
+ `requires` File.dirExists keydir
+ where
+ keydir = home </> \".gitolite/keydir/zzz/propellor\"
+ recompile = Cmd.userScriptProperty user [ \"gitolite trigger POST_COMPILE\" ]
+ `changesFile` (home </> \"gitolite/.ssh/authorized_keys\")
+ installKeys :: [(FilePath, String)] -> Property UnixLike
+ installKeys [] = doNothing
+ installKeys ((path, content):rest) = File.hasContent (keydir </> path ++ \".pub\") [content]
+ `before` installKeys rest
+\"\"\"]]
+
+I spent a while talking to the gitolite author, and managed to write something more optimal than \"gitolite trigger POST_COMPILE\", but then I realized that
+had my username hardcoded into it. So it takes about 1s longer to run, but is more robust this way.
+
+"""]]
diff --git a/doc/forum/integration_with_gitolite/comment_5_1e71a38b32148228b94c7429e721685f._comment b/doc/forum/integration_with_gitolite/comment_5_1e71a38b32148228b94c7429e721685f._comment
new file mode 100644
index 00000000..8a1e6473
--- /dev/null
+++ b/doc/forum/integration_with_gitolite/comment_5_1e71a38b32148228b94c7429e721685f._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ avatar="http://cdn.libravatar.org/avatar/9c3f08f80e67733fd506c353239569eb"
+ subject="comment 5"
+ date="2018-08-26T17:14:20Z"
+ content="""
+It's these lines:
+
+ -- make my SSH key available to gitolite
+ & File.hasContent \"/srv/git/.gitolite/keydir/spwhitton.pub\"
+ [SPW.mySSHKey]
+ `onChange` (userScriptProperty (User \"git\")
+ [\"gitolite compile\", \"gitolite trigger POST_COMPILE\"]
+ `assume` MadeChange)
+"""]]
diff --git a/doc/forum/integration_with_gitolite/comment_6_232d8ab023d060d7d9c000e4c6783ef8._comment b/doc/forum/integration_with_gitolite/comment_6_232d8ab023d060d7d9c000e4c6783ef8._comment
new file mode 100644
index 00000000..80130d5b
--- /dev/null
+++ b/doc/forum/integration_with_gitolite/comment_6_232d8ab023d060d7d9c000e4c6783ef8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="david"
+ avatar="http://cdn.libravatar.org/avatar/22c2d800db6a7699139df604a67cb221"
+ subject="OIC"
+ date="2018-08-27T14:14:09Z"
+ content="""
+Oh, I see now we are doing essentially the same thing. For those of you following along at home, mine is using that cryptic path because for the key because I am using both gitolite's native key handling and propellor to install keys.
+"""]]
diff --git a/doc/forum/making_sure_a_package_is_at_the_latest_version.mdwn b/doc/forum/making_sure_a_package_is_at_the_latest_version.mdwn
new file mode 100644
index 00000000..5eff9424
--- /dev/null
+++ b/doc/forum/making_sure_a_package_is_at_the_latest_version.mdwn
@@ -0,0 +1,13 @@
+The following property sets up my wacky outbound mail setup.
+<pre>
+smtpLeaf :: Property (HasInfo + DebianLike)
+smtpLeaf = propertyList "smtp leaf node" $ props
+ & Apt.installed["nullmailer", "bsd-mailx"]
+ & File.hasPrivContent "/etc/nullmailer/remotes" anyContext
+ & tetheraApt
+ & Apt.installed ["nullmailer-extras"] & Apt.update & Apt.upgrade
+ & Ssh.userKeys (User "mail") anyContext [ (SshRsa, Tethera.Keys.mail_ssh) ]
+ & Ssh.knownHost hosts "smtp.tethera.net" (User "mail")
+</pre>
+
+The "Apt.update & Apt.upgrade" is there because nullmailer-extras is kindof a work in progress and I need to make sure that when I add a new version to the private apt repo it's drawing from, that get's installed. It works but it seems a bit slow, and more importantly upgrading everything is kindof a heavy side effect (which might even break things), in order to update this one package. Is there a better way to do this? Don't assume I know anything, I started using propellor 2 days ago...
diff --git a/doc/forum/making_sure_a_package_is_at_the_latest_version/comment_1_6a73c8b0de1999f05af184bf63ad014a._comment b/doc/forum/making_sure_a_package_is_at_the_latest_version/comment_1_6a73c8b0de1999f05af184bf63ad014a._comment
new file mode 100644
index 00000000..98fb61eb
--- /dev/null
+++ b/doc/forum/making_sure_a_package_is_at_the_latest_version/comment_1_6a73c8b0de1999f05af184bf63ad014a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ avatar="http://cdn.libravatar.org/avatar/9c3f08f80e67733fd506c353239569eb"
+ subject="comment 1"
+ date="2018-08-24T23:12:17Z"
+ content="""
+The existing properties cannot do what you want. You are going to need to write a new one. Simplest implementation would be something that calls `apt-get install foo=1.2.3`.
+"""]]
diff --git a/doc/forum/making_sure_a_package_is_at_the_latest_version/comment_2_7a911c68e4c81031c98dbefce730ade8._comment b/doc/forum/making_sure_a_package_is_at_the_latest_version/comment_2_7a911c68e4c81031c98dbefce730ade8._comment
new file mode 100644
index 00000000..8e74d21f
--- /dev/null
+++ b/doc/forum/making_sure_a_package_is_at_the_latest_version/comment_2_7a911c68e4c81031c98dbefce730ade8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="david"
+ avatar="http://cdn.libravatar.org/avatar/22c2d800db6a7699139df604a67cb221"
+ subject="just needs Apt.update?"
+ date="2018-08-25T13:04:50Z"
+ content="""
+Thinking about this a bit more, it should be enough to require Apt.update once per host, then rely on Apt.installed to do the right thing. I'll have to test this next time I roll out a new version. In theory I could run apt.update for a single source, but that seems to be tricky on the apt level.
+"""]]
diff --git a/doc/forum/making_sure_a_package_is_at_the_latest_version/comment_3_48fe0419c259c9555b6349c3221a80a0._comment b/doc/forum/making_sure_a_package_is_at_the_latest_version/comment_3_48fe0419c259c9555b6349c3221a80a0._comment
new file mode 100644
index 00000000..ae45baec
--- /dev/null
+++ b/doc/forum/making_sure_a_package_is_at_the_latest_version/comment_3_48fe0419c259c9555b6349c3221a80a0._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2018-08-26T15:14:50Z"
+ content="""
+One approach would be to have a property like spwhitton suggests,
+and use it with the `Apt.robustly` combinator. That way, when you update
+the config to specify a new package version, and apt fails to install it,
+propellor will run apt update and then retry the install.
+"""]]
diff --git a/doc/todo/Apt.trustsKey_should_not_invoke_apt-key.mdwn b/doc/todo/Apt.trustsKey_should_not_invoke_apt-key.mdwn
new file mode 100644
index 00000000..d2f9e6db
--- /dev/null
+++ b/doc/todo/Apt.trustsKey_should_not_invoke_apt-key.mdwn
@@ -0,0 +1,9 @@
+[Over at the Debian BTS](https://bugs.debian.org/907290), David Bremner points out that the apt-key manpage, on Debian stable, says
+
+> Instead of using this [add] [sub]command a keyring should be placed
+> directly in the /etc/apt/trusted.gpg.d/ directory with a
+> descriptive name and either "gpg" or "asc" as file extension.
+
+So ISTM that `Apt.trustsKey` should be implemented simply with `File.hasContents`, i.e., the property should delete any old `.gpg` file and then create a `.asc` file with the text string content of the `AptKey`.
+
+--spwhitton
diff --git a/doc/todo/apt_mark_support.mdwn b/doc/todo/apt_mark_support.mdwn
new file mode 100644
index 00000000..50591222
--- /dev/null
+++ b/doc/todo/apt_mark_support.mdwn
@@ -0,0 +1,27 @@
+I'd like a property that removes all packages that were not installed by
+the current set of propellor properties. For systems that are fully
+specified by propellor, this would keep the cruft from piling up.
+
+This could be done using apt-mark. Before propellor installs anything with
+apt, go through the apt-mark list and set all packages to auto. When apt is
+run to install a package, it will mark it as manually installed. Since
+Apt.installed skips running apt when packages are already installed, it
+would need to either be changed to run apt anyway, or to run apt-mark
+manual. And then after all other properties, run apt-get autoremove.
+
+Running the autoremove at the end is supported by the propellor monad,
+but there's currently no way to run something before all properties.
+The first Apt.install to run could handle the apt-mark-list-to-auto part,
+although there's also not currently any state for the property to keep
+track of if it's run before.
+
+It would also be possible to not do the apt-mark at the beginning. Instead,
+make the Propellor monad a Writer (polymorphized somehow perhaps like Info
+is) and have Apt.install track the packages that are installed. (Or it
+could be changed to a HasInfo property, and then the list of packages would
+accumulate in Info, but there are likely things that use Apt.installed
+inside ensureProperty which that would cause problems for.)
+
+Either way, an action run at the end can then update the apt-mark data to
+reflect the gathered list of packages, and run apt-get autoremove.
+--[[Joey]]
diff --git a/doc/todo/spin_failure_HEAD.mdwn b/doc/todo/spin_failure_HEAD.mdwn
index 1a591b35..e49df633 100644
--- a/doc/todo/spin_failure_HEAD.mdwn
+++ b/doc/todo/spin_failure_HEAD.mdwn
@@ -81,7 +81,7 @@ Sending privdata (73139 bytes) to kite.kitenet.net ... done
[2017-06-18 16:31:16 EDT] received marked GITPUSH
[2017-06-18 16:31:16 EDT] command line: GitPush 11 12
16:31:16.361717 pkt-line.c:80 packet: fetch< 17abde8439d17d49676f549f357f45eb2adce868 refs/remotes/db48x/master
-<pre>
+</pre>
> > So there's an actual protocol error here; the first 13 lines
> > of git protocol were not sent.
diff --git a/doc/todo/spin_failure_HEAD/comment_1_9c7d9ae7860d9cfc28e7d015b015dc2e._comment b/doc/todo/spin_failure_HEAD/comment_1_9c7d9ae7860d9cfc28e7d015b015dc2e._comment
new file mode 100644
index 00000000..8fb8a027
--- /dev/null
+++ b/doc/todo/spin_failure_HEAD/comment_1_9c7d9ae7860d9cfc28e7d015b015dc2e._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="david@1439a1cab13195a56248b6a8fd98a62028bcba8a"
+ nickname="david"
+ avatar="http://cdn.libravatar.org/avatar/22c2d800db6a7699139df604a67cb221"
+ subject="still in 5.3.6"
+ date="2018-08-24T02:12:44Z"
+ content="""
+I'm seeing this problem in 5.3.6, but only when the remote is Debian stable. Both ends are running 5.3.6 built from source.
+"""]]
diff --git a/doc/todo/spin_failure_HEAD/comment_2_a9b7013305a7f8d58175510b57bbadd2._comment b/doc/todo/spin_failure_HEAD/comment_2_a9b7013305a7f8d58175510b57bbadd2._comment
new file mode 100644
index 00000000..a8866294
--- /dev/null
+++ b/doc/todo/spin_failure_HEAD/comment_2_a9b7013305a7f8d58175510b57bbadd2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="david"
+ avatar="http://cdn.libravatar.org/avatar/22c2d800db6a7699139df604a67cb221"
+ subject="still in 5.4.1, but only on one machine"
+ date="2018-08-24T10:11:16Z"
+ content="""
+I updated to 5.4.1, and I still consistenly see this trying to spin my office computer from home. Weirdly a VM running Debian stretch on the same network does not repropduce. I'll have to try from a different machine on the office network to see if that makes a difference.
+"""]]
diff --git a/doc/todo/spin_failure_HEAD/comment_3_952939a1333d6fc24ed288a80b76f168._comment b/doc/todo/spin_failure_HEAD/comment_3_952939a1333d6fc24ed288a80b76f168._comment
new file mode 100644
index 00000000..98d7f18b
--- /dev/null
+++ b/doc/todo/spin_failure_HEAD/comment_3_952939a1333d6fc24ed288a80b76f168._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="david"
+ avatar="http://cdn.libravatar.org/avatar/22c2d800db6a7699139df604a67cb221"
+ subject="definitely network related"
+ date="2018-08-24T13:58:49Z"
+ content="""
+I can spin the same host from a different host on the office LAN (in fact they are connected to a cheapo hub, so that might not be much of a test), and from itself. So I guess it definitely has to do with networking. Does propellor need anything other than port 22 open?
+"""]]
diff --git a/doc/todo/spin_failure_HEAD/comment_4_684adfe4d134b4e27ed00db62f8e3372._comment b/doc/todo/spin_failure_HEAD/comment_4_684adfe4d134b4e27ed00db62f8e3372._comment
new file mode 100644
index 00000000..3f6aebcb
--- /dev/null
+++ b/doc/todo/spin_failure_HEAD/comment_4_684adfe4d134b4e27ed00db62f8e3372._comment
@@ -0,0 +1,43 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2018-08-26T14:50:22Z"
+ content="""
+As far as I know, this was fixed in a series of commits,
+[[!commit 01fc1375cece096ab2dec480b843ecdbc4f0d94e]]
+[[!commit 1555c6f88a0446d3e29149eff8315817696731e1]]
+[[!commit 53fe5ffaac4a243bb9fd3cf0e757128150a6a199]]
+
+The problem was intermittent for me, I think based on network timing and
+different buffering behavior with different timings,
+which made it hard to debug, but I've not seen it since and I was seeing it
+frequently enough to be fairly sure I fixed it.
+
+So I wonder if you might have some sort of version skew issue on the host
+being spun (eg, it could have an old version of propellor installed and be
+failing before spin can update it to the fixed version). The easy way to
+verify you have the fixed version is to run `git config propellor.debug 1`
+in /usr/local/propellor/ on the host being spun, and look for
+"--upload-pack ./propellor --gitpush" in a debug message.
+
+If you're confident the remote propellor has the above commits in it,
+you're going to need to do some debugging.
+Setting `GIT_TRACE_PACKET=1` on the remote system was very helpful in
+understanding the problem, and should probably be your first step.
+Setting that environment inside Propellor.Spin.gitPullFromUpdateServer
+should work, of course you'll have to get the remote host to build
+propellor with that change somehow despite --spin to it not working.
+
+ diff --git a/src/Propellor/Spin.hs b/src/Propellor/Spin.hs
+ index 4a945e82..aa73e3b7 100644
+ --- a/src/Propellor/Spin.hs
+ +++ b/src/Propellor/Spin.hs
+ @@ -359,6 +359,7 @@ spinCommitMessage = "propellor spin"
+ -- to receive the data.
+ gitPullFromUpdateServer :: IO ()
+ gitPullFromUpdateServer = req NeedGitPush gitPushMarker $ \_ -> do
+ + setEnv "GIT_TRACE_PACKET" "1" True
+ -- IO involving stdin can cause data to be buffered in the Handle
+ -- (even when it's set NoBuffering), but we need to pass a FD to
+ -- git fetch containing all of stdin after the gitPushMarker,
+"""]]