12:08
Scripting algemeen
- Wat is server-side scripting?
- Welke zijn de meest gebruikte programmeertalen voor server-side scripting?
- Heb ik mijn eigen cgi-bin directory voor het plaatsen van mijn scripts?
- Moeten scripts in de cgi-bin directory worden geplaatst?
- Wat is het verschil tussen "een cgi-bin" en "een cgi-bin directory"?
- Waar vind ik de handige scripts die gratis bij mijn account zijn meegeleverd?
- Waar vind ik meer scripts en handleidingen?
- Hoe vind ik de absolute padnaam van mijn account?
- Wat is het pad naar sendmail?
- Hoe vind ik het pad naar een bepaald programma?
- Welke extensies moeten mijn scripts hebben?
- Kan ik scripts in shell-script schrijven?
- Onder welke gebruikersnaam worden cgi-bins uitgevoerd?
- Onder welke gebruikersnaam worden PHP-scripts uitgevoerd?
- De tijd die mijn script weergeeft klopt niet. Wat doe ik verkeerd?
- Hoe komt het dat bij de overgang van winter- naar zomertijd mijn klok soms gedurende enkele dagen een uur achterloopt?
- Mijn script werkt niet. Kunt u mij helpen?
- Mijn script draait dol. Hoe verbreek ik de vicieuze cirkel?
- Hoe worden de servers beveiligd tegen doldraaiende scripts?
- Moet ik me met de Reaper dan geen zorgen meer maken over slecht geschreven scripts?
- Hoe merk ik dat de Reaper een script heeft gedesactiveerd?
- Wat moet ik doen als de Reaper de permissies van mijn script heeft gewijzigd?
- Hoe controleer ik de CPU-belasting van mijn scripts?
- Mag ik processen in de achtergrond of background laten draaien?
- Sommige scripts beweren een "setuid-bit" nodig te hebben. Hoe zit dat?
- Ondersteunt One2Web ook ASP of ASP.NET op zijn webhosting-accounts?
- Ondersteunt One2Web ook Java of Tomcat op zijn webhosting-accounts?
- Ondersteunt One2Web ook HTA op zijn webhosting-accounts?
- Kan ik met zo'n serverspecificaties niet wat meer permitteren dan op andere webservers?
- Hoe installeer ik een gedownload script?
- Waar moet ik vooral op letten bij de installatie van een gedownload script?
1. Wat is server-side scripting?
Server-side scripting is een techniek waarbij invoer van webpagina's op de webserver wordt verwerkt en nadien kan worden weergegeven via de browser van de bezoeker. Er wordt dus geen gebruik gemaakt van de processor van de computer van de bezoeker van die website.
Zo kan men interactieve websites bouwen, shopping carts, database-applicaties en nog veel meer.
De voordelen van server-side scripting zijn legio: een foute verwerking t.g.v. de computer van de bezoeker is quasi onmogelijk, de computer van de bezoeker wordt niet belast en compatbiliteitsproblemen worden vermeden.
2. Welke zijn de meest gebruikte programmeertalen voor server-side scripting?
De meest gebruikte programmeertalen voor server-side scripting zijn (in volgorde van belangrijkheid): Perl, PHP, ColdFusion, ASP, Java, C, Miva en Python. De meest performante daarvan worden door One2Web ondersteund.
3. Heb ik mijn eigen cgi-bin directory voor het plaatsen van mijn scripts?
U hebt de beschikking over uw eigen cgi-bin directory, die de naam "cgi-bin" heeft en in zich in uw "public_html" directory op uw account bevindt.
4. Moeten scripts in de cgi-bin directory worden geplaatst?
Dit mag, maar is niet noodzakelijk om ze vanop het web te kunnen aanroepen. Traditioneel werden scripts vroeger altijd in dergelijke directory geplaatst, maar vandaag de dag heeft dat geen enkele concrete noodzaak meer. U mag uw scripts om het eender waar in uw public_html directory of een subdirectory plaatsen. U kan de cgi-bin directory zelfs wissen indien u dat wenst.
5. Wat is het verschil tussen "een cgi-bin" en "een cgi-bin directory"?
De afkorting "cgi-bin" staat voor Common Gateway Interface BINary. Het eerste gedeelte slaat op het standaardprotocol voor webapplicaties; het tweede gedeelte slaat op het feit dat dergelijke webapplicaties historisch gezien veelal gecompileerde binaire bestanden waren (doorgaans in C geschreven), in tegenstelling tot de interpreted scripting-talen van vandaag.
"Een cgi-bin" is dus een webapplicatie (om ingevoerde gegevens te verwerken of om dynamisch gegenereerde inhoud te produceren), en "een cgi-bin directory" is dan de map binnen het bestandssysteem van de klant waar dergelijke applicaties kunnen geplaatst worden.
Sommige providers beweren dat hun klanten "een eigen cgi-bin" hebben, waarbij men dan verkeerdelijk "bin" verklaart als Engels voor bak of mand, zoals bij "Recycle Bin" (prullenmand). Dit is een fundamenteel misverstand dat jammer genoeg hardnekkig verderleeft.
6. Waar vind ik de handige scripts die gratis bij mijn account zijn meegeleverd?
U vindt die scripts allemaal terug in uw Control Panel, voorzien van een automatische installatie- en configuratiemogelijkheid, evenals alle informatie en links naar de handleidingen.
Let er wel op dat u deze scripts enkel binnen uw account mag gebruiken en de gebruiksaanwijzingen correct dient op te volgen.
7. Waar vind ik meer scripts en handleidingen?
Indien u zelf geen scripts wenst te schrijven, dan kunt u veel interessante scripts in verschillende programmeertalen terugvinden in on-line bibliotheken. Sommige cgi-scripts zijn gratis, voor andere dient betaald te worden. U vindt er ook interessante handleidingen en tips.
CGI Resource Index
Matt's Script
Archive
CGI Script Center
CGI World
Enkele van de betalende scripts vindt u gratis terug in uw Control Panel (enkel voor eigen gebruik).
8. Hoe vind ik de absolute padnaam van mijn account?
De absolute padnaam van uw account is "/home/gebruikersnaam/", waarin u "gebruikersnaam" vervangt door uw correcte gebruikersnaam. Uw website bevindt zich in de subdirectory public_html, met de absolute padnaam "/home/gebruikersnaam/public_html/".
Voor deze laatste padnaam kunt u in uw cgi-bins ook de environmentvariabele DOCUMENT_ROOT gebruiken. In Perl wordt dit bijvoorbeeld:
$wwwroot = $ENV{'DOCUMENT_ROOT'};
Deze laatste methode verdient de voorkeur omwille van de algemene geldigheid ervan.
9. Wat is het pad naar sendmail?
Het pad naar sendmail is "/usr/bin/sendmail".
10. Hoe vind ik het pad naar een bepaald programma?
U kunt vanuit Telnet of SSH daarvoor het "whereis" commando gebruiken. Wilt u bijvoorbeeld het pad naar "grep" vinden, dan tikt u gewoon "whereis grep" in.
11. Welke extensies moeten mijn scripts hebben?
Afhankelijk van de taal waarin uw scripts geschreven werden, dienen ze een bepaalde extensie te hebben. Voor Perl is dit bijvoorbeeld ".pl". U kunt ook het meer algemene ".cgi" gebruiken. Meer informatie vindt u in uw Control Panel.
Indien uw script de correctie extensie heeft, dan wordt het tijdens het uploaden via FTP van de correcte permissies voorzien, zodat het door Apache wordt uitgevoerd wanneer het over het web wordt aangeroepen, in plaats van de broncode weer te geven zoals bij een tekstbestand.
12. Kan ik scripts in shell-script schrijven?
Om veiligheidsredenen wordt het uitvoeren van shell-scripts niet ondersteund. U kunt uw scripts wel in Perl schrijven, zowel voor gebruik als cgi-bin als voor gebruik vanop de command prompt. PHP scripts draaien enkel onder de webserver.
In Perl kunt u wel Unix-commando's uitvoeren met omgekeerde enkele aanhalingstekens (backticks) zoals bijvoorbeeld `commando` en op die manier zelfs een Perl script schrijven dat enkel uit Unix-commando's bestaat.
13. Onder welke gebruikersnaam worden cgi-bins uitgevoerd?
Bij Unix hebben alle processen een eigenaar: diegene die het proces heeft opgestart. Bij cgi-bins die over het web worden aangeroepen is dat anders: daar hebben de aangroepen processen meestal geen specifieke eigenaar.
In tegenstelling tot de meeste providers worden bij One2Web cgi-bins niet uitgevoerd onder de gebruikersnaam van de webserver (meestal "nobody"), maar wordt er een licht aangepaste versie van suEXEC gebruikt om de cgi-bins te laten draaien onder de userid van de account waarin zij geplaatst werden.
14. Onder welke gebruikersnaam worden PHP-scripts uitgevoerd?
Indien u de PHP-variant gebruikt die in de Apache webserver is ingecompileerd (zie uw Control Panel), dan draaien uw scripts onder de gebruikersnaam van de webserver, zijnde "nobody".
15. De tijd die mijn script weergeeft klopt niet. Wat doe ik verkeerd?
De tijdzone van al onze servers is ingesteld op Central Time. Concreet komt het erop neer dat u bij de gegeven tijd 7 uur dient te tellen om onze Midden Europese Tijd te bekomen. Hou hier best rekening mee indien u scripts schrijft die tijdstippen weergeven of verwerken.
16. Hoe komt het dat bij de overgang van winter- naar zomertijd mijn klok soms gedurende enkele dagen een uur achterloopt?
De aanpassing van winter- naar zomertijd en omgekeerd gebeurt volautomatisch op al onze servers. Door de gebruikte software-implementatie kan het uitzonderlijk gebeuren dat de overgang van winter- naar zomertijd pas enkele dagen later in werking treedt dan verwacht.
17. Mijn script werkt niet. Kunt u mij helpen?
Alle programmeertalen zijn correct geïnstalleerd op onze servers. Indien u de informatie in het Control Panel en de Knowledge Base hebt nagelezen en juist hebt toegepast, dan zit er wellicht een bug in uw script.
One2Web biedt echter geen programmeerhulp aan. Het is de taak van de klant om zijn scripts te debuggen. In de rubriek over Perl kunt u eventueel een aantal tips vinden die ook op uw gebruikte programmeertaal van toepassing zijn.
18. Mijn script draait dol. Hoe verbreek ik de vicieuze cirkel?
Log meteen in via Telnet of SSH en voer het commando
ps -u gebruikersnaam
uit, waarin u "gebruikersnaam" vervangt door uw correcte gebruikersnaam. U krijgt een lijst met procesnummers en hun bestandsnaam. Zoek de lijn waar het dolgedraaide script in voorkomt, bijvoorbeeld "29983 pts/6 0:00 dolscript.pl": het eerste getal is het procesnummer. Voer dan in dit geval het commando
kill -9 29983
uit, in de veronderstelling dat 29983 het procesnummer van het script in kwestie is. Hiermee hebt u het script gestopt, in de veronderstelling dat het niet opnieuw vanop het web wordt aangeroepen.
U kunt ook trachten het script in kwesite te wissen door vanuit Telnet of SSH het commando "rm script.cgi" uit te voeren, in de veronderstelling dat u zich in de juiste directory bevindt en dat script.cgi de naam van het script in kwestie is. Nadien kunt u een vorige versie terug uploaden, waarvan u zeker bent dat die foutloos draaide.
Vooral voor PHP-scripts die draaien onder de versie die in de Apache webserver is ingecompileerd - en dus onder de gebruiker "nobody" draaien - is deze laatste methode aangewezen.
Gelieve er bijzonder op te letten geen eindeloze lussen in uw scripts te creëren, want scripts die de server hinderen in zijn normale werking kunnen er in extreme gevallen voor zorgen dat uw account wordt geschorst of zelfs afgesloten.
19. Hoe worden de servers beveiligd tegen doldraaiende scripts?
Onze servers worden automatisch beveiligd tegen ontspoorde scripts door een zogenaamde Reaper. Dit programma zoekt naar scripts die teveel processortijd gebruiken of waarvan teveel exemplaren tegelijkertijd draaien, en desactiveert die indien nodig.
In het geval dat uw script de server dusdanig zwaar belast dat de systeemprogrammatuur nog nauwelijks kan draaien, kunnen wij uw account tijdelijk schorsen of zelfs definitief afsluiten.
Let wel: indien u de PHP-variant gebruikt die in de Apache webserver is ingecompileerd, dan bestaat er geen enkele automatische bescherming tegen eventuele overbelasting door uw PHP-scripts. Gelieve in dat geval steeds op uw hoede te zijn voor scripts die u ergens vandaan haalt of voor bugs in eigen fabrikaat.
20. Moet ik me met de Reaper dan geen zorgen meer maken over slecht geschreven scripts?
Toch wel. De Reaper is een automatisch mechanisme dat in extreme gevallen - voornamelijk bij Perl scripts - verhindert dat een ontspoord script op uw account de dienstverlening aan de andere klanten in gevaar zou brengen. Het is echter geenszins een allesomvattende beveiliging tegen menselijke slordigheid. Het blijft dus steeds aangewezen om op een verantwoorde manier te programmeren en oordeelkundig om te springen met installatie van allerhande software, zelfs als die van gereputeerde bronnen komt.
21. Hoe merk ik dat de Reaper een script heeft gedesactiveerd?
Doorgaans merkt u dat de Reaper een script heeft gedesactiveerd door de permissies te wijzigen, zodat het niet meer kan uitgevoerd worden.
22. Wat moet ik doen als de Reaper de permissies van mijn script heeft gewijzigd?
Indien de permissies van een script werden gewijzigd zonder uw toedoen, dan heeft de Reaper naar alle waarschijnlijkheid uw script gedesactiveerd omdat het ernstig ontspoorde en de server ontoelaatbaar zwaar belastte.
U dient dan eerst het script en de manier waarop het wordt aangeroepen grondig na te kijken vooraleer u tracht het opnieuw te activeren door de permissies te corrigeren.
In geen geval mag u zomaar de permissies terugzetten. Scripts die herhaaldelijk werden gedesactiveerd omdat ze ontspoorden, en door u zonder meer weer opnieuw werden geactiveerd of geupload, kunnen ertoe leiden dat uw account tijdelijk wordt geschorst of definitief wordt afgesloten.
23. Hoe controleer ik de CPU-belasting van mijn scripts?
U kunt de CPU-belasting van uw scripts nagaan via het "top" commando dat u via Telnet of SSH uitvoert. U krijgt dan een overzicht - dat elke vijf seconden wordt hernieuwd - van de totale belasting van de server waarop uw account is geplaatst, alsook een lijst van de meest belastende processen die door u of uw scripts werden opgestart. U stopt de weergave door op Q te drukken.
Als goede maatstaf zorgt u er best voor dat processen de serverload niet plots merkelijk doen stijgen. Een efficiënt geschreven script zal slechts een fractie van een procent van het CPU-vermogen in beslag nemen gedurende een fractie van een seconde, en de algemene serverbelasting (load average) niet plots de hoogte doen ingaan.
24. Mag ik processen in de achtergrond of background laten draaien?
U mag onder geen beding programmatuur in de achtergrond (background) laten draaien, zoals services, bots, daemons of andere processen. Onoordeelkundig gebruik hiervan zou makkelijk kunnen leiden tot een onaanvaardbare overbelasting van de server, waardoor de dienstverlening aan de andere klanten in het gedrang komt.
Het niet naleven van deze richtlijn kan de tijdelijke of definitieve schorsing van uw account tot gevolg hebben.
25. Sommige scripts beweren een "setuid-bit" nodig te hebben. Hoe zit dat?
Het setuid-bit van een Unix executable is een uitbreiding van de klassieke chmod, waarbij een attribuut wordt aan- of uitgezet dat bepaalt dat een programma of script onder de gebruikersnaam en bijhorende privileges moet worden gedraaid van zijn eigenaar indien het wordt aangeroepen door bijvoorbeeld de webserver.
Bij de doorsnee configuratie van een webserver worden scripts en andere webapplicaties aangeroepen met de gebruikersnaam en privileges van de webserver, meestal "nobody". One2Web gebruikt een aangepaste versie van suEXEC om deze processen daarentegen te laten draaien onder de gebruikersnaam van de klant.
Het gebruik van een zogenaamd "setuid-bit" is dus onnodig: scripts die vanop uw website worden aangeroepen, draaien reeds onder uw gebruikersnaam en Unix-privileges. Scripts van klanten draaien om veiligheidsredenen nooit als root-user.
De enige uitzondering hierop zijn PHP-scripts die draaien onder de versie die in de Apache webserver is ingecompileerd: deze draaien onder de username van de webserver, namelijk "nobody".
26. Ondersteunt One2Web ook ASP of ASP.NET op zijn webhosting-accounts?
Aangezien wij gekozen hebben voor een zuivere Unix-oplossing (Sun Solaris), wordt ASP of ASP.NET op onze pakketten niet ondersteund. We hebben destijds geëxperimenteerd met ChiliSoft ASP voor Solaris, maar zonder volledig bevredigende resultaten.
Alhoewel Microsoft zijn product ASP sterk promoot - voornamelijk naar studentenopleidingen toe en uitsluitend met de bedoeling om Microsoft besturingssystemen en webserver-software sterker te positioneren - is de aanhang onder programmeurs vrij beperkt. Een standaard is het bijlange niet.
U kunt uiteraard wel gebruik maken van het performante Perl of het zeer populaire PHP voor uw scripting, wat veel efficiënter en stabieler is dan ASP. Zelf kiezen we voor het ontwerp van webapplicaties ook steeds voor Perl, net zoals vele grote bedrijven, universiteiten en instellingen.
27. Ondersteunt One2Web ook Java of Tomcat op zijn webhosting-accounts?
One2Web ondersteunt momenteel geen Java of Tomcat op zijn webhosting-accounts. Alhoewel Java door veel programmeurs wordt gesmaakt (meestal voor applicaties buiten server-side scripting), is het bij een Tomcat-opstelling steeds mogelijk dat een ondoordacht geschreven programma de server doet doldraaien of de dienstverlening aan de andere klanten in gevaar brengt. Bij de traditonele scripting-talen zoals Perl wordt deze situatie tegengegaan door een Reaper die processen killt die teveel CPU-tijd in beslag nemen; bij Java ligt dat bij onze specifieke server-opstelling iets moeilijker.
Sommige providers beweren wel Tomcat aan te bieden, maar maken eigenlijk dezelfde bedenkingen: bij nadere inspectie blijken bepaalde onderdelen echter fake te zijn.
28. Ondersteunt One2Web ook HTA op zijn webhosting-accounts?
One2Web ondersteunt Microsoft HTA (HTML Application) op zijn webhosting-accounts. Het enige wat u hoeft te doen, is een tekstbestand aanmaken in de "public_html" directory van uw account met de naam ".htaccess" en hierin deze twee lijnen opnemen:
DirectoryIndex index.shtml index.htm index.html index.hta
AddType application/hta .hta
Daarnaast dient u ervoor te zorgen dat uw bezoekers werken met Microsoft Internet Explorer (minimum versie 5) en de Microsoft HTML Application Host doorlaten in hun firewall.
29. Kan ik met zo'n serverspecificaties niet wat meer permitteren dan op andere webservers?
Het gebruik van krachtige servers van Sun Microsystems kan uiteraard de stabiliteit en performantie van uw website alleen maar ten goede komen.
Soms wordt de kracht van onze Sun Enterprise servers echter gezien als een vrijgeleide om zeer processor-intensieve applicaties te draaien. Men vergeet echter vaak dat er op de server - afhankelijk van het gekozen pakket - nog tussen 174 en 749 andere klanten actief zijn die dat misschien ook denken. Bovendien kan een bottleneck snel verergeren in de tijd.
Wenst u echt de performantie van een dedicated server zonder het bijhorende prijskaartje, dan kan u opteren voor onze Corporate Hosting Account, waar slechts 20 klanten per server worden geplaatst.
30. Hoe installeer ik een gedownload script?
Gelieve de handleiding van het script in kwestie of de website van de makers ervan te consulteren voor de correcte installatie ervan.
Wij kunnen helaas geen handleidingen van alle mogelijke externe scripts bijhouden en bijwerken: daarvoor veranderen die versies veel te snel. Indien u zelf programmatuur installeert (ook al hebt u die zelf niet geschreven), dan is het uw taak om die aan de praat te krijgen.
31. Waar moet ik vooral op letten bij de installatie van een gedownload script?
Indien u een webapplicatie van het internet haalt om te installeren op uw webhosting-account, dan dient u met volgende punten rekening te houden:
1. Installeer nooit beta-software, want deze is nog in ontwikkeling en bevat gegarandeerd nog programmeerfouten die eventueel ernstige gevolgen kunnen hebben. Beta-software is meestal herkenbaar aan de letter b in het versienummer. Opteer daarentegen steeds voor stabiele en geteste releases.
2. Alhoewel het enerzijds voordelig lijkt om volledig gratis scripts te downloaden die u anders zelf had moeten schrijven, hebt u anderzijds geen flauw idee hoe de applicatie in elkaar steekt en of ze geen verborgen tekortkomingen heeft qua stabiliteit en veiligheid. Grondig nakijken is dan ook de boodschap.
3. De vele gratis scripts die u op het Internet kunt terugvinden, zijn vaak degelijk geschreven. Jammer genoeg betekent gratis meestal ook dat er geen ondersteuning is van de auteur wanneer er wel een probleem zou opduiken.
4. Soms ontwikkelt de auteur zijn applicatie op een dedicated server (bijvoorbeeld voor zijn eindwerk op een hogeschool of universiteit) en gaat er dan verkeerdelijk van uit dat alles zonder aanpassing op een shared server webhosting-pakket met een ander besturingssysteem en webserver-software (en heel wat meer gebruikers/bezoekers) even feilloos zal functioneren en maar evenveel belasting zal veroorzaken. Afhankelijk van de programmeerstijl van de auteur kan dit verwaarloosbare tot ernstige problemen veroorzaken.
5. Sommige Content Management Systemen (CMS) zijn berucht voor het overmatig belasten van de server - wat nadelig is voor de andere klanten op dezelfde server - omwille van de overdaad aan toeters en bellen. Sommige zijn specifiek bedoeld voor een shared hosting environment (zoals uw webhosting-account), andere draaien dan weer best helemaal alleen op een dedicated server (zeker als er vele gebruikers tegelijkertijd gebruik van maken), maar jammer genoeg wordt dat onderscheid niet altijd even duidelijk aangegeven.
6. Uiteindelijk vallen de gevolgen van programmatuur die u zelf installeert steeds onder uw verantwoordelijkheid, ongeacht of u het script in kwestie zelf geschreven hebt of niet. Slecht geprogrammeerde webapplicaties die onder bepaalde omstandigheden de server overbelasten, kunnen resulteren in een tijdelijke of definitieve schorsing van uw webhosting-account, afhankelijk van de ernst, de hoeveelheid en de frequentie van de incidenten.
