Veel gestelde vragen

Wij raden aan om eerst de relevante dingen uit de 'Quick Start' te lezen.

• SSH en sftp
• FTP

• Waar vind ik de apache acces en error logs?
• Hoe zit de apache logging in elkaar?

• Op basis van IP adress
• Met een wachtwoord
• Https activeren

De rechten van mijn files staan niet goed

• Java: er blijven pagina's in de frontproxy hangen
  • Java: Ik zie de prive sessie van iemand anders

Ja. Indien gewenst kunnen wij hiervoor een mechanisme voor u opzetten op basis van uw opload account en een trucje met ssh. Stel dat uw applicatieserver xxxx01as heet (= de applicatieserver die leeft onder /e/as/xxxx01 dan kunt u, nadat eea opgezet is, uw applicatieserver stoppen/starten door in te loggen op uw opload account en op de shellprompt te typen

ssh stop-xxxx01as
ssh start-xxxx01as

Stel dat het voor een deel van uw applicatie nodig is dat deze via http iets aan zichzelf, of aan een andere applicatie in dezelfde omgeving vraagt: wat is dan de url?

U kunt externe url (bv http://www.groente.nl/boerkenkoolfeed.xml) gebruiken, maar deze gaat via de frontproxy. Het is ook mogelijk de hit direct op tomcat af te vuren. Hiervoor moet u de naam van uw applicatieserver weten. Stel dat deze xxxx01as is, dan draait de applicatieserver altijd op poort 8888 is de url: http://xxxx01as:8888/ Het kan zijn dat in uw applicatieserver virtual hosting aan staat (als dezelfde applicatieserver gebruikt wordt om in verschillende host contexten meerdere applicaties te draaien (bv www.groente.nl en www.fruit.nl in dezelfde applicatieserver)). In dat geval dient uw applicatie een HTTP “Host:” header mee te geven met de juiste virtual host (bv “Host: www.groente.nl”)

De reden is dat MMBase probeert te schrijven in z'n builders directory; dat is niet toegestaan. Vanaf de upload server kunt u de actie (het kopieren van een builder xml) voor MMBase doen.

Liever niet. Wij bieden geen squid aan, omdat testen bij ons hebben uitgewezen dat onder hoge load apache2 beter presteert dan squid. Bovendien gebruiken wij functionaliteit van apache die door squid niet geleverd wordt (https, header rewriting e.d).

Ja, zowel de test- als de productieomgeving worden gebackupped. Van alle databases wordt dagelijks een export gemaakt, en de export wordt samen met alle andere bestanden gebackupped.

In de productieomgeving is een mogelijkheid om zelf restores uit te voeren mbt de NetApp snapshot faciliteit. In de root van elk filesysteem vindt u de situatie zoals deze enkele uren en enkele dagen geleden op het filesysteem was. Om hier weer files uit terug te toveren gaat u als volgt te werk (nadat u ingelogged bent op de upload server. Hieronder een voorbeeld voor het terughalen van het bestand /e/ap/groenteenfruit/web-app/lekker.jsp In onderstaand voorbeeld is het dollar ($) teken uw unix prompt; dat typt u dus niet in.

• Bepaal op welk filesysteem uw bestand lag. Het makkelijkst is in de directory te gaan staan (“cd”) waar het verloren bestand was en “df .” in te gebruiken

$ cd /e/ap/groenteenfruit/web-app
$ df .
Filesystem            Size  Used Avail Use% Mounted on
fs1:/mmc_ro_00        1.0G   80M  944M   8% /d/fs1/ro/00

Kijk in de “Mounted on” kolom en u ziet dat dit filesysteem blijkbaar gemount was op /d/fs1/ro/00

• In de mount directory vindt u de snapshots. Kies de juiste snapshot en cd vanaf daar naar de juiste plek en pluk daar het gewenste bestand weer vandaan:

$ cd /d/fs1/ro/00
$ ls -a
.  ..  ap  as  db  fp  README  .snapshot
$ cd .snapshot
$ ls
hourly.0  hourly.2  hourly.4  nightly.0
hourly.1  hourly.3  hourly.5  nightly.1
$ cd nightly.0
$ ls
ap  as  db  fp  README
$ cd ap/groenteenfruit/web-app
$ cp lekker.jsp /e/ap/groenteenfruit/web-app/lekker.jsp_restored

Zoals beschreven in onze tips voor een schaalbare website; PHP vraagt relatief veel resources per connectie. PHP handelt zijn connecties af via 'workers'. Die workers hebben standaard met PHP een geheugenlimiet, wij kunnen dit geheugenlimiet aanpassen afhankelijk van het aantal workers. Wij delen alles op in instanties die maximaal 2 GB geheugen. Dus het aantal workers keer het geheugenlimiet per worker is totaal 2 GB. Bijvoorbeeld, PHP geeft standaard 64 MB:2048/64= 32 workers De kunst is om hier een goede balans in te maken: genoeg workers om veel verzoeken af te handelen en genoeg geheugen per worker zodat PHP geen fouten geeft.

We zien vaak dat beheer-omgeviningen van CMS'en relatief veel geheugen nodig hebben. Te weinig geheugen geeft foutmeldingen. Als je het geheugen zou bijstellen tot bijvoorbeeld 512MB, houdt je maar 4 workers per PHP instantie over. Je beheeromgeving werkt dan misschien wel, maar als je meer bezoekers krijgt op je website gaat het mis. Dan kun je hetzelfde effect krijgen als met brakke mysql queries; je houdt geen workers meer over voor je bezoekers en die zien dan een foutmelding “502 proxy error”. Dit ligt niet aan de frontproxy maar het komt doordat de proxy zijn request niet meer kwijt kan bij de backend. Alle workers zijn bezet en kunnen geen nieuwe requests meer aan.

In het algemeen heeft een bezoeker op je PHP site niet zoveel geheugen nodig per worker, dus voor de bezoekers wil je het liefste een balans met meer workers en minder geheugen. Wij kunnen voor het beheren van een CMS een apparte php instantie inrichten met relatief veel geheugen en weinig workers. Alle verzoeken /admin op je site worden dan door die instantie afgehandeld. Voor de security is het dan vaak ook een goed idee om iets te doen met IP whitelisting of extra authenticatie d.m.v. digests in te stellen.