How to run an existing service on OOD

[lurenpluto]

Our OOD is positioned as a personal server, so now I'm thinking about a question: I have my own OOD, and in order to make the most of this personal server, I want to run some of my desired services on it, such as the hot stable diffution, can these services be run as a dec app? How do I use it? Considering the following questions, please feel free to join the discussion!

1. What extra help can cyfs provide for these services? What are the advantages over building directly on my own VPS ?
2. After deploying and running with a dec app, what do these services need to be adapted to, and can they run as a dec app without any modification and adaptation?
3. How will users use the services provided by the dec app itself, such as the current http management page?
4. Can the existing cyfs protocol support the access and use of these dec apps?

[wugren]

The main problem of running existing services should be permissions. The current dec app permission system may not meet the requirements. It is necessary to design a safe and easy-to-use permission system, but this is more complicated. The easiest way is to use the dec app whitelist, and the dec app in the whitelist runs directly with root privileges.

[lurenpluto]

Regarding the permissions of dec service, you can consider the following perspectives

1. Permissions for OOD system and hardware

Nowadays, the dec service is "untrusted" by default on nix systems, so docker is used for isolation, but this is not the only and unchanging solution. From this point of view, if the needs of a dec service exceed the existing docker permission limits, we can consider the following improvements

• To further open the relevant permissions inside docker, need to be explored
• Use other more appropriate permission isolation schemes instead of docker
• Run the "trusted" dec service directly on OOD

2. DEC service permissions on OOD data

This currently goes the whole cyfs permission system, can access the specified object and chunk, should basically meet the needs; if there are special needs, need to further consider improving the permission system, or open the system-level permissions for the "trusted" dec service, etc.

3. DEC service's permission to provide services to the public

This is also the next step to improve the focus of the current dec service to provide services to the public, generally common the following kinds of.

• Set appropriate permissions for object/global-state-path
  So that inside and outside the zone can directly use the standard get interface to access the corresponding object/chunk
• Through call(post-object)
  Need to set the appropriate permissions based on req-path
• Provide built-in page access through A-Link
  This is registered to the root-state when the dec service is installed, and supports access within the same zone

On the basis of the above, we should consider providing further access services and permission configuration for the dec service, for example, we can directly provide traditional web services (similar to nginx's reverse proxy service), and provide convenient configuration and permission support on this basis, such as supporting the same zone or cross-zone, which dec and zone have permission to access the corresponding services, etc.

[lurenpluto]

Gateway in the most initial version, support bdt protocol-based reverse proxy, similar to nginx, but this is relatively primitive, and not integrated into the cyfs-stack internal, so only gateway has this feature, and cyfs-runtime and other places that only use cyfs-stack, there is no way to use this feature directly Therefore, it is very limited.

So from the above point of view, consider upgrading the reverse proxy as a basic feature of cyfs-stack, providing a stream-based reverse proxy that can be used directly by the dec, such as a traditional web server, which can be ported to a dec service relatively easily based on this feature

So this reverse proxy, can be considered from both the client and service side, what should it look like?

Server side

The server side is considered to have the following features

• Someone can register a special req-path as the path of the proxy and assign the corresponding permissions
  req-path is on the root-state, under the root of the dec service, and can be a special class of path, or can be associated with a special leaf node object to distinguish it
• Each req-path can specify a local service address of the dec service, which can be http/tcp/udp protocol
  After the dec service starts, it needs to listen to the local address and port, for example

127.0.0.1:1234

And process the corresponding requests on this address, here we need to make different distinctions according to tcp and udp protocols

• cyfs-stack assigns a bdt virtual port to the req-path
  All requests from this port are forwarded to the local listening address corresponding to req-path, which also needs to be done differently according to tcp and udp protocols
  o tcp is connection-oriented, so cyfs-stack needs to maintain this connection mapping relationship
  o udp is packet-oriented, so in theory it only needs to simply forward

• Integration permissions
  Based on the bdt protocol, the identity of the source device is reliable, so we can do the permission distinction inside and outside the zone; the source dec of the request is more troublesome, but it should still be consistent with our permission system, and for the "sandbox" dec inside the zone, the dec should be reliable; the rest The rest are considered unreliable

Client side

The client side is considered to have the following features

• can use device+vport directly
  If client has embedded cyfs-stack, it can directly use internal bdt-stack to initiate connection/send data to target dec service, based on target device+vport, it can uniquely identify a local service of dec service

• Use of req-path based
  For a given {zone}+{dec-id}+{req-path}, query the corresponding reverse proxy service, for example, design a proxy object to describe the corresponding proxy information; client if the query is a proxy object instead of a file object, then try to extract the corresponding proxy information from the proxy object corresponding proxy information, and use bdt-satck+vport to initiate forwarding

• Use in cyfs-browser
  Consider an A-Link based implementation that implements proxy services for different dec services based on specific a connections

• cyfs-runtime supports local proxies
  cyfs-runtime can be considered to support local proxies, but how to enable them correspondingly? Probably still based on A-Link requests, and in the request with a local proxy interface, so that the dec app inside can directly based on http/tcp/udp and dec service interaction

Integration with A-Link

At present, the A-Link protocol is used to open the built-in page of dec, which is still based on object+chunk process; on the basis of the above support for dec service reverse proxy, consider adding support for stream-based process

For example, in the address bar of cyfs-browser, open the following url

cyfs://a/{zone}/{dec-id}/{req-path}

cyfs-stack internally initiates a query request to the target {zone} (consider still get object), and if the req-path is found to correspond to an http reverse proxy, then it directly initiates a connection to the corresponding device+vport to forward the request to the browser

[lurenpluto]

Based on the above design and ideas, the reverse proxy services supported under the cyfs framework should look like the following:

[streetycat]

How about to add a redirect proxy to nginx? We only use CYFS as transport layer.

1. Integrate nginx in the OOD.
2. The gateway receive http requests wraped with Objects.
3. Unwrap the Objects to original http requests, and redirect to the nginx.
4. nginx redirect to the service without any updates.

But we should modify the way of accessing the service to distinguish classic HTTP requests and encapsulate them into Object.

[lurenpluto]

I think the key to this design is whether cyfs-stack(gateway) should support none-object forwarding services and in what form? At present, the granularity of data handled by cyfs-stack is object-based, but in traditional web2, it is based on stream/http request/udp package, so if we want to add support for these data types, in what form?

1. based on object
   The request data is wrapped into object on the request side, then go with req-path+call(post-object), the object is unpacked on the target side, and then distributed according to req-path
   Is it possible to implement this model by adding a layer on top of the existing cyfs-stack? No need to change cyfs-stack itself

2. Connection-based
   Use req-path+zone(device-id)+vport on the request side to establish a connection with the target side at the bdt layer and forward the stream/udp package/http request directly

So what are the advantages and disadvantages of each of these two forms? What does the data flow model look like for each pattern? How should it be used from a developer's point of view? Is it possible to support the traditional http/tcp/udp development model in a relatively simple and fast way?

[lurenpluto]

It is possible to cut through the current process of opening A-Links in a different way and see what this new process should look like?

Inside cyfs-browser, access the built-in web directory of the dec-service via the following A-Link

cyfs://a/{dec-id}/index.html

Then look at the flow from the dec-service and dec-app webpage perspective respectively.

Dec-service side

When dec is installed, if there is a local web directory, then app-manager needs to call publish the local web directory during installation, i.e. generate the corresponding file objects and web-dir-id (always is an object-map object), and update the corresponding file objects and web-dir-id (always is an object-map object), and hang the latest web-dir-id on the root-state, which is available for query

cyfs-runtime side

1. When cyfs-runtime opens the above A-Link, it first requests with {dec-id} from ood for the current web-dir-id
2. After getting the web-dir-id, request the object(file object) corresponding to /index.html from ood via get_object(wed-dir-id, "/index.html")
3. After getting the object, request the data corresponding to the object via get_data(object_id) (NDN)

From the above process, if a dec service wants to use Nginx-like mechanism to process some requests dynamically like web2, it's still very troublesome to generate a lot of object and file data, and these data must be recorded to the noc and ndc, tracker of cyfs-stack, so I feel this mode is not suitable for processing dynamic html requests