2 rs-serve - A remotestorage server implementation
3 ================================================
11 2.3 authorization tools
17 3.4 Installing system-wide
19 3.6 Integrating authorization
24 remotestorage is an open specification for personal data storage. It is supposed to
25 replace the currently popular proprietary "cloud storage" protocols using an open
26 standard and thereby promoting the seperation of applications and their data on the
29 For more information, check out these links:
30 * http://remotestorage.io/ - Information about the remotestorage protocol and
31 current implementations.
32 * http://unhosted.org/ - Philosophy, hands-on Tutorials and App collection.
37 rs-serve brings three things:
38 * a HTTP endpoint implementing remotestorage: /storage/{user}
39 * a HTTP endpoint implementing webfinger: /.well-known/webfinger
40 * a collection of scripts to manage authorizations: add/remove/list token(s)
42 The user management is taken care of by the system. Each system user with an allowed
43 user id (default: >= 1000. Minimum defined by RS_MIN_UID in src/config.h) can access
44 their ~/storage/ directory (configurable via --dir option) using the remotestorage
47 rs-serve is entirely written in C, using mostly POSIX library functions. It relies
48 on a few portable libraries, see the list under "Dependencies" below.
49 It does however currently use the signalfd() system call, which is only available
50 on Linux. (this is a solvable problem though, if you want to be able to run on
51 another system, please open an issue to ask for help)
56 The currently implemented protocol version is "draft-dejong-remotestorage-01".
58 Currently the following features are supported:
59 * CORS support for all verbs
60 * GET, PUT, DELETE requests on files and folders
61 * Opaque version strings (in directory listings and "ETag" header)
62 * Conditional PUT and DELETE requests ("If-Match", "If-None-Match" headers)
63 * HEAD requests on files and folders with "Content-Length" header
64 (not part of remotestorage-01)
69 The webfinger implementation only serves information about remotestorage and is
70 currently not extensible.
71 The hostname part of user addresses is expected to be the hostname set for the
72 rs-serve instance. This currently defaults to "local.dev" and can be overridden
73 with the --hostname option.
74 Virtual hosting (== hosting storage for multiple domains from a single instance)
75 is currently not supported.
77 2.3) authorization tools
78 ------------------------
80 Authorization has to be handled elsewhere. remotestorage-00 requires the storage
81 provider to bring an OAuth 2 endpoint that can do implicit grant flow.
82 This endpoint is not part of rs-serve for vague reasons.
84 In order to run a fully functional remotestorage provider, you must cook one up
85 yourself (TODO: add link to un.ht customer backend) and hook it up to rs-serve.
87 See the section titled "Integrating authorization" for details.
92 The payload data of the remotestorage endpoint is stored on the local filesystem
93 within the respective user's home directory.
95 Thus a few restrictions apply:
97 * The remotestorage endpoint cannot be used to store both a directory and a file
98 under the same path (ignoring the trailing slash). That means you cannot store
99 /foo/bar/baz and /foo/bar, but only one of them. This is a natural restriction
100 of traditional filesystems, that is currently well adhered to by all apps using
101 remotestorage (as far as I know).
103 * MIME types may not be exact for files that were added "out-of-band", that is
104 not added via the remotestorage protocol, but by copying to the ~/storage/
105 directory by other means. rs-serve stores MIME type and character encoding
106 under the "user.mime_type" and "user.charset" extended attributes, given these
107 are supported by the underlying filesystem. When these attributes aren't set,
108 a MIME type is guessed using libmagic, which may not always yield desirable
109 results. (for example an empty file, created using "touch" will be transmitted
110 via remotestorage with a Content-Type header of "inode/x-empty; charset=binary")
111 If even libmagic fails to make sense of a file, the Content-Type is set to
112 "application/octet-stream; charset=binary".
117 These steps should enable you to install rs-serve.
123 - pkg-config (or tweak the Makefile)
130 On Debian based systems, this should give you all you need:
132 apt-get install build-essential libevent-dev libmagic-dev libattr1-dev
134 If you want to develop, you may also want debug symbols and valgrind (required by
135 leakcheck.sh script):
137 apt-get install libevent-dbg valgrind
139 3.2) Getting the code
140 ---------------------
142 Given you are reading this file, you probably have the code already, but just to
145 Currently the rs-serve code is hosted on github.
147 You can browse it online, at:
149 https://github.com/remotestorage/rs-serve
151 or close it using git:
153 git clone git://github.com/remotestorage/rs-serve.git
158 Given you have all dependencies installed, simply run
162 and you should be good to go.
164 3.4) Installing system-wide
165 ---------------------------
167 To install the rs-serve binary to /usr/bin, run
171 as a privileged user.
173 To install somewhere else, tweak the Makefile first.
175 This will also install an init script to /etc/init.d/rs-serve and a default
176 configuration to /etc/default/rs-serve.
178 On Debian based systems (i.e. when "update-rc.d" is present), "make install"
179 will also install the rs-serve init script into /etc/rc*.d/.
184 There are a variety of options
186 If you want to use the init script, you can set options in /etc/default/rs-serve,
187 otherwise just pass them on the command line.
193 to get a list of supported options.
195 3.6) Integrating authorization
196 ------------------------------
198 To integrate an authorization endpoint, you need to do two things:
200 * configure endpoint URI
202 Set the --auth-uri-format option to a printf style format string. "%s" will be
203 replaced with the username.
205 * configure your authorization endpoint to manage rs-serve tokens
207 rs-serve doesn't care where tokens come from, but it need to know them to
208 decide whether a given request is authorized or not. It maintains an internal
209 store for authorizations (i.e. structures of [user-name, token, scopes]),
210 which must be managed from the outside.
212 The tools to do this are:
216 Usage: rs-add-token <user> <token> <scope1> [<scope2> ... <scopeN>]
218 - <user> is the login name of the user (rs-serve must be able to resolve
219 it using getpwnam() in order to find the home directory)
220 - <token> is the token string authenticating future requests. For rs-serve
221 it is an opaque string.
222 - <scope1>..<scopeN> are scope strings in the same form as described in
223 draft-dejong-remotestorage-01, Section 9.
227 Usage: rs-remove-token <user> <token>
229 <user> and <token> must both be given.
230 If the token cannot be found, rs-remove-token terminates with non-zero status.
234 Lists all currently installed tokens and their respective scopes.
236 The output format is primarily meant for (human) debugging and subject to change.
241 * If you've found a bug, or have any questions, please open an issue on github:
242 https://github.com/remotestoage/rs-serve/issues
244 * If you want to contribute, fork the project on github and send pull requests.
246 * In any case, don't hesitate to talk with us on IRC:
247 #remotestorage and #unhosted, both on irc.freenode.org
250 - #unhosted: http://webchat.freenode.net/?channels=unhosted
251 - #remotestorage: http://webchat.freenode.net/?channels=remotestorage