Server::Apache
Webserver Opstarten
Webserver componenten
De distributie van ClearOS Community is op 28/10/2020 7.8.1 (Final) en bevat voor de Webserver:
 |
||
| 1. | Apache 2.4.6 (CentOS) | (op 28/10/2020 voor ClearOS 7.8.1 de laatst beschikbare versie). |
| 2. | MySQL 5.5.56-MariaDB | (op 28/10/2020 voor ClearOS 7.8.1 de laatst beschikbare versie). |
| 3. | PHP 5.4.16 | (op 28/10/2020 voor ClearOS 7.8.1 de laatst beschikbare versie). |
ClearOS Webserver Activeren
Selecteer: Webconfig > Server > Web > Web server
> Settings
Dit opent de ClearOS Webserver App (app-web-server) waarmee we de Apache HyperText Transfer Protocol Daemon (webserver) activeren. De Webserver App is een front-end van ClearOS voor de Apache webserver. Met deze App activeren we de webserver en kunnen we één of meer (virtuele) servers toevoegen en deze voorzien van de basis configuratie.
De in deze App gemaakte instellingen worden opgeslagen in
/etc/httpd/conf.d/flex-80.conf en /etc/httpd/conf.d/flex-443.conf twee van de includes in het HTTPD (webserver) hoofdconfiguratie bestand /etc/httpd/httpd.conf
Activatie en configuratie
- Selecteer Webserver 'Start'
- Vul servernaam in:
mainserver.makkink.eu
- Selecteer <Configure Default Website>
Edit Web Site Settings
Webconfig Settings
We accepteren de ClearOS defaults behalve:
- File Server Upload: Disabled
Enabling resulteert in het creëren van een flexshare. Hier werken we op deze server niet mee en voor upload gebruiken we Samba. - Show Index: Disabled
Voorkom directory-listing als er geen index.html voor komt - Follow Symbolic Links: Enabled
Nodig voor o.a. URL-rewrite - Allow [.htaccess] Override: Disabled
Voor security, voorkomt misbruik van .htaccess - Zet PHP Engine naar laatst beschikbare PHP versie
Flex-{80,443}.conf's
Als aan het einde 'Update' geselecteerd wordt, worden de instellingen weggeschreven naar de httpd configuratiebestanden flex-80.conf en flex-443.conf met respectievelijk <VirtualHost *:80> en <VirtualHost *:443>
Er wordt gecontroleerd of er al een flexshare bestaat en anders wordt deze aangemaakt zijnde: /var/flexshare/shares/[ServerName] of te wel: /var/flexshare/shares/makkink.eu
Tevens wordt in /etc/fstab de volgende regel toegevoegd:
/var/www/html /var/flexshare/shares/makkink.eu none defaults,bind 0 0
Dit resulteert er in dat er een extra mount
/var/flexshare/shares/makkink.eu aangemaakt wordt.
Deze bevat dus niet de data maar slechts de verwijzing ernaar.
Voorlopig heeft deze mount, als we niet met Flexshares werken geen nut, maar laten we het nu voor wat het is.
flex-80.conf
Na het maken van instellingen ziet het configuratie bestand /etc/httpd/conf.d/flex-80.conf er zo uit:
#----------------------------------------------------------------
# WARNING: This file is automatically created by webconfig.
#----------------------------------------------------------------
# Authentication mechanism
DefineExternalAuth pwauth pipe /usr/bin/pwauth
DefineExternalGroup pwauth pipe /usr/bin/unixgroup
# -----------------------------------------------#
# Web Site
# -----------------------------------------------#
<VirtualHost *:80>
ServerName makkink.eu
ServerAlias *.makkink.eu
DocumentRoot /var/www/html
ErrorLog /var/log/httpd/error_log
CustomLog /var/log/httpd/access_log combined
</VirtualHost>
<Directory /var/www/html>
Options -Indexes +FollowSymLinks -IncludesNOExec
Require all granted
</Directory>
flex-443.conf
Na het maken van instellingen ziet het configuratie bestand /etc/httpd/conf.d/flex-443.conf er zo uit:
#----------------------------------------------------------------
# WARNING: This file is automatically created by webconfig.
#----------------------------------------------------------------
# Authentication mechanism
DefineExternalAuth pwauth pipe /usr/bin/pwauth
DefineExternalGroup pwauth pipe /usr/bin/unixgroup
# -----------------------------------------------#
# Web Site
# -----------------------------------------------#
<VirtualHost *:443>
ServerName makkink.eu
ServerAlias *.makkink.eu
DocumentRoot /var/www/html
ErrorLog /var/log/httpd/error_log
CustomLog /var/log/httpd/access_log combined
SSLEngine on
SSLCertificateFile /etc/pki/CA/sys-0-cert.pem
SSLCertificateKeyFile /etc/pki/CA/private/sys-0-key.pem
SSLCACertificateFile /etc/pki/CA/ca-cert.pem
# No weak export crypto allowed
SSLHonorCipherOrder on
SSLProtocol all -SSLv2 -SSLv3 -TLSv1
SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:
ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:
RSA+3DES:!3DES:!aNULL:!MD5
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
downgrade-1.0 force-response-1.0
</VirtualHost>
Waarschuwing:
Maak geen eigen configuratiewijzigingen door de bestanden flex-80.conf en flex-443.conf handmatig te wijzigen. Zodra we met de Webconfig Webserver App wijzigingen/updates aanbrengen zullen deze eigen directives overschreven worden.
Eigen HTTPD configuratie
Creëer voor eigen custom configuratieinstellingen het bestand custom_httpd.conf in de map /etc/httpd/conf.d/ met daarin de eigen directives.
Zie de uitwerking hiervan in de sectie Custom Httpd Configuratie
Activeren PHP
Met het starten van de HTTPDeamon (Apache) is vanzelf ook PHP actief.
php.ini
Het bestand php.ini bevat de instellingen van PHP
Onderstaande gewijzigde instellingen zijn nodig voor het werken met grotere bestanden zoals het uploaden van foto's in wordpress.
Open hiertoe het PHP settings bestand '/etc/php.ini' in een teksteditor en verifiëer de volgende argumenten (in de volgorde zoals ze voorkomen):
- post_max_size = 100M
- upload_max_filesize = 100M
phpinfo()
Op een server waar PHP actief is kan op eenvoudige wijze achterhaald worden welke versies en modules er op de server actief zijn en wat hun argumenten, variabelen of instellingen zijn.
Dit is mogelijk door de phpinfo functie te gebruiken door de volgende code in een .php bestand (bijvoorbeeld phpinfo.php) te plaatsen en deze via de browser aan te roepen:
<?php phpinfo(); ?>
Dit zal dan een pagina tonen die er als volgt uitziet:
Met daarin ook een sectie betreffende PHP instellingen:
Upgrade naar PHP 7+ met App PHP-Engines
Met de ClearOS 7.8.1 distributie van 2020 werd voor de Apache webserver de toen al verouderde PHP versie 5.4 meegeleverd. Tot op heden ( 28-10-2020) heeft ClearOS hiervoor geen update uitgebracht. Dit terwijl RedHat en CentOS al lang de versies 5.6 en 7.x uitgebracht hebben.
Eind 2017 heeft de ClearOS Community de PHP-Engines App geïntroduceerd waarmee deze RedHat PHP distributies in ClearOS 7.0 geïntegreerd kunnen worden. Deze app kan geïnstalleerd worden vanuit de ClearOS Marketplace of aan de command line met commando # yum install app-php-engines. Zorg er hierbij voor dat de ClearOS-Contribs repositorie beschikbaar is.
Onderstaand wordt de installatie beschreven op 25-03-2019 van de PHP-Engines App met de versies 5.6, 7.0 en 7.1 van RedHat. De oude versie 5.4 is een vast onderdeel van ClearOS 7.x en kan/mag niet verwijderd worden.
In juli 2020 is er een PHP-Engines update uitgebracht en de beschikbare versies zijn nu 5.4, 7.0, 7.1, 7.2 en 7.3
Het contribs team adviseert PHP 5.6 niet te gebruiken en bij recente updates is deze ook niet meer beschikbaar.
Na de installatie van de PHP-Engines App kunnen we de gewenste PHP versie selecteren in de Webserver App.
Handmatige PHP Upgrade naar versie 7.3
Lang voordat de PHP-Engines App met PHP version 7.3 uitkwam was deze PHP versie al beschikbaar in de repo centos-sclo-rh-testing-unverified
Deze versie had ik al op mijn server geïnstalleerd door de procedure te volgen in een post op Github
Zie voor de eigen gebruikte procedure Projectmap Exploring Linux
Website Settings
Webconfig > Server > Web > Web server > Website > Edit
Nu opent de Website Settings pagina, met aan de bodem nu toegevoegd de PHP options:
We selecteren nu de door ons gewenste PHP versie. In dit voorbeeld kiezen we PHP 7.3. In de dropdown is versie 5.6 nog beschikbaar maar selectie resulteerd in een fout.
Na het selecteren van 'Update' is PHP 7.3 actief op de Apache webserver.
We openen phpinfo.php in de webroot en confirmeren dat PHP 7.3 actief is.
Let op, telkens als we een Website Update toepassen (voor bijvoorbeeld kiezen van een andere/nieuwere PHP versie) worden de bestaande Flex-{80,443}.conf bestanden overschreven!!
Maak voor eigen custom directives daarom geen gebruik van deze Flex-{80,443}.conf bestanden. Zie hiervoor de sectie Custom Httpd Configuratie
php.ini voor PHP 7.3
Het bestand php.ini bevat de instellingen van PHP, maar elke PHP Engine heeft zijn eigen php.ini bestand. Om deze te vinden voeren we het commando # locate php.ini uit en dat geeft het volgende resultaat:
[root@mainserver ~]# locate php.ini
/etc/php.ini
/etc/opt/rh/rh-php70/php.ini
/etc/opt/rh/rh-php71/php.ini
/etc/opt/rh/rh-php72/php.ini
/etc/opt/rh/rh-php73/php.ini
Onderstaande gewijzigde instellingen zijn nodig voor het werken met grotere bestanden zoals het uploaden van foto's in wordpress.
Open hiertoe het PHP settings bestand '/etc/opt/rh/rh-php7x/php.ini' in een teksteditor en verifiëer/corrigeer de volgende argumenten (in de volgorde zoals ze voorkomen):
- memory_limit = 256M (voor Wordpress)
- post_max_size = 100M
- upload_max_filesize = 100M
Er moet een herstart van 'httpd' gedaan worden of beter de server reboten om deze wijziging te laden en check met phpinfo()
PHP Picker
Met het selecteren van een PHP versie in Webconfig > Server > Web > Web server > Websites > Settings zijn er voor het PHP twee belangrijke dingen gebeurt:
- In de webroot /var/www/html is een bestand .phpenv geplaatst met daarin de tekst 73. De bedoeling hiervan is dat door dit bestand bijvoorbeeld in een subdir van de website te plaatsen en de inhoud te wijzigen naar 54, dat deze subdir gebruik maakt van PHP 5.4 Zie WikiSuite/app-php-engines
- Er zijn nieuwe flex-{80,443}.conf bestanden aangemaakt in /etc/httpd/conf.d/ met daarin nieuwe directives voor de app-php-engines. Deze directive bepaald welke PHP versie gebruikt moet worden.
De PHP-Engines directive in flex-80.conf:
<Directory /var/www/html>
<FilesMatch \.php$>
SetHandler "proxy:fcgi://127.0.0.1:9073"
</FilesMatch>
</Directory>
Hand picker ;)
Door in de directive het getal 71 aan het eind bijvoorbeeld te wijzigen naar 56 zal het er in resulteren dat in /var/www/html nu PHP 5.6 gebruikt zal worden. Dus we kunnen ook selectief in een subdir een andere PHP versie gebruiken door voor deze subdir (bijvoorbeeld piwigo) een extra directive te plaatsen zoals hieronder
<Directory /var/www/html/piwigo> <FilesMatch \.php$> SetHandler "proxy:fcgi://127.0.0.1:9054" </FilesMatch> </Directory>
Let op, telkens als we een Website Update toepassen worden de bestaande Flex-{80,443}.conf bestanden overschreven!!
Maak voor eigen custom directives daarom geen gebruik van deze Flex-{80,443}.conf bestanden. Zie hiervoor de sectie Custom Httpd Configuratie
PHP extension Imagick
Imagick is de PHP ImageMagick extension voor het creëren en bewerken van foto's gebruik makend van de ImageMagick Application Programming Interface (API).
Piwigo en Wordpress maken middels Imagick gebruik van de ImageMagick App en elke PHP versie heeft zijn eigen Imagick extension.
- Verifiëer dat ImageMagick geïnstalleerd is.
# convert --version Version: ImageMagick 6.9.10-68 Q16 x86_64 2020-04-01 https://imagemagick.org Copyright: © 1999-2019 ImageMagick Studio LLC
- Installeer php-imagick voor PHP versie die in gebruik is
# yum install sclo-php73-php-pecl-imagick.x86_64 --enablerepo=
centos-sclo-sclo-unverified - Reboot server (niet alleen httpd) en verify met phpinfo()
Upgrade PHP 5.4 naar 7.4 met Remi repo
In de ClearOS repositories is de laatste beschikbare PHP versie: 7.3 en in verband met het door IBM stoppen van CentOS worden er ook geen verdere updates verwacht. Zie ook Server::Configureren > PHP update 5.4 naar 7.4
Ook in de CentOS en/of RHEL repositories zijn geen latere versies beschikbaar.
Remi's RPM Repository
Remi onderhoud diverse PHP RPM's for Fedora and EPEL.
Zie https://rpms.remirepo.net/ voor een wizard die helpt met de keuze van de gewenste RPM en vervolgens uitgebreide instructies voor het installeren verstrekt
Selecteer voor Operating System: EL7 voor CentOS
Selecteer voor PHP versie: 7.4.33
Note: Latere versies resulteren in een fatal error in Wordpress i.v.m. het door mij gebruikte thema dat al geruime tijd niet meer onderhouden wordt.
Selecteer voor Type of installation: Single
Dit resulteert erin dat de upgrade de huidige versie 5.4 vervangt door de versie 7.4.33
Selecteer voor Architexture x86-64
Installatie Instructies
De wizard verstrekt nu de stap voor stap instructies om de upgrade uit te voeren.
Hieronder de stappen die ik mede aan de hand van de wizard uitgevoerd heb.
- Zet de PHP versie op de server naar 5.4
Webconfig > Server > Web > Webserver
Edit Websites en zet PHP Engine naar 5.4
Er worden nu nieuwe flexbestanden aangemaakt, integreer deze in custom-httpd.conf met commando # flex-integrate - Maak een lijst met php-modules die op de server in gebruik zijn. Na de upgrade moeten we ervoor zorgen dat voor PHP 7.4 dezelfde modules geïnstalleerd zijn/worden.
# yum list installed php-* en # yum list installed rh-php73-php-* - Installeer Epel (Extra Packages for Enterprise Linux)
# yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
Op mijn server is ClearOS-epel/7/x86_64 al actief, dus heb ik vooralsnog deze install niet uitgevoerd. - Installeer het Remi repository configuratie pakket:
# yum install https://rpms.remirepo.net/enterprise/remi-release-7.rpm - In geval het yum-utils pakket (voor het yum-config-manager commando) nog niet geïnstalleerd is:
# yum install yum-utils
Er is gekozen voor een 'Single' installatie, dat houdt in dat de bestaande versie (php 5.4) opgewaardeerd gaat worden naar de nieuwe versie door het vervangen van de basis pakketten die dezelfde naam hebben of te wel php-*.
Sommige benodigde dependencies zijn beschikbaar in de Remi-safe repository, die standaard ingeschakeld (enabled) is.
PHP version 7.4 packages voor CentOS 7 zijn beschikbaar in de remi-php74 repository
- Schakel de repository in:
# yum-config-manager --enable remi-php74
Check de ingeschakelde repositories:
# yum repolist - Voer de upgrade van PHP 5.4 naar PHP 7.4 uit:
# yum update
Zonodig voor dependencies de remi-safe repositorie inschakelen: # yum-config-manager --enable remi-safe - Maak listing van de met de upgrade geïnstalleerde modules:
# yum list installed php-*
Vergelijk dit met de voor de upgrade gemaakte listing en noteer de nog missende modules
- Installeer de nog ontbrekende PHP 7.4 modules, bijv.:
# yum install php-zip
en
# yum install php-pecl-imagick-im6 - Check de geïnstalleerde php versie en de beschikbare extenties:
# php --version
# php --modules
php.ini voor PHP 7.4
Het bestand php.ini bevat de instellingen van PHP, maar elke PHP Engine heeft zijn eigen php.ini bestand.
Na de upgrade is de basis PHP module PHP 5.4 vervangen door PHP 7.4
Van PHP 5.4 was /etc/php.ini het bestand met de instellingen. Na de upgrade zijn de instellingen voor PHP 7.4 voorlopig opgeslagen als /etc/php.ini.rpmnew
De huidige 5.4 /etc/php.ini moet nu vervangen worden door de 7.4 php.ini, maar op deze laatste moeten we dan eerst nog een edit doen.
Voor Piwigo moeten de volgende instellingen opgenomen worden:
memory_limit = 256M (voor Wordpress)
post_max_size = 100M
upload_max_filesize = 100M
Vervang nu de huidige php.ini: # mv /etc/php.ini.rpmnew /etc/php.ini en REBOOT
Edit en Activeer de PHP-Engines App
We gaan nu de upgrade naar PHP 7.4 integreren in PHP Engines. Zie voorbeeld in Exporing Linux > Projecten
>
Handmatige PHP Upgrade naar versie 7.3
Verwijder PHP 5.4 uit PHP Egines en vervang door PHP 7.4
# cd /usr/clearos/apps/php_engines/libraries
# cp -a PHP_Engines.php PHP_Engines.php.org
# vi
PHP_Engines.php
Vind regel 'protected $supported = array( 'httpd' => 'PHP 5.4',
protected $supported = array(
'httpd' => 'PHP 5.4',
'rh-php70-php-fpm' => 'PHP 7.0',
'rh-php71-php-fpm' => 'PHP 7.1',
'rh-php72-php-fpm' => 'PHP 7.2',
'rh-php73-php-fpm' => 'PHP 7.3'
);
En wijzig dit naar protected $supported = array( 'httpd' => 'PHP 7.4',
- Open Webconfig > Server > Web > PHP Engines en zie dat hier 7.4 in de lijst opgenomen is. Maak 7.4 beschikbaar (enable) en save.
- Open Webconfig > Server > Web > Webserver > Websites > Bewerk en select in de dialoogbox PHP 7.4
- Save en Apache gebruikt nu PHP 7.4
Vergeet niet de opnieuw gecreëerde Flex bestanden te integreren in custom-httpd.conf met commando # flex-integrate. Zie hiervoor de sectie Custom Httpd Configuratie
Upgrade naar PHP 8+ met App PHP-Engines
Met de ClearOS 7.8.1 distributie van 2020 werd voor de Apache webserver de toen al verouderde PHP versie 5.4 meegeleverd. Tot op heden ( 28-10-2020) heeft ClearOS hiervoor geen update uitgebracht. Dit terwijl RedHat en CentOS al lang de versies 5.6 en 7.x uitgebracht hebben.
Eind 2017 heeft de ClearOS Community de PHP-Engines App geïntroduceerd waarmee deze RedHat PHP distributies in ClearOS 7.0 geïntegreerd kunnen worden.
In juli 2020 is er een PHP-Engines update uitgebracht en de beschikbare versies in ClearOS 7.x waren nu 5.4, 7.0, 7.1, 7.2 en 7.3
De oude versie 5.4 was een vast onderdeel van ClearOS 7.x en kan/mag niet verwijderd worden.
In de voorgaande sectie is beschreven hoe een update naar PHP 7.4 uitgevoerd wordt en daarmee PHP 5.4 vervangt en het vaste PHP onderdeel is geworden van ClearOS 7x.
In de ClearOS repositories is de laatste beschikbare PHP versie: 7.3 en in verband met het door IBM stoppen van CentOS worden er ook geen verdere updates verwacht. Zie ook Server::Configureren > PHP update 5.4 naar 7.4
Ook in de CentOS en/of RHEL repositories zijn geen latere versies beschikbaar.
Deze zijn wel beschikbaar in de Remi RPM Repository o.a EL 7 voor Centos.
- Om de flexibiliteit te behouden voor bepaalde apps zoals Piwigo en Wordpress voeren we nu niet een single install uit, maar een een install van Multiple Versions Simultanious
Dat houdt in dat de verschillende PHP versies naast elkaar geïnstalleerd worden zonder dat de basis versie PHP 7.4 overschreven wordt.
- We gebruiken vervolgens de ClearOS app PHP-Engines om de diverse geïnstalleerde versies te selecteren en te gebruiken.
Zie voor het integreren van de nieuwe versie(s) door het aanpassen van PHP-Engines de eigen en eerder gebruikte procedure in Projectmap Exploring Linux
- In de nu volgende sectie wordt de installatie uit de Remi RPM Repository van PHP 8.0.30 beschreven
Installatie PHP 8.0.30 uit de Remi's RPM Repository
Als voorbeeld wordt hierna de installatie van PHP 8.0 beschreven. Dezelfde procedure kan gevolgd worden voor de installatie van de PHP versies 8.1, 8.2 en 8.3
Remi onderhoud diverse PHP RPM's for Fedora and EPEL.
Zie https://rpms.remirepo.net/ voor een wizard die helpt met de keuze van de gewenste RPM en vervolgens uitgebreide instructies voor het installeren verstrekt.
Selecteer voor Operating System: EL7 voor CentOS
Selecteer voor PHP versie: 8.0.30
Selecteer voor Type of installation: Multiple versions simultaneously
Dit resulteert erin dat de installatie paralel aan de basisversie 7.4 geplaatst wordt in /etc/opt/remi
Selecteer voor Architexture x86-64
Installatie Instructies
De wizard verstrekt nu de stap voor stap instructies om de upgrade uit te voeren.
Hieronder de stappen die ik mede aan de hand van de wizard uitgevoerd heb.
- Zet, als dit niet al het geval is, de PHP versie op de server naar 7.4:
Webconfig > Server > Web > Webserver
Edit 'Websites' en zet PHP Engine naar 7.4
Er worden bij elke wijziging van 'Websites' nieuwe flexbestanden aangemaakt, her-integreer deze in custom-httpd.conf met commando # flex-integrate - Maak een lijst met php-modules die op de server in gebruik zijn. Na de upgrade moeten we ervoor zorgen dat voor PHP 8.0.30 dezelfde modules geïnstalleerd zijn/worden.
# yum list installed php-* - Installeer Epel (Extra Packages for Enterprise Linux)
# yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
Op mijn server is ClearOS-epel/7/x86_64 al actief, dus heb ik deze install niet uitgevoerd. - Installeer het Remi repository configuratie pakket:
# yum install https://rpms.remirepo.net/enterprise/remi-release-7.rpm
Dit was al geïnstalleerd bij de upgrade naar PHP 7.4 - In geval het yum-utils pakket (voor het yum-config-manager commando) nog niet geïnstalleerd is:
# yum install yum-utils
Dit was ook al geïnstalleerd bij de upgrade naar PHP 7.4
Er is gekozen voor een 'Multiple versions simultaneously' installatie, dat houdt in de install naast de bestaande versie (php 7.4) geïnstalleerd gaat worden.
Alle benodigde PHP 8.0.30 packages en dependencies zijn beschikbaar beschikbaar in de Remi-safe repository, die standaard al ingeschakeld (enabled) is.
- Check de ingeschakelde repositories en verifiëer dat Remi-safe er bij is:
# yum repolist - Voer de installatie van PHP 8.0.30 uit:
# yum install php80 - Maak listing van de met de install geïnstalleerde modules:
# yum list installed php80*
Vergelijk dit met de voor de upgrade gemaakte listing en noteer de nog missende modules
- Installeer de nog ontbrekende PHP 8.0.30 modules:
# yum install php80-php-bcmath
# yum install php80-php-fpm
# yum install php80-php-gd
# yum install php80-php-gmp
# yum install php80-php-intl
# yum install php80-php-ldap
# yum install php80-php-mbstring
# yum install php80-php-mysqlnd
# yum install php80-php-opcache
# yum install php80-php-pear
# yum install php80-php-pecl-imagick-im6
# yum install php80-php-pecl-zip
# yum install php80-php-soap
# yum install php80-php-sodium
php.ini voor PHP 8.0.30
Het bestand php.ini bevat de instellingen van PHP, maar elke PHP Engine heeft zijn eigen php.ini bestand.
In de zojuist geïnstalleerde PHP 8.0.30 /etc/opt/remi/php80/php.ini moet voor Piwigo de volgende instellingen opgenomen worden:
memory_limit = 256M (voor Wordpress)
post_max_size = 100M
upload_max_filesize = 100M
En REBOOT
PHP-Engines Integratie van PHP 8.0
We gaan nu de installatie van PHP 8.0 toevoegen in PHP Engines.
Zie ook zoals uitgevoerd in Exporing Linux > Projecten
>
Handmatige PHP Upgrade naar versie 7.3
Bij het toevoegen aan PHP-Engines heb ik de procedure gevolgd zoals omschreven op Github Added PHP 7.1 engine
A. Edit PHP_Engines.php
- Maak kopie van /usr/clearos/apps/php_engines/libraries/PHP_Engines.php en geef extentie: .org
- Edit PHP_Engines.php en verwijder in 'class PHP_Engines extends Engine' block 'Variables' alle regels de regels voor php70, php71 en php72. Deze zullen we nooit meer nodig hebben.
We zouden onze server op kunnen ruimen door alle voorkomens van deze php7x te deïnstalleren/verwijderen. Het is echter eenvoudiger ze te laten voor wat ze zijn. - Voeg vervolgens toe de regels voor PHP 8.0
protected $services = array();
protected $supported = array(
'httpd' => 'PHP 7.4',
'rh-php73-php-fpm' => 'PHP 7.3',
'php80-php-fpm' => 'PHP 8.0'
);
protected $ports = array(
'httpd' => 0,
'rh-php73-php-fpm' => 9073,
'php80-php-fpm' => 9080
);
protected $version_codes = array(
'rh-php73-php-fpm' => 73,
'php80-php-fpm' => 80
);
protected $configs = array(
'rh-php73-php-fpm' => '/etc/opt/rh/rh-php73/php.ini',
'php80-php-fpm' => '/etc/opt/remi/php80/php.ini'
);
B. Edit info.php
Maak kopie van /usr/clearos/apps/php_engines/deploy/info.php en geef extentie: .org
Edit info.php:
- Verwijder in $app[requires'] = array(
Alle regels met *php70*, *php71* en *php72*
Voeg toe in $app[requires'] = array(
Alle geinstalleerde php80-php-* modules (# yum list installed php80-php-*)
- Verwijder in $app['core_file_manifest'] = array(
Alle regels met *php70*, *php71* en *php72*
Voeg toe in $app['core_file_manifest'] = array(
Nieuwe regel:
'php80-php-fpm.php' => array('target' => '/var/clearos/base/daemon/php80-php-fpm.php'),
- Verwijder in blok 'www_path.conf' => array(
Alle regels met *php70*, *php71* en *php72*
Voeg toe in 'www_path.conf' => array(
Nieuwe regel:
'/etc/opt/remi/php80/php-fpm.d/www_path.conf',
C. Creëer rh-php80-php-fpm.php
- Ga naar /var/clearos/base/daemon/ en verwijder bestanden:
rh-php70-php-fpm.php, rh-php71-php-fpm.php en rh-php72-php-fpm.php
- Maak kopie van /var/clearos/base/daemon/
rh-php73-php-fpm.php en noem php80-php-fpm.php
- Edit php80-php-fpm.php:
Wijzig alle voorkomens van 7.3 & 73 naar respectievelijk 8.0 & 80
D. Edit upgrade
- Maak kopie van /usr/clearos/apps/php_engines/deploy/upgrade en geef extentie: .org
- Edit bestand upgrade.
Verwijder 'CHECK' secties met:
/etc/opt/rh/rh-php56/php-fpm.d/www.conf
/etc/opt/rh/rh-php70/php-fpm.d/www.conf
/etc/opt/rh/rh-php71/php-fpm.d/www.conf
/etc/opt/rh/rh-php72/php-fpm.d/www.conf
- Voeg toe 'CHECK' sectie voor PHP 8.0
CHECK=`grep "^listen[[:space:]]*=[[:space:]]*.*:9000$"
/etc/opt/remi/php80/php-fpm.d/www.conf 2> /dev/null`
if [ -n "$CHECK" ]; then
logger -p local6.notice -t installer "app-php-engines-core - updating
listen port for PHP 8.0"
sed -i -e 's/^listen[[:space:]]*=.*/listen = 127.0.0.1:9080/'
/etc/opt/remi/php80/php-fpm.d/www.conf
fi
E. Execute 'upgrade'
- # /usr/clearos/apps/php_engines/deploy/upgrade
- Herstart HTTPD
# systemctl restart httpd
F. Enable PHP 8.0 in PHP-Engines
- Webconfig > Server > PHP Engines: Enable PHP 8.0
G. Selecteer PHP 8.0 in Webserver
- Open Webconfig > Server > Web > Webserver > Websites > Bewerk en select in de dialoogbox PHP 8.0
- Save en Apache gebruikt nu PHP 8.0
Vergeet niet de opnieuw gecreëerde Flex bestanden te integreren in custom-httpd.conf met commando # flex-integrate. Zie hiervoor de sectie Custom Httpd Configuratie
Activeren MySQL en phpMyAdmin
Selecteer: Webconfig > Server > Database > MariaDB Database Server
Opent de ClearOS App voor
de MariaDB Database Server
- Selecteer : Start
- Vul het wachtwoord voor admin van de database in: <MySQL-rootwachtwoord> zoals ook gebruikt (zal worden) bij de Wordpress en Piwigo installatie.
- Het verdere beheer van de MySQL database kan nu via de browser met 'phpMyAdmin' met url https://mainserver:81/mysql/, log in als 'root' met het zojuist gegeven MySQL-rootwachtwoord. Zie Server:Firewaal > Diensten met aanvullende firewall beperkingen voor het begrenzen van de toegang tot poort 81 tot specifieke PC's op het lokale netwerk
Upgrade MySQL MariaDB 5.5 naar rh-MariaDB 10.3
In augustus 2020 is de met ClearOS release 7.8.1 (Final) meegeleverde database nog steeds de in 2012 uitgebrachte MariaDB 5.5, waarvan de End Of Life staat op april 2020.
Inmiddels is de laatste in november 2018 door MaraDB
uitgebrachte stabiele versie 10.4 , maar op 1 augustus 2020 is er nog steeds geen ClearOS upgrade beschikbaar.
In de ClearOS Sofware Collections repository clearos-centos-sclo-rh is al wel rh-MariaDB 10.3 beschikbaar voor installatie.
Let op! Zelf data migreren
- De installatie van rh-MariaDB 10.3 is geen upgrade van MariaDB 5.5 met migratie van de data. Er wordt naast de bestaande Database Server MariaDB 5.5 een compleet nieuwe Database Server MariaDB 10.3 geïnstalleerd. We moeten zelf de eigen databases uit MariaDB 5.5 exporteren en deze importeren in MariaDB 10.3
- Er kan slechts één Database Server actief- en verbonden zijn met de sql.sock in /var/lib/mysql/ en /var/lib/system-mysql/
MariaDB 5.5 moet eerst gestopt- en gedeactiveerd worden voordat de nieuwe MariaDB database Server geactiveerd- en gestart kan worden. - De Webconfig App: MariaDB Database Server werkt niet met de RH-MariaDB 10.3. Gebruik deze dus niet meer.
De app kan veilig verwijderd worden:
[root@testserver ~]# yum remove app-mariadb-core
Procedure
Exporteer eigen databases in MariaDB 5.5 (met datadir in /var/lib/mysql/) naar bijvoorbeeld /home/dbase_dump:
Note: De MariaDB 5.5 Database Server zal niet meer gebruikt worden en de eigen Databases kunnen er beter uit verwijderd worden.
# mysqldump -uroot -p'root-mysqlpassword' --opt
--databases piwigo > /home/dbase_dump/piwigo-dump.sql";
# mysqladmin -uroot -p'root-mysqlpassword' drop piwigo;
# mysqldump -uroot -p'root-mysqlpassword' --opt
--databases wordpress > /home/dbase_dump/wordpress-dump.sql";
#mysqladmin -uroot -p'root-mysqlpassword' drop wordpress;
Installeer rh-MariaDB 10.3
# yum install rh-mariadb103 --enablerepo=clearos-centos-sclo-rh # scl enable rh-mariadb103 bash
Stop en de-activeer MariaDB 5.5
# systemctl stop mariadb # systemctl disable mariadb
Activeer en start MariaDB 10.3
# systemctl enable rh-mariadb103-mariadb Created symlink from /etc/systemd/system/mysql.service to /usr/lib/systemd/system/rh-mariadb103-mariadb.service. Created symlink from /etc/systemd/system/mysqld.service to /usr/lib/systemd/system/rh-mariadb103-mariadb.service. Created symlink from /etc/systemd/system/multi-user.target.wants/rh-mariadb103-mariadb.service to /usr/lib/systemd/system/rh-mariadb103-mariadb.service. # systemctl start rh-mariadb103-mariadb
Confirmeer dat Database Server operationeel is
# mysql -V
mysql Ver 15.1 Distrib 10.3.13-MariaDB, for Linux (x86_64) using EditLine wrapper
# systemctl is-enabled mariadb rh-mariadb103-mariadb
disabled
enabled
# systemctl status rh-mariadb103-mariadb
rh-mariadb103-mariadb.service - MariaDB 10.3 database server
Loaded: loaded (/usr/lib/systemd/system/rh-mariadb103-mariadb.service; enabled; vendor preset: disabled)
Active: active (running) since Wed 2020-07-29 17:08:35 CEST; 6min ago
Docs: man:mysqld(8)
https://mariadb.com/kb/en/library/systemd/
Process: 9360 ExecStartPost=/usr/bin/scl enable $RH_MARIADB103_SCLS_ENABLED -- /opt/rh/rh-mariadb103/root/usr/libexec/mysql-check-upgrade (code=exited, status=0/SUCCESS)
Process: 9282 ExecStartPre=/usr/bin/scl enable $RH_MARIADB103_SCLS_ENABLED -- /opt/rh/rh-mariadb103/root/usr/libexec/mysql-prepare-db-dir %n (code=exited, status=0/SUCCESS)
Process: 9247 ExecStartPre=/usr/bin/scl enable $RH_MARIADB103_SCLS_ENABLED -- /opt/rh/rh-mariadb103/root/usr/libexec/mysql-check-socket (code=exited, status=0/SUCCESS)
Process: 9240 ExecStartPre=/usr/bin/scl enable $RH_MARIADB103_SCLS_ENABLED -- /usr/bin/scl_enabled rh-mariadb103 (code=exited, status=0/SUCCESS)
ain PID: 9325 (mysqld)
Status: "Taking your SQL requests now..."
CGroup: /system.slice/rh-mariadb103-mariadb.service
└─9325 /opt/rh/rh-mariadb103/root/usr/libexec/mysqld --basedir=/opt/rh/rh-mariadb103/root/usr
Jul 29 17:08:34 testserver scl[9282]: Database MariaDB is probably initialized in /var/opt/rh/rh-mariadb103/lib/mysql already, nothing is done.
Jul 29 17:08:34 testserver scl[9282]: If this is not the case, make sure the /var/opt/rh/rh-mariadb103/lib/mysql is empty before running mysql-prepare-db-dir.
Jul 29 17:08:35 testserver mysqld-scl-helper[9325]: 2020-07-29 17:08:35 0 [Note] /opt/rh/rh-mariadb103/root/usr/libexec/mysqld (mysqld 10.3.13-MariaDB) starting as process 9325 ...
Jul 29 17:08:35 testserver mysqld-scl-helper[9325]: 2020-07-29 17:08:35 0 [Warning] Could not increase number of max_open_files to more than 1024 (request: 4185)
Jul 29 17:08:35 testserver mysqld-scl-helper[9325]: 2020-07-29 17:08:35 0 [Warning] Changed limits: max_open_files: 1024 max_connections: 151 (was 151) table_cache: 421 (was 2000)
Waarschuwing max_open_files
Alles in het status rapport blijkt in orde, behalve de waarschuwing in de laatste 2 regels. Er is een request van 4185 voor max_open_files.
Het is geprobeerd de huidige limiet van 1024 te verhogen maar dat is niet gelukt. Hoewel het slechts een waarschuwing is proberen we dit toch te herstellen.
Zie voor uitleg en instructies van deze 'hack' het bestand
/usr/lib/systemd/system/rh-mariadb103-mariadb.service
Des te meer open files, des te zwaarder het systeemgeheugen belast wordt.
- Maak in dir /etc/systemd/system/ de directorie rh-mariadb103-mariadb.service.d
- Maak daarin het bestand limits.conf met daarin de code:
[Service]
LimitNOFILE=infinity - Herlaadt de systemdaemon na deze wijzigingen:
# systemctl daemon-reload
# systemctl restart rh-mariadb103-mariadb
MariaDB 10.3 beveiligen
MariaDB 10.3 is nu geïnstalleerd, maar zonder beveiliging d.w.z. dat de Database Server zonder inloggen te openen is.
Om MariaDB te beveiligen met een wachtwoord voeren we het volgende commando in:
# mysql_secure_installation
# mysql_secure_installation
NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MariaDB
SERVERS IN PRODUCTION USE! PLEASE READ EACH STEP CAREFULLY!
In order to log into MariaDB to secure it, we'll need the current
password for the root user. If you've just installed MariaDB, and
you haven't set the root password yet, the password will be blank,
so you should just press enter here.
Enter current password for root (enter for none):
OK, successfully used password, moving on...
Setting the root password ensures that nobody can log into the MariaDB
root user without the proper authorisation.
Set root password? [Y/n] y
New password:
Re-enter new password:
Password updated successfully!
Reloading privilege tables..
... Success!
Vervolgens worden nog enkele opties geboden die we accepteren:
- Verwijderen van anonieme gebruikers
- Blokkeren van toegang
buiten 'localhost', d.d.z. geen remote access
- Verwijder database 'test'
Maak gebruikers aan voor import eigen databases Piwigo en Wordpress
Alleen in het geval dat deze databases geexporteerd zijn van een andere server.
Zie voor de creatie van nieuwe databases Piwigo::Installeren en Wordpress::Installeren
Voordat we de eigen databases kunnen importeren moeten we de gebruikers aanmaken en authoriseren. Dit kan alleen door tijdelijk de databases Piwigo en Wordpress aan te maken.
Nadat de nieuwe gebruikers geauthoriseerd zijn moeten we de lege databases weer verwijderen.
# mysqladmin -uroot -p'root-mysqlpassword' CREATE piwigo; # mysql piwigo -uroot -p'root-mysqlpassword' -e "GRANT ALL PRIVILEGES ON piwigo.* TO piwigo@localhost IDENTIFIED BY 'piwigo-mysqlpassword'"; # mysqladmin -uroot -p'root-mysqlpassword' drop piwigo; # mysqladmin -uroot -p'root-mysqlpassword' CREATE wordpress; # mysql wordpress -uroot -p'root-mysqlpassword' -e "GRANT ALL PRIVILEGES ON wordpress.* TO wordpress@localhost IDENTIFIED BY 'wordpress-mysqlpassword'"; # mysqladmin -uroot -p'root-mysqlpassword' drop wordpress;
Importeer eigen Database Piwigo en Wordpress voorheen opgeslagen in /home/dbase_dump/
# mysql -uroot -p'root-mysqlpassword' < /home/dbase_dump/piwigo-dump.sql # mysql -uroot -p'root-mysqlpassword' < /home/dbase_dump/wordpress-dump.sql
De server draait nu op Database Server MariaDB 10.3
Data en mysql.sock locations
De nieuwe
MariaDB 10.3 gebruikt dezelfde mysql.sock locatie als MariaDB5.5, waardoor bijvoorbeeld phpMyAdmin, Piwigo en Wordpress automatisch naar de nieuwe database worden geleid.
MariaDB 10.3 heeft zijn eigen data directory, zijnde de reden dat we onze eigen databases zelf moeten verhuizen.
MariaDB 5.5 datadir= /var/lib/mysql
socket=/var/lib/mysql/mysql.sock
rh-MariaDB 10.3
datadir=/var/opt/rh/rh-mariadb103/lib/mysql
socket=/var/lib/mysql/mysql.sock
Verhuis MariaDB 10.3 MySQL data naar bindmount /store/live
Voor de rh-MariaDB 10.3 data-dir maken we ook een bindmount naar de dataopslag zoals ook al uitgevoerd is voor MariaDB 5.5 in de sectie Server::Gebruikerdata Opslag
Voor het verhuizen van MySQL data naar de centrale opslag hebben we te doen met één locatie /var/opt/rh/rh-mariadb103/lib/mysql
We gebruiken hiervoor hiervoor de bindmount directory /store/live/mariadb103/mysql
# mkdir /store/live/mariadb103 # mkdir /store/live/mariadb103/mysql
Verzamel informatie van de bron directory en voer commando's uit om de permissies van de bron naar het doel te synchroniseren.
# ls -la /var/opt/rh/rh-mariadb103/lib/mysql |head -n2 total 122936 drwxr-xr-x 4 mysql mysql 248 Oct 28 12:14 . # chown --reference /var/opt/rh/rh-mariadb103/lib/mysql /store/live/mariadb103 # chown --reference /var/opt/rh/rh-mariadb103/lib/mysql /store/live/mariadb103/mysql # chmod --reference /var/opt/rh/rh-mariadb103/lib/mysql /store/live/mariadb103 # chmod --reference /var/opt/rh/rh-mariadb103/lib/mysql /store/live/mariadb103/mysql
Valideer resultaat
# ls -al /store/live/mariadb103 |head -n2 total 0 drwxr-xr-x 3 mysql mysql 19 Oct 28 17:28 . # ls -al /store/live/mariadb103/mysql |head -n2 total 0 drwxr-xr-x 2 mysql mysql 6 Oct 28 17:28 .
Stop nu elke service die momenteel de bron directory mogelijk gebruikt.
# systemctl stop rh-mariadb103-mariadb
Verhuis de data naar de nieuwe locatie:
# rsync -av --delete /var/opt/rh/rh-mariadb103/lib/mysql/* /store/live/mariadb103/mysql/.
Verifieer dat de informatie op de nieuwe locatie is:
# ls -l /store/live/mariadb103/mysql/ total 122944 -rw-rw---- 1 mysql mysql 16384 Oct 28 11:08 aria_log.00000001 -rw-rw---- 1 mysql mysql 52 Oct 28 11:08 aria_log_control -rw-rw---- 1 mysql mysql 976 Oct 28 11:08 ib_buffer_pool -rw-rw---- 1 mysql mysql 12582912 Oct 28 11:08 ibdata1 -rw-rw---- 1 mysql mysql 50331648 Oct 28 11:08 ib_logfile0 -rw-rw---- 1 mysql mysql 50331648 Oct 28 10:47 ib_logfile1 -rw-rw---- 1 mysql mysql 12582912 Oct 28 11:08 ibtmp1 -rw-rw---- 1 mysql mysql 0 Oct 28 10:47 multi-master.info drwx------ 2 mysql mysql 8192 Oct 28 10:47 mysql -rw-rw---- 1 mysql mysql 16 Oct 28 10:47 mysql_upgrade_info drwx------ 2 mysql mysql 28 Oct 28 10:47 performance_schema -rw-rw---- 1 mysql mysql 24576 Oct 28 11:08 tc.log
Verwijder de data uit de oude locatie:
# rm -rf /var/opt/rh/rh-mariadb103/lib/mysql/* # ls -l /var/opt/rh/rh-mariadb103/lib/mysql/ total 0
Maak de bindmount aan in /etc/fstab door nieuwe lijn toe te voegen:
/store/live/mariadb103/mysql /var/opt/rh/rh-mariadb103/lib/mysql none bind,rw 0 0
Mount de toegevoegde devices en verifiëer de bindmounts :
# mount -a # ls -l /var/opt/rh/rh-mariadb103/lib/mysql total 122944 -rw-rw---- 1 mysql mysql 16384 Oct 28 11:08 aria_log.00000001 -rw-rw---- 1 mysql mysql 52 Oct 28 11:08 aria_log_control -rw-rw---- 1 mysql mysql 976 Oct 28 11:08 ib_buffer_pool -rw-rw---- 1 mysql mysql 12582912 Oct 28 11:08 ibdata1 -rw-rw---- 1 mysql mysql 50331648 Oct 28 11:08 ib_logfile0 -rw-rw---- 1 mysql mysql 50331648 Oct 28 10:47 ib_logfile1 -rw-rw---- 1 mysql mysql 12582912 Oct 28 11:08 ibtmp1 -rw-rw---- 1 mysql mysql 0 Oct 28 10:47 multi-master.info drwx------ 2 mysql mysql 8192 Oct 28 10:47 mysql -rw-rw---- 1 mysql mysql 16 Oct 28 10:47 mysql_upgrade_info drwx------ 2 mysql mysql 28 Oct 28 10:47 performance_schema -rw-rw---- 1 mysql mysql 24576 Oct 28 11:08 tc.log
Start de services die gestopt waren:
# systemctl start rh-mariadb103-mariadb
Upgrade MySQL MariaDB 10.3 naar MariaDB 10.5
In augustus 2020 is de met ClearOS release 7.8.1 (Final) meegeleverde database nog steeds de in 2012 uitgebrachte MariaDB 5.5, waarvan de End Of Life staat op april 2020.
Inmiddels is de laatste in februari 2024 door MaraDB
uitgebrachte stabiele versie 11.3 , maar op 4 april 2024 is er nog steeds geen ClearOS upgrade beschikbaar.
In de ClearOS Sofware Collections repository clearos-centos-sclo-rh is al wel rh-MariaDB 10.5 beschikbaar voor installatie.
- De installatie van rh-MariaDB 10.5 is een upgrade van MariaDB 10.3 met migratie van de data.
- Zie Red Hat Software Collections: Upgrading from rh-mariadb103 to rh-mariadb105
- Er kan slechts één Database Server actief- en verbonden zijn met de sql.sock in /var/lib/mysql/ en /var/lib/system-mysql/
MariaDB 10.3 moet eerst gestopt- en gedeactiveerd worden voordat de nieuwe MariaDB database Server geactiveerd- en gestart kan worden. - De Webconfig App: MariaDB Database Server werkt niet met de RH-MariaDB 10.3 & 10.5. Gebruik deze dus niet meer.
De app kan veilig verwijderd worden:
# yum remove app-mariadb-core
Backup MariaDB 10.3
Maak backups van de eigen databases Piwigo en Wordpress
# mysqldump -uroot -p'root-mysqlpassword' --opt
--databases piwigo > /home/dbase_dump/piwigo-dump.sql";
# mysqladmin -uroot -p'root-mysqlpassword' drop piwigo;
# mysqldump -uroot -p'root-mysqlpassword' --opt
--databases wordpress > /home/dbase_dump/wordpress-dump.sql";
#mysqladmin -uroot -p'root-mysqlpassword' drop wordpress;
Backup MariaDB data
Alle data van rh-mariadb103 worden per default opgeslagen in /var/opt/rh/rh-mariadb103/lib/mysql/, die middels een bindmount geplaatst zijn in /store/live/mariadb103/mysql/
Zie Verhuis MariaDB 10.3 MySQL data naar bindmount /store/live
De MariaDB103 data die opgeslagen zijn in /store/live/mariadb103/mysql/ hebben we later in het migratieproces nodig om deze te copieëren naar MariaDB105.
Als backuplocatie gebruiken we daarom de toekomstige MariaDB105 opslag in /store/live/mariadb105/mysql/
Creëer /store/live/mariadb105/mysql/
# mkdir /store/live/mariadb105 # mkdir /store/live/mariadb105/mysql
Verzamel informatie van de bron directory en voer commando's uit om de permissies van de bron naar het doel te synchroniseren.
# ls -la /var/opt/rh/rh-mariadb103/lib/mysql |head -n2 total 122936 drwxr-xr-x 4 mysql mysql 248 Oct 28 12:14 . # chown --reference /var/opt/rh/rh-mariadb103/lib/mysql /store/live/mariadb105 # chown --reference /var/opt/rh/rh-mariadb103/lib/mysql /store/live/mariadb105/mysql # chmod --reference /var/opt/rh/rh-mariadb103/lib/mysql /store/live/mariadb105 # chmod --reference /var/opt/rh/rh-mariadb103/lib/mysql /store/live/mariadb105/mysql
Maak backup en kopieer /store/live/mariadb103/mysql/ naar /store/live/mariadb105/mysql
# cp -a /store/live/mariadb103/mysql/* /store/live/mariadb105/mysql/
Check backup
# ls -l /store/live/mariadb105/mysql total 188544 -rw-rw---- 1 mysql mysql 81920 Apr 3 16:52 aria_log.00000001 -rw-rw---- 1 mysql mysql 52 Apr 3 16:52 aria_log_control -rw-rw---- 1 mysql mysql 4136 Apr 3 16:52 ib_buffer_pool -rw-rw---- 1 mysql mysql 79691776 Apr 3 16:52 ibdata1 -rw-rw---- 1 mysql mysql 100663296 Apr 4 15:37 ib_logfile0 -rw-rw---- 1 mysql mysql 12582912 Apr 3 16:53 ibtmp1 -rw-rw---- 1 mysql mysql 0 Dec 3 2020 multi-master.info drwx------ 2 mysql mysql 4096 Apr 3 10:57 mysql -rw-rw---- 1 mysql mysql 15 Apr 3 10:57 mysql_upgrade_info drwx------ 2 mysql mysql 20 Apr 3 10:57 performance_schema drwx------ 2 mysql mysql 8192 Apr 3 11:00 piwigo drwx------ 2 mysql mysql 8192 Mar 7 13:34 wordpress
Installeer rh-MariaDB 10.5
Zet slow shutdown
# mysql -uroot -p'root-mysqlpassword' -e "SET GLOBAL innodb_fast_shutdown = 0"
Stop rh-mariadb103 server
# systemctl stop rh-mariadb103-mariadb.service
Check status
# systemctl status -l rh-mariadb103-mariadb
● rh-mariadb103-mariadb.service - MariaDB 10.3 database server
Loaded: loaded (/usr/lib/systemd/system/rh-mariadb103-mariadb.service; enabled; vendor preset: disabled)
Drop-In: /etc/systemd/system/rh-mariadb103-mariadb.service.d
└─limits.conf
Active: inactive (dead)
…
Status: "MariaDB server is down"
Disable rh-mariadb103 server
# systemctl disable rh-mariadb103-mariadb.service Removed symlink /etc/systemd/system/multi-user.target.wants/rh-mariadb103-mariadb.service. Removed symlink /etc/systemd/system/mysql.service. Removed symlink /etc/systemd/system/mysqld.service.
Check status opnieuw
# systemctl status -l rh-mariadb103-mariadb
● rh-mariadb103-mariadb.service - MariaDB 10.3 database server
Loaded: loaded (/usr/lib/systemd/system/rh-mariadb103-mariadb.service; disabled; vendor preset: disabled)
Drop-In: /etc/systemd/system/rh-mariadb103-mariadb.service.d
└─limits.conf
Active: inactive (dead)
Installeer de RH-MARIADB105 collectie
Zorg dat in webconfig de repository clearos-centos-sclo-rh enabled is
Of voeg toe in commando : --enablerepo=clearos-centos-sclo-rh
# yum install rh-mariadb105-mariadb-server rh-mariadb105-mariadb-server-utils Installing: rh-mariadb105-mariadb-server x86_64 3:10.5.9-2.el7 rh-mariadb105-mariadb-server-utils x86_64 3:10.5.9-2.el7 Installing for dependencies: rh-mariadb105-mariadb x86_64 3:10.5.9-2.el7 rh-mariadb105-mariadb-common x86_64 3:10.5.9-2.el7 rh-mariadb105-mariadb-config x86_64 3:10.5.9-2.el7 rh-mariadb105-mariadb-errmsg x86_64 3:10.5.9-2.el7 rh-mariadb105-mariadb-libs x86_64 3:10.5.9-2.el7 rh-mariadb105-runtime x86_64 3.7-1.el7
Verifieer dat MariaDB 10.5 default datadir /var/opt/rh/rh-mariadb105/lib/mysql/ bestaat en dat deze nog leeg is.
# ls -l /var/opt/rh/rh-mariadb105/lib/mysql/ total 0
Vergelijk configuratie bestanden en maak 10.5 zonodig gelijk aan 10.3
# less /etc/opt/rh/rh-mariadb105/my.cnf [mysqld] symbolic-links=0 !includedir /etc/opt/rh/rh-mariadb105/my.cnf.d # less /etc/opt/rh/rh-mariadb103/my.cnf [mysqld] symbolic-links=0 !includedir /etc/opt/rh/rh-mariadb103/my.cnf.d
# less /etc/opt/rh/rh-mariadb105/my.cnf.d/mariadb-server.cnf [mysqld] datadir=/var/opt/rh/rh-mariadb105/lib/mysql socket=/var/lib/mysql/mysql.sock log-error=/var/opt/rh/rh-mariadb105/log/mariadb/mariadb.log pid-file=/run/rh-mariadb105-mariadb/mariadb.pid # # less /etc/opt/rh/rh-mariadb103/my.cnf.d/mariadb-server.cnf [mysqld] datadir=/var/opt/rh/rh-mariadb103/lib/mysql socket=/var/lib/mysql/mysql.sock log-error=/var/opt/rh/rh-mariadb103/log/mariadb/mariadb.log pid-file=/run/rh-mariadb103-mariadb/mariadb.pid
Migreer de data van 10.3 naar 10.5
Alle data van rh-mariadb103 zijn opgeslagen in /var/opt/rh/rh-mariadb103/lib/mysql/ (d.m.v. bindmount fysiek in /store/live/mariadb103/mysql/).
Voor de migratie naar 105 moeten deze data gecopiëerd worden naar
/var/opt/rh/rh-mariadb105/lib/mysql/
Deze data hebben wij voor de backup al gecopiëerd naar /store/live/mariadb105/mysql (Zie Maak backup)
Hier volstaat nu dus het plaatsen van een bindmount in /etc/fstab
Maak bindmount
# vi /etc/fstab
…
/store/live/mysql /var/lib/mysql none bind,rw 0 0
/store/live/system-mysql /var/lib/system-mysql none bind,rw 0 0
/store/live/mariadb103/mysql /var/opt/rh/rh-mariadb103/lib/mysql none bind,rw 0 0
/store/live/mariadb105/mysql /var/opt/rh/rh-mariadb105/lib/mysql none bind,rw 0 0
…
Activeer bindmount
# mount -a
Verifieer /var/opt/rh/rh-mariadb105/lib/mysql/ bevat nu de data
# ls -l /var/opt/rh/rh-mariadb105/lib/mysql/ total 188544 -rw-rw---- 1 mysql mysql 81920 Apr 3 10:57 aria_log.00000001 -rw-rw---- 1 mysql mysql 52 Apr 3 10:54 aria_log_control -rw-rw---- 1 mysql mysql 4197 Apr 3 10:54 ib_buffer_pool -rw-rw---- 1 mysql mysql 79691776 Apr 3 10:54 ibdata1 -rw-rw---- 1 mysql mysql 100663296 Apr 3 11:23 ib_logfile0 -rw-rw---- 1 mysql mysql 12582912 Apr 3 10:55 ibtmp1 -rw-rw---- 1 mysql mysql 0 Dec 3 2020 multi-master.info drwx------ 2 mysql mysql 4096 Apr 3 10:57 mysql -rw-rw---- 1 mysql mysql 15 Apr 3 10:57 mysql_upgrade_info drwx------ 2 mysql mysql 20 Apr 3 10:57 performance_schema drwx------ 2 mysql mysql 8192 Apr 3 11:00 piwigo drwx------ 2 mysql mysql 8192 Mar 7 13:34 wordpress
Enable mariadb105
# systemctl enable rh-mariadb105-mariadb.service Created symlink from /etc/systemd/system/mysql.service to /usr/lib/systemd/system/rh-mariadb105-mariadb.service. Created symlink from /etc/systemd/system/mysqld.service to /usr/lib/systemd/system/rh-mariadb105-mariadb.service. Created symlink from /etc/systemd/system/multi-user.target.wants/rh-mariadb105-mariadb.service to /usr/lib/systemd/system/rh-mariadb105-mariadb.service.
Start mariadb105
# systemctl start rh-mariadb105-mariadb.service
Check status mariadb105
# systemctl status rh-mariadb105-mariadb ● rh-mariadb105-mariadb.service - MariaDB 10.5 database server Loaded: loaded (/usr/lib/systemd/system/rh-mariadb105-mariadb.service; enabled; vendor preset: disabled) Drop-In: /etc/systemd/system/rh-mariadb105-mariadb.service.d └─limits.conf Active: active (running) ... Status: "Taking your SQL requests now..." ...
UPGRADE
# scl enable rh-mariadb105 -- mysql_upgrade -p'kn1kk@M!48' Phase 1/7: Checking and upgrading mysql database Processing databases mysql mysql.column_stats OK mysql... etc Phase 2/7: Installing used storage engines... Skipped Phase 3/7: Fixing views Phase 4/7: Running 'mysql_fix_privilege_tables' Phase 5/7: Fixing table and database names Phase 6/7: Checking and upgrading tables Processing databases information_schema performance_schema piwigo piwigo.pi_activity OK piwigo... etc wordpress wordpress.wp_actionscheduler_actions OK wordpress... etc Phase 7/7: Running 'FLUSH PRIVILEGES' OK
REBOOT
Waarschuwing Max-Open-Files
In het status rapport is er een waarschuwing in de laatste 2 regels. Er is een request van 4185 voor max_open_files.
Het is geprobeerd de huidige limiet van 1024 te verhogen maar dat is niet gelukt. Hoewel het slechts een waarschuwing is proberen we dit toch te herstellen.
Zie ook Waarschuwing Max-Open-Files
Maak in dir /etc/systemd/system/ de directorie rh-mariadb105-mariadb.service.d
Maak daarin het bestand limits.conf met daarin de code:
[Service] LimitNOFILE=infinity
Herlaadt de systemdaemon na deze wijzigingen:
# systemctl daemon-reload # systemctl restart rh-mariadb105-mariadb
MariaDB103 verwijderen
Na de installatie en activatie van MariaDB 10.5 kan MariaDB 10.3 verwijderd worden.
De data van rh-mariadb103 zijn virtueel opgeslagen in /var/opt/rh/rh-mariadb103/lib/mysql/ maar fysiek via een bindmount in /store/live/mariadb103/mysql/
Edit /etc/fstab en verwijder de bindmount
# vi /etc/fstab
…
/store/live/mysql /var/lib/mysql none bind,rw 0 0
/store/live/system-mysql /var/lib/system-mysql none bind,rw 0 0
# /store/live/mariadb103/mysql /var/opt/rh/rh-mariadb103/lib/mysql none bind,rw 0 0
/store/live/mariadb105/mysql /var/opt/rh/rh-mariadb105/lib/mysql none bind,rw 0 0
…
Mount en reboot
# mount -a
# reboot
Delete /store/live/mariadb103
# rm -rf /store/live/mariadb103 # ls -l /store/live/ total 4 drwxr-xr-x 13 root root 208 Sep 4 2022 home drwxr-xr-x 3 mysql mysql 27 Apr 4 14:31 mariadb105 drwxr-xr-x 4 mysql mysql 201 Apr 6 13:28 mysql drwxr-xr-x 5 system-mysql system-mysql 250 Apr 6 13:28 system-mysql drwxrwx--- 11 apache lanshare 4096 Mar 30 14:07 webroot
Verwijder rh-mariadb103
# yum remove rh-mariadb103* Loaded plugins: clearcenter-marketplace, fastestmirror ====================================================================================================================================== Package Arch Version Repository Size ====================================================================================================================================== Removing: rh-mariadb103 x86_64 3.3-5.el7 @clearos-centos-sclo-rh 0.0 rh-mariadb103-mariadb x86_64 3:10.3.32-2.el7 @clearos-centos-sclo-rh 38 M rh-mariadb103-mariadb-common x86_64 3:10.3.32-2.el7 @clearos-centos-sclo-rh 179 k rh-mariadb103-mariadb-config x86_64 3:10.3.32-2.el7 @clearos-centos-sclo-rh 366 rh-mariadb103-mariadb-errmsg x86_64 3:10.3.32-2.el7 @clearos-centos-sclo-rh 2.3 M rh-mariadb103-mariadb-server x86_64 3:10.3.32-2.el7 @clearos-centos-sclo-rh 85 M rh-mariadb103-runtime x86_64 3.3-5.el7 @clearos-centos-sclo-rh 29 k Transaction Summary ====================================================================================================================================== Remove 7 Packages
Vind en verwijder elders data van mariadb103
# updatedb # locate mariadb103* Verwijder alle nog aanwezige voorkomens mariadb103 Bijvoorbeeld Verwijder /var/opt/rh/rh-mariadb103 # rm -rf /var/opt/rh/rh-mariadb103/lib/
Permissies Website Root
In het HTTPD configuratiebestand '/etc/httpd/conf/httpd.conf' wordt de root van de website vastgelegd op '/var/www/html'.
Door middel van Samba wordt de website voorzien van bestanden met als eigenaar 'website' en groep 'lan'.
De permissies voor directories zijn 755 en bestanden 644. Hiermee heeft Apache in groep 'apache' voldoende rechten.
Zie ook sectie Samba: Samba Acces naar Webserver
Reset Permissies en Owners van Websites
Bij updates van websites van bijv. Wordpress en Piwigo worden soms onbedoeld permissies en/of ownerships gewijzigd.
Van alle submappen van /var/www/html moeten de permissies (terug)gezet worden naar 755 voor mappen en 644 voor bestanden.
Hiervoor heb ik het script reset-perm-users-websites gemaakt:
##########################################################################################
# Script voor het recursief re-setten van permissies en owners van map /var/www/html, #
# (alle websites). Alles apache:lanshare, mappen 755 en files 644 #
# Ben Makkink 27 maart2024 #
##########################################################################################
#!/bin/sh
chown -R apache:lanshare /var/www/;
chmod -R 755 /var/www/;
find /var/www/html -type f -name '*' -exec chmod 644 '{}' \;
Apache Configureren
Werkwijze
Met de installatie van de Apache Webserver wordt voor de module 'HTTPD' het default configuratiebestand 'httpd.conf' geplaatst in de directory /etc/httpd/conf/
Alleen als het echt niet anders kan, maken we wijzigingen in httpd.conf zelf.
Zeer uitgebreide informatie is te vinden in Apache HTTP Server Version 2.4 Documentation
Met het activeren van de Webserver app en het editen van de settings in de app worden twee bestanden aangemaakt in /etc/httpd/conf.d/ zijnde flex-80.conf en flex-443.conf
Waarschuwing:
Maak geen configuratiewijzigingen door de bestanden flex-80.conf en flex-443.conf handmatig te wijzigen.
Zodra we met de Webconfig Webserver App wijzigingen/updates aanbrengen zullen eigen directives overschreven worden.
Creëer voor eigen configuratieinstellingen een nieuw bestand in de map /etc/httpd/conf.d/ met daarin de eigen directives.
Includes
Het nader configureren van de webserver wordt uitgevoerd door het in /etc/httpd/conf.d plaatsen van include 'bestanden' *.conf
Deze bestanden worden geladen (in alphabetische volgorde) door de directive 'IncludeOptional conf.d/*.conf' geheel aan het eind van httpd.conf
In de /etc/httpd/conf.d map worden door Apps gegenereerde *.conf bestanden geplaatst met directives specifiek voor deze Apps zoals:
- authnz_external.conf
- authz_unixgroup.conf
- autoindex.conf
- awstats.conf
- BackupPC.conf
- flex-80.conf
- flex-443.conf
- php.conf
- ssl.conf
- userdir.conf
- welcome.conf
Om aanvullend eigen 'custom' instellingen voor deze Apps te maken moeten we niet in deze 'app.confs' gaan editen. De App-frontends, zoals de BackupPC App, zullen deze weer overschrijven.
Custom Includes
Voor aanvullende 'custom' instellingen moeten wij onze eigen *.conf bestand maken zoals gesuggereerd in Custom Apache Web Server Configuration
Op het moment van het samenstellen van deze site zijn dat:
We gebruiken voor onze eigen custom configuratie niet de door ClearOS gesuggereerde bestandsnaam clearos.default.conf, in plaats daarvan noemen we deze custom_httpd.conf
Zie voor een overzicht van de *.conf directives op deze server: httpd-include-confs.pdf
Apache Httpd.Conf
In het bestand /etc/httpd/conf/httpd.conf bevinden zich de Apache default directives zoals ClearOS deze instelt als de Apache Webserver geactiveerd wordt.
Bekijk hier het oorspronkelijke ClearOS httpd.conf bestand.
Enkele directives met betrekking tot security bekijken we nader:
<Directory /> |
Hiermee is het voor de gehele server niet toegestaan overrides op httpd directives te maken mbv .htaccess bestanden. Tevens wordt voor de gehele server de toegang aan de webgebruiker ontzegd |
| <Directory "/var/www"> AllowOverride None Require all Granted </Directory> |
Voor de directory (en subdiretories van) "/var/www" zijn overrides nog steed niet toegestaan maar de webgebruikers hebben wel toegang tot de mappen en bestanden in /var/www |
| <Files ".ht*"> Require all Denied </Files> |
Verberg '.ht*' bestanden zoals '.htaccess' door webtoegang te ontzeggen |
.htaccess
Het .htaccess bestand is een high-level website configuratiebestand.
Op Apache websites maakt het .htaccess bestand het mogelijk wijzigingen aan te brengen in de websiteconfiguratie zonder dat daarvoor de HTTPD configuratiebestanden bewerkt moeten worden.
Een .htaccessbestand wordt geplaatst in de root van websiteapps zoals Piwigo en Wordpress. Dit in tegenstelling tot httpd.conf en de 'includes' *.conf die buiten de webroot geplaatst zijn en dus onbereikbaar voor de webgebruiker.
Voorbeeld van een .htaccess bestand
Om in Piwigo een directe url naar originele fotos in ../piwigo/upload te blokkeren wordt een .htaccessbestand geplaatst in de /var/www/html/piwigo/upload met daarin één regel:
In de voorgaande sectie Apache Httpd.Conf zien we dat in de webroot AllowOverride None als default is gezet.
Een .htaccess bestand wordt echter pas uitgevoerd als ergens in de httpd configuratie AllowOverride All wordt gezet.
(AllowOverride kent naast 'None' en 'All' de directive types
'FileInfo', 'Options', 'AuthConfig' en 'Limit').
Dit kunnen we bewerkstelligen door in Webconfig > Server > Web > Web server > Websites > Edit > Settings > Allow [.htaccess] Override de optie 'Enabled' te kiezen. In dat geval wordt in het flex-80.conf bestand het volgende toegevoegd:
<Directory /var/www/html> AllowOverride All </Directory>
Kwetsbaarheid
In ons .htaccess voorbeeld plaatsen we feitelijk een directive binnen de webroot en met wat hackwerk bereikbaar voor webgebruikers.
In theorie is het nu mogelijk middels Piwigo, in plaats van een foto, een .htaccess bestand met eigen directives naar /var/www/html/piwigo/upload te uploaden die daarmee het aanwezige .htaccess bestand vervangt.
Oplossing
Waar mogelijk worden .htaccess bestanden door mij niet toegepast.
Door in Webconfig Allow [.htaccess] Override de default optie 'Disabled' te laten worden eventuele .htaccess bestanden niet uitgevoerd.
De directives in de .htaccess bestanden zijn echter nodig voor het correct functioneren van o.a Piwigo en Wordpress.
Dit lossen we op door als root configuratiebestanden aan te maken in /etc/httpd/conf.d zoals piwigo.conf en wordpress.conf waarin we de directives uit de .htaccess bestanden plaatsen.
Let hierbij op dat het pad van de directive gelijk is aan het pad waar het .htaccess bestand gevonden wordt.
In het voorbeeld van het Piwigo .htaccess bestand met de directe url blokkering vervangen we het .htaccess bestand door onderstaande directive in piwigo.conf
<Directory /var/www/html/piwigo/upload> Require all denied </Directory>
Custom Httpd Configuratie
Het nader configureren van de webserver doen we door het in /etc/httpd/conf.d plaatsen van include bestanden *.conf
Deze bestanden worden geladen in alphabetische volgorde.
Let op: Voorkom dat directives in later geladen *.conf's eerder geladen directives overschrijven.
Virtual hosts kunnen slechts éénmaal gezet worden
We moeten ons realiseren dat de virtualhosts gedefinieerd in de flex-{80,443}.conf bestanden slechts éénmaal geladen kunnen worden.
Als we eigen custom directives toe willen voegen binnen de virtual hosts zit er niet anders op dan, zoals gesuggereerd in Custom Apache Web Server Configuration, de inhoud van de flex-{80,443}.conf bestanden over te hevelen naar een bestand te noemen clearos.default.conf en vervolgens hier de eigen VHost directives toe te voegen. De nu lege flex bestanden moeten daarna verwijderd worden.
Conflict
Als nu in Webconfig een wijziging in de Webserver configuratie gemaakt wordt, het zij manueel of middels een automatische ClearOS update, dan worden er nieuwe flex-{80,443}.conf bestanden aangemaakt met daarin de nieuwe directives en ook de potentieel ge-update VHost directives.
Bij het opnieuw opstarten van HTTPD wordt onze custom clearos.default.conf als eerste geladen en vóór de beide flex-{80,443}.conf bestanden. Als er wijzigingen in de VHost directives zijn gemaakt dan worden deze nu niet geladen.
Dit word door ClearOS radicaal opgelost door bij een update van de Webserver App het clearos.default.conf bestand compleet te verwijderen. Hierdoor worden nu de VHost directives in de nieuwe flex-{80,443}.conf bestanden wél geladen.
Maar nu zijn echter onze eigen custom directives verdwenen, zonder dat we hiervan bij bijv. een automatische update een notificatie krijgen.
Om deze automatische delete te voorkomen noemen we daarom ons custom Webserver configuratiebestand: custom_httpd.conf
Nu is het wel aan ons
de beide flex-{80,443}.conf bestanden te integreren.
Automatische integratie van de nieuwe flex-{80,443}.conf bestanden
In de hierboven geschetste situatie worden de potentieel nieuwe VHost directives in de flex-{80,443}.conf bestanden nu weliswaar niet geladen maar onze website reageert tenminste nog zoals we het gewend waren met de oude custom_httpd.conf
Middels het script flex-integrate dat bijvoorbeeld elke dag draait wordt ervoor gezorgd dat de nieuwe flex-{80,443}.conf bestanden gedetecteerd worden, geintegreerd worden in custom_httpd.conf en Admin hiervan een notificatie krijgt.
Voor nadere 'custom' configuratie van onze Apache Webserver maken we een nieuw bestand aan in /etc/httpd/conf.d en noemen het 'custom_httpd.conf'.
In het custom_httpd.conf bestand integreert het script de inhoud van:
- flex-80.conf Met de via de Webser App gemaakte directives voor de VirtualHost met poort 80 (HTTP)
- flex-443.conf Met de via de Webser App gemaakte directives voor de VirtualHost met poort 443 (HTTPS)
- custom_httpd.inc Met de aanvullende eigen custom webserver directives
Het laatstgenoemde bestand custom_httpd.inc plaatsen we ook in /etc/httpd/conf.d/ en hierin zetten we al onze eigen custom directives. Zie sectie Custom_httpd.inc
Bekijk of download het custom_httpd.conf eindresultaat.
De onderdelen van custom_httpd.conf uitgelicht
Hieronder de onderdelen waaruit custom_httpd.conf samengebouwd wordt.
AWStats access log directives binnen VirtualHosts
De highlight secties betreffen de directives binnen de VirtualHosts voor de AWstats access logs:
# ====================================================================
# Flex-80.conf inclusief eigen directives binnen VirtualHost
# uit /etc/httpd/conf.d/custom_httpd.inc
# ====================================================================
<VirtualHost *:80>
ServerName makkink.eu
ServerAlias *.makkink.eu
DocumentRoot /var/www/html
ErrorLog /var/log/httpd/error_log
CustomLog /var/log/httpd/access_log combined
<Location />
Options -Indexes +FollowSymLinks -IncludesNOExec
</Location>
# START eigen directives binnen vHosts
# ----------------------------------------------------------------
CustomLog /var/log/httpd/wandelen_access_log combined env=wandelen
CustomLog /var/log/httpd/nbp_access_log combined env=nbp
CustomLog /var/log/httpd/blog_access_log combined env=blog
# ----------------------------------------------------------------
<Location /manuals>
Options +Indexes +FollowSymLinks -IncludesNOExec
</Location>
<Location /error>
Options +Indexes +FollowSymLinks +IncludesNOExec
</Location>
# ----------------------------------------------------------------
# EINDE eigen directives binnen vHosts
</VirtualHost>
<Directory /var/www/html>
Options -Indexes +FollowSymLinks -IncludesNOExec
<FilesMatch \.php$>
SetHandler "proxy:fcgi://127.0.0.1:9073"
</FilesMatch>
Require all granted
</Directory>
# ====================================================================
# Flex-443.conf inclusief eigen directives binnen VirtualHost
# uit /etc/httpd/conf.d/custom_httpd.inc
# ====================================================================
<VirtualHost *:443>
ServerName makkink.eu
ServerAlias *.makkink.eu
DocumentRoot /var/www/html
ErrorLog /var/log/httpd/error_log
CustomLog /var/log/httpd/access_log combinedSSLEngine on
SSLCertificateFile /etc/letsencrypt/live/www.makkink.eu/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/www.makkink.eu/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/www.makkink.eu/chain.pem
# No weak export crypto allowed
SSLHonorCipherOrder on
SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE:...bla: bla: bla:...:!3DES:!aNULL:!MD5
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
downgrade-1.0 force-response-1.0
<Location />
Options -Indexes +FollowSymLinks -IncludesNOExec
</Location>
# START eigen directives access_logs binnen vHosts
# ----------------------------------------------------------------
CustomLog /var/log/httpd/wandelen_access_log combined env=wandelen
CustomLog /var/log/httpd/nbp_access_log combined env=nbp
CustomLog /var/log/httpd/blog_access_log combined env=blog
# ----------------------------------------------------------------
<Location /manuals>
Options +Indexes +FollowSymLinks -IncludesNOExec
</Location>
<Location /error>
Options +Indexes +FollowSymLinks +IncludesNOExec
</Location>
# ----------------------------------------------------------------
# EINDE eigen directives binnen vHosts
</VirtualHost>
# ====================================================================
# Eigen HTTPD Directives buiten de VirtualHosts
# ====================================================================
# Access_Logs: Zet 'env' voor paden 'wandelen', 'nbp' en 'blog' vanuit
# de webroot en geef deze env's een alias (wandelen, nbp en blog)
# --------------------------------------------------------------------
SetEnvIf Request_URI "^/wandelen/" wandelen
CustomLog logs/wandelen_access_log combined env=wandelen
SetEnvIf Request_URI "^/nbp/" nbp
CustomLog logs/nbp_access_log combined env=nbp
SetEnvIf Request_URI "^/blog/" blog
CustomLog logs/blog_access_log combined env=blog
Access_log van specifieke subdirectory
Per default wordt er door Apache access logging uitgevoerd over de complete httpd root website.
De drie hierboven toegevoegde 'CustomLog' directives voor 'wandelen', 'nbp' en 'blog' binnen de beide VirtualHosts definieren de customlog files.
Vervolgens worden buiten de vHost secties de paden vanuit de webroot (/var/www/html) gezet met 'SetEnvIf' voor 'wandelen', 'nbp' en 'blog' aangevuld met een alias (wandelen, nbp en blog).
Na deze toevoegingen in 'custom_httpd.conf' en een herstart van de httpd service zijn nieuwe de access_log bestanden wandelen_access_log, nbp_access_log en blog_access_log te vinden in '/var/log/httpd/'.
Deze access-logs worden gebruikt door Awstats voor het tonen van statistieken.
Zie hiervoor sectie Awstats en Access-logs
Vervolg Eigen HTTPD Directives buiten de VirtualHosts
Options voor Website
Blokkeer tonen van directory-index, sta volgen van symbolic links toe, maar blokkeer uitvoerbare bestanden
Voeg onderstaande regels toe aan 'custom-httpd.conf':
<Directory /var/www/html>
Options -Indexes +FollowSymLinks -IncludesNOExec
Require all granted
</Directory>
ServerAdmin e-mail adres
Het adres waar problemen met de server naar toe gemaild moeten worden. Dit adres verschijnt op sommige server gegenereerde pagina's, zoals errror documenten.
Voeg onderstaande regels toe aan 'custom-httpd.conf':
ServerAdmin ben@makkink.eu
DirectoryIndex
In HTTPD.CONF wordt de DirectoryIndex gezet, waarmee wordt bepaald welk bestand Apache opent als er een Directory wordt gevraagd.
Deze setting is alleen index.html. Bij sommige oude webpagina's wordt nog index.htm gebruikt. Deze optie voegen we toe.
DirectoryIndex voor index.php wordt verzorgd in php.conf
Voeg onderstaande regels toe aan 'custom-httpd.conf':
<IfModule dir_module>
DirectoryIndex index.html index.htm
</IfModule>
Mapping naar bestanden buiten de httpd root
Met de alias wordt een korte url bewerkstelligd dus een soort van symbolic link. Met de directive worden nadere instellingen gemaakt, o.a. het beperken wie toegang heeft.
Voeg onderstaande regels toe aan 'custom-httpd.conf':
Alias /manuals "/usr/share/doc"
<Directory "/usr/share/doc">
Options Indexes
AllowOverride None
Require ip 192.168.178.0/24
# Require all granted
</Directory>
NOTE:
Binnen de Virtual Host is door ClearOS ook nog een <Location /> directive geplaatst:
<Location /manuals>
Options -Indexes +FollowSymLinks -IncludesNOExec
</Location>
Een <Location> directive overrules een <Directory> directive.
Dus om naar een map buiten de webroot te kunnen gaan moet ook de <Location> directive gerevoked worden.
Omdat het zetten van de directive binnen de Virtual Host gedaan is moet ook de 'Indexes' revoke voor /manuals binnen de Virtuals Host plaatsvinden.
Deze directive moet net als de CustomLog setting toegevoegd worden aan
Custom_httpd.inc
<Location /> Options -Indexes +FollowSymLinks -IncludesNOExec </Location> # START eigen directives access_logs binnen vHosts # ---------------------------------------------------------------- CustomLog /var/log/httpd/wandelen_access_log combined env=wandelen CustomLog /var/log/httpd/nbp_access_log combined env=nbp CustomLog /var/log/httpd/blog_access_log combined env=blog # ---------------------------------------------------------------- <Location /manuals> Options +Indexes +FollowSymLinks -IncludesNOExec </Location> <Location /error> Options +Indexes +FollowSymLinks +IncludesNOExec </Location> # ---------------------------------------------------------------- # EINDE eigen directives binnen vHosts </VirtualHost>
Ook voor Error Messaging is een <Location> revoke nodig maar nu voor Options +IncludesNOExec zoals hierboven zichtbaar.
Zie ook
het configuratiebestand /etc/httpd/conf.d/errordocs.conf.
Forceer domein www.makkink.eu naar HTTPS
Webserverconfiguratie die er voor zorgt dat gebruikers altijd doorverwezen worden naar https://www.makkink.eu
Voeg onderstaande regels toe aan 'custom-httpd.conf':
# Forceer domein www.makkink.eu naar HTTPSRewriteEngine On RewriteCond %{SERVER_PORT} 80 RewriteRule ^(.*)$ https://www.makkink.eu/$1 [R,L] # Voorbeeld HTTPS met uitzondering voor www/makkink.eu/blog ## RewriteEngine On # RewriteCond %{SERVER_PORT} 443 # RewriteRule ^blog/?(.*) http://www.makkink.eu/blog/$1 [R,L] # RewriteCond %{SERVER_PORT} 80 # RewriteCond %{REQUEST_URI} !^/blog # RewriteRule ^(.*)$ https://www.makkink.eu/$1 [R,L]
Custom_httpd.conf compileren met script
Als de Webserver admin een notificatie zou krijgen dat er een update gedaan is in de Webserverconfiguratie is het vrij eenvoudig voor hem de nieuwe flex-{80,443}.conf bestanden opnieuw te mergen in custom_httpd.conf.
Hiervoor heb ik een script opgezet dat dagelijks draait en nieuwe
flex-{80,443}.conf bestanden detecteerd.
Maar in plaats van alleen een notificatie naar de admin te sturen met de instructie de integratie handmatig uit te voeren, gaat het script verder met het compileren van een nieuwe custom_httpd.conf.
Flex-integrate script
Het script /usr/local/bin/flex-integrate laten we middels een cron dagelijks uitvoeren en het doorloopt de volgende stappen:
- Check of bestanden flex-80.conf en/of flex-443.conf bestaan, zo ja dan is er een webserver-update geweest. Maak deze detectie once-only en hernoem bestanden naar flex80.new en flex443.new
- Compileer een bestand custom_httpd.tmp met selecties uit de bestanden flex80.new, flex443.new en het bestand custom_httpd.inc. Dit laatste bestand is het bestand waarin we de eigen custom httpd directives peprepaeerd hebben.
- Zodra gereed, hernoem de compilatie naar custom_httpd.conf. De op dat moment actieve httpdconfiguratie wordt hiermee overschreven.
- Reboot de webserver waardoor het nieuwe configuratiebestand geladen wordt.
- Stuur een e-mail naar de Admin ter notoficatie dat er een webserver-update is geweest en dat deze geïntegreerd is in het custom-httpd.conf configuratiebestand.
Custom_httpd.inc
Voor het integreren van de nieuwe
flex-{80,443}.conf bestanden prepareren we het bestand custom_httpd.inc met daarin onze eigen custom directives.
Zie voor het complete document
custom_httpd.inc
Het is belanrijk dat alle custom directives die binnen de VHosts geplaats moeten worden, in dit bestand opgenomen zijn tussen de START en EINDE regels.
Alle verdere custom directives die we toe willen voegen moeten we opnemen ná de regel:
Eigen HTTPD Directives buiten de VirtualHosts
# ************************************************************************
# * custom_httpd.inc Ben Makkink 25-09-2020 *
# * Eigen HTTPD directives toe te voegen aan flex80 en flex443 in het *
# * nieuwe HTTPD configuratiebestand 'custom_httpd.conf' *
# ************************************************************************
# Directives in te voegen binnen de vHosts 80 en 443
# ==================================================
# START eigen directives access_logs binnen vHosts
# ----------------------------------------------------------------
CustomLog /var/log/httpd/wandelen_access_log combined env=wandelen
CustomLog /var/log/httpd/nbp_access_log combined env=nbp
CustomLog /var/log/httpd/blog_access_log combined env=blog
# ----------------------------------------------------------------
<Location /manuals>
Options +Indexes +FollowSymLinks -IncludesNOExec
</Location>
<Location /error>
Options +Indexes +FollowSymLinks +IncludesNOExec
</Location>
# ----------------------------------------------------------------
# EINDE eigen directives binnen vHosts
# Eigen HTTPD Directives buiten de VirtualHosts
# ====================================================================
# Access_Logs: Zet 'env' voor paden 'wandelen', 'nbp' en 'blog' vanuit
# de webroot en geef deze env's een alias (wandelen, nbp en blog)
# --------------------------------------------------------------------
SetEnvIf Request_URI "^/wandelen/" wandelen
CustomLog logs/wandelen_access_log combined env=wandelen
SetEnvIf Request_URI "^/nbp/" nbp
CustomLog logs/nbp_access_log combined env=nbp
SetEnvIf Request_URI "^/blog/" blog
CustomLog logs/blog_access_log combined env=blog
# Het e-mail adres waar problemen met de server naar toe gemaild worden
ServerAdmin ben@makkink.eu
# DirectoryIndex: zet het bestand dat Apache opent als een directory
# wordt gevraagd (is in httpd.conf alleen index.html)
<IfModule dir_module>
DirectoryIndex index.html index.htm
</IfModule>
# Mapping naar bestanden buiten de webroot met een alias en opties
# Geef toegang voor alleen de hosts op het LAN
Alias /manuals "/usr/share/doc"
<Directory "/usr/share/doc">
Options Indexes
AllowOverride None
Require ip 192.168.178.0/24
# Require all granted
</Directory>
# Forceer domein www.makkink.eu naar HTTPS
# NIET OP TESTSERVER, certificaat is voor www.makkink.eu(homeserver)
<Directory /var/www/html>
RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://www.makkink.eu/$1 [R,L]
</Directory>
# Voorbeeld voor een uitzondering van www/makkink.eu/blog
# <Directory /var/www/html>
# RewriteEngine On
# RewriteCond %{SERVER_PORT} 443
# RewriteRule ^blog/?(.*) http://www.makkink.eu/blog/$1 [R,L]
# RewriteCond %{SERVER_PORT} 80
# RewriteCond %{REQUEST_URI} !^/blog
# RewriteRule ^(.*)$ https://www.makkink.eu/$1 [R,L]
#</Directory>
Webserver Update integreren in custom-httpd.conf
Bestand /usr/local/bin/flex-integrate (Klik hier voor download van script)
Het commando # sed wordt gebruikt om gespecificeerde secties code/text uit de bestanden flex80.new, flex443.new en custom_httpd.inc te kopieren en te concateneren in custom_httpd.conf
Zie ook
sed command-with-examples
In het script zelf worden de stappen nader toegelicht.
#!/bin/bash # ************************************************************************ # * Flex-integrate detectie en notificatie Ben Makkink 24 juli 2020 * # * Script detecteert nwe flex-80.conf en flex-443.conf bestanden als * # * gevolg van een Webconfig update van de HTTPDconfiguratie. * # * De nwe bestanden worden hernoemd naar flex80.new en flex443.new * # * en vervolgens worden deze samen met de eigen directives in * # * /etc/httpd/conf.d/custom_httpd.inc geintegreerd in het webserver * # * configuratiebestand /etc/httpd/conf.d/custom_httpd.conf * # * Er wordt ook een notificatie naar de webadmin gestuurd. * # * Dit script 'flex-integrate' maakt gebruik van de volgende bestanden: * # * - /etc/httpd/conf.d/custom_httpd.inc * # * - /etc/httpd/conf.d/flex80.new * # * - /etc/httpd/conf.d/flex443.new * # * - /usr/local/bin/flex-mail.txt * # ************************************************************************ # Verifieer dat de voor script benodigde bestanden aanwezig zijn. if [[ ! -f /etc/httpd/conf.d/custom_httpd.inc || ! -f /usr/local/bin/flex-mail.txt ]] then /usr/sbin/sendmail ben@makkink.eu </usr/local/bin/flex-integrate-error.txt; exit; fi # check voor webserver update resulterend in nieuwe flex-{80,443}.conf's if [ -f /etc/httpd/conf.d/flex-80.conf ] then # hernoem flex-{80,443}.conf's naar flex{80,443}.new zodat deze niet # geladen worden maar beschikbaar blijven voor integratie in # custom-httpd.conf mv /etc/httpd/conf.d/flex-80.conf /etc/httpd/conf.d/flex80.new; if [ -f /etc/httpd/conf.d/flex-443.conf ] then mv /etc/httpd/conf.d/flex-443.conf /etc/httpd/conf.d/flex443.new; fi # ************************************************************************* # * Integreer bestanden flex80.new en flex443.new met custom_httpd.inc * # * naar het webserver configuratiebestand 'custom_httpd.conf' * # ************************************************************************* # Maak header van custom_httpd.conf str1="# -------------------------------------------------------------------" str2="# Dit bestand is een samenvoeging van /etc/httpd/conf.d/flex-80.conf," str3="# ../flex-443.conf en ../custom_httpd.inc" str4="# Breng wijzigingen in directives alleen aan in ../custom_httpd.inc" str5="# Run script /usr/local/bin/make-conf om wijzigigngen door te voeren." str6="# -------------------------------------------------------------------" # Aanvullende infostrings str7="# Flex-80.conf inclusief eigen directives binnen VirtualHost" str8="# uit /etc/httpd/conf.d/custom_httpd.inc" str9="# ===================================================================" str10="# Flex-443.conf inclusief eigen directives binnen VirtualHost" # Print script header in bestand /etc/httpd/conf.d/custom_httpd.tmp printf "$str1 \n$str2 \n$str3 \n$str4 \n$str5 \n$str6 \n \n$str9 \n$str7 \n$str8 \n$str9 \n" >> /etc/httpd/conf.d/custom_httpd.tmp; # Print inhoud flex80.new tot de regel met '</VirtualHost>' sed -n '/<\/VirtualHost>/q;p' /etc/httpd/conf.d/flex80.new >> /etc/httpd/conf.d/custom_httpd.tmp; # Concatenate de inhoud van custom_httpd.inc regels 'START' t/m 'EINDE' sed -n '/START/,/EINDE/p' /etc/httpd/conf.d/custom_httpd.inc >> /etc/httpd/conf.d/custom_httpd.tmp; # Concatenate van flex80.new van lijn met </VirtualHost> tot einde bestand. sed -n '/<\/VirtualHost>/,$p' /etc/httpd/conf.d/flex80.new >> /etc/httpd/conf.d/custom_httpd.tmp; # Concatenate infostring printf "\n$str9 \n$str10 \n$str8 \n$str9 \n" >> /etc/httpd/conf.d/custom_httpd.tmp; # Concatenate inhoud flex443.new tot de regel met '</VirtualHost>' sed -n '/<\/VirtualHost>/,$p' /etc/httpd/conf.d/flex443.new >> /etc/httpd/conf.d/custom_httpd.tmp; # Concatenate de inhoud van custom_httpd.inc regels 'START' t/m 'EINDE' sed -n '/START/,/EINDE/p' /etc/httpd/conf.d/custom_httpd.inc >> /etc/httpd/conf.d/custom_httpd.tmp; # Concatenate inhoud flex443.new de regel met '</VirtualHost>' tot einde bestand sed -n '/<\/VirtualHost>/,$p' /etc/httpd/conf.d/flex443.new >> /etc/httpd/conf.d/custom_httpd.tmp; # Concatenate infostring printf "\n$str9 \n" >> /etc/httpd/conf.d/custom_httpd.tmp; # Concatenate inhoud custom_httpd.inc regels 'Eigen HTTPD Directives' tot einde bestand sed -n '/Eigen HTTPD Directives/,$p' /etc/httpd/conf.d/custom_httpd.inc >> /etc/httpd/conf.d/custom_httpd.tmp; # Hernoem custom_httpd.tmp naar custom_httpd.conf en herstart de webserver met de nwe custom_httpd.conf # ------------------------------------------------------------------------ mv /etc/httpd/conf.d/custom_httpd.tmp /etc/httpd/conf.d/custom_httpd.conf service httpd restart # stuur notificatie naar de admin met de inhoud van flex-mail.txt # -------------------------------------------------------------- /usr/sbin/sendmail ben@makkink.eu </usr/local/bin/flex-mail.txt fi
Taak Schedulen
Voeg eencron toe met commando #crontab -e
30 0 * * * /usr/local/bin/flex-integrate &> /dev/null
Het script wordt elke dag 30 minuten na 0 uur uitgevoerd.
Mails ter notificatie
Benodigde bestanden missen
In bovenstaand script flex-integrate wordt als eerste gecontoleerd of de door het script benodigde bestanden beschikbaar zijn. Als dit niet het geval blijkt te zijn dan wordt de uitvoering van het script gestopt na het sturen van een notificatie e-mail naar de Admin met de inhoud van het bestand /usr/local/bin/flex-integrate-error.txt
To: ServerAdmin Subject: Webserver update missende bestanden Er heeft een update aan de Webserver configuratie plaatsgevonden. Als resultaat zijn in /etc/httpd/conf.d/ twee bestanden gecreëerd zijnde: - flex-80.conf - flex-443.conf De inhoud van deze twee bestanden moet geïntegreerd worden in /etc/httpd/conf.d/custom-httpd.conf Dit wordt automatisch uitgevoerd met script 'flex-integrate'. De hierbij benodigde bestanden custom_httpd.inc en/of flex-mail.txt kunnen echter niet gevonden worden. De integratie is niet uitgevoerd! Herstel de benodigde bestanden of voer de integratie op de hand uit. Zie ook https://www.makkink.eu/exploringlinux/server7/html/apache.html#custom-httpd
Integratie succesvol uitgevoerd
Als het script flex-integrate succesvol afgerond is wordt als
laatste ter notificatie een e-mail de Admin gestuurd:
/usr/sbin/sendmail ben@makkink.eu < /usr/local/bin/flex-mail.txt
Met de inhoud van het bestand /usr/local/bin/flex-mail.txt
To: ServerAdmin Subject: Webserver update is uitgevoerd Er is een update/wijziging van de Webserverconfiguratie uitgevoerd. Als resultaat zijn in /etc/httpd/conf.d/ twee nieuwe bestanden gecreëerd, zijnde: - flex-80.conf - flex-443.conf Met het script 'flex-integrate' is de inhoud van deze twee bestanden geïntegreerd in /etc/httpd/conf.d/custom-httpd.conf en de bestanden zijn hernoemd naar respectievelijk flex80.new en flex443.new De webserver is opnieuw gestart om het nieuwe configuratiebestand 'custom-httpd.conf' te laden. Zie ook https://www.makkink.eu/exploringlinux/server7/html/apache.html#custom-httpd
Opruimen
De beide flex{80,443}.new bestanden kunnen we laten voor wat ze zijn, ze worden bij een volgende Webserver-Update gewoon overschreven.
Errordocs.Conf
Als de Apache default instellingen voor 'error messages' gebruikt worden, dan wordt alleen het errornummer geretourneerd zonder verdere uitleg.
Tot en met ClearOS 6.6
was er een sectie in httpd.conf waarin instellingen gemaakt kunnen worden om voor bepaalde (of alle) errors uitgebreide Error Documenten weergegeven kunnen worden. Tevens zijn enkele errordocumenten door mij nog verder naar eigen wens aangepast. Zie hiervoor Server::Apache Error Messaging
Deze ErrorDocuments in de 'error' directory bevatten HTTP error messages in meerdere talen. Als de voorkeur taal van een client beschikbaar is dan wordt deze automatisch geselecteerd.
Verdwenen uit ClearOS 7
In ClearOS 7 is de sectie met ErrorDocument directives echter uit httpd.conf verdwenen, de meertalige Error Documents daarentegen zijn echter nog steeds aanwezig en zelfs op twee locaties:
- /usr/share/httpd/error/
- /usr/clearos/sandbox/usr/share/httpd/error/
Omdat ik toch van de wat duidelijker informatie inclusief hints en links gebruik wens te maken, heb ik in de map /etc/httpd/conf.d hiervoor een configuratiebestand errordocs.conf aangemaakt.
In dit configuratiebestand /etc/httpd/conf.d/errordocs.conf zijn de relevante directives opgenomen zoals deze in het ClearOS 6.6 httpd.conf bestand voorkwamen:
# errordocs.conf Ben Makkink 05-12-2015 # ErrorDocuments directives om multilinguale HTTP foutmeldingen weer te
# geven # Gebruik Alias /error/ om de locatie aan te geven van de ErrorDocumenten
Alias /error/ "/usr/share/httpd/error/" # Geef de benodigde permissies en instellingen voor het correct weergeven <IfModule mod_negotiation.c> <IfModule mod_include.c> <Directory "/usr/share/httpd/error"> AllowOverride None Options IncludesNoExec AddOutputFilter Includes html AddHandler type-map var Require all granted LanguagePriority nl en es de fr ForceLanguagePriority Prefer Fallback </Directory> # Verwijder de '#' voor het ErrorDocument waarvoor de uitgebreide optie # gewenst is # ErrorDocument 400 /error/HTTP_BAD_REQUEST.html.var ErrorDocument 401 /error/HTTP_UNAUTHORIZED.html.var ErrorDocument 403 /error/HTTP_FORBIDDEN.html.var ErrorDocument 404 /error/HTTP_NOT_FOUND.html.var # ErrorDocument 405 /error/HTTP_METHOD_NOT_ALLOWED.html.var # ErrorDocument 408 /error/HTTP_REQUEST_TIME_OUT.html.var # ErrorDocument 410 /error/HTTP_GONE.html.var # ErrorDocument 411 /error/HTTP_LENGTH_REQUIRED.html.var # ErrorDocument 412 /error/HTTP_PRECONDITION_FAILED.html.var # ErrorDocument 413 /error/HTTP_REQUEST_ENTITY_TOO_LARGE.html.var # ErrorDocument 414 /error/HTTP_REQUEST_URI_TOO_LARGE.html.var # ErrorDocument 415 /error/HTTP_UNSUPPORTED_MEDIA_TYPE.html.var # ErrorDocument 500 /error/HTTP_INTERNAL_SERVER_ERROR.html.var # ErrorDocument 501 /error/HTTP_NOT_IMPLEMENTED.html.var # ErrorDocument 502 /error/HTTP_BAD_GATEWAY.html.var # ErrorDocument 503 /error/HTTP_SERVICE_UNAVAILABLE.html.var # ErrorDocument 506 /error/HTTP_VARIANT_ALSO_VARIES.html.var </IfModule> </IfModule>
NOTE:
In deze configuratie errordocs.conf wordt ook in de directive
<Directory "/usr/share/httpd/error"> Options IncludesNOEexec gezet.
In de Virtual Host staat de directive <Location /> met Options -IncludesNOEexec
Hiervoor moet ook in de Virtual Host (80 en 443) een utzondering voor /error gemaakt worden. Zie ook Mapping naar bestanden buiten de httpd root
<Location /error>
Options +Indexes +FollowSymLinks +IncludesNOExec
</Location>
Zie de Apache HTTP Server Version 2.4 documentatie voor AddOutputFilter Includes html, AddHandler type-map var, LanguagePriority en ForceLanguagePriority Prefer Fallback en Apache Module mod_negotiation voor nadere info betreffende het gebruik van de *.var documenten, de zogenaamde 'Multiviews'.
Herstart Apache voor het laden van deze nieuwe directives.
Piwigo.Conf
Piwigo is een fotogalerijprogramma voor websites. Het programma heeft een GPL-licentie, en is geschreven in PHP en gebruikt een MySQL-database.
Piwigo stond eerder bekend als "PhpWebGallery" maar de oorspronkelijke auteur van de software, Pierrick Le Gall, wijzigde in september 2008 de naam naar de huidige.
Zie de Piwigo pagina's voor installatie en configuratie.
De Piwigo App wordt geinstalleerd in de webroot /var/www/html en heeft geen aanvullende http directives nodig.
Voor bijvoorbeeld security worden extra directives aanbevolen middels het gebruik van .htaccess bestanden.
Zoals beschreven in de sectie .htaccess proberen we .htaccess bestanden te vermijden en wordt op deze server in /etc/httpd/conf.d de 'include' piwigo.conf gebruikt waarin we ook andere http 'customisations' onderbrengen. Zie voor de laatste ook Piwigo::Beveiliging > Apache Directives voor Piwigo
#********************************************************************* #* /etc/httpd/conf.d/piwigo.conf * #* Custom httpd configuratie Ben Makkink 27-maart-2016 * #********************************************************************* # In httpd.conf is AllowOverride naar None gezet # Indien Piwigo beveiliging mbv .htaccess toch gewenst is dit hier # toestaan door Override toe te staan <Directory /var/www/html/piwigo> # AllowOverride FileInfo Options AuthConfig Limit </Directory> # Voor toegangscontrole voor de familiewebsite /var/www/html/archief # en toegang middels Piwigo Cookie <Directory "/var/www/html/archief"> Require all denied SetEnvIf COOKIE ^GALLERYSID user_logged_in Require env user_logged_in </Directory> # Blokkeer directe url naar originele fotos in ../piwigo/galleries # In plaats van .htaccess in /var/www/html/piwigo/galleries # Voeg tevens toe in ../piwigo/local/config/config.inc.php # $conf['original_url_protection'] = 'images'; <Directory /var/www/html/piwigo/galleries> Require all denied </Directory> # Blokkeer directe url naar originele fotos in ../piwigo/upload # In plaats van .htaccess in /var/www/html/piwigo/upload <Directory /var/www/html/piwigo/upload> Require all denied </Directory> # Blokkeer directe url naar derivaten in ../piwigo/_data/i # Voeg tevens toe in ../piwigo/local/config/config.inc.php # $conf['derivative_url_style'] = 2; <Directory /var/www/html/piwigo/_data/i> Require all denied </Directory> #************************************************************************ # Zet SameSite support voor Cookies * # Ben Makkink 26-juni-2020 * #************************************************************************ # Zie https://developer.mozilla.org/nl/docs/Web/HTTP/Headers/Set-Cookie/SameSite # en https://www.makkink.eu/exploringlinux/server7/html/apache.html#piwigoconf <ifmodule mod_headers.c> # Header always edit Set-Cookie (.*) "$1; SameSite=strict" Header always edit Set-Cookie (.*) "$1; SameSite=lax" </ifmodule>
Toegangscontrole /var/www/html/archief via Piwigo Cookie
Voor de directorie /var/www/html/archief/ voegen we in bovenstaand bestand een directive toe met als eerste de 'Require all denied' statement. Hiermee wordt toegang tot '/archief/' volledig geblokkeerd.
Daarna word middels 'SetEnvIf' gecontroleerd of in de clientbrowser een Piwigo Cookie is gezet. Deze Cookie wordt gezet als een client via Piwigo ingelogd en geauthentiseerd is als een geregistreerde gebruiker. Zie hiervoor ook Piwigo::Albums Inrichten > Beveiliging 'Archief' en toegang via Piwigo registratie
Als het Cookie gevonden wordt, wordt de variabele 'env' gezet naar 'user_logged_in' en krijgt de clientbrowser toegang tot '/archief/'.
Onderstaande regels worden hiervoor aan piwigo.conf toegevoegd:
# toegangscontrole via Piwigo Cookie <Directory "/var/www/html/archief"> Require all denied SetEnvIf COOKIE ^GALLERYSID user_logged_in Require env user_logged_in </Directory>
Piwigo Cookie zetten
Zie ook Piwigo::Wijzigingen > Hacks > Extra Cookie wanneer gebruiker ingelogd is
Bovenstaande toegangscontrole test of er in de webroot een Cookie met de naam 'GALLERYSID' gezet is door Piwigo.
Piwigo zet weliswaar een Cookie maar dat is slechts een Session Cookie en deze wordt gezet in /piwigo/met de naam 'pwg_id'. Deze Cookie wordt echter ook gezet als er niet op Piwigo ingelogd is en de gebruiker dus 'guest' is. De 'value' van de Piwigo Session Cookie bevat de code waarmee de gebruiker van Piwigo in de MySQL database te herleiden is.
Als de Piwigo Session Cookie al in de webroot zou staan en de bovenstaande 'SetEnvIf' http methode mogelijk ook de inhoud (value) van de Cookie zou kunnen testen, dan kan daar nog steeds verder niets mee gedaan worden zonder toegang tot de Piwigo database.
Het enige alternatief is dat Piwigo een additionele Cookie in de Webroot zet met een unieke naam en dat alleen als er op Piwigo ingelogd is door een geregistreerde gebruiker. Er is een toevoeging nodig in het Piwigo 'index.php' bestand.
Hieronder volgt de benodigde toevoeging direct in het begin na de include calls in het script /var/www/html/piwigo/index.php:
define('PHPWG_ROOT_PATH','./');
include_once( PHPWG_ROOT_PATH.'include/common.inc.php' );
include(PHPWG_ROOT_PATH.'include/section_init.inc.php');
//Ben Makkink 26/03/2016
//Toevoeging voor het zetten van extra cookie als gebruiker ingelogd is
//Control Cookie voor toegang tot afgeschermde data
if ($user['status']!=="guest")
{
setcookie('GALLERYSID',time(),0, '/');
}
else
{
setcookie('GALLERYSID', ' ', time()-7000000, '/');
}
// Check Access and exit when user status is not ok
check_status(ACCESS_GUEST);
// access authorization check
if (isset($page['category']))
In index.php wordt als eerste de include 'common.inc.php' uitgevoerd. In deze include wordt o.a. het global PHP commando 'session_start()' uitgevoerd. Dit commando start een nieuwe- of vervolgt een bestaande Piwigo Sessie en opent vervolgens de Piwigo Home pagina. Als er niet ingelogd is dan is de userstatus 'guest' en wordt de optie geboden in te loggen.
Door nu de status van $user te testen kunnen we vaststellen wanneer de gebruiker ingelogd is (is niet guest) en in dat geval wordt er een Cookie met de naam 'GALLERSID' gezet. De 'value' is niet belanrijk, maar het veld mag niet leeg zijn, we zetten hier bijvoorbeeld de huidige tijd. De expirydate zetten we naar 'onbepaald' door 0 in te voeren. Voor path van de Cookie zetten we '/', zijnde de webroot.
Als de gebruiker uitlogt dan wordt $user['status'] weer naar 'guest' gezet en verwijderen we de Cookie 'GALLERYSID' door zijn waarde naar 'leeg' te zetten en de expirydate naar een punt in het verre verleden
Login en toegangscontrole../archief/ via Piwigo
In de voorgaande sectie is beschreven hoe de site 'archief' afgeschermd is. Alleen als een client ingelogd is als geregistreerde gebruiker op Piwigo zal deze toegang krijgen tot de vertrouwelijke site.
In Piwigo wordt de link met URL naar het archief alleen getoond als een gebruiker ingelogd is.
En omdat er dan ingelogd is krijgt de URL toegang tot het archief.
Zie Piwigo::Albums Inrichten > Albums Beheren > Galerij minatuur met link naar externe site 'Archief'
SameSite extra cookie security
Medio juni 2020 werd de volgende waarschuwing afgegeven in mijn Firefox Browser Console:
Cookie “pwg_id” will be soon rejected because it has the “sameSite” attribute set to “none” or an invalid value, without the “secure” attribute. To know more about the “sameSite“ attribute, read https://developer.mozilla.org/docs/Web/ … e/SameSite
Mede met de informatie in de blog SameSite cookies in practice heb ik, zonder succes, diverse PHP oplossingen geprobeerd. Dit in een poging Piwigo te laten voldoen aan de nieuwe eisen.
Wat uiteindelijk lukte is met een toevoeging in het Apache Webserver configuratiebestand. Omdat het in mijn situatie is alleen voor Piwigo noodzakelijk is, is de code in Piwigo.conf geplaatst.
Middels deze code worden alle cookies die op de server gezet worden bewerkt waardoor ze de vereiste SameSite settings bevatten. Ik heb gekozen voor de 'lax' setting, maar Piwigo werkt ook prima met 'strict'.
#************************************************************************ # Zet SameSite support voor Cookies * # Ben Makkink 26-juni-2020 * #************************************************************************ # Zie https://developer.mozilla.org/nl/docs/Web/HTTP/Headers/Set-Cookie/SameSite # en https://www.makkink.eu/exploringlinux/server7/html/apache.html#piwigoconf <ifmodule mod_headers.c> # Header always edit Set-Cookie (.*) "$1; SameSite=strict" Header always edit Set-Cookie (.*) "$1; SameSite=lax" </ifmodule>
Wordpress.Conf
Wordpress:
- is vrije weblog-software, die onder de voorwaarden van de GNU General Public License (GPL) wordt gepubliceerd.
- is ontwikkeld door Matthew Mullenweg, maar het wordt door een flinke groep ontwikkelaars ondersteund.
- is het meest gebruikte contentmanagementsysteem.
- maakt gebruik van de programmeertaal PHP. Alle content wordt opgeslagen in een MySQL-database.
- is een contentmanagementsysteem (CMS) waardoor de gebruiker op een relatief eenvoudige wijze de inhoud (content) kan wijzigen en/of aanvullen zonder dat daar technische kennis voor vereist is.
Zie de Wordpress pagina's voor installatie en configuratie.
De Wordpress Blog App wordt geinstalleerd in de webroot /var/www/html en heeft enkele aanvullende http directives nodig en deze worden bij de installatie geplaatst in een .htaccess bestand in de wordpress blog root /var/www/html/blog.
De directives in dit .htaccess bestand worden dynamisch gegenereerd door Wordpress en zouden alleen aangepast mogen worden via WordPress filters. Alle wijzigingen aan de richtlijnen worden mogelijk bij een update/upgrade overschreven.
AllowOverride None
Zoals beschreven in de sectie .htaccess proberen we .htaccess bestanden te vermijden en wordt op deze server in /etc/httpd/conf.d de 'include' wordpress.conf gebruikt.
Kopieer hiervoor de inhoud van het /var/www/html/blog/.htaccess bestand.
# BEGIN WordPress
# De richtlijnen (regels) tussen "BEGIN WordPress" en "END WordPress"
# worden dynamisch gegenereerd en zouden alleen aangepast mogen worden
# via WordPress filters. Alle wijzigingen aan de richtlijnen tussen
# deze markeringen worden overschreven.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /blog/
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /blog/index.php [L]
</IfModule>
# END WordPress
en plaats dat in /etc/httpd/conf.d/wordpress.conf
Zorg er hierbij voor dat het een directive wordt voor de Directory waarin het .htaccess bestand staat, dwz /var/www/html/blog
<Directory /var/www/html/blog> # BEGIN WordPress # De richtlijnen (regels) tussen "BEGIN WordPress" en "END WordPress" # worden dynamisch gegenereerd en zouden alleen aangepast mogen worden # via WordPress filters. Alle wijzigingen aan de richtlijnen tussen # deze markeringen worden overschreven. <IfModule mod_rewrite.c> RewriteEngine On RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}] RewriteBase /blog/ RewriteRule ^index\.php$ - [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /blog/index.php [L] </IfModule> # END WordPress </Directory>
Dynamische integratie van .htaccess
Het Wordpress .htaccess bestand wordt dynamisch gegenereerd bij de installatie en/of update door Wordpress.
De hierboven voorgestelde integratie van .htaccess in wordpress.conf is echter statisch waarvoor manuele interventie van de admin vereist is.
WP-HTACCESS
Dit process wordt op mijn server min of meer automatisch gemaakt door een dagelijkse crontab die het script wp-htaccess start met een check of er een wijziging in .htaccess geweest is en of deze al dan niet onderdeel is geweest van een Wordpress update:
- Als de wijziging samenging met een Wordpress update wordt de code van de gewijzigde .htacces vertrouwd en geintegreerd in /etc/httpd/conf.d/wordpress.conf
- Als er echter geen Wordpress update plaatsvond dan wordt de gewijzigde .htaccess code aangemerkt als een potentiële hack en moet Admin het .htaccess bestand eerst evalueren.
Admin ontvangt een e-mail met daarin de te volgen stappen. - Na evaluatie kan Admin de code accepteren door het laten integreren of weigeren waarna het nwe .htaccess vervangen wordt door het oude oorspronkelijke .htaccess bestand.
Meldingen
Als er wel een Wordpress update plaatsvond maar geen .htaccess codewijziging dan ontvangt Admin onderstaande melding in een mail:
To: ServerAdmin
Subject: Wordpress update is uitgevoerd
Er is een update/upgrade van de Wordpress uitgevoerd.
Hierbij heeft er zich geen wijziging voorgedaan in het dynamisch
gegenereerde .htaccess bestand in /var/www/html/blog/.
Er is geen verdere actie nodig.
Zie ook https://www.makkink.eu/exploringlinux/wordpress/html/
installeren.html#htaccess
Als er een .htaccess codewijziging plaatsvond tijdens een Wordpress update dan ontvangt Admin onderstaande melding in een mail:
To: ServerAdmin
Subject: Wordpress .htaccess integratie is uitgevoerd.
Er is een update van het Wordpress .htaccess bestand geïntegreerd
met het webserver configuratiebestand /etc/httpd/conf.d/wordpress.conf.
Het nieuwe .htaccess bestand was onderdeel van een Wordpress update of
goedgekeurd na manuele interventie.
Zie ook https://www.makkink.eu/exploringlinux/wordpress/html/
installeren.html#htaccess
Als er echter een .htaccess codewijziging plaatsvond zonder een Wordpress update dan kan het een hack zijn en ontvangt Admin onderstaande melding in een mail:
To: ServerAdmin
Subject: Wordpress .htaccess gehackt?
Er is een wijziging aangebracht in het .htaccess bestand van Wordpress
zonder dat hiervoor een Wordpress update plaatsvond.
Dit is een verdachte situatie en is mogelijk het resultaat van een hack.
De webserver is dusdanig geconfigureerd dat een Override door .htaccess
niet is toegestaan of te wel de code van .htaccess wordt niet uitgevoerd.
Na een legitieme Wordpress version update wordt de dynamische inhoud van
.htaccess gekopieerd naar de webserverconfiguratie
/etc/httpd/conf.d/wordpress.conf.
POTENTIELE HACK GEBLOKKEERD.
Omdat zojuist de Wordpress ".htaccess" is gewijzigd terwijl er geen version
update plaatsvond is deze als verdacht aangemerkt en geblokkeerd door een
kopie van .htaccess op te slaan als "/var/www/html/blog/hta_fout".
EVALUEREN
Het bestand "/var/www/html/blog/hta_fout" moet eerst geevalueerd worden.
OUDE .HTACCESS TERUGZETTEN
- Als hierbij blijkt dat iets met de code in "hta_fout" inderdaad niet
klopt dan moet de voorlaatste .htaccess teruggezet worden.
Activeer dit door bet bestand "hta_fout" te hernoemen naar "hta_terug".
Door het script "wp-htaccess" uit te voeren wordt de laatste correcte
situatie hersteld (Dit gebeurd ook automatisch als de dagelijkse cron
"wp-htaccess" draait).
INTEGREREN
- Als echter blijkt dat er niets aan de hand is met de code in "hta_fout"
hernoem deze dan naar "hta_ok".
Door het script "wp-htaccess" uit te voeren wordt de nieuwe .htaccess
alsnog gekopieerd en geïntegrrerd in de webserverconfiguratie
/etc/httpd/conf.d/wordpress.conf (Dit gebeurd ook automatisch als de
dagelijkse cron "wp-htaccess" draait).
De webserver wordt opnieuw gestart om het gewijzigde configuratiebestand
"../conf.d/wordpress.conf" te laden.
Zie ook https://www.makkink.eu/exploringlinux/wordpress/html/
installeren.html#htaccess
De resulterende wordpress.conf zie eruit als volgend voorbeeld:
#************************************************************************
#* /etc/httpd/conf.d/wordpress.conf *
#* Custom httpd configuratie voor Wordpress. Ben Makkink 7-maart-2021 *
#************************************************************************
#* Per default is in httpd.conf AllowOverride naar None gezet. *
#* Mede om remote toegang via hacks van .htaccess te voorkomen is het *
#* wenselijk deze ClearOS default instelling te handhaven. *
#* *
#* Wordpress genereerd voor o.a. permalinks en beveiliging wel dynamisch*
#* een .htaccess bestand in de Wordpress root. *
#* Deze directives hevelen we over naar dit bestand 'wordpress.conf' *
#* zodat ze toch uitgevoerd worden. *
#* Elke keer dat er dynamisch een wijziging gemaakt wordt in '.htaccess'*
#* wordt dit bestand 'wordpress.conf' ververst d.m.v. het script *
#* 'wp-htaccess' welke regelmatig start d.m.v. een cron *
#************************************************************************
# Dit bestand vervangt .htaccess, dus reconfirmeer 'AllowOverride None'
<Directory /var/www/html/blog>
AllowOverride None
</Directory>
# Later toe te voegen custom directives boven deze regel invoegen
#========================================================================
<Directory /var/www/html/blog>
# BEGIN WordPress
# De richtlijnen (regels) tussen "BEGIN WordPress" en "END WordPress"
# worden dynamisch gegenereerd en zouden alleen aangepast mogen worden
# via WordPress filters. Alle wijzigingen aan de richtlijnen tussen deze
# markeringen worden overschreven.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /blog/
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /blog/index.php [L]
</IfModule>
# END WordPress
</Directory>
Error Messaging
Tot en met ClearOS 6.6
was er een sectie in httpd.conf waarin instellingen gemaakt kunnen worden om voor bepaalde (of alle) errors, uitgebreide Error Documenten weergegeven kunnen worden.
In ClearOS 7 is deze sectie met ErrorDocument directives uit httpd.conf verdwenen en is alleen onderstaande informatie gebleven.
# Customizable error responses come in three flavors: # 1) plain text 2) local redirects 3) external redirects # # Some examples: #ErrorDocument 500 "The server made a boo boo." #ErrorDocument 404 /missing.html #ErrorDocument 404 "/cgi-bin/missing_handler.pl" #ErrorDocument 402 http://www.example.com/subscription_info.html
Het is mij niet duidelijk waarom dit gedaan is en ook na veel zoeken heb ik ook niets kunnen vinden waarmee ClearOS deze functionaliteit alsnog geïntegreerd heeft.
Om de functionaliteit te behouden heb ik een
configuratiebestand aangemaakt met daarin de relevante directives zoals deze in het ClearOS 6.6 httpd.conf bestand voorkwamen.
Zie hiervoor Server::Apache sectie Errordocs.Conf
Layout ErrorDocuments
Als de Apache default instellingen gebruikt worden dan wordt alleen het error-nummer geretourneerd zonder verdere uitleg.
Voor de 3 meest voorkomende errors worden op deze server de meer uitgebreide boodschappen weergegeven zoals in voorgaande sectie behandeld.
De Error pagina's die nu getoond worden zijn met de module meegeleverd en nog steeds wat basic en bevatten taalfouten.
Maar deze pagina's zijn naar wens verder te personaliseren.
De ErrorDocuments zijn opgeslagen in directory '/usr/share/httpd/error' en we nemen als voorbeeld 'ErrorDocument 401 /error/ HTTP_UNAUTHORIZED.html.var
HTTP_UNAUTHORIZED.html.var
Bekijk hier de inhoud van HTTP_UNAUTHORIZED.html.var en er is een sectie voor elke taal. De taal ingesteld op de clientbrowser bepaald welke taal getoond wordt.
Voor de structuur bekijken we nu de sectie 'Content-language: nl'.
Content-language: nl Content-type: text/html; charset=UTF-8 Body:----------nl-- <!--#set var="CONTENT_LANGUAGE" value="nl"--> <!--#set var="TITLE" value="Authenticatie nodig!"--> <!--#include virtual="include/top.html" --> De server kon niet controleren of u gemachtigd bent om toegang te krijgen tot de URL "<!--#echo encoding="url" var="REDIRECT_URL" -->". U hebt zich onvoldoende geauthenticeerd ( vb : verkeerd paswoord ), of uw browser is niet in staat de nodige authentificatiegegevens door te geven. <!--#include virtual="include/spacer.html" --> Indien u toch gemachtigd bent toegang te krijgen tot het document, controleer uw gebruikersnaam en paswoord en probeer opnieuw. <!--#include virtual="include/bottom.html" --> ----------nl--
We zien dat het begint met een paar standaard html instellingen waarna de rest volgt en deze wordt opgebouwd met de volgende componenten:
- De 'include/top.html' waarin de pagina opgebouwd wordt met o.a de styles met backgroundcolor, background image etc.
- Nu wordt de Nederlandse tekst toegevoegd.
- Het eerste tekstblok wordt gevolgd door 'include/spacer.html' die exact doet wat het zegt, voegt een lege paragraaf toe. Dit kan naar behoefte groter of kleiner gemaakt worden of worden voorzien van een lijn of afbeelding.
- Dit wordt opnieuw gevolgd door een stuk Nederlandse tekst.
- De pagina wordt afgesloten met 'include/bottom.html' en deze heeft als eerste ook weer een 'include ../contact.html.var' met de contact gegevens in de taal van de browser (in ons geval NL). Daarna sluit 'include/bottom.html' de error pagina met de Error Code en Apache versie
Personalisatie Layout
TOP.HTML
Zie hier de code van gewijzigde '/usr/share/httpd/error/include/top.html'
- Prepareer een achtergrond image naar wens van +/- 1700 x 1100 px en +/- 100-200 kB
Sla deze op op server in '/usr/share/httpd/error' met naam 'errormsg_backgr.jpg'
Voeg toe/wijzig style:
body { color: #000000;
background-color: #D4C1A3;
background-repeat: no-repeat;
background-image: url(/../error/errormsg_backgr.jpg);
}
Note: De Apache root is de website root '/var/www/html', dus de url hierboven begint in '/var/www/html' en gaat dan 1 stap terug naar '/var/www' en gaat van daaruit naar alias '/error/' en haalt daar '/usr/share/httpd/error/errormsg_backgr.jpg'.
BOTTOM.HTML
Zie hier code van gewijzigde '/usr/share/httpd/error/include/bottom.html'
- Prepareer een logo +/- 100 x 100 px 5-10 kB
Sla deze op op server in '/var/www/error' met naam 'logo.png'
<a href="/"><img src="/../error/logo.png" /></a><br />
Tekst Correcties
CONTACT.HTML.VAR
De Nederlandse vertaling in contact.html.var ziet er wat vreemd uit:
Indien u van oordeel bent dat deze server in fout is, gelieve de <a href="mailto:<!--#echo encoding="url" var="SERVER_ADMIN" -->">webmaster</a> te contacteren.
Dit gewijzigd naar:
Indien u van oordeel bent dat het een serverfout is, neem dan a.u.b. contact op met de <a href="mailto:<!--#echo encoding="url" var="SERVER_ADMIN" -->">webmaster</a>
HTTP_UNAUTHORIZED.HTML.VAR
De tekst in HTTP_UNAUTHORIZED.html.var is niet echt zinvol en daarom is:
Indien u toch gemachtigd bent toegang te krijgen tot het document, controleer uw gebruikersnaam en paswoord en probeer opnieuw.
Gewijzigd naar:
Als u toegang wenst tot deze pagina's neem dan contact op met de <a href="mailto:<!--#echo encoding="url" var="SERVER_ADMIN" -->">webmaster</a> voor een gebruikersnaam en paswoord.
In HTTP_FORBIDDEN.html.var en HTTP_NOT_FOUND.html.var zijn geen wijzigingen aangebracht.
Awstats en Access-logs
 AWStats is een krachtig tool met veel opties voor grafische webserver rapportage. Het rapportageprogramma voor de webserver analyseert uw webserver logbestanden. Deze genereert daarna voor elke (virtuele) website uitgebreide statistieken over bezoek daarvan. |
Installatie
AWStats wordt in de ClearOS 7 distributie niet als Web log file analyzer App in Marketplace meegeleverd.
Het tool is echter wel beschikbaar in de clearos-epel repository.
Installeer met yum:
# yum install awstats
Het tool AWSTATS 7.8-1.el7 wordt geïnstalleerd samen met 19 dependencies.
Configuratie Wizard
Awstats is verder te configureren met een wizard te starten met het commando # perl /usr/share/awstats/tools/awstats_configure.pl
Als de wizard start wordt als eerste gesuggereerd dat het misschien beter is de configuratie op de hand te doen en hierbij de stappen te volgen die in de AWSTATS Reference Manual beschreven staan. We verlaten daarom de wizard en gaan zoals hieronder beschreven verder.
Logbestanden
De AWSTATS statistieken zijn per default gebaseerd op de Apache access_logs van de gehele webroot 'var/www/html/'. Om statistieken van specieke websites, welke zich als subdirectories in de webroot bevinden, te kunnen produceren zal er eerst gezorgd moeten worden voor access_logs met alleen data voor deze specifieke sites. Zie hiervoor de sectie Access_log van een specifieke subdirectory eerder in dit hoofdstuk.
Configuratiebestanden
- /etc/httpd/conf.d/awstats.conf
Bij de installatie met yum uit de ClearOS distributie wordt stap 1B zoals beschreven in de AWSTATS Reference Manual reeds uitgevoerd en het resulterende configuratiebestand 'awstats.conf' wordt geplaatst in de Apache-Apps configuratie directory '/etc/httpd/conf.d'.
Hieronder '/etc/httpd/conf.d/awstats.conf' ontdaan van de onnodige informatie en geef alle LAN gebruikers (192.168.1.0/24) toegang:# 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. # <Directory "/usr/share/awstats/wwwroot"> Options None AllowOverride None <IfModule mod_authz_core.c> # Apache 2.4 Require ip 192.168.178.0/24 </IfModule> <IfModule !mod_authz_core.c> # Apache 2.2 Order allow,deny # Allow from 127.0.0.1 # Allow from ::1 Allow from 192.168.178.0/24 </IfModule> </Directory> # Additional Perl modules <IfModule mod_env.c> SetEnv PERL5LIB /usr/share/awstats/lib:/usr/share/awstats/plugins </IfModule>
Naar index
- awstats.makkink.eu.conf
Voor elke site op de webserver maken we nu een configuratie aan, om te beginnen de gehele webserver.
Voer volgende commando's uit:
# cd /etc/awstats
# cp -a awstats.model.conf awstats.makkink.eu.conf
Edit awstats.makkink.eu.conf en maak de volgende instellingen:
LogFile="/var/log/httpd/access_log" Sitedomain="makkink.eu" HostAliases="makkink.eu www.makkink.eu localhost 127.0.0.1"
Laat de rest zoals het is en voer uit: # systemctl restart httpd[.service]
- awstats.nbp.conf
Statistieken van de webpagina's van 'NBP'
Voer volgende commando's uit:
# cd /etc/awstats
# cp -a awstats.model.conf awstats.nbp.conf
Edit awstats.makkink.eu.conf en maak de volgende instellingen:
LogFile="/var/log/httpd/nbp_access_log" Sitedomain="nbp" HostAliases="makkink.eu www.makkink.eu localhost 127.0.0.1"
Laat de rest zoals het is en voer uit: # systemctl restart httpd[.service]
Naar index
- awstats.wandelen.conf
Statistieken van de webpagina's van 'Wandelen'
Voer volgende commando's uit:
# cd /etc/awstats
# cp -a awstats.model.conf awstats.wandelen.conf
Edit awstats.makkink.eu.conf en maak de volgende instellingen:
LogFile="/var/log/httpd/wandelen_access_log" Sitedomain="wandelen" HostAliases="makkink.eu www.makkink.eu localhost 127.0.0.1"
Laat de rest zoals het is en voer uit: # systemctl restart httpd[.service]
- awstats.blog.conf
Statistieken van de webpagina's van 'blog' (Dopheide)
Voer volgende commando's uit:
# cd /etc/awstats
# cp -a awstats.model.conf awstats.blog.conf
Edit awstats.makkink.eu.conf en maak de volgende instellingen:
LogFile="/var/log/httpd/blog_access_log" Sitedomain="blog" HostAliases="makkink.eu www.makkink.eu localhost 127.0.0.1"
Laat de rest zoals het is en voer uit: # systemctl restart httpd[.service]
NOTE
De installatie van Awstats resulteerd ook in twee (identieke) configuratiebestanden awstats.localhost.localdomain.conf en awstats.mainserver.makkink.eu.conf.
De taak van deze twee configuratiebestanden
wordt overgenomen door awstats.makkink.eu.conf.
De eerstgenoemde twee bestanden kunnen we verwijderen.
Data updaten en opslaan
Bij de installatie met YUM plaatst AWSTATS ook een cron in /etc/cron.hourly/awstats:
#!/bin/bash exec /usr/share/awstats/tools/awstats_updateall.pl now-configdir="/etc/awstats"-awstatsprog="/usr/share/awstats/wwwroot/cgi-bin/awstats.pl" >/dev/null exit 0
Met deze cron maakt Awstats elk uur een updata voor de statistieken
De data die met de update gecreëerd worden worden in /var/lib/awstats/ toegevoegd aan de bestanden met een naam in het formaat: awstats122015.makkink.eu.txt
Elke maand wordt door de cron van elke site een nieuw bestand aangemaakt. Door het deleten van deze txt bestanden worden de statistieken gereset. Door ze vanuit een backup terug te zetten kunnen historische data getoond worden.
Behalve met de cron, kan een update ook gestart worden aan de prompt door één van onderstaande commando's:
- # /usr/share/awstats/tools/awstats_updateall.pl now
- # /usr/share/awstats/wwwroot/cgi-bin/awstats.pl -update -config=makkink.eu
- # /usr/share/awstats/wwwroot/cgi-bin/awstats.pl -update -config=nbp
- # /usr/share/awstats/wwwroot/cgi-bin/awstats.pl -update -config=wandelen
BUG
Bovenstaand commando
# /usr/share/awstats/tools/awstats_updateall.pl now werkte niet.
Er bleek een bug te zitten in het bestand
awstats_updateall.pl
De programma's zijn door AWSTATS opgezet te werken in /usr/local/awstats, maar ClearOS heeft er voor gekozen ze te verplaatsen naar /usr/share/awstats. Hierbij is vergeten een correctie aan te brengen in awstats_updateall.pl. Wijzig in onderstaande regels 'local' naar 'share' en alles werkt naar behoren.'
# Check if AWSTATS prog is found
my $AwstatsFound=0;
if (-s "$Awstats") { $AwstatsFound=1; }
elsif (-s "/usr/local/awstats/wwwroot/cgi-bin/awstats.pl") {
$Awstats="/usr/local/awstats/wwwroot/cgi-bin/awstats.pl";
$AwstatsFound=1;
In recentere versies van Awstats is dit probleem verholpen
Statistieken bekijken in de browser
Om de statistieken in de browser te bekijken voeren we één van onderstaande URL's in:
- http://homeserver/awstats/awstats.pl?config=makkink.eu
- http://homeserver/awstats/awstats.pl?config=nbp
- http://homeserver/awstats/awstats.pl?config=wandelen
- http://homeserver/awstats/awstats.pl?config=blog
AWStats Webrapport Favicon
Om met een Webpagina een Favicon mee te geven moet er in de <head> sectie een regel als volgt opgenomen zijn: <link rel="shortcut icon" href="/path/favicon.ico" />
De AWStats webpagina wordt opgebouwd met het CGI script /usr/share/awstats/wwwroot/cgi-bin/awstats.pl waarbij de webroot van de pagina '/usr/share/awstats/wwwroot' is. Dat wil zeggen dat de adressering in de pagina relatief is t.o.v. ../wwwroot.
In het awstats.pl script wordt het framewerk opgezet te beginnen met de header waarin we de extra instructie op willen nemen.
Favicon
De Awstats icon die we gaan gebruiken is te vinden in de awstats installatie.
Kopiëer /usr/share/doc/awstats-7.8/images/awstats.ico en plak het in /usr/share/awstats/wwwroot/icon/other
Edit /usr/share/awstats/wwwroot/cgi-bin/awstats.pl
Scrol naar beneden tot aan de sectie:
'Function: Write on output header of HTML page'
Ga in deze sectie verder naar beneden naar "<meta http-equiv=\"keywords\" en voeg instructie toe na de regel: . "</title>\n"; @L895
Script toevoeging voor favicon:
"<meta http-equiv=\"keywords\" content=\"$SiteDomain, free, advanced, realtime, web, server,
logfile, log, analyzer, analysis, statistics, stats, perl,
analyse, performance, hits, visits\"$endtag\n";
}
print "<title>$Message[7] $SiteDomain$periodtitle"
. ( $k[0] ? " - " . $k[0] : "" )
. "</title>\n";
#********************************************************************************************
#* Toevoeging Favicon Ben Makkink 30-10-2020 *
#********************************************************************************************
#* Copieer /usr/share/awstats-7.3/images/awstats.ico en plak deze op /usr/share/awstats/ *
#* wwwroot/icon/other/awstats.ico *
#* Er is in awstats.conf een alias /awstatsicons gezet naar /usr/share/awstats/wwwroot/icon/*
#* Het adres in de webpagina wordt daarom /awstatsicons/other/awstats.ico *
#* Met onderstaande regel wordt de favicon aan de webpagina toegevoegd *
#********************************************************************************************
print "<link rel=\"shortcut icon\" href=\"/awstatsicons/other/awstats.ico\" />\n";
#********************************************************************************************
#* Einde toevoeging Ben Makkink 30-10-2020 *
#********************************************************************************************
if ( $FrameName ne 'index' ) {
AWStats data verhuizen naar nieuwe server
Als we AWStats installeren op een nieuwe server willen we graag de historische AWStats-data van de oude server overzetten naar de nieuwe installatie.
- Bij de nieuwe AWStats installatie zijn in /var/lib/awstats/ al data bestanden aangemaakt. Verwijder alle awstatsMMYYYY.<sitedomain>.txt bestanden (tijdelijk elders bewaren).
Gebruik rsync om alle awstatsMMYYYY.<sitedomain>.txt data bestanden te kopieren van de oude naar de nieuwe server - De httpd accesslogbestanden worden opgeslagen in /var/log/httpd. Verwijder op de nieuwe server alle bestanden uit deze map (tijdelijk elders bewaren).
Gebruik rsync om alles *access_log* bestanden te kopieren van de oude naar de nieuwe server. - Run op de nieuwe server: # /usr/share/awstats/tools/awstats_updateall.pl now
HTTPS en Certificatie
Als er met HTTPS gewerkt wordt wordt gebruik gemaakt van SSL verbinding.
Een SSL/TLS-verbinding is een gecodeerde verbinding tussen de server en bezoeker.
Naast het slotje bovenin je browser voor de URL kun je een SSL-verbinding ook herkennen aan de https aan het begin van de URL.
Https staat voor Hyper Text Transfer Protocol Secure. De extra S aan het einde van http staat dus voor veilig. Klik je op het slotje, dan kun je de gegevens van het certificaat en de uitgever daarvan controleren.
TLS staat voor Transport Layer Security. Eigenlijk is dit niets anders dan een veiligere versie van SSL. Tegenwoordig wordt er eigenlijk altijd gebruik gemaakt van de TLS-technologie. Toch gebruiken we de term SSL nog altijd omdat dit de meest gebruikte term is.
De gegevensstroom tussen de server en bezoeker is heel makkelijk uit te lezen met zogenaamde netwerk sniffers. Wachtwoorden zijn op deze manier bijvoorbeeld heel makkelijk te achterhalen. Om dat enorme (!) beveiligingsrisico op te vangen, kan men het beste een SSL-verbinding gebruiken. Dan worden deze gegevens namelijk versleuteld verzonden.
Webserver SSL activeren
In sectie Webserver Activeren Apache wordt aangegeven hoe we voor de Webserver SSL ondersteuning kunnen activeren.
SSL Certificaat
SSL beveiligt de verbinding tussen twee computers. Om zo’n beveiligde verbinding plaats te laten vinden heb je een certificaat nodig, een SSL-certificaat. Een certificaat bevat gegevens over de certificaathouder, het domein, de naam van de instantie die het certificaat heeft uitgegeven, het land waarin het certificaat is uitgegeven en de geldigheidsduur. Een SSL-certificaat bestaat altijd uit een public- en een private key die nodig zijn om het bericht versleuteld te versturen en uiteindelijk weer in een leesbare tekst om te zetten.
Deze SSL-certificaten worden door verschillende bedrijven uitgegeven. Via een zoekmachine zijn resellers van deze certificaten eenvoudig te vinden. De prijzen lopen daarbij echter wel uiteen van 15 tot meer dan 1500 euro.
SSL Encryptie flowchart
- Browser verbind met een webserver (website) beveiligd met SSL (https). Browser verzoekt de server zich te identificeren.
- Server zendt een kopie van zijn SSL Certificaat, samen met de public-key van de server
- Browser checkt de Certificaat bron (CA) en vergelijkt deze met een lijst van vertrouwde CA's, dat het certificaat niet verlopen is, niet ongeldig verklaard is en dat het geldig is voor de website waarmee het zich verbindt. Als de browser het certificaat vertrouwd, creëert het een symmetrische session-key, versleuteld deze met de ontvangen public-key van de server en zend het naar de server.
- Server ontsleutelt de session-key gebruikmakend van zijn private-key en stuurt een bevestiging versleuteld met de nu gedeelde session-key voor het starten van de versleutelde sessie.
- Server en Browser versleutelen nu alle verstuurde data met de gezamenlijke session-key
Gebruiker aanvaard risico Selfsigned Certificaat
Vanwege de kostprijs heeft ClearOS een eigen self-signed SSL-certificaat met de distributie meegegeven. Dit is een optie waarvan geen enkele webbrowser het certificaat zal (h)erkennen. Zie ook Server::Installeren Certificaat Manager
In ons geval nemen we hiermee genoegen en moeten we de https cliënten verzoeken het certificaat van ons domein te vertrouwen en de waarschuwingen van de browser te laten voor wat ze zijn. Voor kleinschalig gebruik biedt dit voldoende veilige versleuteling.
Hier een voorbeeld van het aanvaarden van het risco en doorgaan in Firefox.
Certificaat Manager
Open in Webconfig > Systeem > Settings > Certificaat manager
Hier is te zien dat er al een CA (Certificaat Autoriteit) en een Systeem Certificaat aangemaakt is. |
Let's Encrypt Free SSL Certificates
Let's Encrypt is een open certificaat authoriteit (OpenCA) die voorziet in gratis SSL Certificaten. De ClearOS Let's Encrypt App integreert de certificaat-levenscyclus en het beheer in Webconfig voor het gebruik door andere aps: Webconfig, Website Hosting, Mail, etc.
Installatie Let's Encrypt
Installeer Let's Encrypt uit de Marketplace in Webconfig en volg de instructies in de ClearOs documentatie
Certificaat aanmaken
System > Security > Let's Encrypt > Add
- Vul in bovenstaande afbeelding bij Primary Domain in het adres van de server op het internet (DNS)
- Klik vervolgens op 'Add'.
- Vervolgens opent onderstaand scherm:
Klik op 'View' om het nieuwe certificaat 'www.makkink.eu' te bekijken.
Het Let's Encrypt Certificaat
Vervang het self-signed certificaat van Webconfig
Bij het installeren van ClearOs wordt de 'Headless' Browser Administratie App 'Webconfig' geïnstalleerd. Zie hiervoor Server::Installeren sectie Headless Webconfig Administratietool. In die sectie wordt het gebruik van een self-signed certificaat door Webconfig uiteen gezet.
Nu we beschikken over een officiëel erkend Certificaat van Let's Encrypt kunnen we deze ook toewjzen aan Webconfig.
Open Webconfig > System > Settings > General Settings
Selecteer 'Edit' en kies het nieuwe Let's Encrypt certificaat.
Certificaat toewijzen aan een website
Voor de webserver is in de sectie 'Webserver Opstarten' beschreven welke Website Settings we kunnen bewerken. In het blok Options hebben we onder 'Digital Certificate' gekozen voor de op dat moment enig beschikbare optie: Self-Signed-Default Certificate.
We kunnen dus eenvoudig terug gaan naar deze Website Settings en hier kiezen voor het nu beschikbare Let's Encrypt Certificaat net zoals we voor Webconfig gedaan hebben.
Pas op! Als we gebruik maken van de geeikte ClearOS methode met het 'clearos.default.conf' configuratiebestand moeten we hier eerst een kopie van maken, want bij elke Website Update wordt 'clearos.default.conf verwijderd.
Bovenstaande edit bewerkstelligt o.a. dat een nieuwe flex-443.conf gemaakt wordt met daarin onder meer de locaties van de Let's Encrypt certificaten en keys.
We moeten nu de certificaten toewijzen aan de website door een edit van <VirtualHost *:443> in het bestand /etc/httpd/conf.d/clearos.default.conf of ../custom-httpd.conf
<VirtualHost *:443> ServerName makkink.eu ServerAlias *.makkink.eu DocumentRoot /var/www/html ErrorLog /var/log/httpd/error_log CustomLog /var/log/httpd/access_log combined CustomLog /var/log/httpd/wandelen_access_log combined env=wandelen CustomLog /var/log/httpd/nbp_access_log combined env=nbp CustomLog /var/log/httpd/blog_access_log combined env=blog SSLEngine on # SSL LetsEncrypt certificaat-bestandslocaties SSLCertificateFile /etc/letsencrypt/live/www.makkink.eu/cert.pem SSLCertificateKeyFile /etc/letsencrypt/live/www.makkink.eu/privkey.pem SSLCertificateChainFile /etc/letsencrypt/live/www.makkink.eu/chain.pem # No weak export crypto allowed SSLHonorCipherOrder on SSLProtocol all -SSLv2 -SSLv3 -TLSv1 SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128
:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!3DES:!aNULL:!MD5 SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
downgrade-1.0 force-response-1.0 </VirtualHost>
Klik om het complete aangepaste bestand clearos.default.conf of custom_httpd.conf te bekijken of te downloaden.
Certificaat van server verwijderen
Als we een server off-line halen om plaats te maken voor een nieuwe server dan heeft het Lets Encrypt certificaat geen nut meer omdat deze voor het domein www.makkink.eu is.
De nu off-line server krijgt een andere (lokale) hostname, bijv. 'testserver'. We moeten het certificaat voor de host www.makkink.eu van deze testserver verwijderen.
Om een certificaat te kunnen deleten moeten we eerst de apps die het certificaat gebruiken, omzetten naar het self-signed ClearOS certificaat.
Webconfig Let's Encrypt SSL certificaat
Webconfig certificaat naar ClearOS self-signed
Webserver Let's Encrypt SSL certificaat
Webserver certificaat naar ClearOS self-signed
Let op:
Na een wijziging in de settings van de Website app worden er nieuwe flex-80 en flex-443 conf's gecreëerd.
Zie ook
Apache Configureren
Run vóór je verder gaat het script flex-integrate om een nieuwe custom-httpd.conf aan te maken.
Nu kan het certificaat verwijderd worden
Confirmatie van verwijderen
Als op de on-line server al dan niet een Let's Encrypt certificaat voor www.makkink.eu in gebruik is levert geen problemen op.
Je kunt meerdere certificaten op hetzelfde domein geregistreerd hebben.
Crawlers en Robots.txt
Het Robots Exclusion Protocol of robots.txt protocol is een conventie om (delen) van een normaal toegankelijke website af te schermen voor bepaalde webspiders en zoekrobots. Dit wordt met name gebruikt om te voorkomen dat (delen van) een website ongevraagd automatisch wordt gekopieerd en bijvoorbeeld daarmee wordt opgenomen in zoekresultaten van zoekmachines.
Het protocol maakt gebruik van het 'robots.txt' bestand, dat in de rootdirectory van een website wordt gezet. Als alternatief voor dit speciale bestand kan in bestaande HTML-bestanden middels HTML-tag Meta het attribuut "robots" worden opgenomen.
Het protocol dient echter alleen ter advies en gaat uit van medewerking van de bezoekende webrobot. Het kan dus niet daadwerkelijk de toegang tot bestanden en mappen ontzeggen en is daarmee ongeschikt om (delen van) een website af te schermen. Het protocol is dan ook voornamelijk bedoeld om gegevens die irrelevant zijn voor bezoekers niet weer te geven in de zoekresultaten van zoekmachines.
Zie ook:
http://nl.wikipedia.org/wiki/Robots_Exclusion_Protocol
http://codex.gallery2.org/Gallery2:How_to_keep_robots_off_CPU_intensive_pages
http://gallery.menalto.com/node/66159#comment-240796
Procedure voor mijn testserver:
- CD naar webroot /var/www/html
- maak tekstbestand robots.txt
- inhoud robots.txt:
User-agent:* # match all bots
Disallow: /archief/ # keep them out
Disallow: /piwigo/
Disallow: /manuals/
Allow: /
