github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-03-22 06:24:14 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

Allow configuration of standard Unix layout #157

New Issue
Closed
opened 2025-11-02 03:11:10 -06:00 by GiteaMirror · 24 comments
GiteaMirror commented 2025-11-02 03:11:10 -06:00
Owner
Copy Link

Originally created by @couling on GitHub (Dec 26, 2016).

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).
Originally created by @couling on GitHub (Dec 26, 2016). 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](https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard) 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) ``` <bountysource-plugin> --- 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). </bountysource-plugin>
GiteaMirror added the type/featuretype/enhancement labels 2025-11-02 03:11:10 -06:00
GiteaMirror commented 2025-11-02 03:11:11 -06:00
Author
Owner
Copy Link

@kjellkvinge commented on GitHub (Dec 26, 2016):

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.

@kjellkvinge commented on GitHub (Dec 26, 2016): 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.
GiteaMirror commented 2025-11-02 03:11:11 -06:00
Author
Owner
Copy Link

@tboerger commented on GitHub (Dec 26, 2016):

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 commented on GitHub (Dec 26, 2016): 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
GiteaMirror commented 2025-11-02 03:11:11 -06:00
Author
Owner
Copy Link

@tboerger commented on GitHub (Dec 26, 2016):

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

@tboerger commented on GitHub (Dec 26, 2016): Let's see if I can prepare a proper showcase within the docker container.
GiteaMirror commented 2025-11-02 03:11:11 -06:00
Author
Owner
Copy Link

@strk commented on GitHub (Dec 27, 2016):

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 ?

@strk commented on GitHub (Dec 27, 2016): 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 ?
GiteaMirror commented 2025-11-02 03:11:12 -06:00
Author
Owner
Copy Link

@couling commented on GitHub (Dec 27, 2016):

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?

@couling commented on GitHub (Dec 27, 2016): 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?
GiteaMirror commented 2025-11-02 03:11:12 -06:00
Author
Owner
Copy Link

@bkcsoft commented on GitHub (Dec 29, 2016):

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

[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
@bkcsoft commented on GitHub (Dec 29, 2016): This should do it, if it doesn't then we have a bug :trollface: ``` [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 ```
GiteaMirror commented 2025-11-02 03:11:13 -06:00
Author
Owner
Copy Link

@couling commented on GitHub (Jan 4, 2017):

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.

@couling commented on GitHub (Jan 4, 2017): 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.
GiteaMirror commented 2025-11-02 03:11:13 -06:00
Author
Owner
Copy Link

@bkcsoft commented on GitHub (Jan 20, 2017):

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

@bkcsoft commented on GitHub (Jan 20, 2017): @couling `conf/` is built into the binary when built with `TAGS="bindata"`, should fix your issue :)
GiteaMirror commented 2025-11-02 03:11:13 -06:00
Author
Owner
Copy Link

@couling commented on GitHub (Jan 20, 2017):

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

@couling commented on GitHub (Jan 20, 2017): Is there a full list of tags recorded somewhere that I need to build with?
GiteaMirror commented 2025-11-02 03:11:13 -06:00
Author
Owner
Copy Link

@bkcsoft commented on GitHub (Jan 21, 2017):

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

@bkcsoft commented on GitHub (Jan 21, 2017): there's a few oneliners floating around for `grep`ing the files for build-tags, but AFAIK there's only `bindata,sqlite` 🙂
GiteaMirror commented 2025-11-02 03:11:13 -06:00
Author
Owner
Copy Link

@tboerger commented on GitHub (Jan 24, 2017):

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

@tboerger commented on GitHub (Jan 24, 2017): https://docs.gitea.io/en-us/install-from-source/#build lists the regular build tags ;)
GiteaMirror commented 2025-11-02 03:11:14 -06:00
Author
Owner
Copy Link

@blankoworld commented on GitHub (May 17, 2017):

@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.

@blankoworld commented on GitHub (May 17, 2017): @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.
GiteaMirror commented 2025-11-02 03:11:14 -06:00
Author
Owner
Copy Link

@couling commented on GitHub (May 17, 2017):

@blankoworld There are basically two options:

  1. Work around: Before running gitea, you need to cd to the conf directory directory
  2. Fix by recompiling the binary. Instead of just:
    make
    You need
    make TAGS="bindata"
@couling commented on GitHub (May 17, 2017): @blankoworld There are basically two options: 1. Work around: Before running gitea, you need to `cd` to the conf directory directory 2. Fix by recompiling the binary. Instead of just: `make` You need `make TAGS="bindata"`
GiteaMirror commented 2025-11-02 03:11:14 -06:00
Author
Owner
Copy Link

@blankoworld commented on GitHub (May 17, 2017):

@couling :

  1. 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?
  2. 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
@blankoworld commented on GitHub (May 17, 2017): @couling : 1. 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? 2. 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
GiteaMirror commented 2025-11-02 03:11:14 -06:00
Author
Owner
Copy Link

@couling commented on GitHub (May 17, 2017):

@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.

@couling commented on GitHub (May 17, 2017): @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.
GiteaMirror commented 2025-11-02 03:11:15 -06:00
Author
Owner
Copy Link

@MTecknology commented on GitHub (Jul 30, 2017):

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 commented on GitHub (Jul 30, 2017): 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. :)
GiteaMirror commented 2025-11-02 03:11:15 -06:00
Author
Owner
Copy Link

@MTecknology commented on GitHub (Oct 26, 2017):

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:

@MTecknology commented on GitHub (Oct 26, 2017): 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: - https://anonscm.debian.org/cgit/pkg-go/packages/golang-code.gitea-gitea.git/plain/debian/patches/003-update-default-configuration.patch - https://anonscm.debian.org/cgit/pkg-go/packages/golang-code.gitea-gitea.git/plain/debian/gitea.postinst - https://anonscm.debian.org/cgit/pkg-go/packages/golang-code.gitea-gitea.git/plain/debian/gitea.service - https://anonscm.debian.org/cgit/pkg-go/packages/golang-code.gitea-gitea.git/plain/debian/gitea.init - https://anonscm.debian.org/cgit/pkg-go/packages/golang-code.gitea-gitea.git/plain/debian/gitea-common.links
GiteaMirror commented 2025-11-02 03:11:15 -06:00
Author
Owner
Copy Link

@bkcsoft commented on GitHub (Oct 29, 2017):

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

@bkcsoft commented on GitHub (Oct 29, 2017): @MTecknology could you please send that as a PR? 🙂
GiteaMirror commented 2025-11-02 03:11:15 -06:00
Author
Owner
Copy Link

@MTecknology commented on GitHub (Oct 30, 2017):

@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.

@MTecknology commented on GitHub (Oct 30, 2017): @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.
GiteaMirror commented 2025-11-02 03:11:16 -06:00
Author
Owner
Copy Link

@blankoworld commented on GitHub (Oct 30, 2017):

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.

@blankoworld commented on GitHub (Oct 30, 2017): 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.
GiteaMirror commented 2025-11-02 03:11:16 -06:00
Author
Owner
Copy Link

@lafriks commented on GitHub (Feb 19, 2018):

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

@lafriks commented on GitHub (Feb 19, 2018): 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
GiteaMirror commented 2025-11-02 03:11:16 -06:00
Author
Owner
Copy Link

@MTecknology commented on GitHub (Feb 19, 2018):

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)

@MTecknology commented on GitHub (Feb 19, 2018): 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)
GiteaMirror commented 2025-11-02 03:11:17 -06:00
Author
Owner
Copy Link

@lafriks commented on GitHub (Feb 20, 2018):

@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?

@lafriks commented on GitHub (Feb 20, 2018): @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?
GiteaMirror commented 2025-11-02 03:11:17 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (May 1, 2019):

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

@zeripath commented on GitHub (May 1, 2019): Since #6631 you can build Gitea with the defaults in the correct place
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label type/enhancement type/feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#157
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?