There's one problem that we're currently not looking at: The api daemon
uses the user name as identifier to separate between different users. The
name is sent in a message from the client to the server which means that it
could be forged, i.e. any user can access any other user's data. It is not
possible to avoid this when using TCP sockets for communication. Hence, we
have two problems here:
* Security: users on a shared host running ooRexx can compromise each other
* Manageability: Only one instance can use the ooRexx designated api port.
I think a clean solution would be to use UNIX sockets on Linux and similar
systems. I don't know about Mac or Windows but I'm sure there exists
something equivalent. Then, each user would have its own instance of the
api daemon that is accessible using a socket stored in the file system,
either the user's home directory or a temporary directory. On Linux,
various tools use this: tmux stores its socket in /tmp/tmux-$(id
-u)/default. Adapting ooRexx to use such a schema should be fairly easy.
Moritz
On Wed, Jul 6, 2016 at 7:40 AM, CVBruce <cvbr...@gmail.com> wrote:
> Yes, both ooRexx client program and rxapi would have to know where to look
> for the PID file. Unless there is a pre-arranged fall back place,
> something like ~/.ooRexx/rxapi.pid
>
> On Jul 6, 2016, at 3:25 AM, Rick McGuire <object.r...@gmail.com> wrote:
>
>
>
> On Wed, Jul 6, 2016 at 6:18 AM, Rony G. Flatscher <rony.flatsc...@wu.ac.at
> > wrote:
>
>>
>> On 05.07.2016 22:43, CVBruce wrote:
>>
>> Although this gets around the pid file problem, it doesn’t get around the
>> port problem, you can still only run one rxapi process per computer. For
>> example you can’t run both 32bit and 64bit rxapi concurrently on the same
>> box, even if your have different pid files. You can’t run ooRexx V4.2 and
>> V5.0 concurrently on the same computer.
>>
>> Moving the PID file will only allow one user to run ooRexx in a shared
>> environment.
>>
>>
>> Is it the case that only the registered port number 10010 gets used? What
>> happens, if it cannot be used, because another process uses it already at
>> the time rxapi starts up?
>>
>
> rxapi won't be able to start and services that require it will fail.
>
>
>>
>> ---
>>
>> I always have thought that there is a fallback solution in asking the
>> operating system to supply a free port (if the ooRexx assigned port was in
>> use and hence opening it would fail) by requesting the port number 0 (then
>> the system assigns a free port instead, which can be retrieved from the
>> returned socket) and then "somehow" communicating it to the clients.
>>
>
> There is no fallback. Since the client needs to be able to locate the
> server, this would be somewhat of a challenge.
>
>
>>
>>
>> Knowing the PID of the rxapi process would allow identify the port that
>> process has opened and its state. On the commandline you could do something
>> like:
>>
>> - get the PID number from the PID file (e.g. "cat ooRexx.pid")
>> - get the tcp port opened from the process with the found PID number
>> (e.g. "netstat -ano | grep PID-number" or something like that) and analyze
>> the result for the port
>>
>> So in the case that we have a rxapi daemon running (probably using the
>> official ooRexx port) it should still be possible to run local instances of
>> rxapi if they use different ports, once a fallback solution was agreed
>> upon.
>>
>
> Ummm, if you're looking to use local instances, then there will not be a
> pid file available to locate the process id.
>
>
>>
>> How about creating an "ooRexx.port" text file in the same place where the
>> "ooRexx.pid" file gets created and stored?
>>
>
> Again, this would probably require some level of superuser authority,
> which is the problem you are trying to solve.
>
> Rick
>
>
>>
>> ---rony
>>
>>
>>
>> On Jul 5, 2016, at 10:39 AM, Michael Lueck <mlu...@lueckdatasystems.com>
>> <mlu...@lueckdatasystems.com> wrote:
>>
>> Greetings Chip,
>>
>> Chip Davis wrote:
>>
>> Would you care to describe your magic incantation?
>>
>> Most of the documentation is in that RFE...
>>
>>
>> "#542 Support non-root interpreter installation and execution on Unix-like
>> systems"
>> https://sourceforge.net/p/oorexx/feature-requests/542/
>>
>>
>> Specifically changing on of the ooRexx source files:
>>
>> rexxapi\server\platform\unix\APIService.cpp
>>
>> // For testing purposes comment out the following line to force RXAPI to
>> // run as a foreground process.
>> #undef RUN_AS_DAEMON
>>
>> #ifdef RUN_AS_DAEMON
>> #define OOREXX_PIDFILE "
>> <https://sourceforge.net/p/oorexx/feature-requests/542/SpecificallychangingonoftheooRexxsourcefiles:rexxapi%5Cserver%5Cplatform%5Cunix%5CAPIService.cpp//FortestingpurposescommentoutthefollowinglinetoforceRXAPIto//runasaforegroundprocess.#undefRUN_AS_DAEMON%23ifdefRUN_AS_DAEMON%23defineOOREXX_PIDFILE>/var/run/ooRexx.pid"
>> bool run_as_daemon = true;
>> #else
>> #define OOREXX_PIDFILE
>> "/kunden/homepages/35/d157794216/htdocs/opt/oorexx/var/run/ooRexx.pid"
>> bool run_as_daemon = true;
>> #endif
>>
>>
>> Then building and installing from the patched source.
>>
>> My organization standard was to in my home directory build an opt/
>> directory, then package names as the next level... and to consider that
>> directory as the virtual root. Thus .../var/run/ right where
>> ooRexx wanted to place its PID file in the first place.
>>
>> I am thankful,
>>
>> --
>> Michael Lueck
>> Lueck Data Systemshttp://www.lueckdatasystems.com/
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>> present their vision of the future. This family event has something for
>> everyone, including kids. Get more information and register today.
>> http://sdm.link/attshape
>> _______________________________________________
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>
>>
>
> ------------------------------------------------------------------------------
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape_______________________________________________
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>
>
>
> ------------------------------------------------------------------------------
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> _______________________________________________
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>
--
Moritz Hoffmann;
http://antiguru.de/
------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
