DigitalOcean

Bonesnap

Well Sneaky, you'll be happy to hear I have signed up and got my first droplet going (Ubuntu 14.04 x64). They have a ton of tutorials and help pages which is great because I'm a huge noob.

So I have a LAMP stack running. I initially tried to install everything manually, but quickly realized I was in way over my head. Kept getting issues when trying to install Apache about not having APR or whatever, even though I had gotten the APR stuff via wget and unzipped/unpacked (are those terms interchangeable in Linux?) via tar xvf (if I remember correctly). Anyway, I looked online for a tutorial on how to do it manually and basically the consensus was to not do that and instead just use apt-get. Which is fine but I would have liked to learn how to do it manually because I am sure I'd learn a lot. Plus I installed my WAMP stack manually (I have never used XAMPP), and because of that I know way more about Apache, PHP, and MySQL configuration than any of my coworkers because they do it via XAMPP.

Anyway, so I undid basically everything I did, which wasn't much because I didn't get very far. I installed everything via apt-get. Kinda disappointed though that the version of PHP is 5.5.9. That's kinda old in my opinion. In any case I'll revisit it at a later date or something and see if I can figure out how to do it manually, because I'd love to use PHP7 when it's released in October.

I created my PHP error log and put it inside the /var/www/ directory, so it's not accessible publicly. What's the best practices for its permissions? I only had a few minutes to experiment with it before I had to return to work but was only able to get PHP to write errors to it with 777 permissions, which I assume are way too high. One thing I saw online was to check which user is running Apache, though I don't know how to do that.

This is the book I picked up on the weekend. Should be getting into it tonight. Fun times ahead!

EDIT: Also when I was using root before I created my new user, I was able to do something like this:

echo "Hello world!" > index.html

But when I tried to do it via my new user, even with sudo, I would get a permission denied error message. Instead I had to do:

sudo touch index.html
sudo nano index.html

And then add in the content. Is there a reason for that?

dalecosp

Bonesnap;11050363 wrote:
Well Sneaky, you'll be happy to hear I have signed up and got my first droplet going (Ubuntu 14.04 x64). They have a ton of tutorials and help pages which is great because I'm a huge noob.

So I have a LAMP stack running. I initially tried to install everything manually, but quickly realized I was in way over my head. Kept getting issues when trying to install Apache about not having APR or whatever, even though I had gotten the APR stuff via wget and unzipped/unpacked (are those terms interchangeable in Linux?) via tar xvf (if I remember correctly). Anyway, I looked online for a tutorial on how to do it manually and basically the consensus was to not do that and instead just use apt-get. Which is fine but I would have liked to learn how to do it manually because I am sure I'd learn a lot. Plus I installed my WAMP stack manually (I have never used XAMPP), and because of that I know way more about Apache, PHP, and MySQL configuration than any of my coworkers because they do it via XAMPP.

Well, Kudos! ;-)

Anyway, so I undid basically everything I did, which wasn't much because I didn't get very far. I installed everything via apt-get. Kinda disappointed though that the version of PHP is 5.5.9. That's kinda old in my opinion. In any case I'll revisit it at a later date or something and see if I can figure out how to do it manually, because I'd love to use PHP7 when it's released in October.

I'll omit the customary FreeBSD reference, but I do have 5.6.9 on my personal box and upgrading is fairly painless (fairly, not totally, mind ya) ...

I created my PHP error log and put it inside the /var/www/ directory, so it's not accessible publicly. What's the best practices for its permissions? I only had a few minutes to experiment with it before I had to return to work but was only able to get PHP to write errors to it with 777 permissions, which I assume are way too high. One thing I saw online was to check which user is running Apache, though I don't know how to do that.

ps -aux | grep http
root     1200   0.0  0.9  37636  9444 ??  Ss   30Jul15     0:52.98 /usr/local/sbin/httpd -DNOHTTPACCEPT
www     27864   0.0  1.1  37636 10892 ??  I    11:24AM     0:00.07 /usr/local/sbin/httpd -DNOHTTPACCEPT
www     28027   0.0  1.1  37636 10948 ??  I    11:57AM     0:00.06 /usr/local/sbin/httpd -DNOHTTPACCEPT
www     28077   0.0  1.1  37636 10840 ??  I    12:06PM     0:00.04 /usr/local/sbin/httpd -DNOHTTPACCEPT
www     28594   0.0  1.1  37636 10876 ??  I     1:13PM     0:00.05 /usr/local/sbin/httpd -DNOHTTPACCEPT

So, ps(1) is your friend. Probably should omit the "-" on Linux, I think that's a BSD-ism ("ps aux" instead).

This is the book I picked up on the weekend. Should be getting into it tonight. Fun times ahead!

EDIT: Also when I was using root before I created my new user, I was able to do something like this:
echo "Hello world!" > index.html
But when I tried to do it via my new user, even with sudo, I would get a permission denied error message. Instead I had to do:
sudo touch index.html
sudo nano index.html
And then add in the content. Is there a reason for that?

The directory you are in doesn't allow you write access. You could "chmod" it, or "chown" it, but generally you want to be careful about such things. What groups are you in? What does 'id' tell you?

id dalecosp
uid=1001(dalecosp) gid=0(wheel) groups=0(wheel)

laserlight

Bonesnap wrote:
Kinda disappointed though that the version of PHP is 5.5.9. That's kinda old in my opinion.

In fact, the expected next Long Term Support release of Ubuntu is expected to be 16.04, which means that it will be released shortly before support for PHP 5.5+ ends. I hope it will support PHP 7+ in the official APT repositories as support for PHP 5.6+ is expected to end before the release of Ubuntu 18.04 (if that happens and is LTS). You could use Ubuntu 15.04 today: it supports PHP 5.6.4 in the official APT repositories, but that may not be worth the trouble of an "in-between" release for a production server.

Incidentally, have you considered Nginx + PHP-FPM? There's a DigitalOcean tutorial on How To Install Linux, nginx, MySQL, PHP (LEMP) stack on Ubuntu 14.04

NogDog

Yeah, seems that nginx is where the PHP action is these days -- at least in the Laravel framework world and its supporting Homestead VM, that's what all the cool kids are using now.

Weedpacket

NogDog;11050373 wrote:
Yeah, seems that nginx is where the PHP action is these days -- at least in the Laravel framework world and its supporting Homestead VM, that's what all the cool kids are using now.

The last five years or so suggest it's not just PHP that's hanging out with nginx more; Necraft's August 2015 survey suggests the biggest sites are leaving Apache for it. Looks like it will be supporting HTTP/2 before Apache as well.

dalecosp

Some may be leaving Apache, and others, perhaps many others are using it as a outward-facing reverse proxy for the Apache boxen doing the heavy lifting behind the nginx box (try typing "nginx" in Google and see if "nginx reverse proxy" is the top auto-suggested search).

I have it serving plain HTML for an interior app, but haven't gone so far as to try and integrate PHP with it.

I guess this old horse likes his familiar pasture 😉 🙁

Bonesnap

So I now have my firewall set up, phpMyAdmin installed and behind .htaccess (took two tries but I was smrt and made a snapshot before trying the first time), MySQL secured. 🙂

One thing I cannot figure out is how the hell do you change your DigitalOcean account password? Nowhere in the settings or dashboard does it have an option for this. I thought under "security" it would be there but it just talks about SSH keys and two-factor authentication, which is what makes me want to change the password in the first place. Initially I made it 25 random characters and stored it in my password manager at home, but I'd like to be able to access it elsewhere if need be, so I enabled two-factor authentication but now I'd like to change the password to something more reasonable for me to remember. I guess I could just log out and use their forgot password link, though I would have imagined it would be a little more user friendly than that.

Question about SSH keys and best practices. So I have mine set up on my main computer at home. It works great. But I have two other PCs at home (one is a laptop) I'd like to set up and realistically I'd like to connect at work as well. I would imagine that reusing a private key is considered a big no-no, so should I regenerate a pair for each computer at home, and then at work just rely on passwords? Seems to me that storing a private key on a work computer is probably considered poor practice. While I don't think I'm going to be let go anytime soon, it is always possible that my access to this machine could be suddenly restricted. I highly doubt anything like that would happen (I have my Dropbox synced with my work computer, so I have other personal stuff here), but I guess it's best to think of all possibilities. What are your guys' thoughts?

dalecosp;11050367 wrote:

ps -aux | grep http
root     1200   0.0  0.9  37636  9444 ??  Ss   30Jul15     0:52.98 /usr/local/sbin/httpd -DNOHTTPACCEPT
www     27864   0.0  1.1  37636 10892 ??  I    11:24AM     0:00.07 /usr/local/sbin/httpd -DNOHTTPACCEPT
www     28027   0.0  1.1  37636 10948 ??  I    11:57AM     0:00.06 /usr/local/sbin/httpd -DNOHTTPACCEPT
www     28077   0.0  1.1  37636 10840 ??  I    12:06PM     0:00.04 /usr/local/sbin/httpd -DNOHTTPACCEPT
www     28594   0.0  1.1  37636 10876 ??  I     1:13PM     0:00.05 /usr/local/sbin/httpd -DNOHTTPACCEPT

So, ps(1) is your friend. Probably should omit the "-" on Linux, I think that's a BSD-ism ("ps aux" instead).

I think the hyphen is optional. It worked for me with and without, and I've seen plenty of commands online where some omit it and others keep it.

This is what I get (ps aux | grep apache2):

root      1078  0.0  2.3 382264 12024 ?        Ss   Aug24   0:02 /usr/sbin/apache2 -k start
www-data  1089  0.0  3.0 387364 15120 ?        S    Aug24   0:00 /usr/sbin/apache2 -k start
www-data  1090  0.0  2.9 388636 14844 ?        S    Aug24   0:00 /usr/sbin/apache2 -k start
www-data  1091  0.0  2.6 387760 13312 ?        S    Aug24   0:00 /usr/sbin/apache2 -k start
www-data  1092  0.0  3.1 388360 15724 ?        S    Aug24   0:00 /usr/sbin/apache2 -k start
www-data  1093  0.0  1.8 385344  9068 ?        S    Aug24   0:00 /usr/sbin/apache2 -k start
www-data  1286  0.0  1.2 382304  6396 ?        S    Aug24   0:00 /usr/sbin/apache2 -k start
www-data  1289  0.0  1.2 382304  6396 ?        S    Aug24   0:00 /usr/sbin/apache2 -k start
www-data  1290  0.0  2.7 387092 13968 ?        S    Aug24   0:00 /usr/sbin/apache2 -k start
www-data  1291  0.0  2.8 387336 14536 ?        S    Aug24   0:00 /usr/sbin/apache2 -k start
www-data  1292  0.0  2.6 387604 13472 ?        S    Aug24   0:00 /usr/sbin/apache2 -k start
brent     2308  0.0  0.1  11740   932 pts/0    S+   09:16   0:00 grep --color=auto apache

dalecosp;11050367 wrote:
The directory you are in doesn't allow you write access. You could "chmod" it, or "chown" it, but generally you want to be careful about such things. What groups are you in? What does 'id' tell you?

It's the public HTML folder, shouldn't it have some kind of write access? And why does the echo command have different restrictions than touch? I was still able to create the file and add content to it, it just took me two steps instead of one.

id tells me this:

uid=1000(brent) gid=1000(brent) groups=1000(brent),27(sudo)

As part of one of the guides it walked you through adding your new user to the sudo group.

laserlight;11050369 wrote:
Incidentally, have you considered Nginx + PHP-FPM? There's a DigitalOcean tutorial on How To Install Linux, nginx, MySQL, PHP (LEMP) stack on Ubuntu 14.04

I am barely grasping Linux as it is, let's not complicate things by making me learn a whole new webserver at the same time :p I will probably experiment with it in the future but for now I'm going to stick with what I know. At least I've seen an Apache config file.

laserlight

Bonesnap wrote:
One thing I cannot figure out is how the hell do you change your DigitalOcean account password? Nowhere in the settings or dashboard does it have an option for this.

It is a secret normally restricted to DigitalOcean adepts, but since you are one of the old guard of PHPBuilder, I shall share it with you: Settings -> Profile -> Edit Profile -> Current Password. The fields for New password and Confirm new password will appear.

Bonesnap wrote:
Question about SSH keys and best practices. So I have mine set up on my main computer at home. It works great. But I have two other PCs at home (one is a laptop) I'd like to set up and realistically I'd like to connect at work as well. I would imagine that reusing a private key is considered a big no-no, so should I regenerate a pair for each computer at home, and then at work just rely on passwords? Seems to me that storing a private key on a work computer is probably considered poor practice. While I don't think I'm going to be let go anytime soon, it is always possible that my access to this machine could be suddenly restricted. I highly doubt anything like that would happen (I have my Dropbox synced with my work computer, so I have other personal stuff here), but I guess it's best to think of all possibilities. What are your guys' thoughts?

Store a passphrase protected private key on your work computer. In the event that you no longer have access to your work computer and could not remove the key file in time, just login at home and delete the corresponding public key from the list of authorised keys. This way, you can configure SSH on the server to disable password authentication.

sneakyimp

Bonesnap;11050363 wrote:
Well Sneaky, you'll be happy to hear I have signed up and got my first droplet going (Ubuntu 14.04 x64). They have a ton of tutorials and help pages which is great because I'm a huge noob.

I'm proud of you. Cloud computing/virtual servers have been a revelation for me. I haven't had to provision an actual dedicated server in years. The virtual machines are much cheaper for lightweight development and small sites too.

Bonesnap;11050363 wrote:
Anyway, so I undid basically everything I did, which wasn't much because I didn't get very far. I installed everything via apt-get. Kinda disappointed though that the version of PHP is 5.5.9. That's kinda old in my opinion. In any case I'll revisit it at a later date or something and see if I can figure out how to do it manually, because I'd love to use PHP7 when it's released in October.

I concur that the version numbers you get with Ubuntu for PHP and MySQL are disappointing, but I still tend to rely on the package system because it's so much easier than compiling from source, resolving dependencies, etc. I believe that although the version numbers seem old, these are specially maintained packages that often have a lot of security patches and such applied in them. I'd also point out that you can do apt-get update and apt-get upgrade to easily and automatically update your software to the latest versions offered by the package maintainers. While it's disappointing in many cases not to have the latest/greatest version, you always have the option of compiling from source if you REALLY need that latest feature. Just remember to download the latest source and recompile/install manually when it gets updated.

Bonesnap;11050363 wrote:
I created my PHP error log and put it inside the /var/www/ directory, so it's not accessible publicly. What's the best practices for its permissions? I only had a few minutes to experiment with it before I had to return to work but was only able to get PHP to write errors to it with 777 permissions, which I assume are way too high. One thing I saw online was to check which user is running Apache, though I don't know how to do that.

Offhand, I don't really know what permissions must be. 777 is certainly waaaay too permissive though. I'm not 100% certain, but I think you don't actually have to create this file manually -- I believe apache will create it as needed. I'm looking around on my workstation and see that one of my php error logs is specified in the apache config file (you can define a different error log for each virtual host:

<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /var/www/example/html
    ServerAdmin sneakyimp@phpbuilder.com
    UseCanonicalName Off
    ErrorLog /var/www/example-error.log
</VirtualHost>

I note that my apache php.ini has no entry for error_log so it defaults to the apache error_log. Sorry I can't be more informative. The error log doesn't factor heavily in my development approach.

If you want to know who the apache user is, just put this script on your server and visit it in your browser:

passthru("whoami");

It should tell you who the apache user is. On Debian/Ubuntu, it's usually www-data. On Centos/Red Hat machines, I've seen httpd and also apache and apache2 I think.

Bonesnap;11050363 wrote:
But when I tried to do it via my new user, even with sudo, I would get a permission denied error message. Instead I had to do:
sudo touch index.html
sudo nano index.html
And then add in the content. Is there a reason for that?

I've noticed that some commands seem to have two distinct aspects when it comes to permission to do something, echoing text into some file being one of them. I have dejectedly resigned myself to entering the extra commands to get it done.

sneakyimp

Weedpacket;11050377 wrote:
The last five years or so suggest it's not just PHP that's hanging out with nginx more; Necraft's August 2015 survey suggests the biggest sites are leaving Apache for it. Looks like it will be supporting HTTP/2 before Apache as well.

Aw man. Add this to the list of skills I need to upgrade. sigh.