Github on tuttu jokaiselle, joka on tehnyt mitä tahansa IT-asioiden tai koodauksen kanssa. Se on sivusto, jossa voidaan tehdä koodausta tai oikeastaan mitä tahansa, joka perustuu tekstiin, yhdessä ja erikseen. Jos olet googlettanut websivuston asetuksia tai pientä ohjelmanpätkää – tai isompaa – niin se löytyy aina projektina Guthubista. Vastaavia muitakin on, kuten Bitbucket tai Gitlab, mutta Github lienee suurin. Vastaavan saa omallekin sivustolle, oikeammin lähes mihin tahansa ympäristöön, jos haluaa pitää langat omissa käsissään.

Gitean dokumentaation löydät osoitteesta https://docs.gitea.io/en-us/

Yleistä ihmettelyä Githubistakin

Oikeammin git on tapa tehdä versiokontrollia. Se ei siis ole mikään ohjelmointi- tai kirjoitustyökalu. Eniten käytetty verkkokoulutusympäristö Moodle kehitetään ja päivitetään Githubin kautta git-ympäristössä, jolloin voi valita minkä version haluaa ottaa käyttöön. Moodle on vain esimerkki ja vastaavia on lukuisia.

Github on laajassa käytössä myös koodin jakamisessa, vaikka se onkin rajua alikäyttöä. Mutta on paljon helpompaa laittaa koodi vaikka Githubiin ja linkittää se sieltä, kuin kopypeistata omaan teksiin ja luottaa, että muotoilut säilyvät eikä html raiskaa oleellisia erikoismerkkejä. Itse käytän sitä juurikin moiseen, koodari kun en ole enkä tee töitä työryhmäpohjaisesti.

Github on toimiva palvelu. Mutta se on ulkoinen palvelu. Joskus on tarpeen pitää hallinta itsellään ja asiat eräällä tavalla perhepiirissä. Silloin tarvitsee vastaavan systeemin, mutta itse ylläpudettynä. Tarjontaa löytyy hieman ja kohtuullisen yleinen, sekä ulkoisesti ja toiminnoiltaan hyvin paljon Githubin tapainen on Gitea.

Mutta suoraan sanottuna… aika harvan kannattaa nähdä vaivaa asentaa se. Minä otin Gitean käyttöön, mutta enemmältikin puhtaasta uteliaisuudesta – ja osaksi ikiomaksi hiekkalaatikoksi, jossa voin harjoitella aihetta git. Suurimmalle osalle Github antaa sen mitä tarvitaan ilman taloudellisia panostuksia – asentaminen, ylläpito ja ylipäätään työ kun ovat taloudellisia panoksia.

Kannattaa miettiä mihin tarkoitukseen Gitean asentaisi. Jos ajatuksissa on kerätä käyntejä sivustolle tarjoamalla Githubille vaihtoehdon, niin ajatus kannattaa haudata ennenkuin se edes itää. Gitean pyörittäminen alkaa äkkiä maksamaan puhdasta rahaa, koska konetehoa ja muistia palaa. Kaupallistaminen sen sijaan on vaikeaa, jopa mahdotonta, koska muut toteuttavat ratkaisunsa ulkoisella rahoituksella ja isommalla työvoimalla.

Koska isot toimijat tekevät asiat kaikessa paremmin, niin omalle vapaalle toteutukselle riittäisi enää ne käyttäjät, joita kukaan ei halua. Kuten arveluttavien koodien ja salasanalistojen jakelijat. Silloin oma git-repo muuttuukin eräällä tavalla pahantahtoisten suosimaksi avoimeksi releeksi. Joten rekisteröityminen kannattaa pitää adminin hallussa.

Mutta jos ajatuksissa on tehdä itselleen, ja mahdolliselle omalle ryhmälle, versionhallinnan omassa hallinnassa, niin pelikenttä muuttuu täysin. Silloin Gitea on hyvinkin harkitsemisen arvoinen vaihtoehto.

Työkalu julkaisuun

Minun kaltaiselleni Githubin alikäyttäjälle Gitea vie yhden oleellisen edun: upotuksen. Voin kopioida gistin (lyhyt Githubin koodinpätkä, jonka kanssa ei tehdä kehitystyötä eikä tarvita versiokontrollia) urlin WordPressin tekstiin ja koodi näkyy. Toki tarvitsen siihen pluginin, joka on muuten hylätty eikä päivity enää, mutta toimii silti, mutta Gitean kanssa ei ole edes sitä. Ainoa tapa on vanhanaikainen linkitys ja pakottaa kävijä pois tekstistä katsomaan vaikka jotain lyhyttä functions.php tiedoston tuunausta.

Saan kuitenkin Giteasta yhden selvän edun, joka sopii minunlaiselleni ja se on hieman parempi turvallisuus. Esittelen mm. Varnishin asetuksia Githubissa. Osaksi siksi, että aivan jokaisen ei tarvitsisi kahlata samoissa sameissa pohjamudissa kuin mitä itse olen edennyt. Osaksi siksi, että kun vahingossa tuhoan jotain, niin minulla on kopio muualla kuin omalla serverilläni. Mutta varsinainen turvallisuusaspekti tulee käyttäjämääristä.

Omassa asennuksessa on kyläilemässä joku joskus harvoin. Githubilla pyörii tuhansia ja tuhansia sekä botit päälle. Jos onnistuu vuotamaan jonkun tunnus/salasanaparin, kuten itselläni kerran lipsahti, niin sekunneissa joku on koittamassa onneaan. Minun pelastukseni oli kirjautumiseen vaadittava IP-osoite, mutta kun vahinko tapahtuu, niin seuraukset ovat välittömiä. Omassa järjestelmässä on enemmän aikaa korjauksiin ja vanhaa versiotietoa pystyy tuhoamaan ilman, että kaiken maailman script kiddiet kurkkivat koko ajan selän takana.

Käytän Githubia myös tekstien rakentamiseen, koska pääsen siihen käsiksi oikeastaan koska ja mistä tahansa. Sekä siinä versiokontrolli tulee aika ajoin vastaan: on tehnyt jonkun muutoksen, innostunut kirjoittamaan, poistanut osia ja parin päivän päästä huomaakin, että pieleen meni. Githubin avulla pääsen takaisin johonkin aikaisempaan tallennuspisteeseen.

Gitea antaa saman palvelun, mutta helpomman kontrollin siihen kuka näkee ja kuka voi myös muokata. Tai jos ei varsinaisesti helpomman, niin ainakin tunne siitä, että vastuu ja valta on itsellä, helpottaa. Ehkä.

Kun tekstirepon yhdistää iPadiin ja johonkin markdownia osaavaan editoriin, kuten vaikka Ulysses, joka osaa importin html:nä, niin aletaan olla tekstintuottamisessa sellaisessa työkalupakissa, että aika ja paikka eivät enää hidasta.

Puhumattakaan jos tekee sivuston kehitystöitä. On vaan helpompaa tehdä asioita omalla serverillä.

Sivusto ja virtual host

• Aivan ensimmäiseksi aseta serverisi nimitietueisiin A-tietue haluamallesi osoitteelle. Osannet tehdä sen itsekin, ja minulla se on git.eksis.one.

Ennen Gitean asennusta kannattaa laittaa virtual host kuntoon. Se, miten teet sen, riippuu tietysti siitä mitä webserveriä käytät. Itselläni on käytössä stakki Nginx – Varnish – Apache2, mutta Gitea omana palvelunaan tipauttaa Apachen pois kuvioista. en kuitenkaan saanut Varnishia cachettamaan yhtään mitään. Tuo lienee merkityksetöntä, koska en usko cachen paljoakaan auttavan Gitean kanssa – tosin, onhan suurin osa sisällöstä muuttumatonta. Siltä osin on ihan  sama vaikka käyttäisi pelkkää Nginxiä tai Apachea.

Itse käytän Varnishia myös muuhunkin, kuten sellaisen roskaliikenteen tappamiseen, joka ei pysähdy Nginxin suodatuksiin, joten pystyn elämään cacheamattoman Varnishin kanssa.

Osannet perusteet virtual hostin asettamisesta serverille, ja miten se otetaan käyttöön.

Nginx

Tehdään hyvin perusasennus Nginxille ja portille 80. SSL:n käyttöönoton jälkeen muutetaan virtual hostin asetuksia. Elämän helpottamiseksi tämä kannattaa tehdä, vaikka käyttäisin Varnishia. Kytky reverse proxyyn tehdään SSL-sertifikaatin hakemisen jälkeen.

server {
    listen 80;
    server_name git.example.tld;

    location / {
        http://unix:/var/run/gitea/gitea.sock;
    }
}

Jos asennat Gitean jo olevan sivuston hakemistoon, niin lisää sen virtual host conffiin tämä:

location /git/ { # Note: Trailing slash
        proxy_pass http://unix:/var/run/gitea/gitea.sock; # Note: Huomaa päättävä keno
    }

Apache2

Apache2:den pitäisi toimia tällä, mutta en ole koskaan koittanut itse:

<VirtualHost *:80>
    ...
    ProxyPreserveHost On
    ProxyRequests off
    AllowEncodedSlashes NoDecode
    ProxyPass / http://unix:/var/run/gitea/gitea.sock nocanon
    ProxyPassReverse / http://unix:/var/run/gitea/gitea.sock
</VirtualHost>

Ja hakemistolla tällä – myöskään tätä en ole kokeillut:

<VirtualHost *:80>
    ...
    <Proxy *>
         Order allow,deny
         Allow from all
    </Proxy>
    AllowEncodedSlashes NoDecode
    # Huomaa: ei päättävää kauttaviivaa hakemistoon /git eikä porttiin
    ProxyPass /git http://unix:/var/run/gitea/gitea.sock nocanon
    ProxyPassReverse /git http://unix:/var/run/gitea/gitea.sock
</VirtualHost>

• Sinun täytyy myös määrittää Gitean asetuksiin /etc/gitea/app.ini lohkoon [server] hakemiston polku:

ROOT_URL = https://www.example.tld/git/

Varnish

Varnishin muokkaukset voi ja kannattaa tehdä vasta sitten, kun SSL toimii, mutta toki asetukset (Nginxin muutoksia lukuunottamatta) voi tehdä valmiiksi. Eivät ne käyttöön kuitenkaan tulle ennenkuin Nginx päästää liikenteen Varnishille.

Varnish vaatii Gitealle oman backendin määrityksen. Lisää tiedostoon default.vcl muiden backendien määritysten jälkeen tämä:

backend gitea {
    .path = "/run/gitea/gitea.sock";
    .first_byte_timeout = 300s;
    .connect_timeout = 300s;
    .between_bytes_timeout = 300s;
}

Jos et käytä sockettia, niin määrittele host ja portti – se on joko tai, et voi käyttää molempia. Joten korvaa socketin .path tällä:

.host = "127.0.0.1";
.port = "3000";

Riippuen siitä miten määrittelet virtual hostien tarpeet, niin täytyy kertoa mitä backendiä käytät. Se tehdään kuitenkin aina periaatteiltaan samalla tavalla, mutta esimerkki perustuu siihen, että määrittelet jokaiselle virtual hostille oman vcl-tiedoston. Tuolla tavalla asiat ovat helpommin hallittavissa.

Virtual hostin rakenne olisi silloon tämän kaltainen, url tietysti muokattuna:

sub vcl_recv {
    if (req.http.host == "git.eksis.one") {
        set req.backend_hint = gitea;
...kaikenlaista...
    }
}

Nginxin virtual host ei paljoa muutu, on Vernish mukana tai ei. Mutta kun normaalisti olisi proxy_pass http://unix:/run/gitea/gitea.sock; tai proxy_pass http://127.0.0.1:3000; niin nyt kerrotaan ihan normaaliin tapaan missä Varnish kuuntelee – koska Varnish sitten ohjaa liikenteen Gitealle.

Joten virtual hostin juurihakemiston määrittely on tuttu huttua (vaihda tietysti Varnishin portti itsellesi oikeaksi):

location / {

        proxy_pass http://127.0.0.1:8080;
        #proxy_pass http://unix:/run/gitea/gitea.sock;
        proxy_set_header X-Real-IP  $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Forwarded-Port 443;
        proxy_set_header Host $host;
        proxy_pass_header Server;
    }

Koska minulla Varnish rakentuu itseasiassa kolmesta eri vcl_recv osiosta

• yleinen tiedostossa default.vcl, jonka tarkoitus on vain siivoilla pyyntöjä
• cookieiden muokkaamiseen all-common.vcl
• jokaiselle virtual hostille omansa, jossa tehdään sitten tarkemmat määrittelyt per sivusto

niin en tee cookie-hommia varsinaisesti default.vcl tiedostossa. Käytännössähän tuolla ei ole mitään merkitystä – sinulla saattaa kaikki olla default.vcl tiedostossa, minulla ne on vaan jaettu kolmeen.

Yleisin syy siihen, että Varnish ei cacheta, on juurikin cookiet. Kaikki sellaiset, jotka eivät vaikuta mitenkään backendin toimintaan, on siivottava. Tässä loppuu oma osaaminen. En nimittäon ymmärrä enkä osaa, joten menen kopypeistaamisella – joka on huomattavan helppo tapa tehdä asioita väärin.

Gitea asettaa ymmärtääkseni kolme evästettä, kun ei olla kirjauduttu:

• i_like_gitea (Gitean oma cookie)
• lang (muistaa kieliasetukset)
• _csrf (pitäisi estää cross site request forgery uhan)

Ymmärtääkseni ainoastaan lang pitäisi päästää backendiin saakka. Tosin silloin se estäisi cachen. Olen siitä huolimatta asettanut asioita näin:

# Gitea
   set req.http.Cookie = regsuball(req.http.Cookie, "lang=[^;]+(; )?", "");
   set req.http.Cookie = regsuball(req.http.Cookie, "i_like_gitea=[^;]+(; )?", "");
   set req.http.Cookie = regsuball(req.http.Cookie, "_csrf=[^;]+(; )?", "");

Tuo ilmeisesti ei toimi, koska cacheen ei mene mitään, jos liikkuu selaimella. Mutta jos kokeilee curl -I https://git.eksis.one/ niin cache toimii. En vaan tajua. Tajuamista heikentää sekin, että kun en ollut sulkenut Varnishin cachesta /users/ sivuja, eli mm. kirjautuminen, niin login ei toiminut – joka taasen on luotettava merkki siitä, että cache toimii.

Gitea ja asennus

Jos hallitset dockerin tai olet jossain muussa ympäristössä kuin Ubuntussa (tätä kirjoitettaessa 20.04), niin vilkaise asennusohjeet Gitean sivustolta. Minä menen helpoimman mukaan – tai ainakin se on helpoin itselleni.

Voit asentaa Gitean myös snap-komennolla. Koitin sitä. Ongelma on se, että snap asentaa sen eri hakemistoihin mihin perusasetukset olettavat. Ei tuo toki muuta tuo mukanaan kuin hieman säätämistä. Mutta jos käytät sitä, niin komento on:

snap install gitea

Koska Gitea on Go-kielellä tehty valmis binääri, niin se ei löydy apt install komennolla. Joten joudutaan käsitöihin – joka tulee tutuksi Gitean kanssa muutenkin, sillä se ei ole mikään UX-suunnittelun huippuesimerkki. Itseasiassa aivan tyypillinen tapaus  avoimen lähdekoodin maailmasta, jossa kehitystyö perustuu idealismiin ja vapaaehtoisiin, ei liiketoimintamalliin. Tai jos taustalta löytyisikin liiketoimintaa, niin se perustuu avaimet-käten-serveripalvelun pyörittämisestä. Gitean kohdalla en ihan ymmärrä miksi joku maksaisi erikseen Gitealle, kun saman, mutta laajemmin, saa Githubista.

Sivuhuomautuksena. Koska teen kaiken root-tunnuksella, niin en laita erikseen näkyviin sudo-komentoa. Jos olet liikkeellä tavallisella user-tunnuksella, niin tarvitset sudon melkein kaikkeen.

• Ensin täytyy tehdä käyttäjä, joka pyörittää Giteaa:

adduser \
   --system \
   --shell /bin/bash \
   --gecos 'Git Version Control' \
   --group \
   --disabled-password \
   --home /home/git \
   git

Tehdään tarvittava tietokanta (jos sinulla on joku muu kuin MariaDB/MySQL niin googleta). Kirjaudu tietokantaan komennolla mysql -u root (tai käyttämäsi tunnus ja perään -p salasana)

• Anna komennot:

SET old_passwords=0;
CREATE USER 'tunnus' IDENTIFIED BY 'salasana';
CREATE DATABASE tietokanta CHARACTER SET 'utf8mb4' COLLATE 'utf8mb4_unicode_ci';
GRANT ALL PRIVILEGES ON tietokanta.* TO 'tunnus';
FLUSH PRIVILEGES;
EXIT;

Käy katsomassa mikä on Gitean tuorein versio. Tätä kirjoitettaessa se oli v1.13.6

• Lataa versio:

cd /tmp
export VER=1.13.6
wget https://github.com/go-gitea/gitea/releases/download/v${VER}/gitea-${VER}-linux-amd64

• Tehdään ladatusta suoritettava tiedosto

chmod +x gitea-${VER}-linux-amd64

• Siirretään Gitea ajamista varten sopivampaan hakemistoon

mv gitea-${VER}-linux-amd64 /usr/local/bin/gitea

• Tarkistetaan, että toimii

gitea --version

• Tehdään tarvittavat hakemistot

mkdir -p /etc/gitea /var/lib/gitea/{custom,data,indexers,public,log}

• Asetetaan oikeudet

chown git:git /var/lib/gitea/{data,indexers,log}
chmod 750 /var/lib/gitea/{data,indexers,log}
chown root:git /etc/gitea
chmod 770 /etc/gitea

• Gitea ei osaa käynnistää itse itseään serverin buuteissa, ja jotta moista ei tarvitsisi tehdä käsin ja tutut systemctl start/restart/stop komennot toimisivat, niin Giteasta täytyy tehdä palvelu, service

nano /etc/systemd/system/gitea.service

• Kopioi tämä ja muokkaa haluamiltasi osin. Esimerkissä on vaadittuna MariaDB ja käytetään socketia:

[Unit]
Description=Gitea (Git with a cup of tea)
After=syslog.target
After=network.target
#
#Requires=mysql.service
Requires=mariadb.service
#Requires=postgresql.service
#Requires=memcached.service
#Requires=redis.service
#
After=gitea.main.socket
Requires=gitea.main.socket

[Service]
# Modify these two values and uncomment them if you have
# repos with lots of files and get an HTTP error 500 because
# of that
###
#LimitMEMLOCK=infinity
#LimitNOFILE=65535
RestartSec=2s
Type=simple
User=git
Group=git
WorkingDirectory=/var/lib/gitea/
RuntimeDirectory=gitea
ExecStart=/usr/local/bin/gitea web --config /etc/gitea/app.ini
Restart=always
Environment=USER=git HOME=/home/git GITEA_WORK_DIR=/var/lib/gitea

[Install]
WantedBy=multi-user.target

• Tehdään socket

nano /etc/systemd/system/gitea.main.socket

Liitä siihen tämä:

[Unit]
Description=Gitea Web Socket
PartOf=gitea.service

[Socket]
Service=gitea.service
ListenStream=<some_port>
NoDelay=true

[Install]
WantedBy=sockets.target

• Otetaan Gitea käyttöön ja käynnistetään se

systemctl daemon-reload
systemctl enable gitea
systemctl restart gitea

• Tarkistetaan, että kaikki toimii tähän asti

systemctl status gitea

Gitean asennuksen viimeistely

Seuraavaksi asennetaan Gitea web-liittymän kautta. Suuntaa sivustolle, ohjeiden alussa A-tietueeseen laittamasi mukaiseen osoitteeseen http://git.example.tld/install. Jos menet pelkästään etusivulle, niin pääset asetuksiin klikkaamalla kirjautumiskuvaketta.

• Jos pääsy kielletään, niin ongelma saattaa olla virtual hostin asetuksissa. Silloin kannattaa ensimmäiseksi avata palomuuriin portti 3000, jota Gitea kuuntelee; ufw enable 3000. Yritä sen jälkeen kirjautumista porttitiedon kanssa http://git.example.tld:3000 ja jos pääset sisälle, niin yritä hahmottaa miksi et pääse ilman porttia. Kun saat tilanteen korjattua, niin muista sulkea palomuurista portti 3000 – on aivan turha päästää kävijöitä sisään eräällä tavalla kiertotietä.

Aseta pyydetyt tiedot – kuten tietokannan tiedot jne. – ja mene muutenkin kaikki vaihtoehdot läpi. Aseta haluamasi. Jos välität sähköpostisi serveriltäsi postfix/sendmail kautta, niin jätä asetukset tyhjäksi. Tämä on niitä tilanteita, joissa suoraan asennustiedoston muokkaaminen on helpompaa. Mutta jos käytät vaikka gmailia, niin samalla vaivalla saat laitettua lähtevän postin asetukset nyt kuntoon.

Kun olet hyväksynyt asetukset, niin saanet virheen eikä Gitea aukea. Se johtuu vain siitä, että se yritetään ladata urlista http://localhost:3000 ja jos et ole paikallisella koneelle, niin ei moista tietenkään löydy. Kun annat normaalin osoitteen http://git.example.tld tai mitä sitten käytätkin, niin etusivun pitäisi aueta. Varmista, että pääset kirjautumaan asennuksessa luomallasi tunnuksella.

sendmail

Sähköpostit olisi hyvä saada liikkumaan. Laitetaan tiedot paikalleen. Avataan asetustiedosto:

nano /etc/gitea/app.ini

Muokkaa tämä itsellesi sopivaksi ja korvaa oleva [mailer] lohko:

[mailer]
ENABLED       = true
FROM          = git@example.tld
MAILER_TYPE   = sendmail
SENDMAIL_PATH = /usr/sbin/sendmail

Gmail olisi tämän tyyppinen:

[mailer]
ENABLED        = true
HOST           = smtp.gmail.com:465
FROM           = example@gmail.com
USER           = example@gmail.com
PASSWD         = ***
MAILER_TYPE    = smtp
IS_TLS_ENABLED = true
HELO_HOSTNAME  = example.com

Tallenna ja käynnistä Gitea uudestaan:

systemctl restart gitea

Lets Encrypt ja SSL

Laitetaan SSL-sertifikaatit kuntoon. Tämä tullee olemaan tulevaisuudessa jonkinasteinen ongelma, mutta ratkaisen sen sitten kun on ajakohtaista. Let’s Encryptin certbot voidaan ajaa muutamallakin vivulla.

• --webroot on yleensä järkevin, mutta koska en tiedä mikä moisen palvelun websivuston juuri olisi, niin en voisi käyttää sitä
• --nginx/apache2 on ehdottomasti helpoin, mutta haluaa itselleen portin 80. Sitä taasen ei ole saatavilla, koska liikenne ohjataan porttiin 443
• --standalone käynnistää sertifikaatin uusimista varten hetkeksi Lets Encryptin oman serverin, mutta se vaatisi Nginxin/Apachen sammuttamista siksi ajaksi
• --manual on jotain mitä en ole koskaan osannut käyttää

Joten menen helpoimman mukaan:

certbot --nginx -d git.example.tld

Makuasia antaako certbotin tehdä uudelleenohjaukset, mutta minä en anna. Ihan siksi, että muokkaan hieman enemmän virtual serveriä ja näin pääsen vähemmällä deletoinnilla.

• Mutta – asetin ensimmäisen kerran SSL-sertifikaatin vivulla --nginx ja sen jälkeen laitoin virtual hostin kuntoon. Seuraavana päivänä uusin sertifikaatin komennolla certbot certonly --webroot -d git.eksis.one ja se meni läpi mitään kyselemättä

Sen jälkeen kun sertfikaatit on onnistuneesti haettu, niin muokataan virtual hostia. Itselläni olisi perusteiltaan tällainen ilman Varnishin mukanaoloa:

server {
    listen 104.248.141.204:443 ssl http2;
    server_name git.eksis.one;

    access_log   /var/log/nginx/access.log;
    error_log    /var/log/nginx/error.log;

    location / {

        #proxy_pass http://127.0.0.1:3000;
        proxy_pass http://unix:/var/run/gitea/gitea.sock;
        proxy_set_header X-Real-IP  $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Forwarded-Port 443;
        proxy_set_header Host $host;
        proxy_pass_header Server;
    }

    ssl_certificate /etc/letsencrypt/live/git.eksis.one/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/git.eksis.one/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

}

server {
    listen 104.248.141.204:80;
    server_name git.eksis.one;

    access_log   /var/log/nginx/access-80.log;
    error_log    /var/log/nginx/error-80.log;

    if ($host = git.eksis.one) {
        return 301 https://$host$request_uri;
    }
        
        return 404;

}

Jos sertikaatin nouto ei onnistu ja annetaan virheeksi 404, niin minulla moinen korjaantuu, kun kerron listen-kohdassa serverin IP:n. En tiedä miksi, mutta minulla IP-osoite täytyy olla jokaisessa virtual hostissa.

Gitean päivittäminen

Koska ollaan asennettu Giteasta binääri ilman mitään repoa, ja koska Gitea ei tarjoa mitään sen kummallisempaa UX-ystävällisyyttä edes ylläpitäjälle, niin päivitykset on tehtävä käsin.

Se edellyttää aika ajoin vilkaisua Gitean sivustolta mikä on tuorein versio.

Itse päivitys on kohtuullisen suoralinjaista. Ensin pysäytetään Gitea systemctl stop gitea, ja edetään kuin tehtäisiin neitseellistä asennusta. Paitsi että ei tarvitse tehdä muuta kuin ladata, muuttaa suoritettavaksi ja kopida sinne missä vanhakin versio oli. Sitten vain käynnistetään Gitea uudestaan ja kaiken pitäisi toimia.

Koska asiat voivat mennä metsäänkin. niin tietysti kannattaa ensin tehdä varmuuskopiot. Saat arvata kerran löytyykö siihen mitään automaatiota…

Gitean varmuuskopiointi

On sitten tarve tehdä varmuuskopio tai palautus, niin kaikki tehdään käsin komentoriviltä. Varmuuskopioinnissa olen onnistunut, mutta palautusta en ole koskaan tehnyt. Vaikka pitäisikin, vaikka vain harjoituksen vuoksi. Varmuuskopio, jota ei pysty tai osaa palauttaa, on melkoisen hyödytön.

Gitean ohjeilla en koskaan onnistunut tekemään varmuuskopiointia. Tiedosto-oikeuksien, tai jonkun muun oikeuksiin liittyvän asian takia, homma pysähtyi ensin tarvittavien hakemistojen luomiseen ja sen jälkeen zip-paketin luomiseen.

Gitean mukaan varmuuskopio tehtäisiin siirtymällä asennushakemistoon. Se tarkoittaa hakemistoa /var/lib/gitea. Ensin vaihdettaisiin käyttäjälle git komennolla su git ja annettaisiin käsky ./gitea dump -c /etc/gitea/app.ini. Tuo kaatuu välittömästi siihen, että ohjelmaa gitea ei löydy tuosta hakemistosta. Kun komennetaan ilman gitean polkua, niin päästään ainakin yrittämään, jolloin törmätään ensin hakemisto-ongelmiin ja sen jälkeen mahdottomuuteen luoda zip-paketti.

Gitean backup tehdään hakemistoon /tmp ja se täytyy myös ajaa siellä. Joten näin saadaan backup:

cd /tmp
su git
gitea dump -c /etc/gitea/app.ini

Se, että /tmp hakemisto on huonoin mahdollinen paikka säilyttää backuppeja, on sitten oma juttunsa. Siellä kun mikään ei säily. Joten muodostettu zip-paketti on sitten erikseen siirrettävä jonnekin muualle.

Mitään moista rutiinijuttua ei saa rakentaa ajatukselle, että sen tekee itse joskus, muistaessaan ja ehtiessään. Se täytyy automatisoida ja ajaa esimerkiksi cronilla.

cd /usr/local/bin
nano giteabackup

Liitä tiedostoon tämä (älä takerru skriptaukseen, jos osaat paremmin; minä vain kopypeistaan näitä):

#!/bin/bash
TMP_DIR=/tmp
BACKUP_FILE=gitea-dump_$(date +"%Y%m%d_%H%M%S).zip

cd "${TMP_DIR}" ; sudo -u git /usr/local/bin/gitea dump --config /etc/gitea/app.ini --file "${BACKUP_FILE}" --tempdir "${TMP_DIR}"
chmod 644 "${TMP_DIR}/${BACKUP_FILE}"
mv "${TMP_DIR}/${BACKUP_FILE}" /home/git

Tehdään siitä ajettava skripti:

chmod 774 giteabackup

Aja skripti /usr/local/bin/giteabackup cronissa, esimerkiksi kerran päivässä.

Backupin palautus tehdään puhtaasti käsitöinä, eikä sille ole olemassa mitään työkalua. Yksnkertaisesti vain puretaan zip ja jyrätään olemassaoleva asennus. Ohjeiden mukaan näin sen pitäisi onnistua:

unzip gitea-dump-XXX.zip
cd gitea-dump-XXX
mv data/conf/app.ini /etc/gitea/app.ini
mv data/* /var/lib/gitea/data/
mv log/* /var/lib/gitea/log/
mv repos/* /var/lib/gitea/repositories/
chown -R git:git /etc/gitea/app.ini /var/lib/gitea

mysql --default-character-set=utf8mb4 -u$USER -p$PASS $DATABASE <gitea-db.sql

systemctl restart gitea

Logit

Gitean logit pitäisi löytyä hakemistosta /var/lib/gitea/log. Pitäisi, koska ei sinne mitään ilmesty. Sitä joudutaan hieman säätämään, joten avaa /etc/gitea/app.ini.

Sieltä pitäisi löytyä asennuksen jäljiltä tällainen lohko:

[log]
MODE                 = console
LEVEL                = info
ROOT_PATH            = /var/lib/gitea/log
REDIRECT_MACARON_LOG = true
MACARON              = console
ROUTER               = console

Logit saat samaan paikkaan muiden kanssa, kun muutat ROOT_PATH polun. Aika looginen vaihtoehto on pitää logit samassa paikassa, joten vaihdan sen /var/log/gitea.  Hakemisto gitea täytyy tehdä itse mkdir /var/log/gitea ja uskoakseni siihen täytyy antaa oikeudet käyttäjälle git eli chown git:git /var/log/gitea.

MODE on console, joka ohjaa logitiedot os.stdout mutta nyt halutaan ne tiedostoon. Joten vaihdetaan arvoksi file.

LEVEL on tasolla info, jonka pitäisi logittaa suunnilleen kaikki. Se kannattanee muuttaa esimerkiksi arvoksi warn.

Gitea tarjoaa kuitenkin myös mahdollisuuden tutumpaan logitukseen NCSA Common Log formaatilla. Sen saa päälle asettamalla ENABLE_ACCESS_LOG = true. Hassua on se, että kun testasin toimintaa fake-loggautumisella, niin ilmoitus kirjautumissivulle saapumisesta tuli Gitean access.log tiedostoon, mutta ei keulilla olevaan Nginxiin. Tässä on jotain, jota en nyt ymmärrä.

Niin tai näin, niin nyt saa logitietoja kertymään. Varsinaista logrotatea ei tarvitse asentaa, koska Gitean pitäisi tehdä se itse, mutta sisäänrakennetun kierron voi halutessaan ohittaa ja ottaa käyttöön järjestelmän logrotaten.

Jos haluat tutustua syvemmin Gitean logitukseen ja sen asetuksiin, niin kannattaa vilkaista ohjeet; https://docs.gitea.io/en-us/logging-configuration/

Omat asetukset ovat hyvin simppelit ja tähän päädyin:

[log]
MODE                 = file
LEVEL                = warn
ROOT_PATH            = /var/log/gitea
REDIRECT_MACARON_LOG = true
MACARON              = console
ROUTER               = console
ENABLE_ACCESS_LOG    = true

Aina kun olet muuttanut mitä tahansa Gitean asetuksia, niin tarvitaan uudelleenkäynnistys:

systemctl restart gitea

Fail2ban ja Gitea

Fail2ban on ehkä serverin tärkeimpiä työkaluja. Roskaliikennettä on enemmän kuin hyötykäyttäjiä, joten haittoja kannattaa edes yrittää hidastaa. Gitean kohdalla se tarkoittaa useimmiten turhien kirjautumisyritysten hillintää.

Jos/kun laitoit päälle access.log tiedot, niin se ei auta Fail2bannin kohdalla. Koputtajat kun saavat saman 200 OK ilmoituksen kuin kaikki muutkin, koska kirjautumissivu latautui kuten kuuluikin. Sen sijaan Gitean ”oma” logi, gitea.log, antaa virheilmoituksen. Se on tämän kaltainen:

2021/03/29 12:12:21 routers/user/auth.go:177:SignInPost() [I] Failed authentication attempt for efeg from 84.231.164.255: user does not exist [uid: 0, name: , keyid: 0]

Tuota voidaan käyttää liipaisemaan Fail2ban.

Tehdään ensin filtteri:

/etc/fail2ban/filter.d/gitea.conf

Lisää sinne tämä:

# gitea.conf
[Definition]
failregex =  .*(Failed authentication attempt|invalid credentials|Attempted access of unknown user).* from <HOST>

ignoreregex =

Tehdään tarvittava jail:

/etc/fail2ban/jail.d/gitea.conf

Lisää tämä, toki itsellesi sopivaksi muokattuna:

[gitea]
enabled = true
filter = gitea
logpath = /var/log/gitea/gitea.log
maxretry = 3
findtime = 3600
bantime = 2h
action = iptables-allports

Ja sitten tarvitaan Fail2bannin käynnistys:

fail2ban-client restart

Cache

Olisin halunnut käyttää reverse proxynä Varnishia, mutta siihen eivät taidot riittäneet. Gitea sen sijaan tarjoaa mahdollisuuden eräänlaiseen objekticacheen. Se ei ole oletuksena päällä, vaan täytyy erikseen asettaa. Hyötyä kannattaa hetki pohtia, sillä kaikki menee rammiin. Joten jos muistia on vähänlaisesti, niin ehkä ei kannata.

Aukaistaan /etc/gitea/app.ini

• Tee uusi lohko ja salli (tai estä arvolla false) cache, sekä laitetaan kaikille yhteiset säädöt:

[cache]
ENABLED = true
ITEM_TTL = 8h   #kuinka kauan käyttämätön objekti pysyy cachessa

Vaihtoehtoja on kolme:

• memory
• redis
• memcache

Jokaiselle tulee [cache]-lohkoon hieman erilaiset asetukset.

Ymmärtääkseni memory on eräällä tavalla levylle kirjoittamisen korvaaja, eikä siinä käytetä mitään ihmeellisempää hallintaa tai muutakaan:

ADAPTER  = memory
INTERVAL = 60 # Garbage Collection interval (sec), en tiedä mitä tekee, mutta joku TTL on tämäkin

Yleisesti servereiltä löytyvä on memcache, mutta en tiedä onko tässä kyse vastaavasta memcached tai onko erolle ylipäätään mitään merkitystä:

ADAPTER = memcache
HOST    = 127.0.0.1:9090;127.0.0.1:9091

Redis on ammattilaistasoa oleva objektivälimuisti. Koska minulla on se käytössä, niin tietysti otin käyttöön. Sen jälkeen alkoikin painiminen. Gitea käynnistyi kylläkin, mutta kaatui heti kun joku tuli sivuille. Googletus ei auttanut mitään. Mutta näillä asetuksilla sitä on käytetty, mutta ilmeisesti cachen toimivuus on hyvinkin epävarmaa, vaikka Gitea pysyisikin pystyssä.

ADAPTER = redis
HOST = network=unix,addr=/run/redis/redis.sock,db=0,pool_size=100,idle_timeout=180
#HOST = redis://:macaron@127.0.0.1:6379/0?pool_size=100&idle_timeout=180s //Gitean ohjeen mukainen
[session]
PROVIDER = redis
PROVIDER_CONFIG = data/sessions

Lopputuloksena en ottanut käyttöön mitään. Kannattaa muuten huomata, että vaikka olisi ENABLED = false, niin Gitea menee kaikki cachen asetukset läpi ja kaatuu, jos ne eivät ole mieleiset. Joten muut cachen asetuksiin liittyvät rivit täytyy kommentoida, oli cache käytössä tai ei.

Koska oma Gitea on alkuvaiheessaan niin kevyt, että varsinaista apua ei olisi cachesta, niin hautasin tämän osaprojektin odottamaan aikaa parempaa.

SSH

Git vaatii usein SSH:n. Tyypillisesti tehdään töitä omalla koneella ja muutokset viedään repoon, tässä Giteaan, SSH:lla. Samaten Giteassa olevat asiat tuodaan ja synkronisoidaan oman koneen versioon SSH:n avulla. Sen on siis toimittava.

Jos et ole asettanut SSH:ta, niin näistä voi lähteä liikkeelle ja katsoa mihin asti pääsee:

• Serveriä määräävä sshd_config
• Käyttäjän oma SSH-config
• Windows 10 ja SSH

Gitea osaa käyttää omaa SSH-palvelintaan, mutta sen käyttö lienee turhaa. Joka tapauksessa serverillä täytyy olla SSH käytössä, joten sitä käytetään. Gitean asetuksia ei paljoa tarvitse muuttaa, mutta pari asiaa on varmistettava. Joten avataan /etc/gitea/app.ini.

Tarkista lohkosta [server]

• SSH_SERVER on oltava se, joka on tunnusten domainosana. Oletuksena se on localhost. Minulla on useita domaineja samalla virtuaaliserverillä, mutta virtuaaliserveri on eräällä tavalla nimetty eksis.one, joten SSH:lla käytettävät tunnukset ovat muotoa tunnus@eksis.one; näin ollen minulla on siinä arvona eksis.one vaikka git.eksis. one toimii myös
• DOMAIN on sivuston domain. Oletuksena se on localhost. Minulla se on siten git.eksis.one
• SSH_ROOT_PATH on se polku, jossa se .ssh hakemisto sijaitsee, johon käyttäjällä git on pääsy. Aika tyypillisesti se on kotihakemistossa, joka on Ubuntussa yleensä /home/git/.ssh

Muita SSH:n asetuksia ei tarvita, kun käytetään järjestelmää.

Käyttäjän git kotikahemisto täytyy tietysti olla vain gitin käytössä. Lisäksi .ssh hakemistolla ja siellä olevassa julkiset avaimet sisältävän authorized_keys tiedoston oikeudet täytyy olla oikein:

chown -R git:git /home/git
chmod 700 /home/git/.ssh
chmod 600 /home/git/.ssh/authorized_keys

Sinä et kuitenkaan koskaan käsittele suoraan gitin omistaman .ssh hakemiston tiedostoja. Se tapahtuu aina web-GUI:n kautta jokaisen Gitean käyttäjän omista asetuksista.

SSH:n toimivuus gitin kanssa on syytä testeta. Sitä varten täytyy ensin laittaa oma julkinen avain Gitean käyttäjätietoihin,

Jos et ole vielä generoinut omaa SSH-avainparia sillä koneella, jonka shellissä teet töitä, niin tehdään se ensin. Komento ssh-keygen tekee homman; vastaa salasanakyselyyn pelkällä enterillä, ellet hae maksimaalista turvallisuutta, joka heikentää käytettävyyttä. Hyväksy tarjottu tallennuspaikka.

Julkinen avaimesi on tallennettuna tiedostoon ~/.ssh/id_rsa.pub. Saat sen helpoiten näkyviin kopiointia varten komennolla cat < ~/.ssh/id_rsa.pub. Kopioi se ja liitä Gitean käyttäjätilisi asetuksissa SSH/GPG-avaimet.

Anna shellissä komento ssh -i ~/.ssh/id_rsa -vT git@<ssh-domain>. Vastauksen pitäisi olla tämäntyyppinen, vaikka esitän vain lopun:

...
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /<tunnuksesi/.ssh/id_rsa RSA SHA256:... explicit
debug1: Server accepts key: /<tunnuksesi>/.ssh/id_rsa RSA SHA256:... explicit
debug1: Authentication succeeded (publickey).
Authenticated to <ssh-domain> ([127.0.1.1]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: Remote: /home/git/.ssh/authorized_keys:2: key options: command user-rc
debug1: Remote: /home/git/.ssh/authorized_keys:2: key options: command user-rc
debug1: Sending environment.
debug1: Sending env LANG = C.UTF-8
Hi there, <tunnuksesi>! You've successfully authenticated with the key named <domain>, but Gitea does not provide shell access.
If this is unexpected, please log in with password and setup Gitea under another user.
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
debug1: channel 0: free: client-session, nchannels 1
Transferred: sent 3224, received 3256 bytes, in 0.8 seconds
Bytes per second: sent 4009.8, received 4049.6
debug1: Exit status 0

Jos sen sijaan saitkin vastauksen:

...
debug1: Offering public key: /<tunnuksesi>/.ssh/id_rsa RSA SHA256:...
debug1: Authentications that can continue: publickey
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Trying private key: /root/.ssh/id_ecdsa
debug1: Trying private key: /root/.ssh/id_ecdsa_sk
debug1: Trying private key: /root/.ssh/id_ed25519
debug1: Trying private key: /root/.ssh/id_ed25519_sk
debug1: Trying private key: /root/.ssh/id_xmss
debug1: No more authentication methods to try.
git@<ssh-domain>: Permission denied (publickey).

niin SSH-avain löytyy, mutta sitä ei hyväksytä syystä tai toisesta.

Jos jätit testin tekemättä ja oletkin tekemässä ensimmäistä repoasi SSH:lla, ja siirtoa yritettäessä saat tylyn vastauksen:

git@<ssh-domain>: Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

niin kyse on tismalleen samasta ongelmasta.

Tuohon on muutama syy:

• .ssh hakemistoa ja sen tiedostoja ei omista git:git (luultavammin ollaan shellissä tehty jotain rootin ominaisuudessa)
• .ssh-hakemiston oikeudet eivät ole 700 ja sen tiedostojen 600
• et ole asettanut Gitean käyttäjätiedoissasi SSH-avainta
• sshd_config ei salli käyttäjälle git SSH:ta

Kolme ensimmäistä on esitelty jo aiemmin ja se, että saako git ylipäätään tehdä mitään SSH:lla, on helposti selvitetty.

nano /etc/ssh/sshd_config

Tarkista muutenkin asetukset, mutta etsi loppupuolelta kohta AllowUsers. Jos sellainen löytyy, niin siinä täytyy olla mainittuna myös git. Jos teet SSH-serverin asetuksiin muutoksia, niin se täytyy käynnistää uudestaan: systemctl restart ssh

Voit myös vilkaista millaisen virheen logit antavat. Komento

tail -f /var/log/auth.log

laittaa liveseurannan päälle ja saat heti virheilmoituksen näkyviin.

Gitean ulkonäkö

Koska Gitea on nimenomaan git-repo koodareille, niin mitään sellaista turhaa kuin helppo ulkonäkön muokkaus ei ole rakennettu. Helppous tarkoittaa tässä valmiita tyylipohjia tai elementtejä. Sinällään Gitean muokkaaminen on siedettävän suoraviivaista – kunhan hallitsee HTML:n ja CSS:n edes perusteiltaan.

Ja taas. Käsitöihin joutuu.

Gitean asennuksessa ei ole mitään rakenteesta valmiina odottamassa muokkausta. Ei edes hakemistorakennetta. Jos olet koskaan tehnyt jotain WordPressin lapsiteeman kanssa, niin periaate on sama. Tehdään toiseen paikkaan samanlainen hakemisto, ja laitetaan sinne vain muuttuneet tiedostot. Ero tulee siinä, että kun  WordPressissä teema ja sen tiedostot ovat valmiina ja riittää vain kopiointi hakemistojen välillä, niin Gitean kanssa kannattaa mennä hakemaan muokattava tiedosto heidän repostaan.

Gitea on staattista HTML:ää eli sivuja ei koota esimerkiksi erillisten PHP-tiedostojen avulla. Templates tiedostot parsitaan yhteen, kun käynnistät Gitean, ja lopputulos on tavallista HTML:ää. Se tarkoittaa myös, että pohjien muokkaus tehdään pelkällä HTML:llä ja siten onnistuu vaikka Notepadissä. Tai sitten jollain staattisella editorilla.

Jos olet koskaan tehnyt käsin websivuja, niin alat jo oivaltamaan missä tulee vastaan Gitean vaikeus. CSS-tiedostot, jotka muokkaavat ulkonäköä, ovat hajallaan ja niiden selvittäminen onkin sitten kertaluokkaa vaikeampaa. Hyvät uutiset ovat, että sivuja ei tarvitse suuremmin muokata, ellei sinulla ole syvempää tarvetta saada ulkonäkö tismalleen samaksi kuin jossain muussa sivustossasi. Ainoita, jotka joutuu erikseen tekenään ovat etusivu ja ”apusivut”, kuten vaikka tietosuojalauseke. Niiden kohdalla on oikeastaan aivan sama käytetäänkö sen kummallisempia CSS-määrityksiä. Jos teet perusteiden mukaan, niin sivut skaalautuvatkin ilman sen kummallisempia virityksiä.

Muista käyttää saman version tiedostoja kuin mikä Gitean versio on. Github näyttää oletuksena masterin, joka ei ole sama kuin asentamasi – jos et asentanut tuoreinta mahdollista kehitysversiota. Joten sinun täytyy vaihtaa oikea haara, branch. Jos muokkaat väärän haaran pohjaa, niin se hyvin suurella todennäköisyydellä kaataa asennuksesi.

Kaikki muokatut pohjat laitetaan hakemistoineen /var/lib/gitea/custom alle. Jos muokattaisiin vain navigointia ja vaihdettaisiin favicon, niin custom hakemistoon jouduttaisiin rakentamaan tällainen:

custom
├── public
│   └── img
│       ├── favicon.ico
│       └── favicon.png
└── templates
    └── base
        └── head_navbar.tmpl

Nyt aletaan pääsemään lähelle sitä miksi Gitea on eräällä tavalla kustomoinnin painajainen. Ainakin turhan työn suhteen.

Kaikki sellaiset tiedostot, joita esitetään sivustolla, kuten vaikka kuvat tai erilliset sivut, laitetaan /custom/public hakemistoon. public on kuin verkkosivuston juuri, joten html-sivut, vaikka ehdot tai tietoturvaseloste, laitetaan suoraan sinne. Kaikki kuvat taasen laitetaan img-hakemistoon.

Muutoin koko Gitean rakenne perustuu pohjiin, templates. Muokatut laitetaan, ilman sen suurempia yllätyksiä, templates hakemistoon. Varsinainen alihakemisto täytyy luntata Gitean Github-reposta ja siellä templates hakemistosta. Teet /var/lib/gitea/custom hakemistoon tismalleen samannimisen hakemiston, jossa Githubissa on se template, jota muokkaat,

Joten kun muokkaat etusivua, niin sen pohja home.tmpl laitetaan /var/lib/gitea/custom/templates hakemistoon, koska se sijaitsee Githubissa templates-hakemiston juuressa. Jos muokkaat alatunnistetta, niin kaivattu template löytyy Githubissa templates-hakemistosta base alta ja nimellä footer.tmpl – silloin omassa Gitea asennuksessa täytyy hakemistosta /var/lib/gitea/custom/templates/base löytyä muokattu footer.tmpl.

gitea embedded

Yksi tapa löytää muokattava pohja on etsiä se Gitean CLI:n avulla. Koska binääriin on ikäänkuin pakattu kaikki mahdollinen, niin haluttu osa on mahdollista löytää ja erottaa komennolla gitea embedded. Samalla näet mikä on tarvittava hakemisto.

• Voit listata kaiken komennolla

gitea embedded list

Syöte on tämän kaltainen, mutta toki pidempi:

templates/admin/user/edit.tmpl
templates/admin/user/list.tmpl
templates/admin/user/new.tmpl
templates/base/alert.tmpl
templates/base/alert_details.tmpl
templates/base/delete_modal_actions.tmpl
templates/base/footer.tmpl
templates/base/footer_content.tmpl
templates/base/head.tmpl
templates/base/head_navbar.tmpl
templates/base/paginate.tmpl
templates/custom/body_inner_post.tmpl
templates/custom/body_inner_pre.tmpl
templates/custom/body_outer_post.tmpl
templates/custom/body_outer_pre.tmpl
templates/custom/extra_links.tmpl
templates/custom/extra_links_footer.tmpl
templates/custom/extra_tabs.tmpl

Jos haluaa päästä helpolla etusivun kanssa, eikä tarvitse esittelytekstejä, niin ehdottomasti helpoin tapa on vain esitellä git-repoja ja laittaa hakumahdollisuus. Etusivu on silloin minimalistisen tarkoituksenmukainen. Käytännössä se vain ohittaa etusivun ja käyttää laskeutumissivuna samaa mitä yläpalkin linkki Tutki näyttäisi. Vähimmän vaivan tie saattaisi olla juurikin tämä, ja sitten laittaa yläpalkkiin navi-nappulan sivulle, jossa esitellään mistä sivustosta on kyse.

Avaa /etc/gitea/app.ini ja lisää [server] lohkoon tämä:

LANDING_PAGE = explore

Jos olet hieman hajulla mitä olet etsimässä, niin pystyt rajoittamaan hakua.

• gitea embedded list **.tmpl antaa pelkästään templatet
• gitea embedded list templates/mail/**.tmpl löytää sähköpostien muokkaamiseen tarvittavat templatet
• gitea embedded list public/img : public/img/** näyttää kaikki tiedostot hakemistosta public/img
• gitea embedded list '**body**' esittäisi kaikki sellaiset, joissa on termi body

Kun olet löytänyt sen pohjan, jota haluat muokata, sekä hahmottanut minkä hakemiston tarvitset sille, niin sinulla on kaksi tapaa lähteä muokkaamaan sitä. Joko menet käsipelillä tehden hakemiston mkdir komennolla, kopioimalla tarvittavan tmpl tai muun tiedoston sisällön Githubista ja sitten luomalla itse tiedoston. Tai sitten erotat sen gitea embedded extract komennolla haluttuun paikkaan.

Pohjia ei kannata laittaa suoraan custom hakemiston alle odottamaan muokkausta, koska Gitean käynnistyksen yhteydessä kaikki siellä oleva otetaan käyttöön. On ehkä syytä käyttää jotain omaa hakemistoa muokkauksessa oleville ja kun ne ovat valmiita, niin sitten siirtää ne paikalleen. En tiedä, mutta fiksumpi ja filmaattisesti saattaisi hyödyntää tässä urakassa Giteaa ja git’iä, koska tällaiseenhan ne on luotu.

Itse olen tehnyt /etc/gitea/temp ja siirrän muokkaukseen menevät pohjat sinne. Ihan sama mihin moisen hakemiston tekee, mutta tuo on minulle loogisin.

Jos haluaa vaikka muokata kaikkia (tai osaa) lähetettävien sähköpostien pohjia, niin komento erottaisi pohjat binääristä ja laittaisi ne oikeisiin hakemistoihinsa /etc/gitea/temp hakemistoon:

gitea embedded extract --destination /etc/gitea/temp 'templates/mail/**.tmpl'

Sitten muokkaisin mitä haluaisin ja siirtäisin muuttuneet hakemistoon /var/lib/gitea/custom/templates/mail. Ja kuten aina, kun Giteassa muutetaan jotain, niin systemctl restart gitea ottaa muutokset käyttöön.

Saattaisi olla houkuttelevaa siirtää kaikki valmiiksi custom hakemistoon ja sitten muokata mitä kokee tarpeelliseksi. Tuo kuuluu sarjaan huonot ideat päivitysten suhteen. Vaikka olisi tullut päivitys, niin Gitea käyttää niitä pohjia, jotka löytyvät custom hakemistosta. Joten jos kaikki pohjat ovat tuolla, niin yksikään päivitys ei näkyisi. Tuolla estetään omien muutosten jyrääminen päivitysten myötä, mutta se tuo mukanaan tismalleen saman ongelman kuin WordPressin lapsiteemojen kanssa. Mitä jos päivitys kohdistuu juuri siihen tiedostoon jota olet muokannut? Mikään ei kerro tuota sinulle ja siihen herää vasta kuin jokin ei toimi. Joten ihan jokainen päivityskerta pitäisi erikseen varmistaa, että muokkaamasi tiedostot eivät ole muuttuneet. Ja jos ovat, niin joudutaan tekemään omat modifikaatiot uudestaan, käsin.

Logon vaihtaminen

Sivuston varsinainen logo, esimerkiksi etusivulla, asetetaan tiedostolla /var/lib/gitea/custom/public/img/logo.svg. Joten muuta logosi svg-muotoon, jos se sattuu olemaan jpg tai png, ja uudelleennimeä se logo.svg sekä siirrä hakemistoon. Gitean uudelleenkäynnistyksen systemctl restart gitea jälkeen logosi ilmestyy. Ai, etkö halunnutkaan yksiväristä logoa? Sellaista se on… mutta svg nimenomaan on yksivärinen.

Jos haluat muuttaa yläpalkin pienempää ikonia, niin versiossa 1.13 sen täytyy olla nimetty gitea-sm.png.tai sitten muokkaat templatea, sillä sekin on kovakoodattu sinne. Koko on asetettu 30 x 30 px, joten suorakulmainen ei skaalaudu kovinkaan hienosti. Ja jotta asiat eivät olisi liian helppoja, niin tuokin tulee muuttumaan versiossa 1.14.

Sivuston metadata

Gitea ei tarjoa sen suurempia SEO-työkaluja, mutta hieman voi säätää sivuston metadataa. Avaa /etc/gitea/app.ini ja lisää nämä, itsellesi sopivasti muokattuina:

[ui.meta]
AUTHOR      = EksisGIT
DESCRIPTION = Tavis nörttimaailmassa, mutta git-repona
KEYWORDS    = git,gitea,github,koodi,web

Muita voi hieman miettiäkin, mutta KEYWORDS on melkoista ajanhukkaa. Yksikään arvonsa tunteva hakukone ei niitä noteeraa.

Seurantakoodin asettaminen

Suurin osa sivustoista, ellei jokainen, seuraa ja tilastoi kävijöitä. Yleisin on Google Analytics, mutta ei itsehostattu ja enemmän käyttäjien yksityisyyttä kunnoittava Matomo ole myöskään huono – hieman rajoittuneempi kuin Analytics, mutta käyttökelpoinen.

Seurantakoodin asettaminen on myös ulkomuodon muokkaamista, vaikka muutos ei näykään kävijälle. Koodi asetetaan usein header-osioon, mutta sivunlatausnopeuksien suhteen ehkä footer olisi parempi vaihtoehto. Kuten oletettavaa on, niin Gitea ei tarjoa minkäänlaisia työkaluja yhdistää CSS- tai JS-tiedostoja, latauksien viivästämisestä puhumattakaan.

Jos asetat koodin headeriin, niin muokattava tiedosto on templates/custom/header.tmpl ja footer tietysti samasta paikasta löytyvä footer.tmpl.

Hae muokattava tiedosto joko Githubista tai erota se gitea embedded extract komennolla. Mutta aikaa säästääksesi – header.tmpl on tyhjä tiedosto, joten voit luoda sen samantien hakemistoon /var/lib/gitea/custom/templates/custom ja kopypeistata seurantakoodin. Muista käynnistää Gitea uudestaan systemctl restart gitea.

Sivulinkkien näyttäminen

Staattisen sisällön linkittäminen voidaan tehdä kahteen paikkaan, joko yläpalkkiin tai alatunnisteeseen.

• alatunnisteen linkit, jotka näkyvät oikealla alhaalla, lisätään tiedostoon templates/custom/extra_links_footer.tmpl
• yläpalkin linkit lisätään tiedostoon templates/custom/extra_links.tmpl
• tabeja saa lisättyä tiedostolla templates/custom/extra_tabs.tmpl (katso mallia varsinaisten tabien pohjasta)

Alatunnisteeseen voi laittaa toki muitakin kuin vain tekstilinkkejä, mutta yleensä käytetään tekstiä. Silloin tehdään normaali linkitys. Itse esitän siellä tietosuojalausekkeen, jonka olen linkittänyt suoraan sivustolle www.eksis.one. Olen laittanut myös human.txt linkityksen. Joten oma sisältö on:

<a class="item" href="https://www.eksis.one/tietosuojaseloste/">Tietosuojaseloste</a>
<a class="item" href="https://www.eksis.one/humans.txt"><img src="{{AppSubUrl}}/img/humanstxt-isolated-blank.gif" width="88" height="31" alt="humans.txt" /></a>

• huomaa {{AppSubUrl}} jolla saa vältettyä polun kirjoittamisen

Alatunniste

Kun lisäät vaikka sivuston linkkejä, niin ne menevät alatunnisteessa jo olevien perään ja ylänavissa aktiiviseksi merkityn linkin perään ja Gitean asettamat seuraavat perässä.

Alatunnisteen, eli alin mahdollinen sivuosa, sisältöä pystyy hieman säätämään kohtuullisen nopeasti.

Esimerkiksi sivujen latausnopeus on turhaa tietoa. Gitean versionumeron näyttäminen on jopa jonkinasteinen turvallisuusriski. Gitan oma brämdäys taasen on vain ärsyttävää, vaikkakin ilmaisessa softassa omalla tavallaan ymmärretävää; ilmaisia lounaita kun ei ole.

Ne saa poistettu avaamalla /etc/gitea/app.ini ja lisäämällä loppuun tämän:

[other]
SHOW_FOOTER_BRANDING           = false
SHOW_FOOTER_VERSION            = false
SHOW_FOOTER_TEMPLATE_LOAD_TIME = false

Linkkirivissä varsinainen kauneusvirhe on Gitean omien verkkosivujen linkitys, joka on nimetty suomalaisessa kieliversiossa huomattavan harhaanjohtavasti  Nettisivut. Se kun antaa viitteen siitä, että linkin takaa löytyisi juurikin asennukseen liittyvä sivusto tai sivustot. Joten vaihdetaan se. Minusta gitea.io on informatiivisempi.

Nyt joudutaan muokkaamaan käännöksiä. Tarkoittaa valitettavasti myös sitä, että päivityksen myötä kaikki itse tehnyt käännösmuokkaukset häviävät – Gitea on ensimmäinen käyttämäni, jossa törmään tähän ongelmaan.

• Ensimmäiseksi täytyy tehdä kielitiedostoille oma hakemisto asennukseen:

mkdir -P /var/lib/gitea/custom/options/locale

• Tehdään kielitiedosto:

nano /var/lib/gitea/custom/options/locale/locale_fi-FI.ini

Avaa oikean version kielitiedosto Gitean reposta ja kopio teksti tiedostoon. Etsi termi website=Nettisivut (löytyy aika alusta) ja vaihda Nettisivut muotoon gitea.io. Tallenna ja käynnistä Gitea uudestaan. Nyt linkin nimi on vaihdettu.

Jos haluat tehdä saman mulle kieliversioille, niin se täytyy tehdä samalla tavalla.

Kielivalikko pitää sisällään kaikki ne kielet, joille Gitea on käännetty. Omalla tavallaan on aivan sama ovatko ne siellä vai eivät, mutta onhan se pitkä. Koska en tarjoa EksisONE sivustolla globaalia sisältöä, niin sitä voi karsia. Englanti kannattaa jättää, koska jokainen suomenkielistä sivustoa käyttävä ei kuitenkaan halua liittymää suomeksi. Samaten englanti kannattaa löytyä, jos vaikka joskus täytyy pyytää apua kansainvälisistä ryhmistä tai foorumeilta. Ruotsi on myös syytä pitää paikallaan.

Kielivalikon muokkaaminen on helppoa. Avaa /etc/gitea/app.ini ja lisää lohko:

[i18n]
LANGS = en-US,fi-FI,sv-SE
NAMES = English,suomi,svenska

Jos haluat kuitenkin muita kieliä, niin liisää niitä käytä lyhenteitä ja kerro kielen nimi natiivissa muodossa.

Gitean kääntäminen

Sivuston sekakielisyys on selvä ulkomuoto- ja käytettävyysvirhe – siitäkin huolimatta, että kaikki ovat tottuneet moiseen. Käännökset kannattaa pitää kunnossa, ja jopa muokata omiin tarpeisiin sopiviksi. Taas kerran vertaus WordPressiin. Asennetaan vaikka Loco, etsitään termi ja käännetään se, tai muokataan käännöstä. Onnistuu useimmiten, mutta toki se edellyttää, että koodari on vaivautunut merkitsemään termin käännettäväksi.

Giteassa sama ei toimi aivan noin helposti. Kirjautumisen jälkeen etusivulla näkyy teksti ”0 total contributions in the last 12 months” ja tuo olisi mukavaa kääntää suomeksi. Jotta se onnistui ilman, että täytyy upota koodin syvyyksiin ja etsiä mikä palikka tuota huutaa, niin avataan ensin Githubista englanninkielinen lokaali locale_en-US.ini ja tarkistetaan onko sitä ylipäätään laitettu käännettäväksi. Koska sitä ei löydy, niin todetaan, että vaiva ei vastaa hyötyä, sillä pitäisi etsiä tuon asettava ohjelmanpätkä ja korjata sinne, ja annetaan olla.

Mutta jos se olisi löytynyt, niin termi olisi kopioitu vastaavaan paikkaan tiedostoon locale_fi-FI.ini ja käännetty. Sen jälkeen muutettu käännöstiedosto olisi laitettu omaan asennukseen /var/lib/gitea/custom/options/locale/locale_fi-FI.ini ja systemctl restart gitea perään. Täysin vastaavasti tehdään suomenkielisen käännöksen muokkaus.

Yleisin syy siihen miksi jokin termi ei ole käännetty, on koodarin laiskuus. Sitä ei ole vain merkitty käännettäväksi.

Giteab kääntäminen on joukkoistettu. Joten puuttuvan käännöksen kohdalla kannattaa vilkaista https://crowdin.com/project/gitea ja tehdä siellä suomen käännökset. Silloin kaikki hyötyvät, eikä oma vaiva kuitenkaan lisäänny. Tuon kaltaisessa kannattaa tyytyä käyttämään yleisesti käytössä olevia termejä, eikä harrastaa luovaa hulluutta. Tätä kirjoitettaessa vain kolmannes Gitean teksteistä oli käännetty suomeksi, joten töitä piisaisi.

Cron

Gitea on siitä omituinen ohjelma, että sille ei tarvitse asettaa erikseen cronia. Mutta vielä omituisempaa on, että dokumenttien mukaan sen sisäänrakennetty kaikki huoltotoimenpiteet ajastava cron on oletuksena pois päältä. Joten kannattaa asettaa.

Avaa /etc/gitea/app.ini ja lisää uusi lohko:

[cron]
ENABLED = true

Sen kummallisempia säätöjä ei tarvitse tehdä, ellei ole kummallisia tarpeita. Oletuksena olevat toimenpiteet riittävät. Jos haluat säätää aikatauluja, niin sitten tarvitset enemmän säätökohtia.

Mitä seuraavaksi?

Kun Gitea on pystyssä ja pyörii, niin on aika alkaa opettelemaan gitin alkeita, tehokäytöstä puhumattakaan. Se on aivan oma maailmansa, eikä sieltä helpoimmasta päästä. Mutta koska Gitea on vain palvelu gitien keskitettyyn hallintaan, niin se on työkalu. Varsinainen asia on se mitä tehdään ja miksi ylipäätään tarvitaan toista työkalua: git versionhallintaa.

Sen jälkeen alkaa hahmottua mitä säätöjä tarvitsee, toimiiko ssh jne. Kun niitä alkaa viilaamaan, niin taatusti tulee Gitean (vajaanoloinen) dokumentaatio sekä Google tutuiksi.

Ensimmäinen repo

Jos luot repon websivun kautta, niin törmäät hassuun tilanteeseen. Et pysty lisäämään ensimmäistäkään tiedostoa. Gitea ei päästä tyhjään repoon. Toki tuo saattaa joskus muuttua, mutta koska aiheesta on kyselty jo – tätä kirjoitettaessa – kolme vuotta, niin usko asian muuttuvan.

Ilmeisesti Gitean käytöntöihin kuuluu, että kaikki liikuttavat tiedostojaan gitin malliin oman koneen komentoriviltä ja webliittymä on oikeastaan vain näyteikkuna. Mutta kun ensimmäinen tiedosto on onnistuttu tekemään, vaikka vain README.md, niin sen jälkeen kaikki onnistuu webliittymänkin kautta. Ei, tuossa ei ole mitään järkeä.

Asian voi ratkaista kahdella tapaa.

Helpoin ja nopein tapa, varsinkin jos et ole aivan sinut git-järjestelmän kanssa tai juuri sillä hetkellä ei ole pääsyä shelliin, on tehdä repo ja yksi tedosto Githubiin (oletan, että sinulla on Github-tili, koska tuskin muutoin olisit itsehostattavaa git-palvelua rakentamassa). Siellä kun saa tehtyä tiedoston luotuun repoon. Sitten tekee importin Giteaan.

Toinen tapa on sitten toimia Gitean kehittäjien halun mukaan ja lähteä liikkeelle shellistä. Silloin aidosti tehdään uusi repo ja ylikirjoitetaan webissä tehty tyhjä.

Tee haluamasi hakemisto. Minulla on kotihakemistossa repo, jonka alla kaikki git-projektit ovat. Tein sinne hekemiston git-manuaali.

• Siirrytään repon hakemistoon

cd ~/repo/git-manuaalit

• tehdään tyhjä README.md tiedosto (toki saat kirjoittaa sisällönkin, jos haluat)

touch README.md

• alustetaan git

git init

• laitetaan README.md siirrettäväksi repoon

git add README.md

• tehdään commit

git commit -m "Aloitus"

• tehdään remote (muutat tietysti originin tiedot ja tunnuksesi itsellesi oikeiksi)

git remote add origin git@eksis.one:jagster/Git-manuaali.git

• tehdään push

git push -u origin master

• Kirjaudu Giteaan varmistaaksesi, että repoon ilmestyi tyhjä README.md

Nyt pystyt lisäämään tiedostoja webliittymänkin kautta.

Jakke Lehtonen

Teen B2B-markkinoille sisällöntuottoa sekä UX-testauksia. Samaan liittyy myös koulutukset yrityksille ja webmaailman kanssa muutoin painiville. Serverien sielunelämää on joutunut ohessa opettelmaan. Toinen puoli toiminnasta on koirien ravitsemuksen ja ruokinnan suunnittelua sekä varsinkin omistajien kouluttamista hoitamaan koiriaan oikein ja vielä paremmin.

Profiili: Jakke Lehtonen