Larch backend serving multiple users

[tschoonj]

Hello again,

Today we ran into our first real problem with the Larch backend.

1. User A starts lathena, which in turn starts the larch_server
2. User A closes lathena and logs out. The larch_server keeps running as daemon
3. User B logs in, starts lathena. He opens a file somewhere in his home directory but gets an error message saying that the file could not be opened. No new larch_server was launched because it's already running, though the process is owned by User A.
4. User B starts dathena, which opens this file without any problem.
5. Copy the file to User A's home folder, login as User A, launch lathena and open the copied file -> works perfectly!

It took us some to figure out what was going on here but I think we got it: Since the larch_server is owned by User A, it will only ever be able to open files that have the correct read permissions for User A, regardless of who is actually running the Athena session. This is why the Ifeffit backend had no problem opening this file.

Suggested solution: every user should have its own larch_server running. This would obviously require unique port numbers for each user when launching the daemon. Using something like Proc::ProcessTable it should be possible to see what larch_server instances are already running and figure out which port numbers were used as command-line argument, allowing me to come up with a new, unique number greater than 4966.

Even though my Perl skills are not great, I should be able to implement something like this. Do you think this would be a valuable addition? Or do you have a better solution how to fix this?

Thanks,

Tom

[bruceravel]

Off the top of my head, I do not have a better solution. If you would be willing to hack up something that works for you, I would be very grateful.

A word about how Demeter starts working with larch. It's all here, with this file providing the parameterization. Perhaps the best thing would be to generate that yaml file dynamically (i.e. figure out the server address and port number on the fly), putting it someplace that Demeter can find it at start up. Then Larch.pm can be modified slightly to look for the dynamically generated yaml file first before falling back on the standard one.

The advantage of this approach is that you can do so with a shell script rather than having to write perl. Or, if you love Rube Goldberg, write a python script that launches Demeter in a way that it correctly starts the larch server. Bonus points if that solution involves a parrot or an open flame :smile:

[bruceravel]

Tom, This gist has the first several lines of Larch.pm with a slight modification to look first for $HOME/.horae/larch_server.yaml. With that modification to Larch.pm and a pretty simple shell script, I think you would solve your problem.

1. Alias "athena" to the shell script
2. Figure out an unused port number using any command line tool
3. Write $HOME/.horae/larch_server.yaml
4. Launch Athena

[newville]

In principle, a process should be able to launch a larch server on a unique port, then connect to that. You'd want to tell the server to shutdown on exit or have some system-wide way to kill zombie servers.

I'd imagine lathena could go through a range of port numbers, trying to connect to each until it finds a free one available and then start the server with that.

The server could also have (but does not currently) have a "self destruct time" and any client has to periodically set this (to say, 1 day in the future)..

[bruceravel]

Figure out an unused port number using any command line tool

This works on my ubuntu box: http://unix.stackexchange.com/a/55940

Alternately, as Matt suggests, the lathena script itself could do something like the second part of that Stack Exchange post.

Tom, think about what solution suites you best. At this point, my preference is to whatever makes you happiest.

[tschoonj]

Thanks for the useful advice Bruce. I will probably stick with a pure Perl solution: it's been over a decade that I did serious Perl programming but I should be able to pull this off.

I agree with Matt that the larch server should shutdown when Athena exits, at least if no other lathena sessions are running for that user.

[tschoonj]

By the way: does the larch backend work on Windows?

[bruceravel]

To the best of my knowledge, it does work on Windows. It has, however, been quite some time since I last gave it a try.

I'm away from the office today, but I'll be available to help out with your solution to this problem on Monday.

[newville]

@tschoonj @bruceravel The larch server should work on Windows, but I can believe it is slightly fragile in that the location of Python needs to be known ahead of time. For other reasons, I'm currently recommending Anaconda Python for Windows and Mac, and I don't think I have tested dathena with this. I don't see why it shouldn't work, but Windows is (are?) good at showing cracks. If there are problems, the fixes should be easy. Also, I haven't tested with Python3.

That said, I think Demeter will never be able to guess reliable where the larch_servers is on Windows or any machine using Anaconda Python, as it installs in the users home directory, but especially Windows with Roaming/Local profiles and similar "features". Demeter should be told where the larch_server executable is.