LAMP stands for Linux, Apache, MySQL, and PHP, which represents a very common configuration for Linux-based web servers. If you’re interested in testing websites, particularly those that involve a server-side scripting language like PHP, you can install a local LAMP server on your own computer. This tutorial will show you some tricks for setting up a local LAMP server.
Most of this tutorial will apply to any Linux distribution, however the first trick only applies to Debian-based distributions using Synaptic (including Ubuntu).
Open Synaptic and choose Edit > Mark packages by task… Then check the box next to LAMP Server, click OK, and click Apply. That’s it!
By defualt, the directory that stores all the files for your new server (/var/www/) can only be written to by root. This gets to be a real pain, since you have to use sudo any time you want to put something in /var/www/. You can fix this using the following command:
sudo chmod o+w /var/www/
This allows anyone to write to /var/www/. I am sure many people will argue that this is a bad policy; however, I generally feel that there is minimal risk in opening up one non-essential directory to write access by anyone on a personal computer.
What if your new website involves interactions between different users or you need to see how it looks on a different operating system? You don’t need to buy hosting space just to do these tests. If you have another computer on the same network, you can actually access the website from that computer.
On your server computer, type this command:
ifconfigFind the IP address after inet addr and enter this in the address bar on a different computer that is on the same network. You should see the Apache “It works!” page or whatever else you have in the root of your /var/ww/ directory.
I hope this helps you create some cool websites without paying for hosting until you really need it.
Cloud computing may a little over-promised, but it isn’t “worse than stupidity,” as Richard Stallman would say. In fact, it’s really a very positive change in the way we use computers. Not only does it eliminate many of the barriers to using any operating system you want, but it also takes the responsibility of storing and backing up data off of the user. This is all in a very early stage, but the glitches should be worked out in a few years.
Unfortunately, it’s very hard for people to create successful web applications without backing from companies like Google and Microsoft. The problem is that when you start using, for example, Google Docs, it is very hard to switch to Zoho Office. You certainly can’t use both to edit the same documents as you could if they were stored on your hard drive. This means that you are locked into using a single application, naturally leading most of us to pick the one we trust the most. This problem also blocks out a lot of the hobbyist open-source projects that might otherwise appear as web applications.
What we need is a “hard drive in the cloud”: a personal storage space from which documents could be opened with any web application. For example, someone could create a document in Google Docs and save it to their “hard drive in the cloud.” Then, they could open that document from Zoho Office and continue working on it there.
The problem with this plan is that it would require an established web application vendor to adopt it before anyone would bother to use it, and no major web application vendor has an incentive to adopt a system which would make it easier for their customers to switch the a different service.
How will we get data portability in the cloud when companies like Google have it in their interest to prevent any such project?
In the future, every wall will be a multi-touce interface, there will be no buttons to confuse our little brains, and everyone’s arms will be sore from holding them out at the wall to type on their computers.
We already knew Apple didn’t like buttons, but I don’t think anyone saw it coming when they announced a new mice with not one, not two, not three, but zero buttons. With zero tactile feedback, zero division between the left and right buttons, the same pointless 360 degree scrolling you never used before, and an insanely high cool factor, the Magic Mouse is clearly something that will be desired by…
For years Apple’s mice have been the least practical part of Apple’s line of products. In answer to $20 ergonomically comfortable mice with two buttons, a scroll wheel, and smaller back and forward buttons for easy navigation, Apple has introduced the $70 Magic Mouse that promises to work just like a normal mouse, as long as you imagine the tactile feedback and remember where the left and right buttons are. On the plus side, it is pretty.
I applaud Apple for trying something new, but a buttonless mouse is not ready to be a real product.Perhaps in ten years we will all have touch mouses, but its too soon for that now. Deliberately decreasing usability in an effort to create art is not a good tradeoff when it comes to our mice. Sorry, but I still like buttons.
This is a post for Blog Action Day 2009, an effort to unite bloggers to discuss one topic for one day from many different perspectives. This year’s topic, chosen by a vote, is climate change.
Remember the big push for everyone to switch to compact fluorescent, or CFL, light bulbs? Many people advertised them as the easy solution to all of our energy problems. Ignoring the other impracticalities of this claim, there are still two problems with CFLs. First, the murcury in them is a potential household risk if a CFL ever breaks [PDF]. Second, unlesss they are properly recycled, that murcury ends up back the in the environment, where it damages ecosystems, eventually making its way up the foodchain to humans.
Luckily, there is a fairly new technology that solves both of these problems: LED light bulbs. LEDs have been around for a long time, but until recently LED light bulbs were expensive and dim. With LED ligth bulbs that are neither expensive (well, not too expensive) nor dim, let’s look at some of the benefits of LED light bulbs:
The only significant problem with LED bulbs is the cost. As opposed to an incandescent or CFL which can be purchased for a few dollars, an LED bulb costs around $50. It does pay off in evergy savings, though.
I compared the approximate cost savings of an EvoLux LED bulb over a standard incandescent and found that the LED bulb would pay off in the fourth year.
So if you’ve been holding out on CFLs or are just looking for a way to save even more energy, try an LED bulb. I chose to try an EvoLux, but don’t limit yourself to that. Find the best deal you can and try it out.
Of course, you can also download the LED vs incandescent light cost savings spreadsheet. Plug in your energy cost and see what happens. (The graph is on sheet 2.)
Happy Blog Action Day!
Hulu, a popular website which offers free, ad-supported TV shows (and a few movies) has ported their Hulu Desktop software to Linux. Hulu says that Hulu Desktop for Linux will work on Ubuntu 9.04 and Fedora, althoug it could almost certainly be run on other Linux distributions.
Hulu Desktop is free and packages are provided for both 32-bit and 64-bit Ubuntu and Fedora.
Although there are still issues with the limited amount of content networks will allow Hulu to offer, Hulu has been gaining steadily in popularity.
This is the fourth part in a four part series covering remote access to Linux machines using SSH.
Everything in this tutorial should apply to most Linux distributions, however some of the commands may be specific to Ubuntu. You may need to modify some commands to work with your Linux distribution. This is an advanced tutorial, so most instructions will be given as text commands.
Allowing outside machines to access your computer is inherently risky. Assuming your router and/or firewall is properly configured, you will need to poke some holes in it. This potentially leaves you vulnerable to attack. Proceed at your own risk. Because security is a constantly changing issue, you are responsible for securing your own computer and network. You have been warned. If you are not behind a router or other physical firewall and you can’t explain why this is the case, do not proceed.
You’ll be glad to know that this step is the easiest of them all. If you’ve made it this far, you have already done the hard part.
There are probably thousands of different SSH clients for Windows, but the most popular of these is a program called PuTTY. It’s a free download and requires no installation, which means you should be able to run it off a flash drive. (Naturally, it’s also open-source and released under the MIT license.) Go ahead and download PuTTY. (Look for putty.exe)
Just double-click on putty.exe and fill out the Host Name and Port fields. Your host name should be:
username@dyndnsuser.dyndns.com
(Where username is your computer username and dyndnsuser is your DynDNS user account.)
Then just enter the port number you set in part 1 and 2.
Click Open and say yes to the RSA key dialog. You’re in!
Wow! That was a lot easier than the other steps. This concludes the series, so have fun with SSH.
This is the second part in a four part series covering remote access to Linux machines using SSH.
Everything in this tutorial should apply to most Linux distributions, however some of the commands may be specific to Ubuntu. You may need to modify some commands to work with your Linux distribution. This is an advanced tutorial, so most instructions will be given as text commands.
Allowing outside machines to access your computer is inherently risky. Assuming your router and/or firewall is properly configured, you will need to poke some holes in it. This potentially leaves you vulnerable to attack. Proceed at your own risk. Because security is a constantly changing issue, you are responsible for securing your own computer and network. You have been warned. If you are not behind a router or other physical firewall and you can’t explain why this is the case, do not proceed.
You’ll be glad to know that the graphical piece is actually a lot easier than the first two parts. It’s really just a few configuration changes and that’s it.
Open your /etc/ssh/sshd_config file.
gksudo gedit /etc/ssh/sshd_config
Then make sure that X11Forwarding is set to on and both of the lines below are uncommented (meaning that they do not have a # in front on them:
X11Forwarding yes X11DisplayOffset 10
That’s it on the server end!
You may also need to change some settings on the computer from which you are connecting. Open your /etc/ssh/ssh_config file. Notice the subtle difference between sshd_config and ssh_config.
gksudo gedit /etc/ssh/ssh_config
Then you need to make sure that these lines are uncommented:
ForwardAgent yes ForwardX11 yes ForwardX11Trusted yes
Now try connecting again:
ssh -X -p <em>port number</em> <em>username</em>@<em>dyndns username</em>.dyndns.com
Then just type the name of a graphical application:
gnomine
Just take a moment to think about how cool it is that you’re running Gnome Mines graphically across the internet from a different computer.
This is the second part in a four part series covering remote access to Linux machines using SSH.
(Sorry this one was a little late. I just forgot to publish it. I’ll post the last two sooner.)
Everything in this tutorial should apply to most Linux distributions, however some of the commands may be specific to Ubuntu. You may need to modify some commands to work with your Linux distribution. This is an advanced tutorial, so most instructions will be given as text commands.
Allowing outside machines to access your computer is inherently risky. Assuming your router and/or firewall is properly configured, you will need to poke some holes in it. This potentially leaves you vulnerable to attack. Proceed at your own risk. Because security is a constantly changing issue, you are responsible for securing your own computer and network. You have been warned. If you are not behind a router or other physical firewall and you can’t explain why this is the case, do not proceed. I would also advise you to only try this on your home network, because your employer will probably dislike you messing with SSH, unless, of course, that’s your job.
There are some security tweaks you can make to your /etc/ssh/sshd_config file. There are, of course, tons and tons of tweaks you can make. A complete guide to the OpenSSH configuration file is way, way beyond this guide, but I’ll cover a few things you can do:
Port 4005 # Only listen on port 4005 # 4005 is just an example, this can be anything roughly between 1500 and 5000
This was discussed in part 1, so I suggest you read that. The basic lesson is that you probably shouldn’t use port 22 (the default).
ListenAddress 192.168.1.175 # Only listen on network interfaces with the IP 192.168.1.175What this line says is to only listen on network connections where your computer’s IP is, in this case, 192.168.1.175. This is useful for a number of reasons. For example, if you have multiple network connections (such as an ethernet connection and a WiFi connection), you could tell SSH to only work on one of those connections. Also, if you were at a coffee shop or some other public WiFi, you would probably not have the same IP address that you do on your own network (depending on your network’s configuration). Basically, it’s just a generally good idea to specify what IP address SSH should listen on. Getting your IP address was also covered in part 1. The quick version is that executing ifconfig should tell you.
Protocol 2 # Only allow logins using SSH 2
There are two versions of the SSH protocol. SSH 1 is old and potentially insecure. Make sure you are only allowing protocol 2 with the line above. This should really already be in your default configuration, but if it isn’t, add it.
PermitRootLogin no
Once again, this is pretty straight-forward and is probably already in your configuration. You shouldn’t usually login to root locally, so why would you let remote users login to root? You can still sudo or whatever.
AllowUsers thomas # Only allow thomas to loginThis option allows you to specify which user(s) should be allowed to login via SSH. You may or may not want to add this, but if your only going to login with one account, it adds a small extra layer of security.
It is worth noting that a lot of these configurations are purely security through obscurity. Contrary to what some people say, I don’t believe there is anything wrong with that, as long as it’s not your only defense.
Time to access your computer across the internet. I’ll warn you about the risks again:
A properly configured home router should usually pretend not to exist by giving no reply to unsolicited communications from the outside. In other words, if I try to talk to your router without your router talking to my server, you router should ignore me as if no one was there. This gives you great security, since if no one knows you are there, it’s hard to attack you. (This does not, of course, have any effect on malware spread by email, the web, chat programs, etc.) Allowing your computer to be remotely accessed over the internet cuts a hole in that anonymity. Your router will have to start replying to requests on a particular port. This is dangerous, but not too dangerous as long as your securing everything correctly. (You can test how your router is configured with GRC’s SheildsUP! tool.)
The first step is to make sure that your computer always gets the same IP address. If you are using DHCP, and you probably are, then your computer will get a different IP address ever time you get on your network, usually in the range of 192.168.1.100 to 192.168.1.150 or so. You need to setup something called a static lease in which one computer, identified by a MAC address and a hostname, always gets the same IP address.
This is a completely router specific process, so I can’t help you much. Unfortunately, some routers don’t even support this feature. Usually by installing a custom firmware like DD-WRT, you can get the feature even if your router doesn’t support it. Chadwick Wachs has an excellent tutorial for setting up static leases in DD-WRT, which should help you.
Next, we need to redirect traffic from your router, which is the only place an external computer can connect to, to your computer. This feature is support by almost ever router, so don’t work. It’s fairly simple, too.
Again, this is router specific, but you can find specific instructions for many routers on PortForward.com. Remember to replace port 22 with whatever port you choose in part 1.
Don’t worry, your almost there! The final step is to find a way to track your router’s changing IP address. (Yes, that changes too.)
Without paying your ISP extra, you can’t usually get a static IP for your router. Luckily, services like DynDNS.com (a free account is plenty) will give you a free subdomain that points to your router. For example:
username.dyndns.com would point to your routers IP
In order to get the IP to update, you need to enter your DynDNS account into your router settings. Once again, this is router specific, but look for a DDNS section in your router configuration.
Ok. If you’ve made it this far, congratulations! You should now be able to access your computer from any other computer on the internet (with an SSH client, of course), using this command:
ssh -p <em>port number</em> <em>username</em>@<em>dyndns username</em>.dyndns.com
Good luck!
Linux Loop will be participating in Blog Action Day 2009. The goal of Blog Action Day is to unite as many bloggers as possible to focus on one cause. This year’s cause is climate change and the date is October 15th. If your interested in getting involved yourself, check out the BAD website. Otherwise, just look forward to Linux Loop’s Blog Action Day post on October 15th.
This is the first part in a four part series covering remote access to Linux machines using SSH.
Everything in this tutorial should apply to most Linux distributions, however some of the commands may be specific to Ubuntu. You may need to modify some commands to work with your Linux distribution. This is an advanced tutorial, so most instructions will be given as text commands.
Allowing outside machines to access your computer is inherently risky. Assuming your router and/or firewall is properly configured, you will need to poke some holes in it. This potentially leaves you vulnerable to attack. Proceed at your own risk. Because security is a constantly changing issue, you are responsible for securing your own computer and network. You have been warned. If you are not behind a router or other physical firewall and you can’t explain why this is the case, do not proceed. I would also advise you to only try this on your home network, because your employer will probably dislike you messing with SSH, unless, of course, that’s your job.
SSH stands for secure shell. It is a protocol that allows you to access a computer across a network. We will use OpenSSH, an implementation of SSH, since it is the default on most Linux systems.
SSH is installed by default on almost every Linux distribution, however there is usually no SSH server, which is required to actually share your machine with SSH. Use your preferred package manager to install openssh-server
.sudo apt-get install openssh-server
To check if OpenSSH is running type this:
ps -e | grep ssh
This command will list all running processes and then filter the list to only display processes that include “ssh”. You should see a line like this:
11032 ? 00:00:00 sshdThis means that OpenSSH is running. If you don’t see a line like that, try running this command:
sudo /etc/init.d/ssh start
(If two sshd instances are running, it may cause problems. You can usually fix this problem by issuing the command sudo killall sshd followed by sudo /etc/init.d/ssh start.)
There are two steps to configuring your SSH sever. First you must edit the OpenSSH configuration file, then you have to open a hole in your firewall. To start, open the OpenSSH configuration file, which is usually located in /etc/ssh/sshd_config, with your favorite text editor.
gksudo gedit /etc/ssh/sshd_config
Part 2 of this series will discus more configuration options. For now, most of the default configuration should be fine. The one part that you should change now is the port. Your computer has a bunch of different ports (specifically 65535 of them). Each port is like a door that other computers can knock on. For example, when you visit a website, the request goes out through port 80 and the website comes back in through port 80. The first 1024 ports are reserved for specific protocols. Port 22 happens to be reserved for SSH. It is not advisable, however, to let your SSH server listen on that port, though, because an attacker would most likely be scanning for open port 22’s. It is best to change the port option in your OpenSSH configuration to a port number greater than 1024 (and less than 65535). This makes it harder for an attacker to guess which door to knock on. If none of that makes sense, that’s OK. Just change the number after “Port” to a number between 1500 and 5000. While you might be able to use higher numbers, really high port numbers will get you in trouble. See the IANA website for more information about port numbering.
# What ports, IPs and protocols we listen for Port 4005
Next you need to open whatever port you choose in your software firewall, if you are using one. Most Linux distributions have one installed by default, so if you don’t know, you probably are using one. Most people should probably install Firestarter, which is a GUI front end to managing IPTables.
sudo apt-get install firestarter
Open Firestarter and follow the setup wizard. Then click on the Policy tab. Select “Inbound Traffic Policy” and click in the box that has “Allow Service | Port | For” at the top. Then click on the Add Rule button. Enter the port you choose and SSH as the name. Then select “Everyone” and click Add.
You are now ready to test it out. Get your IP address on your local network with this command:
ifconfigYou will need to dig through the output to find your IP address. Here is the relevant piece of the output I see:
wlan0 Link encap:Ethernet HWaddr 00:00:00:00:00:00 inet addr:<strong>192.168.1.175</strong> Bcast:192.168.1.255 Mask:255.255.255.0
Now go to another Linux or Mac OS X computer on the same network. Technically you can use the same computer, but it’s not as good of a demo. Type this:
ssh -p <em>port number</em> <em>username</em>@<em>ip address</em>
For example, I would type:
ssh -p 4005 thomas@192.168.1.175
You may get a message about the server’s RSA key. This is normal and typing yes will bypass the message. Then you should get a prompt for your password. Enter your password and you will be inside your other machine.
Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '192.168.1.175' (RSA) to the list of known hosts. thomas@192.168.1.175's password:
Congratulations! SSH is up and running. Part 2 will teach you how to access your computer from another computer across the internet.