00:00 <xpheres> thanks

00:00 <xpheres> I will look into it

00:01 <xpheres> I don't mind having a specific port for sandstorm instead of sharing one with apache, but I change sandstorm.conf configuration and it still does not start

00:02 <ocdtrekkie> Hmmm, are you getting a particular error message? Did the install perhaps fail to complete?

00:02 <xpheres> no it worked till I reinstalled apache

00:02 <xpheres> my log says:

00:02 <xpheres> *** Uncaught exception ***

00:02 <xpheres> stack: 62ffe4 62e745 62d71f 62cefc 496db7 496971

00:02 <xpheres> sandstorm/run-bundle.c++:1874: failed: bind(sockFd, reinterpret_cast<sockaddr *>(&sa), sizeof(sockaddr_in)): Address already in use

00:03 <ocdtrekkie> What ports are defined in your sandstorm.conf?

00:03 <TimMc> There are a couple of ports involved -- the local port Sandstorm listens on, and the one used in URLs.

00:03 <ocdtrekkie> Bear in mind it may be trying to bind to both 80 and 443.

00:03 <xpheres> I changed them to 81 and 444 (and more than standard ports) to see if I can have both services running

00:05 <ocdtrekkie> SMTP port isn't duplicated either?

00:05 <xpheres> the problem is that sudo sandstorm restart shows :Sandtorm is not running

00:08 <ocdtrekkie> Because there really isn't any reason Sandstorm shouldn't work if using different ports (I ran mine on nonstandard ports for years.) I think something has to be grabbing that port already,

00:10 <xpheres_> yes I don't understand either, I will keep testing and maybe restarting to see if I manage to make it work

00:17 <xpheres_> now it runs

00:17 <ocdtrekkie> Weird what'd you do? :P

00:17 <xpheres_> the base url was https://myip and that was the problem

00:17 <xpheres_> I changed it to my ip with https and now it starts

00:17 <xpheres_> without the https I mean

00:18 <ocdtrekkie> You can't use an IP as the base URL. So that's weird.

00:18 <xpheres_> yes I mean the service starts but I can't access the website

00:19 <xpheres_> I touched what I shouldn't

00:19 <ocdtrekkie> I believe your base URL and wildcard host should have your configured port though.

00:20 <ocdtrekkie> It's just really weird if changing those had any impact on the port binding error because I think those are unrelated.

00:21 <xpheres_> I don't know I've just installed it recently and I'm not a network expert, but I will manage to make it work, at least now apache and sandstorm run simultaneously

00:21 <ocdtrekkie> https://docs.sandstorm.io/en/latest/administering/config-file/ is really useful for seeing how the conf should be set up.

00:22 <ocdtrekkie> BASE_URL and WILDCARD_HOST being relatively easy ones to get wrong

00:22 <ocdtrekkie> (You'll note base includes the protocol and wildcard does not)

00:24 <xpheres_> I don't know how to set up wildcard yet but I wanted to test sandstorm on a local network and through a vpn first, not to internet yet

00:24 <xpheres_> so I don't really need a dns yet

00:24 <ocdtrekkie> You'll need wildcard DNS in order to load any apps in Sandstorm.

00:24 <xpheres_> ah I understand

00:25 <xpheres_> then I will do it tomorrow, it is late now. Thanks for all the help!

00:25 <ocdtrekkie> Apps are spawned on randomly generated subdomains so it is an unavoidable requirement.

00:26 <xpheres_> I see, even if I just use it locally I need that dns, got it

00:26 <xpheres_> will learn more and set it up tomorrow

00:26 <ocdtrekkie> Yeah. Feel free to hit us up with any more questions tomorrow or whenever. :)

00:27 <xpheres_> I will, thank you!

00:27 <xpheres_> I have to go now, bye bye!

04:02 <ocdtrekkie> So I turned on DMARC like a week ago and apparently if I participate in Google Groups I get a ton of failure notices. :|

04:09 <ocdtrekkie> I'm reading an article that claims that IF I set my DMARC to reject or quarantine instead of none, Google will automagically start rewriting emails "from" me to come from Google instead.

06:51 <ocdtrekkie> Okay, I did a Sandstorm crime.

06:51 <ocdtrekkie> github.com/ocdtrekkie/lemp-box is a bad idea and I'm totally running with it.

06:57 <ocdtrekkie> I have some small pile of apps not worth packaging that also expect low to no traffic that won't static publish well, but I want to move from my shared hosting to Sandstorm.

08:37 <Zertrin> fingers_crossed:

08:37 <Zertrin> ocdtrekkie: (re: dmarc policy) wow, thanks for pointing that out, I thought there was no way to avoid getting unaligned DMARC reports because of google group. Have googled based on your statement and indeed found recomentations to not use the non policy, but rather quarantine with a low or even 0 percentage, such that google group starts From: rewriting. Have now changed my dmarc dns record, let's see in the coming weeks wether that works :

11:15 <TimMc> ocdtrekkie: I wonder what it would take to have lemp-box's /data be backed by a davros grain...

11:51 <ocdtrekkie> TimMc: Probably both apps adding that filesystem capability Ian wrote. Though I really don't want to make the lemp-box experience good because it lacks any semblance of security.

11:52 <ocdtrekkie> Zertrin: Glad my notes on it were valuable to you! I am going to monitor it a few more days before I try ratcheting up the settings myself.

12:34 <ocdtrekkie> Alternate app name idea for lemp-box: Footgun 😂

14:19 <TimMc> Oh, what's dangerous about it?

14:20 <TimMc> Lack of separation between code and data, maybe?

14:22 <ocdtrekkie> That's a big thing to me compared to other Sandstorm apps. And I may host a couple sites using standalone domains with it, which means anyone can access it and then it's pretty much your standard PHP webhost in a box but with inability to SEO properly.

14:23 <TimMc> Search engine optimization?

14:26 <ocdtrekkie> Sandstorm iframe likely screws up search behavior.

14:27 <ocdtrekkie> But yeah, publicly exposing non-statically published PHP apps which also have a writeable code environment is pretty far from the Sandstorm ideal model.

14:30 <jonesv[m]> <ocdtrekkie> "Alternate app name idea for lemp..." <- I like the first half sentence on the repo: "This Sandstorm app is sort of a crime" 😁

14:32 <TimMc> crimeware

14:36 <TimMc> ocdtrekkie: If the executable code lived in another grain... 🤔

14:54 <ocdtrekkie> I mean it's assuming it's writeable so that doesn't help too much I think.

14:54 <ocdtrekkie> But it can probably run some PHP apps not well suited to Sandstorm.

14:54 <ocdtrekkie> I may try installing Nextcloud in it just to see what happens.

14:55 <ocdtrekkie> Even though I think actually using it for such would be a Really Bad Idea.

15:55 <isd> You'd need to do more than just get those apps to speak the file system cap stuff I wrote -- you also need to convince PHP to load code and whatnot from it, which isn't trivial since it's not a "real" filesystem. So you'd either need to copy it to the grain's own filesystem (and figure out sync) or somehow get php's filesystem access to go over capnp.

15:56 <isd> ...though if you did the latter making it read only would actually be pretty easy once you're there.

15:59 <isd> A while back, when thinking about better ways to watch for grain size changes, I mused to myself about just putting a fuse filesystem over /var so we could intercept and track writes, rather than having to deal with the mess that is inotify. I have some concerns about perf, and frankly I don't want to add that much grain-exposed non-memory-safe code. But in theory it would let us do all sorts of neat things if we controlled the underlying VFS,

15:59 <isd> including redirecting filesystem calls to some powerbox-acquired cap.

16:00 <isd> File it under "things to do when we're rich"

16:00 <isd> :P

16:01 <ocdtrekkie> PHP not speaking capnp probably limits the options there drastically re: file system. But as I said I am not planning on investing heavily in polish for this, because it seems like a bad idea in general.

16:02 <isd> Yeah, I agree don't make this a real app.

16:02 <ocdtrekkie> It's just hopefully solving a niche case where I want to retain access to some old PHP sites nobody visits anymore.

16:02 <isd> I just like to discuss the architectural implications.

16:03 <ocdtrekkie> I am torn on publishing because I feel like it would be useful enough to enough people it might help get people to shift to Sandstorm but it is also definitely not something someone should rely on for anything mildly crucial.

16:04 <ocdtrekkie> Maybe calling it Footgun will help convey the associated risks. :P

16:05 <isd> I don't know if I would want to be in a situation where we have meaningful numbers of users who are using sandstorm for this, whether or not they appreciate the implications.

16:06 <ocdtrekkie> That's relatively fair. I do think it's not actually too bad if you aren't also using standalone domains with it... which I'm gonna.

16:08 <ocdtrekkie> I could permanently store it in the Experimental market, which I do like the idea of for "things we don't necessarily support or recommend".

16:10 <TimMc> Making it hard (but possible) to do an ill-advised (but sometimes useful) thing seems like it would be the right approach.

16:11 <TimMc> . o O ( Would the name "PHP Footgun" be too redundant? )

16:13 <ocdtrekkie> I kinda like that

16:14 <ocdtrekkie> But it may also be redundant

16:39 <TimMc> Double-Barreled Footgun

18:53 <ocdtrekkie> Okay, now the default index.php of the grain explains how to use it, after a pile of warnings about not using it.

18:53 <ocdtrekkie> And it helpfully tells you what versions of PHP and MySQL it is running too.

20:18 <ocdtrekkie> I spent an hour trying to get Nginx to let me also run an app out of a different directory so I could pack in a couple management tools.

20:19 <ocdtrekkie> Nginx confs now make me sad. And I gave up for now.

20:20 <ocdtrekkie> Was hoping to maybe add permissions to a management tool and have it at /footgun-manager and keep that in the normal /opt/app directory.