Allow configuration of standard Unix layout #480

couling · 2016-12-26T11:56:21Z

The current install instructions suggests gitea should be run from a single directory (/home/git/gitea)

This is very non-standard for *nix operating systems and will irritate a lot of sysadmins. I've had earlier versions (gogs) running based on standard layout by configuring app.ini to point to the various directories. But this seems to have broken. The following now seems to be partially ignored.

[server]
STATIC_ROOT_PATH = /foo/bar

My current work around is to construct a directory /var/lib/gitea/ and use symlinks to bring everything into one place.

Our aim ought to be to allow the following layout relatively purely through a handful of app.ini settings and command-line args:

gitea binary --> /usr/sbin/gitea
config --> /etc/gitea/ (eg: /etc/gitea/app.ini)
static content --> /usr/share/gitea (eg: /usr/share/gitea/templates)
variable content --> /var/lib/gitea  (eg: /var/lib/gitea/repositories)
log --> /var/log/gitea (eg: /var/log/gitea/http.log)

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/40400377-allow-configuration-of-standard-unix-layout?utm_campaign=plugin&utm_content=tracker%2F47456670&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F47456670&utm_medium=issues&utm_source=github).

The text was updated successfully, but these errors were encountered:

kjellkvinge · 2016-12-26T12:11:21Z

Hi. In my setup, I have the binary in /usr/local/bin,

It was somewhat confusing to get the files where I wanted them, but I managed without symlinks.
the configfile contains:

[attachment]
PATH = ....
...
[picture]
AVATAR_UPLOAD_PATH = ...

[repository]
ROOT = ...

working directory + /data is where sessions and tmp is placed. This is set by the init script.

I am not sure if there is more "hidden" config values that could make this more easy.

tboerger · 2016-12-26T13:05:24Z

I also don't like the current default behavior for the directories, but changing that means possibly breaking things. Hopefully we will provide better defaults in future releases

tboerger · 2016-12-26T13:06:44Z

Let's see if I can prepare a proper showcase within the docker container.

strk · 2016-12-27T10:10:11Z

I think the milestone of this should be 1.0.x, as it breaks upgrades from Gogs.
Is it a problem to make STATIC_ROOT_PATH work again with the new bindata mechanism ?

couling · 2016-12-27T13:55:18Z

Digging into this a little more. The current thing stopping my setup is that I get the error:

panic: fail to set message file(en-US): open conf/locale/locale_en-US.ini: no such file or directory

This seems to be failing if the conf directory isn't in the CWD (eg: the CWD isn't set to /home/git/custom). This a subtly a different bug than I thought. Do you want me to raise a seperate issue and keep this one clean?

bkcsoft · 2016-12-29T21:15:23Z

This should do it, if it doesn't then we have a bug

[repository.upload]
TEMP_PATH=/tmp/gogs/uploads
[picture]
AVATAR_UPLOAD_PATH=/var/lib/gitea/avatars
[attachment]
PATH=/var/lig/gitea/attachments
[log]
ROOT_PATH=/var/log/gitea
[repository]
ROOT=/var/lib/gitea/repositories

couling · 2017-01-04T19:12:55Z

Yeah that still fails unless I set my working directory first.

panic: fail to set message file(en-US): open conf/locale/locale_en-US.ini: no such file or directory

This is the only item I know if that is affected by the current working directory. I'm pretty sure its a recent change that's caused it but I can't find what it was.

bkcsoft · 2017-01-20T07:54:04Z

@couling conf/ is built into the binary when built with TAGS="bindata", should fix your issue :)

couling · 2017-01-20T08:40:41Z

Is there a full list of tags recorded somewhere that I need to build with?

bkcsoft · 2017-01-21T04:03:02Z

there's a few oneliners floating around for greping the files for build-tags, but AFAIK there's only bindata,sqlite 🙂

tboerger · 2017-01-24T21:49:00Z

https://docs.gitea.io/en-us/install-from-source/#build lists the regular build tags ;)

blankoworld · 2017-05-17T08:46:04Z

@couling I encount the same problem as you about conf/locale/locale_en-US.ini but I don't understand the way you fix the problem.
Mine was:

synchronize (using rsync) /var/lib/gitea with the directory I use (for an example /srv/www/gitea/) that contains a custom directory (in which I redefine some templates, etc.) and while excluding data directory and custom one
change STATIC_ROOT_PATH (that seems to change in the new AUR package I use) to /srv/www/gitea/ instead of previous "/srv/www/gitea/public" value

So I agree with this topic that it's quite difficult on standard Unix to deal with files and directories without the "bindata" option when building Gitea. AUR package doesn't provide any "bindata" option when building.

couling · 2017-05-17T09:05:59Z

@blankoworld There are basically two options:

Work around: Before running gitea, you need to cd to the conf directory directory
Fix by recompiling the binary. Instead of just:
make
You need
make TAGS="bindata"

blankoworld · 2017-05-17T09:13:43Z

@couling :

My app.ini file is in /etc/gitea/app.ini, and files are in /srv/www/gitea. To my mind it may not work in this configuration, may it not?
As I use AUR package (ArchLinux community) I think that the author don't use bindata for some reason. But it cost me nothing to ask him/her why this tag isn't used

couling · 2017-05-17T09:24:42Z

@blankoworld I have a similar setup. I use /srv/gitea/ but the principle is the same. The other difference is that I spread out some files across the filesystem (eg my config files are in /etc). If you work in a single directory, you will want to change the home directory of the user running gitea to /srv/www/gitea. If your configuration is there as well then before running gitea you need to cd /srv/www/gitea/conf OR you need to build gitea with the bindata tag as indicated above..

To my mind gitea defaults really need an overhaul to bring them inline with linux standards.

MTecknology · 2017-07-30T06:55:21Z

I don't disagree with gitea being written to run from a single directory. There are many applications that are written to run this way because of the developer's workflow. Gitea has a lot of configuration options available in app.ini and I'd say we're pretty close to being able to deploy gitea in the "standard unix" structure.

If #2229, and to a lesser degree #2228, were resolved, the rest isn't much more than tweaking the default configuration file when deploying from a package. Easy peasy. :)

MTecknology · 2017-10-26T04:32:59Z

It took a LOT of hacking and the result isn't very pretty, but I have something that follows a standard layout. https://people.debian.org/~mtecknology/ppa/README (unfinished, but presentable for this discussion)

Some of the relevant hacking:

bkcsoft · 2017-10-29T06:25:32Z

@MTecknology could you please send that as a PR? 🙂

MTecknology · 2017-10-30T06:04:48Z

@bkc No, not really. The hacks that I needed for this deployment approach wouldn't work well for dev-style deployments. (I would encourage you to review them.) We need some sort of compromise and I'm hoping a working example of gitea running this way can aid that discussion. The first thing I noticed is that gitea uses the location of the binary location as the root for all relative paths. This can be overridden with an environment variable, but environment variables are rather clunky for production-style deployments (and undocumented). It would be more convenient if the root could be configured via app.ini or build-time variable. It would also be nice if the expected location for app.ini could be configured at build time. One big headache I noticed was how frequently I needed to set static paths. This would be hard to fix, but setting some top level dirs (data/, public/, custom/, etc.) in a global config section and making all making other variable relative to them (instead of just setting static paths all over) would clean up that logic. We have STATIC_ROOT_PATH and APP_DATA_PATH in the configuration file, but they seem to be in sections that lack useful scope and seem to be ineffective where they're at. The actual directory structure is mostly fine, but the way the configuration is clunky. I do think indexers should move to being underneath data/ since data/ seems to be variable stuff. Something that I found extremely annoying, that I suspect will someday come back to bite, is gitea needing write access to config file locations. Gitea shouldn't need to re-create app.ini when it starts. It shouldn't need to write anything at all. Instead, it won't start when it can't edit.

blankoworld · 2017-10-30T08:47:07Z

You're right about documentation, a lot of variables aren't documented. But we have https://docs.gitea.io/en-us/specific-variables/. And it should be fine if developers or contributors can complete progressively this page ^_^.

I was also afraid since Gitea 1.2.2 to see that app.ini should be overwritten by Gitea itself. But this seems to be same thing for other tools as Mattermost. In Mattermost, either you edit the configuration and then you start the service or you start the service and update the configuration through the web interface (which update your configuration file). Seems to be dangerous, but I don't know how to keep configuration you update through the web interface.

lafriks · 2018-02-19T23:41:32Z

I think currently it is possible to have correct standard unix layout with correctly configured app.ini so I think we can close this issue

MTecknology · 2018-02-19T23:56:46Z

With enough fiddling, yes, it's possible to get gitea to mostly adhere to standards. I absolutely wouldn't consider this closed, but I'm also not interested in chasing this. (using gitolite now)

lafriks · 2018-02-20T00:51:08Z

@MTecknology changes are needed only in app.ini. In previous versions it was still using relative to binary paths that were not possible to set in app.ini but with latest version this has been fixed.
What else needs to be done to consider this issue fixed?

zeripath · 2019-05-01T22:33:45Z

Since #6631 you can build Gitea with the defaults in the correct place

lunny added this to the 1.1.0 milestone Dec 28, 2016

lunny added type/enhancement An improvement of existing functionality type/feature Completely new functionality. Can only be merged if feature freeze is not active. labels Dec 28, 2016

lunny modified the milestones: 1.x.x, 1.1.0 Dec 28, 2016

couling mentioned this issue Jan 16, 2017

Provide releases and deb/rpm packages via Bintray #31

Closed

lafriks closed this as completed Feb 19, 2018

lafriks removed this from the 1.x.x milestone Feb 19, 2018

zeripath mentioned this issue Apr 16, 2019

Make CustomPath, CustomConf and AppWorkPath configurable at build #6631

Merged

go-gitea locked and limited conversation to collaborators Nov 24, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Allow configuration of standard Unix layout #480

Allow configuration of standard Unix layout #480

couling commented Dec 26, 2016 •

edited by tboerger

Loading

kjellkvinge commented Dec 26, 2016

tboerger commented Dec 26, 2016

tboerger commented Dec 26, 2016

strk commented Dec 27, 2016

couling commented Dec 27, 2016

bkcsoft commented Dec 29, 2016

couling commented Jan 4, 2017

bkcsoft commented Jan 20, 2017

couling commented Jan 20, 2017

bkcsoft commented Jan 21, 2017

tboerger commented Jan 24, 2017

blankoworld commented May 17, 2017 •

edited

Loading

couling commented May 17, 2017

blankoworld commented May 17, 2017

couling commented May 17, 2017

MTecknology commented Jul 30, 2017

MTecknology commented Oct 26, 2017 •

edited

Loading

bkcsoft commented Oct 29, 2017

MTecknology commented Oct 30, 2017 via email

blankoworld commented Oct 30, 2017

lafriks commented Feb 19, 2018

MTecknology commented Feb 19, 2018

lafriks commented Feb 20, 2018

zeripath commented May 1, 2019

Allow configuration of standard Unix layout #480

Allow configuration of standard Unix layout #480

Comments

couling commented Dec 26, 2016 • edited by tboerger Loading

kjellkvinge commented Dec 26, 2016

tboerger commented Dec 26, 2016

tboerger commented Dec 26, 2016

strk commented Dec 27, 2016

couling commented Dec 27, 2016

bkcsoft commented Dec 29, 2016

couling commented Jan 4, 2017

bkcsoft commented Jan 20, 2017

couling commented Jan 20, 2017

bkcsoft commented Jan 21, 2017

tboerger commented Jan 24, 2017

blankoworld commented May 17, 2017 • edited Loading

couling commented May 17, 2017

blankoworld commented May 17, 2017

couling commented May 17, 2017

MTecknology commented Jul 30, 2017

MTecknology commented Oct 26, 2017 • edited Loading

bkcsoft commented Oct 29, 2017

MTecknology commented Oct 30, 2017 via email

blankoworld commented Oct 30, 2017

lafriks commented Feb 19, 2018

MTecknology commented Feb 19, 2018

lafriks commented Feb 20, 2018

zeripath commented May 1, 2019

couling commented Dec 26, 2016 •

edited by tboerger

Loading

blankoworld commented May 17, 2017 •

edited

Loading

MTecknology commented Oct 26, 2017 •

edited

Loading