1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
|
NB! DENNE FILEN ER UTDATERT, OG FLGER IKKE NVRENDE KONVENSJONER
GENERELT
LDAP-basen skal innehalde opplysningar naudsynt for autentisering,
tilgangsstyring for nettverksressursar (epost, diskusjonslister,
internettilgang og filomrde) og forholdet mellom klasse/elev/lrar.
Andre attributtar for dei ulike elementa i treet skal ogs lagrast, s
som epostadresser, telefonnummer, foresatte og personnummer (viss
Datatilsynet tillet det).
NASJONAL STRUKTUR
Eit effektivt driftsopplegg krever at kvar skule har sitt eige
namnerom slik at ein ikkje fr namnekollisjonar nr ein gr over til
meir sentral drift. Ved bruke ein hierarkisk modell oppnr vi dette
ganske enkelt. Ein hierarkisk modell gjer det ogs mogleg delegere
ansvar for halde ei undergrein oppdatert.
Det er naturleg bruke same organisering som det er i det offentlege
allereie, med andre ord ei inndeling i fylke og kommunar. kutte ut
fylkesdelen fungerer ikkje sidan fleire kommunenamn vert brukt i to
fylke (Sande i Vestfold og Mre og Romsdal, B i Telemark og Nordland,
m.fl.). I Oslo deler vi inn etter bydel sidan det fylket ikkje er
delt inn i kommunar (Kommentar: Dette er kanskje ikkje praktisk, sidan
alle skulane i Oslo vert styrt sentralt.)
NAMNEKONVENSJONAR
Toppen av treet er "o=skolelinux,c=no". Nr/viss Staten kjem inn og
vil ta over drifta av opplegget vrt, kan det vere naturleg bytte ut
toppen av treet med noko anna. Vr programvare br vere budd p at
noko slikt kan skje.
Neste trinn er "l=fylke". Vi brukar dei vanlege tobokstavs-
stuttingane for fylkesnamn, "mr", "sf", "nt", "vf" osv. Merk at Oslo
er "oslo", ikkje "os".
S kjem "l=kommune". Namnet vert skrive fullt ut. Det gr fint
bruke norske teikn og blanke i dette namnet.
Til sist kjem "o=skule". Namnet p skulen m vere unikt innanfor
kommunen, og det er opptil kvar enkelt skule velje namnet som vert
brukt her. Eg synest det vil vere naturleg skrive namnet fullt ut,
men droppe "overfldige" ord. T.d. "Hole barne- og ungdomsskole" vert
til berre "Hole", "Hole BU", eller kanskje "HBU" om det er den vanlege
lokale stuttinga.
AVBILDNING TIL EPOST-ADRESSER
Overgangen fr ein Distinguished Name[1] i LDAP til eit epostdomene er
rett fram. Norid tilrr at vert gjort om til aoa. Tilsvarande
vert gjort for bokstavar med aksent, c cedilla o.l. Blanke vert gjort
om til bindestrek, og punktum vert fjerna.
[1] Distinguished Name (DN) er termen som vert brukt om unike
objekt-IDar.
Nokon dme:
Eining: Ytre Hery Ungdomsskule, Hery kommune, Mre og Romsdal
LDAP DN: o=YHU,l=Hery,l=mr,o=skolelinux,c=no
Domene: yhu.heroy.mr.skolelinux.no
Eining: Oslo Katedralskole, St. Hanshaugen-Ullevl bydel, Oslo
LDAP DN: o=Oslo Katedralskole,l=St. Hanshaugen-Ullevl,l=oslo,
o=skolelinux,c=no
Domene: oslo-katedralskole.st-hanshaugen-ulleval.oslo.skolelinux.no
Viss vi kuttar ut inndelinga i bydelar i Oslo, og leiinga p
Katedralskolen nskte det, kunne vi i staden f:
Eining: Oslo Katedralskole, Oslo
LDAP DN: o=Katta,l=oslo,o=skolelinux,c=no
Domene: katta.oslo.skolelinux.no
Domenet kan uansett overstyrast eksplisitt med attributten
"associatedDomain".
TREET FOR KVAR SKULE
Toppnoden for skulen bestr av
objectClass: organization
objectClass: lisSchool
Dette omfattar verdiar som postadresse, gateadresse, telefonnummer,
faksnummer osv.
Under toppnoden finn vi fire greiner.
GREIN 1: organizationalUnit: Elev
I denne greina finn vi eitt objekt for kvar elev ved skulen. Ein elev
er sett saman av klassane
objectClass: inetOrgPerson
... inneheld attributtar for namn, adresse, telefonnummer osv.
objectClass: posixAccount
... inneheld all informasjon som skal til for autentisere ein
brukar i eit POSIX-milj (i praksis Unix).
objectClass: lisPerson
... inneheld
emailAlias: gyldige epost-aliasar, "k.t.homme", "kjetil.t.homme",
osv.
owner: referanse til lraren som er klasseforstandar.
vedkomande er autorisert til endre verdiar i dette
objektet.
dataOfBirth: fdselsdato
uniqueIdentifier:
personnummer eller annan identifikator gyldig ogs
utanfor denne skulen.
Kvar elev kan ha eitt eller fleire lisKinship-objekt under seg.
Attributtane i lisKinship er "kinship" og "kin". "kinship" er namnet
p forholdet ("mor", "far", "tante", "verge"), "kin" er ein referanse
til ein annan person i LDAP-treet. Sidan det er kinship som vert
brukt for lage eit unikt namn for dette objektet, kan ein elev kun
ha i tante registrert p seg.
GREIN 2: organizationalUnit: Tilsett
I denne greina finn vi alle tilsette p skulen. Dei tilsette er sett
saman av same objektklassene som elevane, med berre sm forskjellar i
semantikken. dateOfBirth er valfritt for elevar ogs, men det er
mindre sannsynleg at dette vert lagt inn p tilsette. "owner" vert
sannsynlegvis heller ikkje brukt, men kan brukast for la ein
avdelingsleiar manipulere sine understtar.
GREIN 3: organizationalUnit: Kontakt
I denne greina finn vi personopplysningar om alle eksterne
kontaktpersonar. Greina finnest hovudsakleg for ha opplysningar om
elevane sine foresatte, men det er fritt fram leggje inn andre
(seljarar, sensorar osv.) Praktisk som ei felles adressebok for
skulen. "objectClass: inetOrgPerson" vert brukt.
GREIN 4: organizationalUnit: Klasse
Her ligg alle klassene/faga registrert. I smskulen vil ein vanlegvis
ha berre ei klasse ("2B"), kanskje to ("2B" og "2B gym"). Generelt
har ein eigne "klasser" for kvar undervisningsaktivitet der anten
elevar eller lrar er forskjellige.
Kvart klasseobjekt er av typen "objectClass: lisClass". Attributtane
er:
owner: Ansvarleg lrar (skrivetilgang til objektet)
teacher: Peikar til lrar som er med p denne undervisnings-
aktiviteten
student: Peikar til student som er med p ...
timeAndPlace: Spesifikasjon av tid og stad for aktiviteten
seeAlso: Peikar til klasseobjekt som elevlista skal kopierast
fr.
Alle desse attributtane er valfrie og kan ein eller fleire verdiar.
Merk at ein lrar m leggjast inn som "teacher" sjlv om han str
oppfrt som "owner".
|
