I also use a USB extension cable to test my DIY GPS when I am downstairs. I extend it to a window. I get a lock then.
Upstairs, I do not have to use an extension cable. I get a connection from multiple satellites. To see this, makes me wonder how much our homes are bombarded from stuff above us.
The USB GPS connected to my RPI3B+ was configured to provide time. KSTARS was setup to use this Time from the attached USB device.
The critical path for time are power and connections. The RPI3, RPI3B+, and RPI4 have 4 USB and 1 nic. USB is asynchronous. The 1 nic is TCPIP, synchronous.
Given the ports, 4 ports are receiving data and 1 port can give or receive data. To give, it must be a time giver. The iOptron is USB based. Depending on the model, models do have RJ45 connectors. I am certain that the iOptron GPS is meant for its consumption. The iOptron OS model is specific to its needs.
My system uses my attached USB GPS to get time. That is my design. The iOptron design is to service its needs.
Some models have wireless capabilities. Wireless would be one avenue to share Time through. The System providing the Wireless service has to have time. Both The RPI3B+ and iOptron would be dependent on the time from the wireless network.
From this discussion, the iOptron must be designed to provide GPS and time to any RPI product via a custom designed cable from iOptron to an RPI product.
The product I use is a DIY GLOSSNOS USB GPS device. This plugs into a 4 port powered USB hub and into the RPI3B+. GPSD provides the service for The RPI3B+ to receive NEMA data from the DIY. The DIY is much less expensive than the iOptron GPS device. I purposely separate USB traffic to provide the maximum opportunity to asynchronously communicate with USB devices.
Not currently possible is the answer, given the reasons provided. A third party could provide time to both systems through wireless services.
I reconnected. Faulty chrome session. We are back in the saddle.
Thank you. Everything is working again.
I guess it is rights issue. The problem I have is with GPS. With First Light and a GPS connected, GPSPANEL map bounces between the default Poland and the current GPS coordinates. It looks like a hardwired coordinate is not allowing the system to change it. Where is the question? Deep dive coming.
I am happy to report First Light is now operational.
The service noVNC.service was corrected. I changed the Type from forking to idle on all these service files
I also found an issue with noVNC.service. This was the problem all along. I was looking at another service and noticed the syntax around After=.
Now, everything works.
Critical path items had
1. User=multiple names
I removed all User= entries. They are not necessary.
2. Syntax errors [UNIT] should be [Unit]
3. NGINX requires SUDO help to load.
4. Type= different levels.
I standardized on Type=idle.
5. After=Multi-user.target service.name
This should be After=service.name
6. Running the update under sudo or root masks the needs of systemctl enable and restart. Be ready to inout the password before and after the &&.
7. The noVNC service bug hung up the POSTINST script from completing. The service Multi-user. Target Service Name did not exist.
8. Bypassing all systemctl commands allowed the script to be completed. Running dpgk —configure-a did not and could not fix syntax errors
9. A December 7 patch left the First Light process in limbo. Several service files were corrupted.
This study is completed. The system is working as advertised. Thank you for your time.
At this point, NGINX is missing noVNC. The service noVNC is dependent on vncserver-x11-service. The service vncserve-x11-service is serving 192.168.200.26, 127.0.0.1, AstroBerry.local, and AstroBerry. RealVNC is servicing the same resources. Hence, a conflict exists.
I can run this dependent group sans the service. First Light works as advertised. As a service, the noVNC does not see its partner.
I have used Type=forking to assist with services being enabled but inactive. Using “ systemctl start service” does not load the service into memory as in terminate and stay ready.
Apparently, noVNC was working on December 7, 2019. This date is the last save date of its log file. After this date, First Light stopped working. The date on the log file tells me when noVNC is running. The vncserver-x11 logfile is filled with these messages:
<11> 2020-01-13T11:56:06.601Z astroberry vncserver-x11: AgentInitCheck: no response from agent
The NGINX log file is filled with these messages:
2020/01/12 21:35:13 [error] 569#569: *8 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.200.26, server: _, request: "GET /indiwebmanager/ HTTP/1.1", upstream: "http://127.0.0.1:8624/", host: "192.168.200.26", referrer: "http://192.168.200.26/desktop/"
This looks like NGINX is attempting to get its stuff from RealVNC. The service vncserver-x11 is running. I will investigate the user context of this trio.
Wow. I have it partially working. Here is what I had to do. I commented out all systemctl commands at the end of POSTINST. Then and only then did the wui install completed successfully. I then began to review the the service configurations for INDIWEBMANAGER, GPSPANEL. NOVNC, INDIWEBMANAGERAPP, and NGINX.
Type =forked is what these services require except for NGINX. NGINX requires SUDO help to be enabled. Now, indiwebmanager successfully runs from rlancaste. That is good. Upon reboot, services stay resident. Ok. To enable, I ran every service under AstroBerry and supplied the password 10 times. Ctrl-c was used to close the service session to start the next application.This work complete the enabling of all service.
The problem now is NGINX does no know where astroberry.local/desktop is . This yields the 502 error by NGINX after clicking the big green button. Apt is now working and 2.0.3 is installed. To recap, the wui is updated successfully to 2.0.3. All service were change to Type=forked. And, NGINX required SUDO help to be registered enabled. Now, figure out the 502 error.
What are the error codes for IndiServer?
I have indiwebmanager throwing: Warning: terminating indiserver failed with exit code 1. Thank you.
Ok. Interesting opinions. I peered behind the curtains and found
/bin/bash -e /bar/lib/dpkg/info/astroberry-server-Wuxi.postinst configure 2.0.3
I used geany to view the postint script. Everything works up until
#Activate basic services
This is where the script stumbles on a RPI3B+. I will investigate why systemctl requires a password to enable and restart when not root. I also will investigate why as root enable and restart happens during the terminal session.
Under root, the entire session must be root also to operate anything. That isn’t good.
It should load into memory and disappear into a command prompt. But to enable and restart requires root.
Running Units must not be in the right context for these services. Contexts Nobody, root, and astroberry load the service into memory as root and require a password when not. In both cases, the terminal is taken over by enabling and restarting the service.
When I look at other services, I see nothing that suggests those services are any different. Enable or restart with any of them doesn’t become a terminal service.
The postinit script executes 5 systemctl enable and restart commands. Of the 5 enable and restart command, 2 passwords are needed per session or a new terminal window per session is required. That seems silly.
Ubuntu-Mate doesn’t have this problem. I have restarted stuff in memory in Ubuntu-Mate. Not once did the restart take over the terminal session.
With Raspbian and as root, the terminal service would not be seen by the non-root user. Context is important.
Root cause has been identified. Now for a solution.
Time to look at Raspbian service accounts. Where is System Account when you need it. LOL. Enjoy.
For a baker, half baked is a state of confusion. My system was built from an image. Two vendor applications for my equipment are added to any build. I did install Synaptic, Logs, and SysLogs as tools like these were missing.
My system is dependent on apt. When I elected to try First Light, I found my system caught in at least three revisions. One critical piece was astroberry-server-wui. Synaptic and apt said I had 2.0.1 and 2.02. I have been noticing during updates of this and that having to abort. A reboot clears logs. When I checked GitHub, 2.03 was available.
With several critical components of First Light not operational, I used Synaptic to see the dependencies and the artifacts provided by this package. Ok, I do need to upgrade.
I attempted to conduct a targeted reinstallation of astroberry-server-wui to get to 2.0.3. I am stuck at this step. I am guessing that a conditional endless loop is in the package. 98% at 6 hours says an endless loop is possible. Giving the AstroBerry password, hitting return, nor giving the PI password breaks the loop. It locks Synaptic and apt up. A reboot by command or by switch are the options. I will submit a bug report.
Astroberry-server-wui repair looks like it has a problem. Version 2.0.3 hangs up at 98%. This is right after this script status.
Created SYMLINK /etc/systemd/system/multi-user.target.wants/gpspanel.service -> /etc/systemd/system/gpspanel.service.
Hours occur and 98% never goes to 100%. To me, indiwebmanager and astropanel are missed. The previous actions do not have a SYMLINK for indiwebmanager and astropanel.
Ok, both service files are there for indiwebmanager and astropanel. They look good. The indiwebmanager is completely different from what I edited. My file contains InDI-web -v and User=root. The new file contains InDI-web -l and User=astroberry. Interesting.
I would like to know which update corrupted wui as well. Thank you for the other pieces NGINX is looking for. I would use systemd to list the UNIT services running. Astropanel.service, Indiwebmanager, and gpspanel were all down. To me, this looked like a half backed install of astroberry-server-wui. All of the devices appeared disabled.
When I finally “fixed” the service file for indiwebmanager, I was able to run InDI-web -v from a command window only. The service never ran properly. It would hang up. To me, this looked like a half backed install. Too many NGINX pieces were not operating. The .service files were corrupted. They looked overlaid as merged files, e.g. Repeated information.
My KSTARS with VNC was working fine. The NGINX was the sticky item. I was content with VNC access. I wanted to see the NGINX piece work.
I am attempting a repair of the wui, e.g. remove and reinstall. Looks like some steps were missed.
AstroBerry:8624 and AstroBerry.local: 8624 produce the same results when on the host. Astroberry.local is not going anywhere but 502 error. The service indiwebmanager does not run without an account and password. Indiwebmanagerapp claims that Python and InDI-web are incomplete.
To me, an update has disrupted AstroBerry-server-Wui. Nothing seems to be working as described in this article. Before I started using INDI, I was attempting to use AstroHub. NGINX was a problem then as now. Updates disrupted that configuration also. Unfortunately, Russia has indicted the management team with giving away state secrets. Has astronomy become a deadly weapon?