×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

How to get the first light with Astoberry Server

  • Posts: 389
  • Thank you received: 15
Hello Kaczorak,

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 baked 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 baked 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 broken or messed up during an update.
Last edit: 4 years 2 months ago by John Robison.
4 years 2 months ago #47853

Please Log in or Create an account to join the conversation.

  • Posts: 389
  • Thank you received: 15
Hello,

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.
4 years 2 months ago #47855

Please Log in or Create an account to join the conversation.

  • Posts: 389
  • Thank you received: 15
Hello,

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.
4 years 2 months ago #47884

Please Log in or Create an account to join the conversation.

  • Posts: 983
  • Thank you received: 375
John, it's very kind of you with all these proverbs and other great remarks. However most of them are somehow missing the point.
Just get vanilla Raspbian Buster with desktop directly from raspberrypi.org and compare what is the difference between Astroberry and the original image. Moreover, just install it and see yourself how many packages need to be updated right after installation. This is NORMAL for every system outhere. You expectation to have up to date system in the image is out of blue. None system is provided like that. Astroberry is not different in this matter and will never be.

Forgive me, but I just do not get how come your system is missing syslog and clears the logs after reboot. The most probable cause is that your SD card is dying. I will not get into convincing you that you are just wrong blaming Astroberry.

There are a few options for you and issues you have:
1) Move to other system and forget about Astroberry
2) Build your own system, which will do whatever you want it to do
3) Use other users' help in your particular issues - there's over 1200 of them in 60 countries. I'm sure someone can help you out, especially that they must somehow deal with this poor system, because they don't report bugs you're discussing here.

Last but not least - this is open source community and open source software. You have access to all the sources and full entitlement to submit patches, improvements and fix bugs to help other users. I would be really glad if you do.
4 years 2 months ago #47889

Please Log in or Create an account to join the conversation.

  • Posts: 389
  • Thank you received: 15
Hello,

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.
4 years 2 months ago #47905

Please Log in or Create an account to join the conversation.

  • Posts: 983
  • Thank you received: 375
Remove "-e" from postinstall script. It will let you complete the script.
I believe that postinstall script requesting a password at any stage means that you are running it as a regular user, not root. Running apt with escalated privileges i.e. sudo apt install whatever runs the debian installation scripts as root, so no password is necessary.
Could you record a screencast of what is happening on your side?
4 years 2 months ago #47909

Please Log in or Create an account to join the conversation.

  • Posts: 389
  • Thank you received: 15
Hello,

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 completes the enabling of all services.

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.
Last edit: 4 years 2 months ago by John Robison.
4 years 2 months ago #47940

Please Log in or Create an account to join the conversation.

  • Posts: 389
  • Thank you received: 15
Hello,

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[963]: 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.
4 years 2 months ago #47987

Please Log in or Create an account to join the conversation.

  • Posts: 389
  • Thank you received: 15
Hello,

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

Nginx
Vncserver-x11-serviced
NoVNC
Astropanel
Gpspanel
Indiwebmanager
Indiwebmanagerapp
VirtualGPS

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

Before

After=multi-user.target vncserver-x11-serviced

After

After=vncserver-x11-serviced

Additional Critical Path services had this configuration issue. They are GPSPANEL, ASTROPANEL, and VIRTUALGPS. Starting any of these with the fix will cause an infinite search for a non existant service.

Now, everything works.

Findings:

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 input 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.
Last edit: 4 years 2 months ago by John Robison.
4 years 2 months ago #47993

Please Log in or Create an account to join the conversation.

  • Posts: 34
  • Thank you received: 3
Hi Radek,

where did you hide the Ubuntu Date and Time-Setting ?

When I´m in the Field with no internet, I need to set the time manualy.

I´ve googled for this, but at astroberry I don´t find this :
Change the date and time
Open the Activities overview and start typing Settings.
Click on Settings.
Click Details in the sidebar.
Click Date & Time in the sidebar to open the panel.
If you have the Automatic Date & Time switch set to on, your date and time should update automatically if you have an internet connection.

CS
Reiner
4 years 2 months ago #47994

Please Log in or Create an account to join the conversation.

  • Posts: 389
  • Thank you received: 15
Hello,

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.
4 years 2 months ago #48010

Please Log in or Create an account to join the conversation.

  • Posts: 983
  • Thank you received: 375

Unfortunatelly Raspbian Desktop Environment (LXDE) does not include a standard tool to set the date and time. The easiest way is to issue a command on the command line, the following are some examples...
sudo date -s "Mon Aug  12 20:14:11 UTC 2014"
sudo date 06211345
sudo date –s “June 21 13:45”
sudo date –s “21 June 13:45 2012”
sudo date –s “13:45 June 21”
sudo date –s “Jun 21 1:45pm”
sudo date –s “Next Thursday 13:45

It's actually good change request... I will need to add it to the system in a future release.
4 years 2 months ago #48017

Please Log in or Create an account to join the conversation.

Moderators: Radek Kaczorek
Time to create page: 1.270 seconds