Ga naar de inhoud 
Plesk-evenement Met handlers kan ik terugkerende hostingtaken gericht automatiseren en processen op betrouwbare wijze standaardiseren. Ik laat aan de hand van praktijkvoorbeelden zien hoe ik gebeurtenissen aan elkaar koppel, scripts activeer en zo het beheer, de integratie en de kwaliteit meetbaar versnel.
Centrale punten
Voordat ik dieper op de materie inga, vat ik de belangrijkste aspecten kort samen en leg ik de nadruk op schaalbare, veilige en traceerbare automatisering. Ik ga in op typische triggers, overzichtelijke scripts, prioriteiten en de koppeling met externe systemen. Daarbij houd ik processen gestroomlijnd, documenteer ik resultaten en bouw ik foutopsporing in mijn uitvoering in. Deze richtlijnen helpen om handlers soepel te laten draaien en risico’s te beperken. Zo blijft de Automatisering beheersbaar en draagt direct bij aan de efficiëntie.
- Trekker definiëren: gebeurtenis kiezen, actie correct koppelen
- Scripts compileren: foutafhandeling, logboekregistratie, exit-codes
- Prioriteit besturen: volgorde van meerdere handlers per gebeurtenis
- Rechten Let op: passende gebruikerscontext, zo min mogelijk rechten
- Integratie toepassen: CRM, facturering en monitoring integreren
Ik hecht veel waarde aan korte lijnen, duidelijke verantwoordelijkheden en consistente resultaten. Met deze punten bouw ik een betrouwbare Werkstromen, die ik op elk moment uitbreid of vervang.
Wat zijn event-handlers in Plesk?
Een event handler koppelt een specifieke gebeurtenis aan een vastgestelde actie en zorgt zo voor de technische Koppeling tussen de trigger en de reactie. Wanneer Plesk een gebeurtenis activeert, zoals „Customer Account Created“, „Subscription Created“ of „Domain Deleted“, start mijn handler een commando, een script of een binair bestand. Ik gebruik hiervoor ofwel de interface (Tools & Settings → Event Manager) ofwel het CLI-hulpprogramma event_handler, afhankelijk van de workflow en de omgeving. Het basisprincipe blijft hetzelfde: er doet zich een gebeurtenis voor, Plesk geeft contextvariabelen door en de handler verwerkt deze op een deterministische manier. Zo creëer ik consistente Processen, die altijd op dezelfde manier reageren, ongeacht het tijdstip, de stemming of hoe je je die dag voelt.
Snelstart via de gebruikersinterface
Om te beginnen maak ik gebruik van de GUI en maak ik snel nieuwe handlers aan, zonder een shell te openen. Ik selecteer de doelgebeurtenis, wijs een passende prioriteit toe, definieer de uitvoerende gebruiker (Linux: root, Windows: Plesk-beheerder) en voer het volledige scriptpad in. Vervolgens controleer ik de variabelen van de gebeurtenis en geef ik deze door aan het script, zodat de actie alle benodigde gegevens bevat. Wie Plesk dagelijks op grotere schaal gebruikt, heeft baat bij een overzicht van functies en toepassingsgebieden; daarvoor is de compacte Plesk-serverbeheer. Nadat ik het heb opgeslagen, controleer ik het resultaat met een testgebeurtenis en kijk ik in de logbestanden of mijn Actie goed verliep. Deze werkwijze bespaart tijd en zorgt voor een duidelijke Documentatie per handelaar.
Geautomatiseerd beheer via CLI
In geautomatiseerde omgevingen integreer ik event-handlers consequent in de CLI om deployments reproduceerbaar te houden. Ik maak een lijst van beschikbare events, maak nieuwe handlers aan en werk bestaande vermeldingen bij via scripts, zodat CI/CD-pijplijnen soepel verlopen. Bij consequent gebruik ontstaat er een duidelijke geschiedenis en zijn de statussen consistent over vele servers heen. Om fouten vroegtijdig te herkennen, log ik de uitvoer van mijn scripts en controleer ik retourcodes. De volgende basiscommando’s gebruik ik regelmatig en pas ik parameters zoals Event, Priority, User en Command aan de betreffende Omgeving naar:
# Beschikbare gebeurtenissen weergeven
plesk bin event_handler --list-events
# Handler aanmaken (voorbeeld)
plesk bin event_handler --create \
-event "Customer account created" \
-priority 20 \
-user root \
-command "/usr/local/bin/on_customer_created.sh"
# Configuratie controleren
plesk bin event_handler --list
Praktijkvoorbeelden
Bij nieuwe klantaccounts voer ik een script uit dat CRM-records aanmaakt en een intern bericht verstuurt. Bij het aanmaken van een abonnement stel ik gestandaardiseerde DNS-records in, richt ik optionele mailboxen in en schrijf ik auditlogs. Bij het toevoegen van domeinen start ik een routine die certificaten aanvraagt of configuratiebestanden voor reverse proxies bijwerkt. Als een abonnement verandert, initieert een handler een externe API-aanroep die licenties of factureringstarieven synchroniseert. Deze use cases houden de administratieve rompslomp laag, verlagen het foutenpercentage en versterken de Traceerbaarheid bij elke actie. Zo ontstaat er een herhaalbaar raamwerk dat ik per klant doelgericht uitbreiden.
Tabel: Belangrijke gebeurtenissen en instellingen
Voordat ik handlers aanmaak, plan ik de gebeurtenis, de prioriteit, de gebruikerscontext en het doel van mijn actie. Het volgende overzicht helpt me om zinvolle standaarden vast te stellen en consistentie te waarborgen over meerdere hosts heen. Ik groepeer hier typische Plesk-gebeurtenissen en voeg opmerkingen toe over de aanbevolen gebruiker en gangbare reacties. De kolom „Variabelen“ herinnert me eraan welke contexten Plesk aan het script ter beschikking stelt. Deze structuur verkort de inwerktijd, verhoogt de kwaliteit en versterkt de technische Duidelijkheid in bedrijf.
| Evenement | Typische variabelen | Aanbevolen gebruiker | Voorbeeldactie | Prioriteit |
|---|---|---|---|---|
| Klantaccount aangemaakt | NEW_CONTACT_NAME, NEW_LOGIN | root / beheerder | CRM-vermelding, welkomstmail | 20 |
| Abonnement aangemaakt | SUBSCRIPTION_ID, DOMAIN_NAME | root / beheerder | DNS-records instellen, standaardmailbox | 30 |
| Domein aangemaakt | DOMAIN_NAME, IP_ADDRESS | root / beheerder | SSL aanvragen, proxy-configuratie opstellen | 40 |
| E-mail Naam Aangemaakt | MAIL_NAME, DOMAIN_NAME | root / beheerder | Quota instellen, sjabloon voor automatisch antwoord | 50 |
| Hostinginstellingen bijgewerkt | HOSTING_TYPE, DOCUMENT_ROOT | root / beheerder | Bestandsrechten aanpassen, cache leegmaken | 60 |
Met deze referentie hoef ik niet lang op te zoeken en kan ik nieuwe automatiseringen aanzienlijk sneller aanmaken, zonder dat ik Onderzoek om het zonder te doen.
Veiligheid, rechten en toezicht
Ik kies bewust de gebruiker die het script uitvoert en beperk de rechten zo veel mogelijk, zodat scripts alleen doen wat de bedoeling is. Gevoelige routines sluit ik in aparte wrappers in, controleer ik invoer en dwing ik correcte exitcodes af. Voor terugkerende situaties loont het bovendien de moeite om een beveiligingsconcept op te stellen, bijvoorbeeld op basis van de Handleiding voor Fail2ban, om verdachte patronen in een vroeg stadium te blokkeren. Ik beschouw logging als een must: elke handler schrijft de tijd, de gebeurtenis, de parameters en het resultaat naar een centraal bestand of naar een monitoring-backend. Zo herken ik afwijkingen, kan ik de oorzaken inkaarten en zorg ik ervoor dat audits duidelijk. Veiligheid is geen extraatje, maar een integraal onderdeel van elke Automatisering.
Prioriteiten, volgorde en afhankelijkheden
Als er meerdere handlers op dezelfde gebeurtenis zijn gekoppeld, regel ik de uitvoering via prioriteiten en houd ik me strikt aan de afhankelijkheden. Een logische keten begint vaak met logboekregistratie, gevolgd door meldingen en pas daarna integraties die externe systemen aansturen. Ik documenteer deze volgorde in de team-wiki en plaats een link hiernaar vanuit de handlerbeschrijving, zodat iedereen de context kent. Waar er interacties zijn, controleer ik neveneffecten op idempotent gedrag om dubbele uitvoering te voorkomen. Bij twijfel kapsel ik neveneffecten in en beveilig ik kritieke paden via retourcodes en geïsoleerde Transacties . Deze discipline voorkomt race conditions en behoudt de technische Netheid mijn processen.
Tests, staging en uitrol
Voordat iets live gaat, test ik alle handlers in een staging-omgeving met realistische gegevens en gecontroleerde timing. Ik activeer gebeurtenissen doelgericht, controleer logbestanden, vergelijk de gewenste en werkelijke toestand en documenteer afwijkingen. Pas wanneer de resultaten reproduceerbaar zijn, automatiseer ik de uitrol via scripts of configuratiebeheer. Ik houd rollbacks achter de hand om foutieve versies snel terug te draaien zonder diensten in gevaar te brengen. Daarna houd ik de eerste uitvoeringen nauwlettend in de gaten om kinderziektes snel te verhelpen. Zo blijft mijn uitrol planbaar en de kwaliteit betrouwbaar in de productie hoog.
Foutdiagnose en herstel
Als een handler niet wordt geactiveerd of mislukt, controleer ik eerst de toewijzing van de gebeurtenis, de gebruikerscontext, de bestandsrechten en de paden. Vervolgens bekijk ik de logbestanden, verhoog indien nodig het detailniveau en simuleer de uitvoering inclusief variabelen via de shell. Als er inconsistenties in de Plesk-configuratie optreden, helpt dat mij Plesk Repair Toolkit, bekende foutpatronen automatisch te verhelpen. Daarnaast beschik ik over vaste herstelstappen: defecte handlers uitschakelen, corrigeren, opnieuw testen en op de juiste manier weer inschakelen. Met duidelijke diagnosepaden minimaliseer ik uitvaltijd en zorg ik voor de Beschikbaarheid mijn Diensten.
Integratie via hooks en uitbreidingen
Als een klassieke event handler niet volstaat, gebruik ik hooks en listeners om dieper in Plesk door te dringen. Een PHP-eventlistener in admin/plib koppelt zich rechtstreeks aan interne processen en breidt mijn reactiemogelijkheden uit. Daarnaast voeg ik in uitbreidingen eigen aangepaste gebeurtenissen toe, die later in het actielogboek verschijnen en net als native gebeurtenissen kunnen worden verwerkt. Zo ontstaat een flexibele architectuur waarin Plesk gebeurtenissen genereert en mijn modules precies de juiste actie leveren. Daarbij let ik op versiecompatibiliteit, documenteer ik interfaces en test ik updates in een vroeg stadium. Zo blijven integraties duurzaam en goed te onderhouden tijdens onderhoudsvensters. bestuurbaar.
Script-blueprints: robuust, testbaar, herbruikbaar
Ik stel consistente scriptsjablonen op die fouten in een vroeg stadium opvangen, netjes loggen en op een deterministische manier afsluiten. Dit vermindert storingen en versnelt het opsporen van fouten. Voor Linux geef ik de voorkeur aan Bash met strikte opties en duidelijke functies:
#!/usr/bin/env bash
set -Eeuo pipefail
IFS=$'\n\t'
LOGFILE="/var/log/plesk/handlers/on_domain_created.log"
log() {
printf '%s | %s | %s\n' "$(date -Is)" "$1" "$2" | tee -a "$LOGFILE"
}
cleanup() { log INFO "Opruiming uitgevoerd"; }
trap cleanup EXIT
trap 'log ERROR "Regel $LINENO mislukt"; exit 1' ERR
: "${DOMAIN_NAME:=}"
: "${IP_ADDRESS:=}"
if [[ -z "$DOMAIN_NAME" ]]; then
log ERROR "DOMAIN_NAME ontbreekt"; exit 2
fi
log INFO "Start handler voor $DOMAIN_NAME met IP ${IP_ADDRESS:-n/a}"
# Voorbeeld: idempotente DNS-installatie
if ! grep -q "$DOMAIN_NAME" /etc/bind/managed.list; then
echo "$DOMAIN_NAME" >> /etc/bind/managed.list
log INFO "DNS-vermelding gemarkeerd"
else
log INFO "DNS-vermelding al aanwezig"
fi
log INFO "Klaar"; exit 0
In Windows maak ik gebruik van PowerShell met Try/Catch, gestructureerde logboekregistratie en duidelijke exitcodes:
Param(
[string]$DOMAIN_NAME,
[string]$SUBSCRIPTION_ID
)
$ErrorActionPreference = "Stop"
$log = "C:\plesk\logs\handlers\on_subscription_created.log"
function Write-Log($level, $msg) {
"$([DateTime]::UtcNow.ToString('o')) | $level | $msg" | Out-File -FilePath $log -Append -Encoding UTF8
}
try {
if ([string]::IsNullOrEmpty($DOMAIN_NAME)) { throw "DOMAIN_NAME ontbreekt" }
Write-Log "INFO" "Start voor $DOMAIN_NAME (Sub $SUBSCRIPTION_ID)"
# Voorbeeldactie
Write-Log "INFO" "Actie geslaagd"
exit 0
} catch {
Write-Log "ERROR" $_.Exception.Message
exit 1
}
Variabelen, overdrachten en correcte aanhalingstekens
Plesk verstrekt per evenement specifieke Contextvariabelen, vaak met voorvoegsels zoals NEW_/OLD_ (bijv. NEW_LOGIN) of veelzeggende namen (DOMAIN_NAME, SUBSCRIPTION_ID). Ik controleer in elk script welke variabelen zijn ingesteld en gebruik defensieve aanhalingstekens:
- Linux: Zet parameters altijd tussen dubbele aanhalingstekens om spaties en metatekens te beschermen.
- Windows: Strings correct tussen aanhalingstekens plaatsen, rekening houden met codepagina's, paden met backslashes escapen.
- Ontbrekende variabelen vroegtijdig herkennen en met eenduidige exit-codes afsluiten.
Belangrijk: niet elke gebeurtenis levert alle verwachte waarden op. Ik documenteer per handler de daadwerkelijk gebruikte variabelen en test grensgevallen (lege waarden, speciale tekens, zeer lange waarden) om verrassingen te voorkomen.
Tijdsgedrag, asynchronie en hulpbronnen
Handlers blokkeren geen kernactie, maar zouden wel korte en zuinig omgaan met bronnen. Langere taken voer ik asynchroon uit, zodat de gebruikersinterface en de provisioning soepel blijven werken. Daarvoor gebruik ik onder Linux bijvoorbeeld systemd-run of een achtergrondproces, en onder Windows Jobs:
# Linux: asynchroon uitvoeren
systemd-run --unit=plesk-handler-%i --collect /usr/local/bin/langläufer.sh "$DOMAIN_NAME"
# Alternatief: gewoon op de achtergrond
nohup /usr/local/bin/langläufer.sh "$DOMAIN_NAME" >/dev/null 2>&1 &
# Windows: achtergrondtaak
Start-Job -ScriptBlock { & "C:\Scripts\langlaeufer.ps1" $env:DOMAIN_NAME } | Out-Null
Ik stel time-outs in voor externe aanroepen, beperk het aantal herhalingspogingen met backoff en sla tussentijdse resultaten op, zodat een afbreking niet tot inconsistente toestanden leidt. Ik houd geen bronnen permanent bezet: ik leeg caches, sluit handles en verwijder tijdelijke bestanden.
Parallelisme, idempotentie en vergrendelingen
Als er snel achter elkaar evenementen plaatsvinden, zorg ik ervoor dat ik Race-omstandigheden . Twee veelvoorkomende patronen:
- Idempotentie: Acties zo opzetten dat er geen schade ontstaat wanneer ze meerdere keren worden uitgevoerd (bijv. „create if not exists“, „upsert“).
- Sloten: Tijdelijke locks voorkomen gelijktijdige schrijftoegang. Onder Linux gebruik ik `flock`:
exec 9>" /var/lock/plesk-handler.lock"
flock -n 9 || { echo "gesperrt"; exit 0; }
# kritischer Abschnitt
In Windows bereik ik iets soortgelijks met een mutex of door op exclusieve basis een lock-bestand aan te maken. Ik log vergrendelingen expliciet, zodat ik bij opstoppingen snel de oorzaken kan achterhalen.
Beheer in teamverband: naamgevingsregels, versiebeheer, rollback
Onderhoudbaarheid begint bij Namen. Ik benoem handlers consequent volgens het patroon „[Gebeurtenis] – [Doel] – [Team]“ en hanteer vaste prioriteitsniveaus (bijv. 10 = logboekregistratie, 20 = melding, 30 = configuratie, 40 = integraties). Scripts worden per versie opgeslagen in /usr/local/bin of C:\Scripts, en niet verspreid over home-mappen.
Ik voer wijzigingen op een gecontroleerde manier door: een nieuwe versie opslaan, de checksums controleren, de handler via de CLI bijwerken en documenteren:
#-ID uit de lijst ophalen
plesk bin event_handler --list
#-handler bijwerken
plesk bin event_handler --update 123 \
-priority 30 \
-command "/usr/local/bin/on_subscription_created.sh" \
-user root
# Handler verwijderen
plesk bin event_handler --remove 123
Voor rollbacks houd ik de vorige versie bij de hand en kan ik met een script snel terugdraaien. Wijzigingen zijn voor alle betrokkenen traceerbaar.
Verschillen tussen besturingssystemen: Linux versus Windows
Beide platforms werken in wezen op dezelfde manier, maar verschillen in de details. Onder Linux let ik op de shebang van de interpreter, uitvoeringsrechten (chmod +x) en absolute paden. Onder Windows houd ik rekening met de ExecutionPolicy (handtekeningen/bypass, afhankelijk van de beveiligingsvoorschriften), padscheidingstekens en codering. Ik kies logdoelen op basis van het platform (bestand, Event Log, Journald) en houd de formaten consistent, zodat analyses niet uit elkaar lopen.
Monitoring en evaluatie
Logs zijn slechts zo goed als hun Analyseerbaarheid. Ik schrijf gestructureerde regels (bijvoorbeeld in JSON-stijl) met velden voor tijdstempel, gebeurtenis, object (domein/abonnement), status, duur en correlatie (bijvoorbeeld PID). Uit deze gegevens genereer ik basisstatistieken:
- Succespercentage per type evenement en periode
- Gemiddelde looptijden en looptijden in het 95e percentiel
- Aantal herpogingen en afbrekingen
- De belangrijkste oorzaken van fouten
Bij afwijkingen stel ik waarschuwingen in (bijvoorbeeld een daling van het slagingspercentage of een piek in de doorlooptijd). Zo signaleer ik knelpunten voordat gebruikers er last van krijgen.
Veelvoorkomende valkuilen en checklist
- Problemen met het pad: Gebruik altijd absolute paden; PATH is in de handler-context vaak minimaal.
- Rechten: Controleer de bestands- en uitvoeringsrechten en de SELinux/AppArmor-profielen.
- Er ontbreekt een tolk: Is /usr/bin/python3 of /usr/bin/node niet aanwezig? Documenteer de afhankelijkheden en installeer ze.
- Citaat: Onverwachte spaties/speciale tekens in domeinnamen of gebruikersnamen correct escapen.
- Time-outs: Externe API’s met tijdslimiet en een herpogingsstrategie aanroepen, resultaten in de cache opslaan.
- Retourcodes: 0 voor succes, duidelijk gedefinieerde codes anders dan nul voor foutpaden – dit vergemakkelijkt de analyse.
- Debug: Stel de testvariabelen handmatig in en start het script afzonderlijk om gebeurtenisstromen te simuleren.
# Linux: Simulatie
export DOMAIN_NAME="example.test"; export SUBSCRIPTION_ID="4711"
bash -x /usr/local/bin/on_subscription_created.sh
# Windows: simulatie
$env:DOMAIN_NAME="example.test"; $env:SUBSCRIPTION_ID="4711"
powershell -File "C:\Scripts\on_subscription_created.ps1"
Gegevensbescherming, vertrouwelijkheid en audit
Wat persoonsgegevens betreft, pas ik Gegevensminimalisatie aan: Geef alleen noodzakelijke parameters door en pseudo-anonimiseer of anonimiseer deze in logbestanden (bijv. hash in plaats van de volledige naam, de laatste cijfers maskeren). Toegangsgegevens of tokens houd ik strikt gescheiden (bestandsrechten, aparte configuratiebestanden, omgevingsvariabelen alleen binnen het benodigde bereik). Bewaartermijnen zorgen ervoor dat logbestanden niet eeuwig blijven staan. Voor audits houd ik per handler een korte, bindende beschrijving bij: doel, gebeurtenis, variabelen, eigenaar, contactpersoon, laatste wijziging.
Schaalbaarheid bij gebruik van meerdere servers
Naarmate omgevingen groeien, vermijd ik centrale knelpunten. Ik ontkoppel externe integraties via buffers (bijv. asynchrone verwerking), ontdubbel gebeurtenissen en beperk het aantal verzoeken naar systemen van derden. Configuraties implementeer ik in fasen, houd ik de statistieken in de gaten en pas ik de prioriteiten aan wanneer afzonderlijke ketens te lang worden. Voor gedeelde bronnen (bijv. DNS, proxy) maak ik gebruik van idempotente updates en uitgebreide conflictcontrole, zodat parallelle wijzigingen niet met elkaar in conflict komen.
Samenvatting: Richtlijnen voor het dagelijks leven
Ik zet Plesk Event Handlers doelgericht in om standaardtaken te automatiseren, fouten te verminderen en integraties soepel te coördineren. De belangrijkste stappen blijven: een gebeurtenis definiëren, een script met foutafhandeling schrijven, een prioriteit toekennen, de gebruikerscontext controleren en logboekregistratie inschakelen. Voor grotere opstellingen beheer ik handlers via de CLI, rol ik wijzigingen uit via een pipeline en zorg ik ervoor dat er rollbacks beschikbaar zijn. Daarbij houd ik veiligheid, monitoring en testomgevingen altijd in de gaten, zodat acties betrouwbaar en transparant blijven. Met deze aanpak bouw ik een onderhoudbare Automatisering die het beheer van de hosting versnelt en de kwaliteit op lange termijn waarborgt zorgt ervoor dat.
