Upgrade path from git #108

New issue

Open

opened 2018-11-26 08:37:36 +00:00 by giplt · 3 comments

giplt commented

2018-11-26 08:37:36 +00:00

(Migrated from github.com)

Implement an admin command in settings to upgrade a hypha instance by pulling the latest commit from a branch in git:

specify a git\branch resource in settings
detect and show if new version is available
implement button and action to upgrade

Implement an admin command in settings to upgrade a hypha instance by pulling the latest commit from a branch in git: - specify a git\branch resource in settings - detect and show if new version is available - implement button and action to upgrade

matthijskooijman commented

2018-11-26 17:08:12 +00:00

(Migrated from github.com)

This looks tricky to me, since it will only work in controlled cirumstances. In particular:

PHP must have write access to the entire Hypha directory (which is not always a good idea, but is common in practice).
The correct branch must be checked out, possibly with an upstream branch also configured etc, and a fast forward must be possible. Limiting to just the master branch might be ok here.
There must not be any uncommitted changes (which mean we need to do something with themes/CSS, as editing hypha.css/hypha.html through the webinterface now changes git-tracked files, see #49).
Git must be available on the commandline (unless we're going to include some PHP implementation of git, but that seems overkill to me).

It does seem that each of these things can be tested from the commandline, so it might be feasible to implement this in a safe manner (and anyone that has a non-standard setup must then upgrade manually, but that is probably ok).

This looks tricky to me, since it will only work in controlled cirumstances. In particular: - PHP must have write access to the entire Hypha directory (which is not always a good idea, but is common in practice). - The correct branch must be checked out, possibly with an upstream branch also configured etc, and a fast forward must be possible. Limiting to just the master branch might be ok here. - There must not be any uncommitted changes (which mean we need to do something with themes/CSS, as editing hypha.css/hypha.html through the webinterface now changes git-tracked files, see #49). - Git must be available on the commandline (unless we're going to include some PHP implementation of git, but that seems overkill to me). It does seem that each of these things can be tested from the commandline, so it might be feasible to implement this in a safe manner (and anyone that has a non-standard setup must then upgrade manually, but that is probably ok).

matthijskooijman commented

2018-12-05 17:14:08 +00:00

(Migrated from github.com)

This might be useful code, it contains some wrappers to call git commands from PHP and has some output-parsing options.

https://github.com/czproject/git-php/blob/master/src/GitRepository.php

This might be useful code, it contains some wrappers to call git commands from PHP and has some output-parsing options. https://github.com/czproject/git-php/blob/master/src/GitRepository.php

matthijskooijman commented

2018-12-29 13:44:17 +00:00

(Migrated from github.com)

One extra caveat: When fetching using SSH, the SSH host key must be accepted. When running from inside the webserver, git runs as another user, with its own ~/.ssh/known_hosts, which likely does not know about the server SSH key yet. Even more tricky is that the default www-data on Debian has /var/www as its homedir, but cannot actually write there, so it fails to create ~/.ssh.

I can imagine some ways to handle this:

Forbid SSH fetch urls, and limit to HTTP(S) urls. Tricky is that you can't easily detect a git url (though HTTP(S) is trivial).
Disable all SSH host key checking. This is probably a bad idea from a security POV. Also, this is a bit tricky, requiring a custom SSH command, or settings in ~/.ssh/config (which is typically not writeable...).
Use a custom known hosts file. This requires filling it somehow, and passing it to git using a custom SSH command...
Add the server key to the global known hosts file in /etc. This is a manual action, but only needs to happen once, so this is probably a good way to support SSH. The only tricky part is to detect that this is needed (but something like "You're not using HTTP, so you might need to setup a known hosts file").

One extra caveat: When fetching using SSH, the SSH host key must be accepted. When running from inside the webserver, git runs as another user, with its own `~/.ssh/known_hosts`, which likely does not know about the server SSH key yet. Even more tricky is that the default `www-data` on Debian has `/var/www` as its homedir, but cannot actually write there, so it fails to create `~/.ssh`. I can imagine some ways to handle this: - Forbid SSH fetch urls, and limit to HTTP(S) urls. Tricky is that you can't easily detect a git url (though HTTP(S) is trivial). - Disable all SSH host key checking. This is probably a bad idea from a security POV. Also, this is a bit tricky, requiring a custom SSH command, or settings in `~/.ssh/config` (which is typically not writeable...). - Use a custom known hosts file. This requires filling it somehow, and passing it to git using a custom SSH command... - Add the server key to the global known hosts file in `/etc`. This is a manual action, but only needs to happen once, so this is probably a good way to support SSH. The only tricky part is to *detect* that this is needed (but something like "You're not using HTTP, so you *might* need to setup a known hosts file").

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

harmen/hypha#108

No description provided.

Rows
Columns