diff options
Diffstat (limited to 'doc/todo')
19 files changed, 306 insertions, 0 deletions
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_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_1_f42f2893433c312821d8d47f84cb5c43._comment b/doc/todo/integrate_shell-monad/comment_6_d0328983a68958a914bd9fc9fe5a3abe/comment_1_f42f2893433c312821d8d47f84cb5c43._comment new file mode 100644 index 00000000..8ba13e99 --- /dev/null +++ b/doc/todo/integrate_shell-monad/comment_6_d0328983a68958a914bd9fc9fe5a3abe/comment_1_f42f2893433c312821d8d47f84cb5c43._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:_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..a18b21e5 --- /dev/null +++ b/doc/todo/merge_request:_changes_to_Reboot.hs.mdwn @@ -0,0 +1,5 @@ +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` 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. +"""]] |