<ocdtrekkie>
RHEL/CentOS/etc. is what I want to use, because I'm also particularly comfortable with cPanel (RHEL/CentOS only).
<ocdtrekkie>
But unfortunately it's going to be a long time before that and Sandstorm could coexist on one server.
<zarvox>
dwrensha: sorry, I was ignoring IRC all day. Answer is "no, not right now" but I'd love it if someone would write a patchset that would make the VM name involve dirname(dirname(abspath(Vagrantfile)))
simonv3 has joined #sandstorm
ak5 has joined #sandstorm
<ak5>
hey guys I am trying to figure out how to give wordpress external network access to be able to install plugins
sunu has quit [Ping timeout: 256 seconds]
<kentonv>
ak5: Unfortunately, right now, you can't. Some plugins work if you upload them as zips.
<kentonv>
basically we want network access to be explicitly approved by the user, but we're still working on that UI
jadewang has joined #sandstorm
<ak5>
kentonv: read the blog posts, I am following you guys :D
<ak5>
kentonv: was just wondering if it worked with the temporary replacement ui
pixelport has joined #sandstorm
sapienTech has joined #sandstorm
joshbuddy has quit [Quit: joshbuddy]
sapienTech1 has joined #sandstorm
sapienTech2 has joined #sandstorm
sapienTech has quit [Ping timeout: 255 seconds]
<sapienTech2>
heads up for the developer in charge of groove basin, volume doesn't come through my Nexus 6 phone using any of the standard browsers
sapienTech1 has quit [Ping timeout: 256 seconds]
pixelport has quit [Quit: Leaving]
todayman has joined #sandstorm
todayman has quit [Ping timeout: 250 seconds]
todayman has joined #sandstorm
<ak5>
any way I can setup a mirror in china for the apps?
jadewang has quit [Ping timeout: 244 seconds]
gopar has quit [Remote host closed the connection]
jadewang has joined #sandstorm
neynah has joined #sandstorm
<kentonv>
ak5: hmm, what for?
<kentonv>
ak5: The app list is pretty simple. The install button just redirects people back to their server with the path /install/<package-id>?url=<download-url>
<kentonv>
so you can pretty easily host your own app list
todayman has quit [Ping timeout: 250 seconds]
joshbuddy has joined #sandstorm
jadewang has quit [Remote host closed the connection]
simonv3 has quit [Quit: Connection closed for inactivity]
joshbuddy has quit [Quit: joshbuddy]
sapienTech2 has quit [Quit: Leaving.]
<ak5>
ah I hadn't looked into it at all - its just the app installs fail here quite miserably 80% of the time in china (beijing)
<ak5>
without a proxy or something (which I have) but others probably not - most users that breach GFW use non foss vpn clients from paid providers and wouldn't know how to connect to them with linux (and probably we don't want them to do that anyway)
<dwrensha>
"Failed to mount folders in Linux guest. This is usually because the "vboxsf" file system is not available."
<dwrensha>
Is anyone out there running a Sandstorm instance on a Linux kernel newer than version 4.0.0? If so, maybe you can help me gather data to trace down a bug.
mnutt_ has quit [Quit: mnutt_]
sunu has joined #sandstorm
natea has quit [Quit: natea]
<dwrensha>
i,i EXT2_SUPER_MAGIC
<paulproteus>
dwrensha: I can't super-duper support Fedora over Debian in vagrant-spk, just since I don't use it, but in theory you should have enough tools to make it work.
<paulproteus>
vboxsf thing is usually due to needing to install "VirtualBox Guest Additions".
<dwrensha>
I didn't need to install additions for the debain/jessie64 box to work
<dwrensha>
meh, anyway, I've found a different debugging route
<paulproteus>
Yeah, the additions are bundled into debian/jessie64.
<paulproteus>
It's on the guest side, fwiw, that it needs to be installed
<dwrensha>
I'm tracking down a problem where an app behaves differently on different Sandstorms!
<paulproteus>
Oh my!
<dwrensha>
On any Debian/Ubuntu Sandstorm install, it works as expected
<dwrensha>
on my Arch Linux Linode install, Mongo eats tons of disk space
<paulproteus>
zomg.
<dwrensha>
I suspect this is Mongo's fault somehow
<dwrensha>
Looks like the Arch Mongo package outside of the Sandbox has the same problem, so I'm poking at that
<paulproteus>
"That's a relief"
<dwrensha>
yeah, but still. The same SPK has quite different behavior on different Sandstorms
<dwrensha>
that's a problem
<paulproteus>
Agreed, definitely a problem.
<dwrensha>
one theory is that Mongo somehow checks the kernel version and does different things in different cases
<dwrensha>
anyway, I'm examining strace output
<paulproteus>
My first reaction is: omg patch out that syscall
<paulproteus>
"We are Linux 1.0, screw you those who want to know more"
<dwrensha>
hm. I'm going to try booting my Linode at a different Linux version.
natea has joined #sandstorm
<dwrensha>
pre 4.0
<dwrensha>
OK, doesn't seem to be the kernel version. I still see the wrong behavior on 3.16.7
<dwrensha>
Even though my Ubuntu box with 3.19.0 produces the correct behavior
mnutt_ has joined #sandstorm
<dwrensha>
hm... perhaps this is a filesystem issue?
<dwrensha>
The Arch box uses ext3
<dwrensha>
the Debian/Ubuntu boxes use ext4
natea has quit [Ping timeout: 260 seconds]
natea_ has joined #sandstorm
<dwrensha>
so it looks like in all cases, if I shell into the grain storage and `ls -sh` the Mongo journal files, they appear to be 200MB
<paulproteus>
ls != du
<dwrensha>
but on the ext4 systems, the grain size bar in Sandstorm reports more like 100kb, and indeed that's the size of the uncompressed zip if I download a backup
<dwrensha>
on the ext3 box, the grain size bar reports 200MB, and the the uncompressed zip is 200MB
<dwrensha>
these files are sparse
<dwrensha>
like, I think they are initiated by writing a single "0" byte every 4k or so
<dwrensha>
`du` and `ls -s` are agreeing
<paulproteus>
TIL ls -s !
<dwrensha>
ughh what filesystem black magic is happening here
mnutt_ has quit [Quit: mnutt_]
<dwrensha>
the grain size on the topbar is measured using lstat()
<dwrensha>
and if I use stat from a shell, I get an answer that agrees with it
<dwrensha>
but why would that disagree with `du`?
<dwrensha>
So it looks like Mongo is relying on the filesystem to do sparse file optimization
todayman has joined #sandstorm
todayman has quit [Ping timeout: 264 seconds]
todayman has joined #sandstorm
<dwrensha>
It looks like the right workaround is for me to call mongod with --nojournal
<dwrensha>
if I download a zip and unzip it on my mac, the size agrees with the stat() size, i.e. it differs a lot between whether the grain was on my Arch box or an Debian/Ubuntu box
<kentonv>
so the uncompressed zip is much larger than the topbar size?
<dwrensha>
yes
<kentonv>
when you say the stat() size, that's ambiguous, because stat() reports both the apparent size and the actual space used
<dwrensha>
st_size
<kentonv>
but the topbar measures st_size
<dwrensha>
right
<dwrensha>
st_size = apparent size
<kentonv>
but you said the apparent size is consistent and the actual space used differs?
<kentonv>
between machines
<dwrensha>
no
<dwrensha>
apparent size differs
<dwrensha>
actual space used looks the same
neynah has joined #sandstorm
<dwrensha>
except for uncompressed backup zips
neynah has left #sandstorm [#sandstorm]
<kentonv>
haha, ok, apparently at 10:19 you said one thing, and at 10:20 I repeated back _exactly the opposite_, and then you said "that's right".
<kentonv>
I am not sure how I managed to read exactly the opposite of what you clearly said
<kentonv>
ok, starting over
<kentonv>
no no
<kentonv>
ok I'm really confusing myself
<kentonv>
at 10:19 you were talking about what you'd expect sparse files to look like
<kentonv>
but that's *not* what you're seeing
<dwrensha>
I am seeing superdense files, I guess
<kentonv>
let's try to make this really clear because clearly I'm getting really confused
<kentonv>
so on ext4
<kentonv>
you see consistent st_size and st_blocks
<kentonv>
and both are small
<kentonv>
on ext3 you see small st_size but large st_blocks?
<dwrensha>
no. On ext4 they are inconsistent, and st_size is small
<dwrensha>
On ext3 they are consistent and both large
<dwrensha>
My Arch box is Ext3
<kentonv>
ohhh... hmm...
<kentonv>
cool, now I have a local file to poke at
<kentonv>
so they try to call fallocate() to pre-allocate a ton of space
<kentonv>
the log you gave me was ext3?
<dwrensha>
yes
<kentonv>
the fallocate() fails there because the fs doesn't support it
<kentonv>
on ext4 I guess it would have allocated a ton of hidden space
<dwrensha>
"hidden"?
<kentonv>
it pre-allocates pages for the file to grow without advancing the file size.
<kentonv>
the file size is just a number stored in the metadata, completely independent of the table of allocated pages
<kentonv>
in fact any file block table is valid with any file size -- missing blocks are assumed to contain zeros, and blocks past the end of the file are pre-allocated space (also zero)
<kentonv>
does --nopreallocj help with this?
<dwrensha>
I'm trying that now
<dwrensha>
it doesn't seem to change the size of the journal
<kentonv>
so it still preallocates even though you told it not to?
<dwrensha>
yeah
<kentonv>
I'm tempted to have seccomp silently ignore fallocate
<dwrensha>
so that st_size is less of a lie?
<kentonv>
it will prevent apps from being able to allocate pages beyond st_size, yeah
<kentonv>
only visible effect should be st_blocks doesn't grow when they expect it
<kentonv>
fwiw blackrock will already effectively ignore fallocate at a lower level.
<kentonv>
hmm
<kentonv>
there's a config option called "log.file_max"
<kentonv>
which if I'm reading the source correctly appears to control this
<kentonv>
I don't know where these config options come from
<ocdtrekkie>
I can upload/install to Alpha, but Oasis fails.
<ocdtrekkie>
To do either.,
<dwrensha>
ocdtrekkie: are you trying spks from the new app store?
<ocdtrekkie>
Yes
<dwrensha>
I think there are some issues with that
<dwrensha>
regarding metadata
<ocdtrekkie>
I also tried installing by URL to Oasis.
<ocdtrekkie>
From the new app store.
<ocdtrekkie>
And that didn't work either.
<dwrensha>
the metadata is part of the spk
<dwrensha>
and Oasis has an old incompatible schema, I think
<kentonv>
ocdtrekkie: yeah the problem is Oasis hasn't been updated lately
<kentonv>
and it doesn't understand some of the recent metadata changes
<ocdtrekkie>
Ahhhhhh
<kentonv>
so apps from apps.sandstorm.io don't work
<kentonv>
Feel free to try on testrock, though. :)
<ocdtrekkie>
I have Alpha (where most of my stuff is), I just thought it was odd.
<ocdtrekkie>
Nonetheless, congrats on an awesome launch of a thing!
<kentonv>
to be clear, it's not actually launched yet. It's up so that we can populate it for launch. :)
<ocdtrekkie>
Well, I finally have my Internets again, so I'll be able to work on getting my ports updated.
xcombelle has quit [Read error: Connection reset by peer]
jadewang has quit [Remote host closed the connection]
simonv3 has quit [Quit: Connection closed for inactivity]
<PMT>
oh good, jadewang already plugged hackpad
<ocdtrekkie>
There isn't a good category for either Meteor Blocks or EtherDraw right now.
<ocdtrekkie>
That I can see in the definition.
<ocdtrekkie>
What do you recommend?
jadewang has joined #sandstorm
<ocdtrekkie>
kentonv: Was meteor-spk ever released with the 'meteor build' fix, and will I currently be able to publish a meteor-spk app to the new app store?
<ocdtrekkie>
Also: getting from "I have a keybase" to "the right stuff is in my package folder" would be really helpful information for the publishing guide.
<ocdtrekkie>
Because I think I am probably done with my first port except for figuring out how to set up all the signing stuff.
<ocdtrekkie>
And knowing what category to put it in.
jadewang has quit [Remote host closed the connection]
NOTevil has quit [Quit: Leaving]
<kentonv>
ocdtrekkie: I think there was a release, yes, but hard to remember.
<ocdtrekkie>
I don't see one in dl.sandstorm.io with a newer date than the PR.
<kentonv>
hmm
<ocdtrekkie>
Also, keybase setup makes me sad, I'm getting errors about gnupg config files being missing. Specifically, a /.gnupg folder.
<kentonv>
it looks like there was never a release including the bug in the first place. (Using "meteor bundle" still works, it just complains about being deprecated.)
<ocdtrekkie>
Yeah, it just complains, but it seemed weird it never got released. Will meteor-spk need an update for the publishing flow? Or will it 'just work'?
<kentonv>
it will just work since it wraps spk
<kentonv>
I mean, it wraps whanever version of spk you have
<kentonv>
when it comes time to publish, use "spk publish", not "meteor-spk publish"
<kentonv>
regarding keybase issues, is that when following Keybase's instructions or specifically when trying to follow Sandstorm's GPG instructions?
<ocdtrekkie>
I used Keybase's instructions to install keybase.
<ocdtrekkie>
Any attempt to execute like... keybase id ocdtrekkie or something like that, gives me the gnupg error.
<ocdtrekkie>
Where is Sandstorm's GPG instructions?
<kentonv>
in package.capnp
<kentonv>
but if the keybase command doesn't work on its own then Sandstorm's instructions probably aren't going to work either.
<kentonv>
are you running keybase directly on Windows? I wonder how much they've tested that.
<ocdtrekkie>
This is all Ubuntu.
<kentonv>
huh
<ocdtrekkie>
Error message PM'd.
jadewang has joined #sandstorm
neynah has joined #sandstorm
bb010g has quit [Quit: Connection closed for inactivity]
<neynah>
I hope that is not sarcasm! It needs tweaking.
<paulproteus>
It looks super duper good to me.
<ocdtrekkie>
I want to login! :(
<ocdtrekkie>
I submitted my first app though. :D
<ocdtrekkie>
I've just been, you know, making problems for kentonv.
<paulproteus>
bd
<neynah>
ocdtrekkie: yay! which one?
<ocdtrekkie>
So far, Meteor Blocks.
<ocdtrekkie>
Mostly because it was the most straightforward. No upstream changes besides updating Meteor.
<paulproteus>
i,i Meatier
<kentonv>
so I'm thinking it's definitely weird to show the upstream author name on the app tiles. Makes it look like they directly submitted it. So I guess I'm going to change it to show the port-er there and list upstream author as a metadata field.
simonv3 has joined #sandstorm
<paulproteus>
BTW apparently there's healthy enthusiasm for storm.debian.net in #debconf on irc.oftc.net.
<kentonv>
but I wonder if that's also going to look weird
<kentonv>
yay!
<paulproteus>
I might "have to" implement support for sso.debian.org.
<paulproteus>
Enthusiasm _and_ skepticism. The best combination.
<kentonv>
neynah: Yeah something like that.
<kentonv>
though I kind of feel like highlighting either name is wrong somehow...
<kentonv>
unless they're the same
<neynah>
kentonv : what do you mean by highlighting? as in the colour?
<kentonv>
I just mean displayed prominently
<kentonv>
displaying the porter prominently feels like they are taking credit for upstream's work. Displaying upstream prominently feels like we've giving them responsibility for a port that they didn't necessarily approve.
<ocdtrekkie>
Should I gitignore .meteor-spk?
<paulproteus>
I don't remember what lives in there!
<paulproteus>
Probably not, though, but I don't remember what lives in there.
<ocdtrekkie>
Almost everything I would expect in .meteor that isn't in .meteor.
<ocdtrekkie>
All of the stuff it downloaded based on the list of packages.
<paulproteus>
Well I have no opinion for now; too tired here in .de
<ocdtrekkie>
All the node modules and everything end up in .meteor-spk
<ocdtrekkie>
Which is weird, because I thought they were supposed to be in .meteor.
<kentonv>
ocdtrekkie: IIRC the meteor bundle is built in .meteor-spk
<kentonv>
so that's the output of bundling your app
<ocdtrekkie>
But I mean, you generally leave out all of that in the source repo.
<ocdtrekkie>
Because when you meteor-spk, it recreates it.
<kentonv>
right
<kentonv>
IIRC, you should gitignore it, but I don't remember 100%