Gitea A painless self-hosted Git service

[mrmarkuz (Markus Neuberger)]

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

NethServer/nethserver-redis

Seems to be just a config entry:

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

[mark_nl (Mark Verlinde)]

@mrmarkuz

Or at least build gitea with the possibility to use it.
A nethserver-redis module exists:

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:

remove build tag information for redis and memcache from docs

Suggesting it has this support by default…?..

[mrmarkuz (Markus Neuberger)]

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.

[mark_nl (Mark Verlinde)]

@mrmarkuz

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.

Nice! 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 ?

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.

[mrmarkuz (Markus Neuberger)]

@mark_nl

in which user-cases it really boosts performance? to be frank, i have no clue…

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

10 Advantages of Redis - DZone

@mark_nl

Regard it to be an advanced feature which may be setup manually. This implies one extra db prop for the CacheHost

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.

[mark_nl (Mark Verlinde)]

@mrmarkuz

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

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

will implement (a) for now, thanx !

[davidep (Davide Principi)]

• built
• installed

gitea process is running and the DB has been initialized!

Great job @mark_nl! What can I do now?

[mark_nl (Mark Verlinde)]

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…

[mark_nl (Mark Verlinde)]

Pushed it to nethforge-testing

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 !

[alefattorini (Alessio Fattorini)]

@mark_nl

Pushed it to nethforge-testing

Kudos to @danb35 @dnutan @mrmarkuz !

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

[mrmarkuz (Markus Neuberger)]

@mark_nl

Happy to hear remarks, comments, quirks and bugs !

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?

[mark_nl (Mark Verlinde)]

@mrmarkuz

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

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?)

@mrmarkuz

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:

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

[mark_nl (Mark Verlinde)]

@mark_nl

Actually i do not know the convention for this

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

[davidep (Davide Principi)]

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.

[mark_nl (Mark Verlinde)]

@davidep

the “update” events of all remaining packages are fired, so httpd is fully restarted.

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:

@davidep

rarely (never) found the need of cleaning up during package removal

Know one possible suspect:

SOGO CalDav is not running - but Webtop CalDav

problem solved The following conf files of Webtop5 were available in /etc/httpd/conf.d/: webtop5-webdav.conf webtop.conf I removed them and let the httpd configuration update, then everything ran again. Annoying such problems! I had until 2 days ago both for testing installed, now only SOGO is installed. When uninstalling, they were apparently not removed - that curious that as long as webtop5 was installed, there were no problems.

[mrmarkuz (Markus Neuberger)]

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" 

[mark_nl (Mark Verlinde)]

@mrmarkuz

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:

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…

[mrmarkuz (Markus Neuberger)]

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).

[mark_nl (Mark Verlinde)]

@mrmarkuz

not be another daemon in this case

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.

[mrmarkuz (Markus Neuberger)]

@mark_nl

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 setup | Gitea Documentation