Can't access wordpress after virtualmin install

11 posts / 0 new
Topic locked
Last post
#1 Wed, 11/12/2014 - 23:36
eduardoeltortuga

Can't access wordpress after virtualmin install

Can't access wordpress after virtualmin install. Local install on ubuntu server 14.04. I had wordpress working. now I am unable to access. Been reinstalling ubuntu many times trying to narrow where the problem occurs. Seems to be after i install virtualmin. Will somebody point me in the right configuration please and thank you

Eddie

Thu, 11/13/2014 - 00:39
andreychek

Howdy,

What happens when trying to access your WordPress install? Are you receiving an error? Do you see another site?

-Eric

Thu, 11/13/2014 - 08:28 (Reply to #2)
eduardoeltortuga

I had WordPress installed and working. Then I installed Webmin and WordPress still worked. Then I installed Virtualmin I got the WSOD. The page source is this:

<?php /** * Front to the WordPress application. This file doesn't do anything, but loads * wp-blog-header.php which does and tells WordPress to load the theme. * * @package WordPress */

/** * Tells WordPress to load the WordPress theme and output it. * * @var bool */ define('WP_USE_THEMES', true);

/** Loads the WordPress Environment and Template */ require( dirname( FILE ) . '/wp-blog-header.php' );

I have been struggling with this for a couple of weeks trying different scenarios. I think Virtualmin is changing something but I don't know exactly what.

Thanks -Eddie

Thu, 11/13/2014 - 12:00
Joe
Joe's picture

How was Wordpress installed? i.e. is it in a central /var/www or similar location, or is it inside of a virtual host directory, like /home/domainname/public_html? If the former, Virtualmin would likely cause it to be unusable, because Virtualmin sets up suexec and a number of other configuration details intended for virtual hosting; an install into /var/www or similar is incompatible with a virtual hosting configuration for a number of reasons.

If this is the case, you would see errors about this in the /var/log/apache/suexec.log or similar.

In a virtual hosting environment, you'd want to have your WordPress installed into the home directory of site in question (generally speaking), which allows suexec to operate (files need to be owned by the user and have relatively strict permissions in order to run under suexec). It's possible to have sites that are not setup to use a centrally installed application by disabling suexec for the domain, but I wouldn't recommend it, for security reasons.

Similarly, if your permissions were too loose, even if all other things were right (i.e. wordpress is installed in a home directory for site in question), suexec would refuse to run things.

If none of that is the case, we'll need more information. But, suexec is the first thing that comes to mind when I try to reason out why something would work before and not after Virtualmin is installed.

--

Check out the forum guidelines!

Thu, 11/13/2014 - 12:08 (Reply to #4)
eduardoeltortuga

That is great information! WordPress is installed in /var/www/html. I will do some more experimenting. I learned a lot from your info. Give me a couple of days and I will get back to you.

Thanks

-eduardo el tortuga

Thu, 11/13/2014 - 12:27
andreychek

Howdy,

Virtualmin configures Apache to use the directories in /home for serving websites.

My suggestion would be that once you install Virtualmin, what you can do is go into it, create a new Virtual Server, and then place your WordPress installation into the public_html directory in that Virtual Server.

That would be something like "/home/USERNAME/public_html".

Also, when doing that, any Apache logs for that domain would be located in $HOME/logs/ -- so you can review the error_log in the logs directly for information regarding WordPress if you receive any errors or problems once you've set it up there.

-Eric

Thu, 11/13/2014 - 13:10
eduardoeltortuga

Thanks to Joe and Eric. You both led me in the right direction. I works even better than before.

Have a great day!

eduardo el tortuga

Wed, 11/19/2014 - 09:37 (Reply to #7)
cvlk

Please let me know what you did, exactly, to make yours work. I have been fretting over this for days! I cannot seem to figure this out. I relocated all the wordpress files from the /var/html/www/ directory to my virtual server directory at /home/user/public_html. I can now access Wordpress via https! :)

I now seem to be having problems with mysql. I do not seem to have access to anything mysql now (terminal), even the root user. I used this in the terminal [ sudo ln -s /home/user/public_html /var/www ] to make the IP address target the user html folder instead of the systemwide www folder.

Thank you for your time! Anyone else care to chime in? Thanks!

Wed, 11/19/2014 - 12:13
eduardoeltortuga

Repairing a MySQL Database with phpMyAdmin: http://php.about.com/od/mysqladministration/qt/repair_mysql.htm

I have a domain name with freedns, "http://freedns.afraid.org/", and it points to my virtual host on my virtual server.

I'm really not that knowledgeable Hope this helps.

Wed, 11/19/2014 - 13:48 (Reply to #9)
cvlk

Thanks for your time!

Tue, 06/06/2017 - 18:51
Virtual-help

I noticed that a few apache configuration files had been changed. So, I compared the changed files with backup files, replaced the changes with the backup content, and uninstalled Virtualmin.

These are the files and some of the content.

vi /etc/httpd/conf.d/php.conf

Remove comment from "SetHandler application/x-httpd-php" Lines 4 - 6 look like:

SetHandler application/x-httpd-php

vi /etc/httpd/conf.d/conf.d/userdir.conf

Add "UserDir disabled" Should look like:

# # UserDir is disabled by default since it can confirm the presence # of a username on the system (depending on home directory # permissions). # UserDir disabled

  #
  # To enable requests to /~user/ to serve the user's public_html
  # directory, remove the "UserDir disabled" line above, and uncomment
  # the following line instead:
  #
  #UserDir public_html

vi /etc/httpd/conf.d/welcome.conf

# # This configuration file enables the default "Welcome" page if there # is no default index page present for the root URL. To disable the # Welcome page, comment out all the lines below. # # NOTE: if this file is removed, it will be restored on upgrades. # Options -Indexes ErrorDocument 403 /.noindex.html

AllowOverride None Require all granted

Alias /.noindex.html /usr/share/httpd/noindex/index.html Alias /noindex/css/bootstrap.min.css /usr/share/httpd/noindex/css/bootstrap.min.css Alias /noindex/css/open-sans.css /usr/share/httpd/noindex/css/open-sans.css Alias /images/apache_pb.gif /usr/share/httpd/noindex/images/apache_pb.gif Alias /images/poweredby.png /usr/share/httpd/noindex/images/poweredby.png

NOTE: The websites did not work until I changed this file mv /etc/httpd/conf.d/awstats.conf.rpmsave /etc/httpd/conf.d/awstats.conf

vi /etc/httpd/conf.d/awstats.conf

#

Content of this file, with correct values, can be automatically added to your Apache server by using the AWStats configure.pl tool.

#

If using Windows and Perl ActiveStat, this is to enable Perl script as CGI. ScriptInterpreterSource registry

#

Directives to add to your Apache conf file to allow use of AWStats as a CGI. Note that path "/usr/share/awstats/" must reflect your AWStats install path.

# Alias /awstatsclasses "/usr/share/awstats/wwwroot/classes/" Alias /awstatscss "/usr/share/awstats/wwwroot/css/" Alias /awstatsicons "/usr/share/awstats/wwwroot/icon/" ScriptAlias /awstats/ "/usr/share/awstats/wwwroot/cgi-bin/"

#

This is to permit URL access to scripts/files in AWStats directory.

# Options None AllowOverride None # Apache 2.2 Order allow,deny Allow from 127.0.0.1 Allow from ::1

Additional Perl modules

SetEnv PERL5LIB /usr/share/awstats/lib:/usr/share/awstats/plugins

vi /etc/httpd/conf/httpd.conf

I removed these lines that are located at the bottom of /etc/httpd/conf/httpd.conf. I have "IncludeOptional conf.d/*.conf" without the quotes in the file and use other configuration files for SSLProtocol and SSLCipherSuite.

SSLProtocol ALL -SSLv2 SSLCipherSuite HIGH:!SSLv2:!ADH:!aNULL:!eNULL:!NULL ServerTokens Minimal ServerSignature Off TraceEnable Off

Comments: SSLProtocol and SSLCipherSuite. I use different configurations in other files.

ServerTokens - Setting ServerTokens to less than minimal is not recommended because it makes it more difficult to debug interoperational problems. Also note that disabling the Server: header does nothing at all to make your server more secure. The idea of "security through obscurity" is a myth and leads to a false sense of safety. https://httpd.apache.org/docs/2.4/mod/core.html#servertokens

ServerSignature - Default is Off. So I removed it. https://httpd.apache.org/docs/2.4/mod/core.html#serversignature

TraceEnable - Default is on. Despite claims to the contrary, enabling the TRACE method does not expose any security vulnerability in Apache httpd. The TRACE method is defined by the HTTP/1.1 specification and implementations are expected to support it. https://httpd.apache.org/docs/2.4/mod/core.html#traceenable fModule mod_authz_core.c>

Topic locked