500 Internal Server error (after no index mod)

[mpb-encrypt]

I’ve lost https, after switching the server directories to ‘no index’ (and even after switching them back to default).

.htaccess contains:

RewriteEngine On 
RewriteCond %{SERVER_PORT} 80 
RewriteRule ^(.*)$ https://fuelmapper.com/$1 [R,L]

I decide to make all my directories ‘no index’ via cPanel (apparently it is recommended).

Access-logs - Failed to alter index settings. /.htaccess: Permission denied

All other dirs were switched to ‘no index’:

etc
logs
mail
public_ftp
public_html
ssl
   certs
   csrs
   keys
tmp
www

I loaded my web site and was presented with:
500 Internal Server error

One by one, I switched them back to default
(trying to find which one caused the fault)

Each time, testing the site, and each time getting 500 error,
until all the directories were at default indexing, yet still 500 error.

I disabled .htaccess - the site loaded - but I’m back to http
I enabled .htaccess - 500 error

Clearly something has permenantly changed, as .htaccess was working perfectly prior to my making the directories ‘no index’.

Is there a reset command?

Also; of the above directories:
Which ones can I / should I switch to ‘no index’?

[jsha]

I think the most likely answer is that your htaccess with noindex had a syntax error. Can you share that version? Also, note that your problem is more about Apache than about Let’s Encrypt. We’ll see if we can help because we’re nice like that, but you’ll probably have better luck asking in an Apache forum, or asking your hosting provider’s support.

[mpb-encrypt]

Thanks for being nice @jsha

I didn’t set noindex in .htaccess.
Perhaps that was the problem.

I used cPanel - Indexes

All dirs were switched to No Index
However, on attempting to switch the dir ‘access-logs’ this message was returned:
Failed to alter index settings. /.htaccess: Permission denied

Having switched all directories back to default (indexed) the 500 server error remained.

I could only get the site working by removing the https code:

RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://fuelmapper.com/$1 [R,L]

I did this by renaming the .htaccess file (to disable it).

Note: the above code was written by @serverco
It was working perfectly, until I tried to switch the directories to no index.

[mpb-encrypt]

Fixed it!

I downloaded the .htaccess file from the server, and found that it had been modified.

‘options - indexes’ had been added to the last line.
Phew!

Regarding no indexing of directories:
Do I just need to ‘noindex’ the public_html directories or should I noindex the others?

At least I now know better what is happening.

Edit:
I have started testing the no index options.
It would appear that ‘options - indexes’ should have been written to a new line.

For whatever reason, cPanel had appended it to the last line of code.
So I think that has solved the mystery

[mpb-encrypt]

The previous post outlined why the .htaccess file was producing a 500 server error.
Here, I outline what might have caused the problem.
Note: I just don’t have time to re-test everything, so these are the likely culprits

How cPanel messed up .htaccess (when implementing noindex)

1. No new line - therefore, instead of writing the new code into a new line, cPanel simply appended ‘options -indexing’ to the last line of code.
   Ie. If the previous code had been written (instead of pasted) the ENTER key would have been pressed, and a new line created. This sounds like a ‘version 1.0’ bug, but you never know

2. The 1st directory presented for ‘no indexing’ was the access_logs dir. Therefore I attempted to noindex it (producing the alert that implementation had failed). However the full alert text was something like: "Directory settings changed. Failed to alter index settings. /.htaccess: Permission denied. In fact this indicates 2 states. First, the directory settings were changed - the code was written. Second, they were not changed - presumably the effect was checked, and failed - but, too late, the damage was done.

[mpb-encrypt]

The previous post outlined why the .htaccess file was producing a 500 server error.
Here, I outline what might have caused the problem.
Note: I just don’t have time to re-test everything, so these are the likely culprits

Either way - the error occurred, therefore it must be a bug, because this error should not have occurred.
Would you agree?

How cPanel messed up .htaccess

(when implementing noindex)

1. No new line (carriage return) - therefore, instead of writing the new code into a new line, cPanel simply appended ‘options -indexing’ to the last line of code.

   Ie. If the previous code had been written (instead of pasted) the ENTER key would have been pressed, and a new line created.

   This sounds like a ‘version 1.0’ bug, but you never know.
   In my experience, people paste code all the time

2. The 1st directory presented for ‘no indexing’ was the access_logs dir.

   Filezilla sees this directory, but when it tries to read it, the response is that the directory doesn’t exist.
   Presumably this is a permissions issue.

   Not knowing this, I attempted to noindex it (producing the alert that ‘implementation had failed’).

   However the full alert text was something like:
   "Directory settings changed. Failed to alter index settings. /.htaccess: Permission denied.

   In fact this indicates 2 states.
   First, the directory settings were changed - the code was written.
   Second, presumably the effect was checked, and failed - but, too late, the damage was done.

   From this, the suggestion is that:
   Because I was attempting to noindex a directory that (effectively) didn’t exist; the code was incorrectly appended to the last line of code.

Analysis

• If (1) - then the cPanel code should check for an EOL first.
• If (2) - then the cPanel code should first check for a valid accessible directory, before writing the code.

Both circumstances can be easily met by an unsuspecting noob, when using cPanel.

Server noobs (like me), copy and paste code AND they are unlikely to know that the access_logs directory cannot be accessed.

Should I file a bug report?

BTW; Why is it that I cannot read the access_logs directory?
I do have a logs directory
It contains logs of visitors - maybe that is fine enough.

[jsha]

Yes, I am guessing the problem is (1). That style of bug is unfortunately common, and I’ve written bugs like that a time or two myself. I think filing a bug report would be a good idea!