Hej folkens,
Her er en opsummering af nogle af konklusionerne fra g�rsdagens m�de om
beboerdatabaser, s�dan at alle pointerne ikke g�r i glemmebogen. F�lgende er mest min
egen opfattelse af konklusionerne omkring den optimale opbygning af databasen, s� hvis
I er uenige eller har tilf�jelser h�ber jeg I vil skrive dem ogs�.
Det er skrevet FAQ-style:
* Skal man have en database?
Ja, hvis man har nogen, der p�lideligt og j�vnligt kan opdatere den er det en klar
fordel. Det er f�rst og fremmest en stor administrativ lettelse. Den er ogs� vigtig
som en kontrolforanstaltning til at identificere folk med brugernavn/password.
IP-adresser, computernavne og Mac-adresser er ikke brugbare, da disse oplysninger er
offentligt tilg�ngelige.
* Hvorn�r skal man lave den?
S� snart som muligt efter at man har f�et sin server op at k�re.
* Hvem skal ajourf�re den?
Det er bedst, hvis kollegiekontoret kan overtales til at g�re det. Husk, at som regel
er det system I kan lave, bedre end det de har. Den overvejende grund til ikke at have
en database er, hvis man ikke p�regner at kunne ajourf�re den.
* Hvem skal v�re I den?
S� vidt som muligt skal alle beboere v�re i den, ogs� selvom de ikke er p� nettet. En
komplet database er mere end dobbelt s� god som en halv database.
* Hvilket system skal vi bruge?
Der findes s� vidt vides ikke noget fikst og f�rdigt, da der er mange individuelle
behov. Men det kan betale sig at drage p� andre kollegiers erfaringer (skriv til denne
mailingliste og sp�rg!). Det er dog bedst at bruge f�rdigepakkede systemer, som er
dokumenteret mv. Ren� fra Tingbjerg foreslog at bruge Horde-systemet (www.horde.org),
som en ramme for systemet. Det er en god id�, selvom systemet langt fra kan bruges som
det er, men vil kr�ve en del finpudsning (php-programmering). Det er noget som Kbhkol
ogs� selv vil kigge n�rmere p�.
* Hvilke brugernavne skal vi bruge?
1) Brugernavn og email-adresse b�r ikke v�re ens
2) Brugernavn b�r ikke v�re knyttet til et v�relse, men til en person. I databasen
st�r der, i hvilket v�relse personen bor p�.
3) Beboer b�r selv v�lge brugernavn og email
4) Der b�r blokeres for mail til brugernavnet (s�dan at et bestemt brugernavn ikke
kan �del�gges af spam)
5) Email'en b�r laves via aliases (s� kan de skiftes, og man kan have flere end 1)
Ang�ende 4) vil det nok have uheldige bevirkninger totalt at lukke for mail til
brugernavne. Det bedste ville v�re kun at lukke for mail udefra kollegiet (eller det
som ikke er fra localhost).
* Hvad med passwords?
Password b�r aldrig opbevares i klartekst. Gem det krypteret eller md5-hashet. Giv
alle et password p� papir n�r de flytter ind, hvis muligt.
* Hvad med fremlejer, interne flytninger og fraflytninger?
Fremlejere er ogs� en slags lejere, og skal derfor kunne f� brugernavn. Dette
brugernavn skal have en udl�bsdato.
Interne flytninger frembyder kun en vanskelig at lave, s�fremt man har indbygget
v�relsesnummeret i brugernavnet. V�lg derfor brugernavne efter ovenst�ende anvisninger.
Ved fraflytninger b�r systemet tillade at post i en bestemt periode sendes videre til
en anden adresse (via aliases). Kontoen b�r dog nedl�gges straks ved fraflytning
(ellers f�r man problemer med at h�ndh�ve netv�rksreglerne).
* Hvad med grupper, udvalg og mailinglister?
Har du en database vil alt dette v�re betydeligt lettere at lave.
Mvh
Espen,
H�rhus Kollegiet
_______________________________________________
kbhkol mailing list
[EMAIL PROTECTED]
http://kbhkol.dk/mailman/listinfo/kbhkol
