= Git server =

Over onderhoud en inrichting van de 'git server'.
Ook in die volgorde.
Dus wat het vaakste voorkomt staat boven aan,
wat minder vaak voorkomt dus onderaan.

== Doet ie het nog ==

De ultime test van de 'git server' is
* een http git pull
* deze testregel wat   meer of  minder spaties geven
* `git commit -a -m "om de git server weer te zien werken"`
* een ssh git push
Als het meezit, dan is er ook ook serieuser testmateriaal voor handen.

///////////////////
Eerder uitgezocht als "commentaar" toegevoegd
zodat de bestede tijd niet geheel verloren gaat.

low level http read check
  wget -q -O - http://losc.nl/Breda/loscweb/.git/info/refs?service=git-upload-pack
  wget -q -O - http://losc.nl/Breda/loscweb/.git/HEAD

low level ssh write check is lastig, met
  telnet november.losc.nl ssh
moet er een TCP connectie komen. Op
  [enter]
wordt die connectie afgesloten met een "protocol mismatch"

Voorbeeld:
 $ telnet november.losc.nl ssh
 Trying 77.72.145.149...
 Connected to november.losc.nl.
 Escape character is '^]'.
 SSH-2.0-OpenSSH_6.0p1 Debian-4+deb7u1

 Protocol mismatch.
 Connection closed by foreign host.

Zo weet je dat de SSH daemon er nog is.
///////////////////

== Met welke SSH-key is de push gedaan ==

Alle 'git ssh pushes' zijn voor `ssh-server`
allemaal connecties van dezelfde user `cp`.
Dat dus weer uit elkaar halen.

In `/etc/ssh/sshd_config` staat o.a.
................
SyslogFacility AUTH
LogLevel VERBOSE
................

In log file /var/log/auth.log is dan het effect
van die ge-activeerde setting terug te halen.
Voorbeeld:

................
grep --before=1 'Accepted publickey for cp from' /var/log/auth.log \
| grep 'Found matching '
................

== Plaatsen van SSH-key ==

Het 'public part' van de de SSH-key wordt toegevoegd
aan `.ssh/authorized_keys` van de user `cp`.
Waarbij `cp` de operating system user is die
schrijfrechten in de 'Centrale Plaats repository' heeft.

In het optionele commentaar veld, de string na de spatie,
van de public key het contact e-mail adres van de contributor zetten.

Het is dus een actie waarbij
tekstbestand `~cp/.ssh/authorized_keys`
er een regel bij krijgt.

Dan is er nog een administratieve stap nodig.
Dat is omdat
  ssh-keygen -l -f /home/cp/.ssh/authorized_keys
geeft slechts 1 regel, eigenlijk 1 key, output geeft.
///////
Immers is `ssh-keygen` gemaakt om enkel key-pairs te genereren.
En zulke key-pairs gaan in afzonderlijke files.
Het is de `-l`, list, optie die dan ook voor enkele keys is.
De file authorized_keys is een uitzondering,
die heeft meerdere keys.
///////

Bij aanlevering van een public SSH key,
het moment dat je 1 file hebt met daarin 1 key
dan ook de fingerprint opvragen met
  ssh-keygen -l

///////
Work in progress, WIP
Hier gebleven
///////

== Verwijderen SSH-key ==

Verwijderen van de SSH-key gebeurd door regel uit authorized_keys
te halen.

Wanneer SSH-keys, dus privileges, in te trekken, staat los van de handeling.
( Bijvoorbeeld dat de key niet meer ingebruik (verloren) is of
  bericht dat er geen gebruik van gemaakt gaat wordt (andere belangstelling).
  (Of in het slechtste geval: misbruik van het privilege.)
)

== Git repository aanmaken ==

Eerst "ssh" naar de server

////////////////////
Wat nu volgt is lang niet meer gedaan
documentatie zo wel eens onjuist kunnen zijn
////////////////////

................
cd /home/cp # path to other repos

mkdir newrepo

cd newrepo

git --bare init
................

Nu is `git push naar SSH URL` mogelijk.

Kopie naar "http c.q. git pull" is met een andere system user gedaan.


== Users ==

Op de git server zijn user accounts aangemaakt.


=== Centrale plaats ===

Operating system user `cp` heeft de leidende git repository.

`adduser --shell git-sh --system --gecos "Centrale Plaats,,," cp`


Controle op die actie:
................
$ grep ^cp /etc/passwd
cp:x:107:111:Centrale Plaats,,,:/home/cp:/usr/bin/git-sh
................

=== Website user ===

Operating system user `wsbreda` houd de website up-to-date.

`adduser --system --gecos "Website Breda,,," wsbreda`


Controle op die actie:
................
$ grep ^wsbreda /etc/passwd
wsbreda:x:108:112:Website Breda,,,:/home/wsbreda:/bin/bash
................

De website user heeft cronjobs.
................
root@november:~# crontab -l -u wsbreda
#
# m h  dom mon dow   command

#
*/2 * * * * /home/wsbreda/loscweb/scripts/commitwatch >> /home/wsbreda/cron.log 2>&1
#
*/20 * * * * /home/wsbreda/loscweb/scripts/update_website >> /home/wsbreda/cron.log 2>&1
#
#
# l l
root@november:~#
................

En die scripts staan in weer loscweb, de git repository
waar deze file ook in staat. `:-)`

== Server ==

Server ( CPU, Memory, disk space and network connection )
heeft webserver (HTTP) en SSH server draaien.

Voor de webserver is het serveren van statische webpagina's voldoende.


== Succes ==

Succesvolle combinaties.

=== november ===

 * Debian GNU/Linux
 * Apache
 * OpenSSH server

=== hostname ===

 * Operating system
 * (web?) server, voor `git pull` (en `git clone`) zonder wachtwoord
of iets anders wat laagdrempellig is.
 * (alles is mogelijk) server, voor "git push", belangrijk is
een soort van drempel die spam en andere ongein voorkomt.