Hvor skal web-kode leve?

Goddag alle og enhver
Jeg har en smule svært ved at afgøre, hvor jeg dels skal placere min python django kode og dels det statiske indhold for en webside (billeder, css) i filsystemet. Jeg bruger Debian Linux og Apache webserveren.

1. En VirtualHost er konfigureret til at servere det statiske indhold, men hvad skal DocumentRoot sættes til for denne? Jeg synes ikke rigtigt det giver mening at bruge /var/www, da indholdet sjovt nok ikke er specielt varierende. Hvorfor er www egentlig i det hele taget placeret under /var? Hvordan ville man gøre i et stort production setup (antaget, at de gør det på den rigtige måde dér)

2. Yderligere en VirtualHost er konfigureret med et ScriptAlias (mod_wsgi) til at køre python-koden uden for DocumentRoot. Django-projektet selv foreslår /home/???, men jeg synes det virker lidt ulogisk at placere koden dér. Hvad skal DocumentRoot i øvrigt være for denne VirtualHost? Så vidt jeg kan se, skal DocumentRoot ikke bruges til ret meget her.

Håber I kan hjælpe mig med dette
Mange hilsner...

Tukanfan (1) skrev:

Hvorfor er www egentlig i det hele taget placeret under /var?

For at du nemt kan redigere filerne. /var er et af de få directories som absolut skal være mountet read/write.

Hvordan ville man gøre i et stort production setup (antaget, at de gør det på den rigtige måde dér)

De store produktions setups jeg har arbejdet med har ikke anvendt apache. (Ikke at der er noget galt med at bruge apache til den slags, jeg har bare tilfældigvis ikke haft noget med store apache systemer at gøre).

Når du siger stort går jeg ud fra, at du mener du har en håndfuld maskiner med apache, som alle skal servere de samme filer. Det første du skal gøre dig op er hvor du vil opbevare din master kopi, og hvordan du vil sikre dig mod datatab. Du skal også gøre op, hvordan du vil distribuere filerne til de enkelte maskiner. Når du har fundet svarene på de spørgsmål, så kommer svaret på dit oprindelige spørgsmål muligvis af sig selv.

Er det et system hvor mange forskellige parter let skal kunne opdatere hver deres virtual host? Eller er det et system, hvor du kun selv skal opdatere filerne. Du kan lægge filerne i en deb eller rpm pakke og installere den på hver server. Men, jeg er ikke sikker på, hvor mange servere man skal op på, før det vil kunne betale sig.

Det eneste der skal være offenlig tilgængeligt er dit statiske indhold (CSS/Billeder/JavaScript), og en bootstrapper for Django.

Resten af koden, og alt andet indhold, bør du sørge for ikke ligger i din public dir.

Tak for svar, begge af jer
Mit problem er ikke så meget, at jeg ikke ved hvordan services sættes op, inklusiv diverse sikkerhedshensyn der skal tages ifm. hver af disse. Udfordringen er nærmere, hvordan man gør det og samtidig følger Linux FHS-guidelines. Jeg kan se, at /var/www er meget smart til shared hosting løsninger, hvor alle filer blandes sammen i én mappe. Så vidt jeg kan se, har denne løsning dog 2 ulemper:

1. Man skal være meget obs på, at webserveren kan kende forskel på kode og ikke-kode, så den ikke serverer source

2. Det er kompliceret at få én webserver(proces) til at servere statisk indhold, og en anden til at eksekvere kode via WSGI fra samme mappe. Man kan f.eks. heller ikke flytte den statiske del over på en anden maskine, med dette setup.

Så, hvad gør man? Koden kan vel placeres i /usr/lib/?. Det statiske indhold har jeg dog lidt sværere ved at se, hvor skal ligge. Givet at man har en dedikeret medie-server, hvor ville man placere det? Benytte /srv/www eller måske oprette en ny mappe i /.

Tukanfan (4) skrev:

Koden kan vel placeres i /usr/lib/?

Jeg ville holde mig fra /usr/lib. Hvis du synes det bør ligge under /usr og du ikke har tænkt dig at bruge systemets pakkemanager til det, så læg det under /usr/local.

#5 Ah ja, selvfølgelig

Tukanfan (4) skrev:

2. Det er kompliceret at få én webserver(proces) til at servere statisk indhold, og en anden til at eksekvere kode via WSGI fra samme mappe.

Selv om man har både statisk og eksekverbart kode i /var/www, behøver det jo ikke at være i samme undermappe.

Jeg brugte "/var/www". Under den mappe havde hvert projekt sin undermappe. Og derunder var diverse undermapper, hvoraf én af dem var public. Fx:

/var/www/myplace.dk/public
/var/www/myplace.dk/wordpress

wwwroot er så public-mappen, og der er alt hvad browseren skal kunne se. Der kan godt være lidt serverside-kode, men ikke noget "farligt". Ikke meget mere end kald til kode uden for public-mappen.

Hvis du vil dele det mere op, kan du vel tilføje en "static"-mappe ved siden af "public", og det fanger du så på et subdomæne eller hvad du nu har lyst til.

På en server med flere projekter kan jeg godt lide at holde det samlet i én mappe, og så have projektets dele splittet i undermapper.

Har du så mounted /var/www på samme volume? Jeg kan forestille mig, at et produktionsmiljø har static mounted på NFS eller lign, mens et shared hosting miljø har det hele mouted lokalt.

Tukanfan (8) skrev:

Har du så mounted /var/www på samme volume?

Om hele /var/www er i ét filsystem? Ja.

Tukanfan (8) skrev:

Jeg kan forestille mig, at et produktionsmiljø har static mounted på NFS eller lign

Altså et miljø med flere servere pr. site, frem for flere sites pr. server?
Der ville jeg kopiere static content ud til alle serverne.

#9

Der findes endda tools som kan automatisere kopieringen, så man undgår små hovsa'er.

#10
Heh, jeg ville være MEGET ked af at håndtere den slags manuelt. Jeg gjorde det ikke engang da jeg havde én produktionsserver. :-D

myplacedk (9) skrev:

Om hele /var/www er i ét filsystem? Ja.

Men er det ikke lidt dumt at have /var/www på samme filsystem som f.eks. /var/log? Tænker på, at de statiske filer kan være ret store, mens logfilerne er meget små ofte.

myplacedk (9) skrev:

Tukanfan (8) skrev:

Jeg kan forestille mig, at et produktionsmiljø har static mounted på NFS eller lign

Altså et miljø med flere servere pr. site, frem for flere sites pr. server?
Der ville jeg kopiere static content ud til alle serverne.

Okay

Tukanfan (12) skrev:

Tænker på, at de statiske filer kan være ret store, mens logfilerne er meget små ofte.

Jeg er vant til at statiske filer er på ganske få KB, hvis da ikke under 1.
Og at logfiler er på adskillige MB. Dvs. som generel regel er det svært at sige noget om.

I øvrigt skulle et moderne filsystem kunne håndtere det fornuftigt. Jeg er ret sikker på at du skal ud i en noget specialiceret situation, før det med små og store filer betyder noget.

Jeg ville nok splitte det op af andre årsager før det. Fx. skal systemet jo helst ikke stoppe med at logge, bare fordi en hjemmeside pludselig fylder for meget, og der ikke er mere ledig plads.

Men der er jo ingen som siger at hele /var skal være i samme filsystem. Du kan godt have /var/log eller /var/www i sit eget filsystem. Eller begge dele i hver sit, og /var i et tredje.

myplacedk (13) skrev:

Jeg er vant til at statiske filer er på ganske få KB, hvis da ikke under 1.

HTML, CSS, JS etc. må formodes at være ganske småt.

Men hosting af software download, video download etc. er normalt ret stort.

myplacedk (13) skrev:

Og at logfiler er på adskillige MB.

Det må de være ellers er trafikken minimal.

myplacedk (13) skrev:

Fx. skal systemet jo helst ikke stoppe med at logge, bare fordi en hjemmeside pludselig fylder for meget, og der ikke er mere ledig plads.

Det er jo lidt en skam at der ikke er noget filsystem som kan håndtere dette uden at man skal opdele sin disk i flere filsystemer. Det ville jo være smart om man kunne lave kvoter på specifikke directories og angive at der skal reserveres minimum xGB til dette directory og hvis man når det når op på yGB skal der raporteres at pladsen er brugt op uanset hvor meget fri plads der i øvrigt er på disken.

Hvis filsystemet kunne dette, så ville det give alle fordelene fra at have flere partitioner, og det det er mere fleksibelt. F.eks. kan man angive et interval fremfor et fast antal GB, og man kan ændre det efterfølgende uden at skulle repartitionere.

Grunden til at det er svært at lave sådan en feature i et filsystem er, at det er næsten umuligt at få en meningsfyldt semantik når man har hardlinks imellem to directories under forskellig kvote. Men da man i forvejen ikke bruger hardlinks så meget, så er det en skam at den detalje forhindrer sådan en praktisk feature i at blive implementeret.

myplacedk (13) skrev:

Jeg ville nok splitte det op af andre årsager før det. Fx. skal systemet jo helst ikke stoppe med at logge, bare fordi en hjemmeside pludselig fylder for meget, og der ikke er mere ledig plads.

Det har du ret i. Jeg formoder det også vil være en god idé, at mounte /var/spool/mail på et separat filsystem for en sikkerheds skyld.

LVM kan vel bruges til at allokere diskplads til de forskellige brugere, selvom det ikke er så let at resize.

Er der desuden nogen af jer, der har brugt /srv til noget?

kasperd (15) skrev:

Det er jo lidt en skam at der ikke er noget filsystem som kan håndtere dette uden at man skal opdele sin disk i flere filsystemer.

Huh? Da jeg legede plads på webhoteller plejede der ca. altid at være et quota-system der gjorde noget i den stil. (Vist nok Linux på dem alle.)

Jeg har aldrig sat mig ind i hvordan det egentlig fungerer. Men set fra brugerens (min) side fungerede det desværre altid som det skulle.

myplacedk (17) skrev:

Da jeg legede plads på webhoteller plejede der ca. altid at være et quota-system der gjorde noget i den stil.

Det fungerer mig bekendt altid på bruger ID og altså ikke på directory.

Hvis du har et filsystem til hele systemet kan kvote systemet f.eks. ikke se forskel på om dine filer ligger i /tmp eller /home, men det gør ofte en stor forskel fordi filer i /home også kræver plads til backups, hvilket filer i /tmp ikke gør.

Hvis du har adgang til at lave hardlinks kan der også opstå interessante situationer. Tag f.eks. følgende situation. Bruger A ligger en stor fil på systemet. Bruger B finder filen interessant og laver et hardlink i sit eget home directory. Bruger A sletter filen for at få plads til at lægge andre filer på systemet.

Et kvotesystem der fungerer på bruger ID (mig bekendt dem alle sammen) vil stadig regne filen imod bruger A's kvote, fordi filen er ejet af A. Men hvis kvotesystemet havde fungeret på directory ville det blive regnet imod B's kvote, hvilket i den beskrevne situation ville være mere fair.

Problemet med at gøre det på directory kan ses i følgende scenarie:
- Bruger A lægger en lille fil på systemet.
- Bruger B laver et hardlink til filen i sit homedirectory.
- Bruger A skriver mange flere data til filen.
- Bruger A sletter sit link til filen.
- Bruger B er over sin kvote.
- Bruger A prøver at skrive en ny fil, men der er ikke plads på filsystemet.

Der er intet i den sekvens af handlinger som A foretog sig som er forkert. Og A var aldrig over sin kvote og havde nok kvote til at skrive den nye fil, men der var ikke plads på filsystemet. Systemet var ikke overcomittet, summen af kvoterne var lille nok til at der burde være plads.

Problemet er, at de handlinger en bruger foretager sig kan altså påvirke en anden brugers kvoteforbrug. Og i ovenstående forløb er det eneste sted man med rimelighed kunne gå ind og forbyde en handling ville være på det punkt hvor der blev oprettet et hardlink imellem to forskellige kvoter.

Men det er vel ikke muligt for brugere at oprette hardlinks med mindre de har shell access?

Tukanfan (19) skrev:

Men det er vel ikke muligt for brugere at oprette hardlinks med mindre de har shell access?

De må jo nødvendigvis understøtte en protokol til at opdatere filerne. Jeg ved helt ærligt ikke hvilke af disse protokoller, der giver mulighed for at oprette hardlinks.

Men derudover kan man vel også skrive php scripts. I default opsætningen kan php bruges til at oprette hardlinks. Men, hvis php er sat op med mere sikre indstillinger kan det ikke lade sig gøre.

Desuden har webserveren måske kun adgang til et read-only mount-point af filsystemet. Før i tiden var man nødt til at bruge NFS hvis man ville have samme filsystem mountet read-write og read-only forskellige steder, men med de nyeste Linux versioner tror jeg nok at det kan sættes separat per mount-point.