<mnutt>
russruss sorry about all of the trouble with transmit + davros. fwiw I tested it at one point, but it's possible that an update to either sandstorm or transmit has changed something
<mnutt>
charging my phone and will do some testing on it tonight
<russruss>
mnutt: no trouble at all! I just learned about sandstorm recently so I’m still blown away by how many great ideas are in the platform
<mnutt>
transmit is the best webdav client out there so I certainly want davros to work with it
<russruss>
yeah, my guess is that when they switched sandstorm to return 200s to OPTIONS is when it stopped working
<russruss>
owncloud iOS has a major bug in the client now too, which I haven’t written up
<russruss>
it uploads the files with a x-www-form-urlencoded tag in the header
<russruss>
but it’s not urlencoded, it’s just the file
<russruss>
not sure how that works on *any* webdav serve
<russruss>
s/serve/server
<mnutt>
hmm
<mnutt>
reviewing that sandstorm change, I think it should be straightforward to return a DAV header along with the 200 to the unauthenticated OPTIONS request, hopefully that will make it happy?
<mnutt>
and asheesh, you totally told me about the feature but I mistakenly thought I didn't need the `dav` option since non-owncloud clients were already working by sending a 401. makes total sense, though
<mnutt>
asheesh: also, would it be possible to bump the app size limit just a bit? I'd like to release the davros version with libreoffice-based previews but it's right on the edge of 100MB
<mnutt>
if you all think that's the way to go. otherwise I can try a different approach or just leave it out until there's a better way to do it
<kentonv>
mnutt: I think the app size limit is 1G
<kentonv>
it's definitely more than 100MB
<mnutt>
kentonv: oh, in that case...never mind. not sure why I had that number in my head
<mnutt>
thanks!
mclasen has quit [Quit: mclasen]
tdfischer_ has quit [Remote host closed the connection]
mnutt has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
yeehi has joined #sandstorm
yeehi has quit [Ping timeout: 252 seconds]
shachaf has quit [Ping timeout: 268 seconds]
shachaf has joined #sandstorm
ftoad has quit [Remote host closed the connection]
keturn has quit [Ping timeout: 268 seconds]
ftoad has joined #sandstorm
keturn has joined #sandstorm
mclasen has joined #sandstorm
mclasen has quit [Client Quit]
Jan\ has quit [Ping timeout: 244 seconds]
pouledodue has joined #sandstorm
mclasen has joined #sandstorm
yeehi has joined #sandstorm
yeehi has quit [Remote host closed the connection]
frigginglorious has joined #sandstorm
davidar has quit [Ping timeout: 240 seconds]
M-hrjet has quit [Ping timeout: 250 seconds]
Simon[m] has quit [Ping timeout: 250 seconds]
M-hrjet has joined #sandstorm
Simon[m] has joined #sandstorm
davidar has joined #sandstorm
wolcen has joined #sandstorm
mnutt has joined #sandstorm
pie_ has joined #sandstorm
mnutt has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jemc has joined #sandstorm
aundro has quit [Quit: Leaving]
aundro has joined #sandstorm
mnutt has joined #sandstorm
tantalum has joined #sandstorm
n8a has quit [Ping timeout: 250 seconds]
yeehi has joined #sandstorm
frigginglorious has quit [Quit: frigginglorious]
n8a has joined #sandstorm
n8a has quit [Ping timeout: 245 seconds]
mnutt has quit [Read error: Connection reset by peer]
frigginglorious has joined #sandstorm
wolcen has quit [Remote host closed the connection]
wolcen has joined #sandstorm
yeehi has quit [Ping timeout: 260 seconds]
yeehi has joined #sandstorm
biotim has quit [Quit: Leaving]
Telesight has joined #sandstorm
biotim has joined #sandstorm
biotim has quit [Client Quit]
biotim has joined #sandstorm
pouledodue has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<asheesh>
Mornin', all
<asheesh>
Especially biotim, welcome! I don't know if I've chatted with you here yet!
<biotim>
thanks! mostly just watching the channel, reading up on how to build sandstorm apps
<asheesh>
: )
<asheesh>
I'm the author of a bunch of the packaging tools & docs, so feel very free to ask me things!
<biotim>
will do, thanks for the intro
Simon[m] has quit [Ping timeout: 256 seconds]
gillisig1 has quit [Ping timeout: 258 seconds]
TimePath[m] has quit [Ping timeout: 258 seconds]
M-hrjet has quit [Ping timeout: 256 seconds]
davidar has quit [Ping timeout: 256 seconds]
JonTheNiceGuy[m] has quit [Ping timeout: 258 seconds]
eternaleye has quit [Ping timeout: 258 seconds]
n8a has joined #sandstorm
M-hrjet has joined #sandstorm
JonTheNiceGuy[m] has joined #sandstorm
TimePath[m] has joined #sandstorm
davidar has joined #sandstorm
eternaleye has joined #sandstorm
Simon[m] has joined #sandstorm
gillisig1 has joined #sandstorm
Zertrin[m] has joined #sandstorm
pouledodue has joined #sandstorm
afuentes has joined #sandstorm
Telesight has quit [Quit: Leaving.]
Telesight has joined #sandstorm
yeehi has quit [Ping timeout: 256 seconds]
<eternaleye>
kentonv: Out of curiosity, do you intend to write more lets-argue posts? I really enjoyed the singletons one (and it's come in useful in fighting their use at $work)
eternaleye has quit [Changing host]
eternaleye has joined #sandstorm
<kentonv>
eternaleye: I have always intended to, but I haven't touched that site in literally over five years, so evidence suggests not. :/
<kentonv>
but we'll see
<eternaleye>
What kind of topics would you want to bring up?
<eternaleye>
Even just an idea of what you'd find worth arguing about is interesting :P
<kentonv>
oh man, so many things.
jaredbidlow has joined #sandstorm
<kentonv>
random thing that comes to mind: Exceptions, and the idea that everything can fail and programmers need to prepare for that.
<kentonv>
though the idea behind object-oriented-security.org was to focus on capability-based security I suppose
<kentonv>
(gtg, meeting)
<Lord>
is there a way to see each update/addition to the app market (rss or else) ?
asheesh has quit [Ping timeout: 258 seconds]
asheesh has joined #sandstorm
pie_ has quit [Ping timeout: 252 seconds]
funwhilelost has joined #sandstorm
funwhilelost has quit [Client Quit]
funwhilelost has joined #sandstorm
<funwhilelost>
Hey, guys. Been really doubling down on Sandstorm and experimenting with packaging. Love it so far. I just posted an issue this morning on the Github which I think is related to a permissions mistake I made a while ago. After updating to 191 this morning I get: supervisor.c++:666: failed: expected geteuid() != 0; can't run as user ID zero (root)
<funwhilelost>
Any thoughts?
biotim has quit [Remote host closed the connection]
raoulzecat has joined #sandstorm
biotim has joined #sandstorm
biotim has quit [Quit: Leaving]
biotim has joined #sandstorm
biotim has quit [Quit: Leaving]
biotim has joined #sandstorm
Telesight has quit [Quit: Leaving.]
tantalum has left #sandstorm [#sandstorm]
<kentonv>
funwhilelost: that's worrying
<funwhilelost>
(I'm still guessing it's me, with a clumsy chown)
<kentonv>
well, that failing assert is new code added last week
<kentonv>
the question is why it trips for you but not anyone else
<kentonv>
or maybe it does trip for other people too and we don't know it
<kentonv>
do you normally start your server running as root or as a regular user?
pie_ has joined #sandstorm
pie_ has quit [Read error: Connection reset by peer]
<funwhilelost>
SSH in as root, started with `su - sandstorm -c 'cd /opt/sandstorm && sandstorm restart'`
<asheesh>
cd /opt/sandstorm
<asheesh>
find -uid 0
<asheesh>
Does this show that there are files owned by UID 0?
<asheesh>
If so, then that's a ltitle unexpected for Sandstorm, although I admit we shouldn't be outright crashing :)
<asheesh>
Also hi funwhilelost ! Thanks for asking about the problem!
<funwhilelost>
Yeah, "var" is.
<asheesh>
Fascinating. Can you change it to be owned by the Sandstorm UID and see if that makes the problem go away?
<funwhilelost>
You bet.
<asheesh>
I guess UID & group ID
<funwhilelost>
It's sandstorm:sandstorm now and a restart shows the same error.
<asheesh>
Yeah, fair enough
<asheesh>
Let me try to repro on a spare machine
<funwhilelost>
Will a "start --verbose" get me more detail?
<kentonv>
the weird thing is your problem is consistent with a problem that existed in the first version of my PR, but which I then fixed
<funwhilelost>
Ah... gotcha.
<funwhilelost>
I can run whatever tools you need me to for better triage.
<kentonv>
but I can't figure out how you'd have that problem with the release version
<kentonv>
and I can't repro
<kentonv>
what's the UID of user "sandstorm"?
<funwhilelost>
999
<kentonv>
what kernel version?
<funwhilelost>
3.13.0-57-generic
pie_ has joined #sandstorm
<funwhilelost>
(Ubuntu 14.04.3)
<funwhilelost>
One other possibility: I have some odd iptables routing so that I can see sandstorm on port 80.
<funwhilelost>
I think that's the only "non-standard" thing I have going on with this box.
<kentonv>
I don't think that could affect it
<funwhilelost>
Ubuntu 14.04 has apparmor installed (I guess it replaced SELinux) but I don't know much about how it enforces policies
<funwhilelost>
Disabling apparmor and restarting made no change.
<kentonv>
yeah I don't think apparmor could be the issue. I don't understand how the code path you're hitting is possible.
<kentonv>
trying to repro
frigginglorious has quit [Ping timeout: 256 seconds]
neynah has joined #sandstorm
* zarvox
suggests strace
<funwhilelost>
zarvox: man page is making me fall asleep... can this run passively while I restart sandstorm? Example?
<funwhilelost>
I think the problem is that sandstorm is daemonized so I'm not sure what process to `strace` exactly...
<funwhilelost>
I was looking through processes just now and found some zombie sandstorms. A killall then a `sandstorm restart` got everything back in working order.
<zarvox>
Oh, touché. You can't inject strace into sandstorm's launching the supervisor.
<zarvox>
(otherwise, I would say to use strace -f, which follows fork()s)
<funwhilelost>
I was just about to run it against a live process by PID when I noticed the the zombie processes.
<funwhilelost>
There is about a 15 second delay before the assertion fails so I would've been able to attach strace before it happened... but now it's working fine. :-/
<kentonv>
I don't think strace is likely to be very helpful here
<funwhilelost>
So maybe the new "var" ownership update actually did fix it, but the zombie sandstorms were giving me a false positive.
<kentonv>
wait your server works now?
<funwhilelost>
Yeah, I ran a killall against some zombies, then started the server and now it's fine.
<funwhilelost>
Maybe something went sideways during the update/restart this morning?
<mrdomino_>
what's the status on integrating the identity powerbox into apps? i don't see it in wekan, unless i'm missing something.
<funwhilelost>
Adding logs to my Github issue.
<mrdomino_>
(depending on the amount of setup time required, i might try and do it)
mrdomino_ is now known as mrdomino
<kentonv>
mrdomino_: David was working on it and is currently on vacation
<mrdomino>
aha
<mrdomino>
ok, rad
<kentonv>
he'll be back next week. Although you might be able to discover the details by looking at his Wekan fork history
<kentonv>
I think everything is working, we just didn't release a new Wekan build yet
<kentonv>
funwhilelost: when you say "zombies" do you actually mean "processes which had exited but whose parent had not yet observed the exit status" (technical definition of "zombie") or did you mean generally "process that didn't seem like it should be running"?
<funwhilelost>
<defunct>
<kentonv>
did they have names?
<funwhilelost>
sandstorm <defunct>
<funwhilelost>
Full output of `ps -A` in Github issue.
<kentonv>
so my best guess is that somehow you got stuck with an old version of the backend process still running. But I don't know how that could happen.
<funwhilelost>
Interesting. Well hopefully I gave you enough to use in case it comes up again.
<asheesh>
I sort of had this happen to me, actually.
<funwhilelost>
The updater seemed happy and it triggered a restart. One anomaly is this: ** Shutting down due to signal \n Not killing Dev daemon because it is not running.
<asheesh>
I updated to the new version, then set the sysctl to zero, then created a new grain, hoping that this would give me the new code.
<asheesh>
But instead I got an error about not being able to reach the grain, so I explicitly restarted Sandstorm and then my problems went away.
<asheesh>
I can try to reproduce it if we really want.
<kentonv>
did you restart sandstorm after changing the sysctl?
<asheesh>
Not at first. I was hoping grain launch was when this would be checked.
<kentonv>
nope
<asheesh>
After doing that restart, I did succeed.
<asheesh>
OK!
<asheesh>
That explains what I saw then.
<funwhilelost>
I really appreciate your help, guys.
<kentonv>
the main Sandstorm process has to detect whether or not to pass root privs down through the backend process
<asheesh>
Interesting, yeah. That makes sense. I wonder if there was something else weird I saw, but if so I can't remember it any detail.
<kentonv>
funwhilelost: does /opt/sandstorm/var/log/sandstorm.log have anything funky in it?
* funwhilelost
looking through logs...
<kentonv>
funwhilelost: maybe grep for "did not terminate after"
<funwhilelost>
Nothing like that.
[d__d] has quit [Remote host closed the connection]
<funwhilelost>
Just the supervisor assertion and the rpc exception (after each attempt to load a grain)
<kentonv>
well, I give up, I guess.
[d__d] has joined #sandstorm
<funwhilelost>
I went back to root owning "var" just to make sure I couldn't repro. It didn't make any difference.
<funwhilelost>
If you get another similar report and want me to verify anything on my server to compare, feel free to reach out.