problems with BaseX under OpenShift (connection failed on port 15007)
I'm running into a problem that perhaps others here can help with. It appears to be almost identical to the problem reported by "P.C." on 5 March 2014 under the subject line 'BaseX server.close() "Connection refused" in Openshift' [1]; the mail record in the basex-talk archive doesn't show a resolution to P.C.'s problem. The main difference I see is that P.C. was deploying BaseX under Tomcat 7 on OpenShift, and I'm using Andy Bunce's quickstart method. [1] https://www.mail-archive.com/basex-talk%40mailman.uni-konstanz.de/msg03861.h... I'm experimenting with Andy Bunce's BaseX quick-start for OpenShift, which I like a lot, and I am experiencing the following sequence of events: 1 Following the instructions at [2], I use rhc to make a new app, add the Quodatum repository as a remote, merge it into the application source, and push the result to OpenShift. (Note: no changes made between the commands "git pull -s recursive -X theirs upstream master" and "git push origin master". The first time I tried it, I did change the admin password, but I thought that that might have something to do with the problem, so I omitted that step for this test.) [2] https://github.com/Quodatum/openshift-basex-quick-start/ The OpenShift app is now available as promised at the URI indicated in [1], namely http://TestAPP-CMSMcQ.rhcloud.com/ (except that TestAPP is not really the name of the app, and CMSMcQ is not the name of the domain). It's a very nice looking console app. 2 I make some change -- any change -- to a file in the repository. To keep things simple, I'll add a comment line reading (: Kilroy was here :) to the file $app-name/basex/repo/quodatum/basex/env.xqm. I'm pretty sure I didn't break anything in the env.xqm file in making the change, and I didn't change anything in any other file. 3 I check the change in to the local git repository: # confirm that we have not touched anything else git status # commit the change git add basex/repo/quodatum/basex/env.xqm git commit -m "Vacuous change to env.xqm, just to have something to check in" 4 I attempt to push the change to the deployed app. The response is shown below (in the extract below, 'Salerno' is the local name of the machine, 'TestAPP' stands in for the name of the test application, and "CMSMcQ" for the OpenShift domain -- I've changed them here, because as can be seen from the log below, the app is currently open to anyone who knows the default admin userid and password). Salerno:TestAPP cmsmcq$ git push origin master Counting objects: 7, done. Delta compression using up to 8 threads. Compressing objects: 100% (5/5), done. Writing objects: 100% (7/7), 649 bytes | 0 bytes/s, done. Total 7 (delta 2), reused 0 (delta 0) remote: Stopping DIY cartridge remote: HOST: 127.12.13.129 remote: PORT: 15005 remote: DEBUG: true remote: USER: admin remote: SERVERHOST: 127.12.13.129 remote: STOPPORT: 15007 remote: SERVERPORT: 15005 remote: PASSWORD: admin remote: java.io.IOException: Connection failed (port: 15007). remote: at org.basex.BaseXHTTP.stop(BaseXHTTP.java:367) remote: at org.basex.BaseXHTTP.stop(BaseXHTTP.java:180) remote: at org.basex.BaseXHTTP.<init>(BaseXHTTP.java:94) remote: at org.basex.BaseXHTTP.main(BaseXHTTP.java:50) remote: Connection failed (port: 15007). remote: An error occurred executing 'gear prereceive' (exit code: 1) remote: Error message: CLIENT_ERROR: Failed to execute: 'control stop' for /var/lib/openshift/568d73d67628e13ca2000004/diy remote: remote: For more details about the problem, try running the command again with the '--trace' option. To ssh://568d73d67628e13ca2000004@TestAPP-CMSMcQ.rhcloud.com/~/git/TestAPP.git/ ! [remote rejected] master -> master (pre-receive hook declined) error: failed to push some refs to 'ssh://568d73d67628e13ca2000004@TestAPP-CMSMcQ.rhcloud.com/~/git/TestAPP.git/' Salerno:TestAPP cmsmcq$ I've logged in to the application using ssh and run the basexhttp stop command manually, and what one gets then is essentially the same. I think the root of the matter here is the line reading "remote: java.io.IOException: Connection failed (port: 15007)", but I'm having trouble thinking of a fix. One could imagine that OpenShift doesn't like application code using a port like 15007. But since it seems to have no trouble with BaseX using 15005, for the SERVERPORT, that doesn't seem to make sense. One could suppose that BaseX isn't actually listening on port 15007. The debugging output produced by -d, however does seems to show that BaseX knows that port 15007 is the stop port. Or does it? Perhaps it means only that BaseX has successfully parsed the -s option on the 'stop' command, which reads: ${OPENSHIFT_DATA_DIR}/basex/binbasexhttp -d \ -n ${OPENSHIFT_DIY_IP} -h ${OPENSHIFT_DIY_PORT} \ -p ${PORT_DATABASE} -s ${PORT_STOP} \ -U ${BASEX_USER} -P ${BASEX_PASSWORD} \ stop which in turn expands to .../basex/binbasexhttp -d \ -n 127.12.13.129 -h 8080 \ -p 15005 -s 15007 \ -U admin -P admin \ stop The startup command uses the same values for the -p and -s options, so it seems plausible that the start command is successfully setting the port. Several questions arise in connection with this problem, apart from the obvious and most important one, namely Q1 Does anyone reading this list understand where the problem might lie? The others that occur to me are: Q2 Is there a server command or an admin query that will show what ports a running instance of BaseX is listening to? Or would that be too broad a security violation? (It would be nice to confirm that BaseX is actually listening for a stop signal on port 15007. Q3 A search through the file system of the application shows that logs are being written to $APPLICATION_HOME/app-root/data/basex/data/.logs/ -- is there any way to find out from a running server what directory it's writing the logs to, to save the trouble of sshing to the application server and running find . -print0 | xargs -0 grep "User was logged in" or the equivalent? The admin:logs() function was helpful, but it would have been even more helpful if it had helped me find the logs directory. Of course, I see now, looking at the documentation, that logs are always (? or only by default?) written to $DATABASE_DIRECTORY/.logs -- if I had been confident of knowing what directory was the database directory in this (still unfamiliar) setup, I would have known where to look. Q4 Is there a command or admin-module query that indicates what directories BaseX regards as the base directory and the database directory? It could be very helpful, if it's not regarded as too great a security risk, for users trying to set things up in a new configuration. Q5 OpenShift's documentation claims that it really wants application logs to go into $APPLICATION-HOME/app-root/logs/ -- is there any way to induce BaseX to write its logs there? The main advantage I can currently see is that it then becomes possible to examine them with the OpenShift rhc tools. Any light anyone can shed on these issues would be very welcome. Thanks! Michael Sperberg-McQueen -- **************************************************************** * C. M. Sperberg-McQueen, Black Mesa Technologies LLC * http://www.blackmesatech.com * http://cmsmcq.com/mib * http://balisage.net ****************************************************************
Hi Michael, I get the same result. I believe the problem is [1]. S_LOCALHOST is "localhost". Maybe this needs to be HOST or SERVERHOST. /Andy https://github.com/BaseXdb/basex/blob/master/basex-api/src/main/java/org/bas... On 6 January 2016 at 21:54, C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com
wrote:
I'm running into a problem that perhaps others here can help with. It appears to be almost identical to the problem reported by "P.C." on 5 March 2014 under the subject line 'BaseX server.close() "Connection refused" in Openshift' [1]; the mail record in the basex-talk archive doesn't show a resolution to P.C.'s problem. The main difference I see is that P.C. was deploying BaseX under Tomcat 7 on OpenShift, and I'm using Andy Bunce's quickstart method.
[1] https://www.mail-archive.com/basex-talk%40mailman.uni-konstanz.de/msg03861.h...
I'm experimenting with Andy Bunce's BaseX quick-start for OpenShift, which I like a lot, and I am experiencing the following sequence of events:
1 Following the instructions at [2], I use rhc to make a new app, add the Quodatum repository as a remote, merge it into the application source, and push the result to OpenShift. (Note: no changes made between the commands "git pull -s recursive -X theirs upstream master" and "git push origin master". The first time I tried it, I did change the admin password, but I thought that that might have something to do with the problem, so I omitted that step for this test.)
[2] https://github.com/Quodatum/openshift-basex-quick-start/
The OpenShift app is now available as promised at the URI indicated in [1], namely http://TestAPP-CMSMcQ.rhcloud.com/ (except that TestAPP is not really the name of the app, and CMSMcQ is not the name of the domain). It's a very nice looking console app.
2 I make some change -- any change -- to a file in the repository. To keep things simple, I'll add a comment line reading
(: Kilroy was here :)
to the file $app-name/basex/repo/quodatum/basex/env.xqm.
I'm pretty sure I didn't break anything in the env.xqm file in making the change, and I didn't change anything in any other file.
3 I check the change in to the local git repository:
# confirm that we have not touched anything else git status # commit the change git add basex/repo/quodatum/basex/env.xqm git commit -m "Vacuous change to env.xqm, just to have something to check in"
4 I attempt to push the change to the deployed app. The response is shown below (in the extract below, 'Salerno' is the local name of the machine, 'TestAPP' stands in for the name of the test application, and "CMSMcQ" for the OpenShift domain -- I've changed them here, because as can be seen from the log below, the app is currently open to anyone who knows the default admin userid and password).
Salerno:TestAPP cmsmcq$ git push origin master Counting objects: 7, done. Delta compression using up to 8 threads. Compressing objects: 100% (5/5), done. Writing objects: 100% (7/7), 649 bytes | 0 bytes/s, done. Total 7 (delta 2), reused 0 (delta 0) remote: Stopping DIY cartridge remote: HOST: 127.12.13.129 remote: PORT: 15005 remote: DEBUG: true remote: USER: admin remote: SERVERHOST: 127.12.13.129 remote: STOPPORT: 15007 remote: SERVERPORT: 15005 remote: PASSWORD: admin remote: java.io.IOException: Connection failed (port: 15007). remote: at org.basex.BaseXHTTP.stop(BaseXHTTP.java:367) remote: at org.basex.BaseXHTTP.stop(BaseXHTTP.java:180) remote: at org.basex.BaseXHTTP.<init>(BaseXHTTP.java:94) remote: at org.basex.BaseXHTTP.main(BaseXHTTP.java:50) remote: Connection failed (port: 15007). remote: An error occurred executing 'gear prereceive' (exit code: 1) remote: Error message: CLIENT_ERROR: Failed to execute: 'control stop' for /var/lib/openshift/568d73d67628e13ca2000004/diy remote: remote: For more details about the problem, try running the command again with the '--trace' option. To ssh:// 568d73d67628e13ca2000004@TestAPP-CMSMcQ.rhcloud.com/~/git/TestAPP.git/ ! [remote rejected] master -> master (pre-receive hook declined) error: failed to push some refs to 'ssh:// 568d73d67628e13ca2000004@TestAPP-CMSMcQ.rhcloud.com/~/git/TestAPP.git/' Salerno:TestAPP cmsmcq$
I've logged in to the application using ssh and run the basexhttp stop command manually, and what one gets then is essentially the same.
I think the root of the matter here is the line reading "remote: java.io.IOException: Connection failed (port: 15007)", but I'm having trouble thinking of a fix.
One could imagine that OpenShift doesn't like application code using a port like 15007. But since it seems to have no trouble with BaseX using 15005, for the SERVERPORT, that doesn't seem to make sense.
One could suppose that BaseX isn't actually listening on port 15007. The debugging output produced by -d, however does seems to show that BaseX knows that port 15007 is the stop port. Or does it? Perhaps it means only that BaseX has successfully parsed the -s option on the 'stop' command, which reads:
${OPENSHIFT_DATA_DIR}/basex/binbasexhttp -d \ -n ${OPENSHIFT_DIY_IP} -h ${OPENSHIFT_DIY_PORT} \ -p ${PORT_DATABASE} -s ${PORT_STOP} \ -U ${BASEX_USER} -P ${BASEX_PASSWORD} \ stop
which in turn expands to
.../basex/binbasexhttp -d \ -n 127.12.13.129 -h 8080 \ -p 15005 -s 15007 \ -U admin -P admin \ stop
The startup command uses the same values for the -p and -s options, so it seems plausible that the start command is successfully setting the port.
Several questions arise in connection with this problem, apart from the obvious and most important one, namely
Q1 Does anyone reading this list understand where the problem might lie?
The others that occur to me are:
Q2 Is there a server command or an admin query that will show what ports a running instance of BaseX is listening to? Or would that be too broad a security violation? (It would be nice to confirm that BaseX is actually listening for a stop signal on port 15007.
Q3 A search through the file system of the application shows that logs are being written to $APPLICATION_HOME/app-root/data/basex/data/.logs/ -- is there any way to find out from a running server what directory it's writing the logs to, to save the trouble of sshing to the application server and running
find . -print0 | xargs -0 grep "User was logged in"
or the equivalent? The admin:logs() function was helpful, but it would have been even more helpful if it had helped me find the logs directory.
Of course, I see now, looking at the documentation, that logs are always (? or only by default?) written to $DATABASE_DIRECTORY/.logs -- if I had been confident of knowing what directory was the database directory in this (still unfamiliar) setup, I would have known where to look.
Q4 Is there a command or admin-module query that indicates what directories BaseX regards as the base directory and the database directory? It could be very helpful, if it's not regarded as too great a security risk, for users trying to set things up in a new configuration.
Q5 OpenShift's documentation claims that it really wants application logs to go into $APPLICATION-HOME/app-root/logs/ -- is there any way to induce BaseX to write its logs there? The main advantage I can currently see is that it then becomes possible to examine them with the OpenShift rhc tools.
Any light anyone can shed on these issues would be very welcome.
Thanks!
Michael Sperberg-McQueen
-- **************************************************************** * C. M. Sperberg-McQueen, Black Mesa Technologies LLC * http://www.blackmesatech.com * http://cmsmcq.com/mib * http://balisage.net ****************************************************************
On Jan 6, 2016, at 5:18 PM, Andy Bunce wrote:
Hi Michael,
I get the same result. I believe the problem is [1]. S_LOCALHOST is "localhost". Maybe this needs to be HOST or SERVERHOST.
/Andy
https://github.com/BaseXdb/basex/blob/master/basex-api/src/main/java/org/bas...
Thank you; it's nice to confirm that the problem can be reproduced. I think [2] may lend support to your conjecture: it appears to be starting the StopServer with STOPPORT and SERVERHOST as parameters. But there are several stop() methods in the code and I shouldn't pretend I understand which is actually calling which. [2] https://github.com/BaseXdb/basex/blob/master/basex-api/src/main/java/org/bas... I notice that these pointers are to the current code, which differs a bit from the code of 8.3 dated 23 September, but there, too, the constructor for BaseXHTTP creates a StopServer instance passing SERVERHOST and STOPPORT as arguments, and the static stop() method opens a socket on LOCALHOST, not SERVERHOST. If that matters. I have now also tested with 8.2.3 and 8.0.1 (by changing the URI in BASEX_VERSION in the config file -- thanks for making it so easy to reconfigure!) and find that both of these versions also exhibit the problem. The wording of the error message changes a bit; in 8.0.1. it says "Connection refused", not "Connection failed", and does not specify a port number. But it's pretty clearly the same issue. Michael -- **************************************************************** * C. M. Sperberg-McQueen, Black Mesa Technologies LLC * http://www.blackmesatech.com * http://cmsmcq.com/mib * http://balisage.net ****************************************************************
In principle it looks like openshift-basex-quick-start might be able to work round the problem by changing the .openshift/stop script to use other means to stop the server e.g."kill". /Andy On 7 January 2016 at 01:59, C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com
wrote:
On Jan 6, 2016, at 5:18 PM, Andy Bunce wrote:
Hi Michael,
I get the same result. I believe the problem is [1]. S_LOCALHOST is "localhost". Maybe this needs to be HOST or SERVERHOST.
/Andy
https://github.com/BaseXdb/basex/blob/master/basex-api/src/main/java/org/bas...
Thank you; it's nice to confirm that the problem can be reproduced.
I think [2] may lend support to your conjecture: it appears to be starting the StopServer with STOPPORT and SERVERHOST as parameters. But there are several stop() methods in the code and I shouldn't pretend I understand which is actually calling which.
[2] https://github.com/BaseXdb/basex/blob/master/basex-api/src/main/java/org/bas...
I notice that these pointers are to the current code, which differs a bit from the code of 8.3 dated 23 September, but there, too, the constructor for BaseXHTTP creates a StopServer instance passing SERVERHOST and STOPPORT as arguments, and the static stop() method opens a socket on LOCALHOST, not SERVERHOST. If that matters.
I have now also tested with 8.2.3 and 8.0.1 (by changing the URI in BASEX_VERSION in the config file -- thanks for making it so easy to reconfigure!) and find that both of these versions also exhibit the problem. The wording of the error message changes a bit; in 8.0.1. it says "Connection refused", not "Connection failed", and does not specify a port number. But it's pretty clearly the same issue.
Michael
-- **************************************************************** * C. M. Sperberg-McQueen, Black Mesa Technologies LLC * http://www.blackmesatech.com * http://cmsmcq.com/mib * http://balisage.net ****************************************************************
Hi Andy,
I believe the problem is [1]. S_LOCALHOST is "localhost". Maybe this needs to be HOST or SERVERHOST.
https://github.com/BaseXdb/basex/blob/master/basex-api/src/main/java/org/bas...
This code is currently called if the BaseX HTTP server is called via the 'basexhttp' start script (or via 'new BaseXHTTP()' in Java) and the 'stop' argument [1]. Are you using these calls somewhere in your code? Christian [1] http://docs.basex.org/wiki/Command-Line_Options#HTTP_Server On Thu, Jan 7, 2016 at 1:18 AM, Andy Bunce <bunce.andy@gmail.com> wrote:
Hi Michael,
I get the same result. I believe the problem is [1]. S_LOCALHOST is "localhost". Maybe this needs to be HOST or SERVERHOST.
/Andy
https://github.com/BaseXdb/basex/blob/master/basex-api/src/main/java/org/bas...
On 6 January 2016 at 21:54, C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> wrote:
I'm running into a problem that perhaps others here can help with. It appears to be almost identical to the problem reported by "P.C." on 5 March 2014 under the subject line 'BaseX server.close() "Connection refused" in Openshift' [1]; the mail record in the basex-talk archive doesn't show a resolution to P.C.'s problem. The main difference I see is that P.C. was deploying BaseX under Tomcat 7 on OpenShift, and I'm using Andy Bunce's quickstart method.
[1] https://www.mail-archive.com/basex-talk%40mailman.uni-konstanz.de/msg03861.h...
I'm experimenting with Andy Bunce's BaseX quick-start for OpenShift, which I like a lot, and I am experiencing the following sequence of events:
1 Following the instructions at [2], I use rhc to make a new app, add the Quodatum repository as a remote, merge it into the application source, and push the result to OpenShift. (Note: no changes made between the commands "git pull -s recursive -X theirs upstream master" and "git push origin master". The first time I tried it, I did change the admin password, but I thought that that might have something to do with the problem, so I omitted that step for this test.)
[2] https://github.com/Quodatum/openshift-basex-quick-start/
The OpenShift app is now available as promised at the URI indicated in [1], namely http://TestAPP-CMSMcQ.rhcloud.com/ (except that TestAPP is not really the name of the app, and CMSMcQ is not the name of the domain). It's a very nice looking console app.
2 I make some change -- any change -- to a file in the repository. To keep things simple, I'll add a comment line reading
(: Kilroy was here :)
to the file $app-name/basex/repo/quodatum/basex/env.xqm.
I'm pretty sure I didn't break anything in the env.xqm file in making the change, and I didn't change anything in any other file.
3 I check the change in to the local git repository:
# confirm that we have not touched anything else git status # commit the change git add basex/repo/quodatum/basex/env.xqm git commit -m "Vacuous change to env.xqm, just to have something to check in"
4 I attempt to push the change to the deployed app. The response is shown below (in the extract below, 'Salerno' is the local name of the machine, 'TestAPP' stands in for the name of the test application, and "CMSMcQ" for the OpenShift domain -- I've changed them here, because as can be seen from the log below, the app is currently open to anyone who knows the default admin userid and password).
Salerno:TestAPP cmsmcq$ git push origin master Counting objects: 7, done. Delta compression using up to 8 threads. Compressing objects: 100% (5/5), done. Writing objects: 100% (7/7), 649 bytes | 0 bytes/s, done. Total 7 (delta 2), reused 0 (delta 0) remote: Stopping DIY cartridge remote: HOST: 127.12.13.129 remote: PORT: 15005 remote: DEBUG: true remote: USER: admin remote: SERVERHOST: 127.12.13.129 remote: STOPPORT: 15007 remote: SERVERPORT: 15005 remote: PASSWORD: admin remote: java.io.IOException: Connection failed (port: 15007). remote: at org.basex.BaseXHTTP.stop(BaseXHTTP.java:367) remote: at org.basex.BaseXHTTP.stop(BaseXHTTP.java:180) remote: at org.basex.BaseXHTTP.<init>(BaseXHTTP.java:94) remote: at org.basex.BaseXHTTP.main(BaseXHTTP.java:50) remote: Connection failed (port: 15007). remote: An error occurred executing 'gear prereceive' (exit code: 1) remote: Error message: CLIENT_ERROR: Failed to execute: 'control stop' for /var/lib/openshift/568d73d67628e13ca2000004/diy remote: remote: For more details about the problem, try running the command again with the '--trace' option. To ssh://568d73d67628e13ca2000004@TestAPP-CMSMcQ.rhcloud.com/~/git/TestAPP.git/ ! [remote rejected] master -> master (pre-receive hook declined) error: failed to push some refs to 'ssh://568d73d67628e13ca2000004@TestAPP-CMSMcQ.rhcloud.com/~/git/TestAPP.git/' Salerno:TestAPP cmsmcq$
I've logged in to the application using ssh and run the basexhttp stop command manually, and what one gets then is essentially the same.
I think the root of the matter here is the line reading "remote: java.io.IOException: Connection failed (port: 15007)", but I'm having trouble thinking of a fix.
One could imagine that OpenShift doesn't like application code using a port like 15007. But since it seems to have no trouble with BaseX using 15005, for the SERVERPORT, that doesn't seem to make sense.
One could suppose that BaseX isn't actually listening on port 15007. The debugging output produced by -d, however does seems to show that BaseX knows that port 15007 is the stop port. Or does it? Perhaps it means only that BaseX has successfully parsed the -s option on the 'stop' command, which reads:
${OPENSHIFT_DATA_DIR}/basex/binbasexhttp -d \ -n ${OPENSHIFT_DIY_IP} -h ${OPENSHIFT_DIY_PORT} \ -p ${PORT_DATABASE} -s ${PORT_STOP} \ -U ${BASEX_USER} -P ${BASEX_PASSWORD} \ stop
which in turn expands to
.../basex/binbasexhttp -d \ -n 127.12.13.129 -h 8080 \ -p 15005 -s 15007 \ -U admin -P admin \ stop
The startup command uses the same values for the -p and -s options, so it seems plausible that the start command is successfully setting the port.
Several questions arise in connection with this problem, apart from the obvious and most important one, namely
Q1 Does anyone reading this list understand where the problem might lie?
The others that occur to me are:
Q2 Is there a server command or an admin query that will show what ports a running instance of BaseX is listening to? Or would that be too broad a security violation? (It would be nice to confirm that BaseX is actually listening for a stop signal on port 15007.
Q3 A search through the file system of the application shows that logs are being written to $APPLICATION_HOME/app-root/data/basex/data/.logs/ -- is there any way to find out from a running server what directory it's writing the logs to, to save the trouble of sshing to the application server and running
find . -print0 | xargs -0 grep "User was logged in"
or the equivalent? The admin:logs() function was helpful, but it would have been even more helpful if it had helped me find the logs directory.
Of course, I see now, looking at the documentation, that logs are always (? or only by default?) written to $DATABASE_DIRECTORY/.logs -- if I had been confident of knowing what directory was the database directory in this (still unfamiliar) setup, I would have known where to look.
Q4 Is there a command or admin-module query that indicates what directories BaseX regards as the base directory and the database directory? It could be very helpful, if it's not regarded as too great a security risk, for users trying to set things up in a new configuration.
Q5 OpenShift's documentation claims that it really wants application logs to go into $APPLICATION-HOME/app-root/logs/ -- is there any way to induce BaseX to write its logs there? The main advantage I can currently see is that it then becomes possible to examine them with the OpenShift rhc tools.
Any light anyone can shed on these issues would be very welcome.
Thanks!
Michael Sperberg-McQueen
-- **************************************************************** * C. M. Sperberg-McQueen, Black Mesa Technologies LLC * http://www.blackmesatech.com * http://cmsmcq.com/mib * http://balisage.net ****************************************************************
Hi Christian, I am calling `basexhttp stop` [1] in the OpenShift stop hook. This is part of OpenShift's application lifecycle management [2] `stop` and `start` are automatically invoked after a code change is committed. My understanding is in the OpenShift environment "localhost" is not resolved/allowed. The environment supplied value must be used, in this case `${OPENSHIFT_DIY_IP}` [3] /Andy [1] https://github.com/Quodatum/openshift-basex-quick-start/blob/master/.openshi... [2] https://developers.openshift.com/en/managing-action-hooks.html [3] https://developers.openshift.com/en/diy-overview.html On 7 January 2016 at 08:46, Christian Grün <christian.gruen@gmail.com> wrote:
Hi Andy,
I believe the problem is [1]. S_LOCALHOST is "localhost". Maybe this needs to be HOST or SERVERHOST.
https://github.com/BaseXdb/basex/blob/master/basex-api/src/main/java/org/bas...
This code is currently called if the BaseX HTTP server is called via the 'basexhttp' start script (or via 'new BaseXHTTP()' in Java) and the 'stop' argument [1]. Are you using these calls somewhere in your code?
Christian
[1] http://docs.basex.org/wiki/Command-Line_Options#HTTP_Server
On Thu, Jan 7, 2016 at 1:18 AM, Andy Bunce <bunce.andy@gmail.com> wrote:
Hi Michael,
I get the same result. I believe the problem is [1]. S_LOCALHOST is "localhost". Maybe this needs to be HOST or SERVERHOST.
/Andy
https://github.com/BaseXdb/basex/blob/master/basex-api/src/main/java/org/bas...
On 6 January 2016 at 21:54, C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> wrote:
I'm running into a problem that perhaps others here can help with. It appears to be almost identical to the problem reported by "P.C." on 5 March 2014 under the subject line 'BaseX server.close() "Connection refused" in Openshift' [1]; the mail record in the basex-talk archive doesn't show a resolution to P.C.'s problem. The main difference I see is that P.C. was deploying BaseX under Tomcat 7 on OpenShift, and I'm using Andy Bunce's quickstart method.
[1]
https://www.mail-archive.com/basex-talk%40mailman.uni-konstanz.de/msg03861.h...
I'm experimenting with Andy Bunce's BaseX quick-start for OpenShift, which I like a lot, and I am experiencing the following sequence of events:
1 Following the instructions at [2], I use rhc to make a new app, add the Quodatum repository as a remote, merge it into the application source, and push the result to OpenShift. (Note: no changes made between the commands "git pull -s recursive -X theirs upstream master" and "git push origin master". The first time I tried it, I did change the admin password, but I thought that that might have something to do with the problem, so I omitted that step for this test.)
[2] https://github.com/Quodatum/openshift-basex-quick-start/
The OpenShift app is now available as promised at the URI indicated in [1], namely http://TestAPP-CMSMcQ.rhcloud.com/ (except that TestAPP is not really the name of the app, and CMSMcQ is not the name of the domain). It's a very nice looking console app.
2 I make some change -- any change -- to a file in the repository. To keep things simple, I'll add a comment line reading
(: Kilroy was here :)
to the file $app-name/basex/repo/quodatum/basex/env.xqm.
I'm pretty sure I didn't break anything in the env.xqm file in making the change, and I didn't change anything in any other file.
3 I check the change in to the local git repository:
# confirm that we have not touched anything else git status # commit the change git add basex/repo/quodatum/basex/env.xqm git commit -m "Vacuous change to env.xqm, just to have something to check in"
4 I attempt to push the change to the deployed app. The response is shown below (in the extract below, 'Salerno' is the local name of the machine, 'TestAPP' stands in for the name of the test application, and "CMSMcQ" for the OpenShift domain -- I've changed them here, because as can be seen from the log below, the app is currently open to anyone who knows the default admin userid and password).
Salerno:TestAPP cmsmcq$ git push origin master Counting objects: 7, done. Delta compression using up to 8 threads. Compressing objects: 100% (5/5), done. Writing objects: 100% (7/7), 649 bytes | 0 bytes/s, done. Total 7 (delta 2), reused 0 (delta 0) remote: Stopping DIY cartridge remote: HOST: 127.12.13.129 remote: PORT: 15005 remote: DEBUG: true remote: USER: admin remote: SERVERHOST: 127.12.13.129 remote: STOPPORT: 15007 remote: SERVERPORT: 15005 remote: PASSWORD: admin remote: java.io.IOException: Connection failed (port: 15007). remote: at org.basex.BaseXHTTP.stop(BaseXHTTP.java:367) remote: at org.basex.BaseXHTTP.stop(BaseXHTTP.java:180) remote: at org.basex.BaseXHTTP.<init>(BaseXHTTP.java:94) remote: at org.basex.BaseXHTTP.main(BaseXHTTP.java:50) remote: Connection failed (port: 15007). remote: An error occurred executing 'gear prereceive' (exit code: 1) remote: Error message: CLIENT_ERROR: Failed to execute: 'control stop' for /var/lib/openshift/568d73d67628e13ca2000004/diy remote: remote: For more details about the problem, try running the command again with the '--trace' option. To ssh://
568d73d67628e13ca2000004@TestAPP-CMSMcQ.rhcloud.com/~/git/TestAPP.git/
! [remote rejected] master -> master (pre-receive hook declined) error: failed to push some refs to 'ssh:// 568d73d67628e13ca2000004@TestAPP-CMSMcQ.rhcloud.com/~/git/TestAPP.git/' Salerno:TestAPP cmsmcq$
I've logged in to the application using ssh and run the basexhttp stop command manually, and what one gets then is essentially the same.
I think the root of the matter here is the line reading "remote: java.io.IOException: Connection failed (port: 15007)", but I'm having trouble thinking of a fix.
One could imagine that OpenShift doesn't like application code using a port like 15007. But since it seems to have no trouble with BaseX using 15005, for the SERVERPORT, that doesn't seem to make sense.
One could suppose that BaseX isn't actually listening on port 15007. The debugging output produced by -d, however does seems to show that BaseX knows that port 15007 is the stop port. Or does it? Perhaps it means only that BaseX has successfully parsed the -s option on the 'stop' command, which reads:
${OPENSHIFT_DATA_DIR}/basex/binbasexhttp -d \ -n ${OPENSHIFT_DIY_IP} -h ${OPENSHIFT_DIY_PORT} \ -p ${PORT_DATABASE} -s ${PORT_STOP} \ -U ${BASEX_USER} -P ${BASEX_PASSWORD} \ stop
which in turn expands to
.../basex/binbasexhttp -d \ -n 127.12.13.129 -h 8080 \ -p 15005 -s 15007 \ -U admin -P admin \ stop
The startup command uses the same values for the -p and -s options, so it seems plausible that the start command is successfully setting the port.
Several questions arise in connection with this problem, apart from the obvious and most important one, namely
Q1 Does anyone reading this list understand where the problem might lie?
The others that occur to me are:
Q2 Is there a server command or an admin query that will show what ports a running instance of BaseX is listening to? Or would that be too broad a security violation? (It would be nice to confirm that BaseX is actually listening for a stop signal on port 15007.
Q3 A search through the file system of the application shows that logs are being written to $APPLICATION_HOME/app-root/data/basex/data/.logs/ -- is there any way to find out from a running server what directory it's writing the logs to, to save the trouble of sshing to the application server and running
find . -print0 | xargs -0 grep "User was logged in"
or the equivalent? The admin:logs() function was helpful, but it would have been even more helpful if it had helped me find the logs directory.
Of course, I see now, looking at the documentation, that logs are always (? or only by default?) written to $DATABASE_DIRECTORY/.logs -- if I had been confident of knowing what directory was the database directory in this (still unfamiliar) setup, I would have known where to look.
Q4 Is there a command or admin-module query that indicates what directories BaseX regards as the base directory and the database directory? It could be very helpful, if it's not regarded as too great a security risk, for users trying to set things up in a new configuration.
Q5 OpenShift's documentation claims that it really wants application logs to go into $APPLICATION-HOME/app-root/logs/ -- is there any way to induce BaseX to write its logs there? The main advantage I can currently see is that it then becomes possible to examine them with the OpenShift rhc tools.
Any light anyone can shed on these issues would be very welcome.
Thanks!
Michael Sperberg-McQueen
-- **************************************************************** * C. M. Sperberg-McQueen, Black Mesa Technologies LLC * http://www.blackmesatech.com * http://cmsmcq.com/mib * http://balisage.net ****************************************************************
I am calling `basexhttp stop` [1] in the OpenShift stop hook.
Thanks ;) In that case, I am wondering what would happen if we replaced 'localhost' by SERVERHOST, but if SERVERHOST is an empty string. Maybe it would make sense to only go for SERVERHOST if it's non-empty and use LOCALHOST otherwise? Suggestions are welcome. I can easily upload an updated version for testing. Christian
This is part of OpenShift's application lifecycle management [2] `stop` and `start` are automatically invoked after a code change is committed.
My understanding is in the OpenShift environment "localhost" is not resolved/allowed. The environment supplied value must be used, in this case `${OPENSHIFT_DIY_IP}` [3]
/Andy
[1] https://github.com/Quodatum/openshift-basex-quick-start/blob/master/.openshi... [2] https://developers.openshift.com/en/managing-action-hooks.html [3] https://developers.openshift.com/en/diy-overview.html
On 7 January 2016 at 08:46, Christian Grün <christian.gruen@gmail.com> wrote:
Hi Andy,
I believe the problem is [1]. S_LOCALHOST is "localhost". Maybe this needs to be HOST or SERVERHOST.
https://github.com/BaseXdb/basex/blob/master/basex-api/src/main/java/org/bas...
This code is currently called if the BaseX HTTP server is called via the 'basexhttp' start script (or via 'new BaseXHTTP()' in Java) and the 'stop' argument [1]. Are you using these calls somewhere in your code?
Christian
[1] http://docs.basex.org/wiki/Command-Line_Options#HTTP_Server
On Thu, Jan 7, 2016 at 1:18 AM, Andy Bunce <bunce.andy@gmail.com> wrote:
Hi Michael,
I get the same result. I believe the problem is [1]. S_LOCALHOST is "localhost". Maybe this needs to be HOST or SERVERHOST.
/Andy
https://github.com/BaseXdb/basex/blob/master/basex-api/src/main/java/org/bas...
On 6 January 2016 at 21:54, C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> wrote:
I'm running into a problem that perhaps others here can help with. It appears to be almost identical to the problem reported by "P.C." on 5 March 2014 under the subject line 'BaseX server.close() "Connection refused" in Openshift' [1]; the mail record in the basex-talk archive doesn't show a resolution to P.C.'s problem. The main difference I see is that P.C. was deploying BaseX under Tomcat 7 on OpenShift, and I'm using Andy Bunce's quickstart method.
[1]
https://www.mail-archive.com/basex-talk%40mailman.uni-konstanz.de/msg03861.h...
I'm experimenting with Andy Bunce's BaseX quick-start for OpenShift, which I like a lot, and I am experiencing the following sequence of events:
1 Following the instructions at [2], I use rhc to make a new app, add the Quodatum repository as a remote, merge it into the application source, and push the result to OpenShift. (Note: no changes made between the commands "git pull -s recursive -X theirs upstream master" and "git push origin master". The first time I tried it, I did change the admin password, but I thought that that might have something to do with the problem, so I omitted that step for this test.)
[2] https://github.com/Quodatum/openshift-basex-quick-start/
The OpenShift app is now available as promised at the URI indicated in [1], namely http://TestAPP-CMSMcQ.rhcloud.com/ (except that TestAPP is not really the name of the app, and CMSMcQ is not the name of the domain). It's a very nice looking console app.
2 I make some change -- any change -- to a file in the repository. To keep things simple, I'll add a comment line reading
(: Kilroy was here :)
to the file $app-name/basex/repo/quodatum/basex/env.xqm.
I'm pretty sure I didn't break anything in the env.xqm file in making the change, and I didn't change anything in any other file.
3 I check the change in to the local git repository:
# confirm that we have not touched anything else git status # commit the change git add basex/repo/quodatum/basex/env.xqm git commit -m "Vacuous change to env.xqm, just to have something to check in"
4 I attempt to push the change to the deployed app. The response is shown below (in the extract below, 'Salerno' is the local name of the machine, 'TestAPP' stands in for the name of the test application, and "CMSMcQ" for the OpenShift domain -- I've changed them here, because as can be seen from the log below, the app is currently open to anyone who knows the default admin userid and password).
Salerno:TestAPP cmsmcq$ git push origin master Counting objects: 7, done. Delta compression using up to 8 threads. Compressing objects: 100% (5/5), done. Writing objects: 100% (7/7), 649 bytes | 0 bytes/s, done. Total 7 (delta 2), reused 0 (delta 0) remote: Stopping DIY cartridge remote: HOST: 127.12.13.129 remote: PORT: 15005 remote: DEBUG: true remote: USER: admin remote: SERVERHOST: 127.12.13.129 remote: STOPPORT: 15007 remote: SERVERPORT: 15005 remote: PASSWORD: admin remote: java.io.IOException: Connection failed (port: 15007). remote: at org.basex.BaseXHTTP.stop(BaseXHTTP.java:367) remote: at org.basex.BaseXHTTP.stop(BaseXHTTP.java:180) remote: at org.basex.BaseXHTTP.<init>(BaseXHTTP.java:94) remote: at org.basex.BaseXHTTP.main(BaseXHTTP.java:50) remote: Connection failed (port: 15007). remote: An error occurred executing 'gear prereceive' (exit code: 1) remote: Error message: CLIENT_ERROR: Failed to execute: 'control stop' for /var/lib/openshift/568d73d67628e13ca2000004/diy remote: remote: For more details about the problem, try running the command again with the '--trace' option. To
ssh://568d73d67628e13ca2000004@TestAPP-CMSMcQ.rhcloud.com/~/git/TestAPP.git/ ! [remote rejected] master -> master (pre-receive hook declined) error: failed to push some refs to
'ssh://568d73d67628e13ca2000004@TestAPP-CMSMcQ.rhcloud.com/~/git/TestAPP.git/' Salerno:TestAPP cmsmcq$
I've logged in to the application using ssh and run the basexhttp stop command manually, and what one gets then is essentially the same.
I think the root of the matter here is the line reading "remote: java.io.IOException: Connection failed (port: 15007)", but I'm having trouble thinking of a fix.
One could imagine that OpenShift doesn't like application code using a port like 15007. But since it seems to have no trouble with BaseX using 15005, for the SERVERPORT, that doesn't seem to make sense.
One could suppose that BaseX isn't actually listening on port 15007. The debugging output produced by -d, however does seems to show that BaseX knows that port 15007 is the stop port. Or does it? Perhaps it means only that BaseX has successfully parsed the -s option on the 'stop' command, which reads:
${OPENSHIFT_DATA_DIR}/basex/binbasexhttp -d \ -n ${OPENSHIFT_DIY_IP} -h ${OPENSHIFT_DIY_PORT} \ -p ${PORT_DATABASE} -s ${PORT_STOP} \ -U ${BASEX_USER} -P ${BASEX_PASSWORD} \ stop
which in turn expands to
.../basex/binbasexhttp -d \ -n 127.12.13.129 -h 8080 \ -p 15005 -s 15007 \ -U admin -P admin \ stop
The startup command uses the same values for the -p and -s options, so it seems plausible that the start command is successfully setting the port.
Several questions arise in connection with this problem, apart from the obvious and most important one, namely
Q1 Does anyone reading this list understand where the problem might lie?
The others that occur to me are:
Q2 Is there a server command or an admin query that will show what ports a running instance of BaseX is listening to? Or would that be too broad a security violation? (It would be nice to confirm that BaseX is actually listening for a stop signal on port 15007.
Q3 A search through the file system of the application shows that logs are being written to $APPLICATION_HOME/app-root/data/basex/data/.logs/ -- is there any way to find out from a running server what directory it's writing the logs to, to save the trouble of sshing to the application server and running
find . -print0 | xargs -0 grep "User was logged in"
or the equivalent? The admin:logs() function was helpful, but it would have been even more helpful if it had helped me find the logs directory.
Of course, I see now, looking at the documentation, that logs are always (? or only by default?) written to $DATABASE_DIRECTORY/.logs -- if I had been confident of knowing what directory was the database directory in this (still unfamiliar) setup, I would have known where to look.
Q4 Is there a command or admin-module query that indicates what directories BaseX regards as the base directory and the database directory? It could be very helpful, if it's not regarded as too great a security risk, for users trying to set things up in a new configuration.
Q5 OpenShift's documentation claims that it really wants application logs to go into $APPLICATION-HOME/app-root/logs/ -- is there any way to induce BaseX to write its logs there? The main advantage I can currently see is that it then becomes possible to examine them with the OpenShift rhc tools.
Any light anyone can shed on these issues would be very welcome.
Thanks!
Michael Sperberg-McQueen
-- **************************************************************** * C. M. Sperberg-McQueen, Black Mesa Technologies LLC * http://www.blackmesatech.com * http://cmsmcq.com/mib * http://balisage.net ****************************************************************
Maybe it would make sense to only go for SERVERHOST if it's non-empty and use LOCALHOST otherwise?
Makes sense to me. I happy to test an updated version. /Andy On 7 January 2016 at 10:02, Christian Grün <christian.gruen@gmail.com> wrote:
I am calling `basexhttp stop` [1] in the OpenShift stop hook.
Thanks ;) In that case, I am wondering what would happen if we replaced 'localhost' by SERVERHOST, but if SERVERHOST is an empty string. Maybe it would make sense to only go for SERVERHOST if it's non-empty and use LOCALHOST otherwise?
Suggestions are welcome. I can easily upload an updated version for testing. Christian
This is part of OpenShift's application lifecycle management [2] `stop` and `start` are automatically invoked after a code change is committed.
My understanding is in the OpenShift environment "localhost" is not resolved/allowed. The environment supplied value must be used, in this case `${OPENSHIFT_DIY_IP}` [3]
/Andy
[1]
[2] https://developers.openshift.com/en/managing-action-hooks.html [3] https://developers.openshift.com/en/diy-overview.html
On 7 January 2016 at 08:46, Christian Grün <christian.gruen@gmail.com> wrote:
Hi Andy,
I believe the problem is [1]. S_LOCALHOST is "localhost". Maybe this needs to be HOST or SERVERHOST.
https://github.com/BaseXdb/basex/blob/master/basex-api/src/main/java/org/bas...
This code is currently called if the BaseX HTTP server is called via the 'basexhttp' start script (or via 'new BaseXHTTP()' in Java) and the 'stop' argument [1]. Are you using these calls somewhere in your code?
Christian
[1] http://docs.basex.org/wiki/Command-Line_Options#HTTP_Server
On Thu, Jan 7, 2016 at 1:18 AM, Andy Bunce <bunce.andy@gmail.com>
wrote:
Hi Michael,
I get the same result. I believe the problem is [1]. S_LOCALHOST is "localhost". Maybe this needs to be HOST or SERVERHOST.
/Andy
https://github.com/BaseXdb/basex/blob/master/basex-api/src/main/java/org/bas...
On 6 January 2016 at 21:54, C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> wrote:
I'm running into a problem that perhaps others here can help with. It appears to be almost identical to the problem reported by "P.C." on 5 March 2014 under the subject line 'BaseX server.close() "Connection refused" in Openshift' [1]; the mail record in the basex-talk archive doesn't show a resolution to P.C.'s problem. The main difference I
see
is that P.C. was deploying BaseX under Tomcat 7 on OpenShift, and I'm using Andy Bunce's quickstart method.
[1]
https://www.mail-archive.com/basex-talk%40mailman.uni-konstanz.de/msg03861.h...
I'm experimenting with Andy Bunce's BaseX quick-start for OpenShift, which I like a lot, and I am experiencing the following sequence of events:
1 Following the instructions at [2], I use rhc to make a new app, add the Quodatum repository as a remote, merge it into the application source, and push the result to OpenShift. (Note: no changes made between the commands "git pull -s recursive -X theirs upstream
master"
and "git push origin master". The first time I tried it, I did change the admin password, but I thought that that might have something to do with the problem, so I omitted that step for this test.)
[2] https://github.com/Quodatum/openshift-basex-quick-start/
The OpenShift app is now available as promised at the URI indicated in [1], namely http://TestAPP-CMSMcQ.rhcloud.com/ (except that TestAPP is not really the name of the app, and CMSMcQ is not the name of the domain). It's a very nice looking console app.
2 I make some change -- any change -- to a file in the repository. To keep things simple, I'll add a comment line reading
(: Kilroy was here :)
to the file $app-name/basex/repo/quodatum/basex/env.xqm.
I'm pretty sure I didn't break anything in the env.xqm file in making the change, and I didn't change anything in any other file.
3 I check the change in to the local git repository:
# confirm that we have not touched anything else git status # commit the change git add basex/repo/quodatum/basex/env.xqm git commit -m "Vacuous change to env.xqm, just to have something to check in"
4 I attempt to push the change to the deployed app. The response is shown below (in the extract below, 'Salerno' is the local name of the machine, 'TestAPP' stands in for the name of the test application, and "CMSMcQ" for the OpenShift domain -- I've changed them here, because as can be seen from the log below, the app is currently open to anyone who knows the default admin userid and password).
Salerno:TestAPP cmsmcq$ git push origin master Counting objects: 7, done. Delta compression using up to 8 threads. Compressing objects: 100% (5/5), done. Writing objects: 100% (7/7), 649 bytes | 0 bytes/s, done. Total 7 (delta 2), reused 0 (delta 0) remote: Stopping DIY cartridge remote: HOST: 127.12.13.129 remote: PORT: 15005 remote: DEBUG: true remote: USER: admin remote: SERVERHOST: 127.12.13.129 remote: STOPPORT: 15007 remote: SERVERPORT: 15005 remote: PASSWORD: admin remote: java.io.IOException: Connection failed (port: 15007). remote: at org.basex.BaseXHTTP.stop(BaseXHTTP.java:367) remote: at org.basex.BaseXHTTP.stop(BaseXHTTP.java:180) remote: at org.basex.BaseXHTTP.<init>(BaseXHTTP.java:94) remote: at org.basex.BaseXHTTP.main(BaseXHTTP.java:50) remote: Connection failed (port: 15007). remote: An error occurred executing 'gear prereceive' (exit code:
https://github.com/Quodatum/openshift-basex-quick-start/blob/master/.openshi... 1)
remote: Error message: CLIENT_ERROR: Failed to execute: 'control stop' for /var/lib/openshift/568d73d67628e13ca2000004/diy remote: remote: For more details about the problem, try running the command again with the '--trace' option. To
ssh:// 568d73d67628e13ca2000004@TestAPP-CMSMcQ.rhcloud.com/~/git/TestAPP.git/ ! [remote rejected] master -> master (pre-receive hook declined) error: failed to push some refs to
'ssh:// 568d73d67628e13ca2000004@TestAPP-CMSMcQ.rhcloud.com/~/git/TestAPP.git/' Salerno:TestAPP cmsmcq$
I've logged in to the application using ssh and run the basexhttp stop command manually, and what one gets then is essentially the same.
I think the root of the matter here is the line reading "remote: java.io.IOException: Connection failed (port: 15007)", but I'm having trouble thinking of a fix.
One could imagine that OpenShift doesn't like application code using a port like 15007. But since it seems to have no trouble with BaseX using 15005, for the SERVERPORT, that doesn't seem to make sense.
One could suppose that BaseX isn't actually listening on port 15007. The debugging output produced by -d, however does seems to show that BaseX knows that port 15007 is the stop port. Or does it? Perhaps it means only that BaseX has successfully parsed the -s option on the 'stop' command, which reads:
${OPENSHIFT_DATA_DIR}/basex/binbasexhttp -d \ -n ${OPENSHIFT_DIY_IP} -h ${OPENSHIFT_DIY_PORT} \ -p ${PORT_DATABASE} -s ${PORT_STOP} \ -U ${BASEX_USER} -P ${BASEX_PASSWORD} \ stop
which in turn expands to
.../basex/binbasexhttp -d \ -n 127.12.13.129 -h 8080 \ -p 15005 -s 15007 \ -U admin -P admin \ stop
The startup command uses the same values for the -p and -s options, so it seems plausible that the start command is successfully setting the port.
Several questions arise in connection with this problem, apart from the obvious and most important one, namely
Q1 Does anyone reading this list understand where the problem might lie?
The others that occur to me are:
Q2 Is there a server command or an admin query that will show what ports a running instance of BaseX is listening to? Or would that be too broad a security violation? (It would be nice to confirm that BaseX is actually listening for a stop signal on port 15007.
Q3 A search through the file system of the application shows that logs are being written to $APPLICATION_HOME/app-root/data/basex/data/.logs/ -- is there any way to find out from a running server what directory it's writing the logs to, to save the trouble of sshing to the application server and running
find . -print0 | xargs -0 grep "User was logged in"
or the equivalent? The admin:logs() function was helpful, but it would have been even more helpful if it had helped me find the logs directory.
Of course, I see now, looking at the documentation, that logs are always (? or only by default?) written to $DATABASE_DIRECTORY/.logs -- if I had been confident of knowing what directory was the database directory in this (still unfamiliar) setup, I would have known where to look.
Q4 Is there a command or admin-module query that indicates what directories BaseX regards as the base directory and the database directory? It could be very helpful, if it's not regarded as too great a security risk, for users trying to set things up in a new configuration.
Q5 OpenShift's documentation claims that it really wants application logs to go into $APPLICATION-HOME/app-root/logs/ -- is there any way to induce BaseX to write its logs there? The main advantage I can currently see is that it then becomes possible to examine them with the OpenShift rhc tools.
Any light anyone can shed on these issues would be very welcome.
Thanks!
Michael Sperberg-McQueen
-- **************************************************************** * C. M. Sperberg-McQueen, Black Mesa Technologies LLC * http://www.blackmesatech.com * http://cmsmcq.com/mib * http://balisage.net ****************************************************************
Makes sense to me. I happy to test an updated version.
+1. The updated snapshot is online http://files.basex.org/releases/latest/
/Andy
On 7 January 2016 at 10:02, Christian Grün <christian.gruen@gmail.com> wrote:
I am calling `basexhttp stop` [1] in the OpenShift stop hook.
Thanks ;) In that case, I am wondering what would happen if we replaced 'localhost' by SERVERHOST, but if SERVERHOST is an empty string. Maybe it would make sense to only go for SERVERHOST if it's non-empty and use LOCALHOST otherwise?
Suggestions are welcome. I can easily upload an updated version for testing. Christian
This is part of OpenShift's application lifecycle management [2] `stop` and `start` are automatically invoked after a code change is committed.
My understanding is in the OpenShift environment "localhost" is not resolved/allowed. The environment supplied value must be used, in this case `${OPENSHIFT_DIY_IP}` [3]
/Andy
[1]
https://github.com/Quodatum/openshift-basex-quick-start/blob/master/.openshi... [2] https://developers.openshift.com/en/managing-action-hooks.html [3] https://developers.openshift.com/en/diy-overview.html
On 7 January 2016 at 08:46, Christian Grün <christian.gruen@gmail.com> wrote:
Hi Andy,
I believe the problem is [1]. S_LOCALHOST is "localhost". Maybe this needs to be HOST or SERVERHOST.
https://github.com/BaseXdb/basex/blob/master/basex-api/src/main/java/org/bas...
This code is currently called if the BaseX HTTP server is called via the 'basexhttp' start script (or via 'new BaseXHTTP()' in Java) and the 'stop' argument [1]. Are you using these calls somewhere in your code?
Christian
[1] http://docs.basex.org/wiki/Command-Line_Options#HTTP_Server
On Thu, Jan 7, 2016 at 1:18 AM, Andy Bunce <bunce.andy@gmail.com> wrote:
Hi Michael,
I get the same result. I believe the problem is [1]. S_LOCALHOST is "localhost". Maybe this needs to be HOST or SERVERHOST.
/Andy
https://github.com/BaseXdb/basex/blob/master/basex-api/src/main/java/org/bas...
On 6 January 2016 at 21:54, C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> wrote:
I'm running into a problem that perhaps others here can help with. It appears to be almost identical to the problem reported by "P.C." on 5 March 2014 under the subject line 'BaseX server.close() "Connection refused" in Openshift' [1]; the mail record in the basex-talk archive doesn't show a resolution to P.C.'s problem. The main difference I see is that P.C. was deploying BaseX under Tomcat 7 on OpenShift, and I'm using Andy Bunce's quickstart method.
[1]
https://www.mail-archive.com/basex-talk%40mailman.uni-konstanz.de/msg03861.h...
I'm experimenting with Andy Bunce's BaseX quick-start for OpenShift, which I like a lot, and I am experiencing the following sequence of events:
1 Following the instructions at [2], I use rhc to make a new app, add the Quodatum repository as a remote, merge it into the application source, and push the result to OpenShift. (Note: no changes made between the commands "git pull -s recursive -X theirs upstream master" and "git push origin master". The first time I tried it, I did change the admin password, but I thought that that might have something to do with the problem, so I omitted that step for this test.)
[2] https://github.com/Quodatum/openshift-basex-quick-start/
The OpenShift app is now available as promised at the URI indicated in [1], namely http://TestAPP-CMSMcQ.rhcloud.com/ (except that TestAPP is not really the name of the app, and CMSMcQ is not the name of the domain). It's a very nice looking console app.
2 I make some change -- any change -- to a file in the repository. To keep things simple, I'll add a comment line reading
(: Kilroy was here :)
to the file $app-name/basex/repo/quodatum/basex/env.xqm.
I'm pretty sure I didn't break anything in the env.xqm file in making the change, and I didn't change anything in any other file.
3 I check the change in to the local git repository:
# confirm that we have not touched anything else git status # commit the change git add basex/repo/quodatum/basex/env.xqm git commit -m "Vacuous change to env.xqm, just to have something to check in"
4 I attempt to push the change to the deployed app. The response is shown below (in the extract below, 'Salerno' is the local name of the machine, 'TestAPP' stands in for the name of the test application, and "CMSMcQ" for the OpenShift domain -- I've changed them here, because as can be seen from the log below, the app is currently open to anyone who knows the default admin userid and password).
Salerno:TestAPP cmsmcq$ git push origin master Counting objects: 7, done. Delta compression using up to 8 threads. Compressing objects: 100% (5/5), done. Writing objects: 100% (7/7), 649 bytes | 0 bytes/s, done. Total 7 (delta 2), reused 0 (delta 0) remote: Stopping DIY cartridge remote: HOST: 127.12.13.129 remote: PORT: 15005 remote: DEBUG: true remote: USER: admin remote: SERVERHOST: 127.12.13.129 remote: STOPPORT: 15007 remote: SERVERPORT: 15005 remote: PASSWORD: admin remote: java.io.IOException: Connection failed (port: 15007). remote: at org.basex.BaseXHTTP.stop(BaseXHTTP.java:367) remote: at org.basex.BaseXHTTP.stop(BaseXHTTP.java:180) remote: at org.basex.BaseXHTTP.<init>(BaseXHTTP.java:94) remote: at org.basex.BaseXHTTP.main(BaseXHTTP.java:50) remote: Connection failed (port: 15007). remote: An error occurred executing 'gear prereceive' (exit code: 1) remote: Error message: CLIENT_ERROR: Failed to execute: 'control stop' for /var/lib/openshift/568d73d67628e13ca2000004/diy remote: remote: For more details about the problem, try running the command again with the '--trace' option. To
ssh://568d73d67628e13ca2000004@TestAPP-CMSMcQ.rhcloud.com/~/git/TestAPP.git/ ! [remote rejected] master -> master (pre-receive hook declined) error: failed to push some refs to
'ssh://568d73d67628e13ca2000004@TestAPP-CMSMcQ.rhcloud.com/~/git/TestAPP.git/' Salerno:TestAPP cmsmcq$
I've logged in to the application using ssh and run the basexhttp stop command manually, and what one gets then is essentially the same.
I think the root of the matter here is the line reading "remote: java.io.IOException: Connection failed (port: 15007)", but I'm having trouble thinking of a fix.
One could imagine that OpenShift doesn't like application code using a port like 15007. But since it seems to have no trouble with BaseX using 15005, for the SERVERPORT, that doesn't seem to make sense.
One could suppose that BaseX isn't actually listening on port 15007. The debugging output produced by -d, however does seems to show that BaseX knows that port 15007 is the stop port. Or does it? Perhaps it means only that BaseX has successfully parsed the -s option on the 'stop' command, which reads:
${OPENSHIFT_DATA_DIR}/basex/binbasexhttp -d \ -n ${OPENSHIFT_DIY_IP} -h ${OPENSHIFT_DIY_PORT} \ -p ${PORT_DATABASE} -s ${PORT_STOP} \ -U ${BASEX_USER} -P ${BASEX_PASSWORD} \ stop
which in turn expands to
.../basex/binbasexhttp -d \ -n 127.12.13.129 -h 8080 \ -p 15005 -s 15007 \ -U admin -P admin \ stop
The startup command uses the same values for the -p and -s options, so it seems plausible that the start command is successfully setting the port.
Several questions arise in connection with this problem, apart from the obvious and most important one, namely
Q1 Does anyone reading this list understand where the problem might lie?
The others that occur to me are:
Q2 Is there a server command or an admin query that will show what ports a running instance of BaseX is listening to? Or would that be too broad a security violation? (It would be nice to confirm that BaseX is actually listening for a stop signal on port 15007.
Q3 A search through the file system of the application shows that logs are being written to $APPLICATION_HOME/app-root/data/basex/data/.logs/ -- is there any way to find out from a running server what directory it's writing the logs to, to save the trouble of sshing to the application server and running
find . -print0 | xargs -0 grep "User was logged in"
or the equivalent? The admin:logs() function was helpful, but it would have been even more helpful if it had helped me find the logs directory.
Of course, I see now, looking at the documentation, that logs are always (? or only by default?) written to $DATABASE_DIRECTORY/.logs -- if I had been confident of knowing what directory was the database directory in this (still unfamiliar) setup, I would have known where to look.
Q4 Is there a command or admin-module query that indicates what directories BaseX regards as the base directory and the database directory? It could be very helpful, if it's not regarded as too great a security risk, for users trying to set things up in a new configuration.
Q5 OpenShift's documentation claims that it really wants application logs to go into $APPLICATION-HOME/app-root/logs/ -- is there any way to induce BaseX to write its logs there? The main advantage I can currently see is that it then becomes possible to examine them with the OpenShift rhc tools.
Any light anyone can shed on these issues would be very welcome.
Thanks!
Michael Sperberg-McQueen
-- **************************************************************** * C. M. Sperberg-McQueen, Black Mesa Technologies LLC * http://www.blackmesatech.com * http://cmsmcq.com/mib * http://balisage.net ****************************************************************
Not quite there with BaseX 8.4 beta 5687c30. Now the issue is in BaseXServer : java.io.IOException: Connection failed (port: 15005). at org.basex.BaseXServer.stop(BaseXServer.java:317) at org.basex.BaseXHTTP.stop(BaseXHTTP.java:191) at org.basex.BaseXHTTP.<init>(BaseXHTTP.java:96) at org.basex.BaseXHTTP.main(BaseXHTTP.java:52) Connection failed (port: 15005). I see there is another stop using S_LOCALHOST here: https://github.com/BaseXdb/basex/blob/master/basex-core/src/main/java/org/ba... I think any use of "localhost" will cause issues on OpenShift. /Andy PS: I have updated https://github.com/Quodatum/openshift-basex-quick-start to use pkill to stop the server for now. https://github.com/Quodatum/openshift-basex-quick-start/blob/master/.openshi... On 7 January 2016 at 11:52, Christian Grün <christian.gruen@gmail.com> wrote:
Makes sense to me. I happy to test an updated version.
+1. The updated snapshot is online http://files.basex.org/releases/latest/
/Andy
On 7 January 2016 at 10:02, Christian Grün <christian.gruen@gmail.com> wrote:
I am calling `basexhttp stop` [1] in the OpenShift stop hook.
Thanks ;) In that case, I am wondering what would happen if we replaced 'localhost' by SERVERHOST, but if SERVERHOST is an empty string. Maybe it would make sense to only go for SERVERHOST if it's non-empty and use LOCALHOST otherwise?
Suggestions are welcome. I can easily upload an updated version for testing. Christian
This is part of OpenShift's application lifecycle management [2] `stop` and `start` are automatically invoked after a code change is committed.
My understanding is in the OpenShift environment "localhost" is not resolved/allowed. The environment supplied value must be used, in this case `${OPENSHIFT_DIY_IP}` [3]
/Andy
[1]
https://github.com/Quodatum/openshift-basex-quick-start/blob/master/.openshi...
[2] https://developers.openshift.com/en/managing-action-hooks.html [3] https://developers.openshift.com/en/diy-overview.html
On 7 January 2016 at 08:46, Christian Grün <christian.gruen@gmail.com
wrote:
Hi Andy,
> I believe the problem is [1]. S_LOCALHOST is "localhost". Maybe
this
> needs to be HOST or SERVERHOST. > > > > https://github.com/BaseXdb/basex/blob/master/basex-api/src/main/java/org/bas...
This code is currently called if the BaseX HTTP server is called via the 'basexhttp' start script (or via 'new BaseXHTTP()' in Java) and the 'stop' argument [1]. Are you using these calls somewhere in your code?
Christian
[1] http://docs.basex.org/wiki/Command-Line_Options#HTTP_Server
On Thu, Jan 7, 2016 at 1:18 AM, Andy Bunce <bunce.andy@gmail.com> wrote:
Hi Michael,
I get the same result. I believe the problem is [1]. S_LOCALHOST is "localhost". Maybe this needs to be HOST or SERVERHOST.
/Andy
https://github.com/BaseXdb/basex/blob/master/basex-api/src/main/java/org/bas...
On 6 January 2016 at 21:54, C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> wrote: > > I'm running into a problem that perhaps others here can help with. > It appears to be almost identical to the problem reported by
"P.C."
> on 5 March 2014 under the subject line 'BaseX server.close() > "Connection > refused" in Openshift' [1]; the mail record in the basex-talk > archive > doesn't show a resolution to P.C.'s problem. The main difference I > see > is that P.C. was deploying BaseX under Tomcat 7 on OpenShift, and > I'm using Andy Bunce's quickstart method. > > [1] > > > https://www.mail-archive.com/basex-talk%40mailman.uni-konstanz.de/msg03861.h... > > I'm experimenting with Andy Bunce's BaseX quick-start for OpenShift, > which I like a lot, and I am experiencing the following sequence of > events: > > 1 Following the instructions at [2], I use rhc to make a new app, > add > the Quodatum repository as a remote, merge it into the application > source, and push the result to OpenShift. (Note: no changes made > between the commands "git pull -s recursive -X theirs upstream > master" > and "git push origin master". The first time I tried it, I did > change > the admin password, but I thought that that might have something to > do > with the problem, so I omitted that step for this test.) > > [2] https://github.com/Quodatum/openshift-basex-quick-start/ > > The OpenShift app is now available as promised at the URI indicated > in > [1], namely http://TestAPP-CMSMcQ.rhcloud.com/ (except that TestAPP > is > not really the name of the app, and CMSMcQ is not the name of the > domain). It's a very nice looking console app. > > > 2 I make some change -- any change -- to a file in the repository. > To keep things simple, I'll add a comment line reading > > (: Kilroy was here :) > > to the file $app-name/basex/repo/quodatum/basex/env.xqm. > > I'm pretty sure I didn't break anything in the env.xqm file in > making > the change, and I didn't change anything in any other file. > > 3 I check the change in to the local git repository: > > # confirm that we have not touched anything else > git status > # commit the change > git add basex/repo/quodatum/basex/env.xqm > git commit -m "Vacuous change to env.xqm, just to have something > to > check in" > > 4 I attempt to push the change to the deployed app. The response is > shown below (in the extract below, 'Salerno' is the local name of > the > machine, 'TestAPP' stands in for the name of the test application, > and > "CMSMcQ" for the OpenShift domain -- I've changed them here, > because as can be seen from the log below, the app is currently > open to anyone who knows the default admin userid and password). > > Salerno:TestAPP cmsmcq$ git push origin master > Counting objects: 7, done. > Delta compression using up to 8 threads. > Compressing objects: 100% (5/5), done. > Writing objects: 100% (7/7), 649 bytes | 0 bytes/s, done. > Total 7 (delta 2), reused 0 (delta 0) > remote: Stopping DIY cartridge > remote: HOST: 127.12.13.129 > remote: PORT: 15005 > remote: DEBUG: true > remote: USER: admin > remote: SERVERHOST: 127.12.13.129 > remote: STOPPORT: 15007 > remote: SERVERPORT: 15005 > remote: PASSWORD: admin > remote: java.io.IOException: Connection failed (port: 15007). > remote: at org.basex.BaseXHTTP.stop(BaseXHTTP.java:367) > remote: at org.basex.BaseXHTTP.stop(BaseXHTTP.java:180) > remote: at org.basex.BaseXHTTP.<init>(BaseXHTTP.java:94) > remote: at org.basex.BaseXHTTP.main(BaseXHTTP.java:50) > remote: Connection failed (port: 15007). > remote: An error occurred executing 'gear prereceive' (exit code: > 1) > remote: Error message: CLIENT_ERROR: Failed to execute: 'control > stop' > for /var/lib/openshift/568d73d67628e13ca2000004/diy > remote: > remote: For more details about the problem, try running the > command > again with the '--trace' option. > To > > > ssh:// 568d73d67628e13ca2000004@TestAPP-CMSMcQ.rhcloud.com/~/git/TestAPP.git/ > ! [remote rejected] master -> master (pre-receive hook declined) > error: failed to push some refs to > > > 'ssh:// 568d73d67628e13ca2000004@TestAPP-CMSMcQ.rhcloud.com/~/git/TestAPP.git/' > Salerno:TestAPP cmsmcq$ > > I've logged in to the application using ssh and run the basexhttp > stop > command manually, and what one gets then is essentially the same. > > I think the root of the matter here is the line reading "remote: > java.io.IOException: Connection failed (port: 15007)", but I'm > having > trouble thinking of a fix. > > One could imagine that OpenShift doesn't like application code using > a > port like 15007. But since it seems to have no trouble with BaseX > using 15005, for the SERVERPORT, that doesn't seem to make sense. > > One could suppose that BaseX isn't actually listening on port
> The debugging output produced by -d, however does seems to show that > BaseX knows that port 15007 is the stop port. Or does it? Perhaps > it > means only that BaseX has successfully parsed the -s option on the > 'stop' command, which reads: > > ${OPENSHIFT_DATA_DIR}/basex/binbasexhttp -d \ > -n ${OPENSHIFT_DIY_IP} -h > ${OPENSHIFT_DIY_PORT} > \ > -p ${PORT_DATABASE} -s ${PORT_STOP} \ > -U ${BASEX_USER} -P ${BASEX_PASSWORD} \ > stop > > which in turn expands to > > .../basex/binbasexhttp -d \ > -n 127.12.13.129 -h 8080 \ > -p 15005 -s 15007 \ > -U admin -P admin \ > stop > > The startup command uses the same values for the -p and -s options, > so > it seems plausible that the start command is successfully setting > the > port. > > Several questions arise in connection with this problem, apart from > the obvious and most important one, namely > > Q1 Does anyone reading this list understand where the problem might > lie? > > The others that occur to me are: > > Q2 Is there a server command or an admin query that will show what > ports a running instance of BaseX is listening to? Or would that be > too broad a security violation? (It would be nice to confirm that > BaseX > is actually listening for a stop signal on port 15007. > > Q3 A search through the file system of the application shows that > logs > are being written to > $APPLICATION_HOME/app-root/data/basex/data/.logs/ > -- is there any way to find out from a running server what directory > it's writing the logs to, to save the trouble of sshing to the > application server and running > > find . -print0 | xargs -0 grep "User was logged in" > > or the equivalent? The admin:logs() function was helpful, but it > would have been even more helpful if it had helped me find the logs > directory. > > Of course, I see now, looking at the documentation, that logs are > always (? or only by default?) written to $DATABASE_DIRECTORY/.logs > -- > if I had been confident of knowing what directory was the database > directory in this (still unfamiliar) setup, I would have known where > to look. > > Q4 Is there a command or admin-module query that indicates what > directories BaseX regards as the base directory and the database > directory? It could be very helpful, if it's not regarded as too > great a security risk, for users trying to set things up in a new > configuration. > > Q5 OpenShift's documentation claims that it really wants application > logs to go into $APPLICATION-HOME/app-root/logs/ -- is there any way > to induce BaseX to write its logs there? The main advantage I can > currently see is that it then becomes possible to examine them with > the OpenShift rhc tools. > > Any light anyone can shed on these issues would be very welcome. > > Thanks! > > Michael Sperberg-McQueen > > -- > **************************************************************** > * C. M. Sperberg-McQueen, Black Mesa Technologies LLC > * http://www.blackmesatech.com > * http://cmsmcq.com/mib > * http://balisage.net > **************************************************************** > > > >
Not quite there with BaseX 8.4 beta 5687c30. Now the issue is in BaseXServer :
java.io.IOException: Connection failed (port: 15005). at org.basex.BaseXServer.stop(BaseXServer.java:317) at org.basex.BaseXHTTP.stop(BaseXHTTP.java:191) at org.basex.BaseXHTTP.<init>(BaseXHTTP.java:96) at org.basex.BaseXHTTP.main(BaseXHTTP.java:52) Connection failed (port: 15005).
I see there is another stop using S_LOCALHOST here: https://github.com/BaseXdb/basex/blob/master/basex-core/src/main/java/org/ba...
Makes sense! If you could check out the latest snapshot again, that’d be great [1]. Thanks, Christian [1] http://files.basex.org/releases/latest/
I think any use of "localhost" will cause issues on OpenShift. /Andy
PS: I have updated https://github.com/Quodatum/openshift-basex-quick-start to use pkill to stop the server for now. https://github.com/Quodatum/openshift-basex-quick-start/blob/master/.openshi...
On 7 January 2016 at 11:52, Christian Grün <christian.gruen@gmail.com> wrote:
Makes sense to me. I happy to test an updated version.
+1. The updated snapshot is online http://files.basex.org/releases/latest/
/Andy
On 7 January 2016 at 10:02, Christian Grün <christian.gruen@gmail.com> wrote:
I am calling `basexhttp stop` [1] in the OpenShift stop hook.
Thanks ;) In that case, I am wondering what would happen if we replaced 'localhost' by SERVERHOST, but if SERVERHOST is an empty string. Maybe it would make sense to only go for SERVERHOST if it's non-empty and use LOCALHOST otherwise?
Suggestions are welcome. I can easily upload an updated version for testing. Christian
This is part of OpenShift's application lifecycle management [2] `stop` and `start` are automatically invoked after a code change is committed.
My understanding is in the OpenShift environment "localhost" is not resolved/allowed. The environment supplied value must be used, in this case `${OPENSHIFT_DIY_IP}` [3]
/Andy
[1]
https://github.com/Quodatum/openshift-basex-quick-start/blob/master/.openshi... [2] https://developers.openshift.com/en/managing-action-hooks.html [3] https://developers.openshift.com/en/diy-overview.html
On 7 January 2016 at 08:46, Christian Grün <christian.gruen@gmail.com> wrote:
Hi Andy,
>> I believe the problem is [1]. S_LOCALHOST is "localhost". Maybe >> this >> needs to be HOST or SERVERHOST. >> >> >> >> >> https://github.com/BaseXdb/basex/blob/master/basex-api/src/main/java/org/bas...
This code is currently called if the BaseX HTTP server is called via the 'basexhttp' start script (or via 'new BaseXHTTP()' in Java) and the 'stop' argument [1]. Are you using these calls somewhere in your code?
Christian
[1] http://docs.basex.org/wiki/Command-Line_Options#HTTP_Server
On Thu, Jan 7, 2016 at 1:18 AM, Andy Bunce <bunce.andy@gmail.com> wrote: > Hi Michael, > > I get the same result. > I believe the problem is [1]. S_LOCALHOST is "localhost". Maybe > this > needs > to be HOST or SERVERHOST. > > /Andy > > > > > https://github.com/BaseXdb/basex/blob/master/basex-api/src/main/java/org/bas... > > On 6 January 2016 at 21:54, C. M. Sperberg-McQueen > <cmsmcq@blackmesatech.com> wrote: >> >> I'm running into a problem that perhaps others here can help >> with. >> It appears to be almost identical to the problem reported by >> "P.C." >> on 5 March 2014 under the subject line 'BaseX server.close() >> "Connection >> refused" in Openshift' [1]; the mail record in the basex-talk >> archive >> doesn't show a resolution to P.C.'s problem. The main difference >> I >> see >> is that P.C. was deploying BaseX under Tomcat 7 on OpenShift, and >> I'm using Andy Bunce's quickstart method. >> >> [1] >> >> >> >> https://www.mail-archive.com/basex-talk%40mailman.uni-konstanz.de/msg03861.h... >> >> I'm experimenting with Andy Bunce's BaseX quick-start for >> OpenShift, >> which I like a lot, and I am experiencing the following sequence >> of >> events: >> >> 1 Following the instructions at [2], I use rhc to make a new app, >> add >> the Quodatum repository as a remote, merge it into the >> application >> source, and push the result to OpenShift. (Note: no changes made >> between the commands "git pull -s recursive -X theirs upstream >> master" >> and "git push origin master". The first time I tried it, I did >> change >> the admin password, but I thought that that might have something >> to >> do >> with the problem, so I omitted that step for this test.) >> >> [2] https://github.com/Quodatum/openshift-basex-quick-start/ >> >> The OpenShift app is now available as promised at the URI >> indicated >> in >> [1], namely http://TestAPP-CMSMcQ.rhcloud.com/ (except that >> TestAPP >> is >> not really the name of the app, and CMSMcQ is not the name of the >> domain). It's a very nice looking console app. >> >> >> 2 I make some change -- any change -- to a file in the >> repository. >> To keep things simple, I'll add a comment line reading >> >> (: Kilroy was here :) >> >> to the file $app-name/basex/repo/quodatum/basex/env.xqm. >> >> I'm pretty sure I didn't break anything in the env.xqm file in >> making >> the change, and I didn't change anything in any other file. >> >> 3 I check the change in to the local git repository: >> >> # confirm that we have not touched anything else >> git status >> # commit the change >> git add basex/repo/quodatum/basex/env.xqm >> git commit -m "Vacuous change to env.xqm, just to have >> something >> to >> check in" >> >> 4 I attempt to push the change to the deployed app. The response >> is >> shown below (in the extract below, 'Salerno' is the local name of >> the >> machine, 'TestAPP' stands in for the name of the test >> application, >> and >> "CMSMcQ" for the OpenShift domain -- I've changed them here, >> because as can be seen from the log below, the app is currently >> open to anyone who knows the default admin userid and password). >> >> Salerno:TestAPP cmsmcq$ git push origin master >> Counting objects: 7, done. >> Delta compression using up to 8 threads. >> Compressing objects: 100% (5/5), done. >> Writing objects: 100% (7/7), 649 bytes | 0 bytes/s, done. >> Total 7 (delta 2), reused 0 (delta 0) >> remote: Stopping DIY cartridge >> remote: HOST: 127.12.13.129 >> remote: PORT: 15005 >> remote: DEBUG: true >> remote: USER: admin >> remote: SERVERHOST: 127.12.13.129 >> remote: STOPPORT: 15007 >> remote: SERVERPORT: 15005 >> remote: PASSWORD: admin >> remote: java.io.IOException: Connection failed (port: 15007). >> remote: at org.basex.BaseXHTTP.stop(BaseXHTTP.java:367) >> remote: at org.basex.BaseXHTTP.stop(BaseXHTTP.java:180) >> remote: at org.basex.BaseXHTTP.<init>(BaseXHTTP.java:94) >> remote: at org.basex.BaseXHTTP.main(BaseXHTTP.java:50) >> remote: Connection failed (port: 15007). >> remote: An error occurred executing 'gear prereceive' (exit >> code: >> 1) >> remote: Error message: CLIENT_ERROR: Failed to execute: >> 'control >> stop' >> for /var/lib/openshift/568d73d67628e13ca2000004/diy >> remote: >> remote: For more details about the problem, try running the >> command >> again with the '--trace' option. >> To >> >> >> >> ssh://568d73d67628e13ca2000004@TestAPP-CMSMcQ.rhcloud.com/~/git/TestAPP.git/ >> ! [remote rejected] master -> master (pre-receive hook >> declined) >> error: failed to push some refs to >> >> >> >> 'ssh://568d73d67628e13ca2000004@TestAPP-CMSMcQ.rhcloud.com/~/git/TestAPP.git/' >> Salerno:TestAPP cmsmcq$ >> >> I've logged in to the application using ssh and run the basexhttp >> stop >> command manually, and what one gets then is essentially the same. >> >> I think the root of the matter here is the line reading "remote: >> java.io.IOException: Connection failed (port: 15007)", but I'm >> having >> trouble thinking of a fix. >> >> One could imagine that OpenShift doesn't like application code >> using >> a >> port like 15007. But since it seems to have no trouble with >> BaseX >> using 15005, for the SERVERPORT, that doesn't seem to make sense. >> >> One could suppose that BaseX isn't actually listening on port >> 15007. >> The debugging output produced by -d, however does seems to show >> that >> BaseX knows that port 15007 is the stop port. Or does it? >> Perhaps >> it >> means only that BaseX has successfully parsed the -s option on >> the >> 'stop' command, which reads: >> >> ${OPENSHIFT_DATA_DIR}/basex/binbasexhttp -d \ >> -n ${OPENSHIFT_DIY_IP} -h >> ${OPENSHIFT_DIY_PORT} >> \ >> -p ${PORT_DATABASE} -s ${PORT_STOP} \ >> -U ${BASEX_USER} -P ${BASEX_PASSWORD} \ >> stop >> >> which in turn expands to >> >> .../basex/binbasexhttp -d \ >> -n 127.12.13.129 -h 8080 \ >> -p 15005 -s 15007 \ >> -U admin -P admin \ >> stop >> >> The startup command uses the same values for the -p and -s >> options, >> so >> it seems plausible that the start command is successfully setting >> the >> port. >> >> Several questions arise in connection with this problem, apart >> from >> the obvious and most important one, namely >> >> Q1 Does anyone reading this list understand where the problem >> might >> lie? >> >> The others that occur to me are: >> >> Q2 Is there a server command or an admin query that will show >> what >> ports a running instance of BaseX is listening to? Or would that >> be >> too broad a security violation? (It would be nice to confirm >> that >> BaseX >> is actually listening for a stop signal on port 15007. >> >> Q3 A search through the file system of the application shows that >> logs >> are being written to >> $APPLICATION_HOME/app-root/data/basex/data/.logs/ >> -- is there any way to find out from a running server what >> directory >> it's writing the logs to, to save the trouble of sshing to the >> application server and running >> >> find . -print0 | xargs -0 grep "User was logged in" >> >> or the equivalent? The admin:logs() function was helpful, but it >> would have been even more helpful if it had helped me find the >> logs >> directory. >> >> Of course, I see now, looking at the documentation, that logs are >> always (? or only by default?) written to >> $DATABASE_DIRECTORY/.logs >> -- >> if I had been confident of knowing what directory was the >> database >> directory in this (still unfamiliar) setup, I would have known >> where >> to look. >> >> Q4 Is there a command or admin-module query that indicates what >> directories BaseX regards as the base directory and the database >> directory? It could be very helpful, if it's not regarded as too >> great a security risk, for users trying to set things up in a new >> configuration. >> >> Q5 OpenShift's documentation claims that it really wants >> application >> logs to go into $APPLICATION-HOME/app-root/logs/ -- is there any >> way >> to induce BaseX to write its logs there? The main advantage I >> can >> currently see is that it then becomes possible to examine them >> with >> the OpenShift rhc tools. >> >> Any light anyone can shed on these issues would be very welcome. >> >> Thanks! >> >> Michael Sperberg-McQueen >> >> -- >> **************************************************************** >> * C. M. Sperberg-McQueen, Black Mesa Technologies LLC >> * http://www.blackmesatech.com >> * http://cmsmcq.com/mib >> * http://balisage.net >> **************************************************************** >> >> >> >> >
That works for me. http://apps-apb.rhcloud.com/ Thanks /Andy On 7 January 2016 at 18:11, Christian Grün <christian.gruen@gmail.com> wrote:
Not quite there with BaseX 8.4 beta 5687c30. Now the issue is in BaseXServer :
java.io.IOException: Connection failed (port: 15005). at org.basex.BaseXServer.stop(BaseXServer.java:317) at org.basex.BaseXHTTP.stop(BaseXHTTP.java:191) at org.basex.BaseXHTTP.<init>(BaseXHTTP.java:96) at org.basex.BaseXHTTP.main(BaseXHTTP.java:52) Connection failed (port: 15005).
I see there is another stop using S_LOCALHOST here:
https://github.com/BaseXdb/basex/blob/master/basex-core/src/main/java/org/ba...
Makes sense! If you could check out the latest snapshot again, that’d be great [1].
Thanks, Christian
[1] http://files.basex.org/releases/latest/
I think any use of "localhost" will cause issues on OpenShift. /Andy
PS: I have updated https://github.com/Quodatum/openshift-basex-quick-start
to
use pkill to stop the server for now.
https://github.com/Quodatum/openshift-basex-quick-start/blob/master/.openshi...
On 7 January 2016 at 11:52, Christian Grün <christian.gruen@gmail.com> wrote:
Makes sense to me. I happy to test an updated version.
+1. The updated snapshot is online
http://files.basex.org/releases/latest/
/Andy
On 7 January 2016 at 10:02, Christian Grün <christian.gruen@gmail.com
wrote:
I am calling `basexhttp stop` [1] in the OpenShift stop hook.
Thanks ;) In that case, I am wondering what would happen if we replaced 'localhost' by SERVERHOST, but if SERVERHOST is an empty string. Maybe it would make sense to only go for SERVERHOST if it's non-empty and use LOCALHOST otherwise?
Suggestions are welcome. I can easily upload an updated version for testing. Christian
This is part of OpenShift's application lifecycle management [2] `stop` and `start` are automatically invoked after a code change is committed.
My understanding is in the OpenShift environment "localhost" is not resolved/allowed. The environment supplied value must be used, in this case `${OPENSHIFT_DIY_IP}` [3]
/Andy
[1]
https://github.com/Quodatum/openshift-basex-quick-start/blob/master/.openshi...
[2] https://developers.openshift.com/en/managing-action-hooks.html [3] https://developers.openshift.com/en/diy-overview.html
On 7 January 2016 at 08:46, Christian Grün <christian.gruen@gmail.com> wrote: > > Hi Andy, > > >> I believe the problem is [1]. S_LOCALHOST is "localhost". Maybe > >> this > >> needs to be HOST or SERVERHOST. > >> > >> > >> > >> > >> https://github.com/BaseXdb/basex/blob/master/basex-api/src/main/java/org/bas... > > This code is currently called if the BaseX HTTP server is called via > the 'basexhttp' start script (or via 'new BaseXHTTP()' in Java) and > the 'stop' argument [1]. Are you using these calls somewhere in your > code? > > Christian > > [1] http://docs.basex.org/wiki/Command-Line_Options#HTTP_Server > > > > On Thu, Jan 7, 2016 at 1:18 AM, Andy Bunce <bunce.andy@gmail.com> > wrote: > > Hi Michael, > > > > I get the same result. > > I believe the problem is [1]. S_LOCALHOST is "localhost". Maybe > > this > > needs > > to be HOST or SERVERHOST. > > > > /Andy > > > > > > > > > > https://github.com/BaseXdb/basex/blob/master/basex-api/src/main/java/org/bas... > > > > On 6 January 2016 at 21:54, C. M. Sperberg-McQueen > > <cmsmcq@blackmesatech.com> wrote: > >> > >> I'm running into a problem that perhaps others here can help > >> with. > >> It appears to be almost identical to the problem reported by > >> "P.C." > >> on 5 March 2014 under the subject line 'BaseX server.close() > >> "Connection > >> refused" in Openshift' [1]; the mail record in the basex-talk > >> archive > >> doesn't show a resolution to P.C.'s problem. The main difference > >> I > >> see > >> is that P.C. was deploying BaseX under Tomcat 7 on OpenShift, and > >> I'm using Andy Bunce's quickstart method. > >> > >> [1] > >> > >> > >> > >> https://www.mail-archive.com/basex-talk%40mailman.uni-konstanz.de/msg03861.h... > >> > >> I'm experimenting with Andy Bunce's BaseX quick-start for > >> OpenShift, > >> which I like a lot, and I am experiencing the following sequence > >> of > >> events: > >> > >> 1 Following the instructions at [2], I use rhc to make a new app, > >> add > >> the Quodatum repository as a remote, merge it into the > >> application > >> source, and push the result to OpenShift. (Note: no changes made > >> between the commands "git pull -s recursive -X theirs upstream > >> master" > >> and "git push origin master". The first time I tried it, I did > >> change > >> the admin password, but I thought that that might have something > >> to > >> do > >> with the problem, so I omitted that step for this test.) > >> > >> [2] https://github.com/Quodatum/openshift-basex-quick-start/ > >> > >> The OpenShift app is now available as promised at the URI > >> indicated > >> in > >> [1], namely http://TestAPP-CMSMcQ.rhcloud.com/ (except that > >> TestAPP > >> is > >> not really the name of the app, and CMSMcQ is not the name of the > >> domain). It's a very nice looking console app. > >> > >> > >> 2 I make some change -- any change -- to a file in the > >> repository. > >> To keep things simple, I'll add a comment line reading > >> > >> (: Kilroy was here :) > >> > >> to the file $app-name/basex/repo/quodatum/basex/env.xqm. > >> > >> I'm pretty sure I didn't break anything in the env.xqm file in > >> making > >> the change, and I didn't change anything in any other file. > >> > >> 3 I check the change in to the local git repository: > >> > >> # confirm that we have not touched anything else > >> git status > >> # commit the change > >> git add basex/repo/quodatum/basex/env.xqm > >> git commit -m "Vacuous change to env.xqm, just to have > >> something > >> to > >> check in" > >> > >> 4 I attempt to push the change to the deployed app. The response > >> is > >> shown below (in the extract below, 'Salerno' is the local name of > >> the > >> machine, 'TestAPP' stands in for the name of the test > >> application, > >> and > >> "CMSMcQ" for the OpenShift domain -- I've changed them here, > >> because as can be seen from the log below, the app is currently > >> open to anyone who knows the default admin userid and password). > >> > >> Salerno:TestAPP cmsmcq$ git push origin master > >> Counting objects: 7, done. > >> Delta compression using up to 8 threads. > >> Compressing objects: 100% (5/5), done. > >> Writing objects: 100% (7/7), 649 bytes | 0 bytes/s, done. > >> Total 7 (delta 2), reused 0 (delta 0) > >> remote: Stopping DIY cartridge > >> remote: HOST: 127.12.13.129 > >> remote: PORT: 15005 > >> remote: DEBUG: true > >> remote: USER: admin > >> remote: SERVERHOST: 127.12.13.129 > >> remote: STOPPORT: 15007 > >> remote: SERVERPORT: 15005 > >> remote: PASSWORD: admin > >> remote: java.io.IOException: Connection failed (port: 15007). > >> remote: at org.basex.BaseXHTTP.stop(BaseXHTTP.java:367) > >> remote: at org.basex.BaseXHTTP.stop(BaseXHTTP.java:180) > >> remote: at org.basex.BaseXHTTP.<init>(BaseXHTTP.java:94) > >> remote: at org.basex.BaseXHTTP.main(BaseXHTTP.java:50) > >> remote: Connection failed (port: 15007). > >> remote: An error occurred executing 'gear prereceive' (exit > >> code: > >> 1) > >> remote: Error message: CLIENT_ERROR: Failed to execute: > >> 'control > >> stop' > >> for /var/lib/openshift/568d73d67628e13ca2000004/diy > >> remote: > >> remote: For more details about the problem, try running the > >> command > >> again with the '--trace' option. > >> To > >> > >> > >> > >> ssh:// 568d73d67628e13ca2000004@TestAPP-CMSMcQ.rhcloud.com/~/git/TestAPP.git/ > >> ! [remote rejected] master -> master (pre-receive hook > >> declined) > >> error: failed to push some refs to > >> > >> > >> > >> 'ssh:// 568d73d67628e13ca2000004@TestAPP-CMSMcQ.rhcloud.com/~/git/TestAPP.git/' > >> Salerno:TestAPP cmsmcq$ > >> > >> I've logged in to the application using ssh and run the basexhttp > >> stop > >> command manually, and what one gets then is essentially the same. > >> > >> I think the root of the matter here is the line reading "remote: > >> java.io.IOException: Connection failed (port: 15007)", but I'm > >> having > >> trouble thinking of a fix. > >> > >> One could imagine that OpenShift doesn't like application code > >> using > >> a > >> port like 15007. But since it seems to have no trouble with > >> BaseX > >> using 15005, for the SERVERPORT, that doesn't seem to make sense. > >> > >> One could suppose that BaseX isn't actually listening on port > >> 15007. > >> The debugging output produced by -d, however does seems to show > >> that > >> BaseX knows that port 15007 is the stop port. Or does it? > >> Perhaps > >> it > >> means only that BaseX has successfully parsed the -s option on > >> the > >> 'stop' command, which reads: > >> > >> ${OPENSHIFT_DATA_DIR}/basex/binbasexhttp -d \ > >> -n ${OPENSHIFT_DIY_IP} -h > >> ${OPENSHIFT_DIY_PORT} > >> \ > >> -p ${PORT_DATABASE} -s ${PORT_STOP} \ > >> -U ${BASEX_USER} -P ${BASEX_PASSWORD} \ > >> stop > >> > >> which in turn expands to > >> > >> .../basex/binbasexhttp -d \ > >> -n 127.12.13.129 -h 8080 \ > >> -p 15005 -s 15007 \ > >> -U admin -P admin \ > >> stop > >> > >> The startup command uses the same values for the -p and -s > >> options, > >> so > >> it seems plausible that the start command is successfully setting > >> the > >> port. > >> > >> Several questions arise in connection with this problem, apart > >> from > >> the obvious and most important one, namely > >> > >> Q1 Does anyone reading this list understand where the problem > >> might > >> lie? > >> > >> The others that occur to me are: > >> > >> Q2 Is there a server command or an admin query that will show > >> what > >> ports a running instance of BaseX is listening to? Or would that > >> be > >> too broad a security violation? (It would be nice to confirm > >> that > >> BaseX > >> is actually listening for a stop signal on port 15007. > >> > >> Q3 A search through the file system of the application shows that > >> logs > >> are being written to > >> $APPLICATION_HOME/app-root/data/basex/data/.logs/ > >> -- is there any way to find out from a running server what > >> directory > >> it's writing the logs to, to save the trouble of sshing to the > >> application server and running > >> > >> find . -print0 | xargs -0 grep "User was logged in" > >> > >> or the equivalent? The admin:logs() function was helpful, but it > >> would have been even more helpful if it had helped me find the > >> logs > >> directory. > >> > >> Of course, I see now, looking at the documentation, that logs are > >> always (? or only by default?) written to > >> $DATABASE_DIRECTORY/.logs > >> -- > >> if I had been confident of knowing what directory was the > >> database > >> directory in this (still unfamiliar) setup, I would have known > >> where > >> to look. > >> > >> Q4 Is there a command or admin-module query that indicates what > >> directories BaseX regards as the base directory and the database > >> directory? It could be very helpful, if it's not regarded as too > >> great a security risk, for users trying to set things up in a new > >> configuration. > >> > >> Q5 OpenShift's documentation claims that it really wants > >> application > >> logs to go into $APPLICATION-HOME/app-root/logs/ -- is there any > >> way > >> to induce BaseX to write its logs there? The main advantage I > >> can > >> currently see is that it then becomes possible to examine them > >> with > >> the OpenShift rhc tools. > >> > >> Any light anyone can shed on these issues would be very welcome. > >> > >> Thanks! > >> > >> Michael Sperberg-McQueen > >> > >> -- > >>
> >> * C. M. Sperberg-McQueen, Black Mesa Technologies LLC > >> * http://www.blackmesatech.com > >> * http://cmsmcq.com/mib > >> * http://balisage.net > >>
> >> > >> > >> > >> > >
Hi Michael, I still know too less about Andy’s Openshift solution (I haven’t tried it personally so far), but maybe I can help answering some other questions:
Q2 Is there a server command or an admin query that will show what ports a running instance of BaseX is listening to?
I usually call "netstat -an" for that.
Q3 A search through the file system of the application shows that logs are being written to $APPLICATION_HOME/app-root/data/basex/data/.logs/ -- is there any way to find out from a running server what directory it's writing the logs to
Q4 Is there a command or admin-module query that indicates what directories BaseX regards as the base directory and the database directory?
You can use db:system() to get the value of the DBPATH option, and file:path-to-native to resolve it to the native, absolute path (provided that the requesting user has ADMIN permissions, or that you are using RESTXQ): file:path-to-native( db:system()//dbpath)
Q5 OpenShift's documentation claims that it really wants application logs to go into $APPLICATION-HOME/app-root/logs/ -- is there any way to induce BaseX to write its logs there?
Hm, tricky. Once we have switched to standard loggers [1], this may get easier. Hope this helps, Christian [1] https://github.com/BaseXdb/basex/issues/940
On Jan 7, 2016, at 1:33 AM, Christian Grün wrote:
...
Q2 Is there a server command or an admin query that will show what ports a running instance of BaseX is listening to?
I usually call "netstat -an" for that.
Q3 A search through the file system of the application shows that logs are being written to $APPLICATION_HOME/app-root/data/basex/data/.logs/ -- is there any way to find out from a running server what directory it's writing the logs to
Q4 Is there a command or admin-module query that indicates what directories BaseX regards as the base directory and the database directory?
You can use db:system() to get the value of the DBPATH option, and file:path-to-native to resolve it to the native, absolute path (provided that the requesting user has ADMIN permissions, or that you are using RESTXQ):
file:path-to-native( db:system()//dbpath)
Q5 OpenShift's documentation claims that it really wants application logs to go into $APPLICATION-HOME/app-root/logs/ -- is there any way to induce BaseX to write its logs there?
Hm, tricky. Once we have switched to standard loggers [1], this may get easier.
Hope this helps,
Very much. Thank you! -- **************************************************************** * C. M. Sperberg-McQueen, Black Mesa Technologies LLC * http://www.blackmesatech.com * http://cmsmcq.com/mib * http://balisage.net ****************************************************************
participants (3)
-
Andy Bunce -
C. M. Sperberg-McQueen -
Christian Grün