Comment by safeaim
5 years ago
Am I the only one having issues trying to get this working? The webserver starts just fine, but once I add the index.html with zip as in the example, it stops working. This is on Mac 10.15, CentOS 8 and Ubuntu 18.04 LTS.
Centos: [centos@test ~]$ ./redbean.com -vv
error: Uncaught SIGSEGV on test.novalocal
./redbean.com
EINVAL/err=22/errno:2/GetLastError:0
Linux test.novalocal 4.18.0-240.10.1.el8_3.x86_64 #1 SMP
Mon Jan 18 17:05:51 UTC 2021
On the mac: ~ my-Maccie$./redbean.com -vv Killed: 9
On Ubuntu: ubuntu@localhost:~$ ./redbean.com -vv
error: Uncaught SIGSEGV on localhost
./redbean.com
EINVAL/err=22/errno:2/GetLastError:0
Linux localhost 4.15.0-136-generic #140-Ubuntu SMP Thu Jan
28 05:20:47 UTC 2021
IIRC, from vague memories of things flying past, Big Sur won't let a modified binary run once it's been checked by Gatekeeper. Which means the first run gets checked and notarised but when you add the `index.html`, the on-disk binary has changed and Gatekeeper won't allow it to run - I guess it's to prevent malicious code modifications, etc.
It looks like you can get around this by adding Terminal.app as a "developer tool" (i.e. it can create processes without hitting Gatekeeper), maybe that works? (once I did that and relaunched terminal, I can run cosmopolitan binaries).
https://docwhat.org/upgrading-to-catalina
Oh wow that's good to know. Maybe you have to do something like `cat foo.com >foo2.com` after you've modified it with the zip tool.
Thank goodness AAPL is here to protect us from doing cool stuff.
Its good from a security perspective, but also its a nightmare to know that the mothership knows everything you run on your machine.
This will also prevent distribution from outside of their appstore giving it will prevent updates.
So as anything Apple, the world security here is being used as code for personal machines remotely controlled by the mothership.
You trade privacy and freedoms for a little convenience.
> This will also prevent distribution from outside of their appstore giving it will prevent updates.
I think that if an app is correctly codesigned, Gatekeeper has no issue with it. Also if it's not correctly codesigned but you've ticked "allow unsigned binaries", you can still run them.
> the mothership knows everything you run on your machine
I can't remember the details from the last time this came up but IIRC it only sends a hash and possibly even then only the first time you launch it. Either way, they're not going to block out-of-appstore distribution except if you're a known malicious actor.
Yeah, but this isn't Big Sur, it's Catalina. But maybe it's the same protection there as well?
The binary didn't work on Ubuntu 18.04 nor CentOS8 either, but I'll report a issue later on today.
What happens if you switch off Gatekeeper?
`sudo spctl --master-disable`
Author here. It works fine on RHEL5 / CentOs5 for me. I can also confirm RHEL7. Please file an issue. What will help in particular is if you can give me the faulting RIP address. That should be in the crash report or in your dmesg log.
Same here on MacOS Catalina 10.15.7. The original invocation runs fine
Visiting http://127.0.0.1:8080/ in my web browser shows a nice redbean page with lobster graphic at http://127.0.0.1:8080/tool/net/redbean.html but then following usage instructions in another shell:
I blame my zip
Addition of index.html shrinks(!) redbean.com from size 204800 to size 204348, with changes starting from char 172938. That clearly corrupts the portable executable format.
Yup, I get "Killed: 9" on macOS (Big Sur) too. I actually had some kind of problem (I think) with the original invocation:
On Mac Big Sur it doesn't seem to work either:
W--------------------000028:tool/net/redbean.c:1145:redbean:56779] setsockopt(server, IPPROTO_TCP, TCP_QUICKACK, &yes, sizeof(yes)) → ENOPROTOOPT/err=42/errno:42/GetLastError:0 V--------------------000023:tool/net/redbean.c:1166:redbean:56779] 0.0.0.0:8080 listen ^CV2021-02-26T12:12:27.012972:tool/net/redbean.c:1183:redbean:56779] 0.0.0.0:8080 terminated
EDIT: I am an idiot: it's working just fine... the messages looked like an error to me, but visiting https://localhost:8080/ does show a nice HTML page!
No, I have the same issue on Linux Mint 20.1
No luck for me on win10. I can open the archive but get errors trying to add to it. 7zip and win explorer zip both fail with either unsupported or corrupted archive errors.
Since it's a .com file, after downloading, win 10 also claims 'this dangerous file comes from the internet and is blocked' which you have to check a box to unblock it. I did, but still get the errors trying to add to it.
Fixed for me (macOS) in this[1] commit.
[1] https://github.com/jart/cosmopolitan/commit/218ef491476f15ab...
Someone already reported the same https://github.com/jart/cosmopolitan/issues/56
Yeah another killed: 9 on Mac BigSur. Could you export the tool in a way that we don't have to zip new files into it? Instead we would have to gcc the whole thing once and be done with it.
Disable Gatekeeper:
After adding a new file with WinRAR, I get:
EINVAL/err=87/errno:2/GetLastError:203 The parameter is incorrect.
Probably the ZIP needs to be saved in a certain format.
Author here. The zip shouldn't need to be saved in any special format. If WinRAR is posing problems then please file an issue because I'd like to fix that. That error doesn't seem like something that would indicate executable corruption. I want to learn more.
Have to say though, using zip so you can reuse the compression is quite a masterstroke.
I tried to add a file using Windows file explorer, but it just complains "The Compressed (zipped) Folder is invalid or corrupted."
This is on Windows 10 19042 build.
7-Zip doesn't even see the folders for that matter.
IDK if this is enough
https://pastebin.com/8RyPWQFf
Sure thing, will provide as much info as possible.