Introduce a bit of hierarchy there, at some stage we'll want to re-order the
tile requests a bit so that it works better for collaborative editing; for the
moment, removing the duplicate entries is enough.
Don't pretend that we know where jails will be, the may be elsewhere. If
indexing jails/systemplate is problem, configure them outside the build
tree instead.
(Instead of having them as separate SOURCEn in the loolwsd.spec.)
Both are related to systemd. The latter probably is relevant only for
openSUSE. (And I actually couldn't get what I tried doing in it to work, see
739edf9dcf464f407dfe663fb2f497b866e73333.)
(cherry picked from commit f8b29d666d52a3f18b0125aaed309fa3e4d719fb)
At least when not running as the owner of those files. Refactor the capability
dropping so that we can separately drop the CAP_FOWNER and CAP_SYS_CHROOT
capabilities. The child process never needs CAP_FOWNER and the parent process
never needs CAP_SYS_CHROOT.
It was a bit misleading to have "chroot" in the name of the script as it isn't
a chroot jail as such that the script is setting up, but a *template* that
will be copied (hardlinked) into each chroot jail.
The script should be installed, so that a loolwsd package can include it. We
don't want to loolwsd use to depend on having the sources available,
obviously.
Use setuid root otherwise. (But note that the portablity to other
Unixes is a work in progress, and for instance it is known that this
doesn't work on OS X yet.)
Makefile.am:18: warning: deprecated feature: target 'SETCAP' overrides 'SETCAP$(EXEEXT)'
Makefile.am:18: change your target to read 'SETCAP$(EXEEXT)'
/usr/share/automake-1.13/am/program.am: target 'SETCAP$(EXEEXT)' was defined here
Makefile.am:1: while processing program 'SETCAP'
Works now for the trivial 'connect' test program. Still need to add
pre-spawning of a new child process as soon as an existing one from the pool
has been taking into use. And need to test with the actual JS client.
Add a new program, loadtest, that runs a requested number of client sessions
in parallel to a loolwsd server. A client session loads one of a list of test
documents, and does some operations on it.
Move the getTokenInteger() and getTokenString() functions out from LOOLSession
into a new namespace LOOLProtocol, as they are neeeded also in the loadtest
program.
Add, also in LOOLProtocol, functions to parse some of the messages from the
server. (In general that is done in client JavaScript code, of course; only
for testing purposes needed in C++ code.)
For now, each LOOL client has a separate child process (or none at all, if it
has accessed only information found in the cache). This will obviously have to
chnage to handle collaboration. Etc.
The parent process talks the same Websocket protocol with the child
processes. When there is a child process for a client, traffic from the client
is forwarded as such to the child process and vice versa.
Will be needed if we want loolwsd to run on Windows. Then we will have one
process receiving the connections from WebSocket clients and sending the
accepted connection sockets to child processes thatr might be already running,
either because they have been "pre-forked", or because of a collaboration
scenario where new clients join a session working on a document.
But initially we will write this as if for Unix only, so development of this
migratory socket stuff is paused for now. (And it isn't even clear whether the
API design so far is a good idea and elegantly implementable.)
