On Mon, 2021-03-22 at 18:17 +0100, Ludovic Courtès wrote:
> Hi Maxime,
Hi

> Maxime Devos <maximedevos@telenet.be> skribis:
> 
> > A patch defining simple ‘ipfs-service-type’ is attached. I've tested
> > this in a VM, and will test it on a ‘real’ system later. The gateway
> > is currently broken, it tries to redirect to non-existent subdomains
> > of localhost. Correcting this might require fiddling with the DNS
> > configuration.
> 
> 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.

> > +@lisp
> > +;; part of the operating-system declaration

> I think you can omit this line.

I think I found that line somewhere & copied it for consistency,
but it has been some time ago.

> > +(service ipfs-service-type
> > +              (ipfs-configuration
> > +               (gateway "/ip4/127.0.0.1/tcp/8880")
> > +               (api "/ip4/127.0.0.1/tcp/8881")))
> 
> Indentation is left (should be aligned with ‘ipfs-service-type’.)

Ok, not sure how this happened.

> > +      (start #~(make-forkexec-constructor/container
> > +                [container stuff]
> > +                #:environment-variables #$%ipfs-environment))
> 
> Nice!
Yep!  Also, this reminds me I'm not sure what the distinction between
#+ and #~ is in activation gexps, in shepherd services definitions,
etc.

> > +  ;; Run ipfs init and ipfs config from a container,
> > +  ;; in case the IPFS daemon was compromised at some point
> > +  ;; and ~/.ipfs is now a symlink to somewhere outside
> > +  ;; %ipfs-home.
> > +  (define container-gexp [complicated container stuff])
> > 
> That’s a bit involved, but it makes sense to me.

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)

(Super hacky work-around:
  rm -r /var/lib/ipfs
  mkdir /var/lib/ipfs
  chmod a-rwx /var/lib/ipfs
  chmod u+rwx /var/lib/ipfs
  chown ipfs:ipfs /var/lib/ipfs
  sudo -u ipfs -g ipfs "`guix build go-ipfs`/bin/ipfs" init
  # ^ this can take some seconds to complete
  sudo -u ipfs -g ipfs "`guix build go-ipfs`/bin/ipfs" config API /ip4/127.0.0.1/tcp/5001
  sudo -u ipfs -g ipfs "`guix build go-ipfs`/bin/ipfs" config Addresses.Gateway /ip4/127.0.0.1/tcp/8082
  herd enable ipfs
  herd start ipfs)

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.

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 ..

Seems like shepherd needs support for file descriptor!  I've a patch for
that, but it needs to be verified (& corrected likely) on GNU/Hurd.  Feel
free to ask for the incomplete patch if you're impatient and want to finish
it yourself!  (Seems to work on GNU/Linux in any case.)

> 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.

Greetings,
Maxime.