delete a user from command line ignores the -c switch with config file

[mariuz]

Gitea Version

1.15.6

Git Version

git version 2.25.1

Operating System

ubuntu 20.04

How are you running Gitea?

i used the binary version with wget

Database

MySQL

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Description

create user from command line works ok and the website is ok , but the issues start when i try to delete a user

(ROOT = /home/git/gitea-repositories and works correctly)
so it tries to write in default folder and ignoring config file /etc/gitea/app.ini

gitea -c /etc/gitea/app.ini admin user delete --id 20

2021/11/02 11:46:42 ...s/storage/storage.go:171:initAttachments() [I] Initialising Attachment storage with type:
2021/11/02 11:46:42 ...les/storage/local.go:47:NewLocalStorage() [I] Creating new Local Storage at /usr/local/bin/data/attachments
2021/11/02 11:46:42 main.go:117:main() [F] Failed to run app with [gitea -c /etc/gitea/app.ini admin user delete --id 20]: mkdir /usr/local/bin/data: permission denied

Screenshots

No response

[wxiaoguang]

You should use the correct app.ini (the one was already created by the first gitea setup), never use the non-related ones.

Make sure you are using the correct app.ini and make sure you run the gitea binary on the same system (host) as gitea web server.

[zeripath]

This is interesting because:

gitea/main.go

Lines 121 to 127 in 95da01c

	func setFlagsAndBeforeOnSubcommands(command *cli.Command, defaultFlags []cli.Flag, before cli.BeforeFunc) {
	command.Flags = append(command.Flags, defaultFlags...)
	command.Before = establishCustomPath
	for i := range command.Subcommands {
	setFlagsAndBeforeOnSubcommands(&command.Subcommands[i], defaultFlags, before)
	}
	}

should be passing along these values up to the subcommand.

With:

https://github.com/go-gitea/gitea/blob/95da01c5cd946d6e6ba0b0110676d3df36ce85db/main.go#L129-164

being responsible propagating the setting the custom conf correctly.

---

I guess one way to check what's going on would be to stick some logging into that function to check if this Before func isn't getting propagated correctly.

---

Aha - it's not that the config is not being picked up correctly, but that the working directory is not the same as what you would run.

[wxiaoguang]

@zeripath

But my test shows that the global options -c position seems correct here.

./gitea -c /tmp/debug/no-such.ini admin user delete --id 123123 
2021/11/03 00:01:32 ...s/setting/setting.go:563:NewContext() [W] Custom config '/tmp/debug/no-such.ini' not found, ignore this if you're running first time

The log shows that the gitea is using debug/no-such.ini

---

To the author of this issue: please ignore the internal discussion above.

Just make sure you are using the correct app.ini and make sure you run the gitea binary on the same system (host) as gitea web server.

[zeripath]

@mariuz you likely need to set -w correctly.

---

Gitea as compiled by default is not really intended to get placed in /usr/local/bin or /usr/bin. It makes assumptions about where it is going to find things based upon the location of the binary. These assumptions can be overridden by environment variables and/or command line options but if those are not present the default locations will be used. The contrib systemd conf file sets the correct variables by default but your shell is not (nor should it be expected to).

In this case because the data path is not set within the app.ini it is assumed to be the data/ sub-directory of the "workpath" - that is the directory in which the gitea executable can be found.

Now, there are several ways of getting round this.

1. There is a filesystem hierarchy compliant script that can be found in our contrib folder that I wrote with the intention that this would be what was placed in /usr/bin or /usr/local/bin and the gitea binary placed elsewhere.
2. The other option is when compiling Gitea you can set some LDFLAGS to change the default locations
3. Continue using environment variables and command line options.