Config option for custom directory #926

@stale[bot] commented on GitHub (Feb 12, 2019):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

@stale[bot] commented on GitHub (Feb 12, 2019): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

GiteaMirror commented

@mckaygerhard commented on GitHub (Feb 12, 2019):

this iisue was solved? why marked stalled?

@mckaygerhard commented on GitHub (Feb 12, 2019): this iisue was solved? why marked stalled?

GiteaMirror commented

@stale[bot] commented on GitHub (Apr 13, 2019):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

@stale[bot] commented on GitHub (Apr 13, 2019): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

GiteaMirror commented

@zeripath commented on GitHub (Apr 13, 2019):

OK, I think just adding a --custom-dir="" option to the commands isn't really worth it. Especially as the cheapest way to implement that would be just to do os.Setenv("GITEA_CUSTOM", providedCustomDir).

We need to look again what $GITEA_CUSTOM really represents. It provides the basis of the following paths: (I will use $GITEA_CUSTOM for setting.CustomPath here)

$GITEA_CUSTOM/options the base directory of local "gitignore", "license", "readme", "label" files.
$GITEA_CUSTOM/public a directory of custom public assets
$GITEA_CUSTOM/templates a directory of custom templates
$GITEA_CUSTOM/robots.txt the robots.txt
$GITEA_CUSTOM/conf/app.ini the default location of the app.ini <- the only separately configurable one of these

Is it acceptable for all of these things to be under say /etc/gitea/? (with the exception of app.ini being maybe pointed to /etc/gitea.ini)

What I suspect is really wanted to provide a build option that would change the default of $GITEA_CUSTOM and app.ini then you don't need this new option or -c making /usr/bin/gitea just work - however, in terms of the necessity of providing this, would it be possible to explain why you can't just make the gitea binary be shadowed by a sh script that adjusts the environment like many programs which don't necessarily obey the FHS e.g. Firefox or chrome? So the original gitea binary ends up as /usr/lib/gitea/bin/gitea and the shell script is /usr/bin/gitea with it setting the GITEA_CUSTOM and passing -c as appropriate.

@zeripath commented on GitHub (Apr 13, 2019): OK, I think just adding a --custom-dir="" option to the commands isn't really worth it. Especially as the cheapest way to implement that would be just to do `os.Setenv("GITEA_CUSTOM", providedCustomDir)`. We need to look again what `$GITEA_CUSTOM` really represents. It provides the basis of the following paths: (I will use `$GITEA_CUSTOM` for `setting.CustomPath` here) * `$GITEA_CUSTOM/options` the base directory of local "gitignore", "license", "readme", "label" files. * `$GITEA_CUSTOM/public` a directory of custom public assets * `$GITEA_CUSTOM/templates` a directory of custom templates * `$GITEA_CUSTOM/robots.txt` the robots.txt * `$GITEA_CUSTOM/conf/app.ini` the default location of the app.ini <- the only separately configurable one of these Is it acceptable for all of these things to be under say `/etc/gitea/`? (with the exception of `app.ini` being maybe pointed to `/etc/gitea.ini`) What I suspect is really wanted to provide a build option that would change the default of `$GITEA_CUSTOM` and `app.ini` then you don't need this new option or `-c` making `/usr/bin/gitea` just work - however, in terms of the necessity of providing this, would it be possible to explain why you can't just make the gitea binary be shadowed by a sh script that adjusts the environment like many programs which don't necessarily obey the FHS e.g. Firefox or chrome? So the original gitea binary ends up as `/usr/lib/gitea/bin/gitea` and the shell script is `/usr/bin/gitea` with it setting the `GITEA_CUSTOM` and passing `-c ` as appropriate.

GiteaMirror commented

@mckaygerhard commented on GitHub (Apr 14, 2019):

El sáb., 13 de abr. de 2019 a la(s) 13:31, zeripath (
notifications@github.com) escribió:

What I suspect is really wanted to provide a build option that would
change the default of $GITEA_CUSTOM and app.ini then you don't need this
new optionor -c making /usr/bin/gitea just work - however, in terms of
the necessity of providing this, would it be possible to explain why you
can't just make the gitea binary be shadowed by a sh script that adjusts
the environment like many programs which don't necessarily obey the FHS
e.g. Firefox or chrome? So the original gitea binary ends up as
/usr/lib/gitea/bin/gitea and the shell script is /usr/bin/gitea with it
setting the GITEA_CUSTOM and passing -c as appropriate.

That its the idea! thanks for your explanation! as i always said why not
center effors to real needs like this?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/go-gitea/gitea/issues/2228#issuecomment-482846919,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAL7XDGGYCZZKNZGFBXEZODPQIKFRANCNFSM4DU6FVWQ
.

@mckaygerhard commented on GitHub (Apr 14, 2019): El sáb., 13 de abr. de 2019 a la(s) 13:31, zeripath ( notifications@github.com) escribió: > What I suspect is really wanted to provide a build option that would > change the default of $GITEA_CUSTOM and app.ini then you don't need this > new optionor -c making /usr/bin/gitea just work - however, in terms of > the necessity of providing this, would it be possible to explain why you > can't just make the gitea binary be shadowed by a sh script that adjusts > the environment like many programs which don't necessarily obey the FHS > e.g. Firefox or chrome? So the original gitea binary ends up as > /usr/lib/gitea/bin/gitea and the shell script is /usr/bin/gitea with it > setting the GITEA_CUSTOM and passing -c as appropriate. That its the idea! thanks for your explanation! as i always said why not center effors to real needs like this? > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <https://github.com/go-gitea/gitea/issues/2228#issuecomment-482846919>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AAL7XDGGYCZZKNZGFBXEZODPQIKFRANCNFSM4DU6FVWQ> > . >

GiteaMirror commented

@zeripath commented on GitHub (Apr 14, 2019):

But why can't you use a script to shadow the Gitea binary like is done for Firefox or Chrome?

@zeripath commented on GitHub (Apr 14, 2019): But why can't you use a script to shadow the Gitea binary like is done for Firefox or Chrome?

GiteaMirror commented

@mckaygerhard commented on GitHub (Apr 15, 2019):

distributions does not use those horrendous scripts.. set right paths in filesystems
it's not stanar, firefox and chrome does are not installed on that way in debian systems.. by example
a script produces issues due confuses gitea paths

simple! reasons!

@mckaygerhard commented on GitHub (Apr 15, 2019): 1. distributions does not use those horrendous scripts.. set right paths in filesystems 2. it's not stanar, firefox and chrome does are not installed on that way in debian systems.. by example 3. a script produces issues due confuses gitea paths simple! reasons!

GiteaMirror commented

783cd64927/modules/setting/setting.go (L479-L484)

@zeripath commented on GitHub (Apr 15, 2019):

I'm fairly certain that /usr/bin/firefox is a script on Debian but I'm not on my box right now to prove it.

Anyway, the best we can achieve is a LDFLAGS on go install approach LDFLAGS="-X \"code.gitea.io/gitea/modules/setting.CustomPath=/new/default\"" this would require a simple change here:

So that it would check if GITEA_CUSTOM is set before trying to use it. E.g. replace L479 with:

if giteaCustom, ok := os.LookupEnv("GITEA_CUSTOM"); ok {
     CustomPath = giteaCustom
}

In terms of changing the default app ini location (aka the -c option) that's easier you can do that now with -X "code.gitea.io/gitea/modules/setting.CustomConf=wherever-hell-you-want" . The other environment variables might be similar.

We'd have to come up with a way of explaining why custom path is different so that users can work out why things aren't changing.

But this kind of behaviour would make the docker build a little easier overall.

Hmm... @techknowlogick what do you think?

@zeripath commented on GitHub (Apr 15, 2019): I'm fairly certain that /usr/bin/firefox is a script on Debian but I'm not on my box right now to prove it. Anyway, the best we can achieve is a LDFLAGS on go install approach `LDFLAGS="-X \"code.gitea.io/gitea/modules/setting.CustomPath=/new/default\""` this would require a simple change here: https://github.com/go-gitea/gitea/blob/783cd649276c472aa3af97dd311eb4766ff3adfb/modules/setting/setting.go#L479-L484 So that it would check if GITEA_CUSTOM is set before trying to use it. E.g. replace L479 with: ```go if giteaCustom, ok := os.LookupEnv("GITEA_CUSTOM"); ok { CustomPath = giteaCustom } ``` In terms of changing the default app ini location (aka the -c option) that's easier you can do that now with `-X "code.gitea.io/gitea/modules/setting.CustomConf=wherever-hell-you-want"` . The other environment variables might be similar. We'd have to come up with a way of explaining why custom path is different so that users can work out why things aren't changing. But this kind of behaviour would make the docker build a little easier overall. Hmm... @techknowlogick what do you think?

GiteaMirror commented

@zeripath commented on GitHub (Apr 15, 2019):

I've put the above changes in to #6631 which if merged means we can close this issue.

--
EDIT: #6631 now implements this option.

@zeripath commented on GitHub (Apr 15, 2019): I've put the above changes in to #6631 which if merged means we can close this issue. -- EDIT: #6631 now implements this option.

GiteaMirror commented

@mckaygerhard commented on GitHub (Apr 15, 2019):

thanks @zeripath and, umm about firefox:

ls -l /usr/bin/firefox-esr 
lrwxrwxrwx 1 root root 30 dic 13 06:34 /usr/bin/firefox-esr -> ../lib/firefox-esr/firefox-esr
file /usr/lib/firefox-esr/firefox-esr
/usr/lib/firefox-esr/firefox-esr: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=443463ab667fbd0c6f5bb7c737d0d219c39ab502, stripped

@mckaygerhard commented on GitHub (Apr 15, 2019): thanks @zeripath and, umm about firefox: ``` ls -l /usr/bin/firefox-esr lrwxrwxrwx 1 root root 30 dic 13 06:34 /usr/bin/firefox-esr -> ../lib/firefox-esr/firefox-esr file /usr/lib/firefox-esr/firefox-esr /usr/lib/firefox-esr/firefox-esr: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=443463ab667fbd0c6f5bb7c737d0d219c39ab502, stripped ```

GiteaMirror commented

@zeripath commented on GitHub (Apr 15, 2019):

I'm not going to get into a cat match with you but /usr/bin/firefox and /usr/bin/google-chrome are both scripts on my system.

@zeripath commented on GitHub (Apr 15, 2019): I'm not going to get into a cat match with you but `/usr/bin/firefox` and `/usr/bin/google-chrome` are both scripts on my system.

GiteaMirror commented

@mckaygerhard commented on GitHub (Apr 15, 2019):

revised and confirmed, but seems i just to parse compatibility:

/usr/bin/firefox its a scritp to property use /usr/bin/firefox-esr

BUT google chrome its not a package from debian... so marked as non-valid ;-)

@mckaygerhard commented on GitHub (Apr 15, 2019): revised and confirmed, but seems i just to parse compatibility: /usr/bin/firefox its a scritp to property use /usr/bin/firefox-esr BUT google chrome its not a package from debian... so marked as non-valid ;-)

GiteaMirror commented