Wij constateren vandaag de dag dat er nog altijd een groot aantal klanten draaien met verouderde of zelfs onveilige PHP-versies binnen verschillende Plesk omgevingen. En hoewel dit (nog) niet tot problemen heeft geleid, is het wel verstandig om hier eens naar te kijken, daar hier ook geld; voorkomen is beter als genezen! Indien uw website gehackt wordt mede hierdoor, dan kunnen wij hier geen of beperkt support op leveren (in dit geval krijgt u dan ook te maken met tech kosten).

In feite is alles beneden PHP 8.x inmiddels (ten tijde van het aanmaken van dit kennisbank artikel) al verouderd, maar de onderstaande PHP-versies zijn zo dermate oud dat wij adviseren om dit aan te passen naar een hogere versie:

• PHP 5.2 (end-of-life sinds januari 2011)
• PHP 5.3 (end-of-life sinds augustus 2014)
• PHP 5.4 (end-of-life sinds september 2015)
• PHP 5.5 (end-of-life sinds juli 2016)
• PHP 5.6 (end-of-life sinds december 2018)
• PHP 7.0 (end-of-life sinds januari 2019)
• PHP 7.1 (end-of-life sinds december 2019)
• PHP 7.2 (end-of-life sinds november 2020)
• PHP 7.3 (end-of-life sinds december 2021)
• PHP 7.4 (end-of-life sinds november 2022)

Inmiddels zijn er ook al bepaalde versies van PHP 8.x end-of-life geworden, maar goed, die zijn nog wel te gebruiken uiteraard.

Het is wel zaak, zeker bij een Plesk server migratie, om een hogere PHP-versie te kiezen voor (bijvoorbeeld een migratie naar AlmaLinux 8.x) voor uw websites, daar PHP 5.x sowieso op dit besturingssysteem niet meer wordt ondersteund. In het meest problematische geval kunnen wij (via een omweg) wel PHP 5.6 op een Plesk omgeving op basis van AlmaLinux 8.x installeren. Maar dit wordt natuurlijk niet geadviseerd. Wanneer met (up-to-date gehouden) Wordpress, Joomla, Drupal of dergelijke CMS draait, dan zal het normaliter sowieso geen probleem zijn om met een hogere PHP-versie te draaien. Vaak is de performance van de nieuwere PHP-versies ook vele malen beter! Dus niet alleen veiliger, maar ook een stuk sneller. Dus waarom nog draaien met oude PHP-versies?

Daarnaast heb je op zeer oude Plesk serveromgevingen (op basis van CentOS 6.x, welke al sinds november 2020 end-of-life is en al helemaal niet meer ondersteund wordt door Plesk) om PHP uit te voeren als zijnde "mod_php" (ook wel Apache PHP genoemd). Dit was vroeger een gemakkelijke methode om oudere PHP programmatuur te draaien, echter is al snel gebleken dat dit absoluut niet veilig was. En derhalve is deze methode dan ook niet meer terug te vinden in modernere besturingssystemen met Plesk (bij CentOS 7.x was deze optie al niet meer mogelijk).

Dus het is zaak, zeker bij een Plesk server migratie, om deze websites aan te passen zodat de PHP uitgevoerd wordt als zijnde "FastCGI application" of "FastCGI toepassing". In dergelijke gevallen moet je dan ook vaak een hogere PHP-versie kiezen, daar mod_php (dus Apache PHP) slechts voor één PHP-versie tegelijk geinstalleerd was. Dit kan je gemakkelijk aanpassen onder "PHP Settings" of "PHP-instellingen" van de website. Zie ook screenshots in de bijlagen. Wacht altijd na het aanpassen van de PHP-versie een paar minuten en test vervolgens de werking van de website. Veelvoorkomende problemen bij de verandering van mod_php naar fastcgi komen door bepaalde instellingen binnen het .htaccess bestand (in de map httpdocs of httpsdocs). Dit is gemakkelijk op te lossen door deze te verwijderen of een comment "#" ervoor te zetten (dit zijn meestal meestal php_flag of php_value regels).

Een compleet overzicht van alle PHP-versies en welke er gebruikt worden op je huidige Plesk serveromgeving, kun je krijgen door te gaan naar "Tools & Settings" (Hulpprogramma's & instellingen) en vervolgens te klikken op "PHP Settings" onder "General Settings" (PHP-instellingen onder Algemene instellingen). Hier zie je een compleet overzicht van alle PHP-versies met daarachter een cijfer. Als je op het cijfer klikt, dan zie je alle websites op je Plesk server die gebruik maken van de genoemde PHP-versie.

Tip: maak altijd een screenshot van de huidige PHP-instellingen, dan kun je bij problemen het één en ander gemakkelijk terug zetten!

Indien je website problemen vertoond na het aanpassen van de gebruikte PHP-versie, dan zal je je website moeten updaten. Waarschijnlijk gaat het dan om zeer verouderde PHP programmatuur die niet zal gaan werken op een nieuwere serveromgeving. Raadpleeg diegene die dit aan je heeft geleverd, dus de ontwikkelaar. Helaas kunnen wij hier niet mee helpen...

Resumé; probeer er altijd voor te zorgen dat je een actuele PHP-versie gebruikt. Op die manier voorkom je eventuele problemen in de toekomst. En bij een Plesk server migratie naar een nieuwere omgeving, moet je de PHP-versies minimaal op PHP 5.6 zetten en dat deze uitgevoerd wordt als zijnde FastCGI. Hogere PHP-versies zijn altijd beter uiteraard (qua veiligheid en performance). Wanneer je dit niet aanpast alvorens een server migratie, dan is de kans aannemelijk dat de website niet meer zal werken na de migratie en dan zal je dit zelf achteraf moeten oplossen. Bij een Plesk server migratie migreren wij websites naar de eerst mogelijke c.q. beschikbare PHP-versie (normaliter PHP 5.6 of PHP 7.1 en hoger). Indien de website voordien niet is aangepast en/of getest, dan zal je dit zelf achteraf moeten corrigeren c.q. oplossen. Dit is niet iets wat bij de migratie is in begrepen.

In Plesk is er sinds enige tijd een nieuwe functie bijgekomen, namelijk de Plesk "Performance Booster"-functie.

Deze zou volgens Plesk dus een performance boost aan je website geven, echter zien wij met enige regelmaat problemen hierdoor ontstaan met bestaande websites. Zeker met websites op basis van een CMS (Wordpress, Drupal, Joomla e.d.), daar deze vaak plugins en/of extensies hebben, waardoor dit problemen op kan leveren. In veel gevallen kan dit zelfs je website compleet breken (en dus offline zetten). In sommige gevallen zal zelfs een back-up teruggeplaatst moeten worden.

Daarnaast zal deze functie sowieso meer (RAM) geheugen gaan verbruiken, wat weer tot andere problemen kan leiden inzake uw serveromgeving en/of websites. Dit wordt ook duidelijk vermeld in het venster van de Plesk Performance Booster, ik citeer: Performance improvements may result in increased RAM utilization. We recommend monitoring the server for possible out-of-memory events.

Aangezien wij altijd een server optimaal configureren, is het activeren van de "Performance Booster"-functie ook niet echt nodig. Indien u dit toch activeert, dan is dit geheel op eigen risico (zie ook nieuwe update hieronder). Wanneer u deze functie activeert en dit tot (serieuze) problemen leidt en u hiervoor een support ticket aanmaakt met het verzoek dat wij kunnen kijken en/of dit kunnen oplossen, dan zal u wel rekening moeten houden met tech kosten. Hoe hoog de tech kosten zijn, dat is afhankelijk van wat er gedaan is en wat de problemen zijn. Dus hou hier rekening mee.

Standaard leveren wij, om de bovengenoemde redenen, dan ook géén support op de Plesk "Performance Booster"-functie. En indien u hiervoor een support ticket aan gaat maken, dan zal u wel te maken krijgen met tech kosten.

Nieuwe update inzake Performance Booster
Wij merken dat klanten toch diverse opties binnen de "Performance Booster" van Plesk activeren. Als een gevolg hiervan, bij servers met weinig geheugen, komt de server in de problemen doordat deze te weinig geheugen beschikbaar heeft. Vervolgens worden bepaalde processen c.q. diensten afgesloten doordat hierdoor niet voldoende geheugen beschikbaar is. Hierdoor kan zelfs de server compleet crashen (met alle gevolgen van dien en kosten). Hou hier rekening mee!

Indien u toch verschillende opties wenst te activeren uit de "Performance Booster", dan is het raadzaam om meer geheugen te bestellen voor uw server. Dit geldt met name voor kleinere servers met minder dan 10 GB dedicated geheugen. Ook is het één en ander afhankelijk van andere factoren, zoals de zwaarte/complexiteit van de websites (met name Wordpress/Joomla) en het aantal bezoekers. Als u deze optie activeert dan moet u doorgaans rekening houden dat u bij een kleinere server toch wel minimaal het dubbele aan dedicated geheugen nodig heeft, zonder dat uw server hierdoor in de problemen komt!

Aangezien er nog een aantal Plesk reseller nodes nog op een zeer oud besturingssysteem draaide (CentOS 6.x) zijn deze automatisch gemigreerd naar een nieuwere omgeving. Indien uw (oude) Plesk reseller pakket op één van de onderstaande reseller nodes stond, dan is deze inmiddels gemigreerd naar een nieuwe reseller node. De grootste voordeel is dat u o.a. van nieuwere PHP-versies gebruik kunt maken nu (o.a. PHP 8.x).

Verderop deze pagina ziet u welke (oude) Plesk reseller nodes inmiddels zijn gemigreerd naar een nieuwe omgeving. Wij willen u adviseren om de onderstaande informatie toch goed door te lezen. Op die manier bent u volledig op de hoogte van wat er wel en niet is gemigreerd. Door verschillende server configuraties (besturingssysteem, Plesk versie e.d.) kan niet alles gemigreerd worden. Dus lees dit aandachtig door!

Deze automatische migratie betekend niet dat u van alle nieuwe functies kunt gebruik maken die vandaag de dag worden geleverd met de reseller pakketten. U blijft na deze migratie uw "oude" reseller pakket behouden, zoals deze destijds besteld is. Indien u wenst gebruik te maken van de functionaliteiten van de nieuwe reseller pakketten, dan zal u een nieuw reseller pakket hiervoor moeten bestellen. Eventueel kunnen wij uw huidige reseller pakket handmatig migreren naar deze (allernieuwste) reseller node. Normaliter zitten hier dan wel tech kosten aan verbonden.

Zoals hierboven aangegven kan u dus gebruik maken van nieuwere PHP-versies, waaronder dus ook PHP 8.x. Helaas heeft deze migratie ook een aantal keerzijden, namelijk;

• Apache PHP (mod_php) wordt niet meer ondersteund
  • Het uitvoeren van PHP via Apache PHP is onveilig en langzaam
  • U kan gewoon een andere PHP runtime kiezen, zoals PHP-FPM of FastCGI
  • Wij hebben al talloze keren aangegeven dat mod_php end-of-life (EOL) is

• Website functioneert niet meer of geeft een foutmelding
  • Raadpleeg de log-bestanden van uw website
  • Probeer een andere PHP-versie (lager of hoger)
  • Update uw (Wordpress) website en/of PHP programma's
  • Controleer of u niet dubbele index bestanden heeft staan

• Oude PHP-versies worden voorlopig nog ondersteund
  • Alle PHP 5.x versies blijven momenteel ondersteund worden op de server
  • In de toekomst kan dit uiteraard wel veranderen, daar deze versies EOL zijn

• RoundCube adressenlijst/-bestanden zijn niet gemigreerd
  • Dit was niet mogelijk om mee te migreren van de oude server i.v.m. configuratie verschillen
  • Eventueel kan dit handmatig gedumpt en gemigreerd worden door onze technici
    • Hier zitten wel tech kosten aan verbonden (éénmalig 50.00 Euro)
    • Deze kosten zijn noodzakelijk gezien de uitgebreide handelingen

• Installatron backups en/of instellingen zijn niet gemigreerd
  • Bij server migraties worden Installatron backups nooit gemigreerd
  • Dit komt door onderlinge server verschillen, waardoor dit niet mogelijk is
  • Ook handmatig dumpen en restoren is niet mogelijk

• In Plesk gemaakte back-ups zijn niet gemigreerd
  • Bij server migraties worden Plesk back-ups nooit gemigreerd
  • Dit komt door de onderlinge verschillen van OS en Plesk systeem
  • Ook handmatig dumpen en restoren is niet mogelijk
    • Tip: maak na de migratie z.s.m. een nieuwe Plesk back-up
      

Welke Plesk reseller nodes zijn er inmiddels gemigreerd?

Hier een overzicht van de (oude) Plesk reseller nodes die volledig uitgemigreerd zijn:

• ns1.securenameserver5.net
  • Gemigreerd naar ns1.securenameserver1.net
  • Gemigreerd op 17 november 2022

• ns1.securenameserver15.net
  • Gemigreerd naar ns1.securenameserver1.net
  • Gemigreerd op 16 november 2022

• ns1.securenameserver16.net
  • Gemigreerd naar securenameserver1.net
  • Gemigreerd op 17 november 2022

• ns1.securenameserver14.net
  • Gemigreerd naar securenameserver1.net
  • Gemigreerd op 17 november 2022

De hierboven vermelde oude Plesk reseller nodes, zijn allemaal gemigreerd naar ns1.securenameserver1.net. Dus vanaf nu kan u deze ook gebruiken als zijnde nameservers voor eventuele domeinnaamregistries en/of verhuizingen. Voor de goede orde, u nieuwe nameservers zijn dus als volgt:

• ns1.securenameserver1.net
• ns2.securenameserver1.net

De oude nameservers blijven sowieso (maximaal) 1 jaar actief; dan heeft u voldoende tijd om de nameservers aan te passen. Hetzelfde geldt als u de hostname gebruikt voor de inkomende en uitgaande mailserver. Onderaan deze pagina vindt u de (nieuwe) aanbevolen email instellingen terug voor deze nieuwe omgeving.

Om in te loggen op uw Plesk reseller omgeving, kan u gebruik maken van de volgende link: https://ns1.securenameserver1.net:8443
Uiteraard is ook webmail weer actief op deze Plesk reseller omgeving; deze kan u openen via: https://webmail.securenameserver1.net

De aanbevolen emailinstellingen voor deze reseller node ziet u hieronder terug.

Let op!
Vroeger werd vooral mail.domeinnaam.nl gebruikt. Dit is niet meer van toepassing vandaag de dag. Met dient dus de opgegeven servernaam (zie hieronder) te gebruiken! Deze is namelijk beveiligd met een professioneel SSL certificaat die zorgt voor een beveiligde verbinding tussen uw email programma en de mailserver.

Inkomende email IMAP-instellingen
Servernaam: ns1.securenameserver1.net
Gebruikersnaam: uw volledige emailadres
Wachtwoord: wachtwoord van uw emailadres
Poort: 993
Versleuteling: SSL/TLS
Optioneel: hoofdmap instellen op "Inbox" (zonder aanhalingstekens) voor synchronisatie

Inkomende email POP-instellingen
Servernaam: ns1.securenameserver1.net
Gebruikersnaam: uw volledige emailadres
Wachtwoord: wachtwoord van uw emailadres
Poort: 995
Versleuteling: SSL/TLS

Uitgaande email SMTP-instellingen
Servernaam: ns1.securenameserver1.net
Gebruikersnaam: uw volledige emailadres
Wachtwoord: wachtwoord van uw emailadres
Poort: 587
Versleuteling: STARTTLS

Voorheen werd voor de uitgaande mailserver poort 465 (met SSL) gebruikt. Aangezien deze poort behoorlijk verouderd begint te worden, is vandaag de dag het advies om poort 587 (met STARTTLS) te gebruiken. Zie voor uitgebreidere uitleg hier en hier. Dus wanneer u in de gelegenheid bent, dan adviseren wij u niet meer poort 465 (met SSL) te gebruiken, maar poort 587 (met STARTTLS) voor de uitgaande mailserver. Op die manier zal u ook in de toekomst geen problemen ondervinden met het versturen van email.

In (bijvoorbeeld) Outlook kan u deze instellingen gemakkelijk controleren door te klikken op "Bestand", vervolgens (in het nieuwe scherm) selecteert u het emailaccount waarmee u "problemen" ondervindt. Wanneer u hier het juiste emailaccount heeft geselecteerd, dan klikt u op het icoon met "Accountinstellingen" en aldaar te klikken op "Serverinstellingen". Controleer hier zowel de "Inkomende e-mail"- alsook de "Uitgaande e-mail"-instellingen. Vaak wordt door Outlook automatisch mail.domeinnaam.nl gevonden/gebruikt, dit is echter incorrect!

Wanneer u email problemen ondervindt, controleer dan of uw SPF-record goed staat. Deze moet vergelijkbaar zijn met:

• v=spf1 mx a ip4:83.172.188.51 ip4:83.172.138.9 a:mail.DOMEINNAAM.TLD a:ns1.securenameserver1.net include:relay.mailchannels.net ~all

Met name het laatste gedeelte is zeer belangrijk! Wij gebruiken op alle (nieuwere) reseller nodes een uitgaand mailfilter. Hiermee voorkomen wij dat server op de zwarte lijst komen te staan, wanneer iemand verzuimd om een contactformulier correct te beveiligen of gewoonweg zijn/haar emailadres gehackt is en spam verstuurd. Door dit uitgaande mailfilter voorkomen wij dus dat de mailserver op de zwarte lijst komt en dat niemand meer emails kan versturen. Dus het is zaak om dit de te controleren. Indien u email extern laat lopen lopen, bijvoorbeeld via Gmail of Microsoft, dan is deze aanpassing natuurlijk niet nodig.

De oude nameservers blijven dus maximaal nog 1 jaar actief (tot medio 11.2023). Daarna verlopen de oude nameservers en kan u deze niet meer gebruiken. Hou hier rekening mee!
Indien u vragen en/of opmerkingen heeft inzake de migratie van uw reseller pakket en u heeft het bovenstaande goede gelezen, dan kan u hiervoor een support ticket openen.

Deze handleiding is bedoelt voor eigenaren van een Plesk of DirectAdmin server (VPS / DPS) bij ons. Deze handleiding is aangemaakt om onnodige support tickets te voorkomen en daarnaast om ons eventueel meer duidelijkheid te bieden. Dus wanneer je een Plesk server of een DirectAdmin server hebt en één van je klanten (of uzelf) email problemen ervaart, dan is het ten zeerste aan te bevelen om deze handleiding goed door te lezen. Dit wordt door ons support team zeer op prijs gesteld.

Wanneer je email problemen ervaart, dan is het aan te bevelen om eerst een testaccount aan te maken onder de domeinnaam die problemen oplevert. Vervolgens gebruik je deze gegevens om het emailaccount (bij de bijbehorende domeinnaam) te testen in bijvoorbeeld Outlook, Thunderbird of MacOS Mail. Ook kun je deze gegevens dan snel aanleveren in een support ticket, zodat wij dit kunnen testen bij aanhoudende problemen.

Gebruik altijd de aanbevolen email instellingen (9 van de 10 email problemen ontstaan dus door verkeerde en/of verouderde email instellingen).

Inkomende email IMAP-instellingen (aanbevolen)
Servernaam: SERVERNAAM (is de volledige hostname van uw server, bijvoorbeeld: ns1.servernaam.nl)
Gebruikersnaam: uw volledige emailadres
Wachtwoord: wachtwoord van uw emailadres
Poort: 993
Versleuteling: SSL/TLS
Optioneel: hoofdmap instellen op "Inbox" (zonder aanhalingstekens) voor synchronisatie

Inkomende email POP-instellingen (alternatief; niet aanbevolen)
Servernaam: SERVERNAAM (is de volledige hostname van uw server, bijvoorbeeld: ns1.servernaam.nl)
Gebruikersnaam: uw volledige emailadres
Wachtwoord: wachtwoord van uw emailadres
Poort: 995
Versleuteling: SSL/TLS

Uitgaande email SMTP-instellingen (aanbevolen)
Servernaam: SERVERNAAM (is de volledige hostname van uw server, bijvoorbeeld: ns1.servernaam.nl)
Gebruikersnaam: uw volledige emailadres
Wachtwoord: wachtwoord van uw emailadres
Poort: 587
Versleuteling: STARTTLS

Voorheen werd voor de uitgaande mailserver poort 465 (met SSL) gebruikt. Aangezien deze poort behoorlijk verouderd begint te worden, is vandaag de dag het advies om poort 587 (met STARTTLS) te gebruiken. Zie voor uitgebreidere uitleg hier en hier. Dus wanneer u in de gelegenheid bent, dan adviseren wij u niet meer poort 465 (met SSL) te gebruiken, maar poort 587 (met STARTTLS) voor de uitgaande mailserver. Op die manier zal u ook in de toekomst geen problemen ondervinden met het versturen van email.

Nogmaals; meestal ontstaan problemen door verkeerde email instellingen, bijvoorbeeld bij servernaam mail.domeinnaam.nl in te vullen (dit kan wel, maar hierop moet dan wel een SSL certificaat staan uiteraard). Normaliter is de hostname van een server altijd beveiligd met een SSL certificaat. En als je je klanten deze instellingen doorgeeft, dan is het troubleshooten van eventuele problemen gemakkelijker dan ieder account individueel. Daarnaast worden er ook vaak fouten gemaakt door geen (goede) versleuteling te kiezen of een verkeerd poortnummer ingegeven. Emailprogramma's van vandaag de dag hebben er een handje van om heel gegevens automatisch in te vullen, zoals verkeerde servernamen, verkeerde poortnummers, etc. Dus controleer dit altijd op voorhand.

Ook ontstaan veel problemen doordat klanten dus met verkeerde mailservers versturen. Dan staat het SPF-record goed en DKIM ingeschakeld en toch krijgt u dan een melding van bijvoorbeeld Gmail dat een email geweigerd is. Een voorbeeld hiervan:

emailontvanger@gmail.com
host gmail-smtp-in.l.google.com [108.177.15.26]
SMTP error from remote mail server after pipelined end of data:
550-5.7.26 This mail has been blocked because the sender is unauthenticated.
550-5.7.26 Gmail requires all senders to authenticate with either SPF or DKIM.
550-5.7.26
550-5.7.26 Authentication results:
550-5.7.26 DKIM = did not pass
550-5.7.26 SPF [voorbeelddomein.nl] with ip: [84.116.50.18] = did not pass
550-5.7.26
550-5.7.26 To mitigate this issue, please visit Gmail's authentication guide
550-5.7.26 for instructions on setting up authentication:
550 5.7.26 https://support.google.com/mail/answer/81126#authentication a1-20020a5d5081000000b0032d88e27f9csi2124471wrt.570 - gsmtp

Hier wordt al direct duidelijk dat de klant in kwestie dus niet verzend via uw server, maar via een andere mailserver. Want de IP-range 84.xx.xx.xx behoort simpelweg niet toe aan ons netwerk. Onze IP-range begint met 83.172.xx.xx. Dus als hier wat anders staat, dan worden verkeerde mailservers gebruikt om emails te verzenden. Dit is geen probleem van de server, maar dat de klant in kwestie gewoonweg verkeerde mailservers gebruikt (en wellicht ook nog verkeerde andere instellingen). Dit leidt dus tot problemen; zo zal DKIM niet meer kloppen, maar ook het SPF-record niet, daar email niet wordt verzonden van de server die u bij ons heeft lopen, maar via een andere provider (ISP) wordt verstuurd. Controleer dus eerst de instellingen van de klant in kwestie of test het zelf via een testaccount! Dit scheelt onnodige support tickets.

Wat wij ook vaak zien, is dat er een support ticket wordt ingeschoten inzake mail problemen, maar dat er toch een probleem is met de (mail)server, daar DKIM geactiveerd staat en het SPF-record ook goed zou staan. Dus zou het aan de server moeten liggen. Die kans is klein, maar goed het kan. Vervolgens gaan wij kijken en dan zien wij dat de domeinnaam via elders geregistreerd staat en dus vervolgens doorgepoint wordt naar uw server. Tsja. Dan zal het SPF- en DKIM-record op uw server natuurlijk niet werken, daar de andere server leidend is (daar komt het verkeerd op binnen).

Dus in dat geval zal je bij die andere provider het DKIM-record alsook het SPF-record aldaar moeten aanpassen. Anders zal email nooit correct afgeleverd worden. Dit gebeurd ook met enige regelmaat en hier kunnen wij weinig aan veranderen, daar wij natuurlijk geen toegang hebben tot servers van derden. Controleer dit dan ook altijd als eerste. Wederom zal dit een hoop onnodige support tickets schelen. Uiteraard kun je ook de domeinnaam verhuizen naar uw eigen server, dan wordt alles geregeld vanaf uw server.

Al onze servers zijn voorzien van diverse beveiligingen, althans zo leveren wij deze op. Zo kan het dus zijn dat een klant (of u) tijdelijk geblokkeerd wordt na herhaaldelijk verkeerd inloggen. Wacht daarom altijd minimaal 20 minuten om er zeker van te zijn dat er géén sprake is van een tijdelijke blokkade.

Bij Plesk kun je dit terug opzoeken in "IP Address Banning (Fail2Ban)" in de Plesk interface, maar ook via SSH in het bestand /var/log/fail2ban.log. Hiervoor moet u wel de IP-adressen van een klant weten (zowel IPv4 alsook IPv6). Bij DirectAdmin is dit terug te vinden in "ConfigServer Security & Firewall" in de DirectAdmin interface, maar ook via SSH in het bestand /var/log/lfd.log. Ook hier moet u wel de IP-adressen weten van uw klant (en eveneens het IPv4- alsook het IPv6-adres). Ook deze informatie hebben wij nodig in een support ticket om eventuele problemen te kunnen onderzoeken. En ook dit kan u eerst zelf testen via het aanmaken van een testaccount onder de domeinnaam zelf.

Daarnaast ontstaan veel problemen door het ontbreken van een DKIM-record of een incorrect / incompleet SPF-record. Beiden zijn vandaag de dag een verplichting om correct emails af te kunnen leveren. DKIM kan simpel geactiveerd worden binnen Plesk door naar de domeinnaam in kwestie te gaan en vervolgens naar "Mail Settings" en aldaar DKIM simpel aan te vinken. Plesk maakt dan gewoon een correct DKIM-record aan. Bij DirectAdmin is dit ook te realiseren (mits DKIM geactiveerd staat op uw server); ga naar de gebruiker in kwestie (van de domeinnaam) en login als klant zijnde. Vervolgens ga je naar "E-mail Accounts" en dan zie je aan de rechterkant de optie "Enable DKIM", hierop klikken en DKIM staat eveneens actief.

Een SPF-record is een ietswat lastiger situatie, maar doorgaans (met de servers die wij de laatste jaren opleveren) staat het SPF-record standaard al gewoon goed (bij nieuw aangemaakte accounts). Problemen ontstaan pas wanneer men dit gaat aanpassen op verzoek van de klant, bijvoorbeeld door gebruik van externe programma's (denk aan boekhouding, mailinglijsten, externe mailprogramma's en ga zo maar door). Je kan een SPF-record gemakkelijk online testen via hier, hier en hier. Dus vollop mogelijkheden om dit zelf te testen.

U kan uiteraard ook nog het één ander testen via de webmail functie van uw serveromgeving. Wanneer deze wel probleemloos emails verzend, dan ligt het probleem echt aan de instellingen van het gebruikte emailprogramma (zie wederom boveaan). Mocht u vanuit webmail ook niet kunnen emailen, dan ligt het probleem waarschijnlijk aan het ontbreken van DKIM-records of aan een incorrect c.q. incompleet SPF-record.

En mocht u (of uw klant), na het bovenstaande, nog altijd problemen ervaren, dan kan u altijd een support ticket aanmaken. Wanneer u dit doet doet, lever dan altijd zoveel mogelijk informatie aan, want hoe meer informatie aangeleverd wordt, hoe sneller en gemakkelijker wij kunnen handelen en het eventuele probleem oplossen uiteraard. Denk hierbij aan het volgende;

• Lever een testaccount aan met complete inloggegevens en dergelijke
• Lever zoveel mogelijk informatie aan inzake het probleem en wat u gecontroleerd heeft
• Wanneer is het probleem ontstaan en waren ervoor ook al problemen?
• Komt het probleem voor bij iedere email die verzonden/ontvangen wordt of puur en alleen één specifiek adres?
• Wat heeft u zelf voor de rest voor acties ondernomen en/of getest?

Tot slot; hoewel het inschakelen van DKIM en een goed aangemaakt SPF-record zeer belangrijk zijn voor het afleveren van email, is dit géén enkele garantie dat email niet in de spammap of map met ongewenste emails beland. Hiervoor hebben wij al jaar en dag een seperaat Helpburo kennisbank artikel voor online staan. Zie hier: https://www.helpburo.eu/Knowledgebase/Article/View/emails-worden-aangezien-als-spam-en-belanden-in-spammap. Dit is voornamelijk nog altijd een probleem bij gratis emailaccounts van Microsoft (denk aan Hotmail, Outlook.com, Live, MSN en dergelijke) en hier valt bar weinig aan te doen. Maar dit wordt ook zeer duidelijk uitgelegd in het desbetreffende kennisbank artikel.

U kan eventueel een klacht indienen bij Plesk, alsook bij WebPros en bij Oakley Capital.

• Emailadressen van Plesk (ontwikkelaar van het controle paneel op uw server)
  • oavrumov@plesk.com
  • skalmykov@plesk.com
  • vkuznetsov@plesk.com
  • ckoch@plesk.com

• Emailadressen van WebPros (dit is de portfolio van Oakley Capital)
  • christian.koch@webpros.com
  • joerg.strotmann@webpros.com
  • veronica.stapleton@webpros.com

• Emailadressen van Oakley Capital (eigenaar van o.a. Plesk, cPanel en WHMCS)
  • david.till@oakleycapital.com
  • alex.collins@oakleycapitalinvestments.com

In de toekomst zullen wij de bovenstaande emailadressen verder uitbreiden. Dus u kan hier uw ongenoegen uiten inzake de (jaarlijkse) verhogingen bij Plesk. Wij hebben hier al talloze discussies over gehad met alle partijen die hierbij betrokken zijn, maar ze geven hier helemaal geen gehoor aan. Ze blijven gewoon doorgaan met het verhogen van de prijzen ieder jaar.

Dit treft dus niet alleen Plesk, maar ook andere onderdelen/producten/diensten die allen staan in de portfolio van WebPros waarvan Oakley Capital de eigenaar is. Dit is een investeringsmaatschappij die alleen geinteresseerd is om zoveel mogelijk winst te maken. Ook die andere diensten in diezelfde portfolio krijgen ieder jaar te maken met verhogingen o.a. cPanel, SolusVM, WHMCS, Sitejet, Xovi, Koality en ga zo maar door.

Hier kun je voorgaande aangekondigde prijsverhogingen van Plesk inzien (sommigen zijn inmiddels al offline gehaald, daar dit een negatief beeld werpt op Plesk (vermoedelijk): hier, hier, hier en hier. De teksten zijn allemaal zo goed als gelijk (dus een simpele "copy & paste" vanuit Plesk) op al die pagina's. Op basis van de eerdere prijsverhogingen zal men in de toekomst de volgende pagina's gaan gebruiken om nieuwe verhogingen aan te kondigen:

• https://www.plesk.com/plesk-price-adjustment-2024-2025-online-customers/
• https://www.plesk.com/plesk-price-adjustment-2025-2026-online-customers/
• https://www.plesk.com/plesk-price-adjustment-2027-2028-online-customers/

Uiteraard zijn deze vandaag nog niet beschikbaar, maar de toekomst zal dit uitwijzen...

Dus mocht u uw beklag willen doen inzake de jaarlijkse prijsverhogingen vanuit Plesk, dan kan u de hierboven genoemde emailadressen gebruiken. Wanneer wij andere emailadressen bemachtigen, dan zullen wij deze vanzelfsprekend updaten. Wij vermoeden dat het weinig zal uithalen, maar wie weet als meerdere klanten zich gaan melden.

Voorwoord: dit artikel heeft alleen betrekking op Plesk webhosting pakketten c.q. hostingaccounts en niet op afgenomen servers, reseller pakketten of DirectAdmin webhosting pakketten.

Inleiding

Op een aantal Plesk servers is het niet mogelijk om een PHP-versie hoger te kiezen dan PHP 7.3. Hoewel dit niet direct een probleem hoeft te zijn, kan het wezen dat de door u gebruikte c.q. geinstalleerde programmatuur of applicaties de melding geeft dat u een hogere PHP-versie moet kiezen. Denk bijvoorbeeld aan CMS applicaties zoals Wordpress en Joomla.

Kanttekening; de kans dat PHP zelf gehackt wordt in onze beveiligde omgevingen is absoluut minimaal en de grootste aantal hacks (99%) gebeuren nog altijd op niet of slecht onderhouden websites. Wij zien regelmatig extreem gedateerde websites die o.a. draaien op Wordpress, Joomla, Drupal en die al jaar en dag niet meer onderhouden zijn. Zo is niet alleen bijvoorbeeld de "core"-software (dus bijvoorbeeld Wordpress, Joomla, etc.) zelf al maanden (soms jaren) niet meer geupdate, maar ook verouderde plugins, extensies of thema's. Ook zien wij vaak dat er bepaalde plugins of extensies worden gebruikt die gewoonweg EOL (End-Of-Life) zijn en die niet meer worden onderhouden door de ontwikkelaar hiervan. U of diegene die uw website onderhoud dient hier zelf zorg voor te dragen.

Terugkomend op nieuwere PHP-versies; zoals u hierboven kunt nalezen kunnen op bepaalde Plesk webhosting servers geen nieuwere PHP-versies gekozen worden dan PHP 7.3. Wij zijn momenteel druk bezig om deze Plesk servers uit te migreren naar nieuwere servers, echter is dit een zeer tijdrovende klus en kan dit niet binnen een maand gerealiseerd worden. Indien u toch gebruik wenst te maken van nieuwere PHP-versie, dan hebben wij hiervoor twee mogelijkheden. Deze worden hieronder uitgelegd. Daarnaast het advies om de overige punten ook te lezen inzake dergelijke Plesk server migraties.

Optie 1

U blijft voorlopig gebruik maken van PHP 7.3 (wat geen risico vormt, alleen krijgt u meldingen te zien in de door u gebruikte programmatuur) en wacht de automatische migratie af van de Plesk server waar uw hostingaccount op staat. Wij kunnen geen mededelingen doen over wanneer de server in kwestie aan de beurt is (dus ook aub geen tickets hierover aanmaken). Afhankelijk van hoe de huidige migraties verlopen (het gaat om enkele honderden Plesk hostingaccounts), verwachten wij dat dit zal plaats vinden medio het 1e kwartaal van 2022. U hoeft hierbij niks te ondernemen, dit gebeurd volledig automatisch te zijner tijd.

• Nadeel: u moet langer wachten totdat uw Plesk hostingaccount gemigreerd wordt naar een nieuwere serveromgeving met PHP 7.4, PHP 8.0 of hoger (inmiddels zijn alle Plesk omgevingen gemigreerd)
• Voordeel: u hoeft geen wijzigen door te voeren op uw apparaten waar u email mee ontvangt en/of verstuurd, dus alles blijft hetzelfde zoals nu

Optie 2

U wilt zo spoedig mogelijk migreren naar een nieuwere serveromgeving met PHP 7.4, PHP 8.0 of hoger. U dient in dat geval een support ticket aan te maken op Helpburo.eu met het verzoek tot migratie van uw Plesk webhostingaccount. Dit kan niet per email! Wanneer u voor deze route kiest, dan dient u zelf wel de inkomende en uitgaande mailservers aan te passen op alle apparaten waarmee u email verstuurd en/of ontvangt (dus computers, laptops, tablets, telefoon, etc.). Uw wachtwoorden blijven normaliter gelijk, tenzij de wachtwoorden zeer zwak zijn (iets waar wij al herhaaldelijk op hebben gehamerd). In dit geval worden ook de wachtwoorden aangepast en dan vermeld in het support ticket tesamen met de nieuwe mailservers.

• Nadeel: u zal de inkomende en uitgaande mailservers moeten aanpassen op alle apparaten waar u email mee verstuurd en waar u email mee ontvangt
• Voordeel: u kan na de migratie direct gebruik maken van de nieuwere PHP-versies die beschikbaar zijn op de nieuwe Plesk server
  

Voor een handmatige migratie rekenen wij éénmalig 15.00 Euro tech kosten.

Overige (migratie) zaken

Welke optie u ook kiest (automatische migratie of handmatige migratie) u moet met een paar overige zaken rekening houden. Deze zaken hebben betrekking op de onderlinge server verschillen van oudere en nieuwere servers. Het één en ander wordt hieronder daarover verder uitgelegd. Wij willen u derhalve vriendelijk vragen om dit dan ook goed door te nemen c.q. te lezen. Mocht uw account gemigreerd worden (handmatig of automatisch), dan gaan wij ervan uit dat u hiervan dan ook kennis heeft genomen.

Spamprotector gebruiker

Wanneer uw Spamprotector heeft geactiveerd staan op uw Plesk hostingaccount, dan zal deze uiteraard ook weer geactiveerd na de migratie. Bij een automatische migratie (optie 1) gaat dit volledig automatisch. Bij een handmatige migratie (optie 2) dienen wij tijdelijk Spamprotector uit te zetten en na de migratie wederom aan te zetten. U kan in die tussenliggende periode wel meer spam krijgen c.q. verwachten. Na de migratie activeren wij Spamprotector wederom. Dit geldt dus alleen wanneer u een Spamprotector abonnement bij ons heeft op uw Plesk webhosting pakket.

MySQL database

De oudere Plesk servers (voor hostingaccounts) maken voornamelijk nog gebruik van MySQL 5.6. Ook deze versie is ondertussen verouderd. Wanneer wij uw account handmatig migreren, dan komt u op een Plesk server te staan met MariaDB 10.4 (of hoger). Bij een automatische migratie komt u op een Plesk server te staan met MariaDB 10.3. U of uw websitebouwer dient wel rekening te houden met het feit dat uw website een dergelijk moderne database ondersteund.

Normaliter vormt dit geen enkel probleem bij goed onderhouden Wordpress, Joomla, Drupal, etc. websites. Deze bieden allemaal ondersteuning hiervoor. De software die vaak problemen vertonen zijn meestal custom (zelfgeschreven) programmatuur of enorm gedateerde software. Vaak draaien dergelijke websites ook op zeer oude PHP-versies (zoals PHP 5.3). Dit soort websites zijn meer dan 7 jaar oud en nooit onderhouden. Zoals u kunt begrijpen kunnen wij hierop geen ondersteuning leveren. U of diegene die uw website heeft gemaakt of onderhoudt, dient dan de programmatuur aan te passen. Dit laatste is sowieso raadzaam bij dergelijke oude websites (vanwege de vele veiligheids risico's).

Installatron gebruikers

Wanneer u gebruik maakt van Installatron, dan bent u (normaliter) de gemaakte backups via Installatron kwijt. Dit heeft te maken met de nieuwere serveromgeving, waarbij oude backups niet functioneren. Ook kunnen bepaalde instellingen m.b.t. Installatron verloren gaan. Dit geldt voor beide migratie opties. Wanneer u een bepaalde applicatie heeft geinstalleerd en gebruikt via Installatron, dan bent u deze natuurlijk niet kwijt. Ook zal uw website ook gewoon door blijven werken. Vandaag de dag, met dank aan Plesk technici, worden dergelijke geinstalleerde (Installatron) applicaties wel herkent en weer toegevoegd aan uw Installatron omgeving. Bij zeer oude servers is dit helaas niet het geval (dit vanwege de oudere server configuratie, die sterk afwijkt van de nieuwere omgevingen). Maar, hoe dan ook, u bent niet uw website kwijt. Wel is het raadzaam, wanneer u Installatron gebruikt, om deze na te lopen in Installatron of deze opnieuw toe te voegen aan Installatron (indien mogelijk) wanneer deze niet aldaar wordt weergegeven.

Overige informatie

Ondertussen hebben wij al behoorlijk wat migraties van oudere Plesk naar nieuwere Plesk omgevingen achter de rug. Het meerendeel van de gemigreerde websites hebben geen problemen opgeleverd. Ook emails alsook emailaccounts, databases, aangepaste DNS-records worden allemaal netjes mee over gemigreerd. In sporadische gevallen kunnen er toch altijd problemen optreden. Meestal heeft dit als oorzaak oude of custom geschreven programmatuur die gewoonweg niet overweg kunnen met de nieuwe serveromgeving. Maar zoals aangegeven betreft dit een zeer klein percentage (minder als 4% van alle gemigreerde websites).

Bij beide migraties zal u nagenoeg geen downtime ervaren; de website zal gewoon door blijven functioneren en uw email zal ook bereikbaar blijven. Wel passen wij wachtwoorden aan van emailaccounts die niet veilig voldoende zijn. Hetzelfde geldt voor MySQL databases. Wanneer dit gebeurd, dan melden wij dit nadien in het support ticket. Het is altijd aan te bevelen om een support ticket aan te maken met het probleem dat u ervaart met uw website of emailadres, daar dit veelal sneller werkt (en wij over meer noodzakelijke informatie beschikken) dan per telefoon of per email. Maar dit geldt voor alle technische vragen en/of problemen.

Tags: plesk webhosting, plesk webhosting pakket, php7.4, php 7.4, php8.0, php 8.0, php8

Aangezien wij onze webhosting pakketten regelmatig updaten en/of aanpassen, kan het voorkomen dat u bijvoorbeeld minder ruimte heeft dan vandaag de dag op de website vermeld staat. Zo kan het dus voorkomen dat u nog 1000 MB pakket heeft, terwijl hetzelfde hosting pakket op de website staat vermeld met (veel) meer ruimte voor dezelfde prijs.

Wij snappen goed dat u ook hiervan gebruik wilt maken. En dat is natuurlijk wel mogelijk. Echter zal dit waarschijnlijk niet op dezelfde (huidige/oude) server kunnen als waar u nu op staat. Dit heeft te maken met de beschikbare resources (bijvoorbeeld opslagruimte) van een server. Als wij dergelijke aanpassingen globaal zouden doorvoeren, dus in één keer voor alle hostingaccounts, dan zou er niet meer voldoende ruimte op de server beschikbaar zijn en zou deze dus kunnen crashen met alle gevolgen van dien. Dat is iets wat wij 100% willen voorkomen uiteraard.

Indien u gebruik wenst te maken van de nieuwe hostingpakket specificaties, dan moeten wij uw hostingaccount verhuizen naar een nieuwere en grotere server. Een bijkomend voordeel is wel dat deze nieuwere server ook vaak weer sneller is. Dit heeft te maken met nieuwere en snellere hardware van een server. Ook is de achterliggende virtualisatie (die wij gebruiken voor al onze servers) nieuwer, wat ook weer ten goede komt van de performance.

Helaas zitten er ook een paar nadelen verbonden een dergelijke server migratie, namelijk;

• U verliest uw contacten/adresboek/aanpassingen in Roundcube of Horde webmail
• U verliest de door u gemaakte back-ups binnen Plesk via Plesk back-up manager
• Afgeschermde c.q. beveiligde mappen moeten opnieuw ingesteld worden
• De inkomende en uitgaande mailservers veranderen en deze dienen aangepast te worden
• Eénmalige tech kosten van 15.00 Euro voor het migreren van uw hosting account (tijdens kantooruren)

In sommige gevallen worden Installatron instellingen en/of back-ups niet meegenomen tijdens de migratie. Dit is niet altijd het geval en varieert per server. Uiteraard wordt de website zelf wel gemigreerd. Het heeft puur en alleen betrekking op Installatron. Helaas kunnen hieraan geen garanties worden verleend of deze specifieke Installatron instellingen gemigreerd worden.

Wat wordt er sowieso wel gemigreerd? Uw complete website (bestanden en databases), uw emailaccounts en emails (*) en DNS records. Na de migratie wordt het één en ander ook nog gecontroleerd door de tech die de migratie doet van uw hostingaccount. Ook worden oude c.q. incorrecte DNS-records handmatig gecorrigeerd door de tech. Wanneer de migratie voltooid is, dan wordt uw hostingpakket aangepast naar de actuele instellingen zoals vermeld op de website (ten tijde van de migratie). Het oude hostingaccount wordt vervolgens dan op non-actief gezet en na enkele dagen automatisch verwijderd. Indien er problemen zijn, dan dient u dit z.s.m. aan te geven uiteraard. Onze ervaring leert dat er na een dergelijke migratie bijna nooit problemen zijn.

(*) indien uw email extern loopt, dus bijvoorbeeld via Gmail of Office 365, dan worden de oude emailaccounts niet gemigreerd. Dit heeft te maken doordat de Plesk Migratie Tool ziet dat de mailaccounts (lokaal) uit staan en lopen via Gmail/Office 365 en worden dan niet gemigreerd. Uw email zal nadien ook gewoon blijven werken via Gmail/Office 365.

Wanneer u met het bovenstaande akkoord gaat, dan kan u een support ticket aanmaken. Dan zullen wij de migratie inplannen met een tech.

Tags: nieuwe hosting pakketten, nieuw plesk hosting pakket, meer ruimte op website, hostingruimte incorrect, te weinig hostingruimte

Let op! Geen PHP 7.4 of hoger? En u heeft een Plesk webhosting pakket? Kijk dan hier!

Binnen Plesk is het mogelijk om diverse PHP-versies te kiezen (onder "PHP Settings" of "PHP-instellingen").
Op sommige servers is zelfs versie 8.2 vandaag de dag mogelijk.

Doorgaans kunt u altijd de volgende PHP-versies kiezen:

• PHP 5.3 (EOL)
• PHP 5.4 (EOL)
• PHP 5.5 (EOL)
• PHP 5.6 (EOL)
• PHP 7.0 (EOL)
• PHP 7.1 (EOL)
• PHP 7.2 (EOL)
• PHP 7.3
• PHP 7.4 (op sommige servers) *
• PHP 8.0 (op sommige servers) *
• PHP 8.1 (op sommige servers) *
• PHP 8.2 (op sommige servers) *

* Indien deze optie niet beschikbaar is en hier wel gebruik van wenst te maken, dan klikt u hier.

PHP-versie veranderen binnen Plesk

Log in op uw Plesk omgeving (niet met uw emailadres, maar met uw domeinnaam of gebruikersnaam).
Klik nu op de tekst "PHP Settings" of "PHP-instellingen".

Indien u dit nooit heeft aangepast, kan het wezen dat deze op "Apache" PHP staat (run PHP as / PHP uitvoeren als).
Het is aan te bevelen om PHP te draaien als "FPM application" of "FPM-toepassing". Dit heeft als reden:

• Veel sneller; FPM is wel tot 5 keer sneller als wanneer deze uitgevoerd wordt als Apache process.
• Vele malen veiliger; doordat PHP als een gescheiden process gedraait wordt, minimaliseert dit veiligheidsrisico's.

U kan ook tegenwoordig (op bepaalde servers) ook kiezen om PHP uit te voeren als FastCGI. Deze is vergelijkbaar met FPM.

U kan vervolgens zelf de gewenste PHP-versie kiezen.

Op al onze shared hosting servers met Plesk of DirectAdmin staat ImunifyAV+ geinstalleerd (en ook op de nieuwste reseller nodes). Dit programma scant periodiek alle websites op een server op o.a. malware, virussen, trojan, backdoors, shell scripts, malafide of gehackte bestanden. Dit zorgt niet alleen voor een veilige website, maar ook voor een veilige server en onderliggende hosting omgeving voor andere klanten.

Wij gebuiken ImunifyAV+ inmiddels alweer een paar jaar naar volle tevredenheid; deze is in de plaats gekomen van Patchman, welke opeens absurde prijsverhogingen ging doorvoeren. Hierdoor moesten wij op zoek naar een betrouwbaar alternatief. Na het testen van verschillende oplossing zijn wij vervolgens uitgekomen bij ImunifyAV. Hierbij hebben wij rekening gehouden met drie zaken die voor ons belangrijk zijn; hoge betrouwbaarheid, goede performance en betaalbaar. ImunifyAV+ voldeed hierin aan alle verwachtingen.

Zoals aangegeven hierboven, staat ImunifyAV+ op al onze shared hostingomgevingen geinstalleerd (en daarnaast ook op onze nieuwste reseller nodes). ImunifyAV+ scant periodiek alle (web)bestanden op malware en dergelijke. Wanneer deze ongewenste/onveilige bestanden vindt, dan wordt hier een melding van gestuurd (naar het contact adres van het hostingpakket). U kan dan zelf het één en ander controleren en opschonen. Wanneer er niks wordt gedaan, dan zal ImunifyAV+ automatisch de bestanden opschonen en/of verwijderen (in het ergeste geval). Helaas moeten wij constateren dat meer dan 95% van de gebruikers helemaal niks doet aan dergelijke meldingen; die dus niet alleen een negatieve invloed kunnen hebben op uw website (o.a. bij Google eruit gegooid worden, website op non-actief en dergelijke), maar ook de algemene veiligheid van onze servers om nog maar te zwijgen over server performance.

Dus wordt er geen actie ondernomen van uw kant, dan worden de bestanden automatisch opgeschoond door ImunifyAV+ en wanneer de bestanden niet opgeschoon kunnen worden (om welke reden dan ook), dan worden deze verwijderd. Hierdoor kan het voorkomen dat uw website het opeens niet meer doet. Kijk in dat geval naar uw eerdere email meldingen of online in uw Plesk of DirectAdmin interface (en vervolgens onder "ImunifyAV"-link). Er worden dan verschillende acties weergegeven inzake het opschonen. Ook kunnen (in sommige gevallen) bepaalde acties ongedaan worden gemaakt; hou dan wel rekening ermee dat uw website opnieuw als onveilig wordt aangemerkt met alle gevolgen van dien.

De veiligheid van onze servers en alle hosting klanten op een bepaalde server, gaan altijd voor op individuele websites. Meestal worden (Wordpress) websites gehackt door slechte beveiliging, het niet updaten/onderhouden van een website (Wordpress core, Wordpress plugins en Wordpress thema's), oude en/of onveilige plugins gebruiken (o.a. die EOL zijn) en ga zo maar door. Als men verzuimd om de website up-to-date te houden, dan is de kans zeer groot dat deze gehackt wordt. Wij zijn nooit verantwoordelijk voor wat u op uw hostingaccount plaatst; wel gaan wij ervan uit dat u dit zelf periodiek onderhoudt of dit door uw websitebouwer laat doen. Wij zijn alleen verantwoordelijk voor het updaten en beveiligen (en veilig houden) van een (web)server. Wanneer een individuele website hierin voor problemen zorgt, dan voeren wij direct maatregelen uit om de veiligheid van de andere klanten en onze server(s) te kunnen waarborgen. In dat geval sturen wij geen melding; in onze ervaring duurt het vervolgens enkele maanden alvorens men er opeens achterkomt dat de website niet meer oproepbaar is. Dit zegt dan ook alweer genoeg hoe men met de veiligheid van zijn/haar website omgaat en dat men dus totaal niet omkijkt naar eventuele updates e.d.

Wij hebben, met name voor Worpress, diverse kennisbank artikelen online staan. Deze bieden veel informatie over veel voorkomende problemen inzake Wordpress en onderliggende zaken (thema's, plugins en dergelijke). Ook wat u kunt doen om Wordpress te beveiligen of wanneer uw Wordpress website langzaam is. Hieronder een overzicht van onze huidige kennisbank artikelen inzake Wordpress:

• Mijn Wordpress website is gehackt
• Wordpress website langzaam of slechte performance
• Verbeter de veiligheid van WordPress
• WordPress pagina blanco / wit (al dan niet na updates)
• Pas op voor commerciele Wordpress plugins
• Versnel Wordpress met Varnish Cache op Plesk servers

Kanttekening; de meeste artikelen zijn actueel, andere worden op korte termijn voorzien van nieuwe updates.

Het is dus een absolute noodzaak om uw (Wordpress) website regelmatig te onderhouden en te voorzien van nieuwe updates (en pas ook periodiek alle wachtwoorden eens aan). Heel veel mensen denken altijd nog dat wanneer een (Wordpress) website online staat, dat deze vervolgens nooit meer onderhouden hoeft te worden als er geen nieuwe inhoud wordt toegevoegd. Dat is dus 100% fout. Wordpress is een prachtige oplossing voor het maken van (al dan niet professionele) websites met een paar klikken, maar dergelijke programma's dienen ook dus regelmatig te onderhouden worden. Wij adviseren om een Wordpress websites tussen de 2 á 4 weken te controleren op mogelijke updates en deze (waar nodig) te updaten. Doet u dit niet, dan is de vraag niet of uw website gehackt wordt, maar wanneer... Een niet onderhouden Wordpress website wordt altijd wel een keer gehackt! Dus hou uw website up-to-date!

Indien u zelf niet uw website kunt updaten, dan dient u contact op te nemen met diegene die uw website heeft gebouwd c.q. gemaakt. Indien deze niet voorhanden is en/of niet meer bestaat, dan zal u op zoek moeten gaan naar een nieuwe partij in deze. In het ergste geval kunnen wij uw Wordpress website voorzien van de laatste updates en weer helemaal veilig maken, maar de kosten hiervoor zijn afhankelijk van het feit hoe erg uw (Wordpress) website verouderd is. Hoe meer werk wij hier aan hebben, hoe hoger de kosten zullen zijn. Vergelijk het met auto onderhoud; als u jaren uw auto niet heeft laten onderhouden, dan zullen de kosten bij een eerste onderhoud ook behoorlijk zijn. Zo ook met een (Wordpress) website. Wij zijn nooit verantwoordelijk voor het onderhoud van uw Wordpress website of onderliggende Wordpress plugins en/of Wordpress thema's. Dit moet u zelf doen of diegene die uw website heeft gebouwd!

Indien u niemand heeft die dit voor u kan doen of u heeft geen contact meer met diegene die uw website heeft gemaakt, dan kan u ons eventueel laten kijken naar uw (Wordpress) website. In dat geval kan u een support ticket aanmaken op ons online support systeem (helpburo.eu). Voor het handmatig inspecteren van uw (Wordpress) website worden er altijd vooraf onderzoekskosten in rekening gebracht van 75.00 Euro. Wanneer de (Wordpress) website opgeschoond en/of hersteld dient te worden, dan volgen er aanvullende tech kosten (doorgaans 25.00 Euro per kwartier); vanzelfsprekend worden de onderzoekskosten hierop in mindering gebracht. Wanneer de (Wordpress) website dermate gehackt is, dat "éénvoudig" herstel / opschoning niet mogelijk is, dan wordt dit eveneens medegedeeld. In dit geval worden er slechts 40.00 Euro onderzoekskosten in rekening gebracht en zal u geadviseerd worden om alles op te laten schonen en met een nieuw (schoon/leeg) hostingaccount te beginnen. Eventueel kan uw email wel bewaard blijven.

Hieronder nog een aantal voorbeelden van ImunifyAV+ detecties (van gehackte websites en/of malafide bestanden). Aansluitend ook nog eens "fake" pagina die probeert creditcard gegevens te stelen van derden. Het spreekt voor zich dat men bij dergelijke zaken direct actie moet ondernemen, anders bestaat de kans dat uw website uit Google wordt verwijderd en/of offline wordt gezet.

Klik op de aafbeeldingen voor een vergroting.

Tags; imunify, imunifyav, imunifyav+, imunifyav plus, geinfeecteerde bestanden, infected files, malware, exploits, root kits, backdoor, shells, cloudlinux

Op (betaalde) Plesk extensies, die u zelf heeft aangeschaft (dus buiten ons om of direct bij Plesk zelf), kunnen wij geen support leveren.

De reden hiervoor is dat wij tijd en energie steken in een Plesk extensie die u niet heeft aangeschaft bij ons. Een vergelijkbaar voorbeeld; als men nieuwe autobanden online besteld en er mankeert iets aan, dan ga je ook niet naar jouw eigen/vaste garage met een klacht over de autobanden die door een andere partij is geleverd. Hetzelfde geldt dus voor de (betaalde) Plesk extensies. Wij rekenen een marginale meerprijs voor de Plesk extensies en daarbij leveren wij dan ook uiteraard support. Sowieso is het verstandig om dergelijke zaken via ons te realiseren, daar dan alles via ons loopt en (indien noodzakelijk) wij ook direct support kunnen aanvragen bij Plesk zelf. Dat is met een plugin die u aanschaft niet het geval helaas (daar de aangeschafte Plesk extensie via een andere partij loopt, namelijk: Cleverbridge).

Op gratis Plesk extensies zit beperkte support van onze kant; indien een dergelijke plugin niet correct werkt, dan zullen wij proberen de oorzaak op te sporen. Kunnen wij niks vinden, dan is het advies om zelf contact op te nemen met de ontwikkelaar van de desbetreffende Plesk extensie. Meestal is dit een andere partij, die hun extensie aanbieden via Plesk. Plesk zelf verwijst ook meestal naar de ontwikkelaar in dit soort gevallen.

Hoe dan ook; heeft u zelf een Plesk extensie aangeschaft via Plesk zelf of elders, dan zal u contact moeten opnemen met de ontwikkelaar van de desbetreffende extensie. Hieronder een aantal bekende c.q. populaire Plesk extensies met de ontwikkelaar van de plugin erachter. Men kan ook proberen om via Plesk zelf support aan te vragen inzake de extensie, maar meestal wordt men dan doorverwezen naar de ontwikkelaar, daar Plesk deze alleen maar (door)verkoopt.

Hieronder een aantal ontwikkelaars van populair Plesk plugins:

• Plesk Premium Email: Kolab / Apheleia IT AG
• Juggernaut Security and Firewall: Danami
• Warden Anti-spam and Virus Protectio: Danami
• ImunifyAV: CloudLinux
• Imunify360: CloudLinux
• SEO Toolkit: XOVI
• Kaspersky Anti-Virus for Server: Kaspersky / Plesk
• Speed Kit: Baqend GmbH
• Acronis Backup: Acronis
• Plesk Email Security: Plesk
• Smart Updates for WordPress Toolkit: Plesk

Op Let's Encrypt SSL certificaten leveren wij geen support, zie ook hier voor meer informatie. De reden hiervoor is dat er regelmatig problemen zijn met deze gratis SSL certificaten helaas. Ook op zogenaamde "third-party" SSL certificaten leveren wij geen support zie hier. In dit geval zal u het beste contact kunnen opnemen met de partij die het SSL certificaat heeft uitgegeven voor u. U heeft bij ons al een goed/professioneel SSL certificaat voor slechts 14.95 Euro voor één jaar. En dat is inclusief support op het SSL certificaat.

Hetzelfde geldt voor voor zelf aangeschafte Plesk licenties (via Plesk zelf of via derden); ook hierop kunnen wij geen support leveren. Onze prijzen zijn altijd scherp inzake de Plesk licenties; zeker inzake onze prijsstelling m.b.t. Plesk licenties voor dedicated servers (DPS). Dit kan u zelf ook controleren op de website van Plesk. Af en toe wordt wel eens vergeten dat een Plesk licentie voor een dedicated server (DPS) bijna het dubbele kost als een reguliere Plesk licentie. Daarnaast krijgt men ook altijd gewoon support op server en/of Plesk problemen via ons, als de licentie bij ons gewoon is afgenomen (inclusief de volledige installatie en configuratie van Plesk zelf).

Mocht u toch support wensen op een zelf aangeschafte Plesk extensie / licentie (dus niet via ons), dan zal het reguliere tech tarief hiervoor gehanteerd worden.

Het onderstaande artikel heeft alleen betrekking op de Plesk reseller pakketten!

U heeft een ouder Plesk reseller pakket, waarbij het niet mogelijk is om een hogere PHP-versie te kiezen als PHP 7.3. Dit is te wijten aan het onderliggende besturingssysteem, dus waar Plesk op draait. Oudere reseller servers beschikken nog over CentOS 6.x, waarbij de ondersteuning vanuit Plesk al enige tijd ten einde is, derhalve zijn er ook geen hogere PHP-versies meer mogelijk op deze oudere reseller omgevingen. Maar wij begrijpen dat nieuwere PHP-versies gewenst zijn, derhalve hebben wij een aantal mogelijkheden voor u op een rij gezet. Wij raden u aan om de twee mogelijkehden goed door te lezen, alvorens u een eventuele keuze maakt.

1. Handmatige migratie naar nieuwe reseller node

Wij migreren uw Plesk reseller pakket uit naar een nieuwere resellere node op basis van CentOS 7.x. Deze reseller node zal zowel oudere PHP-versies alsook nieuwere PHP-versies ondersteunen (o.a. PHP 8.1). Ook zal deze toekomstige c.q. nieuwere PHP-versies ondersteunen. Met deze handmatige migratie krijgt u wel te maken met het volgende;

• U krijgt te maken met compleet nieuwe nameservers;
  • Indien u zelf de domeinnamen in beheer heeft (via ODR of andere oplossing), dan zal u zelf de nameservers moeten aanpassen na de migratie.
  • Indien wij de domeinnamen hebben geregistreerd en deze voor u moeten aanpassen (via bijvoorbeeld DWHS), dan kunnen wij dit voor u aanpassen. De kosten die wij hiervoor berekenen is 1.50 Euro per domeinnaam.
  • Indien u (of uw klanten) de hostname van de oude reseller server gebruikt als mailserver (bijvoorbeeld securenameserverXX.net), dan zal u dit na de migratie eveneens zelf moeten aanpassen in de gebruikte email programma’s.
    
    
• De nieuwe reseller node ondersteund geen mod_php (oftewel Apache PHP) meer;
  • Apache PHP (dus mod_php) werd al jaar en dan als onveilig beschouwd en wordt dan ook niet meer gebruikt op nieuwere server omgevingen.
  • Indien u oude websites heeft draaien op mod_php (te zien in de Plesk interface, onder “PHP Settings” van een domeinnaam), dan zal u dit voor de migratie zelf moeten omzetten naar bijvoorbeeld PHP FastCGI. Doet u dit niet op voorhand, dan kunnen bepaalde websites niet meer functioneren.
    
    
• Er worden éénmalige kosten in rekening gebracht voor de handmatige migratie;
  • De tech kosten zijn 70.00 Euro voor de handelingen die wij moeten verrichten inzake een dergelijke migratie van een reseller pakket.
  • Heeft u meerdere reseller pakketen en moeten deze ook gemigreerd worden naar een nieuwe reseller node, dan betaald u een toeslag van 40.00 Euro voor elk opvolgend reseller pakket.

Actuele wachttijd voor een handmatige migratie: 2 tot 5 weken (afhankelijk van drukte).

Inzake downtime; zo goed als geen downtime. Immers laten wij de domeinnamen actief staan op de oude server enkele dagen en wanneer alle nameservers door u (of door ons tegen betaling) om zijn gezet, wordt een laatste synchronisatie uitgevoerd. Uiteraard is het wel zaak dat de juiste mailservers worden gebruikt en dit tijdig aangepast wordt.

2. Automatische migratie naar nieuwe reseller node

Alle oude reseller nodes worden medio 2023 (o.v.) automatisch gemigreerd naar een nieuwere reseller omgeving eveneens op basis van CentOS 7.x. Bij deze automatische migratie blijven de huidige nameservers wel behouden en hoeft u in feite niks aan te passen. Dus u hoeft o.a. geen nameservers van uw domeinnamen. Ook krijgt u niet te maken met tech kosten. Wat u wel dient te doen is de websites die nog gebruik maken van mod_php (oftewel Apache PHP) om te zetten naar PHP FastCGI. Dit wordt, net als bij de handmatige migratie, niet meer ondersteund op de nieuwe reseller nodes. Doet u dit niet, dan bestaat de kans dat de website niet meer zal werken op de nieuwe reseller node.

Een nadeel van de automatische migratie is er ook, namelijk wanneer de migratie daadwerkelijk plaats zal vinden. Wij hebben een zeer groot aantal reseller klanten verspreid over meerdere reseller nodes. Op dit moment is de verwachte migratie medio 2023, maar dit is onder voorbehoud. Het migreren van dergelijke aantallen reseller pakketten neemt behoorlijk wat tijd en werk in beslag. In eerste instantie was aangegeven de volledige migratie te hebben afgerond 4e kwartaal van 2020, echter mede door aanhoudende drukte en problemen inzake sommige domeinnamen van resellers (gebruik mod_php) is er vertraging opgelopen. Ondertussen zijn er wel een aantal servers uitgemigreerd naar een nieuwere omgeving, maar nog een groot aantal niet. Wilt u niet wachten, dan is het verstandig om een handmatige migratie aan te vragen (zie hierboven). Inmiddels is de looptijd hiervan ook hoger geworden (dit met heel veel nieuwe server orders, andere ingeplande onderhouds werkzaamheden en het oplossen van problemen).

Indicatie geplande automatische migratie: medio 2023 (o.v.).

Inzake downtime; een (groot) aantal uren, afhankelijk van het aantal reseller pakketten op de node, de hoeveelheid gebruikte opslag en drukte op de server. Dergelijke server migraties worden einde van de middag opgestart. Dit vanwege de mogelijke duur van de migratie (enkele uren). Wilt u niet een dergelijke downtime, dan is het wellicht raadzaam om te kiezen voor een andere migratie.

Opmerking; waarom is de planningsdatum zo ver vooruit? De reden hiervoor is vrij gemakkelijk uit te leggen; niet alle resellers willen een dergelijke downtime ervaren en/of gebruiken zeer oude applicaties/software die hoogstwaarschijnlijk niet meer zullen werken op een (veel) nieuwere omgeving. Hierdoor kunnen wij niet een volledige node uitmigreren. Het is alle resellers tegelijk of niets helaas. Wij kunnen resellers niet verplichten om automatisch te migreren.

Nieuwe reseller pakketten (Koper, Brons, Zilver, Goud, Platinum en Titanium)

Wellicht heeft u het gezien op onze website, maar wij hebben ook nieuwe reseller pakketten beschikbaar. Deze bieden veel meer functionaliteit. Zie voor de uitgebreide informatie het volgende Kennisbank artikel op Helpburo: https://www.helpburo.eu/Knowledgebase/Article/View/nieuwe-plesk-reseller-pakketten. Hier staat een zeer uitgebreide uitleg van alle nieuwe extra’s.

Indien u hiervan gebruik wenst te maken, dan kan dit natuurlijk ook. Geef dan aan welk (nieuw) reseller pakket u wenst en of u gebruik wenst te maken van de “Super performance”-optie. Indien u meerdere reseller pakketten heeft, dan kan u deze ook om laten zetten naar één nieuw reseller pakket, dus samenvoegen. Op die manier heeft u dan geen dubbele kosten meer inzake meerdere reseller pakketten. Wel dient u rekening te houden met het feit dat de nameservers veranderen, zie ook de uitleg bij “Handmatige migratie naar een nieuwe reseller node”.

De (tech) kosten voor de migratie naar een nieuw reseller pakket zijn 70.00 Euro. Indien u meerdere reseller pakketten heeft en u deze wenst te laten samenvoegen tot één nieuw reseller pakket, dan wordt er een toeslag berekend van 50.00 Euro per reseller pakket. Dit inzake de extra handelingen die moeten verricht worden inzake de migratie zelf van het reseller pakketten, maar daarnaast ook het samenvoegen van alle reseller pakketten.

Tot slot; wij krijgen vaak het verzoek of men niet kan migreren naar een DirectAdmin reseller pakket, omdat deze iets goedkoper zijn (reden hiervoor zijn de licentie prijzen; deze liggen een stuk lager als bij Plesk). Dat is helaas niet mogelijk, daar hiervoor geen tool/programma voor beschikbaar is en handmatig alles overzetten is ook geen optie, daar DirectAdmin met andere diensten en programmatuur werkt als Plesk en dit dus problemen zou opleveren. Het bovenstaande kennisbank artikel is onder voorbehoud van (typ)fouten en actuele wijzigingen m.b.t. server programmatuur en/of software aanpassingen.

De oude reseller pakketten, die medio 2016 geïntroduceerd waren, zijn volledig komen te vervallen. Deze oude reseller pakketten boden niet de functionaliteit die men mocht verwachten van een dergelijk reseller pakket. Derhalve zijn alle reseller pakketten, ook prijstechnisch (de oude reseller pakketten stonden veel te goedkoop geprijsd online door een fout op de website), aangepast naar hedendaagse maatstaven.

Zo beschikken de nieuwe reseller pakketten over veel meer functionaliteit en een algehele betere performance. Daarnaast bieden de nieuwe reseller pakketten ook ondersteuning voor PHP 8.x (en hoger) en zijn daarmee ook "future proof" voor de komende jaren. Ook beschikken de nieuwe reseller pakketten over IPv6-adressen (naast de reguliere IPv4-adressen) en krijgt u de beschikking over de volgende diensten bij uw (nieuwe) reseller pakket:

• Backupmaster (inclusief 3x gratis restore)
  • Dit is onze eigen back-up oplossing, die wij nu kosteloos aanbieden voor de nieuwe reseller pakketten

• Wordpress Toolkit (alleen bij Plesk reseller pakketten)
  • Gemakelijk uw Wordpress websites updaten, beveiligen en klonen.

• Joomla Toolkit (alleen bij Plesk reseller pakketten)
  • Gemakkelijk uw Joomla websites updaten, beveiligen en klonen.

• OPcache PHP versneller
  • Verbeter de PHP performance van uw websites via caching

• Meer diversiteit inzake PHP-versies
  • Keuze uit PHP 7.x en PHP 8.x versies
  • Fall-back naar PHP 5.6 (alleen bij Plesk reseller pakketten)

• Fully managed updates
  • Wij zorgen voor updates inzake Plesk/DirectAdmin, alsook het besturingssysteem

• Morderne TLS en Cipher reeksen
  • Steeds meer email programma's en webbrowsers stoppen met oudere TLS/Cipher versies

• ImunifyAV+ scanner
  • Professionele malware scanner voor uw websites; hiermee houdt u uw websites schoon

• Evolution skin (alleen bij DirectAdmin)
  • Zeer gebruiksvriendelijke en moderne interface

• Redis caching
  • Versnelt onder andere Wordpress en overige CMS

• Varnish cache (alleen bij "Super Performance"-optie)
  • Met Varnish cache laadt iedere (PHP) website tot wel 200% sneller

• Geen over-selling op reseller nodes
  • Altijd een goede performance op een reseller node, daar wij deze maximaal 60% "vullen" met accounts

En er zijn nog veel meer andere voordelen inzake de nieuwe reseller pakketten. Kijk op onze website voor meer informatie.

De oude reseller pakketten zijn volledig komen te vervallen eind 2020, daar deze prijstechnisch niet te handhaven waren. Indien u een ouder reseller pakket heeft, dan kan u hier gebruik van blijven maken, maar verdere upgrades en/of uitbreidingen zijn helaas niet mogelijk. Ook is het niet mogelijk op deze oudere reseller pakketten hogere PHP-versies te kiezen (zoals PHP 8.x en toekomstige nieuwe versies). Indien u niet wenst te migreren naar een nieuwer model reseller pakket (in verband met te weinig resources beschikbaar of dergelijke), dan kan u altijd uw oude reseller pakket opzeggen conform de voorwaarden. In dat geval zal er géén restitutie plaats vinden. Hou hier rekening mee. Uiteraard kan u wel gewoon gebruik blijven maken van uw huidige (oude) reseller pakket indien u hier nog voldoende resources voor heeft of geen hogere PHP-versies wenst. Hou er wel rekening mee dat (Plesk/DirectAdmin) support op deze oudere reseller pakketten beperkt is.

Indien u gebruik wenst te maken van deze nieuwe reseller pakketten, maak dan een support ticket aan. Dan kan ons team kijken wat de mogelijkheden zijn en u hierover informeren. Over het algemeen is het relatief éénvoudig om bestaande Plesk reseller pakketten over te migreren. Bij de DirectAdmin reseller pakketten is dit een stuk lastiger c.q. tijdrovender. Hou hiermee rekening aub.

Kanttekening; het is niet mogelijk om te migreren van Plesk naar een DirectAdmin reseller pakket (of andersom). Dit heeft te maken met de onderlinge verschillen qua configuratie van de beide interfaces. Indien u toch wenst te overstappen van Plesk naar DirectAdmin (of andersom), dan zal u zelf alles handmatig over moeten zetten. Wij kunnen daarin niet helpen. Wel kunnen wij dan enige coulance toepassen door u één maand kosteloos de tijd te geven om de handmatige migratie zelf te realiseren.

Voor Plesk zijn er heel veel extensies (ook wel plugins genoemd) beschikbaar. Deze bieden extra functies inzake Plesk zelf of voegen compleet nieuwe functies toe aan uw Plesk omgeving. Ook zijn er diverse plugins die de veiligheid van de Plesk server (en onderliggende webhostingaccounts) nog veiliger maken.

Wanneer u een Plesk extensie bij ons aanschaft, dan heeft u hier ook ondersteuning op. Indien u een Plesk extensie zelf aanschaft; via Plesk of bij de ontwikkelaar zelf, dan kunnen wij hierop geen support leveren. Het is voor ons onmogelijk om ondersteuning te bieden op een Plesk extensie die u zelf elders heeft aangeschaft. In dat geval zal u zelf contact moeten opnemen met de ontwikkelaar en/of Plesk. Indien u toch wenst dat wij support leveren op een Plesk extensie die niet via ons is aangeschaft, dan zullen wij genoodzaakt zijn om tech kosten in rekening te brengen. Het is voor ons onbegonnen werk om (gratis) technische support en/of ondersteuning hierop te leveren. Zie ook hier.

Hou er ook rekening mee dat support langer kan duren, indien u bij Plesk een support verzoek indient. Wij zijn al jaar en dag "Platinum Partner" bij Plesk, hetgéén zich vertaald in "priority" support. Ook zal u Plesk toegang moeten verlenen tot uw server (interface en/of SSH toegang). Wij adviseren u hier goed rekening mee te houden. Daarnaast adviseren wij om geen (directe) toegang tot uw Plesk server te verlenen aan ontwikkelaars van extensies. Neem bij twijfel altijd eerst contact met ons op via een support ticket.

Heeft u een Plesk extensie via ons aangeschaft, dan heeft u vanzelfsprekend ondersteuning via ons op de desbetreffende plugin. Uiteraard geldt hetzelfde voor de standaard extensies die door ons geinstalleerd zijn tijdens de oplevering van uw Plesk server. Hieronder een aantal voorbeelden van (betaalde) en populaire Plesk extensies die er beschikbaar zijn:

• Installatron
• Softaculous
• ImunifyAV+
• Imunify360
• Warden Anti-spam and Virus Protection
• Joomla Toolkit
• Speed Kit
• Kaspersky Anti-Virus for Servers
• Juggernaut Security and Firewall
• Google PageSpeed Insights
• Acronis Backup

Dit is slechts een kleine greep van de vele verschillende Plesk extensies.

Wanneer u interesse heeft in een dergelijke Plesk extensie en u wenst via ons support, dan adviseren wij om contact op te nemen met ons. En uiteraard kan u ook zelf een Plesk extensie aanschaffen via Plesk of via een derde partij, maar dan moet u wel rekening houden dat wij hierop geen (gratis) ondersteuning kunnen leveren. Hou hier altijd rekening mee. Zie ook hier.

Tevens zien wij steeds meer Plesk servers beveiligd worden met Google Authenticator. Vanzelfsprekend is een extra laag beveiliging op uw server een goede zaak, echter vertraagd dit ook eventuele support verzoeken. Indien u een support verzoek bij ons indient, zet dan altijd eerst Google Authenticator uit op uw server. U kan deze nadien weer probleemloos inschakelen uiteraard.

Nieuwe reseller pakketten (Koper, Brons, Zilver, Goud, Platinum en Titanium)

Sinds een klein aantal maanden zijn alle reseller pakketten op de schop gegaan. De oude reseller pakketten waren veel te laag geprijsd en derhalve niet rendabel om aan te houden. Zeker niet met de support die wij hierop leveren. Derhalve hebben wij doen besluiten om te stoppen met de oude reseller pakketten en verder te gaan met een nieuwere variant (reseller pakketten 2.0). Deze nieuwe reseller pakketten zijn nog altijd zeer betaalbaar (zeker voor wat men krijgt) en bieden talloze gratis extra’s. Zie hieronder wat men tegenwoordig bij alle Plesk reseller pakketten krijgt:

• Gratis Backupmaster: inclusief 3 keer per jaar gratis restore (van websites/databases/email)
• Gratis Redis Caching: betrouwbare caching welke perfect werkt voor Wordpress en andere CMS
• Gratis outbound mail filtering: voorkomt blacklisting van de uitgaande mailservers
• Gratis Plesk Joomla Toolkit: beheer, beveilig en kloon complete Joomla websites
• Gratis Plesk Wordpress Toolkit: de bekende WP Toolkit van Plesk (was reeds beschikbaar)
• Gratis ImunifyAV+ (met cleaner): detecteert malware op uw websites en schoont dit (automatisch) op

Zoals u zelf kunt constateren bieden onze nieuwe Plesk reseller pakketten echt veel meer functionaliteit als de oude Plesk reseller pakketten. Dit alles voor een betere en betrouwbaardere all-round performance van uw reseller pakket. Daarnaast komt dit alles ook ten goede van de veiligheid van uw reseller pakket, alsook van uw klanten. Dus resumé; de nieuwe reseller pakketten bieden veel meer functionaliteit, veiligheid en betere performance.

Super performance optie

Bij de nieuwe Plesk reseller pakketten is er nu ook een "Super performancen"-optie. Hiermee wordt het (bestelde) nieuwe reseller pakket op de snelst mogelijke reseller node geplaatst (bestaande uit een geavanceerde RAID 50 cloudomgeving op basis van meerdere Enterprise SSD’s) wat de performance drastisch ten goede komt. Daarnaast kan u ook kosteloos gebruik maken Varnish Cache. Met dit laatste kunt u o.a. Wordpress websites tot wel 300% sneller geladen worden. En dit is absoluut geen valse belofte. De "Super Performance" is het maximale haalbare qua performance inzake onze nieuwe Plesk reseller pakketten.

Overstappen / migreren

Indien u nog een ouder model reseller pakket heeft en u wenst te migreren naar één van onze nieuwe Plesk reseller pakketten, dan kunt u het beste een support ticket hiervoor aanmaken op Helpburo. U dient wel rekening te houden met het feit dat u sowieso te maken krijgt met nieuwe nameservers. Daarnaast worden er wel tech kosten in rekening gebracht. Het is ook mogelijk, wanneer u meerdere reseller pakketten bij ons heeft, om deze samen te voegen tot één nieuw reseller pakket. Aan dit laatste zitten wel extra kosten verbonden inzake de ingewikkelde migratie en samenvoeging van twee (of zelfs meerdere reseller pakketten).

Hoe dan ook; wilt u meer informatie of heeft u nog vragen over onze nieuwe Plesk reseller pakketten, maak dan een support ticket aan. Vermeld daarbij wel uw huidige reseller pakket (of pakketten) gegevens.

Lees het onderstaande artikel goed door. Bij verkeerd gebruik van HSTS kan u website langere tijd offline zijn of niet goed functioneren (zie ook laatste alinea).

Wat is HSTS?
HTTP Strict Transport Security (HSTS) is een beveiligingsmechanisme nodig om HTTPS-websites te beschermen tegen zogenaamde downgrade-aanvallen.
Het vereenvoudigt ook de bescherming tegen cookie hijacking.

HSTS kunt u zelf realiseren. Hier vindt u de pagina met informatie en tests: https://securityheaders.com
Onder het kopje "Missing Headers" staan de nodige opties weergegeven. U kan op elke term klikken voor meer uitleg.


Plesk Onyx
Deze dient u of uw websitebouwer toe te voegen onder "Apache & nginx Settings" binnen uw Plesk controle paneel.
Vervolgens kunt u deze zelf plaatsen onder "Additional headers"

Zie de Plesk website voor informatie hierover: https://support.plesk.com/hc/en-us/articles/115002234393-How-to-enable-HTTP-Strict-Transport-Security-HSTS-for-a-domain-on-the-Plesk-server-

DirectAdmin
In DirectAdmin kunt u simpel HSTS activeren door het één en ander in de .htaccess te plaatsen in de hoofdmap van uw website (public_html).
Bijvoorbeeld:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" env=HTTPS

Website problemen/offline
Bij verkeerd gebruik van HSTS kan uw website langere tijd offline raken. Dit heeft te maken met de ingestelde duur (expiry). Dit kan verregaande gevolgen hebben voor uw bezoekers en/of klanten.
Het is een zeer mooi protocol, maar kan ik dagelijks gebruik nog wel tot problemen leiden. Bij eventuele problemen is het ook zeer ingewikkeld om hier achter te komen, daar dit zaken secundaire zaken zijn die moeilijk te traceren zijn.

Je kan de opgeslagen HSTS instellingen verwijderen uit je webbrowser, zie o.a. hier en hier. Hier is een zoekopdracht in Google wanneer de vorige linken niet meer werken c.q. actief zijn: Google zoekopdracht.
Hou er wel rekening mee dat hiermee alleen het probleem voor u en de door u gebruikte webbrowser oplost. Uw bezoekers, die eerder naar uw website zijn geweest kunnen hier nog wel problemen mee ondervinden. Zie ook hier.

Standaard leveren wij nieuwe Plesk servers op met de Web Application Firewall (ModSecurity). Indien uw server hierover nog niet beschikt, dan volgt hier een handleiding hoe u dit kunt installeren en instellen.

Web Application Firewall (ModSecurity) biedt een zeer goede extra laag van bescherming tegen ongewenste bezoekers en mogelijk misbruik van uw server. Ook biedt de Web Application Firewall (ModSecurity) bescherming tegen CVE (Common Vulnerabilities and Exposures). Hiermee worden bijvoorbeeld installaties van Wordpress, Joomla en overige CMS extra goed beschermd.

Indien Web Application Firewall (ModSecurity) nog niet geinstalleerd staat op je Plesk server, dan kun je dit gemakkelijk installeren via de CLI (Command Line Interface), dus via SSH of via Plesk Updates.

Installatie van Web Application Firewall (ModSecurity)

Als eerste de methode via CLI (dus via SSH):

• Log in via SSH op uw Plesk server
• Geef het volgende commando in: plesk installer --select-release-current --install-component=modsecurity

De tweede methode is via de Plesk interface:

• Ga naar Tools & Settings
• Klik op "Updates" (in de "Plesk"-rubriek)
• Selecteer: Add/Remove components
• Klik op plus symbool bij "Web hosting"
• Klik op "ModSecurity"
• Ga nu verder met installeren

Configuratie van Web Application Firewall (ModSecurity)

Wanneer Web Application Firewall (ModSecurity) staat geinstalleerd, dan kun je verder met de onderstaande stappen.
Activeer en configureer Web Application Firewall (ModSecurity) via:

• Ga naar "Tools & Settings"
• Klik op "Web Application Firewall (ModSecurity)"
• Zet de optie "Web application firewall mode" op "On"
• Wijzig geen instellingen en klik op "OK"
• Klik wederom op "Web Application Firewall (ModSecurity)"
• Klik ditmaal op het 2e tabblad met de naam "Settings"
• Ga omlaag en vul bij "Custom directives" het volgende in:

# COUNTRY BLOCKING
SecGeoLookupDb /usr/share/GeoIP/GeoIP.dat
SecRule REMOTE_ADDR "@geoLookup" "phase:1,chain,id:10,drop,log,msg:'Blocking BAD IP Address'"
SecRule GEO:COUNTRY_CODE "@rx ^(UA|LT|EG|RO|BG|TR|PK|MY|RU|CN|SG)$"
SecRule REQUEST_HEADERS:User-Agent "AhrefsBot" "id:'300002',phase:2,t:none,log,deny,msg:'Blocking Ahrefs bot'"
SecRule REQUEST_HEADERS:User-Agent "YandexBot" "id:'300003',phase:2,t:none,log,deny,msg:'Blocking Yandex bot'"
SecRule REQUEST_HEADERS:User-Agent "MJ12bot" "id:'300004',phase:2,t:none,log,deny,msg:'Blocking MJ12bot'"

# RATE-LIMIT GOOGLE BOT
SecRule REQUEST_HEADERS:User-Agent "@contains Googlebot" "phase:1,id:300041,nolog,pass,initcol:RESOURCE=%{request_headers.host}_googlebot,deprecatevar:RESOURCE.count=15/1,expirevar:RESOURCE.count=30"
SecRule REQUEST_HEADERS:User-Agent "@contains Googlebot" "phase:1,nolog,pass,id:300042,setvar:RESOURCE.count=+1"
SecRule REQUEST_HEADERS:User-Agent "@contains Googlebot" "phase:1,nolog,deny,status:503,id:300043,chain,setenv:RATELIMITED"
SecRule RESOURCE:COUNT "@gt 30" ""
Header always set Retry-After "10" env=RATELIMITED
ErrorDocument 429 "Too Many Requests"

# RATE-LIMIT FACEBOOK BOT
SecRule REQUEST_HEADERS:User-Agent "@contains FacebookBot" "phase:1,id:300051,nolog,pass,initcol:RESOURCE=%{request_headers.host}_googlebot,deprecatevar:RESOURCE.count=15/1,expirevar:RESOURCE.count=30"
SecRule REQUEST_HEADERS:User-Agent "@contains FacebookBot" "phase:1,nolog,pass,id:300052,setvar:RESOURCE.count=+1"
SecRule REQUEST_HEADERS:User-Agent "@contains FacebookBot" "phase:1,nolog,deny,status:503,id:300053,chain,setenv:RATELIMITED"
SecRule RESOURCE:COUNT "@gt 30" ""
Header always set Retry-After "10" env=RATELIMITED
ErrorDocument 429 "Too Many Requests"

# RATE-LIMIT FACEBOOK ALTERNATIVE
SecRule REMOTE_ADDR "@ipMatch 31.13.115.0/27,31.13.103.0/27,173.252.79.0/27" \
    "id:400029,phase:2,nolog,pass,setvar:global.ratelimit_Facebookbot=+1,expirevar:global.ratelimit_Facebookbot=3"
SecRule GLOBAL:RATELIMIT_FACEBOOKBOT "@gt 3" \
    "chain,id:4000030,phase:2,pause:300,deny,status:429,setenv:RATELIMITED,log,msg:'RATELIMITED BOT'"
    SecRule REMOTE_ADDR "@ipMatch 31.13.115.0/27"
Header always set Retry-After "10" env=RATELIMITED
ErrorDocument 429 "Too Many Requests"

Hiermee worden risicovolle landen geblokkeerd en Google en Facebook bots (die een overload kunnen veroorzaken op uw server) gelimiteerd.

• Klik tot slot op "OK"

Activatie van Web Application Firewall (ModSecurity)

Nu staat Web Application Firewall (ModSecurity) op uw server geactiveerd, maar zal deze nog niks doen inzake blokkeren of bots limiteren.
Het enige wat u nu nog dient te doen is "IP Address Banning (Fail2Ban)" hiervoor activeren. Dit doe je als volgt:

• Ga (wederom naar) "Tools & Settings"
• Klik op "IP Address Banning (Fail2Ban)"
• Klik op het tabblad "Jails"
• Activeer nu "plesk-modsecurity"-jail
  • Vink "plesk-modsecurity" aan
  • Klik bovenaan op "Switch On"
• Vanaf nu wordt uw Plesk server volledig beschermd via Web Application Firewall (ModSecurity)

Periodiek updaten van GeoIP.dat (optionele stap)

De Web Application Firewall (ModSecurity) maakt gebruik van het bestand GeoIP.dat. De standaard aangeleverde versie wordt nauwelijks onderhouden en/of voorzien van updates. Aangezien IP-adressen steeds vaker overgedragen worden aan nieuwe eigenaren is het dus verstandig om dit bestand regelmatig te updaten. Dit is vrij éénvoudig te doen, u dient alleen SSH toegang te hebben tot uw server.

Volg de onderstaande stappen om GeoIP.dat (periodiek) te updaten:

• Log in op SSH van uw Plesk server
• Geef nu de onderstaande commando's in:
  • cd /opt
  • wget https://mailfud.org/geoip-legacy/geoip_update.sh
  • chmod +x geoip_update.sh
  • ./geoip_update.sh
• Nu is het bestand GeoIP.dat voorzien van de nieuwste IP-adressen en wijzigingen

Als laaste gaan wij nog een zogenaamde cron-job instellen, zodat deze periodiek voorzien wordt van updates.

• Ga weer terug naar de Plesk interface
• Klik op "Tools & Settings"
• Klik vervolgens op "Scheduled Tasks (Cron jobs)" (onder Tools & Resources)
• Klik nu op "Add Task" geef het volgende aan:
  
  • Task type: Run a command
  • Command: /opt/geoip_update.sh
  • Run: Monthly met willekeurige dag en tijd (*)
  • System user: root
  • Description: GeoIP update
  • Notify: Do not notify
• Klik nu op "OK"

(*) kies een willekeurige dag en tijd, dit voorkomt dat er teveel servers de GeoIP-bestanden ophalen en op de zwarte lijst komen.

Nu wordt maandelijks, vaker is niet nodig (en wordt ook afgeraden), de IP-database (GeoIP.dat) vernieuwd met nieuwe IP-adressen en wijzigen. Meer dan dit hoeft u niet te doen.

Deze handleiding is met name bedoelt voor "oudere" opgezette Plesk servers die nog geen gebruik maken van Web Application Firewall (ModSecurity). Indien het niet mogelijk is om Web Application Firewall (ModSecurity) te installeren, dan adviseren wij u een support ticket aan te maken. Wellicht draait u nog op een oude omgeving en dient uw server gemigreerd te worden.

Wanneer u één van de onderstaande producten heeft, dan kan u gebruik maken van het supersnelle Varnish Cache op uw Plesk omgeving:

• Plesk server (VPS/DPS) met Varnish Cache (betaalde optie)
• Plesk reseller pakket (alleen bij "Super performance"-optie)

Wanneer u géén van de bovenstaande producten heeft, dan heeft u géén Varnish Cache ter beschikking. Wanneer u zelf (of derden voor u) Varnish Cache heeft geinstalleerd op uw server, dan kunnen wij hierop geen support leveren. Wij leveren alleen support op Varnish Cache installaties die onze technici hebben geinstalleerd op uw server (of reseller pakket).

Onze geavanceerde Varnish Cache configuratie (en reeds geoptimaliseerd voor de beste performance) is direct klaar voor gebruik. U dient alleen de onderstaande stappen op te volgen en vervolgens zal uw website vele malen sneller geladen worden dan voorheen het geval is. Dit is niet alleen merkbaar op websites die via PHP aangestuurd worden, maar biedt ook een uitstekende performance voor Wordpress websites. Standaard hebben wij configuratie van Varnish Cache zo geconfigureerd dat deze de beste performance levert met name voor Wordpress websites.

Meteen een belangrijke opmerking; Varnish Cache kan alleen het hoofd IP-adres gebruiken van de server (normaal gesproken het IP-adres gekoppeld aan ns1.nameserver.nl). Dit is standaard een "shared" (gedeeld) IP-adres die bruikbaar is voor alle websites. Als u van een ander shared/dedicated IP-adres gebruik maakt voor een website, dan zal deze geen gebruik maken van Varinsh Cache. Dus de vuistregel is dat altijd het IP-adres gekoppeld aan de 1e nameserver (dus ns1.nameserver.nl) wordt gebruikt t.b.v. Varnish Cache. Indien u meerdere Varnish Cache installaties wenst, dan zal dit tegen extra kosten besteld kunnen worden, al wordt dit niet aanbevolen.

Stap 1 - Opties webhostingaccount uitzetten
U dient een aantal opties aan te passen, want anders zal Varnish Cache niet correct functioneren en een foutmelding geven. Hieronder worden de opties aangegeven.

• Permanent SEO-safe 301 redirect from HTTP to HTTPS: uitzetten (dus niet activeren)
  
  • Deze optie is terug te vinden onder "Domains" > "Domeinnaam in kwestie" > "Hosting & DNS" > "Hosting Settings"

• Redirect from http to https: uitzetten (dus niet activeren)
  
  • Deze optie is terug te vinden onder "Domains" > "Domeinnaam in kwestie" > "SSL/TLS Certificates"

• SSL/TLS support: aanzetten (dus wel activeren)
  
  • Deze optie is terug te vinden onder "Domains" > "Domeinnaam in kwestie" > "Hosting & DNS" > "Hosting Settings"

Zie ook de onderstaande screenshot voor een visuele weergave.

Wanneer u deze opties niet correct uit of aan zet, dan zal de website niet oproepbaar zijn en een foutmelding geven. Dus controleer altijd of u de juiste instellingen hanteert; hiermee voorkomt u 99% van alle problemen.

Stap 2 - HTTP-aanpassing toevoegen
Om ervoor zorg te dragen dat de website toch, via Varnish Cache, beveiligd op te roepen is SSL-verbinding (oftewel HTTPS), dient men de onderstaande aanpassing te maken.
Ga naar "Domains" > "Domeinnaam in kwestie" > "Hosting & DNS" > "Apache & nginx" en ga nu naar het invulveld met "Additional directives for HTTP". Plak hier het volgende in:

SetEnvIf X-Forwarded-Proto "https" HTTPS=on
Header append Vary: X-Forwarded-Proto

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTPS} !=on
RewriteCond %{HTTP:X-Forwarded-Proto} !https [NC]
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>

Vul het bovenstaande alleen in bij "Additional directives for HTTP" en dus niet bij "Additional directives for HTTPS", anders zal de website eindeloos blijven laden en fouten geven.

Stap 3 - Docker Proxy Rule aanmaken
De laatste stap is een regel toevoegen aan Docker, zodat Varnish daadwerkelijk gebruikt wordt door uw website.
Hiervoor gaat u naar de domeinnaam in kwestie. En klikt u vervolgens op "Docker Proxy Rules". Klik vervolgens op de knop "Add Rule". De standaard instellingen zijn voldoende, dus u kan vervolgens direct op "OK" klikken.
Wanneer u uw website in een submap heeft staan (bijvoorbeeld in een map "wordpress", "wp", "website" of "watdanook", dan zal u een tweede "Docker Proxy Rule" moeten aanmapen voor de map. Vul in dat geval in "URL"-veld de mapnaam in met een "/" (slash) op het eind, dus bijvoorbeeld: wordpress/ (vergeet niet de slash op het einde).

Dit was de laatste stap. Wanneer u de bovenste drie stappen correct heeft toegepast, dan zal de website via Varnish Cache geladen worden.



Aanvullende informatie
Zoals u hierboven heeft kunnen lezen, werkt Varnish Cache alleen via het hoofd IP-adres van de 1e nameserver (ns1.nameserver.nl). Op andere IP-adressen staat Varnish Cache niet actief, deze kan u eventueel gebruiken voor reguliere websites of non-Wordpress websites (indien u dit wenst).

Gebruik bij Wordpress websites geen andere en/of externe caching plugins of modules! Het is al voldoende om alleen Varnish Cache te gebruiken. Hiervoor heeft u geen andere plugins of modules voor nodig. Indien u toch andere caching methodes gebruikt tesamen met Varnish Cache, dan kan dit tot problemen leiden met uw website. Hou hier rekening mee. Enkele voorbeelden van andere caching plugins of modules zijn W3 Total Cache, WP Super Cache, WP Rocket, Speed Cache en dergelijke. Gebruik deze dus niet in combinatie met Varnish Cache. Vuistregel luidt dan ook; gebruikt u Varnish Cache, gebruik dan geen andere cache of caching technieken.

Maak geen aanpassingen in de door ons aangeleverde configuratie van Varnish en/of Docker. Indien u dit zelf aanpast waardoor Varnish Cache niet meer correct werkt (door uw eigen toedoen), dan zijn wij genoodzaakt om herinstallatie/tech kosten te berekenen voor Varnish Cache. De kosten hiervoor zijn 60.00 Euro.

Wanneer u toch problemen ondervindt, zoals "Too many redirects", "Error 503 Service Unavailable", "Error 503 Backend fetch failed" en dergelijke zijn doorgaans 99% te wijten aan verkeerde instellingen. Dus controleer nogmaals de genoemde instellingen bij stap 1 en stap 2. Een vinkje te weinig / te veel kan er al voor zorg dragen dat Varnish Cache niet correct werkt en uw website niet wordt weergegeven.

Indien u zeker weet dat u alles correct heeft gezet, dan kunt u een support ticket aanmaken.



Deze handleiding is niet bedoelt voor reguliere Plesk hosting pakketten op dit moment en is alleen van toepassing op Plesk servers waarvoor de optie Varnish Cache is besteld en/of Plesk reseller pakketten met de "Super performance"-optie.

Vooropgesteld; veiligheid is een goede zaak inzake servers, echter is Google Authenticator echt niet per se noodzakelijk.

Standaard leveren wij onze servers (VPS/DPS) op basis van Plesk of DirectAdmin standaard al op met de hoogste graag van bescherming. Discutabele poorten worden afgesloten. Firewalls zijn voorgeconfigureerd voor maximale veiligheid, standaard SSH poorten zijn gewijzigd of geven alleen toegang via vooraf aangegeven IP-adressen e.d. Daarnaast worden servers opgeleverd met zeer ingewikkelde (lees: sterke) wachtwoorden. Deze kan u zelf ook uiteraard periodiek aanpassen (ook aanbevolen).

Vanwege de bovenstaande redenen is het niet noodzakelijk om Google Authenticator op uw server te installeren. Indien u toch Google Authenticator wenst te gebruiken, dan dient u deze zelf uit te schakelen bij (iedere) support aanvraag die u bij ons doet. Indien u Google Authenticator niet uitzet, dan kan er een langere periode overheen gaan alvorens uw support aanvraag in behandeling en/of verwerkt kan worden. Sowieso behouden wij het recht, indien wij toegang noodzakelijk achten op een server (om welke reden dan ook) om zelf Google Authenticator te de-activeren en/of te verwijderen. Uiteraard is het laatste alleen in uitzonderlijke gevallen.

Wanneer wij Google Authenticator moeten uitschakelen voor toegang tot uw server (al dan niet bij problemen), dan her-activeren wij Google Authenticator achteraf niet. Dit zal u dan zelf weer moeten doen.

Google Authenticator is niet per se nodig, gezien de strikte veiligheids maatregelen die wij treffen voor iedere server of dit nu een VPS of een DPS is met Plesk of DirectAdmin. Veiligheid staat bij ons altijd hoog in het vaandel en dit ook wel te merken aan onze opgeleverde servers. Zo zijn alle servers (Plesk/DirectAdmin) die door ons opgeleverd zijn, standaard goed beschermd en beveiligd. (*)

Resumé; u hoeft niet Google Authenticator op uw serveromgeving (Plesk of DirectAdmin) te plaatsen. Indien u dit wel doet en wij hebben (al dan niet naar aanleiding van een support ticket) toegang nodig tot uw server, dan behouden wij het recht om Google Authenticator zelf uit te zetten. In dit geval zal u zelf deze opniew moeten activeren uiteraard.

(*) enige uitzondering hierop is wanneer de server eigenaar / beheerder zelf gaat sleutelen aan allerlei instellingen inzake de veiligheid. In dat geval distantiëren wij ons hiervan, daar de servers die wij opleveren reeds meer dan voldoende beveiligd en afgeschermd zijn en derhalve het niet noodzakelijk is om zelf nog achteraf zaken aan te passen.

Wij hebben diverse handleidingen voor Plesk online staan. Het is raadzaam om deze altijd te raadplegen (zeker als reseller of server eigenaar).
Ook zijn er gewone Plesk handleidingen beschikbaar voor eindgebruikers oftewel voor Plesk hosting klanten.

• Plesk Obsidian - Handleiding voor gebruikers [NL]
• Plesk Obsidian - Quick Start Guide [EN]
• Plesk Obsidian - Reseller Guide [EN]
• Plesk Obsidian - Administrator Guide [EN]

De eerste handleiding is met name geschikt voor Plesk hosting klanten om wegwijs te worden binnen de Plesk interface. Deze handleiding is dan ook speciaal in het Nederlands. Alle overige handleidingen zijn alleen in het Engels verkrijgbaar en bevatten handige informatie voor o.a. Plesk reseller en Plesk server eigenaren (VPS/DPS).

Op (nieuwere) Plesk omgevingen geeft Spamassassin de laatse tijd "foutmeldingen", zoals: SpamAssassin: Unknown error code 3 from sa-update
Met vervolgens daarin het volgende vermeld: channel: no 'mirrors.sought.rules.yerp.org' record found, channel failed

Deze melding komt doordat een bepaalde repo (= repository) niet meer beschikbaar is. Dit gebeurt wel vaker en over het algemeen wordt dit na enige tijd vanzelf opgelost.
Mocht u deze melding vervelend vinden en u wenst niet te wachten totdat dit vanzelf opgelost wordt, dan kan u het volgende zelf doen:

1. Log in op SSH
2. Open het bestand: /etc/mail/spamassassin/channel.d/sought.conf
3. En zet een hashtag voor de volgende regels:

# http://wiki.apache.org/spamassassin/SoughtRules
# CHANNELURL=sought.rules.yerp.org
# KEYID=6C6191E3
# Ignore everything below.

Dat zou voldoende moeten zijn.

Maar goed; dit zal automatisch opgelost moeten worden en kan in feite met iedere willekeurige repo gebeuren.
Wanneer u niet wilt wachten en u dit zelf niet kan oplossen, dan kunnen wij dit ook voor u aanpassen tegen het tech tarief.

Tip! Mocht u onze anti-spam oplossing (Spamprotector) gebruiken voor uw domeinnamen, dan is het verstandiger om Spamassassin helemaal uit te zetten. Op die manier kan uw server (VPS/DPS) meer resources gebruiken voor andere services en diensten. Hierdoor kan de algehele server performance weer net iets beter zijn, want Spamassassin staat erom bekend dat dit aardig wat resources kan gebruiken.

Customizing httpd.include for Domains

In Parallels Plesk Panel each domain has virtual hosts configuration stored in a separate file:

<VIRTUAL_HOSTS_D>/<domain-name>/conf/httpd.include

When you need to use some specific configurations for a domain or a subdomain, it's not a good idea to include them directly in httpd.include file. This file is overwritten each time the virtual host configuration is changed, thus any manual alterations made to the file are discarded.

To use custom directives or redefine those inserted by Parallels Plesk Panel, do the following:

1. Create the files vhost.conf and/or vhost_ssl.conf with necessary directives in the <VIRTUAL_HOSTS_D>/<domain-name>/conf/ directory.
   If any (or both) of these files exist by the time the main configuration file is generated, Parallels Plesk Panel inserts the appropriate directive:
   Include <VIRTUAL_HOSTS_D>/<domain-name>/conf/vhost.conf
   or
   Include <VIRTUAL_HOSTS_D>/<domain-name>/conf/vhost_ssl.conf
   into the HTTP and/or HTTPS virtual host context respectively.
   For security reasons, only root can create the vhost.conf and vhost_ssl.conf files.
2. For the changes to take effect, run the following:

   # /usr/local/psa/admin/sbin/websrvmng --reconfigure-vhost --vhost-name=<domain_name>

   For the changes to be implemented for all domains, run the following:

   # /usr/local/psa/admin/bin/websrvmng -a

Wanneer een Plesk server geupdate wordt naar de nieuwste Plesk versie, dus (op het moment van schrijven) Plesk Onyx, dan kan het wezen dat uw website "opeens" vervangen wordt door een (Plesk) index pagina.
Vooropgesteld; uw website is niet weg of verwijderd!

Dit heeft puur te maken dat er twee index-bestanden in de map /httpdocs/ staan, dus bijvoorbeeld een index.html en een index.php.
Bij oudere Plesk versies werd altijd als eerste index.php aangeroepen. Bij nieuwere Plesk versies is dit juist andersom.

Hierdoor krijgt de index.html voorrang op index.php, waardoor de standaard Plesk pagina wordt weergegeven.
Dit gebeurt alleen wanneer u de oude index.html niet verwijderd heeft.

De oplossing is simpel; gebruik de "File-manager" binnen Plesk of gebruik een FTP-programma en herbenoem index.html naar index.html.old.
Vervolgens opslaan en uw website doet het weer.


Hieronder staan een aantal voorbeelden van standaard index.html pagina's. Als u "opeens" één van deze pagina's aanteeft, dan dient u de hierboven genoemde handeling uit te voeren.

Een aantal klanten krijgen de volgende melding te zien inzake hun website op een Plesk server:

Wordpress notifications are received: Failed to reset cache for the instance #XX: An error has occurred when decoding JSON: Decoding failed: Syntax error

Dit probleem wordt veroorzaakt door een problematische Wordpress plugin of Wordpress thema. Dit kan dus diverse oorzaken hebben:

• Het betreft een custom Wordpress plugin of thema
  • Dus niet een standaard Wordpress plugin of thema
  • Neem contact op met de ontwikkelaar van de plugin/thema

• Het betreft een verouderde Wordpress plugin of thema
  • Waarschijnlijk kan u dit oplossen door deze plugin of thema te updaten
  • Controleer of er updates beschikbaar zijn voor de plugin/thema in kwestie

• Het betreft een Wordpress plugin of thema die niet meer onderhouden/ontwikkeld wordt
  • U zal dan diegene moeten raadplegen die uw website heeft gebouwd
  • Deze zal een vervangende Wordpress plugin/thema moeten zoeken en installeren voor u

Dit is geen server gerelateerd probleem, maar heeft puur en alleen betrekking op uw Wordpress website. In uitzonderlijke gevallen kan het nog een bug betreffen in de Wordpress Toolkit van Plesk. In dit laatste geval, dient u even een paar dagen te wachten totdat Plesk hiervoor een update/bugfix voor uitbrengt. Dit wordt volledig automatisch geregeld door Plesk; m.a.w. wij kunnen dit versnellen en/of bespoedigen.

Onze ervaring leert echter dat dit vaak gewoon te wijten is aan een bepaalde Wordpress plugin of Wordpress thema. Met name custom c.q. zelfgemaakte Wordpress thema's leveren problemen op. Een custom Wordpress thema is natuurlijk mooi en uniek, maar doordat Wordpress telkens geupdate wordt, kan bepaalde (PHP) code in het thema niet meer correct functioneren. Dan krijg je een dergelijke melding zoals hierboven. Zie ook wat Plesk zelf aangeeft over deze foutmelding: https://support.plesk.com/hc/en-us/articles/12377006083735?page=1#comment_18266467676055. Hier wordt duidelijk vermeld dat deze melding veroorzaakt wordt door een niet compatible Wordpress thema of plugin.

Het enige wat u kan doen nu is om alle Wordpress plugins en thema's na te lopen inzake uw Wordpress website en deze te updaten, waar nodig. Maak uiteraard wel op voorhaand een back-up via de Plesk Backup Manager; deze is voor iedereen met een Plesk webhosting pakket gratis te gebruiken en voorkomt een hoop ellende wanneer een update uw Wordpress website breekt.

Wanneer een websitebouwer de website heeft gemaakt c.q. ontwikkeld heeft, dan zal u met deze persoon/bedrijf contact moeten opnemen om het één en ander na te lopen. Wij maken geen websites (ook nooit gedaan) en onderhouden ook géén websites. Wij zijn een hostingprovider, dus wij leveren ruimte op onze servers aan klanten. Wat een klant hierop plaatst is aan hun zelf en met alle mogelijkheden van vandaag de dag, is dit onmogelijk om allemaal seperaat te controleren. Indien u toch wenst dat wij dit doen, dan zal dit tegen het tech tarief gaan en deze begint bij 90.00 Euro. De tech zal dan alle plugins en thema's handmatig moeten controleren, daar wij niet bekend zijn met de werking van de website, de gebruikte plugins en thema's. Het start tarief is inclusief 1 uur werkzaamheden, iedere daaropvolgende 15 minuten kost 20.00 Euro. Hou hier rekening mee.

Ons advies

Wij adviseren u als eerste een paar dagen geduld te hebben, want aangezien de Plesk Wordpress Toolkit zeer regelmatig geupdate wordt, kan het dus ook een bug hierin betreffen. Dit zal dan snel genoeg gemeld worden aan Plesk zelf en dan zal er binnen een aantal werkdagen (3 tot 5 werkdagen) een update of bugfix uitgebracht worden. Dit wordt uiteraard volledig door Plesk zelf geregeld en wij kunnen dit niet bespoedigen...

Indien het probleem nog steeds bestaat na ruim een week, dan adviseren wij u één van de hierboven genoemede stappen op te volgen, want dan ligt het probleem zeer zeker binnen uw Wordpress website. Meestal is hier een Wordpress thema of Wordpress plugin debet aan. Dus wanneer het probleem nog steeds aanwezig is na circa 1 week, dan zou u één van de bovenstaande stappen moeten opvolgen.

Op dit moment circuleert er nieuws inzake een kwetsbaarheid m.b.t. Apache Log4j.

Alle (opgeleverde) servers met Plesk of DirectAdmin maken geen gebruik hiervan en dus vormt deze kwetsbaarheid geen risico.
Dus wanneer u een server heeft met Plesk of DirectAdmin, dan hoeft u zich geen zorgen te maken.

De enige servers die (in theorie) een probleem hier mee kunnen hebben zijn zogenaamde plain servers (LAMP). Dit zijn specifieke servers en worden alleen door klanten besteld met technische Linux kennis.
Dit zijn "kale" servers zonder een interface (zoals Plesk of DirectAdmin) en worden door ons alleen voorzien van Linux, Apache, MySQL en PHP (vandaar de naam LAMP). De klanten die dergelijke servers afnemen zijn zelf verantwoordelijk voor wat men installeert op zijn/haar server. Normaliter maken dergelijke servers ook geen gebruik van Apache Log4j, maar het kan zijn doordat u een bepaalde applicatie heeft geinstalleerd op uw server die deze functie wel gebruikt. In dat geval raden wij u aan om deze kwetsbaarheid te dichten. Wij leveren nagenoeg nauwelijks tot geen support op zogenaamde plain (= LAMP) servers, daar hier ontelbare configuratie mogelijkheden voor zijn.

Voor de goede orde; heeft u een server (of hostingaccount) met een Plesk interface of met een DirectAdmin interface, dan heeft u geen last van de Apache Log4j kwetsbaarheid!

Op dit moment is de meest actuele Plesk versie: Plesk Obsidian 18.x.
Deze versie wordt volledig ondersteund door Plesk en ontvangt updates c.q. uitbreidingen.

De volgende versies worden door Plesk (en ook door ons) aangezien als end-of-life (EOL) versies:

• Plesk Onyx 17.x (EOL sinds april 2021)
• Plesk 12.x (EOL sinds januari 2019)
• Plesk 11.x (EOL sinds december 2016)
• Plesk 10.x (EOL sinds mei 2015)
• Plesk 9.x (EOL sinds juni 2013)
• Plesk 8.x (EOL sinds september 2012)
• Plesk 7.x en lager (EOL sinds januari 2012)

Wanneer u nog draait op een Plesk versie die end-of-life is, dan adviseren wij u om uw omgeving door ons te laten migreren. Immers krijgt u al geruime tijd geen (beveiligings)updates meer voor uw omgeving. Dit kan een enorm veiligheidsrisico inhouden voor u en uw klanten.

Plesk 12.x en Plesk 17.x versies kunnen doorgaans zonder veel problemen gemigreerd worden naar een nieuwere omgeving. Oudere versies kunnen wel (grote) problemen opleveren. Dit heeft te maken met de zeer gedateerde achterliggende diensten en componenten. Vaak draaien dergelijke servers ook nog eens op een sterk verouderd besturingssysteem (CentOS 6.x of zelfs nog CentOS 5.x).

Indien uw Plesk server (VPS/DPS) nog met een oude Plesk versie (Plesk 17.x of lager) draait en/of op een oud besturingssysteem (o.a. CentOS 6.x of lager) draait, dan adviseren wij uw server uit te laten migreren naar een (veel) nieuwere omgeving/versie. Niet alleen biedt dit meer veiligheid voor u en uw klanten, maar ook krijgt u dan de beschikking over nieuwere functies en hogere PHP-versies (8.x).

Daarnaast zal de performance ook een stuk hoger liggen, want onze nieuwste servers worden aangemaakt met op basis van de nieuwste versie van onze virtualisatie software. Ook dit laatste biedt een hogere graag van bescherming en betere performance. En ook is de gehele setup c.q. configuratie methode van een Plesk server radicaal aangepast. Dit alles komt ten goede van de algemene veiligheid en performance van uw Plesk serveromgeving.

Mocht u willen migreren, dan adviseren wij u een support ticket aan te maken op Helpburo. Vermeld hierbij wel uw server gegevens. Wij zullen u dan zo spoedig mogelijk informeren over de mogelijkheden die er voor u beschikbaar zijn. Een migratie dient altijd ingepland te worden met één van onze technici. Hiervoor staat doorgaans 1 tot 3 weken; dit is afhankelijk van de hudige drukte inzake reeds eerder ingeplande werkzaamheden.

Wanneer u een (contact) formulier op uw website heeft staan en deze werkt opeens niet meer, dan bestaat de kans dat uw formulier niet beveiligd is (met een captcha code) en daardoor misbruikt wordt/werd om spam te versturen. Als gevolg hiervan hebben wij de PHP sendmail functie voor uw hostingaccount uitgezet. Dit om verdere overlast te voorkomen en schade aan de reputatie van onze IP-adressen.

Wij hebben hierop reeds meerdere keren op geattendeerd via diverse mailings, nieuwsberichten en meldingen op onze websites (en ook op Helpburo). Zie o.a. hier en hier voor deze meldingen. Helaas blijkt er nog altijd een groep te zijn die hier geen gehoor aan geeft. Derhalve zetten wij bij misbruik van welk formulier dan ook de PHP sendmail functie uit voor het desbetreffende account. Spam is één van de grootste ergenissen van vandaag de dag en dit is niet alleen vervelend, maar dit kost ook geld en daarnaast schaadt het dus ook de goede reputatie van onze IP-adressen. Ook kan door dergelijke formulieren IP-adressen op een zwarte lijst (blacklist) komen te staan, waardoor er helemaal geen email meer verstuurd kan worden.

U als server beheerder, website beheerder of webdesigner bent altijd verantwoordelijk voor de door u geplaatste content op uw ruimte. Zo ook dus voor beveiligde (contact) formulieren. Ieder formulier welke beschikt over een email c.q. bericht functie, dient beveiligd / afgeschermd te worden. Een simpele rekenformule gebruiken, zoals "1 + 5" als beveiliging is dus géén beveiliging! Je hebt tegenwoordig een legio aan diverse captcha mogelijkheden, zowel zichtbaar als onzichtbaar. Dus beveilig altijd uw (website) formulieren. Zie ook hier ons andere Kennisbank artikel. Nogmaals; er is géén enkele reden om dit niet te doen.

Hoe krijg ik mijn formulier weer werkend?

Indien uw formulier plotseling niet meer werkt, dan zal de PHP sendmail functie dus uitgezet zijn voor uw hostingaccount. Wij activeren deze functie pas weer als het formulier daadwerkelijk beveiligd is. Eerder doen wij dit niet! Voor Wordpress zijn er verschillende plugins verkrijgbaar die een captcha code gebruiken in het formulier. Zoek dit op. Voor Joomla zijn er soortgelijke oplossingen. Heeft u een aangepaste website of een website laten maken door een andere partij, dan zal u hun moeten vragen om het formulier te beveiligen.

Wanneer het formulier beveiligd is, dan kan u een support ticket aanmaken voor heractivatie van de PHP sendmail functie. Uiteraard zullen wij dit eerst controleren en testen of het formulier in kwestie daadwerkelijk beveiligd is. Wanneer dit daadwerkelijk zo is, dan zullen wij de PHP sendmail functie weer inschakelen voor uw hostingaccount of domein.

Let op! Het uitschaken van de PHP sendmail functie heeft totaal geen invloed op het versturen/ontvangen van email vanuit uw emailprogramma/emailadres. Het heeft puur en alleen betrekking op functies op uw website die emails/berichten versturen, zoals o.a. contact formulieren. Indien u problemen heeft met het verzenden/ontvangen van email, dan zal u een ander Kennisbank artikel moeten raadplegen (hiervoor zijn diverse oplossingen beschikbaar).

Tags: contactformulier, contact formulieren, contact formulier, niet werken formulier, formulier werkt niet, geen berichten website

We krijgen met enige regelmaat support tickets dat opeens één of meerdere menu items of subpagina's niet meer werken inzake een Wordpress website.

Enkele voorbeelden:

• https://domeinnaam.tld/contact/
• https://domeinnaam.tld/nieuws/
• https://domeinnaam.tld/about-us/

Vaak worden deze problemen veroorzaakt dat men de website 100% draait via Nginx in plaats van Apache.
Wanneer men gebruik maakt van Nginx, dan wordt het .htaccess bestand niet meer uitgelezen. Nginx leest geen .htaccess bestanden uit, dat doet alleen Apache.

Om dit te herstellen zal u "Proxy mode" moeten inschakelen onder de domeinnaam in kwestie. Dit doet u via "Hosting & DNS", vervolgens "Apache & nginx Settings" en dan tot "Nginx settings" omlaag scrollen. Aldaar ziet men de optie desbetreffende optie staan: Proxy mode. Deze dient dus aangevinkt te staan. Na twee of drie minuten (afhankelijk van de drukte op de server) zal dit toegepast moeten zijn en zouden menu items en/of subpagina's weer moeten functioneren. Zie ook de screenshots hieronder.

Indien dit niet het geval is, dan kunt u het beste even een support ticket aanmaken.

Wij krijgen zo nu en dan vragen over wat er precies onder "hostingaccounts" of "accounts" wordt verstaan inzake de Plesk reseller pakketten. In het artikel hieronder proberen wij dit te verduidelijken.

Bij Plesk worden er verschillende termen gebruikt, zoals;

• Customers (klanten)
• Domains (domeinen)
• Subscriptions (abonnementen)
• Service Plans (dienstenpakketten)
  
  

Uitleg termen

Wij zullen als eerste dieper ingaan op de bovenstaande termen, zodat dit meer duidelijkheid biedt. Verder daaronder worden de zaken nogmaals verduidelijkt aan de hand van een aantal voorbeelden.

Met "Service Plans" kunt u eigen hosting pakketten configureren. Bijvoorbeeld "Pakket Klein", "Pakket Groot", Pakket "A", etc. Hieraan zit geen limiet in welk opzicht dan ook. U kan bijvoorbeeld een hosting pakket met 100 GB ruimte aanmaken, echter zal het limiet van uw reseller pakket leidend zijn in deze. Dus als u een reseller pakket heeft die 20 GB ruimte geeft, dan mag u in totaal maximaal 20 GB aan ruimte in gebruik hebben binnen uw complete reseller pakket.

Via "Customers" kan u zelf klanten aanmaken; deze kunnen dan inloggen op de Plesk interface en bepaalde zaken kunnen aanpassen en/of instellen binnen hun Plesk account. De klant die u heeft aangemaakt heeft dan alleen toegang tot de gekoppelde domeinnaam (of domeinnamen) en overige zaken. Het aantal "Customers" staat gekoppeld aan het aantal (hosting)accounts wat u mag aanmaken binnen uw reseller pakket.

Wanneer u gaat naar "Domains" dan kan u de volgende primaire opties kiezen; "Add Domain", "Add Subdomain" en "Add Domain Alias". Wanneer u een domeinnaam toevoegd (dus "Add Domain") dan zal dit geteld worden als een (hosting)account binnen uw reseller pakket. Voor een subdomein ("Add Subdomain") of domeinnaamalias ("Add Domain Alias") gelden aparte limieten en worden niet direct meegeteld inzake het aantal (hosting)accounts binnen uw reseller pakket.

Dan hebben we als laatste nog de "Subscriptions"-optie; hiermee maakt u abonnementen aan binnen uw reseller pakket. Een abonnement staat altijd gekoppeld aan een domeinnaam, derhalve valt dit samen met het aantal toegestane (hosting)accounts binnen het door u afgenomen reseller pakket.

Enkele voorbeelden

Tot dusver de uitleg van de belangrijkste begrippen inzake een Plesk reseller pakket. Hieronder gaan we het één en ander verduidelijken aan de hand van een paar voorbeelden.

U besteld een Plesk reseller pakket met 10 (hosting)accounts, dan kan u dit gebruiken zoals hieronder;

• 10 klanten (customers) met ieder 1 abonnement (subscription) of 1 domeinnaam (domain)
• 5 klanten (customers) met ieder 2 abonnementen (subscriptions) of 2 domeinnamen (domains)
• 10 abonnementen (subscriptions) met ieder 1 domeinnaam (domain)
• 5 abonnementen (subscriptions) met ieder 2 domeinnamen (domains)
• 10 domeinnamen (domains)

Dus bij dit Plesk reseller pakket met 10 (hosting)accounts kan u maximaal 10 klanten (customers) aanmaken met in totaal 10 domeinen aanmaken. Hoe u dit zelf verdeelt is aan u. Voor zowel het aantal klanten alsook het aantal domeinen is het harde limiet 10, zoals het reseller pakket aangeeft. Voor het aantal subdomeinen en/of domeinnaamaliassen geldt een ander limiet, welke niet is gekoppeld aan het aantal (hosting)accounts van uw reseller pakket (doorgaans het dubbele). Een abonnement (subscription) staat altijd gekoppeld aan een domeinnaam.

Dan een ander voorbeeld; u besteld een Plesk reseller pakket met 100 (hosting)accounts, dan kan u dit gebruiken zoals hieronder;

• 100 klanten (customers) met ieder 1 abonnement (subscription) of 1 domeinnaam (domain)
• 25 klanten (customers) met ieder 4 abonnementen (subscriptions) of 4 domeinnamen (domains)
• 10 klanten (customers) met ieder 10 abonnementen (subscriptions) of 10 domeinnamen (domains)
• 100 abonnementen (subscriptions) met ieder 1 domeinnamen (domains)
• 25 abonnementen (subscriptions) met ieder 4 domeinnamen (domains)
• 10 abonnementen (subscriptions) met ieder 10 domeinnamen (domains)
• 100 domeinnamen (domains)

Dus bij dit Plesk reseller pakket met 100 (hosting)accounts kan u maximaal 100 klanten (customers) aanmaken met in totaal 100 domeinen aanmaken. Hoe u dit zelf verdeelt is aan u. Voor zowel het aantal klanten alsook het aantal domeinen is het harde limiet 100, zoals het reseller pakket aangeeft. Voor het aantal subdomeinen en/of domeinnaamaliassen geldt een ander limiet, welke niet is gekoppeld aan het aantal (hosting)accounts van uw reseller pakket (doorgaans het dubbele). Een abonnement (subscription) staat altijd gekoppeld aan een domeinnaam.

En tot slot

Het aantal (hosting)accounts welke staat aangegeven bij de Plesk reseller pakketten staan dus gekoppeld aan het aantal klanten "customers" en daarnaast ook aan het aantal domeinnamen "domains" die u kunt aanmaken. De reden voor twee apart ingestelde limieten (voor zowel klanten als domeinnamen) heeft te maken met het feit dat niet alle resellers klanten aanmaakt, maar bijvoorbeeld alleen abonnementen (dus "subscriptions"). Een abonnement is en staat altijd gekoppeld met een domeinnaam, vandaar het limiet op het aantal domeinen m.b.t. het Plesk reseller pakket. Plesk zelft geeft aan dat de volgende zaken worden meegeteld als domeinen (domains): "active/disabled/suspended domains", "domains with the "forwarding" hosting type" en "domains without hosting".

Dan nog een tip van onze kant; indien u een klein(er) reseller pakket heeft en u gebruikt een aantal domeinnamen alleen t.b.v. DNS (dus voor het beheer van A-, MX-records en dergelijke), dan is het wellicht verstandiger om bijvoorbeeld voor de domeinnamen een DWHS DA-Static pakket af te nemen. Dit zijn zeer goedkope pakketten (slechts een paar Euro per jaar) waarmee u dergelijke zaken kunt regelen. Op die manier hoeft u dan geen (hosting)accounts op te "offeren" m.b.t. uw reseller pakket. Op die manier blijft u dan ook optimaal gebruik maken van uw reseller pakket, zonder eventueel direct te hoeven upgraden naar een groter reseller pakket.

Mocht u toch nog vragen hebben inzake uw reseller pakket, een nieuw reseller pakket of iets toch nog onduidelijk zijn, dan kan u altijd een support ticket aanmaken.

Blijkbaar heeft Spamhaus een bijzondere wijziging doorgevoerd onlangs; zo blokkeert Spamhaus alle Open DNS providers, zoals:

• Google DNS
• Cloudflare DNS
• Quad9 DNS
• etc.

Hierdoor kun je de volgende (of soortgelijke) melding terug vinden in de log-bestanden of in de email die je terug krijgt:

Client host [XXX] blocked using zen.spamhaus.org; Error: open resolver; https://www.spamhaus.org/returnc/pub/203.0.113.1

Met name de foutmelding "Error: open resolver" geeft het probleem al duidelijk aan. Dus Spamhaus blokkeert in feite alles wat loopt via een Open DNS provider, waaronder de grootste en meest bekende, zoals Google en Cloudflare. Zeer bijzonder.

Wij maken 100% gebruik van deze Open DNS providers, daar dit zorgt voor zeer snelle en up-to-date DNS queries. Ook voor onze eigen internet verbindingen (zakelijk, maar ook prive) maken wij gebruik van deze Open DNS servers. Uiteraard worden op onze opgeleverde servers ook gebruik gemaakt van interne DNS resolvers, echter zijn die van Google en Cloudflare vaak een stuk sneller.

Hoe dan ook; als u het bovenstaande probleem tegen komt, dus een melding met "Error: open resolver", dan zijn er twee oplossingen;

• (aanbevolen) gebruik geen Spamhaus meer, maar een alternatieve oplossing
• Of log in op SSH van uw server en open het "resolv.conf"-bestand aan via:
  • vi /etc/resolv.conf
• Zorg ervoor dat alles weggehaald is op de drie volgende zaken na:
  • nameserver 83.172.132.45
  • nameserver 83.172.133.45
  • nameserver 127.0.0.1
• Sla het bestand en u zou nu weer email kunnen ontvangen

Er zijn genoeg alternatieven beschikbaar, zowel gratis als betaald. U kan de gratis oplossingen vinden via Google. Een betaalde oplossing is om over te stappen naar ons eigen Spamprotector.
Dit is géén server probleem (ondanks dat Spamhaus dit aangeeft, als je de foutmelding opzoekt), maar ligt aan Spamhaus die Open DNS providers gewoonweg blokkeert. Alle servers (VPS/DPS) die wij normaliter opleveren maken gebruik van onder meer Open DNS providers (o.a. Google en Cloudflare), daar dit zorgt voor de allerbeste performance inzake DNS queries.

Dit is dan ook de reden dat wij adviseren om geen gebruik meer te maken van Spamhaus, maar indien u dit toch wenst, dan kan u de eerder genoemde oplossing toepassen.

Webmail Roundcube en Horde

Vroeger kon men altijd inloggen op de webmail door simpelweg de domeinnaam op te geven met de term webmail ervoor, dus bijvoorbeeld: webmail.domeinnaam.nl.

Vervolgens kon je dan via je favoriete webbrowser online je emails lezen en/of beantwoorden. Dit heeft lange tijd voor de meesten probleemloos gewerkt. Echter is de beveiliging, van verschillende webbrowsers, verder omhoog gegaan. Hierdoor kan het zijn dat je je webmail via je domeinnaam niet meer kunt benaderen. Meestal krijg je dan de melding dat de verbinding niet veilig of onveilig is. Afhankelijk van welke webbrowser je gebruikt, kun je in sommige gevallen doorklikken en de waarschuwing negeren.

Uiteraard is dat niet veilig. Vandaar dat wij al jaar en dag adviseren om de hostname van de server te gebruiken voor het benaderen van je webmail. Dit werkt precies hetzelfde als via je eigen domeinnamen, alleen is de manier van inloggen anders, dit vanwege een andere URL. Je logt gewoon in met je volledige emailadres en wachtwoord. Daarna werkt alles weer vanouds, alleen ditmaal beveiligd via een SSL verbinding uiteraard.

Je kan ook de webmail op je domeinnaam beveiligen via een SSL certificaat. Dit kan via een betaald SSL certificaat (via onze website aan te vragen) en ook via gratis d.m.v. Let's Encrypt (hierop geen enkele vorm van support vanwege de problemen hiermee). Maar wij adviseren om toch te kiezen voor het gebruik van de webmail op de hostname. Dan weet je zeker dat de verbinding altijd beveiligd is.

Welke hostname voor mijn webmail?

Om erachter te komen welke hostname u voor de webmail moet gebruiken, klikt u op de volgende link CheckMailServer (opent een nieuw scherm). In het nieuwe scherm vult u uw domeinnaam in (bijvoorbeeld pietjepuk.nl) en klikt u op "Zoek gegevens".

Vervolgens ziet u onder "Restulaat..." het volgende staan: ns1. en ns2. Wat hierachter staat is de hostname. Dus bijvoorbeeld pleskssd4.nl. In dat geval kunt u uw webmail benaderen via: webmail.pleskssd4.nl. Vervolgens vult u uw volledige emailadres in tesamen met het bijbehorende wachtwoord. En vervolgens kunt u weer helemaal veilig en zonder problemen uw webmail gebruiken.

Wanneer u back-ups maakt binnen Plesk of DirectAdmin, dan kan het voorkomen dat uw website en email offline gaan.

Dit heeft 9 van de 10 keer te maken met het feit dat uw backups teveel ruimte in nemen (meer dan is het toegestaan binnen uw hosting pakket). Het systeem controleert iedere nacht op eventueel overgebruik (= over quota) en indien dit het geval is, dan zet het systeem het desbetreffende hostingaccount op non-actief. Dit gebeurd volledig automatisch en dient puur en alleen ter beveiliging van de server en overige klanten.

De achterliggende gedachte hiervan is dus een extra laag van bescherming, want het kan zijn dat een hostingaccount gehackt is en hier dus misbruik van gemaakt wordt door (bijvoorbeeld) talloze illegale bestanden op uw hostingaccount te plaatsen. Zou dit limiet er niet op zitten, dan kan het wezen dat de server overvol raakt en deze crasht. Dit is iets wat wij natuurlijk altijd willen voorkomen.

Normaliter stuurt het systeem automatisch berichten wanneer uw hostingaccount tegen het limiet aan loopt. Het emailadres welke aan het hostingaccount gekoppeld staat ontvangt deze berichten. Het is dan uw verantwoording om hier dan ook opvolging aan te geven (opschonen van het hostingaccount en/of upgraden naar een groter pakket). Onderneemt u geen actie, dan bestaat de kans dat bij een volgende keer uw hostingaccount (tesamen met uw website email) offline wordt gezet door het systeem. En nogmaals dit gebeurd volledig automatisch! Dit is altijd al zo geweest bij zowel Plesk alsook DirectAdmin.

In uitzonderlijke gevallen kan het zijn dat u geen email heeft ontvangen van het systeem dat uw hostingaccount bijna vol is/was, maar toch offline is gezet door het systeem. Dit kan als oorzaak hebben dat u een hele grote back-up heeft gemaakt van uw hostingaccount (webbestanden, emails, databases, etc.), waardoor u in één keer van 60% naar 120% bent gegaan. Wij zetten meldingen doorgaans aan op ~80% afhankelijk van de grootte van het hostingacocunt.

Indien uw hostingaccount (website en email) offline zijn gezet door het systeem, dan zal u een support ticket moeten aanmaken. Wij zullen dan kijken naar de oorzaak en u adviseren om deze (direct) op te schonen of te upgraden naar een groter pakket. Ook vermelden wij de oorzaak uiteraard (meestal te grote of teveel back-up's). Onderneemt u geen actie, dan zal het account wederom automatisch uitgezet worden door het systeeem. Wij verwijderen geen back-ups van klanten en/of schonen bestanden op. Wij weten immers niet wat wel of niet verwijderd mag worden. In het verleden deden wij dit wel voor onze klanten, echter door een aantal vervelende ervaringen doen wij dit niet meer, tenzij expliciet aangegeven wordt dat het geen probleem is. Maar dit is dan op uw eigen verantwoording.

Indien uw hostingaccount (tesamen met uw email en website) offline is komen te staan door teveel of te grote back-up's, dan is het wellicht raadzaam om Backupmaster aan te schaffen voor uw hostingpakket. Dit is ons eigen ontwikkelde back-up software en deze werkt gewoonweg perfect. U heeft hierbij geen enkele omkijken meer naar back-ups, want deze worden automatisch door ons gemaakt (van zowel bestanden, databases en ook email). En daarnaast kost Backupmaster totaal geen webruimte. Dat wil zeggen dat de back-up's die gemaakt worden door Backupmaster niet mee tellen inzake de beschikbare ruimte van uw hosting pakket.

Indien u Backupmaster wenst af te nemen voor uw hosting pakket, dan betaald u hiervoor slechts een minimale meerprijs van 15.00 Euro per jaar (voor een volledig hostingaccount). U heeft dan totaal geen omkijken meer naar betrouwbare back-ups van uw website, emailaccounts of databases. De prijs van 15.00 Euro per jaar voor Backupmaster is inclusief 3 gratis restores. Wanneer u gebruik wenst te maken van Backupmaster voor uw hostingaccount, dan kan u een support ticket aanmaken. Wij zullen dit dan direct instellen. Daarnaast zetten wij eventuele back-ups via Plesk/DirectAdmin uit. Overige back-ups (via bijvoorbeeld Wordpress zelf of via Installatron) zal u wel zelf uit moeten zetten.

Resumé;

• Hou altijd meldingen van de server in de gaten wanneer uw hostingaccount over het toegestane limiet dreigt te gaan en neem daarop zo spoedig mogelijk actie.
• Indien uw hostingaccount (website en email) offline staan door overgebruik, maar dan een support ticket aan
  • Wij vermelden dan de reden waardoor uw hostingaccount offline staan
  • Vervolgens dient u dan uw hostingaccount op te schonen of te upgraden naar een groter pakket
  • In geval van teveel of te grote back-ups eventueel overwegen om Backupmaster af te nemen

Tags: directadmin, plesk, backup, back-ups, backups, Backupmaster, offline, overmatige gebruik, tw weinig ruimte

Op bijna alle (eigen) servers van ons (o.a. webhosting servers, reseller servers). Staat ImunifyAV+ geinstalleerd. Dit is een malware scanner welke perodiek controleert op discutabele / malafide bestanden en eventuele hacks.

Wanneer een website besmet is, dan zal ImunifyAV+ hiervan een melding sturen. Het is dan zaak om dit direct te controleren en op te lossen. Indien u geen actie onderneemt, dan worden de gehackte bestanden door ImunifyAV+ opgeschoond. Hierdoor kan uw website vervolgens niet meer (correct) functioneren. Vandaar het advies om dit dan ook zo spoedig mogelijk op te pakken en de vermelde bestanden controleren. Regelmatig komen deze malafide c.q. gehackte bestanden op de server door slecht (of zelfs géén) onderhoud van de website (met name Wordpress websites vallen hier onder en bijbehorende plugins).

Indien de website in kwestie wederom besmet raakt en u (wederom) geen actie hierop heeft ondernomen, dan behouden wij altijd het recht om de website (tijdelijk) op non-actief te zetten. Wij hechten extreem veel waarde aan een veilige serveromgeving en houden deze zelf ook up-to-date (meerdere updates per week). Dit verwachten wij dan ook van de klanten met een website (zoals bijvoorbeeld Wordpress). Zo dienen Wordpress websites regelmatig gecontroleerd en onderhouden te worden. Doet men dit niet, dan is de kans zeer groot dat deze gehackt wordt. Wij hebben al een flink aantal Wordpress kennisbank artikelen actief staan op Helpburo. Wij adviseren u om deze goed door te lezen. Er is géén enkele reden om niet uw (Wordpress) website periodiek te onderhouden en te controleren.

Wanneer wij malafide en/of gehackte bestanden op de server actief laten staan binnen een hostingaccount, dan heeft dit niet alleen een nadelige invloed op de veiligheid, maar ook op de server performance (= snelheid), de server stabiliteit en kan dit vele extra problemen opleveren, zoals een complete blok van de IP-adressen van de server. Hier zijn niet alleen andere hosting klanten (die wel alles goed onderhouden) het dupe van, maar het levert onze IP-range ook een negatieve score op. Dit willen wij te alle tijde voorkomen uiteraard. Derhalve zullen wij adequaat optreden tegen gehackte websites, welke een gevaar vormen voor andere klanten, onze servers en reputatie van ons netwerk. De eerste keer worden de bestanden opgeschoond door ImunifyAV+ wanneer er géén actie wordt ondernomen. Wanneer dezelfde of soortgelijke hack wederom plaats vindt, dan zullen wij de website (en bijbehorende) hostingaccount op suspend zetten. Todat de klant of zijn/haar websitebouwer een support ticket aanmaakt en aangeeft direct actie te ondernemen. Gezien het grote aantal websites dat wij hosten, zullen wij de klant hierover niet direct informeren; dat is gewoonweg onmogelijk. U, als eigenaar van uw hostingaccount en website, bent altijd verantwoordelijk voor de content c.q. inhoud die u plaatst binnen uw hostingaccount. Hetzelfde geldt voor periodiek onderhoud en beveiligen van uw (Wordpress) website.

Nogmaals, voor alle duidelijkheid, wanneer u een Wordpress website heeft, dan zal u deze regelmatig moeten onderhouden en voorzien van updates en/of betere beveiliging. Wordpress is een zeer populair CMS en hiervoor zijn duizenden verschillende plugins voor beschikbaar. Het meerendeel van deze plugins zijn goed en veilig, echter dienen deze wel actueel te zijn en dus worden voorzien van updates. Wanneer een WP plugin geruime tijd niet wordt voorzien van updates door de ontwikkelaar, dan is het raadzaam om op zoek te gaan naar een alternatief. Wij bieden hierin geen support, daar wij geen websites maken (en dit hebben wij ook nooit gedaan). U zal dit dan zelf moeten doen of uw websitebouwer moeten vragen.

Wijzelf doen er altijd alles aan om een serveromgeving (van hostingaccounts, reseller pakketten, alsook de bovenliggende hardware nodes) veilig te houden. Dit houdt in dat wij meerdere, al dan niet, automatische updates uitvoeren, nieuwe functies toevoegen en potentiele lekker dichten (via patches) en onze servers 24/7 monitoring en regelmatig scannen op malware en andere beveiligingsrisico's. Derhalve verwachten wij ook van onze klanten dat deze hetzelfde doen en hun website zo goed mogelijk onderhouden en dus voorzien van de noodzakelijke updates en beveiligingsaanpassingen.