I'm not sure about Cabot (first time seeing it is today) but I've been designing a system that supports this type of monitoring. Shoot me an email (contact in profile) if you'd like to be contacted once it's up.
1,980 karma · joined July 22, 2012
Website: http://www.jackdb.com/
Email: sehrope [at] jackdb [dot] com
$ dig drive.google.com
; <<>> DiG 9.8.3-P1 <<>> drive.google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62437
;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;drive.google.com. IN A
;; ANSWER SECTION:
drive.google.com. 300 IN A 74.125.226.225
drive.google.com. 300 IN A 74.125.226.238
drive.google.com. 300 IN A 74.125.226.231
drive.google.com. 300 IN A 74.125.226.228
drive.google.com. 300 IN A 74.125.226.224
drive.google.com. 300 IN A 74.125.226.227
drive.google.com. 300 IN A 74.125.226.232
drive.google.com. 300 IN A 74.125.226.226
drive.google.com. 300 IN A 74.125.226.229
drive.google.com. 300 IN A 74.125.226.233
drive.google.com. 300 IN A 74.125.226.230
;; Query time: 32 msec
;; SERVER: 192.169.1.1#53(192.169.1.1)
;; WHEN: Sun Jan 12 18:37:40 2014
;; MSG SIZE rcvd: 210Having a license doesn't mean you can sue. Having a "license to sue" might though! (if it can exist)
Does it? IANAL but I believe it's possible to license the rights associated with a patent without transferring complete ownership. The shell organization would be a sub-licensee that does your dirty work.
Even better is if you can plan your infrastructure on AWS around using spot instances. They can be really cheap (we're talking a 5x times cheaper then on-demand and 3-4x than reserved). If your instances are used in a stateless fashion with all persistent state saved externally (DB, S3, etc) then you can do some pretty cheap scaling with spot instances.
One setup I've played with is a core set of non-spot instances phalanxed by a number of spot instances (at a couple different price points) for stateless web traffic. As long as the spot price stays below your bid you have significantly more instances available (which should give your users better response times). When the spot price rises your spot instances die and things slow down, but your app would still be alive thanks to the non spot instances. Again it takes quite a bit more engineering to get a setup like this but this is the kind of thing you need to do to take advantage of elastic computing.
On the security front, the SQL blacklist definitely has to go. It's a false sense of security (ex: string concat + dynamic execution gets around it). The suggestion to use a read only user is a good one but even better is to use a read only database (ex: a Postgres replication slave).
Have you checked out JackDB? (http://www.jackdb.com/ full disclosure: I'm the founder) It's a full featured database client that runs entirely in your browser.
To split out the Postgres setup and the initial schema setup, one idea might be to have a the CMD for the container run a script to automatically check for a bootstrap file on startup and run it. The bootstrap file could be specified via a volume mount. To use the container with a different dev setup (i.e. a different bootstrap SQL script) you'd simply start up the container with the shared directory pointing somewhere else.
If you want to save the Postgres data files themselves outside of the container you can again do it with volume mounts but you'll need some way to keep track of which goes where. The volume mounts are specified each time you startup the container so you need something to save those. For Dokku specifically there's the PG plugin and it looks like it does exactly this[2]. I haven't use it but I guess it validates the idea.
This seems like a general trend with Docker; it's really cool tech but it's pretty low level so you need something atop it to make usage smoother.
[1]: https://github.com/sehrope/dokku-logging-supervisord
[2]: https://github.com/Kloadut/dokku-pg-plugin/blob/master/comma...
On a more general note if anybody has backups and they aren't regularly tested restoring them, then you really don't have backups! As an added bonus, regular restoration tests let you practice for the "real deal" and you know how long the entire process will take.
With ShopSafe, each virtual card has a custom expiration of 2-12 months, a max spending limit (ex: $100), and only a single merchant can bill to it. That last feature is important as it means that even if it's leaked before the shorter expiration period nothing should be able to be charged to it. Recurring charges are possible though (ie the same initial merchant can charge you again) so you can use it for situations that require recurring billing. Either way the spending limit still applies.
Anonymity aside, I'd argue that virtual credit cards are even better than BTC from a consumer's perspective as you still have the power of charge backs. Each one has the same rights as your original card including the right to declare a purchase as fraudulent (ex: the merchant didn't ship the goods).
Would be cool if someone would create a physical version of these virtual cards that gets created on the fly for each transaction. I was hoping that Coin or one of the other "virtual physical cards" would do that but I guess that'll come later.
Another advantage of this approach is that for most legitimate charges the email comes right after you used the card when you'll remember the specific details(ie no trouble remembering lots of small purchases at the end of the month).
> Under minimum load the best page rendering time was 233ms
Regarding the node.js performance:
> Under minimum load the best page rendering time was 249ms
What the heck are they doing that takes 250ms that could possibly be app code related? That's a lot of CPU usage if its actually doing CPU-bound work. Since these are web apps that's obviously not the case. The request time is going to be mostly waiting for external resources (DB, message queue, etc).
Without knowing how much time is spent on those external requests these numbers are meaningless.
Language choice is no where near as important as your DB-access patterns (and more generally DB performance, caching, etc).
If every request you process involves serially accessing a 50-100ms external resource four or five times then it will always take 250ms (though you could increase parallelism of multiple requests if done right).
With Bitcoin you give them a brand new address that is tied to nothing.
It's definitely possible to offer a credit card transacting in bitcoin though it would have a number of technical differences. One big one is that the settlement process would need to be immediate, otherwise the transaction would be rejected. With a normal credit card transaction the funds don't actually transfer till the end of the day (if you're lucky) or the next business day (most of the time). With a bitcoin backed card it'd need to be immediate and the credit card company would need to have the bitcoin "at hand" at the time of the transaction.
If you're keen on a DIY option there are a couple out there but I wouldn't consider any of them to be as full featured as our offering and none allows for data source sharing or tracking audit trails. Also, most other tooling is specific to a single database type (MySQL, Postgres, etc) and I'm not sure which you're using (Amazon RDS supports MySQL, Postgres, SQL Server, and Oracle).
That said, here are some other options:
http://phppgadmin.sourceforge.net/
We're looking into adding both BigQuery and Google Cloud SQL integration. The latter should be out pretty soon.
As JackDB requires a direct connection to your database it works best with cloud database as a service providers (ex: Heroku Postgres or Amazon RDS). You can connect it to a local network as well (quite a few folks do!) though you'll have to setup the firewall rules to accommodate it.
> I don't understand why you would ever pay for this?
One big one is ease of use and convenience. If you're using a cloud database (Heroku Postgres, Amazon RDS, etc) then JackDB is the fastest and easiest way to start running queries. With Heroku in particular we have OAuth integration so you can list your data sources and connect in just a couple mouse clicks.
Add to that additional features like never losing your work (close the browser, reopen it, and keep scrolling your query), sharing SQL among your team, and a full audit trail of all activity and you have a product that people will (and do) pay for.
> If you need a web based database gui, what's wrong with the hundreds of free versions?
Obviously I might be a bit biased but I think JackDB is the best database GUI there is. We've been using it ourselves to develop JackDB for quite a while now (i.e. dog fooding).
> And it comes free with the non scary part of giving someone else your database access.
Security is a big deal and there is definitely a trust factor involved in using something like this (or more generally any other cloud data service). We try to be as open as possible about how we handle security and crypto on our site.
Still though, when you consider that the vast majority of people using it are already outsourcing the maintenance of their database to a cloud provider the leap of faith to using JackDB isn't as large as you think it is.
> What does 1+ user mean if not unlimited?
There's no limit to the number of Pro users that can work together with the same data sources.
> Also, row limits are not listed in the top tier, making me think that they are either unlimited, or that the go until they break due to a technical limitation somewhere after 5k rows.
Enterprise deployments can customize the row limits (default is 5K). There's no technical limit on the server side though some browsers slow down at very large limits. Using Chrome we've had no issue with 50K+ rows. It doesn't come up in real world use cases though as people dealing with more than a couple K rows usually want the data exported (which we support separately) vs just scrolling through a result set.
EDIT: I took a look at the source. There's an extra "data-" field to use as the value to sort with which is hard coded to "0" for the 2.44% row. This also answers my question of how it was sorting the textual date fields properly (each has the year in that data- field).
[1]: Pure speculation as I have neither used the site or looked at the code but I'm assuming most people will agree with me
An even more extreme example is a testing VM I setup with 5 copies of Postgres installed[1]. No mucking about locally and it's one command to spin it up. Way better than manually setting it up and so much easier to share too.
As a bonus you can put them on a local http server and your whole team can download them. Just update the URL in your Vagrantfile.
Heck even the case isn't strictly necessary. I've got a similar setup at home and for quite a while mine was hanging off the back of my TV on a short HDMI cable.
2-factor auth does not and cannot protect against offline bruteforcing, quite the contrary, it's only relevant for online authentication with a service provider.
In your example it would be for authenticating with blockchain.info so they could perform an action on your behalf. Assuming they use your actual password as a master key to unlock a wallet they store on your behalf, the 2-factor piece is just extra security they are providing for actions performed through their site. 2-factor auth does nothing to prevent someone from trying to brute force the private key or pass phrase for your wallet.
I'm all for using 2-factor auth (I personally have it enabled on every site/service that supports it) but it's only for securing online access to an external service.
This make no sense. Running Linux (or an OSS stack in general) is not what makes devices out of date. Not updating them does.
If updates are not automatic then the vast majority of people will not perform them. If they're not automatic and a pain in the ass to do (ever tried updating the firmware on a TV?) then even less will do it.
I'm not saying I want auto updates for everything (I personally don't like them though the option is nice) but for the vast majority of folks it's the right option. $NON_TECH_SAVVY_RELATIVE is not going to keep tabs on the latest exploits for her router and know when to login to the management console (assuming she can login) and apply an update.
That depends on your app size. If you're building something relatively small then having a few additional DB connections vs a dedicated MQ server can be worth it (it's really just extra shared memory for the connection). I do agree though that most folks are better off just using a real MQ server. For anything larger (both app size and app scale) it ends up being much better.
> ... the best way to use this pattern is to have a single server listening to PG notifications and publish them to a real MQ.
Another approach I've been looking at is creating a writable FDW[1] that bridges to an MQ system. That combined with a PG background worker[2] to listen for notifications gives you a transactional system that starts/stop with your database.
[1]: http://wiki.postgresql.org/wiki/Foreign_data_wrappers
[2]: http://www.postgresql.org/docs/9.3/static/bgworker.html
while (true) {
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("SELECT 1");
rs.close();
stmt.close();
org.postgresql.PGNotification notifications[] = pgconn.getNotifications();
handleNotifications(notifications);
Thread.sleep(100);
}
LISTEN/NOTIFY is very useful, particularly the transactional nature and not requiring any additional tech stack (e.g. no need for a separate MQ server), but for frequent/high-value/lower latency signalling you're better off using something that doesn't require sleeping/polling.
[1]: That and the lack of exception handling or resource cleanup.