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

Mounting git commits as folders with NFS (2023)

jvns.ca

Post reply on HN
Print view View original

31–40 of 61 posts

Re: Mounting git commits as folders with NFS (2023)

#31

Post by retrocryptid »

Oh man. I was just reminded of ClearCase and Perforce and sort of threw up a little in the back of my mouth. You young whipper-snappers who didn't have to use ClearCase and have only used hg or git don't know how bad it could be. When ClearCase was properly configured, it was fine. But having used it at IBM, DSCCC and Bell Canada, only IBM managed it properly. At DSCCC, we had 40 Sun workstations on a single thin-net segment, each of them trying to mount an NFS share from ClearCase. You had to get there at 6AM to be one of the first five people to log in because if you didn't it was unlikely you COULD even log in. I kept a copy of the part of the code I was working with on a tape and would go into the lab and restore it from tape, do some work, then back it up to tape at the end of the day (the lab machines were reformatted at midnight every day.)

But... yes... this is just using NFS locally to see what's already in GIT, which is perfectly find and as Julia says, allows you to appreciate the structure of the git repo. Ignore this old man yelling at clouds.

Re: Mounting git commits as folders with NFS (2023)

#32

Post by mrlonglong »

retrocryptid wrote: post #31

Oh man. I was just reminded of ClearCase and Perforce and sort of threw up a little in the back of my mouth. You young whipper-snappers who didn't have to use ClearCase and have only used hg or git don't know how bad it could be. When ClearCase was properly configured, it was fine. But having used it at IBM, DSCCC and Bell Canada, only IBM managed it properly. At DSCCC, we had 40 Sun workstations on a single thin-net…

Oh nooooo.

Re: Mounting git commits as folders with NFS (2023)

#33

Post by skydhash »

mmh0000 wrote: post #28
skydhash wrote: post #26

Earlier quoted context omitted.

> The fact that NFSv4 has no concept of true "Authentication" and just blindly accepts whatever the client sends is the craziest network application design ever Doesn’t the secure option require ports only a root user can bind too? And you can always create secure tunnels if the physical network is insecure.

Sure, if you (the admin) have full control over the NFS server, the network, and the client devices, NFS can be secure with the help of Kerberos. But this isn't a simple thing. A Kerberos server needs to be set up, Kerberos clients need to be configured on the NFS server and client, tickets need to be issued, firewall ports need to be opened, and user accounts need to be centrally managed. That's all fine for an Ente…

> Now, how about this common scenario: I want to run a file-sharing server on my network. I want a random "friend" to come over and grab a copy of a file, but I don't want them to see any other files on the NFS server.

How is that a common scenario? Why not give them your drive and the encryption key while you’re at it? It would be way faster.

The correct scenario would be to just copy the file and serve it with ftp or http on another interface.

Re: Mounting git commits as folders with NFS (2023)

#34

Post by IshKebab »

> I fixed this by defining an inode(string) function which hashed a string to get the inode number, and using the tree ID / blob ID as the string to hash.

The tree/blob ID is already a hash though. You don't need to hash it again. Just use the first 8 bytes of the tree ID as the inode.

Re: Mounting git commits as folders with NFS (2023)

#35

Post by mmh0000 »

skydhash wrote: post #33
mmh0000 wrote: post #28

Earlier quoted context omitted.

Sure, if you (the admin) have full control over the NFS server, the network, and the client devices, NFS can be secure with the help of Kerberos. But this isn't a simple thing. A Kerberos server needs to be set up, Kerberos clients need to be configured on the NFS server and client, tickets need to be issued, firewall ports need to be opened, and user accounts need to be centrally managed. That's all fine for an Ente…

> Now, how about this common scenario: I want to run a file-sharing server on my network. I want a random "friend" to come over and grab a copy of a file, but I don't want them to see any other files on the NFS server. How is that a common scenario? Why not give them your drive and the encryption key while you’re at it? It would be way faster. The correct scenario would be to just copy the file and serve it with ftp…

Ah, so you agree NFS is not fit for purpose (network file sharing), and I should use something else to share files over the network.

EDIT (the above is a bit more snark than I intended, let me add a little more):

NFS's direct (still widely used) competitor, SMB, natively supports:

  - Authentication
  - Transfer encryption
  - Authentication encryption
  - Has open implementations across platforms
  - Supports individual account management, and large enterprisey account management (LDAP/AD/etc)
With SMB, I can share out a directory on the network that allows visitors access, optionally authenticated with a simple username and password.

I can share out specific directories with easy control over who can access what. You know, basic network file sharing capabilities.

[[ And, don't take this as a love for SMB, it too has many issues and legacy junk ]]

Re: Mounting git commits as folders with NFS (2023)

#36

Post by IshKebab »

mmh0000 wrote: post #17
steveBK123 wrote: post #9

NFS.. stop right there

You're being downvoted, but, seriously... NFS is a joke for anything outside of an enterprise setup with a bunch of ancillary support services in place. The fact that NFSv4 has no concept of true "Authentication" and just blindly accepts whatever the client sends is the craziest network application design ever: Client: Hi, NFS server, I'm Bob! UID=1000 Server: Hi Bob! Here's access to all of Bob's files! I trust you…

Even worse is the .nfs "silly renaming" nonsense. I was under the impression that NFSv4 fixed that but someone told me it doesn't.

Re: Mounting git commits as folders with NFS (2023)

#37

Post by feurio »

mmh0000 wrote: post #17
steveBK123 wrote: post #9

NFS.. stop right there

You're being downvoted, but, seriously... NFS is a joke for anything outside of an enterprise setup with a bunch of ancillary support services in place. The fact that NFSv4 has no concept of true "Authentication" and just blindly accepts whatever the client sends is the craziest network application design ever: Client: Hi, NFS server, I'm Bob! UID=1000 Server: Hi Bob! Here's access to all of Bob's files! I trust you…

> Setting up Kerberos just to authenticate users for access to my Linux ISOs is a crazy large requirement!

Export as read only?

Re: Mounting git commits as folders with NFS (2023)

#38

Post by jstanley »

nine_k wrote: post #18
oefrha wrote: post #7

Earlier quoted context omitted.

By excellent do you mean bearable? macOS’s SMB stack is certainly not excellent.

Won't the SMB implementation be sufficient to mount git commits as folders?

No, because SMB doesn't support execute permissions. So either all your files are executable or none of them are.

Re: Mounting git commits as folders with NFS (2023)

#39

Post by skydhash »

mmh0000 wrote: post #35
skydhash wrote: post #33

Earlier quoted context omitted.

> Now, how about this common scenario: I want to run a file-sharing server on my network. I want a random "friend" to come over and grab a copy of a file, but I don't want them to see any other files on the NFS server. How is that a common scenario? Why not give them your drive and the encryption key while you’re at it? It would be way faster. The correct scenario would be to just copy the file and serve it with ftp…

Ah, so you agree NFS is not fit for purpose (network file sharing), and I should use something else to share files over the network. EDIT (the above is a bit more snark than I intended, let me add a little more): NFS's direct (still widely used) competitor, SMB, natively supports: - Authentication - Transfer encryption - Authentication encryption - Has open implementations across platforms - Supports individual accou…

> Ah, so you agree NFS is not fit for purpose (network file sharing), and I should use something else to share files over the network

NFS stands for Network File System, not Network File Sharing. If you gave a disk to someone, the permission bits wouldn’t stand for anything too.

Post reply on HN