Hi, thank you very much for taking the time to give this detailed answer. I will go through it through the weekend in detail as I want to be able to administrate these things myself. I'll let you know how it goes..
frank > > >> BTW, why would you run Apache or nginx on port 3000 when you can just > >> run everything on the same webserver? > > > I don't have apache running on 3000 - it have Webbrick still running > > there so the clients can reach the rails app, but I want to deploy it > > via passenger to them as it seems more stable and better for > > production. Just we can't reach it running on Passenger from the > > clients in the intranet. > > > I just wondered if anyone ever configured a scenario like this and can > > share his experience, I know it has little to do with rails actually, > > hope you guys don't mind. > > Deploying for your intranet is basically the same as deploying on a > "public" server. Passenger is a module for Apache or Nginx just like > the PHP processor is. You follow the instructions on the Passenger > site to get it installed, nothing more, nothing less. > > Then there's the other three things I talked about that have more to > do with the actual webserving side of things: > > - Apache/Nginx Vhost configuration: allows you to map internal > "domains" like myapp.rails or myrailsapp.local or whatever flavor you > prefer to a certain directory with a certain interpreter. This allows > you to host your wiki on wiki.mycompany.local and your railsapp on > railsapp.mycompany.local. > - DNS configuration: in order for your internal desktop/laptop > computers to know about these domains, they need to be set up in the > DNS you are choosing (MacOS X server has BIND built-in and it has a > nice configuration utility called Server Admin to manage it). I myself > find the setup in OS X quite easy to get a hang of and if you can't > get a hang of it google should be your friend to figure out how to do > it. It's specific to your internal structure and there is no clearcut > answer as to how to do it. A DNS is basically a "post office" that > knows how to translate human readable URLs to network addresses. "Can > you tell me the address of myrailsapp.mycompany.local?" "Why yes sir, > you'll find him at 192.1.1.55". You can also configure the MacOS X > server DNS in its turn to pass on URLs it doesn't know about to for > example your ISPs DNS. > - Network settings through DHCP: most people use some kind of router, > whether that's a physical box or a service you run on a server to > configure clients on the network: assign IP addresses from either a > static pool or a dynamic pool, tell them which DNS to use (your ISP > will also have a DNS, but that one won't know about your internal > addresses of course). Again, this is going to depend on what you are > using internally and you'll have to search for documentation specific > to your setup in order to know how to configure it. Suppose you have > your OS X Server at 192.1.1.44, then you'll need to set your DHCP > server to tell the clients to set their DNS to 192.1.1.44. > > If all of the above is sounding way too complicated or completely out > of your comfort zone and you don't want to invest time (and thus > probably billable hours aka money) in figuring out the nuts and bolts, > you should just hire someone that's comfortable with it. You'll have > to decide whether spending a couple of hundred bucks on a server admin > will be more cost effective than you spending a day or two figuring > out how your network needs to be set up (and you being able to adjust > things afterwards because you know how everything works of course). > I'll add as a last note that if you have the theoretical background on > how network setup and webserving work, it shouldn't take you all too > long to get things done. > > I know this probably isn't the "download application X and run it and > everything magically will start working" or "here's a blog post I made > with step by step instructions on how to set up a web serving > infrastructure", but that's just because there is no "one way to rule > them all" information board out there. It seems you pretty much have a > setup in your company already, you'll need to (have someone) find out > how to glue everything together. > > Best regards > > Peter De Berdt -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
