Alles dat te maken heeft met de diensten vind je in het filesysteem onder “/e”. Daar is voor elk type dienst een subdirectory, met daaronder alle instanties van die dienst, en daar weer onder de zaken die nodig zijn voor die dienst. Oftwel: alle paden zien er uit als /e/<dienst>/<instantie-naam>/<instantie specifieke zaken>

Dit zijn symlinks/snelkoppelingen voor extra flexibiliteit voor ons als beheerders en overzichtelijkheid voor de websitebouwers/ontwikkelaars. De onderliggende storage laag en daarmee /d/-paden kunnen veranderen maar zolang je gewoon de /e/-paden gebruikt heb je daar geen last van. Sterker nog het is absoluut niet de bedoeling dat paden onder /d/ worden gebruikt in configuratiebestanden of dat hier directe verwijzingen naar zijn in de code. Er zijn een aantal valkuilen waar je op moet letten om dit goed te (blijven) doen.

De bedoeling van de split tussen /e en /d is dat systeembeheerders makkelijk data naar andere filesystemen kunnen schuiven, zonder dat er configuratie in de draaiende applicatie aangepast moet worden. Het zorgt ook voor een centraal 'aanspreekpunt' voor de instanties. Bijvoorbeeld: apache kan met dezelfde configuratie nog steeds de code vinden en zijn logs wegschrijven als het onderliggende /d/pad is veranderd. Zolang de symbolic link maar naar het juiste pad verwijst is er niets aan de hand. Voor de software hebben we een vergelijkbare constructie. Dit is voor een sitebouwer wat minder relevant, maar het staat hier beschreven.

De valkuilen:

Het “locate” commando geeft vaak padnamen terug met /d/. Ook php en diverse ftp clients willen graag symlinks 'dereferencen', waardoor in die hoek ook nog wel eens /d paden zichtbaar willen zijn. Wees hier bedacht op.

De /e/paden zijn dus belangrijk voor websitebouwers en in het bijzonder /e/ap/(naam van je site)/pages. Dit is de documentroot. Een veelgebruikte constructie is om de documentroot pages/current te maken. Hiermee kun je meerdere versies hebben van de site en door een symbolic link te veranderen de versie veranderen die de 'huidige' is en daarmee dus live staat. Alle andere /e/ paden staan hier beschreven.

Subdirectories onder /e/

/e/pad Subdirectory toelichting
/e/{ha,fp,as,db,ml}/<instance>/ log of OLDlog De (gearchiveerde) logfiles van een instantie
/e/{ha,fp,as,db,ml}/<instance>/ conf Configuratiefiles, specifiek voor een instantie
/e/{ha,fp,as,db,ml}/<instance>/ rc De start/stop scripts voor een instantie (onder andere hiermee maken wij van een proces een instantie)
/e/{ha,fp,as,db,ml}/<instance>/ data De data behorende bij een instantie. Denk bijvoorbeeld aan de datafiles van een database of aan de queueing directory van een mailserver.
/e/{ha,fp,as,db,ml}/<instance>/ tmp Temp directory. Kan door de instance gebruikt worden als scratch dir.

Voor applicaties ligt het iets anders; php applicaties hebben een iets andere directory structuur dan java applicaties.

PHP applicaties hebben de volgende structuur onder /e/ap/<applicatienaam>

  • pages

(php applicaties) De document root van een php website. Deze is standaard php-enabled; maar -niet- schrijfbaar voor de webserver. Files hebben standaard als groep 'cw<naampje>'; zodat verschillende uploaders (bijvoorbeeld een omroep samen met een externe webbouwer) schrijfrechten hebben op de files. Belangrijk daarvoor is dat files mode 0664 hebben, en directories 2775. Dit valt prima te bereiken door een 'umask 002' in je .profile neer te zetten.

  • data

De plek waar een applicatie z'n data kan wegschrijven. Deze directory wordt direct via de proxy-webserver uitgeserveerd. Het zelfde rechtenverhaal gaat hier ook op, behalve dan dat de bestanden en directories allemaal lid zijn van een 'dw<naampje>'-groep. Hierin zitten dezelfde mensen als in het 'cw<naampje>'-groepje, maar de webservers die data weg mogen schrijven zijn hier ook aan toegevoegd.

  • config

Hier kunnen config bestanden geplaatst worden. Deze directory zit in het php include path. Bijvoorbeeld de database parameters zijn hier altijd terug te vinden, maar ook allerlei php-code valt hier te plaatsen die niet in de docomentroot hoeft te staan (denk aan generieke classes, libraries, etcetera). Ook deze directory is niet schrijfbaar voor de webserver. Wat betreft de rechten geldt hier hetzelfde als onder /pages.

Tot slot hebben we nog

  • /home/omroep/<accountnaam>

De unix home directory van het upload-account genaamd <accountnaam>. Dit is de plek waar je binnenkomt als je inlogt. Als dit upload account bedoeld is voor het uploaden van applicatie X, dan zal er in de home directory vaak een verwijzing (symlink) naar applicatiedirectory X, dwz /e/ap/X gemaakt worden.

In onze omgeving maken wij onderscheid tussen read-only en read-write filesystemen. Voor de read-only filesystemen geldt dat deze vanaf de web, applicatie en database servers niet gewijzigd kunnen worden. Deze filesystemen worden gebruikt om de uitvoerbare delen en de configuratie van applicaties op te slaan.

In onze omgeving is het zo dat alle web-app en pages directories op read-only filesystemen liggen. Verder ligt alle configuratie (frontproxy, database, applicatieserver) op een read-only filesysteem. De read-write filesystemen worden alleen gebruikt voor logfiles, temp-directories en databases.

De reden hiervoor is dat als een site gehacked wordt, het voor de hacker onmogelijk is om b.v. jsp of php files te wijzigen. Concreet houdt dit in dat bij een geslaagde hack poging de applicatie zichzelf niet kan wijzigen (op instigatie van de hacker), en dat het dus bijzonder moeilijk zal zijn om b.v. aan de database inhoud te komen.

Dit houdt in dat het voor applicaties dus niet mogelijk is om self-modifying code te gebruiken (bv een PHP die een nieuwe versie van zichzelf neerzet). Bij sommige Content Management Systems betekent dat dat het niet mogelijk is om via het web-interface -zeg- extenties te installeren. (want daarvoor moet de webserver kunnen schrijven in z'n eigen docroot en dat mag dus niet in onze omgeving). Zelfs als u bijvoorbeeld “chmod 777” (= unix speak voor world writable) op een php bestand zou doen, dan nog is het niet te wijzigen vanaf een applicatieserver, omdat het op een filesysteem staat dat niet schrijfbaar is voor de applicatie servers.

De enige plek vanaf waar naar de read-only filesystemen geschreven mag worden is de upload server. Da's ook nodig, anders zouden er b.v. nooit nieuwe php bestanden geplaatst kunnen worden.

Indien het toch gewenst is om via het CMS wel dit soort acties te doen, dan kunnen wij in zo'n geval een zgn “admin server” inrichten. Dit is een webserver die op een upload server draait en dus wel mag schrijven in code directories. Wij zorgen ervoor dat deze webserver afgeschermd is van de buitenwereld, zodat het toch veilig blijft.

  • sterretje-cluster/cluster-hosting_filesystem-layout.txt
  • Last modified: 2019/04/26 10:34
  • (external edit)