As we changed the way we query for installed packages with dpkg, the
error that it reports when the package is installed is showing up on the
logs.
Instead we suppress the error message to prevent the following messages:
```
tools >> No packages found matching git-svn. Installing...
tools >> Running "apt-get install -y git-svn"
Package `ack-grep' is not installed and no info is available.
Use dpkg --info (= dpkg-deb --info) to examine archive files,
and dpkg --contents (= dpkg-deb --contents) to list their contents.
```
Instead of relying only on the exit code of dpkg query, we check that
the status is installed for sure.
This prevents situations where the package was not properly installed,
and has a status like "install ok not-installed".
kickstart will check if the ppa has already been added and only update
the package cache the first time it is added. Further updates must be
handled by hand.
It also installs the required packages to manage the ppa over command
line if it is not present yet.
To have some interactions on the script we need to allocate a tty. This
adds a pseudo-tty to the ssh session.
This enables `read -s` on deployment scripts.
`sudo -S` reads the password from stdin. The way it was it was executing
the deploy script with the password as the stdin of the pipe.
Now, when password is passed as an argument we aquire a sudo session
executing a command that always work and then prefixing the installation
with sudo.
Previously, because we were piping the compiled script blob over ssh to
decompress over there without creating an intermediated bundled file, we
were allocating the stdin of the ssh session to have the read from the
pipe.
This blocked the allocation of the /dev/tty over the session and
prevented users to interact with the script. We would like some of the
interactions to work, like prompting for a confirmation or typing a
password.
To fix this, the deployment process was split in two steps. The first
step still receives the bundled file over a pipe, decompresses it on a
temprary folder, and outputs the location of the deployment folder.
We grab this output to feed on the second step, which has a script to go
to the deployment folder and start the execution.
Now, roles can make use of read, as well as sudo with password.
