[HN Gopher] Rsync.net Technical Notes - Q4 2021
___________________________________________________________________
Rsync.net Technical Notes - Q4 2021
Author : rsync
Score : 56 points
Date : 2022-03-07 18:44 UTC (4 hours ago)
(HTM) web link (www.rsync.net)
(TXT) w3m dump (www.rsync.net)
| cjbconnor wrote:
| The link isn't working for me.
| [deleted]
| ireflect wrote:
| Not technical per se, but I'm interested to know how the
| "unlimited plan for life" experiment worked out. Did many folks
| take you up on the offer? I didn't, but I strongly considered it
| (if I'm being honest I just procrastinated the decision until I
| realized the deadline had passed).
| rsync wrote:
| Shhh ... :)
|
| It was, indeed, a _very limited_ test promotion to some small
| subset of customers and I am still undecided on whether it
| makes sense to pursue or not.
|
| Generally speaking, I dislike "lifetime" offers and there is
| some bad history with those being badly abused - specifically
| by cloud providers. Was it Joyent that dishonored the
| strongspace lifetime offers ?
|
| I forget ...
| reaperducer wrote:
| _Generally speaking, I dislike "lifetime" offers and there is
| some bad history with those being badly abused_
|
| Back when Sirius Satellite Radio started, it offered
| "lifetime" subscriptions. People eventually learned that
| Sirius meant the lifetime of the radio as long as it tied to
| the purchaser's account, not the human being.
|
| Many people got Sirius with their new cars. When they started
| trading them in three or four years later, they learned that
| their "lifetime" subscription not only didn't go with them to
| their new car, but the buyer of their old car also didn't get
| the old subscription.
|
| Today, it wouldn't be as big a deal because you can stream
| Sirius ($10/month), or some other radio service over the
| internet. But this was back before even RealPlayer, and the
| mass adoption of cell phones.
| mattl wrote:
| Sirius was early 2000s. RealPlayer was 5+ years before
| that?
| rsync wrote:
| I remember this.
|
| This is why we're hesitant - the bad behavior in this area
| of pricing and promotion makes any offer like this seem
| scammy ...
| cvwright wrote:
| I think Tivo did a similar thing too, back in the day. (I
| wasn't a Tivo customer but I had friends who were.)
|
| Sadly, these things never seem to end well.
| secabeen wrote:
| Honestly, when I'm buying backups, I want to be a paying
| customer; that aligns my providers incentives with mine.
| Being a will-never-pay-again customer means that they
| want to minimize the costs of serving me, and are happy
| to see me go. No thanks.
| selykg wrote:
| Yes, Joyent was the one that totally screwed the pooch on
| that.
|
| I had a few lifetime plans with them. One was with TextDrive,
| before the Joyent acquisition/merger and that was their
| shared hosting plan back when they were doing everything on
| FreeBSD. Then after the merger they did a sort of pre-VPS
| type plan where it was using Solaris Containers. Those were
| really cool little boxes.
|
| I also had one of their Strongspace lifetime plans, and that
| still exists as Expandrive bought them and continues offering
| the lifetime plans.
|
| Edit: oh, and for how it was ended, Joyent was purchased by
| Samsung (I think it was) and to get the lifetime stuff off
| the books they basically forced everyone onto their VPS-like
| solution but only for ~2 years I think it was. So everything
| disappeared.
| amock wrote:
| I haven't forgotten how Joyent treated the customer who had
| lifetime offers and I'll never do business with Joyent again.
| rsync wrote:
| Happy, as always, to answer any questions or discuss any comments
| here.
|
| Thanks again to Allan Jude of Klara Systems and Luke Young of
| bored.engineer for their very interesting comments and
| explanations.
|
| (these tech notes were published in March of 2022 - they are
| backward looking to the events of Q4 2021)
| tempnow987 wrote:
| Site loading a bit lumpily for me for a minute there.
|
| Otherwise interesting write-up and pruning unused features I do
| think helps with security generally.
| pokstad wrote:
| Any news on adding the mkfifo command? I requested it a while
| back and it sounded like it was doable but I have not heard any
| updates.
| rsync wrote:
| Thanks! mkfifo was included in this new command
| addition/whitelisting and we're going to write up an entire
| section on it next quarter.
|
| Can you email ? I actually searched for our conversation for
| a while and could not find it ... bottom line is that
| 'mkfifo' is in place and I can't wait to craft up some
| fascinating remote ssh examples with it ...
| pokstad wrote:
| Bumped our email thread, thanks!
|
| For everyone else, the mkfifo command lets you transfer
| arbitrary streams of data between two systems while using
| rsync.net as an intermediary.
| dividuum wrote:
| I'm slightly confused on why that would be useful within
| the rsync.net context. Is bouncing traffic a new intended
| use case?
| pokstad wrote:
| The big use case my colleague came up with was
| transferring a blob of information between two machines
| without exposing ports on either machine.
| liberix wrote:
| Hi, the rsync.net website seems to be offline right now. Is
| there any other link where we can find the technical notes?
| EvanAnderson wrote:
| I had trouble loading it, too, but managed to get an
| archive.is capture: https://archive.ph/YEzR5
| mattl wrote:
| I can't get archive.ph to load but rsync.net loads fine...
| rsync wrote:
| site never went down but was perhaps slow for a brief moment
| ... try again, please ...
| anarcat wrote:
| it's still sluggish at the time of writing, FWIW.
| benlivengood wrote:
| Is native encryption available on the send-capable accounts?
| rsync wrote:
| Yes. ZFS encryption and raw send.
| anderspitman wrote:
| > and there is your arbitrary python code execution - which is
| exactly what we don't want.
|
| The state of userspace sandboxing across all operating systems
| I'm aware of is dismal. As a developer it should be trivial to
| spawn a process with a subset of the privileges of the parent
| process.
|
| Linux is better than most in terms of options, but you have to
| understand seccomp, namespaces, cgroups, containers,
| capabilities, etc etc. It's too confusing. Why can't I just say
| "spawn this process, limit it to reading files in this directory,
| writing files in this directory, this socket, max 10GB disk
| space, max 5% CPU, max 10% memory"? I'd even settle for just
| being able to limit filesystem and network access.
|
| Even if you do manage to make it work, since the APIs require
| SETUID executables you might actually be opening yourself up to a
| bigger risk.
|
| Someone needs to pull a WireGuard and make a small, simple API
| for userspace sandboxing. And please somehow miraculously make it
| so it is likely to be implemented by Windows.
| dogleash wrote:
| > Someone
|
| Why not you?
| anderspitman wrote:
| Because I'm not a security expert. Gaining the knowledge
| necessary to do it well would probably require a
| specialization change and years of prep, which would be an
| inefficient division of labor. Plus, it's an interesting
| problem, but not one I'm particularly drawn to. I'm currently
| focused on solving other problems[0] higher up the stack.
|
| [0]: https://boringproxy.io/
| stephenr wrote:
| I don't know for sure about the memory and cpu rationing but
| doesn't systemd expose the rest of those limits for service
| units?
| anderspitman wrote:
| Not sure. Even if it does, it's going to be built using the
| APIs I already mentioned, and therefore not available in
| userspace. It doesn't make any sense for a process to need
| special privileges in order to limit a child process to
| _strictly lesser_ privileges.
| lechner wrote:
| Your technical notes really illustrate that there is a science to
| running good backups. Thanks so much!
___________________________________________________________________
(page generated 2022-03-07 23:01 UTC)