thomas-maurice / ansible-role-gitea Goto Github PK

I suspect the version check PR introduced things the linter didnt like very much

• E601: Don't compare to literal True/False
• E306: Shells that use pipes should set the pipefail option

That should be fixed at some point.

LFS_CONTENT_PATH and LFS_JWT_SECRET appear multiple times in the config.

And there are different ansible variables that will define the same secret (LFS_JWT_SECRET)

Hi!

I've mostly used default settings on my ubuntu 18.04 instance.
Database should be sqlite3 and gitea also see it as that.

Problem comes when I use
/usr/local/bin/gitea dump -c /etc/gitea/gitea.ini

and then try to restore then it fails.
Weird part is that true and false don’t exist in SQLite3 and it contains in the dump.

Hi!

I am trying to install gitea on ubuntu 18.04.

After trying to start the service I get

gitea.service: Failed to reset devices.list: Operation not permitted

Any clue how to solve it?

I just noticed that the backup can't work like this. The folder /var/backups/ belongs to the user root on my system (debian 10).

My suggestion would be here once to design the backup as opt-in. and then also the backup path on the the one hand to design as variable, on the other hand with access authorization for the gitea user.

cmd/dump.go:171:fatal() [F] Unable to open gitea-dump-1613185611.zip: open gitea-dump-1613185611.zip: permission denied

By performing git via ssh I got this error:

$ git pull
fatal: Konnte nicht vom Remote-Repository lesen.

Bitte stellen Sie sicher, dass die korrekten Zugriffsberechtigungen bestehen
und das Repository existiert.

If I just try to ssh directly to the gitea server as user gitea, I got the error

PTY allocation request failed on channel 0
Connection to gitea.localhost closed.

I fixed the error by giving the user gitea a shell (/bin/bash) instead of /bin/false.

And now git over ssh works like usual.

And if I know ssh directly to the host, it looks usual to me:

$ ssh [email protected]
PTY allocation request failed on channel 0
Hi there, You've successfully authenticated, but Gitea does not provide shell access.
If this is unexpected, please log in with password and setup Gitea under another user.
Connection to gitea.localhost closed.

I changed it here: DO1JLR@c8602dd
Should I create a pull request or is this probably a issue with the ssh roles I use (add users + keys and configure sshd)

Hi Thomas,

thanks for this role, it is awesome and really helpful in maintaining my Gitea server.

One small request I have is to implement versioning and tagging for this role. It would be good if it would be possible to deploy a known working or older version for some scenarios.

Thanks!

Hi,

Just deployed this Gitea role, with the following variables set in group_vars:

gitea_version: "1.16.7"
gitea_home: /opt/data/gitea
gitea_http_domain: gitea.mydomain.com
gitea_ssh_domain: gitea.mydomain.com
# gitea_http_listen: 10.10.1.10
gitea_http_listen: 0.0.0.0
gitea_ssh_port: 2223
# gitea_root_url: https://gitea.mydomain.com:3000
gitea_root_url: https://gitea.mydomain.com
gitea_protocol: https

But after execution, I am only able to access port 2223 (telnet), but not port 3000. No firewall loaded/running.

root@control:~# netstat -tlpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 10.10.1.10:53           0.0.0.0:*               LISTEN      14010/named
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      618/systemd-resolve
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      1339/sshd: /usr/sbi
tcp        0      0 127.0.0.1:953           0.0.0.0:*               LISTEN      14010/named
tcp6       0      0 :::2223                 :::*                    LISTEN      25255/gitea
tcp6       0      0 ::1:53                  :::*                    LISTEN      14010/named
tcp6       0      0 :::22                   :::*                    LISTEN      1339/sshd: /usr/sbi
tcp6       0      0 ::1:953                 :::*                    LISTEN      14010/named
root@control:~# curl https://gitea.mydomain.com:3000
curl: (7) Failed to connect to gitea.mydomain.com port 3000: Connection refused
root@control:~# curl https://localhost:3000
curl: (7) Failed to connect to localhost port 3000: Connection refused
root@control:~# ping gitea.mydomain.com
PING control01.mydomain.com (10.10.1.10) 56(84) bytes of data.
64 bytes from control (10.10.1.10): icmp_seq=1 ttl=64 time=0.075 ms
^C
--- control01.mydomain.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.075/0.075/0.075/0.000 ms
root@control:~#

Running Ubuntu 20.04. What am I doing wrong? (I am not using a Web proxy)

Although I modified the the playbook for my needs, I think this will still apply also on an unmodified playbook.

Somehow the task "Configure gitea" is not idempotent (not sure why, because it basically just copies a file generated from the config template). Because of this, the deamon-restart gets notified every time, and the service is also restarted every time.

I use ansible 2.9.6 on ubuntu 20.04 from the ubuntu repos (both, server and client are ubuntu 20.04)

HI,
First, great work for this role. It works perfectly.

It would be great to have the possibility to configure gitea to retrieve user identity from a OpenID Connect provider . This is a functionality support by Gitea natively.

thx

there are to endif blocks in templates/gitea.ini.j2 but just one if

if: L 56
endif: L 63
endif: L 69

this leads to templating errors and seems to be in current master as well as v0.0.0
i think deleting the one in L63 should be right.

thanks for all the work you are putting into this, greatly appreciate it
Cheers,
Steffen

Gitea has been updated more often lately. And the practice of updating it every time in this role can be done... But it doesn't seem to make that much sense in the long run.

What do you think about extending this ansible role by adding some magic that automatically downloads the newest gitea version? For example by evaluating a curl on https://github.com/go-gitea/gitea/releases/latest...

Of course the variable gitea_version: 1.12.1 should still be valid. But if you write something like gitea_version: latest, a download of the latest version would be nice.

Or what do you think?

In order to set the MAILER_TYPE = sendmail in the config, it is necessary to define it as variable as all changes in gitea.ini will be overwritten by ansible.

The key server used to retrieve the key (keyserver.ubuntu.com) for the signature answers to a query for the gitea key with "not found", thus the task "Download gitea asc file" in install.yml fails.

The keyserver should be changed to one that has the key. I used keys.gnupg.org, but not sure which server is the most reliable. Maybe the official key server that gitea uses should be used for this role as well.

some ppl are using havily git lfs (may for podcasts or something like this) and are not hosting it on there own server..
you can specify such things in gitea, but it then need also ansible vars/

The version check command with set -eo pipefail fails silently.

Relevant output of ansible -vvv on Debian Buster:

"msg": "non-zero return code",
"rc": 2,
"start": "2020-06-15 02:59:18.807048",
"stderr": "/bin/sh: 1: set: Illegal option -o pipefail",
"stderr_lines": [  
"/bin/sh: 1: set: Illegal option -o pipefail" 
],

The problem was already discussed in ansible/ansible-lint#497.

Short: there is no guarantee which shell Ansible uses on which distro and -o pipefail is not likely to be supported.
The solution could be leaving it out or using suggestion from ansible/ansible-lint#497 (comment).

Despite pipefail being best practice, I tend to support the former. Having checks for bash, although likely to be present, require bash to be installed.