Documentation proposal for remote data mounting, following up from forgejo/forgejo#1590
Documenting remote data folder #193
dbischof90/docs:pr/remote_data_folder_doc into next Looks good. Minor suggestions and then it is good to go.
@ -148,1 +148,4 @@
### Hosting repository data on remote storage systems
You might also mount the data and repository folder on a remote drive such as a
*folders
@ -149,0 +154,4 @@
measures have to be taken in general so that the administrators can adapt this to
their individual setup. Note that the Forgejo developement team does not endorse
this method as it **can potentially lead to corrupted files depending on your setup**,
it is important that you know what you are doing here.
Note that the Forgejo developement team does not endorse this method as it can potentially lead to corrupted files depending on your setup, it is important that you know what you are doing here.
I think this can be left out, it is implied that the reader knows what they are doing.
Okay, just wanted to prevent people coming in later and complaining but you're probably right.
@ -149,0 +167,4 @@
```shell
[...]
/repositories *(rw,sync,no_wdelay,crossmnt,insecure,all_squash,insecure_locks,sec=sys,anonuid=1024,anongid=100)
/repositories *(rw,sync,all_squash,sec=sys,anonuid=1024,anongid=100)
Unless one of the other options is a requirement rather than a configuration choice?
@ -149,0 +203,4 @@
A problem is that if we create ssh keys on the server, they too will have `0777` permissions, which is prohibited by `openssh`.
It is important for all involved tools that these files not be writable by just anybody with a login, so you would get you an error if you try to use them.
Changing permissions will also not work through the chosen `all_squash` setup, which was however necessary to allow a correct ownership
mechanic on the server.
this paragraph should be separated, towards the end maybe? as a not about "why using the rootless image?".
Hmm for me it's "Problem -> Solution", Problem is while that works and solces the chown issue, ssh will act up and to solve this we take the rootless issue. Puts the motivation first and the solution afterwards.
that's a sensible approach when the focus is on the problem. I believe that in this installation guide the focus is on showing a path that will succeed. Discussing the various problems that could get in the way, while very valuable requires a lot more content, hence my suggestion.
I changed the order a bit, let's consider that in a new review!
@ -149,0 +208,4 @@
To circumvent this, you can use the `rootless` image, which hosts an embedded ssh folder. A possible entry in a `docker-compose` file
would look like this
```yaml
this is a diff rather that a yaml file?
Correct, I oriented myself on the DB sections to highlight changes over the "base config" at the top. How would you do it differently?
Oh, that's a good way to do it. Could you maybe add "(this is a diff to the docker compose shown above)" or something similar?
Archived
Archived
Archived
Archived
Archived
Archived
Archived
Archived
Archived
Archived
Archived
No due date set.
No dependencies set.
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?