Install and Configure the Apache Web Server in Linux

0:00Apache is by far the most popular web server on the internet. And if you're running Linux, installing it for personal use is extremely easy. Now there are a couple of things you need to be aware of like the name of the package, how to start the service, where the documents are stored, but it's really, really simple, and you can get yourself an up-and-running Apache server in just minutes. Now I'm here on Ubuntu, and in order to install Apache, we need to install the package. So it's just an apt get install apache2.

0:32Now on Ubuntu or Debian it's going to be called apache2. On CentOS or Red Hat it's going to be called httpd. But once you install the package, the files are actually stored in the same location. So we'll let it install all of its packages and all of its dependencies. Then if we go over to a web browser, with Ubuntu it starts the service automatically. So we can just go to http://localhost. And since it's done installing over there, if we press Enter, we're going to see Apache2 default page.

1:04So it's installed and it's already running. Now if you wanted to store some of your own files or serve out files on your network, all you do is go into var/www/html-- and this is the same whether it's Ubuntu or CentOS. And if we look in here, now we're going to see we have the index.html, which is what this file over here is. But let's say we wanted to make our own. So we're just going to say rm index.html, and then we'll make a new one. And I'm just going to say this is a test file. I'll save this.

1:35And now instantly if we hit Refresh, boom, this is a test file. So we've created a web server file right here in the var/www/html folder, and anything we store in here is going to be served up by Apache. So if you need just a quick and dirty server on your network, all you need to do is install it and then put files in this folder and you literally have a web server in your network that easy. Now there are tons of configuration options for Apache that we can make it do various things and configure it to serve multiple domains, but if you just want to get a quick and dirty Apache installation to serve up some web files on your network, it's as easy as what we just did.

2:17It's important to remember the package name. On CentOS it's going to be httpd and on Ubuntu it's going to be apache2. But apart from that, even the document root on CentOS and Ubuntu are going to be the same. It's that var/www/html folder is where it serves files from by default. So for a quick and dirty web server, that's all you need to do. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00Now by default, Apache has a configuration system that is pretty monolithic, meaning that it's basically one configuration file that does the entire config for the whole daemon. However, with Ubuntu and Debian, there's this really neat folder structure that doesn't really change how the configuration files are done. It doesn't change syntax, but it changes how they're stored on your system and it makes them very modular, which means it's a lot easier to see what's happening and to enable and disable things.

0:31And let me show you what I'm talking about. So on a standard Apache install, like how Apache comes out of the box, there is a one big, long configuration file, and it's usually called apache2.conf. And everything, or almost everything that configures Apache is stored in this file. But what Debian has done, and therefore Ubuntu has done, is that they've taken this file and they've broken it up into folders, and those folders can enable and disable specific things like modules and virtual hosts and any configuration code snippet you can enable and disable without editing this huge single configuration file.

1:13Also means you don't have to scroll through this thing trying to find what it is you want to edit. Now let me show you what I mean. On this Ubuntu system I'm in the etc/apache2 folder. I'm just using a GUI representation here so we can actually see it. And apache2.conf is the file. Now it is still the main configuration file, but like I said, they've broken it up so that all of these different folders are included in the main file. Let's look inside of it, and it'll actually even show us. It says, all right, this is the main folder. However, even though this is the main configuration file, there are the mods or the configuration snippets or the sites that you can enable just by creating a conf file in that folder.

1:56So it is the main configuration file still, but the cool part is it includes things. And I can show you how it does that. I scroll down here. Here are the modules, so include the module configuration. It says include in the mods-enabled folder anything that ends in .load or .conf. So the modules are searched for inside these folders. And now you may have noticed that there were also available and enabled. So what's that all about? Why is there enabled but also available, because it doesn't reference available in the configuration file at all?

2:33And let me show you, on the command line, the real magic behind this system that they have developed. So I'm in the etc/apache2 folder, and I'm going to say ls -l sites-* so we can see both folders. So the sites-available, this is where the actual configuration files are stored. These are virtual host files that define individual sites that Apache will serve up. But notice it's in sites-available which is not referenced inside apache2.

3:05So what you do is you make a symbolic links inside sites-enabled to ..sites-available and then the name of the file that you actually want to use. So basically what you're doing is creating a way to turn on and turn off these configuration files just by creating and deleting symbolic links inside the enabled folder. Does that make sense? The files are actually stored in the sites-available folder, which on their own are not parsed at all because the apache2.conf file doesn't reference sites-available.

3:40But when you do a symbolic link into the sites-enabled folder, then they are parsed because it reads it from sites-available. It's in here, and so then it's read into the running system. So it's kind of just a really neat way that Debian and Ubuntu have allowed you to enable and disable sites or modules or configuration snippets on the fly. It's actually elegant and awesome. Rather than get overwhelmed by the file structure in an Ubuntu or Debian system with Apache, it's great to realize that, really, we're just looking at the modularization-- that's a cool word-- of the configuration files themselves.

4:22We could still put everything in that single apache2.conf file and it would be read in just fine. However, that folder structure makes it a lot easier, a lot simpler, and it makes a lot more sense when you're trying to configure individual virtual hosts or modules or things like that. So that's how the configuration system is set up in Ubuntu and Debian, and it makes for a much more enjoyable process when it comes to actually administering the server itself. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00The Apache configuration system, especially in Debian and Ubuntu, is not really difficult. In fact, they make it really easy for you to modularly add and remove sites and modules and config snippets, things like that. However, you can shoot yourself in the foot. And if you're doing manual linking, you can make some mistakes. Now thankfully, there's a suite of tools to do that. But I like these tools because they solve the problem of oops reduction. Let me tell you what I'm talking about. So with the Apache configuration system in Ubuntu and Debian, there's a very easy path to follow for how to put configuration files in and how to link them.

0:37But if you're not careful and you veer off the track, you're going to find there are alligators. And sometimes those alligators have machetes and it can be a really scary world if you accidentally do things the wrong way. Let me give you an example on the command line of something that I've done more than one time in my career. I'm here in Ubuntu in the etc/apache2 folder. If I type ls, we're going to see that we have the set of folders, mods enabled, sites available, sites enabled. And if we look inside the sites folders, we're going to see there are a couple of different sites.

1:09So there's the default 00default.conf and then coolsite.conf, which is a site that I've created a configuration file for. And if I want that to be active, I would go into the sites enabled folder and I would say ln dash s for symbolic link, dot dot sites available, coolsite.conf. Press Enter. And then if we type ls minus l, it's going to show you that it's created this symbolic link to the configuration file.

1:39And then if we wanted to disable that site, we would simply erase this symbolic link. And then the original file would live happily in the sites available folder. Here's what I've accidentally done more than one time. Like, all right, I'm here. ls minus l. Site star. OK, there it is. It's in there. I want to disable coolsite. So I'm going to say rm sites available coolsite. And then if we do an ls of the sites folder again, we're going to see, oh, oh.

2:11See what I did? I didn't delete the symbolic link. I deleted the original file on accident because I was confused by sites enabled and sites available and which is which and where goes what and all those things. And so what I've done is I've shot myself in the foot. I have a symbolic link that points to nothing. It's a broken link. So now not only do I have an error where I am pointing to a configuration file that doesn't exist, I don't have that configuration file anymore. So now I can't even enable and disable it if I wanted to. Hopefully I have backups because otherwise coolsite.conf is completely gone.

2:45You're probably thinking, Shawn, there must be a better way. And yes, absolutely, there is. Let me clean up my mess first. Let's get rid of this coolsite link that's broken anyway. And now you'll notice, if I show you, that in my root folder I have a backups folder. And look inside there. coolsite.conf. It's almost as if I knew I was going to accidentally delete that file. So now I'm going to put that back so that I can enable the site and disable the site the way we call the correct way. So I want to put it into sites available.

3:16Now if we do an ls minus site star, we're going to see we have it back here. It's coolsite there. It's not enabled but it is in the available folder. Now I can use a tool called a2-- for Apache 2-- nsite. So a2nsite ensite for enable site. And I'm going to tell it what site I want to enable. Well, I want to enable cool site. Press Enter. And now it says enabling site coolsite. Now, it's just the name of the file without the .conf at the end. Because they all have to have .conf so you just specify the name of it without the conf file and with this a2n site program.

3:52And all it does is create that symbolic link for you. So it's created coolsite.conf inside the sites enabled folder by symbolically linking it to that one in the sites available folder. Now, I know all it's doing is symbolically linking, but that's super cool. And there is a companion tool called a2dissite where we can say disable coolsite. And sure enough, now it is disabled it, which just means that it's deleted. Let me go back up here and we can show the folders.

4:23Now it's deleted coolsite.conf symbolic link inside the sites enabled folder. And it's done the correct one, unlike the way I did it where I deleted the file that I needed. So there's a really great and easy way to make sure you don't accidentally delete the wrong file. And there's actually an entire suite of the a2 tools. So if we type a2 and just hit Tab a couple of times, it'll show you all the different tools that are available in Ubuntu and Debian. You can disable and enable the conf snippets, the modules, and the sites.

4:55Plus, there's this A2 query tool, which is kind of neat. If we type a2query, it'll give us the help screen. And we can simply do things like a2query dash s and it'll show us all the enabled sites. 00default is enabled by site administrator. It's just another cool way to query that folder structure and not manually link and unlink things. Using the a2 suite of tools, like I call them, like a2enmod, a2dismod, things like that, are not required. You can still manually link all of those symbolic links to make them enabled and disabled.

5:28However, if you use these tools, you get some oops reduction, which, in my case, has saved me a lot of hours of recreating files from scratch. Because if I'm telling the truth, I don't always have a convenient backup copy of a configuration file, especially if I've recently modified it. I hope this has been informative for you and I'd like to thank you for viewing.

0:00Virtual hosts are the way that you can make one server and one machine with a single IP serve out multiple websites. Now historically we've used IP addressing. So every website had to have its own IP address, but that is not true anymore. Now you can set up one single IP address as long as the names are different for each website, and by name I mean the DNS name. So like somethingsomethingsomething.com and anothersomething.com, as long as those names all resolve to that same IP address that the server has, it can serve out multiple sites from one single IP address on one single server.

0:40And it's really easy to do, so we're just going to go to the command line so I can show you how it happens. Now the first thing we have to make sure is that our DNS resolution is working because name-based virtual hosts all depend on DNS resolution. So I'm going to say ping localhost. This is just our localhost, which obviously will respond to a ping. But then I've also set up a DNS entry for coolsite. So I'm going to say ping coolsite. And then it's going to also respond to the same IP address, the 127.0.0.1.

1:11That still resolves, but coolsite and localhost both resolve to that same localhost address. So the next thing we need to do is create a virtual-host entry or a site entry for our new coolsite DNS entry. So we're going to go into sites-available, and inside here we have the default site and then an SSL site. We'll talk about that in a different Nugget. But we need to create a new conf file specifically for coolsite. So I'm going to say vi coolsite.conf.

1:43It needs to end in .conf so we can have it read in to the configuration of Apache. So we're going to create this file from scratch, and it's a very simplistic file in order to enable a virtual host. We just start out the stanza by saying virtualhost *:80. And what this is saying is, all right, this is a virtual-host stanza, and I want you to listen on every single address on the computer on port 80. So it's going to listen on all the port 80s-- port 80 on all of its IP addresses.

2:18And then we need to say server name is coolsite. That's the DNS name that it's going to listen for. If we request a site on coolsite, it's going to use this virtual host. And then the document root is going to be /var/www/coolsite. So that's where the documents are going to be stored. And then we just need to close out this stanza, virtual host, close this out. And this is all we need for a name-based site to work.

2:50The server name, this is the DNS name, coolsite. So if you're doing one for a live website it's probably going to be somethingsomethi ngsomething.something.com, a site like that. But for us, coolsite resolves. So that's what we're going to do is just the server name is coolsite and then where the documents for that are stored. So let's save this file. We're going to say a2enable site coolsite. And now it tells us that it's enabled, but in order to activate it we have to reload apache2. And it even gives us the command to do that.

3:20So systemctl reload apache2. So it's reloaded apache2. And now I do want to show you, I have those sites available already. So var/www/html, that's where our default site is. I created this new folder called coolsite, and in there is a different index.html. And if we go over to our web browser, we should be able to tell the difference. So let's http://localhost, and it should say "This is the plain old default page."

3:51But if we go to, again, the same computer but using a different DNS name, coolsite, now it says "This is COOLSITE." So it's giving us a different page even though it's being served from the same exact computer using the same exact IP address. The coolest part about virtual hosts is that there's no limit to the number you can put on a system. As long as you can make a DNS name for that IP address on your network, you can create a brand-new site. If you own one domain address, you can make unlimited subdomains and have each one be its own virtual host or its own website.

4:28It's a really great way to utilize a server by having it host multiple sites. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00If you have a Apache installed on your server, chances are you're going to want to have PHP installed as well, because it's a very popular programming language for people to use using a web browser as the way that you see the results of the code that you're actually writing. Now the process is pretty simple. You have to know the name of the package to install, which is kind of the most complicated part. And then just make sure the module is enabled. But what is PHP itself? Well, it's pretty simple. Interestingly, it actually originally stood for personal home page, which I didn't know until I was researching what it originally stood for because all these years I've never known.

0:34Now it generally-- people say that it's stands for hypertext preprocessor, or something like that. But a little bit of trivia, personal home page was the original acronym. Anyway, it's a programming language just like any of these other programming languages. The cool part about PHP is that the results display right inside of a web browser. It's a server side language, which means you write the PHP code, and the server, off in the cloud or wherever your server is, actually executes the code, but you get to see the results on your monitor.

1:06So you get to actually run the code on the server and then your portal of interaction, if you will, is in your web browser. I love PHP because everybody has access to a web browser. So it's easy to interact with the code itself. Now installing it on your server, you're going to know if you need to do that. Because if you put the code on a server that doesn't have the PHP modules, it's not going to work right. And the results are going to be a little bit different depending on what version and what operating system you have. For example here I have on our Apache server, I have created a file called index.PHP.

1:41We can look at it really quick. It's just a very small bit of code. And this is inside the index.PHP file. And it should just print this. Look mom, I'm doing PHP. No, not PCP. It should print that on the screen if we go to it. And if we go to cool site/index.PHP and press Enter, we'll see nothing is displayed on the screen. Now another thing you might end up with is you can actually see the PHP code displayed, which is not what you want, because you could have like passwords or private information inside the PHP code.

2:12And if the PHP module is not running, sometimes it will actually display the code itself right on the page. So what we want to do is enable PHP on our server. Now the toughest part is remembering what the name of the package might be. So I recommend going to a command line and typing something like AppCache search for PHP, and then grep the results for Apache. And this will give you a list of a handful of things, and oh yeah, that's what it's called. It's libApache2-mod-PHP.

2:43Again, not really easy to remember, but pretty easy to search for. And all we need to do is install that. So app get install libApache2-mod-PHP. Now if you're using a different distribution version or something, it might be something like this one. You might have to specify the version. This is just a meta package that will give you the latest version, which is what I want. So I'm going to press Enter. It's going to install it. I'm going to say yes, I want it to install. I can see it's creating all the configuration files and mods available.

3:16And now if we head over to the Apache 2 folder and we look inside mods enabled, we should look for PHP. And sure enough, PHP 7.2.conf is enabled. So the installer actually enabled it. If it hadn't, we would type something like a2enmod PHP 7.2, and it would actually do it. But since it's already done that, we don't have to worry about enabling the module. The installation process actually enabled that module for us.

3:48Now I think it actually restarted the service too, but let's restart Apache just to make sure that it's working right. So we're going to say service Apache 2 restart. It's restarted the service. And now if we go back over to our cool site index.PHP and we hit refresh, it should show us the results of the code. And sure enough, it says look mom, I'm doing PHP. No, not PCP. And notice it doesn't show us the code itself. It shows us the results of that programming language, PHP. That's as easy as it is to install PHP on your Apache server.

4:20Now in Ubuntu we don't even have to enable the module because the installation process actually enables the PHP module on our Apache server. In Ubuntu, the toughest part is coming up with the name of the package. And using that AppCache search and then grep for Apache, that's my recommended way of trying to remember the name of the package itself, because sometimes we're remembering that, it's just not going to work. So just search for it. When you see it, you'll recognize it. You can install it and you're ready to go. I hope this has been informative for you. And I'd like to thank you for viewing.

0:00Now, most web servers on the internet are using SSL any more, because it's a way to encrypt the traffic. So you can't use a sniffing tool to see somebody's private data going across a network or across the internet. Now there are multiple ways to accomplish that on a server. You can get a free certificate-- that's a completely valid, 100% valid certificate-- If you have a public facing server. You can get it from a site like, Let's Encrypt, which is just an awesome, incredible site. And there are even tools that will automatically install the certificates and keep them updated on your server.

0:32We're actually going to use something called a self signed cert. One, because our server is internal. It's not facing the public. And also, if we use a self signed cert, we get to learn how to go about doing all the things-- we learn how to make them. And then lastly, how to install it on the server. And that's what we're going to do right now. Now, since we're creating our own certificates, we have to have a place to store them. So I like to just create a folder inside this Apache2 folder. So I'm going to say, make a directory called SSL. And then we'll go into there. And now we need to create the files that are required-- the private key and the public key, or the public cert.

1:05And to do that, we're going to use the open SSL program. Open SSL. And there's a long string of commands. I'll type them out and then explain them. All right. So this basically says, we're requesting that open SSL create some certs. This x509 says the type of cert, meaning we're going to do a self-signed one. Nodes means we don't want it to actually ask us for a pass phrase every time we go to the website. How long before it expires. That we need new keys created. We're not signing with an already existing private key.

1:35The type of encryption. And then the location for the key and the cert that we're going to create, which are both in the current directory. So I'm going to press Enter. It will create them. It'll ask us some stuff. We can fill this out however we want. I'll put a little bit of true information in here. Let's see, I'm in Michigan. I don't want to type anything else. I'm just going to hit Enter. And it's going to create those files. We can see them in here-- ls, there they are. Coolsite.crt and coolsite.key. And now we need to create a virtual machine that is going to listen on the SSL or the HTTPS ports.

2:08So we need to go back now. Go into sites available. And in here, we already have coolsite, which you created in a different Nugget. This is just a simple, virtual host. Well, I'm just going to copy this, because a lot of what we need is already in there. So I'm going to say Copy coolsite to coolsite-ssl-- just to follow the same format that they're using here-- dot com. And now let's edit that. Now, inside here, this stuff is mostly the same. We do need to change the port, because SSL listens on port 443.

2:42The server name is going to be the same, coolsite. The location of the files is going to be the same. So we're going to do that. Make a little bit of space here. Now, we do need to turn on SSL, so it knows to use SSL. So I'm going to say SSLEngine on. And then we need to tell it where the cert files are. So SSLCertificatefile is in etc., Apache2, SSL, coolsite.crt. And then SSLCertificateKeyFile for the private key is going to be in etc., Apache2, SSL, coolsite.key.

3:24And that's really all we need to do-- well, with this virtual host. So let's save this virtual host. Now we need to enable this virtual host. So we're going to say a2ensite coolsite-SSL. So it's going to enable that site. Now, we also need to enable the SSL module. Remember Apache is modular. So we have to enable that-- a2enmod SSL. All right? So there we've enabled the SSL module. And any other modules that it needs it's going to just load as well-- any dependencies it has.

3:55So that's all set. Now we just need to restart the server. We can either use systemctl to restart Apache2, or just the old, standard service Apache2 restart. It's done it. And now, we come over here, and go http://coolsite. We should see the site that we created before. This is the coolest site. But if we add an S here-- for HTTPS-- we should get a warning. Yeah, this site is not secure. Now what it means is, this is a self signed certificate.

4:27This is not on one of the certificate authorities, which-- this is what we would expect, because we just did a self signing. So we click Advanced and add an exception. Confirm it. And then boom. Now it's going to allow us to go there. There is a lock there, meaning that this is secure. However, that little warning just says, but remember, this isn't like a publicly verified site. Which is fine, because it's self signed. But there we go. It's listening on port 443. We're in HTTPS. So now this is encrypted, but it's the same website as it was before, because it's serving the same files from the same location.

5:00It's just doing it with encryption now. So whether you're doing self signed certs like we just did, or you're getting a free cert or a paid cert on the internet, setting up the server itself it's really, really simple. And it's easy to make your server do encryption on your website. So if you have any data, you don't have to worry about it being compromised over the network. I hope this has been informative for you. And I'd like to thank you for viewing.

0:00Once you have SSL set up on your network, you really want to make sure that your users actually go to the HTTPS site instead of defaulting to HTTP. Now there's an old way that we used to do this using mod_rewrite, which is an Apache module that will take the URL and rewrite it and change it so that it goes to the other site, but that's really not the best way to go about doing it anymore. Now with a virtual host we can simply use the redirect command. Now why do we want to do this? Like I said, it's so that your users are forced to go to HTTPS.

0:31Because sometimes if you have both available, HTTP and HTTPS, your users may be using the insecure, nonencrypted website and not even realize it. Because think about it, when you go to a website, what do you type? You type cbtnuggets.com. You don't actually type the HTTPS part of that. So when you type just the domain name, the browser is going to go to the nonencrypted HTTP site, and you want it to automatically go. Thankfully it is super easy using the virtual host redirect to go right to the HTTP site.

1:06Here on our machine we have two virtual hosts set up. This is the one that is running HTTPS. You can see here if we were to get rid of the S and just use HTTP, it would also work. Notice it's going to the same site, but now it's not encrypted. So what we want to do is go into the etc/apache2 folder, sites-available, and we want to edit the non-SSL site. Because again, SSL is working fine. We just want the non-SSL or just the HTTP site to redirect.

1:38So let's edit that one. And all we're going to do is add a single entry into this document. So we have it all set up. That's the document root, server name, but now we're going to just say redirect forward slash, meaning the entire site, and then where we want it to go, https://coolsite/. And we have to make sure we put the slash at the end so it knows to redirect it to that folder on that site. All right, so this is a redirect. That's all there is. There's no crazy modules or regular expressions we have to do, just that one single line.

2:14We'll restart the service. And now if we come back over here, when we hit Refresh it should automatically send us to the secure site. So I'm just going to hit Refresh on the HTTP site, and boom, it actually took us there without any interaction on our part. So if I delete that again, I go to the regular site, and boom, it redirects us to HTTPS automatically. There's no message. There's nothing like that. It's just if you type it-- in fact, let's just type it in. Actually if we just type it in, it might search for it on Google instead.

2:46Oh no, it did good. So coolsite, and sure enough, boom, it went right to HTTPS. So if you have your sites up and you've fallen down a Google hole where you're trying to figure out mode_rewrite rules and how to set up an htaccess file in order to redirect to the HTTPS, just use this new one-liner method for redirecting to HTTPS. It's so simple. It's very reliable, so it's really difficult to mess up. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00WebDAV is a very powerful file server, but it's not one that's terribly common anymore because it uses the web server itself, meaning that your Apache web server is going to act as a file server. And so it has the same security concerns that a regular web server would have, you know, unencrypted traffic over port 80? So while there are some scenarios that WebDAV makes sense, for example, what if you only have access to the web server ports on a server? Generally, there are better and fully encrypted by default ways of accessing files that don't rely on WebDAV.

0:35But it is available, and it's really simple to set up. Now how it works, like I said, it uses just your web server. Normally, when you're browsing the web, you send a request to the web server, and then the web server will return an HTML file for your browser to show you. But with WebDAV, you actually have access to the file system that is specified. So it's not just like uploading a file to a web form where it's stored somewhere so only the server operator can get to it.

1:06Using WebDAV, you have direct access of writing and reading it from the server's file system. And again, just using the web server ports itself, it's a little bit strange how easy it is to access the server's file system using just the web browser ports themselves. I'm logged into my Linux workstation here. And I'm going to SSH over to a server on my network. So I'm going to go to the Ubuntu server on my network. And here we are on the Ubuntu server.

1:36Now Apache 2 is already installed. So I'm going to go over to et cetera, Apache 2, sites enabled. And in here, I'm going to have the default website. Now normally, you would make a virtual host for WebDAV. But we're just going to edit the default file for the entire web server. We go into the main virtual hosting here. I'm going to add a couple lines. First, I'm going to make an alias just so it's easier to read. I'm going to say, Alias /dav, and I want that to be /var/www/html/dav.

2:10And then Location /dav. And in this block of code, we're simply going to say, DAV On and close the location section. We'll save this. We do have to enable the WebDAV module by default. It's not going to be enabled. So sudo a2nmod dav_fs. It enabled the module so that it will work. Now we do need to create that folder. So I'm going to go into /var/www/html/.

2:41Inside here, there's just the index.html. So I'm going to say, sudo make directory dav, sudo chown www-data, meaning the web server. Make sure the web server owns this folder. And lastly, restart the server. All right. And that should be it. We should be able to connect to the WebDAV server on our Ubuntu server. So let's get out of the server so that we're here on our workstation. Let's open up a web browser. Make sure that the web server itself is running.

3:11All right. Our web server is running. So now let's just try to connect to WebDAV using Nautilus here. So I'm going to say, connect to server. I'm going to pick a WebDAV server. The server is Ubuntu, and the folder is /dav. Now, you can make this password protected using standard Apache 2 tools like htpasswd. And that's just all on the server side, just like you would password protect any other folder on your server. We did not do that.

3:42So this should be fully readable and writable without any authentication. So let's click Connect. And sure enough, here we are in this WebDAV folder called dav. And we can try and create a folder. So it's called untitled folder. If we come back over here, ssh ubuntu, ls /var/www/html/dav. And look at that. Untitled folder was created on the remote server. It's pretty scary how easy it is to connect to a remote folder just via a web server.

4:13Now it is important to know, this is not secure traffic. This is just port 80. So nothing is encrypted here. It's just sent over plain text over our network. But it's that easy to set up a WebDAV server on your network. Like I mentioned, there are security concerns when you're talking about WebDAV, especially because it's just a website. It uses port 80 by default. But you can secure it using SSL. And you can make it password-protected using htpasswd, just like you would any other folder on an Apache server. So it's possible to shore up the security concerns.

4:46Just know that they're there because by default WebDAV doesn't offer any security on your network. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00Whenever we're learning things in Linux, it does not matter if we're using CentOS or Debian, or usually I actually use Ubuntu which is a Debian derivative. It doesn't matter because Linux is just a collection of packages that are all doing the same thing like Apache. Apache is a piece of software that will run on CentOS or Debian, perfectly fine. Most of the time there aren't even drastic differences with how to configure them on the different operating systems. But with Apache, it is a little bit different. They have a different package name. There are a set of tools that do not exist in CentOS, which is a real bummer.

0:33And the configuration structure in CentOS is less robust, let's say, than in Debian or Ubuntu. So we're going to look at them. It's the same configuration changes that you make regardless of which distro you're using, but where to make those changes and how to put them in place can be a little confusing. Like I mentioned, the package names themselves even are a horse of a different color when it comes to the two operating systems. In CentOS it's going to be httpd. In Debian or Ubuntu it's going to be apache2.

1:06Their whole sites-available folder structure that we're used to using in a Debian-based or Ubuntu-based system just does not exist in CentOS. It's just a folder called conf.d that you create your own files, and there's no linking or anything like that using the a2ensite, a2dissite which makes symbolic links from sites-available into sites-enabled. None of that exists in CentOS. You just create files from scratch. And if you don't want them there, you move them out of the way.

1:38So let's look and see because, really, the syntax is the same. It's just a matter of where you put the things that makes a difference. Now I'm here in a CentOS 7 machine just on a terminal window. I'm in the folder etc/httpd which, in Debian, it's etc/apache2. But if we look in this folder, it's set up quite a bit different from a Debian-based distribution. We have the conf folder. Inside the conf folder are the systemwide preferences of httpd.conf. We normally don't edit this.

2:10This is normally just there. You can edit it. It doesn't hurt anything. In fact, this is the single configuration file that has a reference or that calls all of the configuration files in the other folders. So what happens? This is the one config file. And in here it says I also want you to read in everything in the conf.d folder that ends in dot conf and everything in the conf.modules.d folder that ends in dot conf as well. And so if you want to create a virtual file, you would go into conf.d.

2:41And inside here we have some sample things. These are some configuration things that have been created. And if we wanted to create a virtual host, we would just do something like coolsite.conf. And then in here is where we would put our virtual host directives and then all the things that we would put. We would save this. And then that is how we would activate it. There's no enable and disable. If it exists in this folder and it ends in dot conf, it's going to be read in when the system restarts.

3:17And then let's say that we had-- here, let me type ls so we can see it in here. Let's say that we've created this but we decided, you know what, I want to deactivate it but I don't want to erase it because I want to go back to it. In Debian we would just get rid of that symbolic link, but what we can do here is we could move it. We could say move coolsite to coolsite.conf.disabled. And then since it doesn't end in conf, it's not going to be read in. So this is kind of like how you do the disable and enable thing inside a CentOS system is you just make sure that the extension at the end of the file is not dot conf that it will not be read in.

3:58So this is just as good as if we remove that symbolic link in a Debian system. And the same thing when you're doing modules. You could put them in here, but generally-- let's get out of here. Inside the conf.modules.d folder we have modules that have been added. For example, here's the dav module. They've enabled WebDAV on this server. And so this exists in here, and this is where you would make that configuration. And if you wanted to disable it, we would just move it. We would say move 00.dav to 00.dav.disabled, or we could just move it to dot disabled, and then it would end in disabled so it wouldn't be read in.

4:43It doesn't matter what you use. You could just say dis or off or whatever you want as long as the extension is not dot conf. And that's really the biggest difference between a Debian-based Apache install and a CentOS-based Apache install. But once you get it and you know that the only thing is the configuration directory being different and how it's structured, it's not difficult to go from one to another. But that initial installation package name, knowing that you don't have those nice tools for enabling and disabling sites and modules and things like that, it can be a little daunting at first.

5:16But just know, the same syntax that you learned using Debian work perfectly fine in CentOS. It's just slightly more difficult and more complex to get them working inside a CentOS system. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00Reverse proxies are a way that Apache can act like a middleman from one server to another. A really common way to utilize a reverse proxy is to give a front end to an internal server, or you may have a server that's behind a firewall you don't want to expose directly to the internet, but you want to be able to access it from the outside. And it looks kind of like this. You'll have a reverse proxy server right here, and you'll have these servers inside your firewall. This is exposed to the internet right here, but these are internal.

0:31Now the reverse proxy can get to them. So it's might be a server1, an intranet server. And what happens is it maps virtual hosts through Apache, and it actually acts like this server is exposed over here to the web. So let's say we have an app server that we want to have access from the outside. Well, internally it might be running at app:8080, on a different port even. A lot of times apps are running on ports other than port 80. So this is running on port 8080, and we want to be able to access it directly from a web address not using a special port, and we want to access it from the other side of the server.

1:11So what we can do is set up a reverse proxy that the end user only ever accesses the reverse-proxy machine, but behind the scenes it's making a connection back and forth so the internal app server is as if it were being accessed from this front-facing not port 8080 but just under a standard web port so you don't to put that colon 8080 at the end. Anyway, that's how it works. Setting it up is remarkably easy. It's just another virtual host. So that's what we're going to do is set up a reverse proxy with a virtual host.

1:45Now on our server here I have accessed this server called appserver port 8080. And all this is it's just an example or a sample thing. There's like a button on it. We can see this is what it looks like. But to get to it, you have to go to the appserver URL port 8080, and that's how we need to get to it. I want to be able to access it using just a virtual host on this computer. So inside apache2, we'll see this is just what we have here. I'm going to go into our sites-available folder, and inside here we have coolsite and coolsite-ssl.

2:19Now these are two virtual hosts. Both of them are working. But this coolsite.com file automatically redirects us to SSL. So we've done that in a previous Nugget. So I'm actually going to change this SSL virtual host and have it act as a reverse proxy to get to this app server in the background. So let's edit that file. And inside here we're not going to change much here other than we no longer have to have this DocumentRoot because it's not actually going to be serving out files anymore.

2:49It's going to be redirecting traffic using the reverse-proxy feature. So we need to configure this virtual host to use a proxy server. Now the first thing I want to do is say ProxyPreserveHost, and I want to turn that to on. And what that's going to do is when it's communicating back and forth, it's going to keep the external host so that we'd never know the internal address of appserver port 8080. We're not going to know that at all. It's going to preserve the outside host. So for us, it's going to just show coolsite.

3:21Now we need to have two proxy pass directives, so ProxyPass, and we want to pass a forward slash to http://appserver port 8080 forward slash, and we want to do ProxyPassReverse forward slash http://appserver port 8080 forward slash. What this does is not only does it allow traffic to go one way from the server to our end user, but also traffic can go back and forth.

3:55And this will pass it both ways going back and forth. So we're preserving the hostname, ProxyPass, ProxyPassReverse, and this is it. So now instead of serving out web pages, this is going to redirect people internally to this appserver back here. So let's save this. Now this is a feature that uses a module. It uses the mod proxy. So we need to actually enable that. So I'm going to say a2nmod proxy, and I'm going to say a2nmod proxy_http. So those are both enabled.

4:26Now we need to do service apache2 restart, and now let's restart it. So now this is still going to work, obviously. This is still our appserver. But if we open a new tab and now we go to coolsite, it should do two things. It should go to the SSL site, and that SSL site should actually be the app in the background. So let's hit Enter, and sure enough, there we see My Awesome App that we have over here is now going through SSL, and it's actually showed right here on this website without a special port.

4:59It's actually using a reverse proxy. So not only are reverse proxies really easy to set up but they're very, very convenient because let's say you have a bunch of web servers on your local network and you want to serve them all out through your one single IP address. You can use a reverse proxy to point to a bunch of different apps or servers inside your network. I hope this has been informative for you, and I'd like to thank you for viewing.