[bug#45905] [PATCH] IPFS service definition

[Ludovic Courtès]

Hi Maxime!

Maxime Devos <maximedevos@telenet.be> skribis:

>> OK.  That doesn’t prevent one from using it, right?
>
> Nah, the REST API presumably works just fine and there is plenty to see on
> the webui:
>
> http://localhost:5001/ipfs/bafybeif4zkmu7qdhkpf3pnhwxipylqleof7rl6ojbe7mq3fzogz6m4xk3i/#/
>
> Not perfect, but it might suffice for your purposes.
> That reminds me the configuration can be modified from there.
> I didn't figure how to disable that.  Not ideal from a security
> perspective, but at least its only loopback & ipfs is in a container.

Good.

[...]

> Yep!  Also, this reminds me I'm not sure what the distinction between
> #+ and #~ is in activation gexps, in shepherd services definitions,
> etc.

#+ is ‘ungexp-native’.  It makes sense if you consider a cross-compiled
system.  Code in an activation gexp is meant to run on the target
system, so you want to use #$ (‘ungexp’) there.

You might want to use #+ when building things that can just as well be
built natively.  For instance, the background image for GRUB must be
built by running Inkscape natively on the host system, so we use
#+inkscape (or similar) to do that.

I hope that makes sense.

> Unfortunately, there are (non-container related) some more issues.
> Last few weeks I've been seeing this error (/var/log/ipfs.log):
>
> (start snip)
> Error: fs-repo requires migration
> Initializing daemon...
> go-ipfs version: 0.8.0
> Repo version: 11
> System version: amd64/linux
> Golang version: go1.14.15
> Found outdated fs-repo, migrations need to be run.
> Run migrations now? [y/N] Not running migrations of fs-repo now.
> Please get fs-repo-migrations from https://dist.ipfs.io
>
> Error: fs-repo requires migration
> (end snip)

Bah, I remember seeing that.

> Unfortunately "fs-repo-migrations" does not seem to be packaged in Guix.
> Apparently there has been a change in repo format in the go-ipfs v0.7.0
> --> v0.8.0 upgrade.  I believe for most users simply automatically running
> the upgrades would be sufficient.

Yes, I think so.  We “just” need to package ‘fs-repo-migrations’ first.

Perhaps it’d be okay, as a first step, to provide an IPFS service that
doesn’t handle migrations automatically.

> Now, how could we do this safely from shepherd?  Maybe before starting open
> a pipe, write "y\n" to it an pass it as file descriptor 0 (stdin) would
> be sufficient?  But shepherd always closes /dev/stdin before exec IIRC ..

You could have the ‘ipfs’ Shepherd service depend on, say, a one-shot
‘ipfs-migration’ service.  The ‘ipfs-migration’ service would run
‘fs-repo-migrations’ if it’s necessary.

>> The patch LGTM.  However, we usually commit services along with a system
>> test under (gnu tests …).  The manual has info on how to run individual
>> system tests:
>> 
>>   https://guix.gnu.org/manual/en/html_node/Running-the-Test-Suite.html
>> 
>> Could you write a test that ensures that basic functionality works?  It
>> could be as simple as waiting for the service to be up, then invoking
>> ‘ipfs add’ and ‘ipfs get’.  WDYT?
>
> Will look into it eventually, but I am currently occupied with other things
> that have deadlines )-:. (Not feeling very inspired for a
> writing/presentation assignment ...)  (And I would rather hack on GNUnet
> frankly; IPFS is more of a stop-gap to me for having some distributed
> something for substitutes.)  So feel free to beat me to it.

I’m not offering to work on it :-), but hopefully you or maybe some
fellow contributor can finish it up in the coming weeks!

Thanks,
Ludo’.