store/doc-espensk/environ.html

   1 <HTML><HEAD>
   2 <TITLE> Environment-konfigurering </TITLE>
   3 <!-- Changed by: Espen Skoglund, 23-Apr-1996 -->
   4 </HEAD><BODY>
   5
   6 <H1> Environment-konfigurering </H1>
   7
   8 For enkelte applikasjoner er det nødvendig at spesielle
   9 environment-variabler er satt for at applikasjonen i det hele tatt
  10 skal fungere.  Det kan f.eks. hende at nye filstier må legges inn i
  11 <CODE>PATH</CODE> eller <CODE>MANPATH</CODE>-variablene, eller at
  12 andre applikasjonsspesifikke variabler må settes
  13 (eks. <CODE>FMHOME</CODE> i FrameMaker).
  14
  15 <P>Det er derimot ønskelig at brukerne skal slippe å vite om disse
  16 variablene -- de skal automatisk konfigureres inn i brukerens oppsett.
  17 Et filsett, <CODE>env-config</CODE>, i <EM>store</EM> sørger for
  18 dette.
  19
  20 <P>I katalogen <CODE>/store/etc/ENV</CODE> ligger det en rekke filer
  21 ``<CODE>ENV-*</CODE>'' som forteller noe om hvlike
  22 environment-variabler som må settes.  Disse filene hører til
  23 forskjellige filsett (<CODE>teTeX</CODE>, <CODE>postgres95</CODE>,
  24 osv.).  Filsettet <CODE>env-config</CODE> inneholder dessuten noen
  25 default-variabler som det ikke passer å spesifisere i de andre
  26 filsettene (eks. <CODE>TZ</CODE> og <CODE>XFILESEARCHPATH</CODE>, samt
  27 standardverdier for <CODE>PATH</CODE> og <CODE>MANPATH</CODE>).
  28
  29 <P>Alt hva vi behøver for å konfigurere brukernes environment-oppsett
  30 til vår applikasjon, er derfor å snekre i sammen en slik fil som
  31 spesifiserer hvilke variabler som må settes.
  32
  33 <H3> Konfigurasjonsfilenes format </H3>
  34
  35 La oss se på formatet som disse konfigusrasjons-filene har.
  36
  37 <UL>
  38 <LI>Blanke linjer, samt kommentarer (linjer som begynner
  39   med <CODE>#</CODE>) blir ignorert.
  40
  41 <P><LI>Dersom tekststrengene <CODE>$TOP</CODE> eller
  42   <CODE>$TOPDIR</CODE> forekommer, blir dette byttet ut med filstien
  43   til linktre-roten (typisk <CODE>/store</CODE>).
  44
  45 <P><LI>Formatet på de resterende linjene, er som følger:
  46
  47   <BLOCKQUOTE><CODE>
  48         <I>&lt;uid&gt;</I>:<I>&lt;gid&gt;</I>:<I>&lt;pri&gt;</I>:<I>&lt;type&gt;</I>:<I>&lt;variabel&gt;</I>=<I>&lt;verdi&gt;</I>
  49   </CODE></BLOCKQUOTE>
  50
  51   <DL>
  52     <DT><CODE>&lt;uid&gt;</CODE>
  53     <DD>Er en kommaseparert liste av brukere (dvs. bruker-id'er) som skal
  54       ha variabelen satt (f.eks. ``<CODE>espensk,geiri</CODE>'').
  55       Dersom feltet består av ``<CODE>*</CODE>'', vil alle brukere få
  56       variabelen satt.  Komplimentet av brukere kan også spesifiseres
  57       ved å benytte ``<CODE>!</CODE>''.  ``<CODE>!root</CODE>''
  58       forteller f.eks. at alle brukerne utenom root-brukeren skal ha
  59       variabelen satt.  Man kan forøvrig benytte tall-uider i denne
  60       listen også, disse vil da bli oversatt til navn-uider dersom det
  61       lar seg gjøre.
  62
  63     <P><DT><CODE>&lt;gid&gt;</CODE>
  64     <DD>Er en kommaseparert liste over grupper (dvs. gruppe-id'er) som
  65       skal ha variabelen satt.  ``<CODE>/usr/bin/groups</CODE>''
  66       benyttes for å bestemme hvilke grupper den aktuelle brukeren er
  67       medlem av.  Formatet er forøvrig likt det som benyttes for
  68       <CODE>&lt;uid&gt;</CODE>.
  69
  70     <P><DT><CODE>&lt;pri&gt;</CODE>
  71     <DD>Forteller hvliken prioritet denne variabelsettingen har.  I
  72       filstier benyttes dette til å fortelle hvor tidlig i stien
  73       verdien skal settes.  I <CODE>PATH</CODE> har
  74       f.eks. ``<CODE>/store/bin</CODE>'' prioritet 5 og
  75       ``<CODE>/store/opt/krb5/bin</CODE>'' priotitet 4.  Dette fører
  76       til at ``<CODE>/store/opt/krb5/bin</CODE>'' havner før
  77       ``<CODE>/store/bin</CODE>'' i den ferdige stien.
  78
  79       <P>Dersom vi har med vanlige verider å gjøre (dvs. alle verdier
  80       som ikke er stier) vil dette fungere som en helt vanlig
  81       priotitet.  <CODE>TZ</CODE> med prioritet 4 benyttes f.eks. før
  82       <CODE>TZ</CODE> med prioritet 5.
  83
  84     <P><DT><CODE>&lt;type&gt;</CODE>
  85     <DD>Forteller hvilken type variabel vi har med å gjøre.
  86       <DL COMPACT>
  87       <DT><CODE>p</CODE> -
  88       <DD>sier at vi har med stier å gjøre.  Alle enhetene i denne
  89           variablen blir sjekket for eksistens i filtreet før de blir
  90           lagt til.  Hvis vi f.eks. legger
  91           ``<CODE>/usr/ingres/bin</CODE>'' inn i <CODE>PATH</CODE>,
  92           vil dette bare gjelde på lglaben (og andre steder hvor
  93           ingres er installert).
  94       <DT><CODE>n</CODE> -
  95       <DD>sier også at vi har med stier å gjøre.  Forskjellen er at disse
  96           stiene ikke blir sjekket for eksistens.  Dette er nyttig når
  97           vi f.eks. definerer <CODE>XFILESEARCHPATH</CODE> til å være
  98           ``<CODE>/store/lib/X11/app-defaults/%N</CODE>''.  I dette
  99           tilfellet finnes jo ingen slik katalog.
 100       <DT><CODE>s</CODE> -
 101       <DD>sier at vi har med en enkel verdi å gjøre (f.eks.
 102           <CODE>TZ</CODE>).
 103       </DL>
 104
 105     <P><DT><CODE>&lt;variabel&gt;=&lt;verdi&gt;</CODE>
 106     <DD>Dersom variabelen er en enkel verdi (type <CODE>s</CODE>), blir
 107       variabelen (eventuelt) satt til den gitte verdien.  Dersom
 108       variabelen derimot er en sti (type <CODE>p</CODE> eller
 109       <CODE>n</CODE>), blir den gitte verdien (eventuelt) lagt til i
 110       stien.
 111   </DL>
 112
 113   <P>Hvis en linje ender med ``<CODE>\</CODE>'' (backslash), blir
 114   linjen konkatinert med neste linje, og et ``<CODE>:</CODE>'' (kolon)
 115   blir satt som skille mellom dem.  Dette er nyttig dersom du
 116   spesifiserer en sti bestående av flere elementer, og ønsker å rydde
 117   opp i konfigurasjonsfilen.  Følgende to settinger er altså like:
 118
 119   <LISTING>
 120     *:*:2:p:PATH=/opt/ansic/bin \
 121             /opt/nettladm/bin \
 122             /opt/graphics/common/bin
 123
 124     *:*:2:p:PATH=/opt/ansic/bin:/opt/nettladm/bin:/opt/graphics/common/bin
 125   </LISTING>
 126
 127   Begge sier at alle brukere (og alle grupper) skal ha de 3 filstiene
 128   lagt til i <CODE>PATH</CODE>.  Siden prioriteten er høy (2), vil
 129   disse elementene havne langt frem i stien.  Siden variabel-settingen
 130   er av type <CODE>p</CODE>, vil eksistensen til hver av katalogene
 131   bli sjekket før de blir tatt med.  Dvs. at dersom f.eks. katalogen
 132   ``<CODE>/opt/graphics/common/bin</CODE>'' ikke eksisterer, vil den
 133   ikke bli tatt med i den ferdige stien.
 134
 135   <P>Den typiske bruken av environment-settinger, er derimot meget
 136   enkel.  Som oftest ønsker vi bare å legge til et enkelt element i
 137   <CODE>PATH</CODE> og/eller <CODE>MANPATH</CODE>.  Dette gjelder
 138   f.eks. for Kerberos-applikasjonen.  Filsettet inneholder derfor en
 139   fil ``<CODE>etc/ENV/ENV-kerberos</CODE>''.  Innholdet i denne filen
 140   er:
 141
 142   <LISTING>
 143     #
 144     # Kerberos settings
 145     #
 146     *:*:4:p:PATH=$TOPDIR/opt/krb5/bin
 147     *:*:4:p:MANPATH=$TOPDIR/opt/krb5/man
 148   </LISTING>
 149
 150   Vi ser også at filen inneholder en liten kommentar.  Dette er smart
 151   fordi det fører til at
 152
 153   <LISTING>
 154     $ <I>cat /store/etc/ENV/ENV-*</I>
 155   </LISTING>
 156
 157   gir nogenlunde fornuftig output.
 158
 159 </UL>
 160
 161 <H3> Hvordan benytte seg av det ferdiggenererte oppsettet </H3>
 162
 163
 164 Applikasjonen <CODE>env-config</CODE> genererer filene
 165 <CODE>/store/etc/src.sh</CODE> og <CODE>/store/etc/src.csh</CODE> hver
 166 natt ved hjelp av en <EM>nightly command</EM>.  De genererte filene er
 167 i henholdsvis <EM>bourne-shell</EM> og <EM>c-shell</EM> format, og kan
 168 ``<EM>sources</EM>'' av andre shell-oppstart-filer (eller interaktivt
 169 av brukerne) dersom det er ønskelig.  <CODE>Zsh</CODE> genererer
 170 dessuten sin egen <CODE>/store/skel/zshenv</CODE> hver natt slik at
 171 den ikke behøver å <EM>source</EM> noen av disse filene.
 172
 173 <P>Dersom applikasjoner ønsker å konfigurere dette selv, slik som
 174 f.eks. <CODE>zsh</CODE> gjør, er det ønskelig at koden i
 175 <CODE>env-config</CODE> benyttes.  Eksempel på perl-kode følger:
 176
 177 <LISTING>
 178     require "$ENV{'TOPDIR'}/lib/environment/environ.pl";
 179
 180     %Env = &Env'read_env( "$ENV{'TOPDIR'}/etc/ENV" );
 181     $Tekst_som_må_inkluderes_i_skript = &Env'build_env( %Env );
 182 </LISTING>
 183
 184 Den aktuelle teksten kan dermed plasserers hvor det måtte være
 185 ønskelig (eks. <CODE>/store/skel/zshenv</CODE>).
 186 ``<CODE>&Env'build_csh_env</CODE>'' kan også benyttes istedenfor
 187 ``<CODE>&Env'build_env</CODE>'' dersom <EM>csh</EM>-syntaks er
 188 ønskelig.
 189
 190 <P>Filsett som skal benytte seg av environment-konfigurasjonene bør
 191 settes til å ha <EM>dependency</EM> <CODE>env-config</CODE> (dette
 192 gjelder f.eks. <CODE>zsh</CODE>).  Hvis ikke dette blir gjort vil ikke:
 193
 194 <UL>
 195   <LI>``<CODE>environ.pl</CODE>'' kunne inkluderes i perl-skript
 196     (dersom det benyttes).
 197   <LI>``<CODE>etc/src.sh</CODE>'' eller ``<CODE>etc/src.csh</CODE>''
 198     vil ikke eksistere (dersom dette f.eks. skulle <EM>sources</EM> i
 199     oppstartfilene).
 200   <LI>Default-konfigurasjonene vil ikke eksitere.  Dette vil føre til
 201       at vi bl.a. ville få en meget slank <CODE>PATH</CODE> og
 202       <CODE>MANPATH</CODE>.
 203 </UL>
 204
 205 <HR>
 206 <ADDRESS><A HREF="/~espensk/">eSk</A></ADDRESS>
 207
 208 </BODY></HTML>