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.

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.

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.