Environment-konfigurering

For enkelte applikasjoner er det nødvendig at spesielle environment-variabler er satt for at applikasjonen i det hele tatt skal fungere. Det kan f.eks. hende at nye filstier må legges inn i PATH eller MANPATH-variablene, eller at andre applikasjonsspesifikke variabler må settes (eks. FMHOME i FrameMaker).

Det er derimot ønskelig at brukerne skal slippe å vite om disse variablene -- de skal automatisk konfigureres inn i brukerens oppsett. Et filsett, env-config, i store sørger for dette.

I katalogen /store/etc/ENV ligger det en rekke filer ``ENV-*'' som forteller noe om hvlike environment-variabler som må settes. Disse filene hører til forskjellige filsett (teTeX, postgres95, osv.). Filsettet env-config inneholder dessuten noen default-variabler som det ikke passer å spesifisere i de andre filsettene (eks. TZ og XFILESEARCHPATH, samt standardverdier for PATH og MANPATH).

Alt hva vi behøver for å konfigurere brukernes environment-oppsett til vår applikasjon, er derfor å snekre i sammen en slik fil som spesifiserer hvilke variabler som må settes.

Konfigurasjonsfilenes format

La oss se på formatet som disse konfigusrasjons-filene har.

Blanke linjer, samt kommentarer (linjer som begynner med #) blir ignorert.
Dersom tekststrengene $TOP eller $TOPDIR forekommer, blir dette byttet ut med filstien til linktre-roten (typisk /store).
Formatet på de resterende linjene, er som følger:
<uid>:<gid>:<pri>:<type>:<variabel>=<verdi>

<uid>
Er en kommaseparert liste av brukere (dvs. bruker-id'er) som skal ha variabelen satt (f.eks. ``espensk,geiri''). Dersom feltet består av ``*'', vil alle brukere få variabelen satt. Komplimentet av brukere kan også spesifiseres ved å benytte ``!''. ``!root'' forteller f.eks. at alle brukerne utenom root-brukeren skal ha variabelen satt. Man kan forøvrig benytte tall-uider i denne listen også, disse vil da bli oversatt til navn-uider dersom det lar seg gjøre.
<gid>
Er en kommaseparert liste over grupper (dvs. gruppe-id'er) som skal ha variabelen satt. ``/usr/bin/groups'' benyttes for å bestemme hvilke grupper den aktuelle brukeren er medlem av. Formatet er forøvrig likt det som benyttes for <uid>.
<pri>
Forteller hvliken prioritet denne variabelsettingen har. I filstier benyttes dette til å fortelle hvor tidlig i stien verdien skal settes. I PATH har f.eks. ``/store/bin'' prioritet 5 og ``/store/opt/krb5/bin'' priotitet 4. Dette fører til at ``/store/opt/krb5/bin'' havner før ``/store/bin'' i den ferdige stien.
Dersom vi har med vanlige verider å gjøre (dvs. alle verdier som ikke er stier) vil dette fungere som en helt vanlig priotitet. TZ med prioritet 4 benyttes f.eks. før TZ med prioritet 5.
<type>
Forteller hvilken type variabel vi har med å gjøre.

p -
sier at vi har med stier å gjøre. Alle enhetene i denne variablen blir sjekket for eksistens i filtreet før de blir lagt til. Hvis vi f.eks. legger ``/usr/ingres/bin'' inn i PATH, vil dette bare gjelde på lglaben (og andre steder hvor ingres er installert).
n -
sier også at vi har med stier å gjøre. Forskjellen er at disse stiene ikke blir sjekket for eksistens. Dette er nyttig når vi f.eks. definerer XFILESEARCHPATH til å være ``/store/lib/X11/app-defaults/%N''. I dette tilfellet finnes jo ingen slik katalog.
s -
sier at vi har med en enkel verdi å gjøre (f.eks. TZ).

<variabel>=<verdi>
Dersom variabelen er en enkel verdi (type s), blir variabelen (eventuelt) satt til den gitte verdien. Dersom variabelen derimot er en sti (type p eller n), blir den gitte verdien (eventuelt) lagt til i stien.

Hvis en linje ender med ``\'' (backslash), blir linjen konkatinert med neste linje, og et ``:'' (kolon) blir satt som skille mellom dem. Dette er nyttig dersom du spesifiserer en sti bestående av flere elementer, og ønsker å rydde opp i konfigurasjonsfilen. Følgende to settinger er altså like:
*:*:2:p:PATH=/opt/ansic/bin \ /opt/nettladm/bin \ /opt/graphics/common/bin *:*:2:p:PATH=/opt/ansic/bin:/opt/nettladm/bin:/opt/graphics/common/bin Begge sier at alle brukere (og alle grupper) skal ha de 3 filstiene lagt til i PATH. Siden prioriteten er høy (2), vil disse elementene havne langt frem i stien. Siden variabel-settingen er av type p, vil eksistensen til hver av katalogene bli sjekket før de blir tatt med. Dvs. at dersom f.eks. katalogen ``/opt/graphics/common/bin'' ikke eksisterer, vil den ikke bli tatt med i den ferdige stien.
Den typiske bruken av environment-settinger, er derimot meget enkel. Som oftest ønsker vi bare å legge til et enkelt element i PATH og/eller MANPATH. Dette gjelder f.eks. for Kerberos-applikasjonen. Filsettet inneholder derfor en fil ``etc/ENV/ENV-kerberos''. Innholdet i denne filen er:
# # Kerberos settings # *:*:4:p:PATH=$TOPDIR/opt/krb5/bin *:*:4:p:MANPATH=$TOPDIR/opt/krb5/man Vi ser også at filen inneholder en liten kommentar. Dette er smart fordi det fører til at $ cat /store/etc/ENV/ENV-* gir nogenlunde fornuftig output.

Hvordan benytte seg av det ferdiggenererte oppsettet

Applikasjonen env-config genererer filene /store/etc/src.sh og /store/etc/src.csh hver natt ved hjelp av en nightly command. De genererte filene er i henholdsvis bourne-shell og c-shell format, og kan ``sources'' av andre shell-oppstart-filer (eller interaktivt av brukerne) dersom det er ønskelig. Zsh genererer dessuten sin egen /store/skel/zshenv hver natt slik at den ikke behøver å source noen av disse filene.

Dersom applikasjoner ønsker å konfigurere dette selv, slik som f.eks. zsh gjør, er det ønskelig at koden i env-config benyttes. Eksempel på perl-kode følger:

require "$ENV{'TOPDIR'}/lib/environment/environ.pl"; %Env = &Env'read_env( "$ENV{'TOPDIR'}/etc/ENV" ); $Tekst_som_må_inkluderes_i_skript = &Env'build_env( %Env ); Den aktuelle teksten kan dermed plasserers hvor det måtte være ønskelig (eks. /store/skel/zshenv). ``&Env'build_csh_env'' kan også benyttes istedenfor ``&Env'build_env'' dersom csh-syntaks er ønskelig.

Filsett som skal benytte seg av environment-konfigurasjonene bør settes til å ha dependency env-config (dette gjelder f.eks. zsh). Hvis ikke dette blir gjort vil ikke:

``environ.pl'' kunne inkluderes i perl-skript (dersom det benyttes).
``etc/src.sh'' eller ``etc/src.csh'' vil ikke eksistere (dersom dette f.eks. skulle sources i oppstartfilene).
Default-konfigurasjonene vil ikke eksitere. Dette vil føre til at vi bl.a. ville få en meget slank PATH og MANPATH.

eSk