A .htaccess file 3-4 naponta önkényesen átíródik

vlezli képe

Sziasztok!

Sok .htaccess fájllal kapcsolatos bejegyzést találtam itt, de egyik se pontosan az én esetem, ezért kérek segítséget új fórumtéma beküldésével.

A honlap : http://kovacsuveg.hu , Drupal 7 alatt fut. Fizetős a tárhely, már több mint 7 éve üzemel a honlap.

Kb. fél éve küzdök egy problémával. Nagyjából 3-4 naponta leáll a honlap és 500 internal server error hibaüzenet jelenik meg. Némi kutakodás és itteni fórumtémák olvasása után rájöttem, hogy a gyökérkönyvtárban lévő .htaccess file rendetlenkedik. Olyan, mintha valaki mindig átírna benne valamit, amitől a honlap üzemképtelenné válik.

Ilyenkor mindig lecserélem a .htaccess fájlt az aktuális verzióból kiszedettre, amitöl újabb 3-4 napig remekül működik a honlap, de aztán kezdődik minden elölről.

Legutóbb már a fájl engedélyeit próbáltam mérsékelni, elvettem az írási jogokat, de ez se segített, pár nap múlva megint leállt a honlap ugyanezzel a hibával. Ma ismét kicseréltem a fájlt, most így éppen működik a honlap, de 3-4 napon belül bizonyára ismét le fog állni...

A legutóbbi hibás .htaccess fájlt lementettem és idemellékelem, hátha valaki lát benne valami érdemlegeset (pdf-re alakítottam, mert másképp nem lehetett feltölteni).

Találkozott már valaki ilyen problémával? Mi okozhatja és mi lehet a megoldás?

A válaszokat előre is köszönöm!

Drupal verzió: 
Fórum: 
lazar képe

Ismerni kellene a htaccess tartalmát, mi az ami módosul. Nem csatoltad.
Hol van a hosting és mit mind e jelenségre?

0
0
vlezli képe

Kedves Lazar!
A honlap a Magyar Hosting-nál van már 7 éve, eddig semmi probléma nem volt.

A kérdéses - átírt - fájlt próbáltam csatolni a bejegyzés létrehozásakor, úgy látszik nem sikerült...

Itt most nem látok feltöltési lehetőséget, így megpróbálom idemásolni a fájl tartalmát. Hátha ez alapján sikerül valami megoldást találni. Minden jó tanácsnak örülök!

Egyébként a bejegyzésem óta egyszer megint elszállt a honlap, és most is a .htaccess fájl cseréje segített!

#
# Apache/PHP/Drupal settings:
#

# Protect files and directories from prying eyes.

Require all denied

Order allow,deny

# Don't show directory listings for URLs which map to a directory.
Options -Indexes

# Follow symbolic links in this directory.
Options +FollowSymLinks

# Make Drupal handle any 404 errors.
ErrorDocument 404 /index.php

# Set the default handler.
DirectoryIndex index.php index.html index.htm

# Override PHP settings that cannot be changed at runtime. See
# sites/default/default.settings.php and drupal_environment_initialize() in
# includes/bootstrap.inc for settings that can be changed at runtime.

# PHP 5, Apache 1 and 2.

php_flag magic_quotes_gpc off
php_flag magic_quotes_sybase off
php_flag register_globals off
php_flag session.auto_start off
php_value mbstring.http_input pass
php_value mbstring.http_output pass
php_flag mbstring.encoding_translation off

# Requires mod_expires to be enabled.

# Enable expirations.
ExpiresActive On

# Cache all files for 2 weeks after access (A).
ExpiresDefault A1209600

# Do not allow PHP scripts to be cached unless they explicitly send cache
# headers themselves. Otherwise all scripts would have to overwrite the
# headers set by mod_expires if they want another caching behavior. This may
# fail if an error occurs early in the bootstrap process, and it may cause
# problems if a non-Drupal PHP file is installed in a subdirectory.
ExpiresActive Off

# Various rewrite rules.

RewriteEngine on

# Set "protossl" to "s" if we were accessed via https://. This is used later
# if you enable "www." stripping or enforcement, in order to ensure that
# you don't bounce between http and https.
RewriteRule ^ - [E=protossl]
RewriteCond %{HTTPS} on
RewriteRule ^ - [E=protossl:s]

# Make sure Authorization HTTP header is available to PHP
# even when running as CGI or FastCGI.
RewriteRule ^ - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

# Block access to "hidden" directories whose names begin with a period. This
# includes directories used by version control systems such as Subversion or
# Git to store control files. Files whose names begin with a period, as well
# as the control files used by CVS, are protected by the FilesMatch directive
# above.
#
# NOTE: This only works when mod_rewrite is loaded. Without mod_rewrite, it is
# not possible to block access to entire directories from .htaccess, because
# is not allowed here.
#
# If you do not have mod_rewrite installed, you should remove these
# directories from your webroot or otherwise protect them from being
# downloaded.
RewriteRule "/\.|^\.(?!well-known/)" - [F]

# If your site can be accessed both with and without the 'www.' prefix, you
# can use one of the following settings to redirect users to your preferred
# URL, either WITH or WITHOUT the 'www.' prefix. Choose ONLY one option:
#
# To redirect all users to access the site WITH the 'www.' prefix,
# (http://example.com/... will be redirected to http://www.example.com/...)
# uncomment the following:
# RewriteCond %{HTTP_HOST} .
# RewriteCond %{HTTP_HOST} !^www\. [NC]
# RewriteRule ^ http%{ENV:protossl}://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
#
# To redirect all users to access the site WITHOUT the 'www.' prefix,
# (http://www.example.com/... will be redirected to http://example.com/...)
# uncomment the following:
# RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
# RewriteRule ^ http%{ENV:protossl}://%1%{REQUEST_URI} [L,R=301]

# Modify the RewriteBase if you are using Drupal in a subdirectory or in a
# VirtualDocumentRoot and the rewrite rules are not working properly.
# For example if your site is at http://example.com/drupal uncomment and
# modify the following line:
# RewriteBase /drupal
#
# If your site is running in a VirtualDocumentRoot at http://example.com/,
# uncomment the following line:
# RewriteBase /

# Pass all requests not referring directly to files in the filesystem to
# index.php. Clean URLs are handled in drupal_environment_initialize().
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !=/favicon.ico
RewriteRule ^ index.php [L]

# Rules to correctly serve gzip compressed CSS and JS files.
# Requires both mod_rewrite and mod_headers to be enabled.

# Serve gzip compressed CSS files if they exist and the client accepts gzip.
RewriteCond %{HTTP:Accept-encoding} gzip
RewriteCond %{REQUEST_FILENAME}\.gz -s
RewriteRule ^(.*)\.css $1\.css\.gz [QSA]

# Serve gzip compressed JS files if they exist and the client accepts gzip.
RewriteCond %{HTTP:Accept-encoding} gzip
RewriteCond %{REQUEST_FILENAME}\.gz -s
RewriteRule ^(.*)\.js $1\.js\.gz [QSA]

# Serve correct content types, and prevent mod_deflate double gzip.
RewriteRule \.css\.gz$ - [T=text/css,E=no-gzip:1]
RewriteRule \.js\.gz$ - [T=text/javascript,E=no-gzip:1]

# Serve correct encoding type.
Header set Content-Encoding gzip
# Force proxies to cache gzipped & non-gzipped css/js files separately.
Header append Vary Accept-Encoding

# Add headers to all responses.

# Disable content sniffing, since it's an attack vector.
Header always set X-Content-Type-Options nosniff

# php -- BEGIN cPanel-generated handler, do not edit
# Set the “alt-php53” package as the default “PHP” programming language.

AddHandler application/x-httpd-alt-php53___lsphp .php .php5 .phtml

# php -- END cPanel-generated handler, do not edit

0
0

Veres László

Geva képe

a cpanel - frissüléskor - írta át a htaccess fájlt, mivel nem vágott egybe a tárhely beállításaimmal a honlap .htaccess fájlja - a https, www nélküli átirányításaim rendre 'elvesztek' a .htaccess felülírásával. Igaz, nem szálltak el a honlapjaim, de hátha nálad is valami ilyesmi lesz a megoldás. kb fél éve kezdődött itt is :-)

látom cpanel felület van a tárhelyeden,
+ a PHP 5.3 van beállítva??? már nem támogatott ez a verzió + a drupal 7 vagy modulok sem fognak működni ezzel (pl a legutolsó backup_and_migrate modul friss verziója már 5-s php-vel nem működik, 7.2 vagy 7.3 kell)

0
0
vlezli képe

Kedves Geva!

Úgy tűnik, nálam is a rossz PHP verzió csinálta a problémát. Eddig 5.4-es volt, amit átállítottam 7.2-re. Egy hét elteltével még minden működik, remélem most már nem is fog átíródni a .htaccess fájl!

Nagyon szépen köszönöm a tippet és a segítséget!

1
0

Veres László

Geva képe

úgy legyen, reméljük hogy nálad _csak_ a php verzió okozta az átíródást.
Nálam az eredeti .htaccess fájl átíródását nem a php verzió okozta - akkor nálam már kb egy éve a 7.2-s verzió volt beállítva(igaz, már a php verzió váltásnál is átíródott a .htaccess fájl, de ez jó ideig nem ismétlődött) ...valami beállítás a cpanel felület domain körül nem volt jó...
szóval légy résen! :-)
most éppen fehér oldal fogadott a megadott url-n!!!! a https átirányítás sem éledt
mi történt?

0
0