Unexpected token >

[dennorske]

SyntaxError: Unexpected token < in JSON at position 0

That is one of the errors i get during installation.

Not sure whether to report it for the docker image or for the software itself-

Here is some adittional info:

[Wed Jul 24 18:24:32.363439 2019] [php7:notice] [pid 17] [client 172.17.0.1:42804] G\\DBException: SQLSTATE[HY000] [2002] Connection refused in /var/www/html/lib/G/classes/class.db.php:98\nStack trace:\n#0 /var/www/html/lib/G/classes/class.db.php(109): G\\DB->__construct()\n#1 /var/www/html/app/loader.php(52): G\\DB::getInstance()\n#2 /var/www/html/index.php(20): include_once('/var/www/html/a...')\n#3 {main}, referer: https://pics.xxx.xxx/

172.17.0.1 - - [24/Jul/2019:18:24:32 +0000] "POST /index.php HTTP/1.1" 500 372 "https://pics.xxx.xxxx/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.142 Safari/537.36"

Could you show me in the right direction regarding this?

[rodber]

The installer checks the DB connection when you enter the credentials. After that, the system provides that info "into" the actual application. If you get a connection refused in that stage then is something that is beyond the software as it is supposed that the DB has been already check and validated.

To put it in more simple words, out or nowhere the database is refusing connections.

[dennorske]

Yes that is strange, i tried re-doing it three times now, also tried changing the credentials of the user for the database instance. Is it fully compatible with MariaDB 10.4? Could there be some compatibility issues causing the issue later in the process?

Thanks for the fast response btw

[rodber]

Since this is Docker, you should pay attention to the DB container logs. You should actually check if the installer creates the app/settings.php file.

[dennorske]

I can confirm that the file is getting created under app/settings.php .. 🐫 I tested with a different mysql engine as well, and i get the same issue.

Can i somehow go on manually from this point? What steps are remaining after this

[rodber]

If that file exists then the problem is the DB container.

[dennorske]

Hi again Rodolf - I appreciate you taking your time to look through the issues in here.

I just tried a local Database on the system, I am unable to complete the docker :installer image. I am out of ideas what to try at this point - I wish i could provide more logs or something but I can't see anything useful.

I was able to install Chevereto using :1.1.3 image instead - without any hiccups. I am up and running but still I am wondering why it didn't work correctly with the installer.

Does it matter I am behind a reverse proxy?

[rodber]

I'm helping here because @tanmng makes Docker containers that work with Chevereto. I'm the main Chevereto developer, that's why I'm participating.

This is a repository, not a ticketing system. The goal is to improve the software (doesn't matter which) for everybody.

I believe that @tanmng has all the info he needs to carry his own checks. He may also need your input to detect what could be wrong here. In any case, please note that the interest here is the reliability of the docker container and to detect what went wrong and how that gets triggered.

[tanmng]

@dennorske Hello,

Sorry, due to my work I receive a rather hight volume of Github notification so news about the repo got buried.

Did you get a chance to debug your issue any further?

[tanmng]

@dennorske So, I got some time and looked a bit more into this. Here's some information

Your installed encountered an issue after it printed out Creating app/settings.php file

I checked over the source of the installer script and extracted the relevant section

      installer
        .fetchCommonInit()
        .then(data => {
          installer.log("Creating app/settings.php file");
          let = params = Object.assign({filePath: runtime.absPath + "app/settings.php"}, installer.data.db)
          return installer.fetch("createSettings", params);
        })
        .then(data => {
          installer.log("Performing system setup");
          let params = {
            username: installer.data.admin.username,
            email: installer.data.admin.email,
            password: installer.data.admin.password,
            email_from_email: installer.data.email.emailNoreply,
            email_incoming_email: installer.data.email.emailInbox,
            website_mode: \'community\',
          };
          return installer.fetch("submitInstallForm", params);          
        })

From the look of it, when the installed tried to perform the step createSettings (inside the container), it encountered an error and printed out the error message.

Your browser, trying to parse that error message as JSON, also failed (that explains the error you got in your console).

inside your browser JS, there's an object called installer that has the fetchOnAlways defined as follow

fetchOnAlways: function(data) {
installer.log(data.message);
},

Ultimately, that means whenever the installer object receives anything from the server it will have to print out the message field from it. Given that the text body was not a valid JSON body -> this fails

---

continued

Looking further at the Networking tab of my browser, I think I might have understood what's the issue.

It's a bit complicated so I'll try to explain this in as much detailed as possible.

Form the javascript snippet I shared above, apparently, after the step createSettings, installer is supposed to perform submitInstallForm. I believe the install form that Rodolfo refers to here is the one below

Below is a screenshot of my Networking tab during installation process

I think, after installer finishes making a bunch of API calls to the Docker container, it will try to load the website once more and then submit the install form.

When installer tries to load the website, it got the normal HTML reponse (as shown in here)

Unfortunately, because installer is set up to print the message field from any response it receives from the server, it always tries to parse the response body as JSON and fails (because this time it's an HTML text, not JSON).

TLDR: I think the installer tried to parse a normal HTML text as JSOn and fails.

I will try to ping Rodolfo and discuss this further with him and get a new + fixed installer script

[dennorske]

Thank you for the information and very well compiled explanation. I was unable to solve it at the time and ended up using some other image for the installation. Please let me know if I can be of further assistance for the above problem

[tanmng]

@dennorske Thanks for the information. I'm glad you were able to run the application using another tag.

I think this is the same error as this issue on the installer repo. I will try to find some time afterwork to try and run + debug the installer a bit further.

[dennorske]

That looks very similar to this yes. Can you reproduce the same behaviour by testing?