My only beef here is the naming of these methods--feels confusing. The docstring does clarify, but at a glance, the names would make me think of disabling or enabling a service *provided* by the provisioned package at *launch* time (install this package but configure it to be disabled when someone launches my resultant AMI)

Maybe something like

```python
# aminator/plugins/provisioner/linux.py
@abc.abstractmethod
def _activate_provisioning_service_block(self):
    """ keep the package manager from firing up daemons in post install """

@abc.abstractmethod
def _deactivate_provisioning_service_block(self)
    """ undo whatever was done to keep the package manager from firing up daemons in post install """

def _configure_chroot(self):
    if config.get('block_services_while_provisioning', False):
        log.debug('Blocking services from starting during provisioning')
        if not self._activate_provisioning_service_block():
            log.critical('Failure configuring provision-time service block')
            return False
# snipped for brevity
def _teardown_chroot(self):
    if config.get('block_services_while_provisioning', False):
        log.debug('Deactivating provision-time service block')
        if not self._deactivate_provisioning_service():
            log.critical('Failure deactivating provision-time service block')
            return False
```

apt.py can stay the same, save for a change to the config key and the method name
for yum.py, I would simply take rewire and short circuit, move their logic into _deactivate/_activate_provisioning_service_block (they're going to call rewire/short circuit functions in util/linux.py--I don't think adding a layer of indirection with an extra function call buys us much)