Denna handledning är avsedd för dig som är ansvarig för databasen i Elektrosektionens Studieresekommitté. Handledningen är skriven av Erik Åman i SRKA2001 och är tänkt att gå i arv till kommande databasadministratörer efter eventuell uppdatering.
Handledningen omfattar bara det som är specifikt för SRKs databas och förutsätter att du har någorlunda kunskaper i de tekniker som används (främst SQL, Perl och HTML). Den här texten kan naturligtvis inte innehålla all information, så dra dig inte för att fråga din företrädare om du behöver mer hjälp.
Databasen är till för att hålla reda på framförallt aktiviteter, medlemsuppgifter och kontakter med företag. Du som databasansvarig kan naturligtvis utvidga databasen ännu mer. Genom databasen förs uppgifter om lämpliga företag och kontaktpersoner vidare bland Elektros studieresor. Alla medlemmar kan hämta uppgifter och skriva in ny information, t ex i samband med företagskontakter. Det är också väldigt praktiskt att alltid kunna ha färska uppgifter om adress och telefonnummer till alla medlemmar.
Ett problem med att ha databasen åtkomlig via webbgränssnitt har varit att när man sitter hemma och talar med ett företag per telefon, har man oftast inte direkt tillgång till databasen, utan man får ladda ner alla uppgifter man behöver, föra anteckningar på papper och därefter föra in dem i databasen. Detta problem borde bli mindre i och med att bredbandsuppkoppling hemma blir vanligare.
Att använda databaser för att hålla reda på företagskontakter verkar ha en lång tradition i Elektros Studieresa. På en diskett i SRK-rummet hittade jag en FileMaker-databas där uppgifterna om inkomster om inkomster sträckte sig ända till SRKB89.
Datasektionens studieresa Studs har en databas som utgår från samma källkod och också använder Oracle-databasen genom www.e.kth.se.
Databassystemet består av en stor uppsättning Perlfunktioner som kommunicerar med en SQL-databas för att ta fram uppgifter som presenteras som webbsidor.
Databasmotorn av version Oracle 8.0.5 används förutom av SRK också åtminstone för kursvalsystemet på Elektro. Oracle 8.1.5 verkar vara installerat, men jag vet inte varför jag inte har använt den... För att kommunicera med databasen via kommandorad använder man programmet sqlplus som gömmer sig i katalogen /misc/commercial/oracle/cur/app/oracle/product/8.0.5/bin/. Innan dess måste man dock ha kört ett login-skript. Mitt shellskript ("srkdatabas") för att starta databasen ser ut såhär:
#!/bin/tcsh source /misc/commercial/oracle/cur/home/.login sqlplus srka@public
Skaffa genast ett gratis konto på http://technet.oracle.com/ för att få läsa Oracles svårbegripliga dokumentation bestående av gigantiska HTML-sidor med oläsliga illustrationer. Jag hade själv aldrig sett en rad SQL innan jag blev databasansvarig, så jag hittade en interaktiv snabbkurs. När jag lärt mig lite mera, hade jag stor nytta av tipsen på SQL for Web Nerds.
Här är en liten beskrivning över de tabeller som finns i databasen och vad som lagras i dem för att du ska få en överblick så snabbt som möjligt. Titta gärna i filen db_init.Oracle.sql (som du ska använda för att initiera databasen första gången) medan du läser det här. Observera att jag har gjort flera förändringar i tabellstrukturen medan jag har varit ansvarig för databasen. Jag har försökt komma ihåg att alltid uppdatera initieringsfilen, men det kan finnas någonting som jag har missat.
Här är en genomgång av de tabeller som finns i databasen. De är i stort sett sorterade så att de som är lätta att förstå sig på kommer först och de komplicerade tabellerna som kräver att du förstått de tidigare kommer sist.
Medlemstabellen innehåller diverse personuppgifter om varje medlem. Uppgifterna kan ändras av medlemmen själv och ses av alla medlemmar. Födelsedatumet visas dock inte för andra (integritetsskäl?). Lösenordet finns också i den här tabellen, men uppdateras f n inte automatiskt i .htaccess om en medlem ändrar uppgifterna i databasen.
I den här felstavade tabellen lagras de uppgifter som medlemmarna matar in innan de har blivit godkända som medlemmar av databasadministratören. Det är nästan samma fält som i medlemstabellen, men när jag har ändrat fältstorleken i MEDLEM har jag inte orkat uppdatera den här tabellen.
Här lagras information om företag som vi kontaktar och information om en kontaktperson. Varje företag har en status som anger om företaget har kontaktats, köpt något av oss, etc. Att ha en status för varje företag är dock ganska onödigt med nuvarande databaslayout, eftersom informationen lagras för varje enskild aktivitet istället. I företagstabellen finns också information om vilken medlem som är huvudansvarig för företaget.
I denna tabell finns kommentarer (även kallade dagboksanteckningar eller kontaktposter som man fyller i när man har varit i kontakt med ett företag. Det framgår vilket företag det gäller och vilken medlem som gjort anteckningen när.
Väldigt lik FORETAG, men innehåller istället information om företag som deltar vid seminarier. Förmodligen i separat tabell därför att man talar med helt andra personer på företagen när man diskuterar seminarier än när man diskuterar andra arrangemang. Vi i SRKA2001 har inte använt databasen för det enda seminarium som vi hade.
Här stoppar man väl in kommentarer till seminarierna om man använder de funktionerna.
Här lagras uppgifter om Studieresans arrangemang såsom branschdagar, företagsbesök, möten mm. De är bra att ha i databasen både för att medlemmarna får tillgång till den snygga kalendern där man kan kolla att arrangemang inte krockar med varandra och för att man ska kunna knyta företag till aktiviteter. Datum, tid och plats lagras för varje aktivitet. Den som anges som ansvarig (ägare) har alltid rätt att modifiera aktiviteten. Om det som finns i fältet "pryl" är booleskt sant, innebär det att detta inte är någon egentlig aktivitet. I stället är det bara ett sätt att samla ihop företagen i grupper. I SRKB2000 användes prylaktiviteter bl a för att hålla reda på vilka medlemmar som skulle ringa vilka företag inför seminarier och företagspresentationer.
Jag vet ärligt talat inte vad "fda" står för, men har efter moget övervägande bestämt mig för att det bör läsas ut "företagsdeltagandeattribut". Den här tabellen modifieras aldrig medan databasen används, utan innehåller konstanta värden (om inte du som databasansvarig ändrar något). Dessa värden anger vilken typ av attribut som ska gå att stoppa in i tabellen FORETAGSDELATGANDE.
För varje attribut finns en sträng som identifierar attributet, attributets namn på svenska samt attributets typ. Det finns också ett fält för sorteringsordning. När det finns många attribut blir det nämligen snyggt om de kommer i lågon naturlig ordning och då sorterar man efter det här fältet.
Exempel på attribut kan vara vilket datum som någon ringde till företaget och berättade om aktiviteten eller hur många ölkuponger som företaget vill ha.
Den här tabellen är starkt förknippad med FDA ovan, men i denna tabell lagras själva attributen som gäller ett visst företags deltagande vid en viss aktivitet. För varje attribut finns information om vilken aktivitet och vilket företag som den hör till. Det kommer normalt att finnas flera attribut som har att göra med ett visst företag och en viss aktivitet, så det blir många rader i den här tabellen som normalt presenteras tillsammans för användaren. På varje rad finns också uppgifter om vilken typ av attribut (fda) som det rör sig om och naturligtvis attributets värde. Värdet lagras alltid som en sträng, men ska gå att omvandla till den typ av värde som anges av attributets fda. Typkontrollen är dock för närvarande dålig, så det går att stoppa in felaktiga värden.
Nu blir det ännu krångligare. Olika aktiviteter kräver naturligtvis olika typer av attribut. Exempelvis finns det ingen anledning att kunna ange antalet frukostgäster vid en företagspresentation på kvällen, men för en branschdag behövs det många olika attribut. Denna tabell löser det problemet genom att möjliggöra att man för varje aktivitet anger vilka attribut som ska vara tillåtna. Det finns på varje rad i tabellen uppgifter om vilken aktivitet och vilket attribut det gäller samt om just det attributet ska användas vid just den aktiviteten. När någon skapar en ny aktivitet, förses den men förvald information om vilka attribut som ska finnas. Kolla igenom förvalen så att de blir lämpliga. När jag skapade tabellen såg jag nämligen bara till att de blev bakåtkompatibla genom att det blev exakt samma som fanns tidigare om användaren inte anger något.
Tabellen fungerar ungefär på motsvarande sätt som FDA, men här är det frågan om medlemsdeltagandeattribut. Den innehåller också ett fält för skydd där man kan ange att enbart databasadministratören ska få modifiera ett visst attribut. Detta blev nödvändigt när jag ville se till att en person som var ansvarig för en branschdag också skulle kunna modifiera informationen om samtliga anmälda företag. Då införde jag attributet "Får modifiera kopplade företag" som för den branschdagen och den medlemmen innehöll värdet "Ja". Däremot var det ju viktigt att inte vem som helst skulle få lägga till ett sådant attribut för sig själv.
De attribut som finns i tabellen för närvarande rör bl a frågan om medlemmen skulle vara närvarande, om medlemmen sedan var närvarande och om medlemmen får modifiera de kopplade företagen. Observera att som databasen fungerar idag, så måste man fylla i "Ja" för attributet "Berörs av aktiviteten" för att den ska dyka upp i kalendern som förval. Det är väldigt svårt att förklara för användarna att det inte räcker med att medlemmen "har obligatorisk närvaro" utan att man också måste fylla i att medlemmen "berörs av aktiviteten", så detta borde fungera annorlunda.
Den här tabellen fungerar för kopplingar mellan mmedlemmar och aktiviteter på samma sätt som FORETAGSDELTAGANDE fungerar för företagskopplingar. Här lagras alltså själva värdena som rör en aktivitet och en medlem. Om man skapar en aktivitet som man kopplar 20 medlemmar till och varje medlem får tre attribut, så kommer det att gå åt 60 rader i den här tabellen.
Den här ska väl innehålla möjliga seminariedeltagarattribut, men jag har inte arbetat något med sådana.
Föga förvånande stoppar man här in själva attributen för något företags deltagande vid ett seminarium.
Det här är en tabell med relativt konstant innehåll där varje rad innehåller en gruppbeteckning och gruppens namn på svenska.
Här lagras det vilka grupper som medlemmarna är med i. Detta kan medlemmarna själva redigera och informationen här används med fördel för att hålla e-postaliasen uppdaterade. För varje grupp som någon är med i skapas det en rad i den här tabellen med medlemmens och gruppens id.
Medlemmar i gruppen admin betraktas som databasadministratörer och har därmed oinskränkt rätt att göra vad de vill.
Det skulle naturligtvis vara en stor katastrof om alla uppgifterna i databasen försvann. Jag fick ett läfte från systemgruppen förra året om att de skulle börja ta backup av innehållet i databasen, men ingen riktig bekräftelse på att de verkligen gör det. För säkerhets skull har jag regelbundet spottat ut alla data till textfiler, så att jag kanske med mycket möda skulle kunna återskapa infromationen.
Det kan ta ganska lång tid innan man lyckat sätta sig in i funktionerna så mycket att man vågar göra några större ändringar. I stort sett är det så att för varje tabell i databasen finns det en fil med funkioner som hanterar objekt i den tabellen. Dessutom finns det ytterligare Perlfiler med funktioner som behöver anropas från många av de andra och filer med funktioner för sökning, startsida, etc.
Lite förvirrat kan det bli av att flera personer med olika stil på programmeringen har bidragit till koden. Jag (Erik Åman) har både gjort diverse små förändringar här och var i koden och skrivit helt nya funktioner för sökning och valbar layout. I de gamla funktionerna är det i stor utsträckning så att det finns många funktioner som ser nästan likadana ut, men skiljer sig i några detaljer därför att de hanterar olika objekt. När jag skrivit helt nya funktioner har istället försökt göra någorlunda generella funktioner och använt subrutinanrop mycket mer flitigt. Dessutom har jag försökt att ta bort allt HTML-specifikt från den del av koden som hanterar databaslogiken och flyttat funktionerna för presentation till en separat fil.
Namnen på SQL-tabeller och kolumner är på svenska, men i Perlfunktionerna är det i allmänhet variabelnamn på engelska.
Funktioner för att skapa, manipulera och visa aktiviteter, men inte fda och mda som hanteras huvudsakligen i egna filer.
Här har vi de funktioner som hanterar data om vilka fda som ska kunna finnas för kopplingarna mellan en viss aktivitet och något godtyckligt av företagen. Har vissa likheter med mda.pl och fda.pl.
För närvarande någon hophafsad funktion för att skapa placeringslistor till webbsidor för branschdagar.
Funktioner för att visa en ganska snygg kalender med aktiviteter. De gör sitt jobb så bra att jag inte har funnit anledning att peta så mycket i den här filen.
Vanligt bibliotek för att tolka CGI-argument.
Kollar att den som försöker använda databasen själv finns med i densamma. Även funktioner för rättigheter för gäster (=nya medlemmar) och administratör.
Funktioner för sidhuvud, sidfot, felmeddelanden, datumhantering och inmatning av fda och mda.
Funktioner för att skapa, manipulera och visa företag. Även funktioner för att skapa dagboksanteckningar om företag, men dessa kan f n inte ändras eller tas bort.
Skapar databasens startsida.
För varenda objekttyp ska det finnas funktioner för att skapa, hämta information, modifiera och radera det. Dessutom finns det t ex funktioner som svarar på om en medlem äger ett visst objekt eller om medlemen i fråga har rätt att redigera det. Här är det tänkt att allt som är Oracle- och SQL-relaterat ska finnas för att göra resten av databasen oberoende av dataabasmotorn. Några SQL-satser finns dock också i search_funcs.pl.
Visar några olika övningsuppgifter och tips som medlemmarna bör gå igenom för att lära sig använda databasen. Gör egentligen inga databasförfrågningar och skulle egentligen kunna sparas som statiska HTML-filer. Några detaljer i övningarna kan vara inaktuella eftersom databasen har utvecklats under året och någon ny övningsuppgift borde kanske tillkomma.
Hanterar företagsdeltagandeattributen, dvs att knyta företag till en aktivitet.
Hanterar studieresans grupper och vilka som är med i dem.
Hanterar medlemsdeltagandeattributen, dvs att knyta medlemmar till en aktivitet. Ganska stora likheter med fda.pl naturligtvis.
Funktioner för att hantera medemsuppgifterna. Medlemmarna kan redigera uppgifterna om sig själva och se uppgifterna om de andra.
Funktioner för att de nya medlemmarna ska kunna registrera sig och för att databasadministratören sedan ska kunna göra dem till fullvärdiga medlemmar genom att flytta över dem till tabellen MEDLEM.
Om användaren avbryter medan han håller på att registrera uppgifter om sig själv i databasen, kommer han eller hon inte att kunna återuppta registreringen med samma användar-id. Den databasansvarige får då radera motsvarande rad från tabellen WANNABEE.
En inte helt färdigutvecklad uppsättning funktioner för att skapa tabeller, rubriker, formulär mm i HTML och på så sätt göra resten av databasen oberoende av presentationen. Används dock ännu bara från search.pl och search_funcs.pl.
Seminariedeltagandeattributen. Observera att jag inte har använt dessa funktioner och att någonting kanske borde uppdateras om den ska funka bra. Ursprungligen en modifiering av fda.pl.
Låter användaren söka bland företag, medlemmar, fda och mda med hjälp av funktionerna i search_funcs.pl.
Denna fil innehåller funktionerna för att söka bland olika objekt och presentera resultatet med en någorlunda konfigurerbar layout. Här används i allmänhet många subrutinanrop och parametrar till varje funktion. Den här filen kan därför vara lite svårare än de övriga att begripa sig på. Avsikten är dock att det ska vara lätt att återanvända och bygga ut koden.
Företagen som deltar på seminarier. Observera att jag inte har använt dessa funktioner och att någonting kanske borde uppdateras om den ska funka bra. Ursprungligen en modifiering av foretag.pl.
Visar statistik om totala inkomster och bäst betalande företag.
Här finns information om de tabeller som man kan söka i. Det är till viss del samma information som finns i SQL-databasen, men på ett format som är lätt för Perlfunktionerna att använda sig av. Datastrukturerna här talar om vad fälten heter, hur man kommer åt dem, vilken typ av data det är mm. Avsikten är att en gång i en avlägsen framtid så ska informationen om tabellstrukturen endast finnas här och inte utspridd runt om i koden. För närvarande är det dock bara search.pl som använder denna information. Tabellerna FDA och MDA är redan gjorda i samma anda (så att man inte behöver ändra koden för att man inför ett nytt attribut) och därför finns funktioner i denna fil för att läsa dessa tabeller och översätta dem till samma datastrukturer.
Något som calendar.pl använder för att ta reda på vad klockan är slagen. Bör ses över i god tid före år 2038 (då det råkar ha gått 231 sekunder sedan 1 januari 1970).
Symbolisk länk till new_member.pl.
Något slags guider och trollkarlar som bl a ska underlätta att skapa nya aktiviteter. Jag har dock försummat underhållet av denna fil när jag har gjort ändringar i databasen, så den går inte att använda utan modifieringar.
Ett praktiskt sätt att kunna hålla ordning på vilka ändringar man gör i filerna är att använda RCS (Revision Control System). I med hjälp av det systemet kan man checka ut en fil, modifiera den och därefter checka in den. Visar det sig att man har gjort bort sig när man modifierade filen, kan man när som helst återgå till en tidigare version. 'man rcsintro' ger mer information.
Enklast är att använda RCS-funktionerna i Emacs. Åtminstone i XEmacs på elektro kan man välja t ex Tools->VC->Check in File filnamn.pl. Observera att det står "check in" även när man checka ut... När man sedan checkan in filen får man ange en kommentar med vad man har gjort för ändringar. Tangentbordskommandona är C-x v v för att checka ut eller in och C-c C-c för att avsluta inmatning av kommentar.
Det måste finnas en medlem med id ingen. Den skapas automatiskt av initieringsskriptet och är exempelvis ansvarig för nya företag innan någon riktig medlem har tagit på sig ansvaret.
Du som är databasadministratör har naturligtvis oinskränkt makt att göra vad som helst i databasen. När man prövar nya funktioner kan det vara bra att använda ett användarkonto som tillhör en "vanlig medlem". Jag skapade användaren Ture Teknolog (e17_qqq) för att ha i testsyfte. När de övriga medlemmarna håller på och lär sig databasen, kan de också använda testanvändaren till att koppla till aktiviteter m m.
Ibland känns databasen lite slö när det tar flera sekunder fråndet att användaren klickat någonstans tills det börjar hända någonting. Det finns flera orsaker som samverkar till det. Efter att en förfrågan har skickats till webbservern, måste Perl tolka den fil som funktionen finns i och alla filer som den använder. Därefter måste det öppnas en förbindelse till databasmotorn, dvs en konstant (men lite för lång tid). När så Perlfunktionen har exekverat en stund till och skickat en SQL-fråga, kan det ta ganska lång tid för databasmotorn att tolka den och sammanställa resultatet. Ibland ska det göras flera förfrågningar till databasen. Sen ska naturligtvis resultatet tas emot av Perlfunktionen, behandlas och skickas till användarens dator där webbläsaren tar en stund på sig att rendera sidan.
Om du är skicklig, kan du säkert optimera några moment. Annars kan du trösta dig med att det var värre förr. Tidigare tog det två minuter varje gång man ville lista samtliga företag i databasen, eftersom det krävdes två (eller var det tre) förfrågningar till databasmotorn för vart och ett av de över 700 företagen. Med nuvarande funktioner går det på en betydligt kortare tid som beror mer på användarens anslutningshastighet.
Eller: Hjälp! Jag har just blivit vald till databasansvarig i Studieresan. Vad gör jag nu?
Kontakta förra årets databasansvarige och läs igenom den här texten, så är du en god bit på väg.
Till att börja med måste den nya studieresan få en hemkatalog, förslagsvis i /misc/projects/esekt/. Det är du eller den som är ansvarig för webbsidorna som får be systemgruppen om det. Det skapas inte något nytt användarkonto för studieresan, utan de som får skriva i hemkatalgen är medlemmar i en AFS-grupp som någon i Studieresan får administrera.
Systemgruppen ska också se till att fixa ett användarkonto åt studieresan i deras Oracledatabas. Försök alltså att hitta någon som har kompetens till att ordna det. För att databasen sedan ska fungera som tidigare så ska uppgifterna om användarnamn och lösenord också lagras i en fil som heter något i stil med /etc/athena/sqlsrkb2000. Detta syns dock bara i webbserverns filsystem om jag har förstått det rätt. Denna fil kommer sedan att läsas från Perlprogrammen så att de kan komma åt databasen
Systemgruppen ska också ordna en katalog att köra cgi-skript i. I den måste det finnas en "suid-wrapper" (tror jag det heter) som ägs av root och i sin tur ser till att exekvera de Perlfiler som du lägger i samma katalog.
Sätt dig in i hur databasen fungerar ur ett användarperspektiv genom att titta på föregående års databas.
Skapa din egen databas och sätt igång att leka lite med den tills du tycker att du känner den tillräckligt väl. För att få använda databasen via webben måste databasen betrakta dig som medlem. För att få skapa en medlem måste man dock först själv vara en medlem som är med i administratörsgruppen. Att lösa den här moment 22-situationen är kanske en bra första övnngsuppgift.
Sedan bör du få hjälp med att kopiera över alla relevanta uppgifter från föregående års databas till den nya.
I samarbete med den webbansvarige ordnar du med rättigheter att komma åt Studieresans interna webbsidor (där databasen ingår). I den skyddade katalogen ska det finnas en fil som heter .htaccess som lämpligtvis hänvisar till andra filer som innehåller information om grupper och lösenord och begränsar åtkomsten till medlemmar i en viss grupp. Gör likadant som föregående år eller läs i dokumentationen till Apache om ni inte vet hur man gör.
Börja med att skapa en tillfällig användare som ska kunna komma åt en webbsida med information om registreringen och databasen. Tala om användarnamn och lösenord för alla i Studieresan och uppmana dem att gå till registreringssidan med länk till new_member.pl för att registrera sig.
Kolla att informationen som kommer in verkar rimlig. Gör användaren till fullvärdig medlem i databasen och se till att medlemmens lösenord funkar med kommandot htpasswd (i /usr/local/vol/www/apache/cur/bin/).
Se till att reservera någon tid på ett stormöte eller annan tid när ni träffas för att tala om för medlemmarna hur databasen fungerar. Jag rekommenderar att använda videoprjektor kopplad till datorn och visa hur man gör några vanliga saker i databasen. Jag använde bara stillbilder och uppmanade medlemmarna att lära sig själva, men alla var inte tillräckligt intresserade för att göra det. Om du inte har tillgång till en sal med lämplig projektor, så kan du hyra hos Teknisk Service i E-huset för ca 600 kr. Det är väl investerade pengar för Studieresan.
Försök dessutom att få medlemmarna att testa så mycket som möjligt själva. De kan skapa nya företag och aktiviteter och koppla dem till varandra för att förstå hur databasen fungerar.
Förklara att det är viktigt att all information skrivs in databasen så att man har all korrekt infromation på rätt ställe. Inför Elarm skrev vi inte in all information från anmälningsblanketterna i databasen och det blev en väldig massa bläddrande bland papperen varenda gång man skulle räkna samman något.
Det är lämpligt om alla medlemmar har en uppsättning företag som de är ansvariga för, åtminstone när alla företag ska kontaktas inför de stora branschdagarna. Däremot behöver inte samma fördelning gälla inför mindre eller mer nischade aktiviteter.
I SRKB2000 lät de medlemmarna få exempelvis vart 40:e företag (om de var 40 medlemmar). Vår branschdagschef gav istället varje medlem ca 20 företag som låg nära varandra i bokstavsordning. Jag rekommenderar den senare metoden eftersom det då är stor chans att man får företag inom samma koncern och därmed undviker att flera medlemmar talar samma kontaktperson på ett företag. Dock kan det bli lite orättvist när det visar sig att den medlemmen bara har en person att ringa till för alla de tio företagen i koncernen.
Det finns f n ingen funktion för att på ett enkelt sätt tilldela en medlem flera företag samtidigt.
Det är mest praktiskt att den databasansvarige har hand om att administrera Studieresans e-postlistor.
Systemgruppen ska redigera filen /usr/local/staff/mail/aliases.local för att lägga till e-postalias som hänvisar till filer som finns i studieresans hemkatalog. Se till att få ungefär motsvarande alias som föregående studieresa med undantag för arrangemangsspecifika adresser. Elarm kan dock vara bra att ha med redan från början. Adresserna ska vara av typen srkb2002.någonting@e.kth.se med undantag för elarm@e.kth.se. srkb2002@e.kth.se blir lämpligtvis adressen till styrelsen. Under året kan det behövas e-postadresser för vissa arrangemang. Säg till medlemmarna att de kan be dig om det och skapa en fil som anger vilka som ska få breven till den adressen innan du skickar begäran vidare till systemgruppen. Se till att medlemmarna bestämmer sig för exakt vilken adress de vill ha, så att de inte ansöker om "itdagen" men trycker "it-dagen" i någon broschyr.
Du kan felsöka e-posten med SMTP-kommandot expn såhär:
telnet elixir smtp Trying 130.237.48.5... Connected to elixir.e.kth.se. Escape character is '^]'. 220 elixir.e.kth.se ESMTP Sendmail 8.9.3/8.9.3; Sat, 21 Oct 2000 17:20:03 +0200 (MET DST) expn srka2001.www 250-<ea@ebox.tninet.se> 250 <\e95_eam@elixir.e.kth.se> quit 221 elixir.e.kth.se closing connection Connection closed by foreign host.
E-postadresserna till olika grupper uppdaterar du naturligtvis genom att titta vilka som har angett i databasen att de är med i gruppen. Om du är lite vågad och skicklig av dig, bör du kunna se till att det uppdateras helt automatiskt i filen för e-postaliaset när någon anger sig tillhöra en grupp i databasen. Några e-postalias kanske man administrerar genom att berörda medlemmar får skicka ett brev till dig och tala om att de vill vara med. Det kan dock bli lite rörigt, så det bästa är nog att ha ett ett-till-ett-förhållande mellan grupper i databasen och e-postalias, så att det inte behöver bli några oklarheter.
Den databasansvarige och/eller den webbansvarige bör också se till att de medlemmar och grupper som behöver får utrymme att spara dokument i någon underkatalog till Studieresans hemkatalog. Branschdagsgruppen i SRKA2001 behövde en hel del utrymme för att spara annonser till katalogerna. Det var inga problem att få diskkvotan ökad till 200 MB när vi bad om det. Använd gärna grupper (med hjälp av kommandot 'pts') för att bestämma vilka som ska få göra vad i vilka kataloger. Manualer om AFS-systemet bör innehålla information om hur man gör det.