peterkeen / dokuen

A personal PaaS for mac and linux

Hi there 👋

• Blog
• Mastodon

dokuen's Issues

Improve logging

Logs are getting swallowed from start_app. Need to capture and redirect them.

Error at dokuen create

So, I tried installing it on an Ubuntu-server 12.04 LTS. Everything went fine, except on dokuen create --aplication=name

I followed standard installation procedure, as detailed in the README.

Please find the full command and error log below.

$ ssh git@ip_address dokuen create --application=test
[email protected]'s password:
/var/lib/gems/1.8/gems/dokuen-0.0.11/lib/dokuen/application.rb:57:in `create': undefined method `dokuen_dir' for nil:NilClass (NoMethodError)
        from /var/lib/gems/1.8/gems/dokuen-0.0.11/lib/dokuen/cli.rb:44:in `create'
        from /var/lib/gems/1.8/gems/thor-0.15.2/lib/thor/task.rb:27:in `send'
        from /var/lib/gems/1.8/gems/thor-0.15.2/lib/thor/task.rb:27:in `run'
        from /var/lib/gems/1.8/gems/thor-0.15.2/lib/thor/invocation.rb:120:in `invoke_task'
        from /var/lib/gems/1.8/gems/thor-0.15.2/lib/thor.rb:275:in `dispatch'
        from /var/lib/gems/1.8/gems/thor-0.15.2/lib/thor/base.rb:408:in `start'
        from /var/lib/gems/1.8/gems/dokuen-0.0.11/bin/dokuen:15
        from /usr/local/bin/dokuen:19:in `load'
        from /usr/local/bin/dokuen:19
$ 

I am at your disposal for any further test or information.

Remove hard coded username

The launchdaemon config has a hardcoded username. Make setup ask for this name and write to _common. Let it be overridden.

Update mason dependency and cut a new release

ddollar/mason recently went to 0.1.0 with changes needed. Update the gemfile and cut a new release and remove that stuff from the README.

Remove gitolite dependency

Gitolite doesn't add anything dokuen can't do itself. The only thing it does is manage the repos and the hooks and it kind of gets in the way, since we already have a create command.

This needs to do the following:

• Manage SSH public keys and access to repos (owners/collaborators)
• Rebuild authorized_keys when changes to ssh keys happen
• Manage repositories. Within the dokuen directory, there will be a repositories directory.
• Act as the git server

Custom SSL certificates

Allow for app-specific ssl certificates. I don't know how that plays with CNAMES.

Add-on support

Add-ons would be cool. The basic idea would be to register something with Dokuen that looks like a buildpack, but contains "provision" and "destroy" scripts.

run_command doesn't work sometimes

If run_command contains quotes of any variety, ssh aborts with FATAL: suspicious characters loitering about '<command>'. I'm not really sure what this is about.

Version config variables

Config vars should be versioned just like code releases. This probably means the env dir gets timestamped directories just like the release dir.

• Timestamped env dirs with unchanged variables copied forward
• A new app-level directory named versions
• A "version" consists of a sequentially numbered directory in the versions directory, which then contains two symlinks. app points at the timestamped code release in releases, env points at the timestamped env in env. It also contains one real directory named procs, which is where pidfiles live (moved from the code release directory)
• The current symlink points at the current version. The previous symlink can probably go away.
• Add a set of version commands

Load the environment each time subprocess restarts

In the wrapper, instead of calling load_env immediately after daemonize!, call it at the top of run_loop. This way, when the subprocess restarts it gets a fresh copy of the env.

Unknown sub-command

Hi, I've been having some real trouble getting dokuen working - I've tried a couple of times and I'm getting stuck each time now on

$ ssh git@myserver dokuen create --application=<my application>
FATAL: unknown gitolite sub-command

I'm hoping someone will have some advice - I've tried everything I can think of! (see below for my steps so far)

Host System: Mac OS X 10.8 (Mountain Lion)

1. Install the OS X gcc installer
2. Install RVM multiuser edition (installs to /usr/local/rvm) so I have a ruby for my usual user account, and dokuen for the git user.
3. Create a git user (using the OS X users GUI)
4. Add my own username and the git username to the user group rvm
5. Install ruby 1.9.3-p194 (I've had problems with rvm's version of the new stable ruby, p286) rvm install 1.9.3-p194
6. Log into the shell as the git user: $ login git
7. Install gitolite: $ cd ~; git clone git://github.com/sitaramc/gitolite
8. Follow the rest of the gitolite instructions (as per the readme)
9. Install homebrew
10. Install nginx (I think there's a bunch of other libraries you need to install this way, but I can't remember what they were, it's all as simple as:) brew install nginx
11. Install dokuen gem install dokuen
12. Follow the instructions in the dokuen caveat:
13. Add 'dokuen' => 1, to the COMMANDS array in /Users/git/.gitolite.rc
14. Some quirk on Mac OS X means you need to add information about the git exec path to the .gitolite.rc as well, I added the following line to the line before # ------------------ at the end of the file: $ENV{GIT_EXEC_PATH} = "/usr/libexec/git-core";
15. Its not mentioned anywhere (that I found), but for the git pre-hooks to work with dokuen you need to change the line in .gitolite.rc which starts GIT_CONFIG_KEYS so that it allows the pre-hook: GIT_CONFIG_KEYS => 'hooks.pre' (or you could just put '*', if you're feeling permissive)
16. I also needed to make sure my /Users/git/.profile included a line to add some bits to my PATH: PATH=$PATH:$HOME/bin:/usr/local/bin
17. Now, cloning the gitolite admin repository from my second computer is pretty simple, but it kept asking me for a password (which is obviously incorrect, it should be using the key pair), in the end I had to add a line to my client computer's ~/.ssh/config to allow access using a specific key (see below)
18. So now I can clone the admin repo: git clone mygit:gitolite-admin.git
19. Now comes the part I'm stuck at. I move to my web application directory and try to start dokuen: $ cd ~/Projects/mywebapp; ssh mygit dokuen create --application=mywebapp
    20 scrabble for information
20. It looks as though dokuen isn't allowed as a sub-command: client-computer$ ssh mygit help doesn't list dokuen.
21. Check to see that the dokuen binary exists in the right place (one install it wasn't there): ls -la /Users/git/gitolite/src/commands/ | grep dokuen - yup, it does.
22. It looks like the dokuen executable was owned by root, not by git, so I changed that sudo chown git /Users/git/gitolite/src/commands/dokuen. No change.
23. Really stuck. Post an issue on github (sorry!)

I really hope you can help out, this seems like it should be so easy!

Let me know if there's anything else I can help with.

Thanks,

JP

(The line in my ~/.ssh/config)

Host <hostname, eg 'mygit'>
  user git
  Hostname myserver
  IdentityFile "/Users/me/.ssh/my_key.pub"
  IdentitiesOnly yes

Create a system user for each application at app-create-time

Applications should have some amount of separation from each other and other parts of the host system. Create a user for each application automatically. This should be configurable, in so far as you can turn it on and off and also configure the username pattern.

Add linux support

This should just amount to writing out a different thing instead of a LaunchDaemon. On ubuntu, an upstart. On other machines, an init.d style script probably.

Optional http to https forwarding

If FORWARD_HTTP and USE_SSL are both set, set up an nginx listener on port 80 that redirects to https.

Allow custom domains

Add an env var ADDITIONAL_DOMAINS that contains a comma separated list of domain names to attach to the server config in nginx.

Reduce or eliminate dependency on Mason

Mason is great but it does some weird things with buildpacks. Specifically, it clones buildpacks into $HOME/.mason, which is inconvenient wrt permissions. Ideally we could specify where to find and clone buildpacks and make that directory sticky group writable, but failing that we may need to incorporate the things that Mason does directly into Dokuen.

Shutdown command does not work

It fails to shut down the sub processes because it assumes the pidfile is just an integer instead of being a YAML file. Also, add a generalized "shutdown" command that shuts down everything. Basically the opposite of "boot". Also, a "restart" command would be nice.

Make stop signal sent by wrapper configurable

For some reason rails processes don't react to SIGTERM. Make this configurable.

Implement access restrictions via gitolite

The only people who should be able to push to a repo or run commands are writers for that repo. It should reject everyone else. Gitolite provides facilites for this kind of access control. See Easy.pm

Also apps should either run as that user or an app-specific user. Look into creating new users at app creation time.

Improve README

Write a section that describes how dokuen does what it does.

Isolate sudo-able commands into their own scripts

Sudo access is way too broad right now, since the git user can basically run anything as a sudo command via dokuen run_command.

Isolate the two things that need sudo into their own scripts:

• install_launchdaemon
• restart_nginx

This is basically what I had in the rough scripts.