Cgit, Nginx and Gitolite: A Personal Git Server

> this is an internet facing endpoint which will get people probing it to attack (assuming you used a cloud server)

Honestly this is the number one problem with internet security today. Why are computers allowed to talk to strangers at all? They should just drop all data coming from unauthenticated connections. This would destroy the mass appeal of the modern internet but it makes a lot of sense for computers hosting personal services that are meant to be used by one or few users.

Technologies such as port knocking and single packet authorization make vulnerabilities irrelevant since there's no way to exploit them before authenticating oneself.

What's this scaremongering? It's a git repo, "who knows what" can be easily checked with a quick git diff ORIG_HEAD after a pull. And you actually see the changes you're going to be building, rather than relying on some random untrusted thirdparty repo or AUR package, that can be abandoned at any time, or worse.

The update checking workflow can be as simple as putting the repo commit or tag list, or news feed into your RSS reader, and just do a quick check if update is warranted when you get some update in your feed. Many projects have an announce mailing list that you can subscribe to. There are special announce lists for security issues.

And in case of cgit, if you're running a tagged release, how do you know that git 2.25.1 (some random release from a year ago) doesn't have any security vulnerabilities when used with cgit? Building from git and basing cgit on top of 2.30.0 seems a bit more reasonable to me in this case.

I’m not going to disagree with you on the usage of package managers. No only is it easier to install, but easier to maintain.

But, isn’t cgit basically read-only? If so, that doesn’t seem to be particularly risky. All of the main interactions with gitolite are through SSH, which I’d expect to be the main area of attack.

Please avoid gitea. I can't say anything about the other software but gitea is known for having accessibility issues, see https://github.com/go-gitea/gitea/issues/7057

Edit: the reason that I posted this was not due to some hypothetical blind people but rather because I have been in a situation where I want to show a cool project to a friend with vision issues but I can't because the project is hosted on a gitea instance. I posted this because I was unaware of this issue until recently and presumed that there would be others here who are also not aware of this.

Came here to say gitea. It's a single exe, the set up is trivial, and it just runs on my raspberry pi and backs up to my NAS.

My journey went like this:

I ran git in a container "like you're supposed to" with https access but I wanted better management than adding user access to apache.

So I decided to upgrade to gitea. It was a pretty involved installation but I finally got it going. I set up a gitea cotnainer and was able to use it for a while. But one day it stopped working and I had to spend a bunch of time diagnosing why mariadb wasn't coming up. I can't recall exactly what i did (something with ib_logfile) but i finally got it going.

And a few days later when checking on it, I noticed it was using a bunch of cpu time. Apparently it uses resources just sitting there idle, like 5% cpu.

In the end, I made a git container again. I just used SSH access and one user: git

  # pacman -S git
  # useradd -m -G wheel -s /usr/bin/git-shell git
  # systemctl enable sshd

repos are in ~/git/foo.git and ~/git/bar.git, ~/.ssh/authorized_keys for the hosts I give automated access to, password for others.

  $ git clone git@gitmachine:git/foo.git

I liked the idea of git+https. And running gitea seemed like it would be like having my own git infrastructure!! But in my experience, git is easy with a minimal setup.

gitea like everything else won't make everyone happy but for me it's a godsend, it's my personal git server for the last two years and I use it daily.

however if you have special requirement like a large team, or accessiblity(which I didn't check) you can try something else. The point here is that, it's much easier to use gitea than to use git+gitolite+nginx unless you want to spend more time with sysadmin instead of development itself.

How do you handle backups with your instance? I have a simple bash script that sync the entire data directory to Backblaze and I'd love to hear easier or better ways to do this.

How is HAProxy any easier then nginx when it comes to proxying fcgi work?

I also came to chime in with this. I have been running a "personal git server" this way for almost a decade.

On the server:

    cd ~
    mkdir directoryname.git
    cd directoryname.git
    git init --bare

On the client(s):

    git clone username@server:directoryname.git

That's all there is to it!

>All you need to run a 'personal git server' is sshd

To expand on this slightly: making your "personal" git server accessible to collaborators (without needing to manage user accounts user accounts) is also very simple. You can statically serve your repository using any web server.

Collaboration is then based on each contributor pushing (ssh) to their personal server from which everyone else may pull (http).

I dream of the day when the internet is decentralized again (either by ipv6 or tunnel proxies[0]) and we can just push/pull directly to each other.

[0]: https://github.com/anderspitman/awesome-tunneling

rsync.net is great for this: https://blog.kozubik.com/john_kozubik/2010/02/git-and-subver...

Another option is to run a web GUI like cgit, gitweb, Gitea, or Gogs without exposing it to the internet (so it's only accessible at http://localhost:8888 or similar).

When you want to view it from another machine you can just use SSH port forwarding, like:

    ssh -L 8888:localhost:8888 user@hostname

You interact with Gitolite via ssh. The things Gitolite makes easier for you is it generate those repos for you (no need to login, just push a config file) and it handles access via ssh keys.

I for instance have an own key for my phone, so I can access the repo with my notes etc, but if you steal my phone you cannot push any code.

I do the same. There are plenty of tools for local analysis and visualization of git repos; I finder it better to use those as appropriate and just use bare repos cloned from the server.

For what its worth, another thing you might consider looking into is using RSnapshot [0]. RSnapshot helps me sleep at night. This will create multiple directories that are hard links to files that did not change, thus saving disk space and giving you multiple days or weeks of snapshots, in the even something was corrupted and you want to roll back at the filesystem level. Most questions one could come up about rsnapshot with are answered on Serverfault [1] There are many how-to sites [2] with usage examples. You can create snapshots locally or remote. On mac you can brew install rsnapshot.

[0] - https://rsnapshot.org/

[1] - https://serverfault.com

[2] - https://linuxconfig.org/guide-to-rsnapshot-and-incremental-b...

One of the advantages of systems like git is that you just need to clone and you have a complete copy of the original repository, you can synchronize with push/pull. No need to mess with backblaze and containers unless you want to back up your server configuration too. If you lose your server, just push your working copy on a new server. With enough people, losing data becomes almost impossible.

In fact you don't even need a server, just push/pull between your machines, a server just makes things more convenient.

Do you not have all your code locally as well? It seems like if your drive failed for a personal git host, you could just re-push everything back up to it.

Have you considered a distributed filesystem?

For example:

Glusterfs Replicated 3 (1 arbiter/parity), put on top of zfs filesystems with checksumming.

Users/consuming services can Fuse mount over the network

Incremental backups of bricks (1 should be enough) to a mirror or spinning rust

Then all you need to worry about is offsite

If you really only need to solve for gitea, this is prob overkill but if you have more services putting stuff on disk it could be worth it. Works great for me.

I can second git hooks as a vastly underrated approach to automation. Lots of people who only use github don't know about them. Copy-pasta from an old comment of mine:

"So, git hooks are basically executable scripts (of whatever language you have available, I use bash) placed in the .git/hooks dir, whcih are then executed at whichever event is designated (by the name of the script itself) For me, it's post-recieve. After initial setup, a push automatically triggers the post-recieve hook that does something like the following from my git dir:

    GIT_WORK_TREE=..../example.com git checkout -f

and voila, pushes are insta-live, but commits can be pulled and worked on in the meantime.

Learned from a few sources (shout out to Dreamhost for my original intro to this idea), but here are some relevant readings:

https://www.ibm.com/developerworks/library/wa-git/

https://opensource.com/life/16/8/how-construct-your-own-git-... "

I used the exact same stack (gitolite+cgit) in the early stages of a previous startup, and code reviews were the big missing part that made us move to something more full featured (for us, gitlab).

It's pretty easy to trigger ci runs via git hooks, and once you're used to it, checking their results in jenkins instead of in the git repository UI makes no difference. But code reviews really need a dedicated interface.

I wouldn't enjoy writing personal code without CI/CD if it grew beyond a few hundred lines. It's a lot more convenient to have a setup like that, to the point where I'd say it's essential.

The old school way is to notify the ci/cd server using a post-receive hook. You can do it, but it’s not integrated in cgit, it must be set from the command line when you initialize the repo

Personally, I think fossil is far better than git. It offers you a lot more than git: wiki, ticket system, chat, ...

Sorcia website doesn’t load for me

For anyone that has issues with fail2ban, I'm a fan of pam_shield. It's a pam module, so it's intercepting live requests rather than tailing logs, which seems cleaner to me. For debian, it was a relatively simple apt-get type install (libpam-shield). But, yeah, changing the default port surely kills off the noise.