Received: from MTA-15-3.privateemail.com (MTA-15-3.privateemail.com [198.54.122.111]) by gbr-app-1.alpinelinux.org (Postfix) with ESMTPS id 49D632231C9 for <~alpine/users@lists.alpinelinux.org>; Tue, 2 May 2023 22:19:43 +0000 (UTC) Received: from mta-15.privateemail.com (localhost [127.0.0.1]) by mta-15.privateemail.com (Postfix) with ESMTP id 1B52A18000A2 for <~alpine/users@lists.alpinelinux.org>; Tue, 2 May 2023 18:19:42 -0400 (EDT) Received: from [192.168.1.238] (unknown [50.80.229.133]) by mta-15.privateemail.com (Postfix) with ESMTPA id CE3DD18000A0 for <~alpine/users@lists.alpinelinux.org>; Tue, 2 May 2023 18:19:41 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=theroyalrainbow.com; s=default; t=1683065982; bh=Zvrd/4LaLBSbsJlwhsQUbfSa7adoePIHT5hxqc78Vsc=; h=Date:To:From:Subject:From; b=ma7wNnstS8ZYibA0u+jtCxjoqwDr3o23r2zubzLLdPP41sg90Dem62cQCi1ycvgkQ 4CCip6RFtneYR7vUS1zsHQyS409UxlNHd5EjrNvsfKkGA2ICKO/Jp187lAFIvSmdvI EA8/2HHRPOBmfYhlMPR6fsQvohPtkFYYItG7J161dWy6zRuRVdqcedlNzSq/cLY+Id ZdqIc3CQj0fJmTYE+SZqdLbcF3/L3SrQ4vtfHmlLxp3t5Eul62un5Bmsk2Tyoy057H O43YZ/6l/udiXEBYBNE0X88OrpPhEMWrBZEvuIiHZUPiEF05LJrnxctEzmORxLFcjC rFIGEMZMZNwIA== Message-ID: <45d0716a-71c3-0a2f-766f-845000bf62bb@theroyalrainbow.com> Date: Tue, 2 May 2023 17:19:41 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Content-Language: en-US To: ~alpine/users@lists.alpinelinux.org From: JB Schirtzinger Subject: Issues with Gnunet Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP 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.