After recovering from a hardware failure on the Az/El Rotator, I tried to bring the client system back on line but could not get the PI-3 to connect and stay on the network… Don’t know why and Im not a Linux wiz, so I decided to reinstall with the latest Satnogs build.
Following the instructions at ‘https://wiki.satnogs.org/Raspberry_Pi_3’ all goes fine until the ‘Apply’ operation where the below error is posted. Running from a SSH session, I have tried the Setup process twice with the same results. I have verified the API Key is correctly entered and other fields are correct. Currently no RTLSDR or Rotor system attached. Newtwork connection is hard wired but behind firewalls. I will also try again this evening from my home network which is less restrictive.
Any ideas what Im doing wrong?
TASK [satnogs-radio : Add archive repositories keys] ******************************************************
failed: [localhost] (item=8B48AD6246925553) => {“changed”: false, “cmd”: “/usr/bin/apt-key adv --keyserver pool.sks-keyservers.net --recv 8B48AD6246925553”, “item”: “8B48AD6246925553”, “msg”: “Error fetching key 8B 48AD6246925553 from keyserver: pool.sks-keyservers.net”, “rc”: 2, “stderr”: “Warning: apt-key output should not be parsed (stdout is not a terminal)\ngpg: keyserver receive failed: Network is unreachable\n”, “stder r_lines”: [“Warning: apt-key output should not be parsed (stdout is not a terminal)”, “gpg: keyserver recei ve failed: Network is unreachable”], “stdout”: “Executing: /tmp/apt-key-gpghome.sRiPJCIx5i/gpg.1.sh --keyse rver pool.sks-keyservers.net --recv 8B48AD6246925553\n”, “stdout_lines”: [“Executing: /tmp/apt-key-gpghome. sRiPJCIx5i/gpg.1.sh --keyserver pool.sks-keyservers.net --recv 8B48AD6246925553”]}
Hi @N7IPY – this failure is happening when the setup script is trying to add a new source of packages for the Raspberry Pi. As part of that, it’s trying to install a GPG key,which will help the Pi make sure the packages it installs are okay (that is, that they’re signed by the right folks).
Looking at the error, my guess would be that either the server that had the keys (“pools.sks-keyservers.net” in your error message) was having problems right then, or else that server was unreachable by the Pi (maybe because of the network it was on?). I’ve tried the command on my home machine, and it works (so we know the key is there to be fetched, at least).
Trying it at home would be a good thing to try; if that works, I don’t think it should be needed again – that is, I think you could take it back to the original location (with the possibly more restricted network you mentioned) and not need to worry about it again…the script should be smart enough to know it doesn’t need to fetch it more than once.
Thanks for the input. I did try the command from my home network last night but had the same timeout failure trying to access the server. I will reinstall on a blank microSD card today and then wait to to the configuration until this evening where my home network is under my control.
It’s an easy process that does not take long. The developers have made the install process easy enough that just about anyone with a little computer background can do it.
Will update once I have results.
When I installed SatNOGS onto my Raspberry Pi3 using the image I ran into the same failure as mentioned above. I have been looking through the ansible playbook code and from what I found this to me looks to be an issue with the archive repository keys it tries to install. In file main.yml in folder satnogs-client-ansible\roles\satnogs-radio\tasks it tries to validate two keys against pool.sks-keyservers.net and one of the keys fails making the whole installation of gr-satnogs fail. Also see below snippet of the code.
When I validated the keys by entering them manually on the above mentioned server only one key returned a valid response. Key 8B48AD6246925553 return ‘No results found. No keys found’ while key 7638D0442B90D010 returns below result.
Search results for ‘7638d0442b90d010’
Type bits/keyID cr. time exp time key expir
pub 2048R/05C44DC0 2017-08-15
Fingerprint=CF1C 335D 088E 33D7 EB02 3F78 29D3 8665 05C4 4DC0
Hi @pa-tester – a quick Google search for 8B48AD6246925553 turned up a few different questions from folks running into the same question. On my Pi, this key is shown as a key for Debian 7 packages:
I’m unable to tell right now if any packages depend on that key for signing. It would seem unlikely that anything from Debian 7 is actually being installed.
Can you try removing the failing key from the Ansible manifest and re-running? If everything works, great; if it still fails, the source will need to be updated in the Ansible manifest. Either way, please file a bug about it so the developers know.
If it turns out it does need to be installed, you can do that a few different ways. I’ll list the steps from this blog post:
install from another keyserver: apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 8B48AD6246925553
I did run some more tests and this time it even failed on both keys. So I remove the complete code snippet as shown above. Ran satnogs-setup and executed Update and Apply and now the installation continued and the remaining packages satnogs-radio and ham-utils were installed. I am now able to schedule an observation and have it executed on my Raspberry Pi so I have now a working system.
I did not try the solution you provided since it worked without the keys being installed.
I have done more testing and after a lot of trial and error I came to below results.
Found on Internet that for keyserver access port 11371 is used. Tried setting port forwarding in my routers for port 11371 to my Raspberry. The ansible script was still failing with the same issue.
Tried using telnet if I could connect to the server using port 11371 from my Raspberry and this is working.
Found on the Internet a way to connect to the keyserver using port 80 so I changed the URL in /root/.satnogs/ansible/roles/satnogs-radio/tasks/main.yml from pool.sks-keyservers.net to hkp://pool.sks-keyservers.net:80 and this worked.
It is most likely a port issue which I tried to solve by setting port forwarding but this seems not to work (or I did it wrong). But by changing the URL of the server as described above the issue can also be soved and there is no need to open up ports on your local network with all the risks involved.
I will continue to use the above workaround and if possible like to see this included into the ansible script.