Differences

This shows you the differences between two versions of the page.

Link to this comparison view

sterretje-cluster:cluster-hosting_filesystem-layout [2020/03/06 07:53] (current)
Line 1: Line 1:
 +===== Filesysteem layout: /e en /d =====
 +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. 
 +
 +
 +
 +{{:​sterretje-cluster:​d-paden-e-paden.png|}}
 +
 +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 [[sterretje-cluster:​cluster-hosting_local-en-software|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 [[sterretje-cluster:​cluster-hosting_layout-e-paden|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.
 +
 +===== Read-only en Read-write filesystemen =====
 +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: 2020/03/06 07:53
  • (external edit)