Gitea A painless self-hosted Git service

What do you think about making redis work? Or at least build gitea with the possibility to use it.
A nethserver-redis module exists:

Seems to be just a config entry:

https://docs.gitea.io/en-us/config-cheat-sheet/

sample.app.ini: (version 1.4.3)

To use redis or memcache, be sure to rebuild everything with build tags redis or
'memcache:go build -tags=‘redis’`

Those Build Tags never worked for me and never found documentation on building it with redis/memcached support, only the hint in the sample app.ini.

This “hint” is removed in 1.5.0:

Suggesting it has this support by default…?..:thinking:

It’s working! You don’t need a password which was my fault (late night copy/paste error):

I used db=2 because db 0 was already populated on my test machine.

[cache]
ADAPTER = redis
INTERVAL = 60
HOST = network=tcp,addr=127.0.0.1:6379,db=2,pool_size=100,idle_timeout=180
ITEM_TTL = 16h

After restarting gitea and logging in to the web UI the db2 gets filled, before there was no db2:

[root@testvm2 ~]# redis-cli INFO | grep ^db
db0:keys=37,expires=1,avg_ttl=55923
db2:keys=2,expires=1,avg_ttl=57596747

EDIT:

If you leave the db=, then db0 is used.

Nice! :+1: worked for me too, sort-off do not see cache populated. But it does not crash as before.

Leave us with how to move on ? :grinning:

Question for me is: in which user-cases it really boosts performance? to be frank, i have no clue…

And how to implement it

(a) simple implementation / hard setup:
Regard it to be an advanced feature which may be setup manually. This implies one extra db prop for the CacheHost

(b) simple full templated setup / hard implemetation:
In this case we should probably start a dedicated redis instance (ie redis-giitea.service) …?
And add the nethserver-redis dependency.

(a) does not exclude (b) in an (future) updated version.

1 Like

Me too. Maybe it makes sense on raspberry or with many projects and repositories.

IMHO this is the way to go for now and if we see it has advantages we could always decide to implement method (b).

BTW, I did some research of redis vs memchached and it seems like redis has more features and is more flexible.

1 Like

Me too… from my reads redis is regarded superior and modern.

will implement (a) for now, thanx !

1 Like
  • built
  • installed

gitea process is running and the DB has been initialized!

Great job @mark_nl! What can I do now?

1 Like

Thanx,

You probably had a brief look at the package, so if you find something wrong let me know.

And who decides it is good enough for NethFrog testing?

Wonder if my pub.key is still installed…

1 Like

Pushed it to nethforge-testing :grinning:

Kudos to @danb35 @dnutan @mrmarkuz !

To install and evaluate :

yum install --enablerepo=nethforge-testing nethserver-gitea

local admin = gitea
password = gitea

Nethersever users must login in with the short username.

Initial documentation

Happy to hear remarks, comments, quirks and bugs !

4 Likes

Late to the party. You made a great job guys. Kudos :smile:

2 Likes

First, thanks for your effort and patience with my domain requests…

When you set the virtualhost and uninstall nethserver-gitea the /etc/httpd/conf.d/zz_gitea.conf isn’t deleted and still points to files that are not there anymore:

   SSLCertificateFile "/etc/pki/gitea/certs/gitea.crt"
   SSLCertificateKeyFile "/etc/pki/gitea/private/gitea.key"

what causes httpd to not (re)start:

Sep 06 14:28:14 testvm2.domain.local httpd[6543]: AH00526: Syntax error on line 32 of /etc/httpd/conf.d/zz_gitea.conf:
Sep 06 14:28:14 testvm2.domain.local httpd[6543]: SSLCertificateFile: file '/etc/pki/gitea/certs/gitea.crt' does not exist or is empty

Another question: Is it possible to set a custom gitea mail from address?

2 Likes

you mean here, right?

[mailer]
ENABLED = true
FROM = gitea@example.con
USE_SENDMAIL = true
SENDMAIL_PATH = /usr/sbin/sendmail

If we add a db-prop for it we can ! (in next release oke?)

Good point it happens more…

I can remove it by adding
rm -f /etc/httpd/conf.d/zz_gitea.conf
or
mv /etc/httpd/conf.d/zz_gitea.conf.rpmsave
in the spec at %postun

Actually i do not know the convention for this :open_mouth:

1 Like

Is this oke to remove the configuration file?

%postun
if [ $1 == 0 ]; then
  /usr/bin/rm -f /etc/httpd/conf.d/zz_gitea.conf > /dev/null 2>&1
  /usr/bin/systemctl reload httpd
fi

Or is there an e-smith method to do this?

Asking the big guns now
cc/ @giacomo @davidep

1 Like

Good question… I rarely (never) found the need of cleaning up during package removal. The %postun script above shouldn’t harm!

Please note that if the .conf file is not a template/RPM config file, it is removed by RPM itself. When a nethserver package is removed, the “update” events of all remaining packages are fired, so httpd is fully restarted.

1 Like

IIUC:

if a dummy/etc/httpd/conf.d/zz_gitea.conf (which gets overwritten at template expansion) is in the package it is removed by RPM.

/usr/bin/systemctl reload httpd is not needed: the update event after removal takes care of this.

Just to be sure at package removal (not update) may keep:

%postun
if [ $1 == 0 ]; then
  /usr/bin/rm -f /etc/httpd/conf.d/zz_gitea.conf > /dev/null 2>&1
fi

EDIT:

Know one possible suspect:

2 Likes

Cleaning up /etc/httpd/conf.d seems to be a good idea in general because even if NS cert is used and httpd throws no error some unneeded virtualhost/reverseproxy stays there.

This leads to another question: Is there a special reason to use an own certificate for gitea? It seems to work If you just use the NS cert/key, I tried git push to HTTPS and it worked:

   SSLCertificateFile "/etc/pki/tls/certs/localhost.crt"
   SSLCertificateKeyFile "/etc/pki/tls/private/localhost.key" 

It’s a result of my interpretation off :

A certificate consumer daemon should expand those templates to its own certificate paths, by installing the proper configuration under /etc/e-smith/templates.metadata.

http://docs.nethserver.org/projects/nethserver-devel/en/latest/certificate_management.html

And that interpretation be wrong…

Honestly, I don’t know if it means that you have to create an own cert for using same httpd (which may not be another daemon in this case). :thinking:

Good point ! the httpd is not run as gitia and should (?) use the localhost cert.

Gitea may require a certificate, although we actually do not seem use it (not sure about this…) as gitea listens on http://localhost:5321.

Yes, it seems giteas built in server can use an own cert but we use reverse proxy:

https://docs.gitea.io/en-us/https-setup/