As of virtualmin 6.10 the (new?) feature of setting up a default landing page for new servers is causing some serious issues with my workflow. I have some level of automation taking place where a new server is created and wordpress is auto-installed for a client.
The inclusion of the default index.html takes priority over the index.php of the wordpress script which breaks the entire flow for the user.
Is there any way to stop this or to go back to the previous version of Virtualmin where this was not present?
I am also using a skeleton directory for some custom wordpress files, but not sure how to REMOVE this index.html from the directory as it’s not part of the skeleton directory.
There has got to be a better way. Is there a way to run some script after a server install to delete the index.html file in the home directory so I’m not modifying virtualmin files?
I would just like to register our own “boo” to this update as well, and request that there be a way added to skip this new behavior. We’re in exactly the same boat as OP and, in addition to index.html being populated against our desires, it also removes the WordPress-specific index.php file that had previously been there (thanks to create_index_content()).
Otherwise, why bother with templates at all if you’re going to blow away stuff that the template does, and the “solution” is to reapply the affected files from the template with yet another script?
#!/bin/bash
if [ "$VIRTUALSERVER_ACTION" = "CREATE_DOMAIN" -a ! -z "$VIRTUALSERVER_HOME" ]; then
cd $VIRTUALSERVER_HOME
rm -f public_html/index.html
cp -a /etc/skel-wp/public_html/index.php public_html/index.php
chown $VIRTUALSERVER_USER:$VIRTUALSERVER_GROUP public_html/index.php
fi
The timestamp on index.php matches the template (/etc/skel-wp/public_html/index.php) exactly, so that’s definitely happening. I was executing long listings of the public_html/ folder in quick succession and it went from:
-rw-r--r-- 1 pcgtest pcgtest 405 Aug 12 13:00 index.php
to:
-rw-r--r-- 1 pcgtest pcgtest 0 Aug 12 13:01 index.html.webmintmp.14449
-rw-r--r-- 1 pcgtest pcgtest 405 Feb 6 2020 index.php
to:
-rw-r--r-- 1 pcgtest pcgtest 985717 Aug 12 13:01 index.html
-rw-r--r-- 1 pcgtest pcgtest 405 Feb 6 2020 index.php
So you can see the copy of index.php happened… and index.html was populated after my post script ran. So it appears this isn’t a viable solution at all.
Can you please take another look at this and let us know what the appropriate approach should be? Thanks!
@Ilia can you take a look at this? We shouldn’t be overriding existing indexes in /etc/skel, including index.php. And, if it’s running after the postcreate hook, that’s a bug. Post-script should happen after anything Virtualmin is doing. That’s the point of it.
The problem was the order DirectoryIndex is read. It always started with index.html and hit it first, even if index.php exists. That’s what is happening now, the files from /etc/skel are copied but Apache prefers existing index.html to index.php. The workaround would be is to tweak Apache DirectoryIndex directive. Linked patch will address this issue for new installs.
And, if it’s running after the postcreate hook, that’s a bug. Post-script should happen after anything Virtualmin is doing.
It appears that it is infact creating landing index.html after post script is run.
To be fair, I might have also misread this code in create_index_content and/or misremembered some testing wherein I thought index.php was being deleted, not just overridden:
# Remove any existing index.* files that might be used instead
local $dest = &public_html_dir($d);
if ($over) {
local @indexes = grep { -f $_ } glob("$dest/index.*");
if (@indexes) {
&unlink_file(@indexes);
}
}
And, if it’s running after the postcreate hook, that’s a bug. Post-script should happen after anything Virtualmin is doing.
It appears that it is infact creating landing index.html after post script is run.
I’m glad to hear I’m not going crazy, and it’s good to know this will be getting addressed. Thanks!
Okay, is it really deleted? What do you actually see under ~/public_html after creating new virtual server? Is index.php file there, just as our landing index.html page?
Both files are there and, as you discussed, index.html is simply overriding index.php. The problem still exists that the post script runs beforeindex.html gets created and, thus, is unable to delete it. (Yes, it would be easy enough to prefer index.php via DirectoryIndex but I’d still like to not leave public_html/ polluted when we’re already supplying our own data.)
Okay, I understand now what was the initial intent. What if a user wanted to keep both (or more) files, and use Virtualmin landing page as a default fall back?
Do you have a version number assigned yet that will incorporate these changes? I’d like to keep my eyes out for it so that we can test it with our clients. Thanks!
