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/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/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/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
15 files changed, 198 insertions, 0 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/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/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/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?
+"""]]