I was faced with this issue. But I didn't like the idea of changing the group of my home directory to www-data. This problem can simply be solved by modifying the configuration file for the virtualHost.Simply configure the Directory tag to include these
Here's another answer intending to add a simpler explanation. Let's say you want to serve a file named "main" which is in the /var/www/testwebsite directory(the DocumentRoot of an already configured & enabled virtual host). Now assume we want the Apache web server to only have access to the "main" file and not other files(e.g. main might be an entry point to our web app), then it means that the apache web server has to be the owner of that file. so chown www-data:www-data /var/www/testwebsite/main must do it. (notice: www-data is both the name of the user and the name of the group that apache uses when interacting with other files(actually, on distributions other than Ubuntu, this might be a different name, in which case it can simply be looked up in the apache2.conf as well)). Also in case the "main" file doesn't have the permission to be read/executed, it must be granted to the apache's user and group: chmod 770 /var/www/testwebsite/main. This gives the user(www-data) and the group(www-data) who are owners of the file "main" these permissions: read/write/execute(4+2+1=7), and gives other users no permissions. Now that single file(main) can be run by the Apache while we can have any other strict level of restriction on all other files in the /var/www/testwebsite directory.
Supermarket belongs to the community. While Chef has the responsibility to keep it running and be stewards of its functionality, what it does and how it works is driven by the community. The chef/supermarket repository will continue to be where development of the Supermarket application takes place. Come be part of shaping the direction of Supermarket by opening issues and pull requests or by joining us on the Chef Mailing List.
This cookbook provides a complete Debian/Ubuntu style Apache HTTPD configuration. Non-Debian based distributions such as Red Hat/CentOS, ArchLinux and others supported by this cookbook will have a configuration that mimics Debian/Ubuntu style as it is easier to manage with Chef.
Depending on your OS configuration and security policy, you may need additional recipes or cookbooks for this cookbook's recipes to converge on the node. In particular, the following Operating System settings may affect the behavior of this cookbook:
On RHEL, SELinux is enabled by default. The selinux cookbook contains a permissive recipe that can be used to set SELinux to "Permissive" state. Otherwise, additional recipes need to be created by the user to address SELinux permissions.
To deal with firewalls Chef Software does provide an iptables and ufw cookbook but is migrating from the approach used there to a more robust solution utilizing the general firewall cookbook to setup rules. See those cookbooks' READMEs for documentation.
On ArchLinux, if you are using the apache2::mod_auth_openid recipe, you also need the pacman cookbook for the pacman_aur LWRP. Put recipe[pacman] on the node's expanded run list (on the node or in a role). This is not an explicit dependency because it is only required for this single recipe and platform; the pacman default recipe performs pacman -Sy to keep pacman's package cache updated.
It is recommended to create a project or organization specific wrapper cookbook and add the desired custom resources to the run list of a node. Depending on your environment, you may have multiple roles that use different recipes from this cookbook. Adjust any attributes as desired.
By default, Apache comes with a basic site (the one that we saw in the previous step) enabled. We can modify its content in /var/www/html or settings by editing its Virtual Host file found in /etc/apache2/sites-enabled/000-default.conf.
I am having some wierd issues with Apache2 server on my ubuntu server. I believe some configuration files may have been tampered with. What is the easiest way to remove apache2 completely from my server. I am aware of how to install by using
I installed certbot in debian buster.
I am using as server apache2. When I required the first time my certificate I used the standalone method, using my own web server (apache2) and setting up the webroot served by apache.
I think the best option is, when the certificate must be renewd to stop apache2, use certbot with his own server (so all domains point to the same webroot), then restart apache2.
How edit the configuration of certbot to do this?
--webroot is still the best option.
You could manually edit each of the renewal.conf files (tedious).
Or simply renew each cert with the appropriate --webroot via --dry-run
Which should update the renewal.conf for you.
Because if I could execute the standalone server by certbot I don't have to worry about the configuration of virtual servers in apache2.
But if i don't kill apache2 the port 80 isn't free to be used.
I set set some rewrite rules, www.mydomain.one and cloud.mydomain.one redirict to mydomain.one.
dyn.mydomain.one doesn't redirict.
mydomain.one and dyn.mydomain.one has 2 different webroot. So whent I renew the certificate I think certbot will check all domains.
If you are going to shutdown the web service, you should run two web servers:
One for HTTP on port 80 (which only redirects everything to HTTPS)
One for HTTPS.
Then you can shutdown the one doing HTTP to run certonly in standalone mode.
[and only reload the HTTPS server whenever a new cert is issued]
Ok thank you very much, but I red it and I am still confused
So a
certbot renew --dry-run --pre-hook "service apache2 stop" --post-hook "service apache2 start"
Should not solve my problems becase my config file is not edited.
[sudo] password for kay: Reading package lists... Done Buildingdependency tree... Done Reading state information... Doneapache2-utils is already the newest version (2.4.52-1ubuntu4.4). Thefollowing packages were automatically installed and are no longerrequired: libllvm13 libllvm13:i386 libvulkan1:i386libxcb-randr0:i386 mesa-vulkan-drivers:i386 Use 'sudo apt autoremove'to remove them. 0 to upgrade, 0 to newly install, 0 to remove and 12not to upgrade. 1 not fully installed or removed. Need to get 0 B/89.5kB of archives. After this operation, 0 B of additional disk spacewill be used. Do you want to continue? [Y/n] Y dpkg: error processingpackage apache2-utils (--configure): package is in a very badinconsistent state; you should reinstall it before attemptingconfiguration Errors were encountered while processing: apache2-utilsE: Sub-process /usr/bin/dpkg returned an error code (1)
I have successfully built my mutipage Dash app with the app.py-pages folder structure. In the pages folder, I have multiple pages. Then I created an AWS EC2 instance, started an apache2 server on Ubuntu, and ran a gunicorn server and the page can be accessed from the browser. The dash app consists of many pages with datatables that pull data from a RDS MySQL instance and is supposed to show those data in the datatables. The app works perfectly in the local environment. Also, the connection between the EC2 and the RDS is set up correctly and the EC2 can retrieve data from the database successfully and pretty quickly.
Yosemite no longer has Personal Web Sharing as an option. Although the Apache 2 web server is still supplied by Apple as part of the Yosemite distribution, there is no "easy" way to turn it on (or off). So, if you managed to turn it on, you already know how to turn it off!
By default the Apache 'prefork' MPM is compiled-in. You can list compiled-in modules with command httpd -l. If you require the 'worker' or 'event' MPM, use option +workermpm or +eventmpm appended to your install command. If you inadvertently installed the default Apache, simply running the installer command with the optional suffix will overwrite the existing Apache.
A sample configuration file is provided in /opt/local/etc/apache2/original/httpd.conf. Don't edit this file; leave it as is so you can refer to the defaults later. The first time you install apache2, the sample configuration file will be copied to /opt/local/etc/apache2/httpd.conf for you. You can edit this file as desired. When you later upgrade apache2 to a newer version, MacPorts will upgrade the sample configuration file but will not modify your httpd.conf, so be sure to manually compare your httpd.conf with the new sample configuration file and bring over any relevant changes. You should also keep backup copies of your httpd.conf in a safe place.
However under OSX, the purpose of launchd is to notice processes that stop without its knowledge, and to restart them. So if you use apachectl -k restart, launchd may notice apache "crashing" and restart it itself, confusing apachectl. Instead, you shoulduse "port" to tell launchctl to unload apache2, then load it again. This will result in a short interruption of service.
Where refers to the name of your computer as specified in the System Preferences Sharing pane. To resolve the warning, edit the configuration file and set the server name appropriately. For personal use, localhost is sufficient.
NOTE: The setting of "ServerName" to anything other than the Fully Qualified Domain Name (FQDN) of the server under Apache 2.2.x and Yosemite, does not produce the expected results.Using the links above to "localhost" will fail with Safari complaining "Failed to open page. Safari can't open the page "localhost" because Safari can't connect to the server "localhost". The simple answer is "localhost" is an "old-tyme" shortcut which should still work, but often does not for many different reasons. The "Fix" is to simply use the FQDN of your server when testing Apache or related Web services.
The following instructions are to generate a "self-signed" certificate.
This is simply a shortcut for testing purposes (a self-signed certificate is not recommended for production!).
The complete dialog is listed here for reference. The commands necessary are prefixed as "$ sudo", with comments prefixed with a #.