diff options
Diffstat (limited to 'doc')
56 files changed, 938 insertions, 89 deletions
diff --git a/doc/forum/Apt.install_return_ok_even_if_asked_something_impossible.mdwn b/doc/forum/Apt.install_return_ok_even_if_asked_something_impossible.mdwn new file mode 100644 index 00000000..2858a75a --- /dev/null +++ b/doc/forum/Apt.install_return_ok_even_if_asked_something_impossible.mdwn @@ -0,0 +1,14 @@ +Hello joey + +here the result of the Apt.installed [ "dgit", "pypi2dsc" ] + + apt installed dgit pypi2dsc ... ok + + +BUT + +pypi2dsc does not exist (it is pypi2deb) + +So there is something wrong with the installed property :) + +Cheers diff --git a/doc/forum/Apt.install_return_ok_even_if_asked_something_impossible/comment_1_9ce26e0a77c118c3b75bb00827a880b9._comment b/doc/forum/Apt.install_return_ok_even_if_asked_something_impossible/comment_1_9ce26e0a77c118c3b75bb00827a880b9._comment new file mode 100644 index 00000000..de841793 --- /dev/null +++ b/doc/forum/Apt.install_return_ok_even_if_asked_something_impossible/comment_1_9ce26e0a77c118c3b75bb00827a880b9._comment @@ -0,0 +1,18 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2016-06-17T14:31:35Z" + content=""" +Implementation has: + + check (isInstallable ps) go + +So, if the packages are not isInstallable, nothing is done, and the property +succeeds. + +I think this check was intended to avoid running apt-get install unncessarily +when the packages are already installed. However, isInstalled doesn't +differentiate between a package being already installed and not available. + +So, fixing. +"""]] diff --git a/doc/forum/Bug_with_Sbuild.mdwn b/doc/forum/Bug_with_Sbuild.mdwn new file mode 100644 index 00000000..3891ba69 --- /dev/null +++ b/doc/forum/Bug_with_Sbuild.mdwn @@ -0,0 +1,68 @@ +Hello, I installed a machine with these properties + + + & sbuild (System (Debian Unstable) "i386") (Just proxy) + & Sbuild.piupartsConfFor (System (Debian Unstable) "i386") + & Sbuild.updatedFor (System (Debian Unstable) "i386") `period` Weekly (Just 1) + & Sbuild.usableBy (User "picca") + & Sbuild.shareAptCache + +where + + + type Proxy = Maybe Url + + sbuild :: System -> Proxy -> RevertableProperty (HasInfo + Linux) Linux + sbuild system@(System dist arch) proxy = Sbuild.builtFor system `before` setup + where + setup :: RevertableProperty (HasInfo + Linux) Linux + setup = Chroot.provisioned chroot + chroot = Chroot.debootstrapped Debootstrap.BuilddD chrootdir $ props + & os + & case proxy of + (Just p) -> "/etc/apt/apt.conf.d/01proxy" `File.hasContent` ["Acquire::http::Proxy \"" ++ p ++ "\";"] + Nothing -> doNothing + & Apt.installed ["apt-transport-https"] + & Apt.stdSourcesList + & Apt.update `onChange` Apt.upgrade + & Apt.cacheCleaned + chrootdir :: FilePath + chrootdir = "/srv/chroot" </> + case dist of + (Debian suite) -> Apt.showSuite suite ++ "-" ++ arch + (Buntish suite) -> suite ++ "-" ++ arch + os = case dist of + (Debian suite) -> osDebian suite arch + + +But when I use it I get this error message + + + i686-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -I/usr/lib/python2.7/dist-packages/numpy/core/include -I/«PKGBUILDDIR»/src -I/usr/include/python2.7 -c /«PKGBUILDDIR»/python/cython/_fisx.cpp -o build/temp.linux-i686-2.7/«PKGBUILDDIR»/python/cython/_fisx.o + ccache: error: Failed to create directory /var/cache/ccache-sbuild/9/1: Permission denied + error: command 'i686-linux-gnu-gcc' failed with exit status 1 + E: pybuild pybuild:274: build: plugin distutils failed with: exit code=1: /usr/bin/python setup.py build + + picca@ORD03037:~/Debian/python-fisx/python-fisx$ ls -l /var/cache/ccache-sbuild/ + total 76 + drwxr-xr-x 2 root root 4096 juin 16 15:48 0 + drwxr-xr-x 2 root root 4096 juin 16 15:48 1 + drwxr-xr-x 2 root root 4096 juin 16 15:48 2 + drwxr-xr-x 2 root root 4096 juin 16 15:48 3 + drwxr-xr-x 2 root root 4096 juin 16 15:48 4 + drwxr-xr-x 2 root root 4096 juin 16 15:48 5 + drwxr-xr-x 2 root root 4096 juin 16 15:48 6 + drwxr-xr-x 2 root root 4096 juin 16 15:48 7 + drwxr-xr-x 2 root root 4096 juin 16 15:48 8 + drwxr-xr-x 2 root root 4096 juin 16 15:48 9 + drwxr-xr-x 2 root root 4096 juin 16 15:48 a + drwxr-xr-x 2 root root 4096 juin 16 15:48 b + drwxr-xr-x 2 root root 4096 juin 16 15:48 c + -rw-rw-r-- 1 picca instrumentation 16 juin 16 16:32 ccache.conf + drwxr-xr-x 2 root root 4096 juin 16 15:48 d + drwxr-xr-x 2 root root 4096 juin 16 15:48 e + drwxr-xr-x 2 root root 4096 juin 16 15:48 f + -r-xr-xr-x 1 root root 172 juin 16 15:48 sbuild-setup + drwxrwxr-x 2 picca instrumentation 4096 juin 16 16:32 tmp + + diff --git a/doc/forum/Bug_with_Sbuild/comment_1_31f5e3716bbea976d7eb780e15aa04b1._comment b/doc/forum/Bug_with_Sbuild/comment_1_31f5e3716bbea976d7eb780e15aa04b1._comment new file mode 100644 index 00000000..742d99b7 --- /dev/null +++ b/doc/forum/Bug_with_Sbuild/comment_1_31f5e3716bbea976d7eb780e15aa04b1._comment @@ -0,0 +1,28 @@ +[[!comment format=mdwn + username="picca" + subject="comment 1" + date="2016-06-17T07:50:41Z" + content=""" +here the manpage fo ccache + + SHARING A CACHE + A group of developers can increase the cache hit rate by sharing a cache directory. To share a cache without unpleasant side effects, the following conditions should to be met: + + · Use the same CCACHE_DIR environment variable setting. + + · Unset the CCACHE_HARDLINK environment variable. + + · Make sure everyone sets the CCACHE_UMASK environment variable to 002. This ensures that cached files are accessible to everyone in the group. + + · Make sure that all users have write permission in the entire cache directory (and that you trust all users of the shared cache). + + · Make sure that the setgid bit is set on all directories in the cache. This tells the filesystem to inherit group ownership for new directories. The command “find $CCACHE_DIR -type d | xargs chmod + g+s” might be useful for this. + + The reason to avoid the hard link mode is that the hard links cause unwanted side effects, as all links to a cached file share the file’s modification timestamp. This results in false dependencies to + be triggered by timestamp-based build systems whenever another user links to an existing file. Typically, users will see that their libraries and binaries are relinked without reason. + + You may also want to make sure that the developers have CCACHE_BASEDIR set appropriately, as discussed in the previous section + +it seems that a a setgid bit is required for all directory. +"""]] diff --git a/doc/forum/Bug_with_Sbuild/comment_2_3ca5ceb0ac97451c1eea00ec72b55896._comment b/doc/forum/Bug_with_Sbuild/comment_2_3ca5ceb0ac97451c1eea00ec72b55896._comment new file mode 100644 index 00000000..c2b34090 --- /dev/null +++ b/doc/forum/Bug_with_Sbuild/comment_2_3ca5ceb0ac97451c1eea00ec72b55896._comment @@ -0,0 +1,9 @@ +[[!comment format=mdwn + username="spwhitton" + subject="comment 2" + date="2016-06-19T07:19:33Z" + content=""" +Thank you for reporting this and for finding the fix, Fred. In a branch I'll be submitting soon I have modified `Ccache.hasCache` to chmod setgid the cache root, and this should propagate to all newly created subdirectories. + +Joey: what do you think about adding `cmdProperty \"chmod\" [\"-R\", \"g+s\" \"/var/cache/ccache-foo\"]` to `Ccache.hasCache` to fix existing broken setups? In my view it would be better to just add a note to the changelog suggesting this fix, but I'm not sure what you think would be best. +"""]] diff --git a/doc/forum/Bug_with_Sbuild/comment_3_59b5bafd51d1255c4ab79e468afcca1c._comment b/doc/forum/Bug_with_Sbuild/comment_3_59b5bafd51d1255c4ab79e468afcca1c._comment new file mode 100644 index 00000000..fc12b9fe --- /dev/null +++ b/doc/forum/Bug_with_Sbuild/comment_3_59b5bafd51d1255c4ab79e468afcca1c._comment @@ -0,0 +1,13 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 3""" + date="2016-06-20T17:53:24Z" + content=""" +I generally try to fix up after bugs in the implementation of properties, +because otherwise maintaining my hosts gets problimatic. + +In this case, the sbuild support is pretty new and probably not much +used, so I guess it's up to you. chmod -R is rather expensive. If there's +a cheap way to detect when that's needed and only run it then, that +would be ideal.. +"""]] diff --git a/doc/forum/Bug_with_Sbuild/comment_4_6777722f9a18832aad1f195e78e6ac03._comment b/doc/forum/Bug_with_Sbuild/comment_4_6777722f9a18832aad1f195e78e6ac03._comment new file mode 100644 index 00000000..70d3dc47 --- /dev/null +++ b/doc/forum/Bug_with_Sbuild/comment_4_6777722f9a18832aad1f195e78e6ac03._comment @@ -0,0 +1,7 @@ +[[!comment format=mdwn + username="spwhitton" + subject="comment 4" + date="2016-06-21T08:57:02Z" + content=""" +I found a way to do it and committed it to the branch we're discussing [[elsewhere|todo/merge_request:_changes_to_Reboot.hs/]]. +"""]] diff --git a/doc/forum/Propellor_from_unprivileged_account.mdwn b/doc/forum/Propellor_from_unprivileged_account.mdwn new file mode 100644 index 00000000..127cee44 --- /dev/null +++ b/doc/forum/Propellor_from_unprivileged_account.mdwn @@ -0,0 +1,4 @@ +I have a need to configure the properties of some machines for which I am not the primary administrator (in particular, this is at a university where the central IT group does the administration, but delegates some tasks to department via sudo or by reading specific files). I imagine that I would have write my own properties. Is there a special way to call propellor, or code changes that need to be made to have propellor do the git clone and build in a user's home directory? + +Best, +Jack diff --git a/doc/forum/Propellor_from_unprivileged_account/comment_1_9a093f5ee1473549cef0578d1b2d1054._comment b/doc/forum/Propellor_from_unprivileged_account/comment_1_9a093f5ee1473549cef0578d1b2d1054._comment new file mode 100644 index 00000000..01fff2a8 --- /dev/null +++ b/doc/forum/Propellor_from_unprivileged_account/comment_1_9a093f5ee1473549cef0578d1b2d1054._comment @@ -0,0 +1,21 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2016-06-09T20:06:05Z" + content=""" +Well propellor is normally built in the user's home directory and then +deploys updates to the hosts and is built and run as root on them. + +If you're wanting to only run propellor as a user, to manage some +user-specific properties, see the Propellor.Location module to change +the path where propellor depploys itself to on a host. + +And in Propellor.Spin it has several `"root@"` that you'd need to change to +make it ssh into the host as a different user. + +And, in Propellor.CmdLine, there's a check of `getRealUserID` to see if it's +running as root. + +I think that's everything that assumes root (aside from a great many +properties of course!), but can't swear to it. +"""]] diff --git a/doc/forum/Systemd_container_pre-setup_properties.mdwn b/doc/forum/Systemd_container_pre-setup_properties.mdwn new file mode 100644 index 00000000..1cb94d66 --- /dev/null +++ b/doc/forum/Systemd_container_pre-setup_properties.mdwn @@ -0,0 +1,3 @@ +When creating a systemd container, what would be the best way to execute properties before propellor is run inside the container proper? + +I'm trying to setup packages for networking in a systemd container, but I first need the network to get the packages. Ideally, we should be able to run a few properties on the chroot that are used when creating a systemd container (and therefore use the host network). So far, I've solved this by adding the properties in the Systemd.Core.installed property. Not nice, but works if all your systemd containers are the same. I've tried creating a chroot myself, tar it and pass that to Systemd.container, but things got a little complicated. It also requires additional properties on the host that have to be moved if the container moved to another host. diff --git a/doc/forum/Systemd_container_pre-setup_properties/comment_1_420b48d04f16fe5ca7a75c4720e50e1a._comment b/doc/forum/Systemd_container_pre-setup_properties/comment_1_420b48d04f16fe5ca7a75c4720e50e1a._comment new file mode 100644 index 00000000..45b8afd4 --- /dev/null +++ b/doc/forum/Systemd_container_pre-setup_properties/comment_1_420b48d04f16fe5ca7a75c4720e50e1a._comment @@ -0,0 +1,35 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2016-06-17T01:49:24Z" + content=""" +Currently, Chroot.provisioned' is passed a `systemdonly :: Bool`, +which limits the chroot provisioning to the Systemd.installed +property. + +What you want to do needs a more flexible interface there. +Add a `Maybe ChildProperty` parameter to specify what should be done +to finish provisioning the chroot. + +Then, change the Systemd.Container data type: + + -data Container = Container MachineName Chroot.Chroot Host + +data Container metatypes = Container + + { containerMachinName :: MachineName + + , containerChroot :: Chroot.Chroot + + , containerHost :: Host + + , containerChrootProvision :: Property metatypes + + } + +And Systemd.nspawned will pass +`(Just (toChildProperty (containerChrootProvision c)))` to `Chroot.provisioned'` + +Systemd.Container constructor functions will default to setting +`containerChrootProvision = Systemd.Core.installed`, but +the user can then change the Container to add more properties +to run in the chroot when provisioning it. + +(There's also a tricky bit where Systemd.nspawned needs to extract any info +from containerChrootProvision and add it onto its own info to propigate +it. If you do the rest of it, I will handle this tricky bit..) +"""]] diff --git a/doc/forum/cabal:_Unrecognised_flags:_propellor-config.mdwn b/doc/forum/cabal:_Unrecognised_flags:_propellor-config.mdwn new file mode 100644 index 00000000..dd8048a2 --- /dev/null +++ b/doc/forum/cabal:_Unrecognised_flags:_propellor-config.mdwn @@ -0,0 +1,106 @@ +G'day Joey. Trying to deploy to a new host and I'm hitting this error: + + cabal: Unrecognised flags: propellor-config + sh: 1: ./propellor: not found + propellor: user error (ssh ["-o","ControlPath=/home/craige/.ssh/propellor/os01.mcwhirter.io.sock","-o","ControlMa + ster=auto","-o","ControlPersist=yes","root@os01.mcwhirter.io","sh -c 'if [ ! -d /usr/local/propellor/.git ] ; the + n (if ! git --version >/dev/null; then apt-get update && DEBIAN_FRONTEND=noninteractive apt-get -qq --no-install- + recommends --no-upgrade -y install git; fi && echo STATUSNeedGitClone) || echo STATUSNeedPrecompiled ; else cd /u + sr/local/propellor && if ! cabal configure >/dev/null 2>&1; then ( apt-get update ; DEBIAN_FRONTEND=noninteractiv + e apt-get -qq --no-upgrade --no-install-recommends -y install gnupg ; DEBIAN_FRONTEND=noninteractive apt-get -qq + --no-upgrade --no-install-recommends -y install ghc ; DEBIAN_FRONTEND=noninteractive apt-get -qq --no-upgrade --n + o-install-recommends -y install cabal-install ; DEBIAN_FRONTEND=noninteractive apt-get -qq --no-upgrade --no-inst + all-recommends -y install libghc-async-dev ; DEBIAN_FRONTEND=noninteractive apt-get -qq --no-upgrade --no-install + -recommends -y install libghc-missingh-dev ; DEBIAN_FRONTEND=noninteractive apt-get -qq --no-upgrade --no-install + -recommends -y install libghc-hslogger-dev ; DEBIAN_FRONTEND=noninteractive apt-get -qq --no-upgrade --no-install + -recommends -y install libghc-unix-compat-dev ; DEBIAN_FRONTEND=noninteractive apt-get -qq --no-upgrade --no-inst + all-recommends -y install libghc-ansi-terminal-dev ; DEBIAN_FRONTEND=noninteractive apt-get -qq --no-upgrade --no + -install-recommends -y install libghc-ifelse-dev ; DEBIAN_FRONTEND=noninteractive apt-get -qq --no-upgrade --no-i + nstall-recommends -y install libghc-network-dev ; DEBIAN_FRONTEND=noninteractive apt-get -qq --no-upgrade --no-in + stall-recommends -y install libghc-mtl-dev ; DEBIAN_FRONTEND=noninteractive apt-get -qq --no-upgrade --no-install + -recommends -y install libghc-transformers-dev ; DEBIAN_FRONTEND=noninteractive apt-get -qq --no-upgrade --no-ins + tall-recommends -y install libghc-exceptions-dev ; DEBIAN_FRONTEND=noninteractive apt-get -qq --no-upgrade --no-i + nstall-recommends -y install libghc-stm-dev ; DEBIAN_FRONTEND=noninteractive apt-get -qq --no-upgrade --no-instal + l-recommends -y install libghc-text-dev ; DEBIAN_FRONTEND=noninteractive apt-get -qq --no-upgrade --no-install-re + commends -y install make ; cabal update ; cabal install --only-dependencies ) || true; fi&& if ! test -x ./propel + lor; then cabal configure && cabal build propellor-config && ln -sf dist/build/propellor-config/propellor-config + propellor; fi;if test -x ./propellor && ! ./propellor --check; then cabal clean && cabal configure && cabal build + propellor-config && ln -sf dist/build/propellor-config/propellor-config propellor; fi && ./propellor --boot os01 + .mcwhirter.io ; fi'"] exited 127) + +When I build propellor manually on the remote host, same issue: + + /usr/local/propellor# cabal build propellor-config + cabal: Unrecognised flags: propellor-config + +Building without the propellor-config flag *appears* to work fine: + + /usr/local/propellor# cabal build + Building propellor-3.0.4... + Preprocessing executable 'propellor-config' for propellor-3.0.4... + ... + Linking dist/build/propellor-config/propellor-config ... + Preprocessing executable 'propellor' for propellor-3.0.4... + +So when I change line 39 in Bootstrap.hs to drop "propellor-config" it appears to work OK, locally: + + % ~/.propellor/propellor --spin os01.mcwhirter.io + Preprocessing executable 'propellor-config' for propellor-3.0.4... + [85 of 90] Compiling Propellor.Bootstrap ( src/Propellor/Bootstrap.hs, dist/build/propellor-config/propellor-config-tmp/Propellor/Bootstrap.o ) + Linking dist/build/propellor-config/propellor-config ... + Propellor build ... done + + You need a passphrase to unlock the secret key for + user: ???? + 4096-bit RSA key, ID ?????, created ???? + + [master 0e810ff] propellor spin + 1 file changed, 4 insertions(+), 3 deletions(-) + Git commit ... done + Resolving dependencies... + Configuring propellor-3.0.4... + Warning: 'license: BSD2' is not a recognised license. The known licenses are: + GPL, GPL-2, GPL-3, LGPL, LGPL-2.1, LGPL-3, BSD3, MIT, Apache, Apache-2.0, + PublicDomain, AllRightsReserved, OtherLicense + Building propellor-3.0.4... + Preprocessing executable 'propellor-config' for propellor-3.0.4... + Preprocessing executable 'propellor' for propellor-3.0.4... + Preprocessing library propellor-3.0.4... + ... + +However it still fails with the original error on the remote host, despite the new Bootstrap.hs having been copied in place correctly. + + % ~/.propellor/propellor --spin os01.mcwhirter.io + Preprocessing executable 'propellor-config' for propellor-3.0.4... + [85 of 90] Compiling Propellor.Bootstrap ( src/Propellor/Bootstrap.hs, dist/build/propellor-config/propellor-config-tmp/Propellor/Bootstrap.o ) + Linking dist/build/propellor-config/propellor-config ... + Propellor build ... done + + You need a passphrase to unlock the secret key for + user: ????? + 4096-bit RSA key, ID ?????, created ????? + + [master bf1b056] propellor spin + 1 file changed, 1 deletion(-) + Git commit ... done + Sending privdata (11 bytes) to os01.mcwhirter.io ... done + Sending git update to os01.mcwhirter.io ... done + remote: Counting objects: 5, done. + remote: Compressing objects: 100% (5/5), done. + remote: Total 5 (delta 4), reused 0 (delta 0) + From . + * branch HEAD -> FETCH_HEAD + cabal: Unrecognised flags: propellor-config + Resolving dependencies... + Configuring propellor-3.0.4... + Warning: 'license: BSD2' is not a recognised license. The known licenses are: + GPL, GPL-2, GPL-3, LGPL, LGPL-2.1, LGPL-3, BSD3, MIT, Apache, Apache-2.0, + PublicDomain, AllRightsReserved, OtherLicense + cabal: Unrecognised flags: propellor-config + propellor: cabal build failed + Shared connection to os01.mcwhirter.io closed. + propellor: remote propellor failed + +I feel like I'm working around another local issue but so far my "fix" has been in Bootstrap.hs. + +Thoughts? diff --git a/doc/forum/cabal:_Unrecognised_flags:_propellor-config/comment_1_5742cd0937a47a14cf3dc41e003e3855._comment b/doc/forum/cabal:_Unrecognised_flags:_propellor-config/comment_1_5742cd0937a47a14cf3dc41e003e3855._comment new file mode 100644 index 00000000..93d70dc0 --- /dev/null +++ b/doc/forum/cabal:_Unrecognised_flags:_propellor-config/comment_1_5742cd0937a47a14cf3dc41e003e3855._comment @@ -0,0 +1,26 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2016-06-07T17:13:29Z" + content=""" +propellor-config is the name of the Executable component +in the cabal file that we want cabal to build. + + Usage: cabal build [FLAGS] + or: cabal build COMPONENTS [FLAGS] + +It's the COMPONENT shown in the cabal build help. It seems that your cabal +doesn't not understand this syntax. What version of cabal is that? + +(Based on the license warning, I'm guessing its an older version of cabal +than the 1.22.6.0 I'm using here. The cabal 1.20.0.3 in Debian stable also +supports this syntax.) + +Only building the propellor-config Executable is only an optimisation; +otherwise cabal build also builds propellor as a library which is not +needed here. So your workaround to drop that parameter should be ok. + +You probably need to rebuild propellor on the remote host manually +after updating the code there, since the remote host has a version of +propellor compiled such that it tries to recompile itself using that parameter.. +"""]] diff --git a/doc/forum/cabal:_Unrecognised_flags:_propellor-config/comment_2_7121b4ceb44419c7a9b3b0c2ff76e52b._comment b/doc/forum/cabal:_Unrecognised_flags:_propellor-config/comment_2_7121b4ceb44419c7a9b3b0c2ff76e52b._comment new file mode 100644 index 00000000..928f5d11 --- /dev/null +++ b/doc/forum/cabal:_Unrecognised_flags:_propellor-config/comment_2_7121b4ceb44419c7a9b3b0c2ff76e52b._comment @@ -0,0 +1,26 @@ +[[!comment format=mdwn + username="craige@a46118dff5bc0fad85259759970d8b4b9fc377d7" + nickname="craige" + subject="comment 2" + date="2016-06-07T22:32:04Z" + content=""" +Local (Debian \"Stretch\"): + + % cabal -V + cabal-install version 1.22.9.0 + using version 1.22.8.0 of the Cabal library + +Remote (Buntish 14.04): + + # cabal -V + cabal-install version 1.16.0.2 + using version 1.16.0 of the Cabal library + +This host needs to remain 14.04 for reasons out of my control. + +When I land in a few hours, I'll try upgrading cabal on that host and I expect the problem will disappear. + +Thanks! + +(kicking myself for not thinking of cabal versions) +"""]] diff --git a/doc/forum/cabal:_Unrecognised_flags:_propellor-config/comment_3_886748a3a28e33c90bbc5485eddc8efb._comment b/doc/forum/cabal:_Unrecognised_flags:_propellor-config/comment_3_886748a3a28e33c90bbc5485eddc8efb._comment new file mode 100644 index 00000000..8c04f052 --- /dev/null +++ b/doc/forum/cabal:_Unrecognised_flags:_propellor-config/comment_3_886748a3a28e33c90bbc5485eddc8efb._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 3""" + date="2016-06-08T17:07:09Z" + content=""" +This could be probed at runtime, I'd be willing to consider a patch +checking cabal --version if you want to develop one. + +(Propellor supports Debian stable, but Ubuntu 14.04 is older than that.) +"""]] diff --git a/doc/forum/cabal:_Unrecognised_flags:_propellor-config/comment_4_7ee19c190d1acb8106079871dda7f521._comment b/doc/forum/cabal:_Unrecognised_flags:_propellor-config/comment_4_7ee19c190d1acb8106079871dda7f521._comment new file mode 100644 index 00000000..83ebf6ec --- /dev/null +++ b/doc/forum/cabal:_Unrecognised_flags:_propellor-config/comment_4_7ee19c190d1acb8106079871dda7f521._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="craige@a46118dff5bc0fad85259759970d8b4b9fc377d7" + nickname="craige" + subject="Resolved" + date="2016-06-13T23:35:40Z" + content=""" +Cracked enough heads to get the box upgraded and the issue unsurpisingly vanished :-) +"""]] diff --git a/doc/forum/functions_that_yield_properties/comment_5_922e9e20c5326ceb695f7593d8bd72f5._comment b/doc/forum/functions_that_yield_properties/comment_5_922e9e20c5326ceb695f7593d8bd72f5._comment new file mode 100644 index 00000000..7cbcdd84 --- /dev/null +++ b/doc/forum/functions_that_yield_properties/comment_5_922e9e20c5326ceb695f7593d8bd72f5._comment @@ -0,0 +1,38 @@ +[[!comment format=mdwn + username="spwhitton" + subject="comment 5" + date="2016-06-07T07:32:49Z" + content=""" +Unfortunately, the more general type doesn't seem to work: + + withMyAcc + :: (SingI outer, Cannot_ensureProperty_WithInfo inner ~ 'True, + NotSuperset (Targets inner) (Targets outer) ~ 'CanCombine) + => Desc + -> (User -> Property (MetaTypes inner)) + -> Property (MetaTypes outer) + withMyAcc desc mkp = property' desc $ \w -> do + u <- getMyAcc + ensureProperty w (mkp u) + + accountForSean :: Property DebianLike + accountForSean = withMyAcc \"account for Sean\" User.accountFor + +yields + + src/Propellor/Property/SiteSpecific/SPW/Account.hs:85:18: + Couldn't match kind ‘*’ with ‘MetaType’ + Expected type: Property DebianLike + Actual type: Property (MetaTypes outer0) + In the expression: withMyAcc \"account for Sean\" User.accountFor + In an equation for ‘accountForSean’: + accountForSean = withMyAcc \"account for Sean\" User.accountFor + + src/Propellor/Property/SiteSpecific/SPW/Account.hs:85:47: + Couldn't match kind ‘MetaType’ with ‘*’ + Expected type: User -> Property (MetaTypes inner0) + Actual type: User -> Property DebianLike + In the second argument of ‘withMyAcc’, namely ‘User.accountFor’ + In the expression: withMyAcc \"account for Sean\" User.accountFor + +"""]] diff --git a/doc/forum/use_withUmask_in_a_property.mdwn b/doc/forum/use_withUmask_in_a_property.mdwn new file mode 100644 index 00000000..9ae7d7ba --- /dev/null +++ b/doc/forum/use_withUmask_in_a_property.mdwn @@ -0,0 +1,12 @@ +I'm trying to combine the following two properties: + + propertyList "generate new key file" $ props + & cmdProperty "openssl" + [ "genrsa" + , "4096" + , "> " ++ key + ] + `assume` MadeChange + & key `File.mode` combineModes [ownerReadMode, ownerWriteMode] + +I've tried to use withUmask, without success. Is there a way to do that? diff --git a/doc/forum/use_withUmask_in_a_property/comment_1_593c3e8b1499b4cc9cc7db74bb775506._comment b/doc/forum/use_withUmask_in_a_property/comment_1_593c3e8b1499b4cc9cc7db74bb775506._comment new file mode 100644 index 00000000..d52b4786 --- /dev/null +++ b/doc/forum/use_withUmask_in_a_property/comment_1_593c3e8b1499b4cc9cc7db74bb775506._comment @@ -0,0 +1,38 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2016-06-20T18:04:27Z" + content=""" + withUmask :: (MonadIO m, MonadMask m) => FileMode -> m a -> m a + +That needs a monad, and propellor Property is not a monad itself. +But, a Property does contain an Propellor monad action, which is run to ensure +that the property is met. You can use withUmask inside that action. + +The problem then becomes, how to run a Property like +your `cmdProperty` inside the Propellor monad? + +The answer is, using `ensureProperty`. +[Documentation](http://hackage.haskell.org/package/propellor/docs/Propellor-EnsureProperty.html) + +Something like this is what you're looking for: + + foo = Property UnixLike + foo = property' "generate new key file" $ \w -> + withUmask filemode $ + ensureProperty w genrsa + where + filemode = -- something + + genrsa :: Property UnixLike + genrsa = cmdProperty "openssl" + [ "genrsa" + , "4096" + , "> " ++ key + ] + `assume` MadeChange + +Incidentially, cmdProperty runs a command without exposing it to the +shell, so I don't think the redirection in your example will work. +You probably want to use scriptProperty instead. +"""]] diff --git a/doc/forum/use_withUmask_in_a_property/comment_2_edefd952bdb96c8a6a5d705170a05a77._comment b/doc/forum/use_withUmask_in_a_property/comment_2_edefd952bdb96c8a6a5d705170a05a77._comment new file mode 100644 index 00000000..a569d068 --- /dev/null +++ b/doc/forum/use_withUmask_in_a_property/comment_2_edefd952bdb96c8a6a5d705170a05a77._comment @@ -0,0 +1,20 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 2""" + date="2016-06-20T18:36:07Z" + content=""" +Here's another, perhaps simpler way to do it. The `adjustPropertySatisfy` +function takes an existing Property and applies a function to the Propellor +action inside it. + + adjustPropertySatisfy :: Property metatypes -> (Propellor Result -> Propellor Result) -> Property metatypes + +So, given the `genrsa` Property from my example above, you could +modify its action to use withUmask: + + adjustPropertySatisfy genrsa (withUmask filemode) + +This is simpler, but less flexible since it causes the entire +Propellor action to be run with the specified umask, not just part of the +action. But it works well for your purpose I think. +"""]] diff --git a/doc/forum/use_withUmask_in_a_property/comment_3_5bdd79ed99f2b001d5dfc8a7d0b2c177._comment b/doc/forum/use_withUmask_in_a_property/comment_3_5bdd79ed99f2b001d5dfc8a7d0b2c177._comment new file mode 100644 index 00000000..3a9f89c2 --- /dev/null +++ b/doc/forum/use_withUmask_in_a_property/comment_3_5bdd79ed99f2b001d5dfc8a7d0b2c177._comment @@ -0,0 +1,18 @@ +[[!comment format=mdwn + username="gueux" + subject="comment 3" + date="2016-06-20T18:49:30Z" + content=""" +Thanks! + +By reading Cmd.hs, I've managed to get this: + + createKey :: FilePath -> Property UnixLike + createKey key = property (\"new private key file: \" ++ key) $ liftIO $ withUmask 0o0177 $ withFile key WriteMode $ \h -> + cmdResult <$> boolSystem' \"openssl\" [Param \"genrsa\", Param \"4096\"] (\p -> p { std_out = UseHandle h }) + + cmdResult :: Bool -> Result + cmdResult False = FailedChange + cmdResult True = NoChange + +"""]] diff --git a/doc/forum/use_withUmask_in_a_property/comment_4_13bfe4aec95f5e72f4f61b764fb29a5a._comment b/doc/forum/use_withUmask_in_a_property/comment_4_13bfe4aec95f5e72f4f61b764fb29a5a._comment new file mode 100644 index 00000000..0a45cdfc --- /dev/null +++ b/doc/forum/use_withUmask_in_a_property/comment_4_13bfe4aec95f5e72f4f61b764fb29a5a._comment @@ -0,0 +1,7 @@ +[[!comment format=mdwn + username="gueux" + subject="comment 4" + date="2016-06-21T09:42:31Z" + content=""" +Is there a equivalent of `withUmask` for `withFile`? The latter seems harder to interact with... +"""]] diff --git a/doc/forum/use_withUmask_in_a_property/comment_5_da0074f18fe0ce020325a9f59f44cb1d._comment b/doc/forum/use_withUmask_in_a_property/comment_5_da0074f18fe0ce020325a9f59f44cb1d._comment new file mode 100644 index 00000000..c566bb64 --- /dev/null +++ b/doc/forum/use_withUmask_in_a_property/comment_5_da0074f18fe0ce020325a9f59f44cb1d._comment @@ -0,0 +1,13 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 5""" + date="2016-06-22T19:24:43Z" + content=""" +Unfortunately `withFile` uses IO, instead of being generalized to MonadIO, +so the approaches that work with `withUmask` don't work with it. + +One way is to write a version of withFile that's generalized to MonadIO: + + withFile' :: (MonadIO m, MonadMask m) => FilePath -> IOMode -> (Handle -> m r) -> m r + withFile' name mode = bracket (liftIO $ openFile name mode) (liftIO . hClose) +"""]] diff --git a/doc/haskell_newbie.mdwn b/doc/haskell_newbie.mdwn index bd343cd6..d6e339ed 100644 --- a/doc/haskell_newbie.mdwn +++ b/doc/haskell_newbie.mdwn @@ -48,12 +48,12 @@ Finally, you need to define the configuration for each host in the list: [[!format haskell """ mylaptop :: Host mylaptop = host "mylaptop.example.com" - & osDebian Unstable "amd64" + & osDebian Unstable X86_64 & Apt.stdSourcesList myserver :: Host myserver = host "server.example.com" - & osDebian (Stable "jessie") "amd64" + & osDebian (Stable "jessie") X86_64 & Apt.stdSourcesList & Apt.installed ["ssh"] """]] diff --git a/doc/news/version_2.15.4.mdwn b/doc/news/version_2.15.4.mdwn deleted file mode 100644 index 4e20bcc9..00000000 --- a/doc/news/version_2.15.4.mdwn +++ /dev/null @@ -1,15 +0,0 @@ -propellor 2.15.4 released with [[!toggle text="these changes"]] -[[!toggleable text=""" - * Build /usr/src/propellor/propellor.git reproducibly, - which makes the whole Debian package build reproducibly. - Thanks, Sean Whitton. - * Obnam: To cause old generations to be forgotten, keepParam can be - passed to a backup property; this causes obnam forget to be run. - * Delete /etc/apt/apt.conf.d/50unattended-upgrades.ucf-dist when - unattended-upgrades is installed, to work around #812380 which results - in many warnings from apt, including in cron mails. - * Added Propellor.Property.LetsEncrypt - * Apache.httpsVirtualHost: New property, setting up a https vhost - with the certificate automatically obtained using letsencrypt. - * Allow using combineProperties and propertyList with lists of - RevertableProperty."""]]
\ No newline at end of file diff --git a/doc/news/version_2.16.0.mdwn b/doc/news/version_2.16.0.mdwn deleted file mode 100644 index b7527f05..00000000 --- a/doc/news/version_2.16.0.mdwn +++ /dev/null @@ -1,18 +0,0 @@ -propellor 2.16.0 released with [[!toggle text="these changes"]] -[[!toggleable text=""" - * Obnam: Only let one backup job run at a time when a host has multiple - different backup properties, to avoid concurrent jobs fighting over - scarce resources (particularly memory). Other jobs block on a lock - file. - * Removed references to a Debian derivative from code and documentation - because of an unfortunate trademark use policy. - http://joeyh.name/blog/entry/trademark\_nonsense/ - * That included changing a data constructor to "Buntish", an API change. - * Firewall.rule: Now takes a Table parameter. (API change) - * Firewall: add InIFace/OutIFace Rules, add Source/Destination Rules, - add CustomTarget, and more improvements. - Thanks, Félix Sipma. - * Ssh.authorizedKey: Fix bug preventing it from working when the - authorized\_keys file does not yet exist. - * Removed Ssh.unauthorizedKey and made Ssh.authorizedKey revertable. - (API change)"""]]
\ No newline at end of file diff --git a/doc/news/version_2.17.0.mdwn b/doc/news/version_2.17.0.mdwn deleted file mode 100644 index 4149dbab..00000000 --- a/doc/news/version_2.17.0.mdwn +++ /dev/null @@ -1,30 +0,0 @@ -propellor 2.17.0 released with [[!toggle text="these changes"]] -[[!toggleable text=""" - * Added initial support for FreeBSD. - Thanks, Evan Cofsky. - * Added Propellor.Property.ZFS. - Thanks, Evan Cofsky. - * Firewall: Reorganized Chain data type. (API change) - Thanks, Félix Sipma. - * Firewall: Separated Table and Target (API change) - Thanks, Félix Sipma. - * Ssh: change type of listenPort from Int to Port (API change) - Thanks, Félix Sipma. - * Firewall: add TCPFlag, Frequency, TCPSyn, ICMPTypeMatch, NatDestination - Thanks, Félix Sipma. - * Network: Filter out characters not allowed in interfaces.d files. - Thanks, Félix Sipma. - * Apt.upgrade: Run dpkg --configure -a first, to recover from - interrupted upgrades. - * Apt: Add safeupgrade. - * Force ssh, scp, and git commands to be run in the foreground. - Should fix intermittent hangs of propellor --spin. - * Avoid repeated re-building on systems such as FreeBSD where building - re-links the binary even when there are no changes. - * Locale.available: Run locale-gen, instead of dpkg-reconfigure locales, - which modified the locale.gen file and sometimes caused the property to - need to make changes every time. - * Speed up propellor's build of itself, by asking cabal to only build - the propellor-config binary and not all the libraries. - * Tor.named: Fix bug that sometimes caused the property to fail the first - time, though retrying succeeded."""]]
\ No newline at end of file diff --git a/doc/news/version_2.17.1.mdwn b/doc/news/version_2.17.1.mdwn deleted file mode 100644 index 22727666..00000000 --- a/doc/news/version_2.17.1.mdwn +++ /dev/null @@ -1,8 +0,0 @@ -propellor 2.17.1 released with [[!toggle text="these changes"]] -[[!toggleable text=""" - * Avoid generating excessively long paths to the unix socket file - used for ssh connection caching. Mostly. Can still generate a too long - one if $HOME is longer than 60 bytes. - * Uwsgi: add ".ini" extension to app config files. - Files without extensions were ignored by uwsgi. - Thanks, Félix Sipma."""]]
\ No newline at end of file diff --git a/doc/news/version_2.17.2.mdwn b/doc/news/version_2.17.2.mdwn deleted file mode 100644 index 3b11ec89..00000000 --- a/doc/news/version_2.17.2.mdwn +++ /dev/null @@ -1,8 +0,0 @@ -propellor 2.17.2 released with [[!toggle text="these changes"]] -[[!toggleable text=""" - * When new dependencies are added to propellor or the propellor config, - try harder to get them installed. In particular, this makes - propellor --spin work when the remote host needs to get dependencies - installed in order to build the updated config. - * Apt.update: Also run dpkg --configure -a here as apt for some reason - won't even update if dpkg was interrupted."""]]
\ No newline at end of file diff --git a/doc/news/version_3.0.4.mdwn b/doc/news/version_3.0.4.mdwn deleted file mode 100644 index f6e1eac2..00000000 --- a/doc/news/version_3.0.4.mdwn +++ /dev/null @@ -1,8 +0,0 @@ -propellor 3.0.4 released with [[!toggle text="these changes"]] -[[!toggleable text=""" - * Run letsencrypt with --noninteractive. - * Fix build with ghc 8.0.1. - Thanks, davean. - * Module added for the Borg backup system. - Thanks, Félix Sipma. - * Fix build with directory-1.2.6.2."""]]
\ No newline at end of file diff --git a/doc/news/version_3.0.5.mdwn b/doc/news/version_3.0.5.mdwn new file mode 100644 index 00000000..b9655cf5 --- /dev/null +++ b/doc/news/version_3.0.5.mdwn @@ -0,0 +1,8 @@ +propellor 3.0.5 released with [[!toggle text="these changes"]] +[[!toggleable text=""" + * Modules added for Sbuild and Ccache. + Thanks, Sean Whitton + * Systemd: Added killUserProcesses property, which can be reverted + to return systemd to its default behavior before version 230 started + killing processes like screen sessions. + * Systemd: Added logindConfigured property."""]]
\ No newline at end of file diff --git a/doc/todo/bytes_in_privData__63__.mdwn b/doc/todo/bytes_in_privData__63__.mdwn index 27297fd5..66e3b1c2 100644 --- a/doc/todo/bytes_in_privData__63__.mdwn +++ b/doc/todo/bytes_in_privData__63__.mdwn @@ -15,3 +15,5 @@ It seems like I can't set the content of a PrivFile to arbitrary bytes. Enter private data on stdin; ctrl-D when done: propellor: <stdin>: hGetContents: invalid argument (invalid byte sequence) + +> [[done]]! --[[Joey]] diff --git a/doc/todo/bytes_in_privData__63__/comment_10_7812a96a98405d924a69e998dd42f275._comment b/doc/todo/bytes_in_privData__63__/comment_10_7812a96a98405d924a69e998dd42f275._comment new file mode 100644 index 00000000..602f91f0 --- /dev/null +++ b/doc/todo/bytes_in_privData__63__/comment_10_7812a96a98405d924a69e998dd42f275._comment @@ -0,0 +1,9 @@ +[[!comment format=mdwn + username="andrew" + subject="comment 10" + date="2016-06-17T05:25:08Z" + content=""" +I've recreated my propellor repository a few times and have had to write out .pfx files. Essentially a binary format of .pem and .key. I had no problem getting the pfx file into privData, but propellor bails when writing the binary data on the host. This patch tackles the writing on host bit (not the writing to privData). You've used `hPutStr` to write out data which errors on certain bytes (because `hPutStr` assumes a character encoding?). 0x00 is a likely candidate. I don't recall the exact error, but at least Haskell noticed this and gave an error rather than writing out a partial file. + +I'll see if I can get a deduping patch to tidy up fileProperty and byteProperty. +"""]] diff --git a/doc/todo/bytes_in_privData__63__/comment_11_3839f018cbbd1043e645bf728162dea1._comment b/doc/todo/bytes_in_privData__63__/comment_11_3839f018cbbd1043e645bf728162dea1._comment new file mode 100644 index 00000000..93094e84 --- /dev/null +++ b/doc/todo/bytes_in_privData__63__/comment_11_3839f018cbbd1043e645bf728162dea1._comment @@ -0,0 +1,14 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 11""" + date="2016-06-17T13:16:17Z" + content=""" +Hmm, the way Strings are used for PrivData takes advantage of ghc's +"filename encoding", which is supposed to allow arbitrary bytes to be +included in filenames; unicode surrogate characters are used to map +them to unicode. + +But, Property.File is using readFile, witeFile, and writeFileProtected, +which will bail on invalid unicode as the filename encoding is not used. +Your patch avoids that problem I see. +"""]] diff --git a/doc/todo/bytes_in_privData__63__/comment_12_a4edd5e06854a4b37eeb6b3db5c01947._comment b/doc/todo/bytes_in_privData__63__/comment_12_a4edd5e06854a4b37eeb6b3db5c01947._comment new file mode 100644 index 00000000..1d645d09 --- /dev/null +++ b/doc/todo/bytes_in_privData__63__/comment_12_a4edd5e06854a4b37eeb6b3db5c01947._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 12""" + date="2016-06-19T17:53:17Z" + content=""" +I found a reasonable way to refactor it without the duplication, so have +landed the patch. +"""]] diff --git a/doc/todo/bytes_in_privData__63__/comment_8_07f4a5604e51ee3114853e5017ef2a5f._comment b/doc/todo/bytes_in_privData__63__/comment_8_07f4a5604e51ee3114853e5017ef2a5f._comment new file mode 100644 index 00000000..11010dd2 --- /dev/null +++ b/doc/todo/bytes_in_privData__63__/comment_8_07f4a5604e51ee3114853e5017ef2a5f._comment @@ -0,0 +1,9 @@ +[[!comment format=mdwn + username="andrew" + subject="comment 8" + date="2016-06-15T06:44:55Z" + content=""" +This has bit me one too many times, so here is a full implementation. There could be some dedup work to merge fileProperty and byteProperty, but I'd rather not break API with a trivial bug fix. + +<https://github.com/arcticwaters/propellor/commit/f5a921760ccabf0a3ebdda626c19ee6ecbe89629> +"""]] diff --git a/doc/todo/bytes_in_privData__63__/comment_9_7c87ab0fba0aa90e2b24b457851b63c4._comment b/doc/todo/bytes_in_privData__63__/comment_9_7c87ab0fba0aa90e2b24b457851b63c4._comment new file mode 100644 index 00000000..b904351a --- /dev/null +++ b/doc/todo/bytes_in_privData__63__/comment_9_7c87ab0fba0aa90e2b24b457851b63c4._comment @@ -0,0 +1,17 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 9""" + date="2016-06-17T01:33:05Z" + content=""" +Thank you, Andrew! + +Before I merge this, I want to clear up something that confuses me; +you characterized this as a bug that has bit you. How did the +pre-bytestring File.hasContentProtected exhibit buggy behavior? + +AFAICS, it already supported binary privdata, just in a suboptimal +way. + +(Also fileProperty and bytesProperty should indeed be deduped; +a second patch that merges them, even with an API change, would be ok.) +"""]] diff --git a/doc/todo/integrate_shell-monad/comment_1_202c24d0a757d5086f65721fc2779131._comment b/doc/todo/integrate_shell-monad/comment_1_202c24d0a757d5086f65721fc2779131._comment new file mode 100644 index 00000000..bfa5e3b1 --- /dev/null +++ b/doc/todo/integrate_shell-monad/comment_1_202c24d0a757d5086f65721fc2779131._comment @@ -0,0 +1,11 @@ +[[!comment format=mdwn + username="gueux" + subject="comment 1" + date="2016-06-13T17:31:37Z" + content=""" +How would you see the integration of shell-monad or turtle? + +Do you have a preference? + +I actually use turtle and it is great! It may be more complete than shell-monad which may be an advantage or a disadvantage... +"""]] diff --git a/doc/todo/integrate_shell-monad/comment_2_4e82a5994b4647b4483c92c7785ee905._comment b/doc/todo/integrate_shell-monad/comment_2_4e82a5994b4647b4483c92c7785ee905._comment new file mode 100644 index 00000000..0779c49f --- /dev/null +++ b/doc/todo/integrate_shell-monad/comment_2_4e82a5994b4647b4483c92c7785ee905._comment @@ -0,0 +1,39 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 2""" + date="2016-06-13T20:23:37Z" + content=""" +One easy way would be something like: + + shellMonadProperty :: Control.Monad.Shell.Script Result -> Property UnixLike + +But, I don't know if that would really be useful. The better use case for +shell-monad seems to be where things like `userScriptProperty` take a +`Script`, that is currently an alias for `String`. Since shell-monad can +generate a shell script, it would be easy to write: + + shellMonad :: Control.Monad.Shell.Script () -> Script + +Or, perhaps change userScriptProperty to accept either a stringy-Script or +a shell monad Script, via a type class. Then it could be used like this: + + userScriptProperty (User "joey") $ do + cmd "echo" "hello" + cmd "rm" "/home/joey/something" + +Turtle seems to not have its own monad but simply uses MonadIO. So seems +you can use Turtle in the implementation of propellor properties the same as +other IO actions. Which is great, it should be easy to use it if you want +to. Something like: + + import Turtle.Prelude + + myProperty :: Property UnixLike + myProperty = property "my property using turtle" $ liftIO $ do + echo "hello" + rm "/something" + return NoChange + +But I don't think turtle can generate shell scripts like used by +`userScriptProperty`. +"""]] diff --git a/doc/todo/integrate_shell-monad/comment_3_155d4af99bbbd8681a9924198aa7da73._comment b/doc/todo/integrate_shell-monad/comment_3_155d4af99bbbd8681a9924198aa7da73._comment new file mode 100644 index 00000000..48d25d7f --- /dev/null +++ b/doc/todo/integrate_shell-monad/comment_3_155d4af99bbbd8681a9924198aa7da73._comment @@ -0,0 +1,11 @@ +[[!comment format=mdwn + username="gueux" + subject="comment 3" + date="2016-06-14T10:56:04Z" + content=""" +I've posted a question on https://github.com/Gabriel439/Haskell-Turtle-Library/issues/157 + +Probably Gabriel will have a good idea for this :-). Maybe another solution would be to generate executables instead of shell scripts? + + +"""]] diff --git a/doc/todo/integrate_shell-monad/comment_4_4914d37a548e1a19733156fbd77142a6._comment b/doc/todo/integrate_shell-monad/comment_4_4914d37a548e1a19733156fbd77142a6._comment new file mode 100644 index 00000000..77f30917 --- /dev/null +++ b/doc/todo/integrate_shell-monad/comment_4_4914d37a548e1a19733156fbd77142a6._comment @@ -0,0 +1,20 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 4""" + date="2016-06-14T17:11:09Z" + content=""" +We already have /usr/local/bin/propellor executable, so the cron job or +whatever could be made to run it with a parameter that runs the turtle IO +action. (Or generally, any IO action.. Being able to run arbitrary haskell +IO code as a cron job would be great!) + +This would need some way to get a `UniqueId` for an IO action, that is +stable across runs of propellor, and a way to build up a` Map UniqueId (IO ())` of such +actions. The Info interface could be used to build up that Map. + +---- + +Some of the places I'd like to use shell-monad though are where propellor +is bootstrapping itself on a host and all it can easily run at that point +is shell script. +"""]] diff --git a/doc/todo/integrate_shell-monad/comment_5_315c81503d6aea67b2b762ff3e435445._comment b/doc/todo/integrate_shell-monad/comment_5_315c81503d6aea67b2b762ff3e435445._comment new file mode 100644 index 00000000..9c185bd2 --- /dev/null +++ b/doc/todo/integrate_shell-monad/comment_5_315c81503d6aea67b2b762ff3e435445._comment @@ -0,0 +1,9 @@ +[[!comment format=mdwn + username="gueux" + subject="comment 5" + date="2016-06-15T10:41:53Z" + content=""" +That would be over cool! :-) + +I don't see how to create these UniqueIds, though. I'm not sure I could help a lot on this one (at least before we have a first prototype)... +"""]] diff --git a/doc/todo/integrate_shell-monad/comment_6_d0328983a68958a914bd9fc9fe5a3abe._comment b/doc/todo/integrate_shell-monad/comment_6_d0328983a68958a914bd9fc9fe5a3abe._comment new file mode 100644 index 00000000..8ba13e99 --- /dev/null +++ b/doc/todo/integrate_shell-monad/comment_6_d0328983a68958a914bd9fc9fe5a3abe._comment @@ -0,0 +1,13 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2016-06-16T21:04:55Z" + content=""" +Could use a tuple of a Data.Unique for the current build of propellor, +and a propellor build ID (eg, git rev that was built). + +That would make sure that propellor runs the correct IO action. +But, when propellor is updated, any cron jobs etc that try to run +with the old UniqueId would fail. Unless the old propellor binary +could be cached away and used as a fallback, I suppose.. +"""]] diff --git a/doc/todo/merge_request:_Firejail.hs.mdwn b/doc/todo/merge_request:_Firejail.hs.mdwn new file mode 100644 index 00000000..b593c5b4 --- /dev/null +++ b/doc/todo/merge_request:_Firejail.hs.mdwn @@ -0,0 +1,16 @@ +Please consider merging branch `firejail` of repo `https://git.spwhitton.name/propellor`. + +Changes: + +- Add `applytoList` property combinator +- Add `Propellor.Property.Firejail` module + +Comments: + +- I'm not sure whether Joey or I originally wrote `applyToList`; it's been in my config.hs for a while +- `Firejail.jailed` accepts a list of executables (and `Firejail.jailed'` is not exported) because as with `Apt.installed`, I think most users will want to jail more than one program. For example `Firejail.jailed ["firefox", "evince"]`. +- I made the build clean on GHC 7.10 but there is a warning on 7.6 that `Prelude` does not export `Foldable`. I don't know how to fix this while maintaining the 7.10 clean build, and it seems to me that having the 7.10 build be clean is more important than having the 7.6 build be clean. + +--spwhitton + +> [[done]], thanks! (I fixed the warning.) --[[Joey]] diff --git a/doc/todo/merge_request:_Sbuild.keypairInsecurelyGenerated.mdwn b/doc/todo/merge_request:_Sbuild.keypairInsecurelyGenerated.mdwn new file mode 100644 index 00000000..7a22e976 --- /dev/null +++ b/doc/todo/merge_request:_Sbuild.keypairInsecurelyGenerated.mdwn @@ -0,0 +1,5 @@ +Please consider merging branch `insecure-sbuild-keygen` from repo `https://git.spwhitton.name/propellor`. + +- Adds `Sbuild.keyringInsecurelyGenerated` which is useful on throwaway build VMs + +> [[merged|done]] --[[Joey]] diff --git a/doc/todo/merge_request:_changes_to_Reboot.hs.mdwn b/doc/todo/merge_request:_changes_to_Reboot.hs.mdwn new file mode 100644 index 00000000..a6dec37b --- /dev/null +++ b/doc/todo/merge_request:_changes_to_Reboot.hs.mdwn @@ -0,0 +1,7 @@ +Please consider merging branch `reboot` of repo `https://git.spwhitton.name/propellor` + +- Factor out reboot code in `Propellor.Property.SiteSpecific.DigitalOcean` into `Propellor.Property.Reboot` +- Add `Propellor.Property.Reboot.toKernelNewerThan`. +- Add `Propellor.Property.SiteSpecific.Exoscale` + +> [[done]]; all changes merged --[[Joey]] diff --git a/doc/todo/merge_request:_changes_to_Reboot.hs/comment_10_d353b81063c5343b452f8c6e0fce5586._comment b/doc/todo/merge_request:_changes_to_Reboot.hs/comment_10_d353b81063c5343b452f8c6e0fce5586._comment new file mode 100644 index 00000000..04b02aea --- /dev/null +++ b/doc/todo/merge_request:_changes_to_Reboot.hs/comment_10_d353b81063c5343b452f8c6e0fce5586._comment @@ -0,0 +1,19 @@ +[[!comment format=mdwn + username="spwhitton" + subject="reboot branch merges cleanly" + date="2016-06-21T09:20:40Z" + content=""" +Ah, very nice :) + +I reverted my GHC 6 commits and the merge with your master branch is now clean. + +Some changelog text you can use: + +- New info property Schroot.useOverlays to indicate whether you want schroots set up by propellor to use the Linux kernel's OverlayFS. +- Schroot.overlaysInTmpfs sets Schroot.useOverlays info property. +- If you have indicated that you want schroots to use OverlayFS and the current kernel does not support it, Sbuild.built will attempt to reboot into a kernel that does, or fail if it can't find one. +- Sbuild.built will no longer add duplicate `aliases=UNRELEASED,sid...` lines to more than one schroot config. It will not remove any such lines that the previous version of propellor added, though. +- Sbuild.keypairGenerated works around Debian bug #792100 by creating the directory /root/.gnupg in advance. +- Improved Sbuild module haddock. +- Ccache.hasCache now sets the setgid bit on the cache directory, as ccache requires. +"""]] diff --git a/doc/todo/merge_request:_changes_to_Reboot.hs/comment_1_766444e44fe64a66d57596b1ea9d416d._comment b/doc/todo/merge_request:_changes_to_Reboot.hs/comment_1_766444e44fe64a66d57596b1ea9d416d._comment new file mode 100644 index 00000000..a1a72054 --- /dev/null +++ b/doc/todo/merge_request:_changes_to_Reboot.hs/comment_1_766444e44fe64a66d57596b1ea9d416d._comment @@ -0,0 +1,26 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2016-06-13T22:59:56Z" + content=""" +While I've merged this, I am unsure if Reboot.toKernelNewerThan +should stop propellor from ensuring any subsequent properties. + +That works if we have: + + & toKernelNewerThan foo + & Sbuild.built + +But not if the two properties are flipped. So, doesn't it follow +that Sbuild.built is a buggy property? + +If Sbuild.built needs a particular kernel version running, +it could requires toKernelNewerThan. Then any use of Sbuild.built +would make sure the right kernel is running, rebooting into it if +necessary. + +And, if toKernelNewerThan failed due to the right kernel version not being +installed, Sbuild.built would be prevented from running. In which case, it +would be fine for propellor to continue on with ensuring other unrelated +properties. +"""]] diff --git a/doc/todo/merge_request:_changes_to_Reboot.hs/comment_2_736788cdf9afc98da3dfd5a120e7978b._comment b/doc/todo/merge_request:_changes_to_Reboot.hs/comment_2_736788cdf9afc98da3dfd5a120e7978b._comment new file mode 100644 index 00000000..fa1048a3 --- /dev/null +++ b/doc/todo/merge_request:_changes_to_Reboot.hs/comment_2_736788cdf9afc98da3dfd5a120e7978b._comment @@ -0,0 +1,11 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 2""" + date="2016-06-13T23:13:28Z" + content=""" +readVersionMaybe was buggy; for "4.1.2" it yielded +`Just (Version {versionBranch = [4], versionTags = []})` +which is lacking anything but the major. + +I fixed it by taking the maximum of the list of all possible parses. +"""]] diff --git a/doc/todo/merge_request:_changes_to_Reboot.hs/comment_3_4466bc58fd3e69938c184c817ddbb3e6._comment b/doc/todo/merge_request:_changes_to_Reboot.hs/comment_3_4466bc58fd3e69938c184c817ddbb3e6._comment new file mode 100644 index 00000000..4fa14683 --- /dev/null +++ b/doc/todo/merge_request:_changes_to_Reboot.hs/comment_3_4466bc58fd3e69938c184c817ddbb3e6._comment @@ -0,0 +1,23 @@ +[[!comment format=mdwn + username="spwhitton" + subject="comment 3" + date="2016-06-14T03:16:18Z" + content=""" +Thanks for taking a look at my branch, and especially for fixing my inadequately-tested `readVersionMaybe`. + +`Sbuild.built` does not *require* a particular version of the kernel. It is just that the file that it generates in `/etc/schroot/chroot.d` can vary depending on the kernel version running at the time that `Sbuild.built` is first ensured. In particular, if the running kernel does not support overlayfs (as jessie's kernel doesn't), the line `union-type=overlay` will be omitted from the file in `/etc/schroot/chroot.d`. This renders `Schroot.overlaysInTmpfs` useless. + +I think it should be up to the user to apply a property like + + & Sbuild.built foo `requires` Reboot.toKernelNewerThan bar + +to individual hosts, because it depends on whether they actually care about using an overlay chroot. Perhaps on an old machine they don't intend to use overlays. In my config, I do something like this: + + & osDebian Testing \"i386\" + & Apt.stdSourcesList `onChange` (Apt.upgraded `before` Apt.cacheCleaned `before` Reboot.toKernelNewerThan \"4\") + & Sbuilt.builtFor ... + +The idea is that if I reinstall my machine from a jessie installation CD, propellor will upgrade to testing and boot to the new kernel before it builds the chroot, so I get the `union-type=overlay` line in my config. + +I could prepare a patch to add this information to the haddock of Sbuild.hs? +"""]] diff --git a/doc/todo/merge_request:_changes_to_Reboot.hs/comment_3_6460a7f85249bd8b9a83f2e145a25d62._comment b/doc/todo/merge_request:_changes_to_Reboot.hs/comment_3_6460a7f85249bd8b9a83f2e145a25d62._comment new file mode 100644 index 00000000..3d842ac3 --- /dev/null +++ b/doc/todo/merge_request:_changes_to_Reboot.hs/comment_3_6460a7f85249bd8b9a83f2e145a25d62._comment @@ -0,0 +1,29 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 3""" + date="2016-06-14T04:04:50Z" + content=""" +It might also be worth making the Sbuild properties know +whether overlays are desired. Then they could make sure to set up the +config file with the needed lines, even if the wrong kernel is running. + +I assume schroot fails to work in that configuration, so the properties +for it would fail and then the user would notice they need to add a +property to get a new enough kernel version.. + +It could be specified with another parameter to the Sbuild properties. +Or, you could add a pure Info property `useOverlays` and have the +Sbuild properties check if the Info has that set. This would also +let Schroot.overlaysInTmpfs require useOverlays and auto-enable them. + +Most of the implementation of that: + + useOverlays :: Property (HasInfo + UnixLike) + useOverlays = pureInfoProperty "use schroot overlays" (InfoVal UseOverlays) + + data UseOverlays = UseOverlays + + useOverlays :: Propellor Bool + useOverlays = isJust . fromInfoVal + <$> (askInfo :: Propellor (InfoVal UseOverlays)) +"""]] diff --git a/doc/todo/merge_request:_changes_to_Reboot.hs/comment_4_b39af83b7f793013a7d63f340ee8de6d._comment b/doc/todo/merge_request:_changes_to_Reboot.hs/comment_4_b39af83b7f793013a7d63f340ee8de6d._comment new file mode 100644 index 00000000..148f8efb --- /dev/null +++ b/doc/todo/merge_request:_changes_to_Reboot.hs/comment_4_b39af83b7f793013a7d63f340ee8de6d._comment @@ -0,0 +1,29 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 4""" + date="2016-06-14T03:41:53Z" + content=""" +When `requires` is used as in your first example, Reboot.toKernelNewerThan +does not need to throw an exception. It could just return FailedChange +and then Sbuild.builtFor wouldn't get run. + +Your second example, as written is actually buggy. If Apt.upgraded +fails for some reason, then Reboot.toKernelNewerThan never gets run, +and then Sbuilt.builtFor can still run with the wrong kernel version. + +The second example could instead be written thus: + + & osDebian Testing "i386" + & combineProperties "sbuild setup" + ( props + & Apt.stdSourcesList `onChange` (Apt.upgraded `before` Apt.cacheCleaned `before` Reboot.toKernelNewerThan "4") + & Sbuilt.builtFor ... + ) + +Then if any part of the upgrade fails the following properties don't run +thanks to `combineProperties`. And here too Reboot.toKernelNewerThan does +not need to thow an exception. + +So, I'm not seeing any good use cases for it throwing an exception in these +examples. +"""]] diff --git a/doc/todo/merge_request:_changes_to_Reboot.hs/comment_6_c2b043ecea1524e4d5743196fc0d191c._comment b/doc/todo/merge_request:_changes_to_Reboot.hs/comment_6_c2b043ecea1524e4d5743196fc0d191c._comment new file mode 100644 index 00000000..05ca43ae --- /dev/null +++ b/doc/todo/merge_request:_changes_to_Reboot.hs/comment_6_c2b043ecea1524e4d5743196fc0d191c._comment @@ -0,0 +1,13 @@ +[[!comment format=mdwn + username="spwhitton" + subject="comment 6" + date="2016-06-16T06:30:04Z" + content=""" +I like the idea of a `useOverlays` info property. It is better, and more in the spirit of propellor, to have the choice explicit, rather than implicitly relying on the behaviour of certain shell commands in certain conditions (relying on sbuild-createchroot(1) to create the config file in /etc/schroot/chroot.d is the thing I like least about Sbuild.hs, though it's necessary for achieving the goal of having a totally standard Debian sbuild setup). + +Before I implement this, I have a couple of questions: + +1. In the case where `Reboot.toKernelNewerThan` finds a satisfactory kernel to reboot to, what do you think about the choice of rebooting immediately or at the end of the current propellor run? If every property that needs the newer kernel `requires` it, it would mean that other properties that don't need the newer kernel get ensured sooner. Not sure whether this is actually an advantage, but it might encourage using `requires` instead of relying on implicit ordering. + +2. You suggest relying on schroot(1) and sbuild-createchroot(1) failing if `union-type=overlay` is present in the config file but the kernel doesn't support overlays. I'd prefer to go further and have the sbuild properties conditionally `requires` `Reboot.toKernelNewerThan` if the info property is set. That way, we can be confident that we'll never get an inconsistent state out of the sbuild properties. Does this sound sensible? +"""]] diff --git a/doc/todo/merge_request:_changes_to_Reboot.hs/comment_7_c556c4905ff4840e148bdd51a8dc1e53._comment b/doc/todo/merge_request:_changes_to_Reboot.hs/comment_7_c556c4905ff4840e148bdd51a8dc1e53._comment new file mode 100644 index 00000000..5898e0a5 --- /dev/null +++ b/doc/todo/merge_request:_changes_to_Reboot.hs/comment_7_c556c4905ff4840e148bdd51a8dc1e53._comment @@ -0,0 +1,13 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 7""" + date="2016-06-17T01:21:08Z" + content=""" +If Reboot.toKernelNewerThan doesn't reboot right away, then +when a property `requires` it, the property's code is not +guaranteed to run under the new kernel. +So, an immediate reboot seems to make sense. + +Making the sbuild properties automatically include +Reboot.toKernelNewerThan seems reasonable. +"""]] diff --git a/doc/todo/merge_request:_changes_to_Reboot.hs/comment_8_b4b2bd5741fbc7759d85d826dc1f9f7f._comment b/doc/todo/merge_request:_changes_to_Reboot.hs/comment_8_b4b2bd5741fbc7759d85d826dc1f9f7f._comment new file mode 100644 index 00000000..36556924 --- /dev/null +++ b/doc/todo/merge_request:_changes_to_Reboot.hs/comment_8_b4b2bd5741fbc7759d85d826dc1f9f7f._comment @@ -0,0 +1,11 @@ +[[!comment format=mdwn + username="spwhitton" + subject="comment 8" + date="2016-06-19T12:31:40Z" + content=""" +Please consider merging my new `reboot` branch which addresses the discussion we've had. + +I also included some other improvements to `Sbuild.hs`, a bug fix in `Ccache.hs` and some GHC 7.6 compatibility fixes. With one exception,[1] I think that the changes are sufficiently self-explanatory that `git diff master..spwhitton/reboot` will be enough for you to review the branch. If not, I will happily split the commits into several branches. + +[1] I changed the haddocks on some functions in Sbuild.hs so that they will be properly hyperlinked, and did some other documentation rearrangements. +"""]] diff --git a/doc/todo/merge_request:_changes_to_Reboot.hs/comment_9_233140189ee7ffebad687db76dfe2258._comment b/doc/todo/merge_request:_changes_to_Reboot.hs/comment_9_233140189ee7ffebad687db76dfe2258._comment new file mode 100644 index 00000000..1afbef11 --- /dev/null +++ b/doc/todo/merge_request:_changes_to_Reboot.hs/comment_9_233140189ee7ffebad687db76dfe2258._comment @@ -0,0 +1,22 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 9""" + date="2016-06-20T17:56:25Z" + content=""" +Félix sent some patches today fixing compiling Propellor.Exception on old +ghc, which overlap with part of your patch. You addressed the same problem +in different ways. Since I already merged his (more extensive I think) +fixes for that, your branch will need to be updated. + +The only thing I caught during review is that the documentation for +useOverlays says that the property has to be added before +Sbuild.builtFor, but actually info-setting properties +set info before any properties run, so can safely appear after properties +that use the info they set! + +(I'm not sure if overlaysInTmpfs can safely come after +Sbuild.builtFor, but if it cannot it's not due to setting useOverlays.) + +Also, it would be good to have some lines to add to the changelog +about the sbuild changes. +"""]] |