Live data from Hacker News

Introducing Pow, a zero-configuration Rack server for Mac OS X

pow.cx

121–130 of 146 posts

Re: Introducing Pow, a zero-configuration Rack server for Mac OS X

#121
post #6

This is a great web page, but I think it's borderline irresponsible to keep using this gimmick: curl get.pow.cx | sh for installation. Yes, it's easy and slick. Yes, you'd have to read the code itself to make sure Pow didn't own your machine up after a secure install. Yes, you can just read the shell script. But 0.0001% of people playing with Pow will do that. Why make things easier for attackers at all? This is an i…

Let's cut to the chase. OP is right. cUrl is a shitty way to install software. All these other arguments are peripheral to the central issue, which is simply that cUrl is a shitty way to install software. Reasons have already been given, arguments have already been made, and no difference has been made.

cUrl is a shitty way to install software.

Re: Introducing Pow, a zero-configuration Rack server for Mac OS X

#122

Maybe it's just me but I can not seem to get any application to work. Chrome just says "Server Not Found". I tried to check the logs in ~/Library/Logs/Pow but the directory doesn't even exist. Didn't know if it was something silly before I created a ticket on Github.

yep, same thing here. I get this if I launch it manually on 10.6.7: launchctl load "$HOME/Library/LaunchAgents/cx.pow.powd.plist" Bug: launchctl.c:2325 (23930):13: (dbfd = open(g_job_overrides_db_path, O_RDONLY | O_EXLOCK | O_CREAT, S_IRUSR | S_IWUSR)) != -1 launch_msg(): Socket is not connected

When I ran this, I got the following error: "launchctl: Dubious permissions on file (skipping)"

The file was chmodded to 664; changing it to 644 did the trick.

Re: Introducing Pow, a zero-configuration Rack server for Mac OS X

#124

What the hell it's written in node.js and coffeescript. Color me impressed. I'm now motivated to tackle this for python.

Indeed, that would be awesome if we could have the same kind of zero-conf, instant-deploy-via-symlink for wsgi/python apps.

Re: Introducing Pow, a zero-configuration Rack server for Mac OS X

#125
post #55

How much of this is OSX specific since it's a node.js app? Other than the launchctl and plist stuff could this be ported to linux?

The majority of the OS X -specific aspects have to do with how it launches (launchd .plist files) and how it automagically resolves .dev domains (using /etc/resolver - see: http://developer.apple.com/library/mac/#documentation/Darwin... )

Substituting launchd is easily done with any process launcher of your choice. As for the .dev TLD trick - that's a little harder, as OS X 10.6 has support for flat files inside /etc/resolver/* which the name of the file indicates what configuration/settings to use when resolving that domain. As such, they just drop a file named 'dev' in there and tell it to look to localhost on a custom port for DNS resolution. Then they run a mini DNS server on that port to resolve .dev domains to localhost.

Probably the only way to do something similar to this for linux would be to run a name server of your own on your box and add a custom zone configuration for the .dev TLD and recursive lookup for anything else.

Re: Introducing Pow, a zero-configuration Rack server for Mac OS X

#126
post #18
post #6

This is a great web page, but I think it's borderline irresponsible to keep using this gimmick: curl get.pow.cx | sh for installation. Yes, it's easy and slick. Yes, you'd have to read the code itself to make sure Pow didn't own your machine up after a secure install. Yes, you can just read the shell script. But 0.0001% of people playing with Pow will do that. Why make things easier for attackers at all? This is an i…

Well, just to play devil's advocate, do you read through the source code of MySQL, Apache, or RPM packages every time you install them? With things like this that come from reputable sources, it's not unreasonable to put some trust in the source and some trust in the smaller percentage of developers who actually read the source code.

This scripts vs binaries situation reminds me of something in the linux kernel: you can't use the sticky bit against scripts. When you add it, it shows as sticky in 'ls -lF' but doesn't work when you go to run it. Sticky bit is only for binaries.

It seems stupid, but on the other hand I never see people abusing the sticky bit, possibly as a result of the higher barrier to entry.

On the other hand, it causes me inconvenience every time I want to do something legitimate with it.

Re: Introducing Pow, a zero-configuration Rack server for Mac OS X

#127
post #16
post #8

Earlier quoted context omitted.

Why is this bad? I get why it seems offensive, but how is running a random shell script from some host any different than running some random software downloaded and installed from the same host? Anything malicious that the shell script could do could also be done by the software itself once installed, no? If they're from the same official source, why should one be considered more trustworthy than the other? EDIT: Ok…

If you download an installer from an https:// link, even though you still aren't capital-S Secure, you're still more secure than running shell scripts spat out over TCP port 80.

If you want https you can install from github:

curl https://github.com/37signals/pow/raw/master/install.sh | sh

Re: Introducing Pow, a zero-configuration Rack server for Mac OS X

#130
post #15

gem install passenger passenger start no preference panes to install. No Apache configuration files to update. And Passenger eliminates the need to edit /etc/hosts. To get a Rack app running, just type a single command.

There are some drawbacks to using Passenger/Mongrel/Webrick for development though, especially when you need to test subdomains and/or SSL.

How so? I've been using Passenger on my dev machine for over a year now. The original reason I installed Passenger on my dev machine was exactly because of how easy it was to get SSL and subdomains working; the app I was working on at the time had 100% SSL user logins, each routed to their own subdomains.
Post reply on HN