Daemon error.

[NigelNapier]

Daemon hangs at checking version.

[NigelNapier]

I did a test install but the BETA installer is still using beta6 instead of beta7, hence my original issue.

[allebb]

Can you confirm that you can run 'lsb_release' from the command line? - Or
does that result in a 'command not found' error?

On 30 October 2014 08:18, Nigel Caldwell notifications@github.com wrote:

PHP Warning: Illegal string offset 'version' in
/etc/sentora/panel/modules/updates/hooks/OnDaemonDay.hook.php on line 27

Install done just now on Ubuntu 14.04 LTS x86 Minimal.

Daemon just hangs at the above line.

—
Reply to this email directly or view it on GitHub
#83.

[5050]

I'm looking for the cause of the error you have.
It does not happens on my test server nor on DO, but happens on a VM.
It seems (to be confirmed) because under (still) unknow reason the updater routine does not retrieve the xml file from the server API.
I was "out of service" lasts days (overdose of sentora), I 'll be beck on it before end of week..

[allebb]

XML? Oh, sorry I thought we was taking about the JSON 'version check' API

• Do you believe this is in fact the module XML configuration files then
  that are not returning a value for the version number? - Can you provide
  any more details/a screenshot Nigel?

On 30 October 2014 11:23, Pascal Peyremorte notifications@github.com
wrote:

I'm looking for the cause of the error you have.
It does not happens on my test server nor on DO, but happens on a VM.
It seems (to be confirmed) because under (still) unknow reason the updater
routine does not retrieve the xml file from the server API.

—
Reply to this email directly or view it on GitHub
#83 (comment).

[NigelNapier]

root@********:~# lsb_release -a

No LSB modules are available.

Distributor ID: Ubuntu

Description: Ubuntu 14.04.1 LTS

Release: 14.04

Codename: trusty

[NigelNapier]

It gets to checking for the latest Sentora version and hangs.

I believe that this is the JSON file?

[allebb]

Yeah, the version checker API returns JSON,- However, at present the
Sentora module 'local' versions are stored in XML files... so could be that
it's actually getting the correct version from the web API but when the
Daemon goes to check each module version it then gets screwed up...

Anyways, lets just assume for now that the problem is with the core Sentora
version...

The web service API looks ok to me:
http://api.sentora.org/latestversion.json

Might be worth checking if your server can load//retrieve the data from
that URL? - Eg. no firewall blocking it or DNS issue etc.

On 30 October 2014 11:48, Nigel Caldwell notifications@github.com wrote:

It gets to checking for the latest Sentora version and hangs.

I believe that this is the JSON file?

—
Reply to this email directly or view it on GitHub
#83 (comment).

[NigelNapier]

The daemon's still not running either.

I've restarted my server 5 times so far and my domains are still not active. I have reported this in another bug.

From what I have read I believe it's somethng to do with cron not working still.

[allebb]

Can for force a 'Daemon Day run' from the Control Panel and then execute
the Daemon manually and then provide me with the output/screenshot so I
have something to work with?

On 30 October 2014 12:02, Nigel Caldwell notifications@github.com wrote:

The daemon's still not running either.

I've restarted my server 5 times so far and my domains are still not
active. I have reported this in another bug.

From what I have read I believe it's somethng to do with cron not working
still.

—
Reply to this email directly or view it on GitHub
#83 (comment).

[5050]

There was two errors.

1. the http://api.sentora.org/latestversion.json returns now an object without array, and I corrected the module to parse it correctly. (Note : I touched the api to provide exactely the same result than zpanel api, but it screwed the website, so I rolled it back and adapted the module to the new format.)
   This error is corrected and pushed on GitHub core, but I'm not sure it is already in the tagged version of the core.

2. The remaining problem concern the "api" http://www.zpanelcp.com/uds/core.xml that is referenced in each module xml file.
   It seems that under some case that link is not handled correctly and provoque something like file not found or like result empty (i do not remember the exact message).

That is why I asked to motters infos about update and store in the council exchanges, with idea to replace it by a temporary other (to be writen) in the store.sentora.org domain. (see subject : Problem with modules update refs in XML files)

It will not solve the problem of this file not returned, but it will give us back the control of its content, and it would enable to get a version number based on module name instead on only one same version for all modules.

[5050]

We are lucky : I found one of the last log of my installs. It contains :

START checking for any avaliable module updates..
Checking update for mod: Aliases
The remote file does not exist.
Checking update for mod: Apache Config
The remote file does not exist.
Checking update for mod: Backup
The remote file does not exist.

... and so on.

Note : the VM have access to the internet and downloaded all other file correctly....

I've extracted a set of file from the panel and write a caller in order to do tests. I saw that all was working fine on my NAS, but I have had not time enough to debug it on the same VM which produced the errors. Would be done soon.

[5050]

the faulty line is
$getupdateinfo = fs_filehandler::ReadFileContents($updateurl);
it waits very long and then returns an empty content.
(Note: $updateurl value is correct, it is "http://www.zpanelcp.com/uds/core.xml")

I tryed to replace it by:
$getupdateinfo = file_get_contents($updateurl);
with same result.

The error log file shows :
[Thu Oct 30 14:31:02.734848 2014] [:error] [pid 1787] [client 192.168.1.10:55031] PHP Warning: file_get_contents(http://www.zpanelcp.com/uds/core.xml): failed to open stream: Connection timed out in /var/sentora/hostdata/zadmin/public_html/u14sentora_fr/index.php on line 45

Run within a console of the same VM, a command wget http://www.zpanelcp.com/uds/core.xml resolves the domain immediately with this return:

• Résolution de www.zpanelcp.com (www.zpanelcp.com)... 2607:5500:1000:1::, 23.254.192.6
• Connexion vers www.zpanelcp.com (www.zpanelcp.com)|2607:5500:1000:1::|:80...

then wait a very long time (around to 2 minutes) and finally success to get the file content.

PHP losts its content because of its time-out occurs before 2 minutes, and the installer seems locked because there is 41 module to get the version -> more than 41 minute to wait !

Runned from my NAS SSH console (linux_synology), the wget do exactly the same 2 minutes wait and then response,

Runned from my prod server SSH (also under Ubuntu14 like the VM) it is immediate.

Queried from firefox, the response to same url is also immediate.

It ssems the problem comes from something in the client environment, but I have no idea about what to search for.

Any idea ?

[5050]

Last info for today : on my VM and on my nas, a wget to any other link (like github) grabs the file immediately.

I wonder if the problem cannot come from the server zpanelcp.com itself...

I installed a very small replacement file (that returns same content than zpanelcp url) on our sentora store domain at url
http://store.sentora.org/module_version.php
and with it the response is always immediate independently of client config. !!!

I propose to replace all refs to http://www.zpanelcp.com/uds/core.xml by this url:
http://store.sentora.org/module_version.php?module=(module-name)
so as soon as the store will be ready we can replace the file on the server by a real script to handle modules versions and enable modules update on per module basis.

[NigelNapier]

Um already been working on the modules, (there is a pull request already), the modules have been part changed.

[5050]

After discussion in Council, we adopted to do a first temporary change of the module.xml files, until motters have progress enough in the future store management.
Once it will be ready, a last definitive change will be done with an updater because it will very probably require also important changes in modules "updates".
I just updated the xml changes according to this. I will push today a few pending pulls and other changes that are still waiting here in installer and core to correct a few other bugs and we will ready to go to test and test again.

[NigelNapier]

@5050 @bobsta63

I can confirm that latest fixes are now running the Daemon during install as it should.
Working on CentOS 7 & Ubuntu 14.04 LTS x86 Minimal.
I'll be conducting further testing later on today.