I have a win box(clean, no bloat, no node, no servers) that I develop with, and incidentally have cygwin on it. I also have an arch linux server fully configured like a dream, the way i like it, and even use putty on the win box for it. I would love to use the resoures on the linux for this, however the problem is i spend too much time on nginx, php-fpm and crap like that on the server, to keep a proper dns name dialed in to have proper dns accessible names to map the browser on the dev machine to the server, normally, when i need it.
Im willing to break the pattern, to stab at a quick solution, since this comes up so often for me, but i want the easy option, i thought i ask opinions.
-What i need is a way to access the node server, any node server for that matter, from the win box browsers. that's my main requirement.
-Secondarily, i need to access git, on the server, for repo storage, and preferable even work on the files out of there as \\hostname\projects\site\index.js etc.. on the winbox.
-I prefer NOT to use git through any kind of start menu, or icon, i would hate that, im a command line guy.
Existing
win development, want to work on a node app, arch box on 192.168 subnet with working node, no dns mapped (can add to etc/hosts, but to have the linux box capture that dns name too much work for now)
Option 1
use cygwin right here, install node on it, go to town on development, but i want to use the git repo/git on the arch linux box somehow still, i wont install git, or nodejs on windows per say, only through command line, choclatey maybe, but preferable cygwin, if there is such a thing, i just havent used it before really.
Option 2
Whats available for me to map something easy to the linux, and use the resources available there and putty, e.g. do i need a quick dns solution or what am i looking for? (dont suggest bind or dnsmasq please) i much prefer bind, have it on there, but dont want to get that dialed in, just want to spend an hour on this each time i need to work on a website, i need something quick.
What about a proxy, if i point my browsers to proxy to the ip of the server? I dont really mind using ips, as long as the site allow it.
suggestions?
There is nothing wrong with dnsmasq. Its wayyy simpler than Bind, you just put names in etc/hosts. For the Windows machine, install Virtual Box and Ubuntu. Not sure cygwin works at all with Node but it would probably suck compared to Virtual Box.
There is no simple Linux DNS that I know of besides dnsmasq. nsd is not bad but its still a pain in the ass. There might be an easy to setup Windows DNS server though. But I would just use Virtual Box and dnsmasq.
On Windows the hosts file is normally in \WINDOWS\system32\drivers\etc
Related
I've built an application that run with node.js, which permit to retrieve some data through a REST API.
I want to put it online on a personal computer (Windows), but I have no idea how to install a server and what I need to make my application available online.
Can someone explain me the steps to do it ? I know that some online services exists like Heroku but I want to do it by myself.
Thank you
This question looks small, but it's actually huge. I started writing this as a basic guide, and it ended up really being quite a lengthy answer, so I split it into pieces. Overall hope this helps!
Using a VPS
You don't want to serve a website from your personal computer, because any time your computer is off, the website will be down. You don't want that kind of responsibility with your computer, so much of the time people choose to essentially rent server space from companies that's sole purpose is to get you space/bandwidth on a simple computer that is always on. These are often called VPS's (virtual private servers).
So the first step I'd recommend is to grab a VPS for yourself. Digital Ocean is a great service that you can get a solid server from for $5/month, I would recommend starting there. There are bunches of other companies you can get VPS's from though if you prefer, probably the most popular alterntive being linode.
Once you've got yourself a VPS, log in to it using ssh. Usually it will look something like this:
ssh root#000.000.0000
...with the number at the end being the IP address of your server. Most VPS's are some flavor of linux, so being familiar with the linux command line interface is important. Once you're all set in your server, you'll want to do a few things. This is what I usually do, in order:
Install vim
For me, vim is the easiest way to edit files through the command line. This certainly might not be the case for everyone - some people prefer emacs, and some nano, which is a lot simpler. If you are interested in learning about vim, there are loads of tutorials around the 'net. If getting into vim isn't your thing, I'd recommend using nano instead wherever I mention it from here on.
To get it installed, we can use apt, which is aptitude, the package manager on ubuntu, the flavor of linux I'll use in this answer since it's a popular one for servers, and is the default for digital ocean. Just run apt-get update to make sure packages are up to date, then apt-get install vim to put in vim.
Add your ssh key
Add your ssh key to ~/.ssh/authorized_keys so that you don't need a password to log in. If you are unfamiliar with ssh keys, they are basically a pair of cryptographic keys that you can use to avoid needing to authorize with a password every time. By adding your public key to the ~/.ssh/authorized_keys file, you are essentially telling the server "this is my computer, so you don't need to ask me for a password to log in". Github has a great guide on how to generate keys. Once this is done, you can open the file with vim, get into insert mode, and paste the public key in from your local machine. Save and quit and you're set.
Install node.js
If you are trying to run a node app, you will of course need to have node! Installing node on linux is a bit different because the node installer I'm sure you used locally is graphical, where here you only have the command line. Luckily, it's not much more difficult with this set of instructions, which you can follow exactly. Make sure you do not just do the default apt-get install nodejs, as this will install an old version. Take the couple steps after the second paragraph to add ppa and get a newer version.
Deploy your app
Ok, so you have a machine that has node and theoretically could run your app. This is good news. Now we need to actually get the app onto the machine. There are a few ways you can do this. If you have ruby installed locally, you can use capistrano, a popular deployment solution. A lighter weight approach that I often prefer is deploy, although I don't think that will work on windows. You can also just use github or bitbucket - push your app to a remote repo then clone it down from your VPS (make sure to apt-get install git and set up your username first - if it's a private repo you'll probably have generate and add a key to get access to pull it down). However you manage to do it, get the files transferred.
Test your app
On your VPS, cd into wherever your app was put and run it. Make sure everything is working ok, and hit http://YOUR_IP:PORT, just your ip address followed by a port number that your app is running on after the colon. You should be able to see your app. If not check back to the terminal, it may have crashed. Sometimes you can find flukes when you are setting it up on a different system. If your app uses a database, you might need to get this configured too. You can google "ubuntu setup database name" and find some tutorials -- digital ocean has a pretty solid library of these types of tutorials themselves.
Install nginx
Nginx is a great way to serve multiple apps on one machine, and to handle domain names and such. I wrote an article on how to set up nginx that you can check out to learn the basics and get it installed. Once this is done, you can link up your app with a proxy_pass. Rather than try_files, which is what the article does to server static files, just drop in a proxy_pass statement to the port your app is running on instead, and nginx will direct traffic right through to your app. Here's an example, if you had your app running on port 1234 and your domain name was example.com
server {
server_name example.com;
location / {
proxy_pass http://localhost:1234;
}
}
This will just take traffic coming into the box from example.com and pass it to your app, which is awesome.
Get your domain in order
I have to assume you don't want to require people to use an IP address to access your app, and you want a domain name. Go grab one from wherever, and once you have this you need to edit the DNS records. I've found that it's easiest to use dnsimple for this, as not every domain registrar has solid dns record handling, and you can keep all your dns management in one place. Now, just put an A record on the root of your domain, pointing it to your VPS's IP address. After giving it a couple minutes for the records to propigate, a hit to that domain should go directly to your server - fantastic.
Now is the time to check through and make sure that your app is running properly and that your nginx configuration is correct (and that you have reloaded nginx). Make sure that in your configuration, the server_name mirrors the domain you set to point at your VPS. Make sure the port in the proxy_pass is the same as your app is running on. Once this has been confirmed, go to the domain, and if you did it right, your app will come up. Whoo!
Run it on a production server
Great, so we got our app running and it's online on the internet for the public to enjoy. Just about time to sit back and let everyone throw money at you, a common occurance whenever you get a site shipped. But don't recline too quickly, because the last thing we need is to make sure this app stays up and continues running even if something goes wrong, or you log out of your VPS, so you don't always have to keep a terminal window open running the app. For this, we can use what some call production servers -- servers made specifically to ensure that your app runs in the background and stays running all the time. Luckily, node has a few of these open source, my favorite being pm2. Check out this page, read the getting started instructions, install pm2 on your machine, and run your app. The process might look something like this:
npm install pm2 -g
cd path_to_my_app
pm2 start app.js
Since you ran it on the same port, your nginx configuration should remain the same, and your app should still be up if you visit the domain.
Phew, that was a lengthy process. Probably more than you expected - makes sense why something like heroku exists. So is this really worth it, running and maintaining the site yourself? I'd argue yes, and I host every one of the sites and apps I run like this. Here's why:
learning: I learn tons about how things work this way, and get much better at sysops.
cost: You can host like 20 sites on a single $5 digital ocean box. hosting is pennies.
control: Heroku sometimes goes down and it sucks because all you can do is wait for them to get it back up. If my site goes down, it's my fault and I can find out why and fix it.
I'm sure this answer was more than you ever expected to get here, but hope this helps! Getting from dev to sysops is a journey and sometimes can get really frustrating, but I promise once you have a good handle on things, it feel great and really helps your skills a lot.
Finally, I want to note that this is without a doubt an opinionated guide. There are tons of other tools and other ways to do these things -- the workflow I have here is just the way I prefer to do things. By all means feel free to tinker and suit the workflow to your needs once you have it under your belt! There are also lots of other details that could be added in here about setting up different databases, improving your deploy/restart flow, and securing your box a little more throughly. Would love to hear any feedback and add any of these pieces in if you or others are interested.
Google Platform has resources for Node developers. There is a tutorial shows you how to deploy a simple Node.js application to Google App Engine Managed VMs. Detail of the pricing is here.
Amazon Web Service (AWS) also has the similar service. Here is the tutorial. The AWS Free Tier is designed to enable you to get hands-on experience with AWS at no charge for 12 months after you sign up. You can investigate AWS as a platform for your Node.js application. Check it here.
I would like to start out by apologizing. I have very little knowledge in the areas of Linux and Servers. I have been asked at work to set up a Linux box running Apache Tomcat. The Server needs to be enabled to allow websockets. I managed to get Debian installed. During the installation it gave me the option to make it a web server, which I did. There are now some different folders and files that are named "apache" in the files system, so my guess is that I am in fact running Apache, but to be honest I'm not 100% sure, and if it is, I don't know if its Tomcat. I fumbled around a bit and figured out the IP address of the computer I installed on and tried going to that IP from another computer in the network and it worked. I was able to see the html file that I put in the /var/www folder on the host machine. I then went out and found a nice piece of code, someone was kind enough to share, that is suppose to test websockets capability but I cant seem to get it working. My thinking is that my server isn't allowing PHP to run. I came to this conclusion by testing. I took a web page from my other server, its written in PHP, that when opened will send a text to my phone. Its just a small piece of code that I used for testing. When I tried running it from the Linux server it wont run, meaning it wont send the text to my phone. So here I am. I realize I'm asking for a simple solution to a complex problem, but I'm under the gun so to speak. I have about a week to get this going, so I just don't have the time to really immerse my self in this stuff the way I would like to. My question in its simplest form is"How do I configure my server to run PHP?" Any help/advice would be greatly appreciated! Thank you all for your time and patience.
Have you tried running a simple PHP script like echo 'Hello World';??
If not then try, if it works then your PHP is up, but sockets are just not configured to use.
If it doesn't work then install Ubuntu, a simple newbie friendly interface for Linux, and then install LAMP, here its how to do it.
And don't panic.
I do a lot of web-app development on multiple platforms: Java, PHP and ASP.net. To keep work separate I like to run any app I happen to be developing under its own domain name on my local intranet, e.g. "peter.example.com", "paul.example.com" & "mary.example.com".
For about a year I've been running BIND and very happy to edit my own zone files and whatnot. However running this service causes long bootups so I want to move this off my dev box soon.
This got me to wondering if there's a project like DD-WRT out there that would let me flash an old router to run BIND from it.
Does anyone out there know of any homebrew DNS appliances?
Try OpenWRT, it's a GNU/Linux distribution tailored for routers that has a rather large set of packages available for it. This includes BIND, which I'm using on my own router as caching DNS resolver specifically to have DNSSEC up and running.
PS This question would probably have been better on serverfault or maybe superuser.
We received access to the environment, but I now need to go through the process of securing it so that the previous vendor can no longer access it, or the Web applications running on it. This is a Linux box running Ubuntu. I know I need to change the following passwords:
SSH
FTP
MySQL
Control Panel Admin
Primary Application Admin
However, how do I really know I've completely secured the system using best practices, and am I missing anything else that I need to do other than just changing passwords?
3 simple steps
Backup configurations / source files from HTTP / SQL tables
Reinstall operating system
Follow standard hardening steps on fresh OS
Regardless of who it was, they could have installed any old crap on there (rootkits) that you can't configure away.
You will probably get more responses at serverfault.com on these kinds of questions.
There are several things you can do to secure SSH by editing your sshd_config file which is usually in /etc/ssh/:
Disable Root Logins
PermitRootLogin no
Change the ssh port from Port 22
Port 9222
Manually specifying which accounts can login
AllowUsers Andrew,Jane,Doe
SecurityFocus has a good article about securing MySQL, although it's a bit dated.
The best thing you could do would be reinstall and make sure when you bring over files from the old system to the new that it is just data, and not executables that could be nasty. If this is to much, changing all the passwords, and watching the logs for a few weeks, as well as playing with iptables to block former vendor. Also given that it could have a rootkit at the kernel level its probably good idea to change that out, and also watch traffic coming out of the box fro something that might be going to the vendor. It really is a hassle to take someone else's machine and say that is safe now, I would go as far to say it is nearly impossible.
side note. This isn't really programming related so probably shouldn't be on this site.
I'd like to set up a cheap Linux box as a web server to host a variety of web technologies (PHP & Java EE come to mind, but I'd like to experiment with Ruby or Python in the future as well).
I'm fairly versed in setting up Tomcat to run on Linux for serving up Java EE applications, but I'd like to be able to open this server up, even just so I can create some tools I can use while I am working in the office. All the experience I've had with configuring Java EE sites has all been for intranet applications where we were told not to focus on securing the pages for external users.
What is your advice on setting up a personal Linux web server in a secure enough way to open it up for external traffic?
This article has some of the best ways to lock things down:
http://www.petefreitag.com/item/505.cfm
Some highlights:
Make sure no one can browse the directories
Make sure only root has write privileges to everything, and only root has read privileges to certain config files
Run mod_security
The article also takes some pointers from this book:
Apache Securiy (O'Reilly Press)
As far as distros, I've run Debain and Ubuntu, but it just depends on how much you want to do. I ran Debian with no X and just ssh'd into it whenever i needed anything. That is a simple way to keep overhead down. Or Ubuntu has some nice GUI things that make it easy to control Apache/MySQL/PHP.
It's important to follow security best practices wherever possible, but you don't want to make things unduly difficult for yourself or lose sleep worrying about keeping up with the latest exploits. In my experience, there are two key things that can help keep your personal server secure enough to throw up on the internet while retaining your sanity:
1) Security through obscurity
Needless to say, relying on this in the 'real world' is a bad idea and not to be entertained. But that's because in the real world, baddies know what's there and that there's loot to be had.
On a personal server, the majority of 'attacks' you'll suffer will simply be automated sweeps from machines that have already been compromised, looking for default installations of products known to be vulnerable. If your server doesn't offer up anything enticing on the default ports or in the default locations, the automated attacker will move on. Therefore, if you're going to run a ssh server, put it on a non-standard port (>1024) and it's likely it will never be found. If you can get away with this technique for your web server then great, shift that to an obscure port too.
2) Package management
Don't compile and install Apache or sshd from source yourself unless you absolutely have to. If you do, you're taking on the responsibility of keeping up-to-date with the latest security patches. Let the nice package maintainers from Linux distros such as Debian or Ubuntu do the work for you. Install from the distro's precompiled packages, and staying current becomes a matter of issuing the occasional apt-get update && apt-get -u dist-upgrade command, or using whatever fancy GUI tool Ubuntu provides.
One thing you should be sure to consider is what ports are open to the world. I personally just open port 22 for SSH and port 123 for ntpd. But if you open port 80 (http) or ftp make sure you learn to know at least what you are serving to the world and who can do what with that. I don't know a lot about ftp, but there are millions of great Apache tutorials just a Google search away.
Bit-Tech.Net ran a couple of articles on how to setup a home server using linux. Here are the links:
Article 1
Article 2
Hope those are of some help.
#svrist mentioned EC2. EC2 provides an API for opening and closing ports remotely. This way, you can keep your box running. If you need to give a demo from a coffee shop or a client's office, you can grab your IP and add it to the ACL.
Its safe and secure if you keep your voice down about it (i.e., rarely will someone come after your home server if you're just hosting a glorified webroot on a home connection) and your wits up about your configuration (i.e., avoid using root for everything, make sure you keep your software up to date).
On that note, albeit this thread will potentially dwindle down to just flaming, my suggestion for your personal server is to stick to anything Ubuntu (get Ubuntu Server here); in my experience, the quickest to get answers from whence asking questions on forums (not sure what to say about uptake though).
My home server security BTW kinda benefits (I think, or I like to think) from not having a static IP (runs on DynDNS).
Good luck!
/mp
Be careful about opening the SSH port to the wild. If you do, make sure to disable root logins (you can always su or sudo once you get in) and consider more aggressive authentication methods within reason. I saw a huge dictionary attack in my server logs one weekend going after my SSH server from a DynDNS home IP server.
That being said, it's really awesome to be able to get to your home shell from work or away... and adding on the fact that you can use SFTP over the same port, I couldn't imagine life without it. =)
You could consider an EC2 instance from Amazon. That way you can easily test out "stuff" without messing with production. And only pay for the space,time and bandwidth you use.
If you do run a Linux server from home, install ossec on it for a nice lightweight IDS that works really well.
[EDIT]
As a side note, make sure that you do not run afoul of your ISP's Acceptable Use Policy and that they allow incoming connections on standard ports. The ISP I used to work for had it written in their terms that you could be disconnected for running servers over port 80/25 unless you were on a business-class account. While we didn't actively block those ports (we didn't care unless it was causing a problem) some ISPs don't allow any traffic over port 80 or 25 so you will have to use alternate ports.
If you're going to do this, spend a bit of money and at the least buy a dedicated router/firewall with a separate DMZ port. You'll want to firewall off your internal network from your server so that when (not if!) your web server is compromised, your internal network isn't immediately vulnerable as well.
There are plenty of ways to do this that will work just fine. I would usually jsut use a .htaccess file. Quick to set up and secure enough . Probably not the best option but it works for me. I wouldn't put my credit card numbers behind it but other than that I dont really care.
Wow, you're opening up a can of worms as soon as you start opening anything up to external traffic. Keep in mind that what you consider an experimental server, almost like a sacrificial lamb, is also easy pickings for people looking to do bad things with your network and resources.
Your whole approach to an externally-available server should be very conservative and thorough. It starts with simple things like firewall policies, includes the underlying OS (keeping it patched, configuring it for security, etc.) and involves every layer of every stack you'll be using. There isn't a simple answer or recipe, I'm afraid.
If you want to experiment, you'll do much better to keep the server private and use a VPN if you need to work on it remotely.