| Age | Commit message (Collapse) | Author |
|---|
|
so that gpg can do password prompting despite being connected by pipes to
propellor (or git).
|
|
* Added Rsync.installed property.
* Added DiskImage.vmdkBuilt property which is useful for booting
a disk image in VirtualBox.
|
|
|
|
|
|
|
|
|
|
Remove --build which is no longer present.
Order the list of options the same.
Document --rm-key in man page.
|
|
encoding-related crashes in eg, Propellor.Property.File.
|
|
Paths_propellor prevents use of the module out of propellor's tree.
Failure looked like:
/home/lukas/.propellor/.cabal-sandbox/lib/x86_64-linux-ghc-7.10.3/propellor-3.0.
1-0JokOieT9kY9W7enKSzFHh/libHSpropellor-3.0.1-0JokOieT9kY9W7enKSzFHh.a(DotDir.o)
:(.text+0x591): undefined reference to `propezu0JokOieT9kY9W7enKSzzFHh_Pathszupropellor_getLibDir_closure'
This module is only needed for the wrapper program anyway, which handles --init.
This does mean that ./propellor --init in propellor's tree will fail even
though the help shows --init as an option.
|
|
|
|
|
|
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.
Fixes http://propellor.branchable.com/todo/problem_with_spin_after_new_dependencies_added/
|
|
Got lost in recent changes and broke the cron job.
|
|
- Propellor bootstrapping
- Basic pkg
- Basic ZFS datasets and properties
- Simple Poudriere configuration (regular and ZFS)
- Poudriere jail creation
FIXME:
- Cron.hs: runPropellor needs the System, but hasn't yet gotten it.
Reorganizing:
- Remove FreeBSD.Process
- Move ZFS up to Property
- Add Info for Pkg.update/Pkg.upgrade
- Move FreeBSD.md to doc so it'll show up automatically.
- Merge the FreeBSD config with the other sample config.
- Use Info to check Pkg updated/upgraded and Poudriere configured.
- Warnings clean-up, move ZFS types to Propellor.Types.
- Maintainer and license statements.
|
|
|
|
When spinning a remote host, we do want to rebuild propellor on it,
and this use of --continue that did a rebuild was different from all the
other uses of --continue that avoided a rebuild.
This fixes a build loop involving that special case. When --continue
SimpleRun ran a rebuild, it re-execed propellor with --continue SimpleRun,
and so would rebuild again, and re-exec again if the binary kept changing.
Backwards compatability should be ok; old versions of propellor,
when run with --serialized SimpleRun by the new version, do a buildFirst,
followed by another (redundant) buildFirst, and then run. The one redundant
buildFirst is not a problem in the upgrade scenario.
(Unfortunately, I can't rename SimpleRun to something nicer despite only
spin using it; backwards compatability does prevent that.)
|
|
|
|
|
|
|
|
There may not be changes from the origin repo, so fetchFirst wouldn't
build, but changes are pushed by spin, so it always needs to build.
|
|
buildFirst re-runs propellor with --continue, which is supposed to
make defaultMain bypass subsequent calls to buildFirst. But, use of a Bool
to do that caused the code to be unclear, and some of the cases lost track
of that.
--continue SimpleRun would buildFirst, and if the binary changed, would
--continue SimpleRun. This could loop repatedly, on systems such as FreeBSD
where building re-links the binary even when there are no changes. As
discussed in github pull #11
Fixed by introducing a CanRebuild data type, which buildFirst and updateFirst
require in order to do any work makes it more clear what's going on.
It's not a type-level proof that propellor won't rebuild repeatedly,
but gets closer to one.
(Only remaining way such a bug could slip in is if the CanRebuild
value was reused in a call to buildFirst and also inside the IO action
passed to it.)
There were some other weirdnesses around repeated builds. In particular,
Run as non-root did an updateFirst, followed by a buildFirst. I think this
redundant build was an accident, and have removed it.
|
|
|
|
|
|
Force console mode when --spin calls SimpleRun
|
|
|
|
|
|
Controlling host inherits the privdata for the host it spins, and sends it
along to that host.
|
|
Much less invasive than the other implementation.
|
|
|
|
controller of other hosts.
The hard part of this is avoiding loops of controllers. To make that work,
a ControllerChain is passed to the host that's spun, and is added to the
Info of the host being spun, where the controller property can check it
to detect an avoid a loop.
That needed an expansion of the CmdLine data type. I made the new
ControlledRun only be used when there is a ControllerChain provided.
This avoids breaking backwards compatability with old propellor
deployments, as --spin still uses SimpleRun.
Note: Making an old propellor deployment be controlled by a controller
won't work until it's been updated to this commit, so it knows about
the ControlledRun parameter.
(Untested)
|
|
|
|
|
|
|
|
address.
|
|
Propellor.Property.Cmd, so they are available for use in constricting your own Properties when using propellor as a library.
Several imports of Utility.SafeCommand now redundant.
|
|
* Make propellor resistent to changes to shared libraries, such as libffi,
which might render the propellor binary unable to run. This is dealt with
by checking the binary both when running propellor on a remote host,
and by Cron.runPropellor. If the binary doesn't work, it will be rebuilt.
* Note that since a new switch had to be added to allow testing the binary,
upgrading to this version will cause a rebuild from scratch of propellor.
|
|
|
|
|
|
|
|
|
|
Note that if it fails to spin a host, it will stop. I think this is better
than continuing to the next, because there might be a reason to spin hosts
in some specific order (ie, update dns first and then use it).
|
|
|
|
When propellor is deployed by uploading the binary, there's no git repo, so
each spin needs to re-upload it to get any config changes. This should be
rare since this is only intended to be used when taking over a host and
getting it properly set up from source, but it still needs to be supported.
|
|
full hostname.
|
|
|
|
|
|
|
|
|
|
|
|
|
