Google provide Wordpress Launcher although in beta. I have try them by adding custom domain via Google Cloud DNS, but i still not success in adding custom domain with SSL (https).
Any Idea ?
Wordpress from Google Click to Deploy launches on Google Compute Engine, not Google App Engine, meaning you are getting an entire Debian virtual machine, not just an App Engine instance. The App Engine instructions are not applicable.
Here's the process I used (replace "www.veggie.com" with your domain):
Go to Deployment Manager and select your Wordpress deployment.
Under "Get Started with WordPress", click "SSH" to open a Google Cloud Shell console on the Debian virtual machine hosting your site.
If you haven't already, generate a CSR using openssl req -new -newkey rsa:2048 -nodes -keyout www_veggie_com.key -out www_veggie_com.csr. More info
You will be prompted with some questions. Answer them using letters and numbers only. For example:
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:New Mexico
Locality Name (eg, city) []:Albuquerque
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Veggie Inc # put "NA" if not applicable
Organizational Unit Name (eg, section) []:NA # put "NA" if not applicable
Common Name (e.g. server FQDN or YOUR name) []:www.veggie.com # MUST BE the website you are securing. Use *.veggie.com if you purchased a wildcard certificate
Email Address []:webmaster#veggie.com
A challenge password []: # just leave this blank
An optional company name []: # leave this blank too
Move the private key to a safe place, e.g. sudo mv www_veggie_com.key /etc/ssl/ssl.key/
View the CSR (Certificate Signing Request) file using cat www_veggie_com.csr. It should look something like this:
-----BEGIN CERTIFICATE REQUEST-----
sdkfjhksdjfhkjsdvbksdjfkhsdkfhskdjfhskjdfhksdjfhkdsjvbnksjksjkjh
2398dfjk3290fdsjk3290slk093koldfj3j0igr0/4387yvdjkn4398fdh92439h
sdkfjhksdjfhkjsdvbksdjfkhsdkfhskdjfhskjdfhksdjfhkdsjvbnksjksjkjh
2398dfjk3290fdsjk3290slk093koldfj3j0igr0/4387yvdjkn4398fdh92439h
sdkfjhksdjfhkjsdvbksdjfkhsdkfhskdjfhskjdfhksdjfhkdsjvbnksjksjkjh
2398dfjk3290fdsjk3290slk093koldfj3j0igr0/4387yvdjkn4398fdh92439h
sdkfjhksdjfhkjsdvbksdjfkhsdkfhskdjfhskjdfhksdjfhkdsjvbnksjksjkjh
2398dfjk3290fdsjk3290slk093koldfj3j0igr0/4387yvdjkn4398fdh92439h
sdkfjhksdjfhkjsdvbksdjfkhsdkfhskdjfhskjdfhksdjfhkdsjvbnksjksjkjh
2398dfjk3290fdsjk3290slk093koldfj3j0igr0/4387yvdjkn4398fdh92439h
sdkfjhksdjfhkjsdvbksdjfkhsdkfhskdjfhskjdfhksdjfhkdsjvbnksjksjkjh
2398dfjk3290fdsjk3290slk093koldfj3j0igr0/4387yvdjkn4398fdh92439h
sdkfjhksdjfhkjsdvbksdjfkhsdkfhskdjfhskjdfhksdjfhkdsjvbnksjksjkjh
sdkfjhksdjfhkjsdvbksdjfkhsdkfhskdjfhskjdfhksdjfhkdsjvbnksjksjkjh
2398dfjk3290fdsjk3290slk093koldfj3j0igr0/4387yvdjkn4398fdh92439h
3fjkbdjgkedkj4vie929ckw0gfjdfgjs90q=
-----END CERTIFICATE REQUEST-----
Copy the contents of the CSR file to your clipboard (in Google Cloud Shell, just highlight the text with your mouse and hit Ctrl+C).
Go to the site where you purchased the certificate and find the option to Activate the certificate. You should be prompted to upload or copy and paste the CSR. If you are prompted to confirm the server type, it is an Apache server. After I did that, my certificate issuer sent me the certificates via email.
Once you have your certificates, return to the Google Cloud Shell.
Use the gear menu > Upload File to upload your SSL certificates to your server. I put the certificates in /etc/ssl/ssl.crt/.
Enter sudo nano /etc/apache2/sites-available/wordpress.conf to use Nano to edit your server's configuration file to point to your certificate(s) and your key file. My wordpress.conf only had a <VirtualHost *:80> section, so I added a <VirtualHost *:443> section at the bottom:
<VirtualHost *:443>
ServerAdmin webmaster#veggie.com
ServerName www.veggie.com:443
DocumentRoot /var/www/html
# Copy <Directory /> and other settings from <VirtualHost *:80> here as well
SSLEngine on
SSLCertificateFile /etc/ssl/ssl.crt/www_veggie_com.crt
SSLCertificateKeyFile /etc/ssl/ssl.key/www_veggie_com.key
SSLCertificateChainFile /etc/ssl/ssl.crt/www_veggie_com.ca-bundle
</VirtualHost>
Restart the Apache server using sudo service apache2 restart
Try visiting your homepage via https (e.g. https://www.veggie.com) and see if it worked.
This is bit of a complicated process. Despite Googles efforts to https the whole internet and the fact that every App Engine app gets a secure appspot.com-subdomain, adding your own domain with your own certificate is bit complicated.
The process is documented here
1. SSH into the server
SSH into the server running your HTTP website as a user with sudo privileges.
2. Install snapd
You'll need to install snapd and make sure you follow any instructions to enable classic snap support.
Follow these instructions on snapcraft's site to install snapd.
https://snapcraft.io/docs/installing-snap-on-debian
3. Ensure that your version of snapd is up to date
Execute the following instructions on the command line on the machine to ensure that you have the latest version of snapd.
sudo snap install core; sudo snap refresh core
4. Remove certbot-auto and any Certbot OS packages
If you have any Certbot packages installed using an OS package manager like apt, dnf, or yum, you should remove them before installing the Certbot snap to ensure that when you run the command certbot the snap is used rather than the installation from your OS package manager. The exact command to do this depends on your OS, but common examples are sudo apt-get remove certbot, sudo dnf remove certbot, or sudo yum remove certbot.
If you previously used Certbot through the certbot-auto script, you should also remove its installation by following the instructions here.
5. Install Certbot
Run this command on the command line on the machine to install Certbot.
sudo snap install --classic certbot
6. Prepare the Certbot command
Execute the following instruction on the command line on the machine to ensure that the certbot command can be run.
sudo ln -s /snap/bin/certbot /usr/bin/certbot
7. Choose how you'd like to run Certbot
Either get and install your certificates...
Run this command to get a certificate and have Certbot edit your Apache configuration automatically to serve it, turning on HTTPS access in a single step.
sudo certbot --apache
Or, just get a certificate
If you're feeling more conservative and would like to make the changes to your Apache configuration by hand, run this command.
sudo certbot certonly --apache
8. Test automatic renewal
The Certbot packages on your system come with a cron job or systemd timer that will renew your certificates automatically before they expire. You will not need to run Certbot again, unless you change your configuration.
You can test automatic renewal for your certificates by running this command:
sudo certbot renew --dry-run
If that command completes without errors, your certificates will renew automatically in the background.
9. Confirm that Certbot worked
To confirm that your site is set up properly, visit https://yourwebsite.com/ in your browser and look for the lock icon in the URL bar.
Source:
https://certbot.eff.org/lets-encrypt/debianstretch-apache
Here's the steps I used for free SSL certificate on wordpress VM launched in google cloud.
Make sure "Allow http" and "Allow https" are selected in vm settings and also overall firewall rules for the your project has 443/80 rules (which are there by default).
Enabling Free SSL Certificate :
Change the domain name below from my-domain.com to required domain name.
Step 1 :
wget https://dl.eff.org/certbot-auto && chmod a+x certbot-auto
sudo ./certbot-auto certonly --webroot -w /var/www/html/ -d my-domain.com -d www.my-domain.com
Step 2:
sudo vi /etc/apache2/sites-available/default-ssl.conf
Add following after ServerAdmin
<Directory /var/www/html/>
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
allow from all
</Directory>
At the end of file
Comment out two SnakeOil Certs lines and add below.
SSLCertificateFile "/etc/letsencrypt/live/my-domain.com/cert.pem"
SSLCertificateKeyFile "/etc/letsencrypt/live/my-domain.com/privkey.pem"
SSLCertificateChainFile "/etc/letsencrypt/live/my-domain.com/chain.pem"
Step 3 :
sudo vi /etc/apache2/sites-available/wordpress.conf
Remove all 3 lines
Add below lines
<VirtualHost *:80>
ServerAdmin webmaster#localhost
DocumentRoot /var/www/html
ServerName www.my-domain.com
ServerAlias my-domain.com
Redirect permanent / https://www.my-domain.com/
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
<Directory /var/www/html/>
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
allow from all
</Directory>
ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
<Directory "/usr/lib/cgi-bin">
AllowOverride None
Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
Order allow,deny
Allow from all
</Directory>
ErrorLog ${APACHE_LOG_DIR}/error.log
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel warn
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
Step 4 :
Restart apache
sudo a2ensite default-ssl
sudo a2enmod ssl
sudo service apache2 restart
Step 5 (Optional) :
Enable auto renewal for cert :
sudo mv certbot-auto /etc/letsencrypt/
sudo crontab -e
Add following at the end
45 2 * * 6 cd /etc/letsencrypt/ && ./certbot-auto renew && /etc/init.d/apache2 restart
Step 6 :
Test https version is working in browser.
Only after making sure that https is working :
Go to WP-Admin :
Settings > General > change site url and host url to https://my-domain.com
Note : Any error in typing wrong url in step 6, you can loose web access to wordpress. After that, you have to follow other steps to gain the access back through ssh.
Hope this helps.
I'm trying out Phoenix and for reasons beyond my control, I need it to be served through apache2.
There's a guide for serving Phoenix behind a proxy webserver but it only gives an example configuration for nginx (which I would be using if I could).
So I went to the documentation for mod_proxy and added these two lines to my VirtualHost:
<VirtualHost *:443>
...
LoadModule proxy_module modules/mod_proxy.so
ProxyPass /back http://www.example.com:4000 timeout=10
...
</VirtualHost>
I have the default Phoenix app running in development mode on port 4000. I tried going to https://example.com/back and the result is
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
I've checked my logs at /var/log/apache2/error.log and there is no error message corresponding to GET /back, although there IS a corresponding entry in access.log. All of the other things I'm serving are still working fine. I'm at a loss here, any pointers?
The problem was twofold.
Firstly, proxy submodules needed to be enabled.
sudo a2enmod proxy_http && sudo service apache2 restart
What led me to this fix was enabling a higher log level in apache2.conf:
LogLevel debug proxy:trace4
The relevant error was AH01144 (list of apache2 errors).
Secondly, I needed a reverse proxy:
<VirtualHost *:443>
...
ProxyPass /back http://www.example.com:4000 timeout=10
ProxyPassReverse /back http://www.example.com:4000 timeout=10
...
</VirtualHost>
I have been using an Ubuntu machine for my development environment for years and am attempting to migrate to OSX (Mountain Lion). The only hiccup at this point is the apache2 configuration.
On the Ubuntu machine "apache2 -v" reveals
Server version: Apache/2.2.22 (Ubuntu)
Server built: Nov 8 2012 21:37:30
On the OSX machine "httpd -v" reveals
Server version: Apache/2.2.22 (Unix)
Server built: Aug 24 2012 17:16:58
So you can imagine that I'm thoroughly confused as to why the virtual host config isn't migrating well.
The following ProxyPass and Alias bits of my VirtualHost config work very well when used on my first apache2 instance but not on the second. The directory structures on both machines
For all intents and purposes, the virtual host config is as follows
NameVirtualHost *:80
<VirtualHost *:80>
ProxyPass /img !
Alias /img /somedir/media/img
ProxyPreserveHost On
ProxyPass / http://127.0.0.1:8080/
ProxyPassReverse / http://127.0.0.1:8080/
</VirtualHost>
with the goal being that apache will serve all images and the app server at port 8080 doing the heavy lifting (common pattern).
In Ubuntu this works great. On the macbook, the images aren't being served up.
Verify that the proxy module is being loaded. This would either be done with a dynamic load config line in the conf file:
LoadModule proxy_http_module modules/mod_proxy_http.so
Or compiled into Apache:
./httpd -l | grep proxy
mod_proxy.c
mod_proxy_connect.c
mod_proxy_ftp.c
mod_proxy_http.c
mod_proxy_scgi.c
mod_proxy_ajp.c
mod_proxy_balancer.c
You can likely pull the mod_proxy_http.so from the other server.
Turns out the default apache config defined a very restrictive default site configuration. Commenting that out and restarting the server cleaned things up nicely.
I'm installing Reviewboard on linux, I have copied the config provided by the install package to httpd.conf
<VirtualHost *:80>
ServerName localhost
DocumentRoot "/usr/www/reviewboard/htdocs"
# Error handlers
ErrorDocument 500 /errordocs/500.html
WSGIPassAuthorization On
WSGIScriptAlias "/reviewboard" "/usr/www/reviewboard/htdocs/reviewboard.wsgi/reviewboard"
<Directory "/usr/www/reviewboard/htdocs">
AllowOverride All
Options -Indexes FollowSymLinks
Allow from all
</Directory>
# Alias static media requests to filesystem
Alias /reviewboard/media "/usr/www/reviewboard/htdocs/media"
Alias /reviewboard/errordocs "/usr/www/reviewboard/htdocs/errordocs"
Alias /reviewboard/favicon.ico "/usr/www/reviewboard/htdocs/media/rbcommons/images/favicon.png"
</VirtualHost>
However, when I access "http://SITE/reviewboard/htdocs/reviewboard.wsgi", it just gives me the file in plain text instead of running the script
I have checked the mod_wsgi is running on apache2 by "apache2ctl -t -D DUMP_MODULES"
Did I miss any other configuration?
You should be using the URL:
http://SITE/reviewboard
and the WSGIScriptAlias directive should be:
WSGIScriptAlias "/reviewboard" "/usr/www/reviewboard/htdocs/reviewboard.wsgi"
Do be aware though that it is bad practice to be putting your whole Django site under DocumentRoot. That you are seeing the source code for the WSGI script file highlights why it is bad. That is, have an issue with your Apache configuration and you could expose all your source code for people to download. Especially bad if settings.py is in there and it contains database passwords.
Now, address those issues and update question with what you then have and what next problem is as I don't expect that to completely solve the problem because with those mistakes you should have got a different problem than what you describe, so suspect that your configuration is not even being used.
I've got an apache web server (without mod_perl) that's been running just fine for a long time.
It has been suggested that we use mod_perl to improve the performance of some scripts.
I want to go ahead and install mod_perl on the server, which seems to be a relatively straightforward process, but I'm confused by some of the stuff coming up on Google searches.
If I install mod_perl (through the debian repositories), will all of my existing CGIs suddenly start "using mod_perl" and exhibiting potentially wonky behavior?
Or is there some configuration in apache that needs to be done for an old CGI to "start using mod_perl"?
Apologies if this is a straightforward answer but I am confused by the terminology being used in multiple ways in the documentation.
mod_perl has to be configured in your httpd.conf to be enabled. So not every script on your server will start to use mod_perl automatically.
Usually, you enable mod_perl per VHost. A usual configuration of mod_perl for a vhost looks like this:
<VirtualHost some.funny-domain.com>
ServerName some.funny-domain.com
ServerAdmin admin#funny-domain.com
DocumentRoot /data/path/to/root/
Perlrequire /data/path/to/startup.pl
PerlModule Apache2::Reload
PerlInitHandler Apache2::Reload
PerlModule Apache2::RequestRec
ScriptAlias /cgi-bin/ "/data/path/to/root/cgi-bin/"
<Location /cgi-bin/>
SetHandler perl-script
PerlResponseHandler ModPerl::Registry
PerlOptions +ParseHeaders
PerlOptions +SetupEnv
Options +ExecCGI
</Location>
CustomLog logs/access.log combined
ErrorLog logs/error.log
</VirtualHost>
Be carefull with the automated install-process! It may enable mod_perl on the wrong host for some reason! BackUp your config and apache-installation first to be able to "roll back" easily.
Comment: The line "Perlrequire /data/path/to/startup.pl" is not required. It is optional and sets some environment variables for the running scripts under the mod_perl env.