ysbaddaden / prax

Rack proxy server for development
http://ysbaddaden.github.io/prax/
Other
475 stars 49 forks source link

Simplifying installation process #12

Open suan opened 11 years ago

suan commented 11 years ago

Seems to me the entire installation process can be compressed down to sudo apt-get install prax (or equivalent) if we package prax up nicely with the appropriate post-install actions. Do you think that's the case, or is there more trickery needed?

If so, I think it's a worthy thing people could contribute towards (myself included if I had the time :tongue:)

ysbaddaden commented 11 years ago

Definitely. The install process should be simplified and automatic.

A debian package would be a good start.

dyson commented 11 years ago

So I went down the same route of porting Pow and then concluded it wasn't worth the effort (although I did get it working) and after checking out prax I think it can be everything pow is and more. Well done ysbaddaden.

My thoughts on instillation and I guess prax more widely was to make prax a gem, and add a simple dns server to prax. We can then remove the libnss object file (and compilation requirement) and it could be osx and linux compatible. The slight annoyance is as linux doesn't support conditional dns lookups (like osx) we would need to set the dns server as the default on the linux systems, and forward all non matching requests through to the originally configured server in resolv.conf. In ubuntu's case this is 127.0.1.1 but I am not sure of other distros. There could be a configuration option to not use the internal dns if you were already for instance running dnsmasq or whatever for more advanced use cases.

RubyDNS (https://github.com/ioquatix/rubydns) could be easily added (a fair amount of overkill though) but if you didn't want dependencies a simple resolver with forwarding wouldn't be a huge amount of work.

Then you would have: $ gem install prax $ sudo prax install and away you go.

What are you thoughts on a gem and adding dns? I guess it's slightly of topic but it makes sense to create a package if you want to stick with libnss but if you are happy to include dns then a gem makes perfect sense.

ysbaddaden commented 11 years ago

Hello, glad you like Prax :)

I don't have any particular idea on packaging prax thought. A gem could be simple enough. A resolver (DNS or libnss) must always be installed, but a sudo prax install is doable. Especially if documented when the gem is installed.

The reason I choosed libnss instead of anything, is because it just works on Linux. You can't trust /etc/resolve.conf because it may be overwritten at anytime.

Note: I might work on a DNS resolver and Mac OSX compatibility soon.

J.

ysbaddaden commented 11 years ago

After some thoughts, a gem is definitely the way to go:

$ gem install prax
$ prax install
dyson commented 11 years ago

After I had a quick look at making a gem, there doesn't appear to be a nice way to use the bash scripts executables, so they would need to be converted over to ruby scripts. I still think that it's the correct way to proceed though.

Was there any particular reason why all of the executables were written in bash? Apart from the fact it was probably just easier?

davekaro commented 11 years ago

Possibly related... in the meantime, where are you guys cloning the prax repo to on your machine? Then, are you adding /path/to/prax/bin to your PATH manually?

ysbaddaden commented 11 years ago

I simply link bin/prax into my ~/bin which is in my PATH.

The commands are in bash, because that's enough and faster and simpler.

And the prax start command MUST be in bash, otherwise we'd have bugs with rbenv/rvm and others messing the PATH, etc.

suan commented 10 years ago

Looks like a lot's changed since I opened this issue!

I have some questions about the /etc/init.d script that's now generated - Looks like it doesn't start the prax server itself (it just simply adds to iptables) I think the intuitive thing to do would be to start the server itself as well, especially for a dev-tool like this, most people would want it running all the time. And being able to manage the prax server through init.d will make it more familiar. Also init.d scripts are the default way to autostart things in debian.

Also, I noticed that the install script doesn't make any attempts to add prax to the PATH. How about having it symlink /usr/bin/prax to the prax executable since the init.d script already has DAEMON set to /usr/bin/prax?

Once we have the above 2 in place, we can modify the installation instructions to git clone to somewhere permanent but out-of-the-way like /opt or /usr/local, run the installation script, and you will then have a truly complete install, without us having to worry about packaging.

Thoughts?

suan commented 10 years ago

Addressed to some extent in #59

ysbaddaden commented 10 years ago

Just stating the obvious for history: messing with iptables requires root permissions, hence the initd script, but the Prax server must be run as the current user (and certainly not as root).

I'm using a .config/autostart/pow.desktop that starts Prax whenever I log into GNOME —thought this is actually broken in the unstable branch, for some reasons fixed by configuring rbenv in ~/.praxconfig.

suan commented 10 years ago

Yeah I came across .config/autostart too, but that doesn't account for systems where X is not installed. I wish base debian had a similar directory or config file where you could put things you wanted to autostart in.