mboost-dp1

UNIX /opt


Gå til bund
Gravatar #1 - BurningShadow
16. nov. 2011 23:39
Det er rart at vide, at der er folk der er klogere end mig, og det er rart at vide hvor jeg skal finde dem... Jeg har igen brug for jeres hjælp/input, til at løse et lille problem jeg har.

På et helt normalt OS, som f.eks. Linux eller *BSD, kan man jo smide software i /opt, men så er det at jeg undre mig, skal jeg selv sørge for at opdatere min path, eller er der et smart lille værktøj, der kan gøre det for mig, evt. ved at holde øje med /opt?
Gravatar #2 - BurningShadow
17. nov. 2011 19:09
Ingen der ved det?
Gravatar #3 - kasperd
17. nov. 2011 19:43
En mulighed er at oprette en fil i /etc/profile.d samtidigt med at programmet installeres. Denne fil skal indeholde de nødvendige shell kommandoer til at checke om det nødvendige directory allerede er i PATH, og hvis ikke det er, så tilføjde det.

Den metode burde virke på Redhat, Fedora og Ubuntu, og sikkert også andre distributioner. Jeg ved ikke om BSD systemerne gør noget tilsvarende.
Gravatar #4 - BurningShadow
17. nov. 2011 20:40
Det var dét jeg manglede, for at kunne få puslespillet til at gå op :-)
Og så bliver det endda lettere end forventet, at tilpasse det til mit behov.

Rigtig mange tak :-)
Gravatar #5 - Daniel-Dane
17. nov. 2011 21:04
Det var så lidt.
Gravatar #6 - BurningShadow
18. nov. 2011 11:43
Inspireret af /etc/profile.d løsningen, har jeg fundet en (synes jeg selv) fornuftig variant. I stedet for at gennemgå /etc/profile.d og eksekvere en bunke scripts, der alle tilføjer til path, så kan jeg lige så godt gennemgå mappen hvor softwaren er installeret.

for DIR in `find /boot/System/nix/ -maxdepth 2 -type d -name bin`; do
export PATH=$PATH\:$DIR
done;
...tilsvarende for de andre paths.

Det kunne være, at andre kunne have fornøjelse af dette, selvom det forudsætter at man kan være sikker på at de ikke allerede er i PATH.

Unix-folket ville naturligvis nok vælge /opt/ og en maxdepth 3, men ellers ser jeg ingen grund til at det ikke skulle kunne genbruges.
Gravatar #7 - kasperd
20. nov. 2011 17:38
BurningShadow (6) skrev:
Det kunne være, at andre kunne have fornøjelse af dette, selvom det forudsætter at man kan være sikker på at de ikke allerede er i PATH.
Der er også andre potentielle problemer. Du tager ikke højde for at directories kan indeholde specialtegn som en shell vil håndtere andereledes. F.eks. har Mac OS X for vane at benytte mellemrum mange steder, hvilket sådanne shell kommandoer skal være klar til at håndtere. Her er mit bud som burde være lidt bedre på ovenstående punkter
export PATH="$PATH:$(
find /usr /opt -type d -name bin | while read -r DIR
do
if ! [[ ":$PATH:" = *:"$DIR":* ]]
then
echo "$DIR"
fi
done | paste -s -d:)"
Det andet man skal være opmærksom på når man sætter directories i sin PATH er de mulige sikkerhedsproblemer. Man skal undgå alle steder, hvor brugere udover root kunne tilføje filer. Hvis man f.eks. kiggede gennem /var, så kunne en ondsindet bruger oprette /var/tmp/whatever/bin, som så ville blive indsat i PATH. Det directory kunne så indeholde filnavne svarende til gængse tastefejl. F.eks. kunne der være en ls-l kommando.
Gravatar #8 - BurningShadow
20. nov. 2011 19:57
#7

¤1
Det vil være et brud på vore pakke guidelines, at bruge specialtegn, men det skader jo nok ikke at tage højde for det alligevel...

¤2
God pointe.
Jeg er så så "heldig", at der hvor det skal bruges, vil det blive et af de mindste sikkerhedsproblemer. Sikkerheden har traditionelt ikke haft høj prioritet, hvilket dog er på vej til at ændre sig. Det vil ikke være fuldt implementeret i den første release, men der er gjort en bunke indledende forberedelser.
Der er ingen grund til at komme ind på detaljerne, men med hensyn til software pakker, vil de blive inddelt i trusted og untrusted, hvor hver enkelt fil i en trusted pakke, kan verificeres, og hvor installationen af untrusted pakker sker på brugerenes eget ansvar, efter en advarsel.
Problemets omfang vil ikke blive så stort, for der vil primært være tale om to typer software. 1) Nogle *nix komponenter (cups, sane, sdl, etc), der skal bruges af systemet. 2) Udviklingsværktøjer, og div. libraries, hvoraf hovedparten af pakkerne bliver leveret af os.
Det meste andet software vil være native (eller skal kunne opfører sig som om det var), og installeret et helt andet sted.
Derudover skal pakker der kan bruges system-wide, installeres af root (når der bliver implementeret noget sikkerhed...), og alle andre pakker, ported såvel som native, skal installeres i ~/software, og kun være tilgængelig for den aktuelle bruger.
Gå til top

Opret dig som bruger i dag

Det er gratis, og du binder dig ikke til noget.

Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.

Opret Bruger Login