it-swarm.it

Qual è la differenza tra / opt e / usr / local?

Secondo Filesystem Hierarchy Standard , /opt è per "l'installazione di pacchetti software applicativi aggiuntivi". /usr/local è "destinato all'amministratore di sistema durante l'installazione del software in locale". Questi casi d'uso sembrano abbastanza simili. Il software non incluso nelle distribuzioni di solito è configurato per impostazione predefinita per l'installazione in /usr/local o /opt senza particolari rime o motivi per cui hanno scelto.

C'è qualche differenza che mi manca o entrambi fanno la stessa cosa, ma esistono per ragioni storiche?

440
Patches

Mentre entrambi sono progettati per contenere file non appartenenti al sistema operativo, /opt e /usr/local non intendono contenere lo stesso set di file.

/usr/local è un luogo in cui installare i file creati dall'amministratore, in genere utilizzando il comando make (ad es. ./configure; make; make install). L'idea è quella di evitare scontri con file che fanno parte del sistema operativo, che verrebbero sovrascritti o sovrascriverebbero quelli locali altrimenti (ad es. /usr/bin/foo fa parte del sistema operativo mentre /usr/local/bin/foo è un'alternativa locale).

Tutti i file in /usr sono condivisibili tra istanze del sistema operativo, sebbene ciò avvenga raramente con Linux. Questa è una parte in cui l'FHS è leggermente contraddittorio, come /usr è definito come di sola lettura, ma /usr/local/bin deve essere letto/scritto per consentire l'installazione locale del software. Lo standard del file system SVR4, che è stata la principale fonte di ispirazione dell'FHS, raccomanda di evitare /usr/local e usa /opt/local invece di superare questo problema.

/usr/local è un'eredità del BSD originale. A quel tempo, il codice sorgente di /usr/bin I comandi del sistema operativo erano in /usr/src/bin e /usr/src/usr.bin, mentre l'origine dei comandi sviluppati localmente era in /usr/local/src e i relativi binari in /usr/local/bin. Non c'era idea di imballaggi (al di fuori dei tarball).

D'altro canto, /opt è una directory per l'installazione di pacchetti disaggregati (ovvero pacchetti che non fanno parte della distribuzione del sistema operativo, ma forniti da una fonte indipendente), ognuno nella propria sottodirectory. Sono già costruiti interi pacchetti forniti da un distributore di software di terze parti indipendente. Diversamente da /usr/local roba, questi pacchetti seguono le convenzioni della directory (o almeno dovrebbero). Ad esempio, someapp verrebbe installato in /opt/someapp, con uno dei suoi comandi è /opt/someapp/bin/foo, il suo file di configurazione sarebbe in /etc/opt/someapp/foo.conf e i relativi file di registro in /var/opt/someapp/logs/foo.access.

393
jlliagre

La differenza di base è che /usr/local è per software non gestito dal packager di sistema, ma che continua a seguire le regole di distribuzione unix standard.

Ecco perché hai /usr/local/bin, /usr/local/sbin/usr/local/include eccetera...

/opt d'altra parte è per software che non segue questo e viene distribuito in modo monolitico. Questo di solito include software commerciale e/o multipiattaforma confezionato in stile "Windows".

89
Šimon Tóth

Sono davvero molto simili e l'uso dell'uno o dell'altro è più una questione di opinione. Il diario di Linux ha avuto questa discussione punto/contrappunto su questo argomento esatto qui .

18
philfr

Per me, personalmente, è quello che Bill ha detto nel link di @ philfr:

Su un sistema di sviluppo o su una sandbox, avere una directory/opt in cui puoi semplicemente lanciare le cose e vedere se funzionano ha molto senso. So che non passerò attraverso lo sforzo di impacchettare le cose per provarle. Se l'app non funziona, puoi semplicemente rm la directory/opt/mytestapp e quell'applicazione è cronologia. Il packaging può avere senso quando si esegue una distribuzione di grandi dimensioni (ci sono volte in cui eseguo pacchetti di app), ma molte volte è bello gettare/optare.

Sfortunatamente, la maggior parte dei make install scripts inserisce i file in /usr/local invece di creare un link simbolico lì: - /

13
pepoluan

Innanzitutto, non penso che ci sia una risposta rigorosa; amministratori diversi avranno opinioni diverse, in base al loro background. Storicamente, /usr/local è arrivato per primo; era la convention di Berkley, IIRC. Ad un certo punto durante lo sviluppo di System V, se non sbaglio (questo è tanto tempo fa e non ho preso appunti), c'era una decisione o un desiderio di poter montare /usr sola lettura, il che significa che non è possibile aggiungere nuovo software ad esso; quello potrebbe essere stato il motivo per cui /opt è stato inventato. A quanto pare, c'erano così tanti software esistenti che scrivevano su /usr quell'idea non è mai veramente decollata.

La mia preferenza personale è /opt, con una sottodirectory separata per ciascun prodotto; questo rende la rimozione di un prodotto un semplice caso di rm -fr. Ma se tutto il tuo software viene installato tramite un buon gestore di pacchetti, non importa, e se il software che installi non obbedisce rigorosamente a queste convenzioni e scrive configurazioni e simili da qualche parte sotto /usr, non importa neanche, anche se per le ragioni opposte.

12
James Kanze

Ho una visione leggermente diversa di questo problema.
Mentre tutto in jlliagre 's risposta è corretto, l'applicazione pratica per me, durante la distribuzione di software in un cluster, si riduce alle variabili di ambiente predefinite e predefinite riutilizzo delle librerie.

In parole povere - /usr/local E tutte le sue dir figlio sono negli ambienti appropriati come PATH e MANPATH, e /usr/local/lib{,64} Sono in ldconfig (/etc/ld.so.conf.d/).

/opt/ OTOH non lo è - il che è vantaggioso quando si richiedono più versioni o pacchetti in conflitto per coesistere nel sistema, ma richiede una sorta di gestione dell'ambiente (ad es. environment-module oppure raccolte software ) e svantaggioso in quanto potenzialmente "spreca" lo spazio di archiviazione duplicando le librerie condivise, poiché ogni installazione in /opt può essere completamente autonoma.

Perché la natura condivisa di /usr/local Funzioni, si presume che ad es. i binari vengono installati direttamente su /usr/local/bin (e le pagine man per appropriarsi di /usr/local/share/man/...) anziché /usr/local/app/{bin,share/man,...} ecc.

10
Dani_l

In sintesi, la mia risposta viscerale ...

Avendo usato la mia giusta quota di FreeBSD dalla 2.2.6 e Red Hat Linux dalla versione 9 ...

/usr/local == Old School Conventions
/opt       == New School Conventions

La disposizione delle cose sui file system UNIX/Linux ha più a che fare con convenzioni e tradizione, che con la logica assoluta.

Altrimenti, concordo principalmente con tutti gli altri. :-)

C'è sempre qualche eccezione alla regola. Alla fine della giornata, decidi cosa è meglio per la tua installazione (quando puoi).

0
Anthony Rutledge