Gewenste locatie voor cgi-uitvoerbare bestanden in Lion Server

Deze vraag heeft alleen betrekking op het gebruik van een Lion Server voor testen en prototypen, dus ik heb niet meerdere sites nodig die afzonderlijke domeinen hosten. Al mijn projecten hebben mappen in de hoofdmap, niet in afzonderlijke submappen "Sites".

In Lion Server heeft Apple de vorige directory-indeling laten vallen van:

/ Bibliotheek/WebServer/CGI-uitvoerbare bestanden [aliased als cgi-bin]

/ Bibliotheek/WebServer/Documenten [aliased als hoofdmap]

Nu is de webserver eenvoudig:

/ Library/Server/Web/Data/Sites/Default

After I installed Lion Server, Apache was still configured with cgi-bin aliased to /Library/WebServer/CGI-Executables and root directory to /Library/WebServer/Documents. I changed the latter in the Web section of Lion's Server.app to/Library/Server/Web/Data/Sites/Default.

Ik zou willen sloot/Bibliotheek/Webserver. Ik kan geen enkele verwijzing vinden naar een voorkeur/aanbevolen map voor mijn uitvoerbare bestanden. Ik denk: / Bibliotheek/Server/Web/Data/Exec [aliased in Apache config als cgi-bin of wat dan ook]

Ik ben eraan gewend al mijn uitvoerbare bestanden op één plaats te hebben en ze delen gewoonlijk veel modules met elkaar, dus ik ben niet geneigd om een ​​cgi-map in de eigen map van elk project te plaatsen.

Iets te melden? Huidige beste praktijken?

Bedankt.

2
Waarom sloot de standaardlocatie van/Library/Webserver? Naarmate ik grijzer wordt, weersta ik niet om iets te veranderen tenzij de reden solide is en volkomen duidelijk waarom het nieuwe beter is.
toegevoegd de auteur Oskar, de bron
Ik ben gewend om de mappenstructuur te aanvaarden die aan mij wordt gepresenteerd. In dezelfde geest ben ik teruggegaan naar het gebruik van/Library/Webserver/Documents en/Library/Webserver/CGI-Executables op mijn eigen machines toen OS X voor het eerst uitkwam. Die leken te zijn gelaten in/Bibliotheek toen ik Lion Server installeerde. Ik hoopte dat ik wat verlichting zou vinden over waarom er nu geen aparte map is voor CGI's, en impliciet de goede vraag die je stelt - waarom was het veranderd?
toegevoegd de auteur typeseven, de bron

3 antwoord

OS X is een op unix gebaseerd systeem, daarvoor kunt u de standaard Unix-bestandsstructuur gebruiken.

Over het algemeen gebruiken de meeste unix/linux distro's/var/www/voor webserveropslag, je zou je iets kunnen voorstellen als/var/www/html voor pagina's en media en/var/www/cgi-bin voor cgi-uitvoerbare bestanden.

Er zijn andere locaties beschikbaar (/ srv bijvoorbeeld), zie deze lijst op wikipedia voor uitleg over de directorystructuur (indien nodig)

1
toegevoegd
Ik stel het antwoord op prijs - maar macs missen technisch gezien niet alle standaard directory-structuur, omdat alles leeft in/privé en som-links bestaan ​​voor "compatibiliteit" - De afspraak is om niets anders in var te plaatsen dan tijdelijke bestanden op de mac, daarom zijn we allemaal zoek naar conventie om de "volgende beste plek" te vinden om deze bestanden te laten leven.
toegevoegd de auteur Oskar, de bron
Ik denk dat ik had gehoopt dat mensen zouden uitleggen waarom ze vonden dat een specifieke locatie de voorkeur had. Uw concept om geen server- of gebruikersgegevens te mengen met leveranciersdocumenten is geweldig! De vraag is niet zozeer waar je mag dingen opslaat, maar waar en waarom de ene locatie de voorkeur heeft boven de andere. Ik zal proberen mijn antwoord te bewerken om beter op te pakken waarom ik vind dat het superieur is aan de alternatieven. Het gaat niet om beleefdheid - ik hoor liever dat ik weet hoe en waarom ik ongelijk heb en ben overtuigd of begrijp tenminste waarom/var of/srv of/Library/WebServer/CGI-uitvoerbare bestanden de voorkeur hebben.
toegevoegd de auteur Oskar, de bron
Bedankt allemaal. Afwezig liever , of misschien iemand van Apple die uitlegt waarom zij de wijziging in de directorystructuur na een decennium hebben aangebracht, concludeer ik dat het, afgezien van het vermijden van problemen, willekeurig is. Mijn spullen worden altijd op de server van iemand anders of op een andere ISP geïnstalleerd, dus elke build maakt twee afzonderlijke configs: een voor de directorystructuur van mijn (nu Lion) testserver en de andere voor de directorystructuur waar de app wordt geïmplementeerd. Al het andere is hetzelfde. Die en Apache-stijl aliasing (d.w.z. cgi-bin) betekenen dat ik niet echt terugkijk zodra mijn directorystructuur op zijn plaats is.
toegevoegd de auteur typeseven, de bron
Aangezien er slechts drie symlinks naar/privé zijn, vind ik de opmerking 'macs technisch gezien missen alle standaard directory-structuur' een beetje overdreven (ja, ik ben beleefd). OS X is niet alleen gebaseerd op Unix, het is een POSIX-compatibel Unix-besturingssysteem. Het feit dat het een paar symlinks gebruikt, doet daar niets aan af. Ik denk dat de opmerking van Benjamin een goede is, hoewel ik/var niet zou gebruiken. Mijn eigen regels (nu ongeveer 30 jaar oud - bedankt Melinda) zijn dat ik mijn spullen nooit met de dingen van de verkoper moet mengen.
toegevoegd de auteur user1997744, de bron
Ik heb nog nooit van die conventie gehoord (alleen tmp-bestanden in/var), sorry. Maar waarom gebruik je dan niet dezelfde structuur als die je had in SL?
toegevoegd de auteur tci, de bron
Het ding is: er is geen objectieve reden om een ​​locatie boven een andere te verkiezen. Zolang uw installatie goed gedocumenteerd, beveiligd en aan uw behoeften voldoet, waarom zou u erom geven? je kunt/srv,/opt,/var,/srv,/usr/local of een OSX-specifieke locatie gebruiken ... Zorg gewoon voor updates om problemen te voorkomen.
toegevoegd de auteur tci, de bron

My preference would be to place system wide common CGI executables in /Library/Server/Web/Data/Exec

Een paar concepten kwamen bij me op, denkend aan welke map het beste zou kunnen zijn:

  1. Avoid storing my CGI among the Apple delivered system CGI.
  2. Avoid storing my CGI in a folder where Server Admin and Finder have hidden by default.

    Of lesser importance are the actions taken by Apple to no longer ship with or continue to hide some folders from view (I'm happy to break from the vendor lead - but generally need a good reason to do so)

  3. Don't change from Snow Leopard's location of /Library/WebServer/CGI-Executables (the lazy sysadmin principle - why change anything you don't have to)

  4. Least effort - if I have to chance something - less change is better.

Het lijkt duidelijk dat /Bibliotheek/Server/Web/Data/Sites gegevens zou bevatten die de webserver anders zou serveren op basis van de behoeften van elke site. Dus als mijn Orange -site CGI had die alleen voor die ene site bedoeld was, bewaar ik ze misschien in /Library/Server/Web/Data/Sites/Orange/Exec dan in de "standaard" -locatie.

Ik zie geen goede reden om /Library/WebServer in de buurt te houden, omdat ik mijn Apache-configuratiebestand zal bewerken om mijn sites toe te voegen - en ik vermoed dat we het zullen veranderen in een puntvrijgave en hoeft niet te raden.

Ik zou elke map die standaard verborgen was in Finder en Server Manager sluiten - dus voor mij zou /private uit zijn. Ik zeg niet dat het verkeerd is dat iemand daar dingen bewaart - vooral als het je werk of denkkracht redt door de codestructuur opnieuw te gebruiken van een ander UNIX-besturingssysteem dat geen gebruik maakt van het unieke /Systeem van Mac OS X /Bibliotheek mapstructuur.

0
toegevoegd

Answering my own question in case the conclusion wasn't clear. No one has clarified why Apple changed the directory structure for the web server in OS X Lion (& Mountain Lion) Server. However, for me the salient question was whether there was a "best practices" location for web executables - or a "preferred" location as @bmike put it. My conclusion from the several useful comments and from my own testing is that the choice of location is arbitrary, and therefore what counts as best practice is to locate your web executables where they best serve your site, following the criteria and suggestions mentioned by the commenters.

Voor mij is mijn eigen server slechts een stap op weg naar de uiteindelijke locatie van mijn spullen op de server van iemand anders of bij een andere internetprovider. Dus elke build creëert twee verschillende configs: één voor de directorystructuur van mijn (nu Mountain Lion) testserver en de andere voor de directorystructuur waar de app wordt geïmplementeerd. Al het andere is hetzelfde.

Dus ik heb een directorystructuur voor mijn webserver opgezet die het gemakkelijk maakt om mijn projecten bij te houden en zijn paden in mijn buildsysteem heeft vastgelegd. Die en Apache-stijl aliasing (dat wil zeggen met behulp van 'cgi-bin' als een alias voor de map uitvoerbare bestanden) betekent dat ik niet echt terugkijk nu mijn eigen directorystructuur is geïnstalleerd. Ik heb net de app gebouwd en hij komt op de juiste plek terecht om op mijn server te draaien. Dus dat is het antwoord voor mij.

In een productieserver zou de beste praktijk waarschijnlijk de suggesties van de commentatoren bevatten: minimale verandering, minimale verrassing voor een latere beheerder en persistentie door systeemupgrades. Bedankt allemaal.

0
toegevoegd