plesk panel
Gebruikt iemand van jullie Plesk Panel? Of is iemand hier (goed) bekend mee?
Twee keer nee, maar dat wil je natuurlijk niet horen. ;-)
- Bij mijn stage bedrijf gebruiken we op 1 van de 3 servers Plesk om alle domeinen te beheren.
Haha, nee liever niet ;) Bewuste keuze dat je het niet gebruikt?
@Hertog:
Weet je er veel vanaf? Ik ben benieuwd of het makkelijk werkt. Momenteel heb ik cPanel, maar ik ben niet over alles even tevreden. Ik zit te kijken om over te stappen naar een andere hosting provider, en daar hebben ze Plesk Panel 11.5, maar ik vraag me dus af of dat fijn werkt. Hoe is jouw ervaring?
Ik werk er niet dagelijks mee, maar als ik er mee werk heb ik er niet echt problemen mee. Ik vind het makkelijk in gebruik en kun je bv gemakkelijk nieuwe subdomein, emails, databases etc aanmaken.
Kun je via Plesk ook (makkelijk) updaten? Bijv. updaten naar een nieuwere PHP of MySQL versie en dergelijke? En welk webmail programma wordt gebruikt?
Ozzie PHP op 11/01/2014 11:22:26:
>> Twee keer nee, maar dat wil je natuurlijk niet horen. ;-)
Haha, nee liever niet ;) Bewuste keuze dat je het niet gebruikt?
Haha, nee liever niet ;) Bewuste keuze dat je het niet gebruikt?
Tsja, wat is bewust? Het is eigenlijk nooit bij me opgekomen om een panel te gaan gebruiken. ;-)
Mijn eerste webserver heb ik opgezet in 1996 (Purveyor; nooit meer iets van dat pakket gehoord) en in 1997 ben ik overgestapt naar Apache. Volgens mij waren er toen nog niet eens admin panels. Ik ben dus eigenlijk altijd gewend geweest de server handmatig te configureren.
Daarnaast val ik denk ik niet in de doelgroep van admin panels. Die zijn m.i. ideaal voor een beheerder als die klanten heeft die hij wil afschermen van de eigenlijke configuratie, zodat hij niet het risico loopt dat een klant door een tikfoutje de server onderuit schoffelt. En ze zijn ideaal voor de klanten die niets (willen) weten van serverconfiguraties, maar gewoon eenvoudig een website willen beheren.
Momenteel beheer ik op mijn werk het serverpark. We hebben iets van 350 domeinen. Laatst kwamen er zo'n 80 bij, en ik vrees dat ik mezelf nu nog steeds een dikke RSI aan het klikken was geweest als ik die via een admin panel had moeten toevoegen. Nu was het een kwestie van de lijst met domeinen knippen en plakken vanuit mijn email, een paar commando's geven in VI, en ik was in een seconde of 45 klaar.
Er is overigens nog een reden dat we op mijn werk geen admin panel gebruiken: de hele website hangt aan elkaar van request/authorization handlers die in Perl zijn geschreven (mod_perl onder Apache), in combinatie met reverse proxies en url rewrites, en ik heb zo de indruk dat die setup iets te complex is geworden om te beheren met een generiek softwarepakket.
>> en ik heb zo de indruk dat die setup iets te complex is geworden om te beheren met een generiek softwarepakket.
Nou, dit is wel een puntje. Ik heb nu cPanel en als je dan een vhost wil aanpassen dan kan dit niet in de httpd.conf zelf, maar dan moet je templates gebruiken, omdat ze anders worden overschreven bij een update.
Maar waar ik benieuwd naar ben... als je alles handmatig doet en je voert een Apache update uit, worden dan niet al je vhosts en dergelijke overschreven?
In dit geval kon ik die 80 vhosts als ServerAlias aan een bestaande host hangen, en als ze allemaal een eigen configuratie moeten krijgen maak ik een for-loopje in mijn shell en wijzig ik met sed de placeholders in een templatefile. Dus iets als
Code (php)
1
2
3
4
2
3
4
for domain in $(cat domains.txt)
do
sed s/DOMAIN/${domain}/g template.conf > /etc/httpd/conf.d/vhost-${domain}.conf
done
do
sed s/DOMAIN/${domain}/g template.conf > /etc/httpd/conf.d/vhost-${domain}.conf
done
> als je alles handmatig doet en je voert een Apache update uit, worden dan niet al je vhosts en dergelijke overschreven?
Nee. Als je de update via een package manager als yum of rpm doet, wordt de nieuwe (distibutie) configfile naast je bestaande configuratie gezet als httpd.conf.rpmnew etc. Je moet dan wel zelf controleren of er nog wijzigingen in zitten t.o.v. de oude versie die je mee moet/wilt nemen in je bestaande configuratie.
Daarnaast is het verstandig om zoveel mogelijk te configureren via /etc/httpd/conf.d (i.p.v. /etc/httpd/conf) omdat die conf.d-directory sowieso met rust gelaten wordt.
Maar hoe weet je dit allemaal? Ik heb hier echt (nog) geen kaas van gegeten. Is er een goed boek ofzo wat ik hiervoor kan lezen?
Gewijzigd op 11/01/2014 14:16:24 door Willem vp
Ah oke... misschien wel een goed idee. Ik ben geen systeembeheerder, en eigenlijk wil ik daar ook niks mee te maken hebben en gewoon alles via een beheerpanel regelen, maar ik vrees dat dat ijdele hoop is.
ja, dat is ijdele hoop, wanneer je een server(s) of in jouw geval een vos hebt, moet je ook kennis hebben van de software ..
Overigens, als je website zelf veilig is, kan dan toch nog van buitenaf je server worden gehackt eigenlijk?
Ja, een server kan ook gehackt worden.
En wat is dan het punt waarop men probeert in te breken? Je ssh poort?
SSH is als protocol weliswaar veiliger, maar het blijft een populaire poort om brute force attacks op los te laten (zwakke wachtwoorden zijn tenslotte de natte droom van elke hacker). Als je je security een beetje op orde hebt (remote root logins zijn niet mogelijk, inloggen met private keys i.p.v. wachtwoorden, etc) dan is de kans dat het lukt klein, maar je logfiles worden best wel groot van alle gelogde pogingen. Om die reden heb ik op mijn eigen server een jaar of 6 geleden SSH naar poort 10022 verhuisd. Sindsdien geen enkele verdachte inlogpoging meer gehad. Op mijn werk heb ik een ander mechanisme ingevoerd: 5x een failed login van een bepaald adres (tenzij van een whitelisted adres) en het adres wordt geblokkeerd via iptables. Daar komt bij dat ik alle servers hun blacklist laat synchroniseren via een centrale database, zodat dat IP-adres meteen (nou ja, binnen 2 minuten) overal wordt geblokkeerd. Tsjakka! ;-)
Van die blacklist-database maak ik trouwens ook dankbaar gebruik in mijn webserver. Heb niet het lef om een request te doen naar /cgi-bin/php of /w00tw00t of zo, want dat levert per omgaande een extra record in de blacklist-database op.
En heb overigens niet de illusie dat als je website veilig is de boel niet meer gehackt kan worden, want ook in de software van je webserver kan nog een security-lek zitten.
Ik moet nog veel leren op dit gebier merk ik al wel...
Plesk is uitgebreider, maar ik vind het onhandig heb er een tijd mee gewerkt maar gelukkig is het bedrijf waar ik werk overgestapt naar DirectAdmin
Dank je voor je reactie. Kun je eens aangeven wat je precies makkelijker vindt aan DirectAdmin? Als ik Plesk met DirectAdmin vergelijk dan ziet DirectAdmin er minder professioneel uit. Nu zegt dat natuurlijk niet alles, en juist daarom ben ik heel benieuwd waarom je de voorkeur geeft aan DirectAdmin.
Je kan veel instellingen aanpassen via Plesk, ook bijvoorbeeld PHP.ini aanpassingen per website, vanuit de interface. Ook onze klanten kunnen goed werken met de Plesk.
Het rechtensysteem is goed in Plesk en ook, mocht je je klanten willen beperken, zitten er goede oplossingen in voor limieten en wat te doen als het limiet behaald wordt (blokkeren, waarschuwing).
Updaten van de server software is volgens mij niet mogelijk binnen Plesk, maar ik moet eerlijk zeggen dat ik mij daar niet mee bezig hou, dat doet onze provider. Webmail is in de laatste versies zowel Horde/IMP als Squirrelmail.