| 2012-09-21 09:38:20 |
Jason Gerard DeRose |
bug |
|
|
added bug |
| 2012-09-21 09:41:05 |
Jason Gerard DeRose |
description |
Requiring an open port accepting outside connections is a bit scary, but there's no other way to do device to device file transfer and CouchDB replication on the local network. Use the cloud (and Internet) when it helps solve the problem, but never depend on it.
And worse, right now we have two open ports (file transfer, and CouchDB). So we want to condense this into a single HTTPS server that handles file transfers, and proxies requests to CouchDB. Many things about CouchDB's design make me not thrilled about having it directly accepting outside connections, so CouchDB will only listen on 127.0.0.1.
This server will be launched via it's own executable so we can use a tightly contained AppArmor profile. It needs to talk to CouchDB, and it needs read access to files in FileStore (.dmedia/files/*/*). A few restrictions I think are prudent:
* No DBus access whatsoever... the needed CouchDB env will be passed via stdin when the server is launched
* Server will use SSL and will only accept connections from clients with certs signed by user CA or otherwise in a cert whitelist
* Server should block access to all the "fun" CouchDB paths like /_config, /_replicate, etc... we probably want to block all the /_foo paths, and some of the /dbname/_bar paths too
* Server should be smart about using limited credentials when forwarding to CouchDB... this is especially important once we can do project sharing on the local network
* Server should be smart about limiting what CouchDB paths can be accessed based on the cert the client is connecting with... again, this is especially important for localnet project sharing. For example, the users other devices need to replicate dmedia-0, but "outside" users should never have access to dmedia-0 (they should only be able to access the dmedia-0-foo and novacut-0-bar project databases).
I also want this server to use IPv6. As this is only indented for localnet use, it doesn't matter if the ISP offers IPv6 support. When there isn't an IPv6 DHCP server, Ubuntu automatically configures all networking interfaces with IPv6 link-local addresses (derived from the MAC address). So that means you could plug two devices together with an Ethernet cable, and it would just work, with no config, no DHCP server. |
Requiring an open port accepting outside connections is a bit scary, but there's no other way to do device to device file transfer and CouchDB replication on the local network. Use the cloud (and Internet) when it helps solve the problem, but never depend on it.
And worse, right now we have two open ports (file transfer, and CouchDB). So we want to condense this into a single HTTPS server that handles file transfers, and proxies requests to CouchDB. Many things about CouchDB's design make me not thrilled about having it directly accepting outside connections, so CouchDB will only listen on 127.0.0.1.
This server will be launched via it's own executable so we can use a tightly contained AppArmor profile. It needs to talk to CouchDB, and it needs read access to files in FileStore (.dmedia/files/*/*). A few restrictions I think are prudent:
* No DBus access whatsoever... the needed CouchDB env will be passed via stdin when the server is launched
* Server will use SSL and will only accept connections from clients with certs signed by user CA or otherwise in a cert whitelist
* Server should block access to all the "fun" CouchDB paths like /_config, /_replicate, etc... we probably want to block all the /_foo paths, and some of the /dbname/_foo paths too
* Server should be smart about using limited credentials when forwarding to CouchDB... this is especially important once we can do project sharing on the local network
* Server should be smart about limiting what CouchDB paths can be accessed based on the cert the client is connecting with... again, this is especially important for localnet project sharing. For example, the users other devices need to replicate dmedia-0, but "outside" users should never have access to dmedia-0 (they should only be able to access the dmedia-0-foo and novacut-0-bar project databases).
I also want this server to use IPv6. As this is only indented for localnet use, it doesn't matter if the ISP offers IPv6 support. When there isn't an IPv6 DHCP server, Ubuntu automatically configures all networking interfaces with IPv6 link-local addresses (derived from the MAC address). So that means you could plug two devices together with an Ethernet cable, and it would just work, with no config, no DHCP server. |
|
| 2012-09-21 09:41:43 |
Jason Gerard DeRose |
description |
Requiring an open port accepting outside connections is a bit scary, but there's no other way to do device to device file transfer and CouchDB replication on the local network. Use the cloud (and Internet) when it helps solve the problem, but never depend on it.
And worse, right now we have two open ports (file transfer, and CouchDB). So we want to condense this into a single HTTPS server that handles file transfers, and proxies requests to CouchDB. Many things about CouchDB's design make me not thrilled about having it directly accepting outside connections, so CouchDB will only listen on 127.0.0.1.
This server will be launched via it's own executable so we can use a tightly contained AppArmor profile. It needs to talk to CouchDB, and it needs read access to files in FileStore (.dmedia/files/*/*). A few restrictions I think are prudent:
* No DBus access whatsoever... the needed CouchDB env will be passed via stdin when the server is launched
* Server will use SSL and will only accept connections from clients with certs signed by user CA or otherwise in a cert whitelist
* Server should block access to all the "fun" CouchDB paths like /_config, /_replicate, etc... we probably want to block all the /_foo paths, and some of the /dbname/_foo paths too
* Server should be smart about using limited credentials when forwarding to CouchDB... this is especially important once we can do project sharing on the local network
* Server should be smart about limiting what CouchDB paths can be accessed based on the cert the client is connecting with... again, this is especially important for localnet project sharing. For example, the users other devices need to replicate dmedia-0, but "outside" users should never have access to dmedia-0 (they should only be able to access the dmedia-0-foo and novacut-0-bar project databases).
I also want this server to use IPv6. As this is only indented for localnet use, it doesn't matter if the ISP offers IPv6 support. When there isn't an IPv6 DHCP server, Ubuntu automatically configures all networking interfaces with IPv6 link-local addresses (derived from the MAC address). So that means you could plug two devices together with an Ethernet cable, and it would just work, with no config, no DHCP server. |
Requiring an open port accepting outside connections is a bit scary, but there's no other way to do device to device file transfer and CouchDB replication on the local network. Use the cloud (and Internet) when it helps solve the problem, but never depend on it.
And worse, right now we have two open ports (file transfer, and CouchDB). So we want to condense this into a single HTTPS server that handles file transfers, and proxies requests to CouchDB. Many things about CouchDB's design make me not thrilled about having it directly accepting outside connections, so CouchDB will only listen on 127.0.0.1.
This server will be launched via it's own executable so we can use a tightly contained AppArmor profile. It needs to talk to CouchDB, and it needs read access to files in FileStore (.dmedia/files/*/*). A few restrictions I think are prudent:
* No DBus access whatsoever... the needed CouchDB env will be passed via stdin when the server is launched
* Server will use SSL and will only accept connections from clients with certs signed by user CA or otherwise in a cert whitelist
* Server should block access to all the "fun" CouchDB paths like /_config, /_replicate, etc... we probably want to block all the /_foo paths, and some of the /dbname/_foo paths too
* Server should be smart about using limited credentials when forwarding to CouchDB... this is especially important once we can do project sharing on the local network
* Server should be smart about limiting what CouchDB paths can be accessed based on the cert the client is connecting with... again, this is especially important for localnet project sharing. For example, the user's other devices need to replicate dmedia-0, but "outside" users should never have access to dmedia-0 (they should only be able to access the dmedia-0-foo and novacut-0-bar project databases).
I also want this server to use IPv6. As this is only indented for localnet use, it doesn't matter if the ISP offers IPv6 support. When there isn't an IPv6 DHCP server, Ubuntu automatically configures all networking interfaces with IPv6 link-local addresses (derived from the MAC address). So that means you could plug two devices together with an Ethernet cable, and it would just work, with no config, no DHCP server. |
|
| 2012-09-21 09:48:23 |
Jason Gerard DeRose |
description |
Requiring an open port accepting outside connections is a bit scary, but there's no other way to do device to device file transfer and CouchDB replication on the local network. Use the cloud (and Internet) when it helps solve the problem, but never depend on it.
And worse, right now we have two open ports (file transfer, and CouchDB). So we want to condense this into a single HTTPS server that handles file transfers, and proxies requests to CouchDB. Many things about CouchDB's design make me not thrilled about having it directly accepting outside connections, so CouchDB will only listen on 127.0.0.1.
This server will be launched via it's own executable so we can use a tightly contained AppArmor profile. It needs to talk to CouchDB, and it needs read access to files in FileStore (.dmedia/files/*/*). A few restrictions I think are prudent:
* No DBus access whatsoever... the needed CouchDB env will be passed via stdin when the server is launched
* Server will use SSL and will only accept connections from clients with certs signed by user CA or otherwise in a cert whitelist
* Server should block access to all the "fun" CouchDB paths like /_config, /_replicate, etc... we probably want to block all the /_foo paths, and some of the /dbname/_foo paths too
* Server should be smart about using limited credentials when forwarding to CouchDB... this is especially important once we can do project sharing on the local network
* Server should be smart about limiting what CouchDB paths can be accessed based on the cert the client is connecting with... again, this is especially important for localnet project sharing. For example, the user's other devices need to replicate dmedia-0, but "outside" users should never have access to dmedia-0 (they should only be able to access the dmedia-0-foo and novacut-0-bar project databases).
I also want this server to use IPv6. As this is only indented for localnet use, it doesn't matter if the ISP offers IPv6 support. When there isn't an IPv6 DHCP server, Ubuntu automatically configures all networking interfaces with IPv6 link-local addresses (derived from the MAC address). So that means you could plug two devices together with an Ethernet cable, and it would just work, with no config, no DHCP server. |
Requiring an open port accepting outside connections is a bit scary, but there's no other way to do device to device file transfer and CouchDB replication on the local network. Use the cloud (and Internet) when it helps solve the problem, but never depend on it.
And worse, right now we have two open ports (file transfer, and CouchDB). So we want to condense this into a single HTTPS server that handles file transfers, and proxies requests to CouchDB. Many things about CouchDB's design make me not thrilled about having it directly accepting outside connections, so CouchDB will only listen on 127.0.0.1.
This server will be launched via it's own executable so we can use a tightly contained AppArmor profile. It needs to talk to CouchDB, and it needs read access to files in FileStore (.dmedia/files/*/*). A few restrictions I think are prudent:
* No DBus access whatsoever... the needed CouchDB env will be passed via stdin when the server is launched
* Server will use SSL and will only accept connections from clients with certs signed by user CA or otherwise in a cert whitelist
* Server should block access to all the "fun" CouchDB paths like /_config, /_replicate, etc... we probably want to block all the /_foo paths, and some of the /dbname/_foo paths too
* Server should be smart about using limited credentials when forwarding to CouchDB... this is especially important once we can do project sharing on the local network
* Server should be smart about limiting what CouchDB paths can be accessed based on the cert the client is connecting with... again, this is especially important for localnet project sharing. For example, the user's other devices need to replicate dmedia-0, but "outside" users should never have access to dmedia-0 (they should only be able to access the dmedia-0-foo and novacut-0-foo project databases).
I also want this server to use IPv6. As this is only indented for localnet use, it doesn't matter if the ISP offers IPv6 support. When there isn't an IPv6 DHCP server, Ubuntu automatically configures all networking interfaces with IPv6 link-local addresses (derived from the MAC address). So that means you could plug two devices together with an Ethernet cable, and it would just work, with no config, no DHCP server. |
|
| 2012-09-26 23:36:33 |
Jason Gerard DeRose |
dmedia: status |
Triaged |
In Progress |
|
| 2012-09-26 23:36:48 |
Jason Gerard DeRose |
branch linked |
|
lp:~jderose/dmedia/peering |
|
| 2012-10-01 06:43:48 |
Jason Gerard DeRose |
summary |
Unified web server for file transfer and CouchDB proxy |
Unified web server for file transfer and CouchDB proxy [Part 1] |
|
| 2012-10-01 06:44:05 |
Jason Gerard DeRose |
summary |
Unified web server for file transfer and CouchDB proxy [Part 1] |
Unified web server for file transfer & CouchDB proxy [Part 1] |
|
| 2012-10-01 07:11:03 |
Launchpad Janitor |
branch linked |
|
lp:dmedia |
|
| 2012-10-01 07:12:29 |
Jason Gerard DeRose |
dmedia: status |
In Progress |
Fix Committed |
|
| 2012-10-09 19:45:42 |
Jason Gerard DeRose |
summary |
Unified web server for file transfer & CouchDB proxy [Part 1] |
Part 1: unified HTTPS server |
|
| 2012-10-25 02:12:00 |
Jason Gerard DeRose |
dmedia: status |
Fix Committed |
Fix Released |
|
