Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Git servers work, and how to keep yours secure

gemini.nytpu.com

Post reply on HN
Print view View original

31–40 of 51 posts

Re: How Git servers work, and how to keep yours secure

#31

Post by moehm »

neilv wrote: post #10

Is there a rock-solid git server that I can use on a home server for versioned immutable backups of misc. files on personal devices (e.g., account config), as well as private software development git repos? (I've done a cheaper version of this -- except for the immutable part, and the separation of accounts between devices -- in the past using SSH+SVN to a home server, and it was great.) I was thinking immutable from…

> A given device can pull branches of certain repos, and make commits to the branches. But a device's user account on the git server doesn't have permission to affect past commits. So, for example, if my dodgy Linux smartphone is compromised...

Yes, Gitolite can do this.

R is read access only

RW is read and write access

RW+ is read, write and the ability to overwrite history (rebasing)

Re: How Git servers work, and how to keep yours secure

#33

Post by stevenhuang »

For those trying to host a git server on your home network like I have and encountered network issues even after port forwarding, you might be behind carrier grade NAT.

You'll need some forwarding solution, or use an SSH reverse tunnel to punch through CGNat.

Use something like ngrok or localhost.run. For example if you're using gitea, host it on localhost:8080 then run this:

ssh -R 80:localhost:8080 localhost.run

This will forward localhost:8080 to .localhost.run

Now you just pass .localhost.run to colleagues and they'd be able to connect to your self-hosted git instance.

Now do the same for ssh port.

Caveat that your traffic would route through localhost.run, so it's best to not use this for anything serious, or alternatively host your own reverse SSH tunnel on a VPS somewhere.

Re: How Git servers work, and how to keep yours secure

#34

Post by elevation »

3np wrote: post #28
elevation wrote: post #18

I like self hosting git but these tutorials set you up with only a one-machine solution. I'd like to be able to self-host a git service that's robust in the face of network/hardware/OS maintenance. I know git is distributed by design. So if I want to push code to a pair of servers for better availability, I can do it explicitly: git push git push But what if I wanted to make this transparent but still highly availabl…

Plenty of alternative approaches that can get you there. Here’s one: * distributed file system like gluster or ceph for repos * clustered db (eg replicated Postgres) * redundant instances of gitea * load balancing Am I missing something?

Load balancing redundant gitea over clustered postgres and clustered fs provides a resilient read-only stack.

The trouble comes when the system receives two simultaneous pushes to the same branch. When ceph goes to merge them, which one wins? There has to be a distributed write mutex. Perhaps this mutex could be acquired in a pre-commit hook on the gitea nodes, but it's absolutely necessary (in addition to the other clustered services) to prevent silent data loss or corruption.

Re: How Git servers work, and how to keep yours secure

#35

Post by lucb1e »

Ajedi32 wrote: post #19
elevation wrote: post #18

I like self hosting git but these tutorials set you up with only a one-machine solution. I'd like to be able to self-host a git service that's robust in the face of network/hardware/OS maintenance. I know git is distributed by design. So if I want to push code to a pair of servers for better availability, I can do it explicitly: git push git push But what if I wanted to make this transparent but still highly availabl…

git remote set-url --add origin $second_url Not quite HA cluster levels of redundancy, but it's also way simpler to set up.

I actually have this at work for a repo where we want to both push to the server where it'll be deployed (so this server doesn't need some sort of access to another system, trust relations going only one way) as well as to the source repo where we actually collaborate and have an issue tracker etc. Works great for us. Yes, of course you can setup some limited access for this server to pull from the original source but... small team with high security requirements, so this low-tech solution is quite perfect.

Re: How Git servers work, and how to keep yours secure

#36

Post by candiddevmike »

megous wrote: post #22
moistbar wrote: post #20

Earlier quoted context omitted.

Arch also doesn't make for a particularly good server OS.

Why? (Asking as someone running Arch on many servers for the last 5 years, and debian server for much longer) I can think of a few things I dislike, but all of the failures so far were self-inflicted. Like forgetting to update packages that I self compiled outside of supported repository. It's not completely autonomous when it comes to upgrades, you have to think for a while before hitting "yes" after seeing the list…

Arch changes too much, and change means risk. In my opinion, for production, boring is always best. If the latest flavor of X is absolutely essential for the business, there are typically ways to get it for most LTS distros (back ports, third part repos, etc).

Re: How Git servers work, and how to keep yours secure

#37

Post by acidburnNSA »

jeffmk wrote: post #24

Gitea[0] is a pleasant, easy-to-set-up 'GitHub lite', if you are looking for something more turnkey and less custom: - users/organizations - issues - PRs - milestones - releases - wikis - activity/contrib graphs I have it running on a $5/mo Linode instance for some of my personal projects. [0] https://gitea.io/

Is the code review process roughly on par with the github experience? I can't find many examples of a PR with inline comments, etc.

Re: How Git servers work, and how to keep yours secure

#38

Post by xomodo »

stevenhuang wrote: post #33

For those trying to host a git server on your home network like I have and encountered network issues even after port forwarding, you might be behind carrier grade NAT. You'll need some forwarding solution, or use an SSH reverse tunnel to punch through CGNat. Use something like ngrok or localhost.run. For example if you're using gitea, host it on localhost:8080 then run this: ssh -R 80:localhost:8080 localhost.run Th…

How could one selfhost localhost.run setup on own wildcard domaine?

Re: How Git servers work, and how to keep yours secure

#39

Post by strogonoff »

rsync wrote: post #16
neilv wrote: post #10

Is there a rock-solid git server that I can use on a home server for versioned immutable backups of misc. files on personal devices (e.g., account config), as well as private software development git repos? (I've done a cheaper version of this -- except for the immutable part, and the separation of accounts between devices -- in the past using SSH+SVN to a home server, and it was great.) I was thinking immutable from…

"Is there a rock-solid git server that I can use on a home server for versioned immutable backups ..." A few things ... First, 'git' is built into the rsync.net platform and you can do anything you like with it, remotely, over ssh: ssh user@rsync.net "git clone git://github.com/freebsd/freebsd.git freebsd" I personally track a number of repos I consider important and keep my own source trees up to date without runnin…

A question I had for a long time: is rsync.net affiliated in some way with the authors of the rsync utility?

Re: How Git servers work, and how to keep yours secure

#40

Post by redwall_hp »

jeffmk wrote: post #24

Gitea[0] is a pleasant, easy-to-set-up 'GitHub lite', if you are looking for something more turnkey and less custom: - users/organizations - issues - PRs - milestones - releases - wikis - activity/contrib graphs I have it running on a $5/mo Linode instance for some of my personal projects. [0] https://gitea.io/

It supports LFS too. I use it for my Unity hobby projects, because I'm already paying for my VPS (which has tens of gigabytes of space), so paying GitHub for extra space would be silly.
Post reply on HN