MyFavMirrors
/
moonfire-nvr
mirror of https://github.com/scottlamb/moonfire-nvr.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
moonfire-nvr/db/Cargo.toml

43 lines
990 B
TOML
Raw Normal View History

initial split of database to a separate crate It should reduce compile time / memory usage to put quite a bit of the code into a separate crate. I also intend to limit visibility of some things to only within the db crate, but that's for a future change. This is the smallest move that will compile.
2018-02-21 02:15:39 -05:00
[package]
name = "moonfire-db"
version = "0.0.1"
authors = ["Scott Lamb <slamb@slamb.org>"]
readme = "../README.md"
upgrade to 2018 Rust edition This is mostly just "cargo fix --edition" + Cargo.toml changes. There's one fix for upgrading to NLL in db/writer.rs: Writer::previously_opened wouldn't build with NLL because of a double-borrow the previous borrow checker somehow didn't catch. Restructure to avoid it. I'll put elective NLL changes in a following commit.
2018-12-28 13:21:49 -05:00
edition = "2018"
initial split of database to a separate crate It should reduce compile time / memory usage to put quite a bit of the code into a separate crate. I also intend to limit visibility of some things to only within the db crate, but that's for a future change. This is the smallest move that will compile.
2018-02-21 02:15:39 -05:00
[features]
nightly = []
[lib]
path = "lib.rs"
[dependencies]
lose "extern crate" everywhere (Rust 2018 edition)
2018-12-28 22:53:29 -05:00
base = { package = "moonfire-base", path = "../base" }
update deps
2018-12-28 11:13:03 -05:00
base64 = "0.10.0"
initial db layer work for authentication (#26)
2018-11-02 02:25:06 -04:00
blake2-rfc = "0.2.18"
use cstr crate rather than unsafe This removes a few uses of unsafe, and it verifies statically that there are no interior NUL bytes.
2019-07-04 17:51:38 -04:00
cstr = "0.1.7"
initial split of database to a separate crate It should reduce compile time / memory usage to put quite a bit of the code into a separate crate. I also intend to limit visibility of some things to only within the db crate, but that's for a future change. This is the smallest move that will compile.
2018-02-21 02:15:39 -05:00
failure = "0.1.1"
fnv = "1.0"
lazy_static = "1.0"
libc = "0.2"
preliminary web support for auth (#26) Some caveats: * it doesn't record the peer IP yet, which makes it harder to verify sessions are valid. This is a little annoying to do in hyper now (see hyperium/hyper#1410). The direct peer might not be what we want right now anyway because there's no TLS support yet (see #27). In the meantime, the sane way to expose Moonfire NVR to the Internet is via a proxy server, and recording the proxy's IP is not useful. Maybe better to interpret a RFC 7239 Forwarded header (and/or the older X-Forwarded-{For,Proto} headers). * it doesn't ever use Secure (https-only) cookies, for a similar reason. It's not safe to use even with a tls proxy until this is fixed. * there's no "moonfire-nvr config" support for inspecting/invalidating sessions yet. * in debug builds, logging in is crazy slow. See libpasta/libpasta#9. Some notes: * I removed the Javascript "no-use-before-defined" lint, as some of the functions form a cycle. * Fixed #20 along the way. I needed to add support for properly returning non-OK HTTP statuses to signal unauthorized and such. * I removed the Access-Control-Allow-Origin header support, which was at odds with the "SameSite=lax" in the cookie header. The "yarn start" method for running a local proxy server accomplishes the same thing as the Access-Control-Allow-Origin support in a more secure manner.
2018-11-26 00:31:50 -05:00
libpasta = "0.1.0-rc2"
tests and fixes for Writer and Syncer * separate these out into a new file, writer.rs, as dir.rs was getting unwieldy. * extract traits for the parts of SampleFileDir and std::fs::File they needed; set up mock implementations. * move clock.rs to a new base crate to be accessible from the db crate. * add tests that exercise all the retry paths. * bugfix: account for the new recording's bytes when calculating how much to delete. * bugfix: when retrying an unlink failure in collect_garbage, we shouldn't warn about all the recordings no longer existing. Do this by retrying each step rather than the whole procedure again. * avoid double-panic scenarios, which I hit while tweaking the mocks. These are quite annoying to debug as Rust doesn't print information about either panic. I ended up using lldb to get a backtrace. Better to be cautious about what we're doing when already panicking. * give more context on raw::insert_recording errors, which I hit as well while tweaking the new tests.
2018-03-04 15:24:24 -05:00
log = "0.4"
initial split of database to a separate crate It should reduce compile time / memory usage to put quite a bit of the code into a separate crate. I also intend to limit visibility of some things to only within the db crate, but that's for a future change. This is the smallest move that will compile.
2018-02-21 02:15:39 -05:00
lru-cache = "0.1"
mylog = { git = "https://github.com/scottlamb/mylog" }
use the nix repository again nix-rust/nix#1097 is merged so it does what we need now.
2019-07-20 19:13:12 -04:00
nix = { git = "https://github.com/nix-rust/nix" }
backend support for live stream (#59) This is so far completely untested, for use by a new UI prototype. It creates a new URL endpoint which sends one video/mp4 media segment per key frame, with the dependent frames included. This means there will be about one key frame interval of latency (typically about a second). This seems hard to avoid, as mentioned in issue #59.
2019-01-21 18:58:52 -05:00
odds = { version = "0.3.1", features = ["std-vec"] }
initial split of database to a separate crate It should reduce compile time / memory usage to put quite a bit of the code into a separate crate. I also intend to limit visibility of some things to only within the db crate, but that's for a future change. This is the smallest move that will compile.
2018-02-21 02:15:39 -05:00
openssl = "0.10"
update deps The immediate motivation is that Cargo.lock referred to a commit version in a PR branch of my nix fork that no longer exists. (I didn't know, but it makes sense, that "git push -f" not only forcibly updates the branch to refer to a new commit but also gets rid of orphaned commits.) Use a moonfire branch that I'll keep stable until I'm ready to move on. I also updated parking_lot and rusqlite to new major versions (nothing in the interface that I care about has changed) and did a full cargo update.
2019-07-17 17:32:09 -04:00
parking_lot = { version = "0.9", features = [] }
schema comparison in new upgrade tests, "moonfire-nvr check" The .sql files here are copied from earlier revisions: v0.sql fee4141:src/schema.sql v1.sql 0d69f4f:src/schema.sql v3.sql 422cd2a:db/schema.sql
2019-07-11 11:07:40 -04:00
prettydiff = "0.3.1"
add concept of user/session permissions (I also considered the names "capabilities" and "scopes", but I think "permissions" is the most widely understood.) This is increasingly necessary as the web API becomes more capable. Among other things, it allows: * non-administrator users who can view but not access camera passwords or change any state * workers that update signal state based on cameras' built-in motion detection or a security system's events but don't need to view videos * control over what can be done without authenticating Currently session permissions are just copied from user permissions, but you can also imagine admin sessions vs not, as a checkbox when signing in. This would match the standard Unix workflow of using a non-administrative session most of the time. Relevant to my current signals work (#28) and to the addition of an administrative API (#35, including #66).
2019-06-19 18:17:50 -04:00
protobuf = { git = "https://github.com/stepancheg/rust-protobuf" }
upgrade a few deps
2018-08-25 01:06:14 -04:00
regex = "1.0"
update deps The immediate motivation is that Cargo.lock referred to a commit version in a PR branch of my nix fork that no longer exists. (I didn't know, but it makes sense, that "git push -f" not only forcibly updates the branch to refer to a new commit but also gets rid of orphaned commits.) Use a moonfire branch that I'll keep stable until I'm ready to move on. I also updated parking_lot and rusqlite to new major versions (nothing in the interface that I care about has changed) and did a full cargo update.
2019-07-17 17:32:09 -04:00
rusqlite = "0.19.0"
fix #64 (extraneous flushes) Now each syncer has a binary heap of the times it plans to do a flush. When one of those times arrives, it rechecks if there's something to do. Seems more straightforward than rechecking each stream's first uncommitted recording, especially with the logic to retry failed flushes every minute. Also improved the info! log for each flush to see the actual recordings being flushed for better debuggability. No new tests right now. :-( They're tricky to write. One problem is that it's hard to get the timing right: a different flush has to happen after Syncer::save's database operations and before Syncer::run calls SimulatedClocks::recv_timeout with an empty channel[*], advancing the time. I've thought of a few ways of doing this: * adding a new SyncerCommand to run something, but it's messy (have to add it from the mock of one of the actions done by the save), and Box<dyn FnOnce() + 'static> not working (see rust-lang/rust#28796) makes it especially annoying. * replacing SimulatedClocks with something more like MockClocks. Lots of boilerplate. Maybe I need to find a good general-purpose Rust mock library. (mockers sounds good but I want something that works on stable Rust.) * bypassing the Syncer::run loop, instead manually running iterations from the test. Maybe the last way is the best for now. I'm likely to try it soon. [*] actually, it's calling Receiver::recv_timeout directly; Clocks::recv_timeout is dead code now? oops.
2019-01-04 14:56:15 -05:00
smallvec = "0.6"
initial split of database to a separate crate It should reduce compile time / memory usage to put quite a bit of the code into a separate crate. I also intend to limit visibility of some things to only within the db crate, but that's for a future change. This is the smallest move that will compile.
2018-02-21 02:15:39 -05:00
tempdir = "0.3"
time = "0.1"
update all Rust deps
2018-12-01 18:20:19 -05:00
uuid = { version = "0.7", features = ["std", "v4"] }
fix #64 (extraneous flushes) Now each syncer has a binary heap of the times it plans to do a flush. When one of those times arrives, it rechecks if there's something to do. Seems more straightforward than rechecking each stream's first uncommitted recording, especially with the logic to retry failed flushes every minute. Also improved the info! log for each flush to see the actual recordings being flushed for better debuggability. No new tests right now. :-( They're tricky to write. One problem is that it's hard to get the timing right: a different flush has to happen after Syncer::save's database operations and before Syncer::run calls SimulatedClocks::recv_timeout with an empty channel[*], advancing the time. I've thought of a few ways of doing this: * adding a new SyncerCommand to run something, but it's messy (have to add it from the mock of one of the actions done by the save), and Box<dyn FnOnce() + 'static> not working (see rust-lang/rust#28796) makes it especially annoying. * replacing SimulatedClocks with something more like MockClocks. Lots of boilerplate. Maybe I need to find a good general-purpose Rust mock library. (mockers sounds good but I want something that works on stable Rust.) * bypassing the Syncer::run loop, instead manually running iterations from the test. Maybe the last way is the best for now. I'm likely to try it soon. [*] actually, it's calling Receiver::recv_timeout directly; Clocks::recv_timeout is dead code now? oops.
2019-01-04 14:56:15 -05:00
itertools = "0.8.0"
add concept of user/session permissions (I also considered the names "capabilities" and "scopes", but I think "permissions" is the most widely understood.) This is increasingly necessary as the web API becomes more capable. Among other things, it allows: * non-administrator users who can view but not access camera passwords or change any state * workers that update signal state based on cameras' built-in motion detection or a security system's events but don't need to view videos * control over what can be done without authenticating Currently session permissions are just copied from user permissions, but you can also imagine admin sessions vs not, as a checkbox when signing in. This would match the standard Unix workflow of using a non-administrative session most of the time. Relevant to my current signals work (#28) and to the addition of an administrative API (#35, including #66).
2019-06-19 18:17:50 -04:00
[build-dependencies]
protobuf-codegen-pure = { git = "https://github.com/stepancheg/rust-protobuf" }