Hello all.

I run alpine in a VM via virtualbox. I have installed gnunet following 
the outline indicated here: https://wiki.alpinelinux.org/wiki/GNUnet

When the system root account gnunet starts via rc-service, it only 
starts roughly 7 services. Peerinfo and file sharing (fs) is not 
included among those services. Should I halt that service and use the 
gnunet-arm -s command on the root account, it will start 26 services 
roughly which is the usual amount.(as per other systems install 
defaults) This would be fine, except that non-root user account 
"alpineuser" loses the ability to resolve websites with gns-proxy. The 
ability to resolve with gns resumes when gnunet-arm -e is issued on root 
account, and the system and user services are started. Of course, this 
means that I am back to the 7 services again. I have to stop rc-service 
system startup to get the 26 services via arm to start.


On the other hand, if I go to alpine user and run gnunet-arm -s nothing 
happens other than the above 7 services from system continue to run. If 
I try to start some service with gnunet-arm -i on  account "alpineuser", 
the command prompt informs me that it has never heard of whatever 
service it is that I am attempting to start.  If I then stop all 
services on alpineuser from root with 
rc-service-gnunet-alpineuser-services stop, and start all services on 
the account "alpineuser" from gnunet-arm -s, it will start the seven 
services again as though there is nothing fundamentally different 
between the root starting of the services vs the local starting of the 
services on the account. Naturally, this means I can resolve websites 
with the gns proxy as well.

The goal would ideally be to have peerinfo, fs, and whatever else run by 
default with these 7 services, and I have tried editing various config 
files concerning gnunet.conf in about three to four different locations 
with no success. I assume it is probably a configuration/permission 
problem somewhere, but the troubleshooting material is not widely 
available on this matter and the "doubling" of commands between system 
and user makes this harder to figure out since it is more difficult to 
disentangle what is doing what and when. (lack of documentation makes 
this even harder yet--or conflicting documentation which also is out 
there in abundance)

Probably the only way to smoothly understand what I mean is to test this 
out in virtualbox yourself. If you find that after you install it 
following the instructions here https://wiki.alpinelinux.org/wiki/GNUnet 
does not then produce the behavior I describe above, then I would be 
grateful to understand what you did that was different to my process. 
Using gnunet on other systems often just "works" and therefore the 
impetus to dig through config files is low. Probably it "works" due to 
system d, but that isn't a great reason for it to work. No need to make 
a deal with the devil and sell your soul because everyone else is "doing 
it". Different, though, usually means "weird interaction" potential, and 
so I believe that is another possibility here.