DietPi-Software | IPFS Node

[ravenclaw900]

Status: Ready

• Test on VM
• Test on RPi

Reference: #4232

Commit list/description:

• DietPi-Software | Add IPFS Node
• DietPi-Software | Add uninstall instructions

[ravenclaw900]

Well, I tried updating VirtualBox and now the kernel module is not loading. Time to start using QEMU.

[MichaIng]

I like the idea to merge nodes for distributed projects. Probably the decentralised search engines YaCy and SearX (not added yet) could be added there as well, as the local node as well contributes to the global network.

[ravenclaw900]

Coincidentally, I was planning to do SearX sometime soon.

[MichaIng]

Well, I tried updating VirtualBox and now the kernel module is not loading. Time to start using QEMU.

Related to IPFS? You mean updating the desktop application or the DietPi guest system?

[ravenclaw900]

It was the desktop application, and I hadn't even switched to the IPFS branch yet, so almost certainly not related.

[ravenclaw900]

Fixed now (broken permissions on the kext directory).

[MichaIng]

Online docs required: MichaIng/DietPi-Docs#425
Did some install tests and it works like a charm 👍.

[MichaIng]

One error during startup:

2021/04/11 18:25:50 failed to sufficiently increase receive buffer size (was: 208 kiB, wanted: 2048 kiB, got: 416 kiB). See https://github.com/lucas-clemente/quic-go/wiki/UDP-Receive-Buffer-Size for
details.

https://github.com/lucas-clemente/quic-go/wiki/UDP-Receive-Buffer-Size

# sysctl net.core.rmem_max
net.core.rmem_max = 212992
# sysctl -w net.core.rmem_max=2500000
net.core.rmem_max = 2500000
# Issue solved

Shall we implement an /etc/sysctl.d/dietpi-ipfs.conf to have this applied automatically. Not sure whether ~2.4 MiB packet receive buffer can be an issue for low memory devices?

---

Another question: I don't see a reason to have the ipfs user being member of the dietpi group, since its internal data is completely independent from any file system directories, right? The CLI in case needs read permissions, but the dietpi group is by default only required for write permissions to the /mnt/dietpi_userdata media directories. Shall we skip that group membership, to harden the application a little?

[ravenclaw900]

Let's add the file, at least for the sake of mitigating the error. It seems that the dietpi user requires full permissions to the directory for IPFS commands to work, I just did that so that we wouldn't have to apply 777 permissions to the directory.

[MichaIng]

It seems that the dietpi user requires full permissions to the directory for IPFS commands to work

What has the dietpi user to do with it? You mean when one logs in with that user and runs the ipfs command from console? For this reason I thought about the CLI alias: #4236 (comment)
Generally the dietpi user should not be seen as the intended login user and I aim to remove it in favour of an optional custom login user to be created on first boot of DietPi. To have new files and directories in case created with the correct user, so that the web UI remains to have full access, the CLI should be executed as ipfs user as well.

[ravenclaw900]

Ah. In that case, yes, let's remove it from the dietpi group.

[MichaIng]

Okay, I'm adding the change, including the CLI alias and the receive buffer raise.

[MichaIng]

The web interface is unprotected by default. Is there a way at application level to enable login authentication, limit access to local network or such?

[MichaIng]

I'll merge it, we can further test and think about web UI protection in the issue.