Proposal: Updating the binary version automatically via shell script

[keks24]

• Operating system:

$ < /etc/os-release
PRETTY_NAME="Debian GNU/Linux 10 (buster)"
NAME="Debian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

Description

Hello,

I wrote a shell script to update my local Gitea instance automatically. I would like to leave this here, so others have a use of it.

Currently it only downloads the amd64 binary version from GitHub. Others may make it more dynamic.

Maybe it is useful and stable enough to mentioning it here or put it into the contrib directory?

Prerequisites:

The following packages are installed:

• aria2c
• curl
• install
• gpg
• logger
• mkdir
• rm
• sha256sum
• systemctl

An example:

I have not created a GPG keyring on my server and also not signed Gitea's GPG public key with my private key, so the check returns a warning, but better than nothing!

$ update_gitea --release-version 1.12.5
<13>Oct  2 13:05:42 update gitea[18086]: /usr/local/sbin/update_gitea: executed
The release version '1.12.5' is accessable via 'https://github.com/go-gitea/gitea/releases/tag/v1.12.5'. Starting download...

10/02 13:05:42 [NOTICE] Downloading 3 item(s)

10/02 13:05:42 [WARN] aria2c had to connect to the other side using an unknown TLS protocol. The integrity and confidentiality of the connection might be compromised.
Peer: github.com (140.82.121.4:443)

10/02 13:05:42 [WARN] aria2c had to connect to the other side using an unknown TLS protocol. The integrity and confidentiality of the connection might be compromised.
Peer: github.com (140.82.121.4:443)

10/02 13:05:42 [WARN] aria2c had to connect to the other side using an unknown TLS protocol. The integrity and confidentiality of the connection might be compromised.
Peer: github.com (140.82.121.4:443)

10/02 13:05:42 [NOTICE] CUID#9 - Redirecting to https://github-production-release-asset-2e65be.s3.amazonaws.com/72495579/4b060c80-0404-11eb-81f6-0c942f10a257?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20201002
%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20201002T130542Z&X-Amz-Expires=300&X-Amz-Signature=0ca95a713bd2a31e5e03e8a0e347e90f6df181a7b1fa6a7b5365879915ca2653&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=72495579&response-content-
disposition=attachment%3B%20filename%3Dgitea-1.12.5-linux-amd64.sha256&response-content-type=application%2Foctet-stream
[...]
Download Results:
gid   |stat|avg speed  |path/URI
======+====+===========+=======================================================
781ba3|OK  |    22KiB/s|/usr/local/share/gitea/1.12.5-linux-amd64/gitea-1.12.5-linux-amd64.asc
f9b22b|OK  |     892B/s|/usr/local/share/gitea/1.12.5-linux-amd64/gitea-1.12.5-linux-amd64.sha256
c5c618|OK  |   8.8MiB/s|/usr/local/share/gitea/1.12.5-linux-amd64/gitea-1.12.5-linux-amd64
Status Legend:
(OK):download completed.
gpg: Signature made Thu 01 Oct 2020 20:34:51 UTC
gpg:                using RSA key CC64B1DB67ABBEECAB24B6455FC346329753F4B0
gpg: Good signature from "Teabot <teabot@gitea.io>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 7C9E 6815 2594 6888 62D6  2AF6 2D9A E806 EC15 92E2
     Subkey fingerprint: CC64 B1DB 67AB BEEC AB24  B645 5FC3 4632 9753 F4B0
gitea-1.12.5-linux-amd64: OK
You are about to install:
'/usr/local/share/gitea/1.12.5-linux-amd64/gitea-1.12.5-linux-amd64'
to
'/usr/local/sbin/gitea'
This will also restart the systemd service unit!

Is this OK? (y/N) y
● gitea.service - Gitea (Git with a cup of tea)
   Loaded: loaded (/etc/systemd/system/gitea.service; enabled; vendor preset: enabled)
   Active: active (running) since Fri 2020-10-02 13:07:55 UTC; 17ms ago
 Main PID: 21289 (gitea)
    Tasks: 4 (limit: 4915)
   Memory: 4.0M
   CGroup: /system.slice/gitea.service
           └─21289 /usr/local/sbin/gitea web --config /etc/gitea/app.ini

Oct 02 13:07:55 gitea systemd[1]: Started Gitea (Git with a cup of tea).
Gitea was successfully updated to version '1.12.5'!

The files are downloaded to /usr/local/share/gitea/<some_version>-<some_os>-<some_arch>/. There is no cleanup routine implemented and must be done manually:

$ tree
.
├── 1.12.4-linux-amd64/
│   ├── gitea-1.12.4-linux-amd64
│   ├── gitea-1.12.4-linux-amd64.asc
│   └── gitea-1.12.4-linux-amd64.sha256
└── 1.12.5-linux-amd64/
    ├── gitea-1.12.5-linux-amd64
    ├── gitea-1.12.5-linux-amd64.asc
    └── gitea-1.12.5-linux-amd64.sha256

2 directories, 6 files

Updating the same version once again, skips the download:

$ update_gitea --release-version 1.12.5
<13>Oct  2 13:09:33 update gitea[24335]: /usr/local/sbin/update_gitea: executed
The download directory '/usr/local/share/gitea/1.12.5-linux-amd64' already exists. Installing the binary from there...
gpg: Signature made Thu 01 Oct 2020 20:34:51 UTC
gpg:                using RSA key CC64B1DB67ABBEECAB24B6455FC346329753F4B0
gpg: Good signature from "Teabot <teabot@gitea.io>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 7C9E 6815 2594 6888 62D6  2AF6 2D9A E806 EC15 92E2
     Subkey fingerprint: CC64 B1DB 67AB BEEC AB24  B645 5FC3 4632 9753 F4B0
gitea-1.12.5-linux-amd64: OK
You are about to install:
'/usr/local/share/gitea/1.12.5-linux-amd64/gitea-1.12.5-linux-amd64'
to
'/usr/local/sbin/gitea'
This will also restart the systemd service unit!

Is this OK? (y/N)

$ update_gitea --help

update_gitea - Download and update a given Gitea version.

Usage: update_gitea <options>

OPTIONS
  -h, --help
     Display this help text.

  -r, --release-version <version>
     Download a given release version

  -v, --version
     Displays the current version of this script.

EXAMPLES:
  Download and update a given Gitea version:
     update_gitea --release-version 1.12.4

Screenshots

[jolheiser]

This might be a nice thing to add to awesome-gitea. 🙂

[zeripath]

From 1.13 we should recommend flushing the queues before upgrading too.

[keks24]

From 1.13 we should recommend flushing the queues before upgrading too.

You mean gitea manager flush-queues?

[zeripath]

Yes

[keks24]

Alright! I would like to implement this, but it returns an error:

$ gitea manager flush-queues
Gitea: InternalServerError
Unable to contact gitea: Post "http://localhost:3000/api/internal/manager/flush-queues": dial tcp [::1]:3000: connect: connection refused

I could not find any process listening to port 3000:

$ ss -tulpan | grep "3000"

How do I configure this?

[zeripath]

As with all gitea commands you will need to provide it with a config - so set the -c parameter.

[keks24]

Ah, of course! I totally forgot about this...

I tried different parameter positions and also set the log level to trace. I somehow do not get any debug information, but the command always returns me exit code 1:

$ gitea manager flush-queues --config /etc/gitea/app.ini
$ echo "${?}"
1

What am I doing wrong?

---

/etc/gitea/app.ini

APP_NAME = Gitea: Git with a cup of tea
RUN_USER = gitea
RUN_MODE = prod

[oauth2]
JWT_SECRET = <some_secret>

[security]
INTERNAL_TOKEN = <some_token>
INSTALL_LOCK   = true
SECRET_KEY     = <some_token>
# custom - 20191103 - rfischer: set "PASSWORD_HASH_ALGO" to "pbkdf2"
PASSWORD_HASH_ALGO = pbkdf2

[server]
# LOCAL_ROOT_URL   = http://localhost:80/
# HTTP_PORT        = 80
SSH_DOMAIN       = gitea.local
DOMAIN           = gitea.local
#ROOT_URL         = http://gitea.local/
DISABLE_SSH      = false
SSH_PORT         = 22
LFS_START_SERVER = true
LFS_CONTENT_PATH = /var/lib/gitea/data/lfs
LFS_JWT_SECRET   = <some_secret>
OFFLINE_MODE     = true
# custom - 20191103 - rfischer: enable tls
LOCAL_ROOT_URL   = https://localhost/
PROTOCOL         = https
ROOT_URL         = https://gitea.local/
HTTP_PORT        = 443
CERT_FILE        = /etc/gitea/tls/gitea.local/gitea.local.crt
KEY_FILE         = /etc/gitea/tls/gitea.local/gitea.local.key
# custom - 20191103 - rfischer: set further settings
ENABLE_GZIP      = true

[database]
DB_TYPE  = sqlite3
HOST     = <some_ip_address>:<some_port_number>
NAME     = gitea
USER     = gitea
#PASSWD   =
# custom - 20191103 - rfischer: set a database password
PASSWD   = <some_password>
SSL_MODE = disable
CHARSET  = utf8
PATH     = /var/lib/gitea/data/gitea.db

[repository]
ROOT               = /home/gitea/gitea-repositories
# custom - 20190105 - rfischer: prefer a better formatted apache2.0 license file
PREFERRED_LICENSES = Custom_Apache-2.0

# custom - 20191103 - rfischer: add "[repository.pull-request]"
[repository.pull-request]
WORK_IN_PROGRESS_PREFIXES = WIP:, [WIP]
CLOSE_KEYWORDS            = close, closes, closed, fix, fixes, fixed, resolve, resolves, resolved
REOPEN_KEYWORDS           = reopen, reopens, reopened

# custom - 20191103 - rfischer: add "[repository.issue]"
[repository.issue]
LOCK_REASONS = too heated, off-topic, resolved, spam

# custom - 20191103 - rfischer: add "[ui]"
[ui]
DEFAULT_THEME = arc-green

# custom - 20191103 - rfischer: add "[markdown]"
[markdown]
CUSTOM_URL_SCHEMES = ftp, git, svn, rsync

[mailer]
ENABLED = false

[service]
REGISTER_EMAIL_CONFIRM            = false
ENABLE_NOTIFY_MAIL                = false
#DISABLE_REGISTRATION              = false
# custom - 20200102 - rfischer: disable registration
DISABLE_REGISTRATION              = true
ALLOW_ONLY_EXTERNAL_REGISTRATION  = false
ENABLE_CAPTCHA                    = false
REQUIRE_SIGNIN_VIEW               = false
DEFAULT_KEEP_EMAIL_PRIVATE        = false
DEFAULT_ALLOW_CREATE_ORGANIZATION = true
DEFAULT_ENABLE_TIMETRACKING       = true
NO_REPLY_ADDRESS                  = noreply.example.org

[picture]
DISABLE_GRAVATAR        = true
ENABLE_FEDERATED_AVATAR = false

[openid]
ENABLE_OPENID_SIGNIN = false
ENABLE_OPENID_SIGNUP = false

[session]
PROVIDER = file

# custom - 20191103 - rfischer: add "[attachment]"
[attachment]
ALLOWED_TYPES = */*

[log]
MODE      = file
LEVEL     = trace
ROOT_PATH = /var/log/gitea

[lunny]

@zeripath Is the flush a necessary step to upgrade?

[zeripath]

potentially yes - the idea is that you would clean up all waiting tasks before you upgraded. Imagine a situation whereby the pull model struct is completely changed then when you restore from the queue list you won't be able to map that back. It's that kind of thing.

I don't think we've made any significant changes that would break anything - but it's possible.

[zeripath]

@keks24 is the server also running? What do the logs from the server say? Are you running master? (This command is only available on master)

What does gitea manager -c path_to_config flush-queues --debug result in?

[keks24]

@keks24 is the server also running? What do the logs from the server say? Are you running master? (This command is only available on master)

What does gitea manager -c path_to_config flush-queues --debug result in?

1. Yes, I made sure, that it is running like it said, when executing gitea manager --help:

$ systemctl status gitea
● gitea.service - Gitea (Git with a cup of tea)
   Loaded: loaded (/etc/systemd/system/gitea.service; enabled; vendor preset: enabled)
   Active: active (running) since Sat 2020-10-03 13:45:39 UTC; 1 day 12h ago
 Main PID: 4926 (gitea)
    Tasks: 13 (limit: 4915)
   Memory: 251.6M
   CGroup: /system.slice/gitea.service
           └─4926 /usr/local/sbin/gitea web --config /etc/gitea/app.ini

Oct 05 01:00:02 gitea gitea[4926]: [Macaron] 2020-10-05 01:00:02: Started POST /api/internal/ssh/8/update/15 for [::1]
Oct 05 01:00:03 gitea gitea[4926]: [Macaron] 2020-10-05 01:00:03: Completed POST /api/internal/ssh/8/update/15 200 OK in 569.851305ms
Oct 05 02:00:01 gitea gitea[4926]: [Macaron] 2020-10-05 02:00:01: Started GET /api/internal/serv/command/8/keks24/documentation?mode=1&verb=git-upload-pack for [::1]
Oct 05 02:00:01 gitea gitea[4926]: [Macaron] 2020-10-05 02:00:01: Completed GET /api/internal/serv/command/8/keks24/documentation?mode=1&verb=git-upload-pack 200 OK in 1.489687ms
Oct 05 02:00:01 gitea gitea[4926]: [Macaron] 2020-10-05 02:00:01: Started POST /api/internal/ssh/8/update/15 for [::1]
Oct 05 02:00:02 gitea gitea[4926]: [Macaron] 2020-10-05 02:00:02: Completed POST /api/internal/ssh/8/update/15 200 OK in 373.611925ms
Oct 05 02:00:02 gitea gitea[4926]: [Macaron] 2020-10-05 02:00:02: Started GET /api/internal/serv/command/8/keks24/documentation?mode=1&verb=git-upload-pack for [::1]
Oct 05 02:00:02 gitea gitea[4926]: [Macaron] 2020-10-05 02:00:02: Completed GET /api/internal/serv/command/8/keks24/documentation?mode=1&verb=git-upload-pack 200 OK in 1.059409ms
Oct 05 02:00:02 gitea gitea[4926]: [Macaron] 2020-10-05 02:00:02: Started POST /api/internal/ssh/8/update/15 for [::1]
Oct 05 02:00:02 gitea gitea[4926]: [Macaron] 2020-10-05 02:00:02: Completed POST /api/internal/ssh/8/update/15 200 OK in 161.137996ms

2. I do not see anything in the log file, even with the following at the end of /etc/gitea/app.ini and restarting Gitea via systemctl restart gitea.service:

[log]
MODE      = file
LEVEL     = trace
ROOT_PATH = /var/log/gitea

Setting LEVEL = debug also does not add any new entries in the log file.

3. Since I am running a single instance on one server, I guess, I am running on master? How can I verify this? Could you elaborate?
   I think, you meant master branch? I thought of cluster systems with master and slave instances. I am using Gitea 1.12.5; maybe flushing is only available from 1.13.x?

4. After executing gitea manager -c /etc/gitea/app.ini flush-queues --debug, I get the following message:

$ gitea manager -c /etc/gitea/app.ini flush-queues --debug
Incorrect Usage: flag provided but not defined: -debug

NAME:
   Gitea manager flush-queues - Flush queues in the running process

USAGE:
   Gitea manager flush-queues [command options] [arguments...]

OPTIONS:
   --timeout value                Timeout for the flushing process (default: 1m0s)
   --non-blocking                 Set to true to not wait for flush to complete before returning
   --custom-path value, -C value  Custom path file path (default: "/usr/local/sbin/custom")
   --config value, -c value       Custom configuration file path (default: "/usr/local/sbin/custom/conf/app.ini")
   --version, -v                  print the version
   --work-path value, -w value    Set the gitea working path (default: "/usr/local/sbin")


DEFAULT CONFIGURATION:
     CustomPath:  /usr/local/sbin/custom
     CustomConf:  /etc/gitea/app.ini
     AppPath:     /usr/local/sbin/gitea
     AppWorkPath: /usr/local/sbin

2020/10/05 02:31:58 main.go:111:main() [F] Failed to run app with [gitea manager -c /etc/gitea/app.ini flush-queues --debug]: flag provided but not defined: -debug

It seems, that there is no --debug parameter available for gitea manager and also it was recognised in a wrong way: -debug. In general, there is no such parameter:

gitea --help
NAME:
   Gitea - A painless self-hosted Git service

USAGE:
   gitea [global options] command [command options] [arguments...]

VERSION:
   1.12.5 built with GNU Make 4.1, go1.14.9 : bindata, sqlite, sqlite_unlock_notify

DESCRIPTION:
   By default, gitea will start serving using the webserver with no
arguments - which can alternatively be run by running the subcommand web.

COMMANDS:
     web       Start Gitea web server
     serv      This command should only be called by SSH shell
     hook      Delegate commands to corresponding Git hooks
     dump      Dump Gitea files and database
     cert      Generate self-signed certificate
     admin     Command line interface to perform common administrative operations
     generate  Command line interface for running generators
     migrate   Migrate the database
     keys      This command queries the Gitea database to get the authorized command for a given ssh key fingerprint
     convert   Convert the database
     doctor    Diagnose problems
     manager   Manage the running gitea process
     embedded  Extract embedded resources
     help, h   Shows a list of commands or help for one command

GLOBAL OPTIONS:
   --port value, -p value         Temporary port number to prevent conflict (default: "3000")
   --pid value, -P value          Custom pid file path (default: "/var/run/gitea.pid")
   --custom-path value, -C value  Custom path file path (default: "/usr/local/sbin/custom")
   --config value, -c value       Custom configuration file path (default: "/usr/local/sbin/custom/conf/app.ini")
   --version, -v                  print the version
   --work-path value, -w value    Set the gitea working path (default: "/usr/local/sbin")
   --help, -h                     show help

DEFAULT CONFIGURATION:
     CustomPath:  /usr/local/sbin/custom
     CustomConf:  /usr/local/sbin/custom/conf/app.ini
     AppPath:     /usr/local/sbin/gitea
     AppWorkPath: /usr/local/sbin

Without --debug, Gitea just exits with exit code 1:

$ gitea manager -c /etc/gitea/app.ini flush-queues
$ echo "${?}"
1

Edit - 20201005 - 0518:

I found the issue. I have to execute gitea manager flush-queues as the user gitea, since the process was also started with this user.

$ ps aux | grep "gitea"
[...]
gitea      646  0.0 18.4 1534440 193968 ?      Ssl  02:35   0:08 /usr/local/sbin/gitea web --config /etc/gitea/app.ini

$ su - gitea
$ printenv GITEA_CUSTOM GITEA_WORK_DIR
/etc/gitea/
/var/lib/gitea/
$ gitea manager flush-queues
Flushed

/var/log/gitea/gitea.log

[...]
2020/10/05 03:41:31 ...s/context/context.go:330:func1() [D] Session ID: <some_session_id>
2020/10/05 03:41:31 ...s/context/context.go:331:func1() [D] CSRF Token: <some_token>

I always executed the commands as the user root without setting the environment variables accordingly.

Is it safe, to flush queues with root privileges or is it better to use the respective user for this?

[zeripath]

All flush-queues does is connect to the Gitea server on an internal web endpoint.

It simply needs the correct environment and the correct config. It doesn't matter which user calls it - it would likely be safe as root.

I didn't realise that you were on 1.12, 1.13 will have better debugging and should give you a better report of the error - I'm not certain what could have been going wrong there. (I'd also forgotten that flush-queues was in 1.12!)

[keks24]

Alright!

So, I should be able to execute one of the following commands as user root, right? This should set the environment variables at runtime:

$ gitea manager flush-queues --custom-path="/etc/gitea/" --work-path="/var/lib/gitea/" --config="/etc/gitea/app.ini"
$ gitea manager flush-queues --custom-path "/etc/gitea/" --work-path "/var/lib/gitea/" --config "/etc/gitea/app.ini"
$ gitea manager flush-queues -C "/etc/gitea/" -w "/var/lib/gitea/" -c "/etc/gitea/app.ini"
$ gitea manager flush-queues -C /etc/gitea/ -w /var/lib/gitea/ -c /etc/gitea/app.ini
$ gitea manager flush-queues -C /etc/gitea -w /var/lib/gitea -c /etc/gitea/app.ini

I am trying to mimic the configuration of /etc/systemd/system/gitea.service, which I also get from gitea --help as user gitea:

$ su - gitea
$ gitea --help
[...]
DEFAULT CONFIGURATION:
     CustomPath:  /etc/gitea/ (GITEA_CUSTOM)
     CustomConf:  /etc/gitea/conf/app.ini
     AppPath:     /usr/local/sbin/gitea
     AppWorkPath: /var/lib/gitea/
$ logout

But it does not work. It just exits again:

$ echo "${?}"
1

Even exporting the variables does not solve this:

$ export GITEA_CUSTOM="/etc/gitea/"
$ export GITEA_WORK_DIR="/var/lib/gitea/"

I am blind right now and cannot see what I am missing.

[zeripath]

A log.Fatal is, in all likelihood, occurring within setting.NewContext - which because the console logger has been completely disabled - is not appearing.

I don't know where or which but that's why I've put the --debug option on 1.13.

Thinking on the correct thing to do is probably not to delete the console logger but set it to still print out fatals (See #13032). However, that won't be backportable really.

[keks24]

A log.Fatal is, in all likelihood, occurring within setting.NewContext - which because the console logger has been completely disable is not appearing.

I don't know where or which but that's why I've put the --debug option on 1.13.

Thinking on the correct thing to do is probably not to delete the console logger but set it to still print out fatals (See #13032). However, that won't be backportable really.

Fair enough.

I would not expect to have a backport or something, since it would cause more work to maintain Gitea.

I will keep the current solution to run the command as gitea and meanwhile I will investigate how to flush queues with another user. :)

Thank you for your efforts!

By the way:
Do I have to create an issue at awesome-gitea, so my repository gets added there or is this issue sufficient?