Comment 11 for bug 906176

Hi shazzner. This is almost ready for promulgation. The only blocker is that the 'provides' listed in the metadata.yaml do not actually provide anything. At the very least, the website/http relation needs to have a 'website-relation-joined' hook that does

relation-set hostname=`unit-get private-address` port=80

The server side is less important since I don't see any 'requires' in the charm store for gitolite.

Fix those relations so they perform some function, or remove them from metadata.yaml.

Another blocker, you have a predictable file creation in /tmp, which is a security problem since a user could create a symlink to a file which they can then cause you to overwrite. Its super minor, but a well known problem and could cause issues later:

KEY_NAME=`config-get pub-key-name`
KEY_FILE="/tmp/$KEY_NAME.pub"

juju-log "Created: $KEY_FILE"
PUB_KEY=`config-get pub-key`
echo "$PUB_KEY" >> "$KEY_FILE"

This might be ok since its only during install, but it would be MUCH better and simple to use mktemp to create a random filename:

KEY_FILE=`mktemp /tmp/$KEY_NAME.pub.XXXXXXXX`

Some other minors (fix these at your leisure, they are not blockers for the charm store):

* indent the gitweb sed's at the end of install

* consider moving almost all of the install bits that use config-get to a config-changed hook. This will allow the service to be changed after initial deploy, and shouldn't require any logic changes.

* Perhaps also consider locking SSH down by disabling password logins. Since you'll be exposing port 22.. its important to make sure the brute forcers never succeed.