problems with BaseX under OpenShift (connection failed on port 15007)

On 6 January 2016 at 21:54, C. M. Sperberg-McQueen <cmsmcq at 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.html > > 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 at TestAPP-CMSMcQ.rhcloud.com/~/git/TestAPP.git/ > ! [remote rejected] master -> master (pre-receive hook declined) > error: failed to push some refs to 'ssh:// > 568d73d67628e13ca2000004 at 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 7 January 2016 at 01:59, C. M. Sperberg-McQueen <cmsmcq at 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/basex/BaseXHTTP.java#L375 > > > > 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/basex/BaseXHTTP.java#L152 > > 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 > **************************************************************** > > > > >

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/basex/BaseXHTTP.java#L375

> Q2 Is there a server command or an admin query that will show what > ports a running instance of BaseX is listening to?

> 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?

> 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?

>> 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/basex/BaseXHTTP.java#L375

On Thu, Jan 7, 2016 at 1:18 AM, Andy Bunce <bunce.andy at 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/basex/BaseXHTTP.java#L375 > > On 6 January 2016 at 21:54, C. M. Sperberg-McQueen > <cmsmcq at 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.html >> >> 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 at TestAPP-CMSMcQ.rhcloud.com/~/git/TestAPP.git/ >> ! [remote rejected] master -> master (pre-receive hook declined) >> error: failed to push some refs to >> 'ssh://568d73d67628e13ca2000004 at 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 7 January 2016 at 08:46, Christian Grün <christian.gruen at 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/basex/BaseXHTTP.java#L375 > > 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 at 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/basex/BaseXHTTP.java#L375 > > > > On 6 January 2016 at 21:54, C. M. Sperberg-McQueen > > <cmsmcq at 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.html > >> > >> 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 at TestAPP-CMSMcQ.rhcloud.com/~/git/TestAPP.git/ > >> ! [remote rejected] master -> master (pre-receive hook declined) > >> error: failed to push some refs to > >> 'ssh:// > 568d73d67628e13ca2000004 at 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.

> 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/.openshift/action_hooks/stop > [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 at 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/basex/BaseXHTTP.java#L375 >> >> 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 at 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/basex/BaseXHTTP.java#L375 >> > >> > On 6 January 2016 at 21:54, C. M. Sperberg-McQueen >> > <cmsmcq at 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.html >> >> >> >> 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 at TestAPP-CMSMcQ.rhcloud.com/~/git/TestAPP.git/ >> >> ! [remote rejected] master -> master (pre-receive hook declined) >> >> error: failed to push some refs to >> >> >> >> 'ssh://568d73d67628e13ca2000004 at 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

On 7 January 2016 at 10:02, Christian Grün <christian.gruen at 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/.openshift/action_hooks/stop > > [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 at 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/basex/BaseXHTTP.java#L375 > >> > >> 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 at 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/basex/BaseXHTTP.java#L375 > >> > > >> > On 6 January 2016 at 21:54, C. M. Sperberg-McQueen > >> > <cmsmcq at 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.html > >> >> > >> >> 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 at TestAPP-CMSMcQ.rhcloud.com/~/git/TestAPP.git/ > >> >> ! [remote rejected] master -> master (pre-receive hook declined) > >> >> error: failed to push some refs to > >> >> > >> >> 'ssh:// > 568d73d67628e13ca2000004 at 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.

> /Andy > > On 7 January 2016 at 10:02, Christian Grün <christian.gruen at 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/.openshift/action_hooks/stop >> > [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 at 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/basex/BaseXHTTP.java#L375 >> >> >> >> 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 at 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/basex/BaseXHTTP.java#L375 >> >> > >> >> > On 6 January 2016 at 21:54, C. M. Sperberg-McQueen >> >> > <cmsmcq at 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.html >> >> >> >> >> >> 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 at TestAPP-CMSMcQ.rhcloud.com/~/git/TestAPP.git/ >> >> >> ! [remote rejected] master -> master (pre-receive hook declined) >> >> >> error: failed to push some refs to >> >> >> >> >> >> >> >> >> 'ssh://568d73d67628e13ca2000004 at 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 7 January 2016 at 11:52, Christian Grün <christian.gruen at 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 at 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/.openshift/action_hooks/stop > >> > [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 at 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/basex/BaseXHTTP.java#L375 > >> >> > >> >> 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 at 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/basex/BaseXHTTP.java#L375 > >> >> > > >> >> > On 6 January 2016 at 21:54, C. M. Sperberg-McQueen > >> >> > <cmsmcq at 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.html > >> >> >> > >> >> >> 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 at TestAPP-CMSMcQ.rhcloud.com/~/git/TestAPP.git/ > >> >> >> ! [remote rejected] master -> master (pre-receive hook > declined) > >> >> >> error: failed to push some refs to > >> >> >> > >> >> >> > >> >> >> 'ssh:// > 568d73d67628e13ca2000004 at 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/basex/BaseXServer.java#L313

> > 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/.openshift/action_hooks/stop#L8 > > > > > > On 7 January 2016 at 11:52, Christian Grün <christian.gruen at 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 at 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/.openshift/action_hooks/stop >> >> > [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 at 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/basex/BaseXHTTP.java#L375 >> >> >> >> >> >> 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 at 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/basex/BaseXHTTP.java#L375 >> >> >> > >> >> >> > On 6 January 2016 at 21:54, C. M. Sperberg-McQueen >> >> >> > <cmsmcq at 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.html >> >> >> >> >> >> >> >> 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 at TestAPP-CMSMcQ.rhcloud.com/~/git/TestAPP.git/ >> >> >> >> ! [remote rejected] master -> master (pre-receive hook >> >> >> >> declined) >> >> >> >> error: failed to push some refs to >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> 'ssh://568d73d67628e13ca2000004 at 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 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,

On 7 January 2016 at 18:11, Christian Grün <christian.gruen at 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/basex/BaseXServer.java#L313 > > 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/.openshift/action_hooks/stop#L8 > > > > > > > > > > > > On 7 January 2016 at 11:52, Christian Grün <christian.gruen at 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 at 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/.openshift/action_hooks/stop > >> >> > [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 at 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/basex/BaseXHTTP.java#L375 > >> >> >> > >> >> >> 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 at 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/basex/BaseXHTTP.java#L375 > >> >> >> > > >> >> >> > On 6 January 2016 at 21:54, C. M. Sperberg-McQueen > >> >> >> > <cmsmcq at 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.html > >> >> >> >> > >> >> >> >> 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 at TestAPP-CMSMcQ.rhcloud.com/~/git/TestAPP.git/ > >> >> >> >> ! [remote rejected] master -> master (pre-receive hook > >> >> >> >> declined) > >> >> >> >> error: failed to push some refs to > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> 'ssh:// > 568d73d67628e13ca2000004 at 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 > >> >> >> >> > **************************************************************** > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> > > >> >> > > >> >> > > >> > > >> > > > > > >