Talk:Gitea

PostgreSQL draft

Latest comment: 1 November 20183 comments3 people in discussion

Install and configure and start the PostgreSQL, then do this to create gitea user and db:

1. Switch to posgres user:

$ sudo -u postgres -i

2. Start create db wizzard (TODO add explanation why not superuser):

[postgres]$ createuser --interactive
name: gitea
superuser: no

3. then createdb named gitea using gitea user (its ok to launch the createdb command as regular user as well)

[postgres]$ createdb gitea -U gitea

4. then try access the the DB via localhost, cause that's how the gittea will try to access it

[postgres]$ psql -d gitea -U gitea -h 127.0.0.1 -W (connect to gitea db as gitea user, host localhost and -W without anything for empty password)

Now to edit the /etc/gitea/app.ini

Default PostgreSQL port is 5432 if you haven't changed it

/etc/gitea/app.ini

[database]
DB_TYPE = postgres
HOST = 127.0.0.1;5432
NAME = gitea
PASSWD = 
USER = postgres
SSL_MODE = disable

TODO setup a password, SSL_MODE wanted?
TODO using localhost:port might be unsecure, better to connect directly at the socket (in "/run/postgresql");
- (try connecting to db psql -d gitea -U gitea and typing \conninfo for details)

Pulec (talk) 01:00, 2 July 2018 (UTC)Reply[reply]

Please sign your posts. :)

Any recommendations from Gitea/Gogs for setting up PostgreSQL?

Francoism (talk) 09:38, 24 June 2018 (UTC)Reply[reply]

Wrote something based on my setup and my previous experience with Mattermost

Archange (talk) 16:29, 1 November 2018 (UTC)Reply[reply]

Upgrading to gitea version >= 1.5 mariadb

The solution in the article seems not to ultimatively solve the problem with the database.

For "set global innodb_large_prefix = `ON`;" to have an effect, the ROW_FORMAT of the table has to be DYNAMIC or COMPRESSED (https://stackoverflow.com/questions/24321896/mysql-row-format-compressed-vs-dynamic) ,to be able to set the ROW_FORMAT to either DYNAMIC or COMPRESSED the file format has to be at least BARRACUDA (https://mariadb.com/kb/en/library/xtradbinnodb-storage-formats/).

For me to get gitea >= 1.5 working with mariadb < 10.2 I first added those four lines to the mariadb config

/etc/mysql/my.cnf

[mysqld]
innodb_file_format = barracuda
innodb_file_per_table = 1
innodb_large_prefix = 1

Then I started gitea >= 1.5 which still resulted in a bunch of errors concerning the key length;

To change the ROW_FORMAT on all tables in the gitea database I run a slightly adapted (to my needs) bash script taken from (https://lxadm.com/MySQL:_changing_ROW_FORMAT_to_DYNAMIC_or_COMPRESSED)

#!/bin/bash

DATABASE=gitea

ROW_FORMAT=DYNAMIC

TABLES=$(echo SHOW TABLES | mysql -s $DATABASE)

for TABLE in $TABLES ; do
    echo "ALTER TABLE $TABLE ROW_FORMAT=$ROW_FORMAT;"
    echo "ALTER TABLE \`$TABLE\` ROW_FORMAT=$ROW_FORMAT" | mysql $DATABASE
done

The escaped back quotes are necessary since one table in the database is called RELEASE which is a reserved word within mysql. You probably will have to run the script multiple times since after each run gitea will add new tables to the database depending on which tables already have been converted to ROW_FORMAT DYNAMIC. If you cannot access your db without a password you have to adapt the mysql command in the for loop accordingly

You can check if all tables have been converted

mysql -u root -p

MariaDB [(none)]> use gitea;
MariaDB [gitea]> show table status;

max key length is 767 bytes

Latest comment: 12 December 20181 comment1 person in discussion

gitea-1.5.1-1-x86_64.pkg.tar.xz

I am using local/mariadb 10.1.36-1

and when creating the DB like in the wiki with

CREATE DATABASE `gitea` DEFAULT CHARACTER SET `utf8mb4` COLLATE `utf8mb4_unicode_ci`;

i get an error at the install page:

Datenbankeinstellungen sind ungültig: Error 1071: Specified key was too long; max key length is 767 bytes

if i change it to:

CREATE DATABASE `gitea` DEFAULT CHARACTER SET `utf8` COLLATE `utf8_general_ci`;

everything works as expected.

MariaDB

As described in the workaround link, I successfully installed Gitea on MariaDB by altering /etc/mysql/my.cnf

I simply added three settings.

/etc/mysql/my.cnf

######################################
## Fixing Gitea installation issues ##
######################################
innodb_default_row_format = dynamic
innodb_file_format = Barracuda
innodb_large_prefix = 1
######################################

Bebedizo (talk) 09:28, 12 December 2018 (UTC)Reply[reply]

Apache Reverse Proxy Over Unix Socket

Latest comment: 12 December 20181 comment1 person in discussion

I have the following settings in my VirtualHost directive of Apache 2.4 - and things seem to work.

However, I am not an expert on (reverse) proxies, so I regard this as a starting point for further investigation, e.g. the part with http:// looks awkward.

some-vhost.conf

<VirtualHost *:443>
   ...
   AllowEncodedSlashes NoDecode
   <Location />
      Require all granted
      ProxyPass unix:/run/gitea/gitea.socket|http://127.0.0.1:3000/
      ProxyPassReverse unix:/run/gitea/gitea.socket|http://127.0.0.1:3000/
   </Location>
   ...
</VirtualHost>

Bebedizo (talk) 09:45, 12 December 2018 (UTC)Reply[reply]

Apache Reverse Proxy with gitea in subfolder

Gitea within a subfolder of the apache document root. This means my URL is https://foo.bar and gitea is reachable via https://foo.bar/git:

subfolders/gitea.conf

<Proxy *>
    Order allow,deny
    Allow from all
</Proxy>
SSLProxyEngine On
SSLProxyCheckPeerCN Off
ProxyPass /git https://localhost:3000
ProxyPassReverse /git https://localhost:3000

Use full absolute path with LFS_CONTENT_PATH

Latest comment: 25 August 20191 comment1 person in discussion

I updated my app.ini from the pacnew of 1.9.x-ish release and noticed git ssh:// access was broken. Further investigation revealed that the default LFS_CONTENT_PATH=data/lfs in the updated default app.ini.pacnew was the cause of the breakage.
In my old app.ini from 1.8.3 it was LFS_CONTENT_PATH=/var/lib/gitea/data/lfs which didn't come from the upstream release nor from PKGBUILD's gitea-arch-defaults.patch. I suspect the gitea server set it during the initial config but didn't confirmed it so I'm posting this in the discussion page. Tinywrkb (talk) 23:23, 25 August 2019 (UTC)Reply[reply]

Erroneous Bash executable path entry causes SSH login error

Latest comment: 22 December 20191 comment1 person in discussion

The default install of gitea added an incorrect entry to /etc/passwd

/etc/passwd

gitea:x:986:986:Gitea daemon user:/var/lib/gitea:/usr/bin/bash

sshd with UsePAM enabled will fail mysteriously as seen with

journalctl -u sshd -f

PAM: Authentication failure for gitea from [ip address:port]

To solve this, I corrected the Bash path.

/etc/passwd

gitea:x:986:986:Gitea daemon user:/var/lib/gitea:/bin/bash

Agentxp22 (talk) 13:41, 22 December 2019 (UTC)Reply[reply]

Panic on last update (community/gitea 1.11.3-2)

Latest comment: 31 March 20201 comment1 person in discussion

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

Getting this error with last update. Many issues reference this but could not find a solution for the moment.

https://github.com/go-gitea/gitea/issues?q=is%3Aissue+panic+locale+is%3Aclosed

Conf file is at /etc/gitea/app.ini Gitea user is at /var/lib/gitea Assets are at /usr/share/gitea (the locale file is at /usr/share/gitea/options/locale)

Temporarily fixed it by pointing /var/lib/gitea/conf to /usr/share/gitea/options with a symlink. Now the service starts but the web service replies with html/template: "home" is undefined and is unusable. SSH push/pull is functional.

EDIT: OK see [bug tracked here](https://bugs.archlinux.org/task/66011). Temporary fix by setting STATIC_ROOT_PATH = /usr/share/gitea in /etc/gitea/app.ini. This makes everything work again.

aureooms (talk) 07:40, 31 March 2020 (UTC)Reply[reply]

Gitea in a subfolder with nginx

There are some slight differences (trailing slashes) for running gitea in a subfolder rather than at the top domain, e.g. https://sub.domain.tld/gitea. Info found here: https://www.thedroneely.com/posts/gitea-in-a-sub-directory-with-nginx/

nginx /etc/nginx/nginx.conf (or included file that has the gitea location block) needs

location /gitea/ {
     proxy_pass http://unix:/run/gitea/gitea.socket:/;
}

While gitea's /etc/gitea/app.ini needs the trailing slash in DOMAIN and ROOT_URL, i.e. DOMAIN = https://sub.domain.tld/gitea/.

If only the root document loads, but not the assets, try adding :$uri to proxy_pass:

/etc/nginx/servers-available/gitea.conf

location /git/ {
    # make nginx use unescaped URI, keep "%2F" as is
    rewrite ^ $request_uri;
    rewrite ^/git(/.*) $1 break;

    proxy_pass http://unix:/run/gitea/gitea.socket:$uri;
    ...
}

read-only file system

Latest comment: 7 May 20221 comment1 person in discussion

As per this issue https://github.com/go-gitea/gitea/issues/6160 I was also getting the read-only file system error in the log when attempting to create a repo just after an initial setup. Whilst also using a custom path for ROOT, as per the solution mentioned in the link the following corrected the problem:

systemctl edit gitea

Then added override

[Service]
ReadWritePaths=/etc/gitea/app.ini /my/path/to/gitea/data

--Jamesp9 (talk) 14:43, 7 May 2022 (UTC)Reply[reply]

Transition to Forgejo

Latest comment: 10 January 20231 comment1 person in discussion

What is the plan for a transition of Gitea to Forgejo? There is an AUR package already. There is now a Forgejo package, the gitea package maintainer told me there is no plan to transition gitea to forgejo, so this has to be done manually. --Utzer (talk) 14:44, 10 January 2023 (UTC)Reply[reply]