Fun with cgit and cgi services in general
Getting cgit to work has been as painful as some older 'useful' packages. The first problem was cgi was not working despite having been using it with mapserv not long ago. Working through fcgiwrap.service and it's associated .socket I eventually spotted that the prot to connect to was actually fcgiwrap.sock ... the .socket file had dropped the final et, but my nginx vhosts were still trying to use it. The next step was to get cgit to actually run. The configuration information may be comprehensive, but functional examples for nginx on tumbleweed are a bit thin on the ground. This moring I gave in on trying to configure it on rdm1.uk and fired up a subdomain, which is probably tidier anyway, and so https://git.rdm1.uk appeared. No use trying to look at it, the connection is sitting behind auth_basic on nginx. While I could see easier what was going on, running cgit.cgi was still playing curveball and I was having problems getting consistant results. Running cgit.cgi manually from the command prompt was supposed to help, and one could see the 404 error that it was producing, but no explination why. Something that none of the 'AI' helpers have any concept of. I NOW know what was going on and yes it is using the right 'user' which in the case of my webstack is nginx:nginx ... but of cause from the command line you can't pretend to be that :) The magic box is /var/cache/cgit/ which caches the displayed pages along with the PROCESSED cgitrc file. Restarting fcgiwrap and nginx make no difference what so ever, it's the files here that matter. After making any change to the cgitrc files, you need to remove the rc_* files so that cgit will actually try and rebuild it. Some thing neither 'AI' muppet identified. Running from the command prompt creates the file, in my case as root and then nginx can't read it. Wipe the folder and run from the browser and things burst into life. This aide of things has be the problem all along so two days of buggering around with nginx was never going to fix it.
Just how we identify the repositories is the next step, and despite advise that manually listing them in the /etc/cgitrc, all I have working currently is the scan-path=/srv/git method which is now picking up bitweaver repo structure although I have had to link the second layer of repos directly into /srv/gitso I can see them, and then add cgitrc files into the .git folder to provide section and name information. It's actually looking good although it may take a while to get everything sorted. I'm still trying to work out just where some things are being accessed, but another key was the addition of virtual-root=/ otherwise things go messy with the generated links and it also seemed to help get the initial scan to run properly.
The next layer to attack is clone-prefix=https://git.rdm1.uk/webstack.git but that will only be necessary if I am killing ties with github and need to provide my own sources for cloning. Inside the router I don't have a problem with that and in any case I will probably be managing via BeyondCompare rather than git anyway. Git is however starting to provide the sort of trcking that my mercurial setup provided for a long time. A couple of lest than productive days, but if dosuments like this come out life will be easiser.
I need to set up a sample configuration set of files taken from the webstack repo and showing how cgit can be slotted in. I suspect now I could even go back to https://rdm1.uk/cgit and get it working!
To add git.rdm1.ukvhost.conf, main cgitrc file, file structure provided by cgit package, .git/cgitrc sample and description file from .git structure.
Outstanding questions, why can't I create manual repo intries in /etc/cgitrc.