Tags:
create new tag
, view all tags

nethz cronjobs

Crontabs

Cronjobs sind periodisch ablaufende Programme. Im Fall von nethz sind dies Perl-Skripte. Der Aktuelle CronTab (Auflistung aller aktiven Jobs) kann man als User w3_idn mit dem Kommando crontab -l auflisten.

Um den crontab zu ändern, sollte nicht das übliche Kommando crontab -e ausgeführt werden, sondern mit

  • das File ~/conf/crontab editieren
  • stop crontab Crontab stoppen
  • start crontab Crontab starten

angepasst und installiert werden. Damit wird sichergestellt, dass beim Verschieben der Instanz der Crontab erhalten bleibt.

DBMS Jobs

Neben cronjobs laufen auch sog. DBMS Jobs ab, welche direkt auf der nethz-Datenbank gespeichert sind. Sie sind in der Programmiersprache von Oracle, PL/SQL, geschrieben. Der cronjob check_dbms_jobs.pl prüft rebgelmässig, ob alle eingetragenen Jobs auch wirklich fehlerfrei laufen und ob eventuell suspendierte Jobs vorhanden sind.

Kurzübersicht

Alle cronjobs sind von der nethz-DB abhängig. Die zusätzlichen Abhängigkeiten der cronjobs von externen Maschinen sind in der folgenden Tabelle ersichtlich.

Programm Beschreibung Logfile Abhängigkeiten
delete_mail_lists.pl löscht die temporären Studenten-Emaillisten auf Exchange   AD
do_delete_after.pl Dieser Cronjob löscht abgelaufene Services definitiv do_delete_after.log Alle
do_login_until.pl Setzt bei allen GRANTED_SERVICE mit ENABLED=1 und LOGIN_UNTIL < sysdate das ENABLED - Flag auf 0. Das Passwort wird neu gesetzt do_login_until.log Alle
ethstud.pl Erstellt das File ethstud.txt auf ftp.ethz.ch   scp nach weasel.ethz.ch
get_ngroups.pl Schreibt alle Ngroups (Authorisierungsgruppen) in ein Export-File für LDAPS. Muss vor put_ngroups.pl laufen ngroups LDAPS
isg_mail_warning.pl Schickt allen ISLs und Gruppenadmins eine Warnung, dass sie ihre Mitglieder bestätigen müssen. http://isg-tool.ethz.ch/   sendmail
mail_warning.pl verschickt Mails, welche von einem ablaufenden nethz-Service informieren mail_warning.log sendmail
put_ngroups.pl Stellt die Unterschiede in den Ngroups-Zugehörigkeiten fest und aktualisiert das Attribut ou der Userobjekte im LDAPS-Directory ngroups, ngroups.errlog, ngroups.processing, ngroups.previous, ngroups.result LDAPS
schedule_execute.pl führt alle PERSON create, UNAME create, SERVICE grant und SERVICE limit Befehle der Tabelle SCHEDULE aus schedule_execute. yyyy.mm.dd_hh:mi:ss. afs_cmds Alle
schedule_pdb_check.pl Arbeitet alle Jobs der Tabelle SCHEDULE mit den Angaben OBJECT_CLASS = 'PERSON', ACTION='check' ab. Überprüft den ETH-Status und erstellt entsprechende neue Jobs, z.B. PERSON 'create', UNAME 'create' und SERVICE 1 'grant', SERVICE 2 'limit' etc. (SCHEDULE-Tabelle) DLDB-Views (PDB)
schedule_pdb_jobs.pl arbeitet die PDB-Schnittstellentabellen SS_NETHZ_AUTH und SS_NETHZ_DIENT ab und erstellt Datensätze in der Tabelle SCHEDULE (SCHEDULE-Tabelle) SS-Views (PDB)
spamfilter.pl Aktualisiert die opt out, white- und blacklist für den nethz Spamfilter   scp zu phil1 und phil2
update_AD.pl Aktualisiert die Attribute im Active Directory / Exchange: Postadresse/Telefon/Company/Department etc update_AD.log, update_AD.errlog AD
update_Emails_from_PDB.pl Alle Emails von der PDB, die nicht mit dem Admin_Tool erstellt wurden, werden mit diesem Job übernommen   DLDB-Views (PDB)
update_LDAPS.pl aktualisiert alle Attribute für alle Einträge ausser das OU-Attribut im UNIX-LDAPS   LDAPS
update_Ngroup_Domain.pl Aktualisiert alle Domänen-Ngroups    
update_Ngroup_Exchange.pl Aktualisiert die Ngroups im AD update_Ngroup_Exchange.log, update_Ngroup_Exchange.errlog AD
update_Ngroup_MA_LZ.pl Aktualisiert alle Leitzahlen-Ngroups (Mitarbeiter)    
update_Ngroup_Students.pl Aktualisiert alle Studiengang-Ngroups (Studierende)    
update_Person_from_PDB.pl Aktualisiert die aktuellen Angaben zur Person (Adresse, Nachname, IS_STUDENT, IS_LECTURER, IS_GUEST, COMPANY, DEPARTMENT update_Person_from_PDB.log, update_Person_from_PDB.errlog DLDB-Views (PDB)
update_Ugroups_by_LZ.pl Mitarbeiter werden Leitzahlen-Usergruppen zugeordnet, Studenten werden der Usergruppe student.ethz.ch zugewiesen update_Ugroups_by_LZ.log DLDB-Views (PDB)
update_Ugroups_orphanage.pl User ohne Usergruppe werden der Gruppe orphanage zugeordnet update_Ugroups_orphanage.log  
update_inbounds.pl Aktualisiert IS_INBOUND und IS_FILTERED der Tabelle EMAIL: Alle Domänen, die der Exchange-Server verwaltet / die gefiltert werden   AD, scp nach phil1.ethz.ch
update_uname_login_until.pl Setzt das Ablaufdatum des Usernames auf dasselbe Datum wie des am längsten gültigen Services update_uname_login_until.log  

aktueller crontab (12.08.2014)

MAILTO=swen@ethz.ch,kdavor@ethz.ch

################################################################################
# Environment variables

PERLBREW_VERSION=0.67
PERLBREW_PERL=perl-5.16.3
PERLBREW_BASHRC_VERSION=0.67
PERLBREW_ROOT=/instances/home/idnp/perl5/perlbrew
PERLBREW_HOME=/instances/home/idnp/.perlbrew
PERLBREW_MANPATH=/instances/home/idnp/perl5/perlbrew/perls/perl-5.16.3/man
PERLBREW_PATH=/instances/home/idnp/perl5/perlbrew/bin:/instances/home/idnp/perl5/perlbrew/perls/perl-5.16.3/bin

#
PERL5LIB=/instances/home/idnp/cronjobs

PATH=/instances/home/idnp/perl5/perlbrew/bin:/instances/home/idnp/perl5/perlbrew/perls/perl-5.16.3/bin:/usr/lib64/qt-3.3/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/instances/home/idnp/bin

ORACLE_BASE=/usr/lib/oracle/11.1/client64
ORACLE_HOME=/usr/lib/oracle/11.1/client64

NLS_LANG="american_america.we8iso8859p9"
TNS_ADMIN="/usr/lib/oracle/11.1/client64/network/admin"
LANG='en_US'



# Admin-Tool generell
*/10      * * *   * ${HOME}/cronjobs/clean_sessions.pl 12 
  30      5 * *   * ${HOME}/cronjobs/update_uname_login_until.pl
   3     18 * *   * ${HOME}/cronjobs/do_login_until.pl
  33     11 * *   * ${HOME}/cronjobs/do_delete_after.pl
   0      7 * *   * ${HOME}/cronjobs/mail_warning.pl
#  32      * * *   * ${HOME}/cronjobs/update_doc.pl
   0 5-20/5 * *   * ${HOME}/cronjobs/schedule_pdb_jobs.pl
   5 5-20/5 * *   * ${HOME}/cronjobs/schedule_pdb_check.pl
  20 5-20/5 * *   * ${HOME}/cronjobs/schedule_execute.pl

################################################################################
# VPP

# VPP billing
# */10      * * *   * ${HOME}/cronjobs/update_vpp_accounting.pl --report-missing-users --email=swen@ethz.ch --log=${HOME}logs/vpp_log_errors.log
# the same without --report-missing-users

*/10      * * *   * ${HOME}/cronjobs/update_vpp_accounting.pl --email=swen@ethz.ch --log=${HOME}/logs/vpp_log_errors.log

# Reporting
  23      1 * *   1 ${HOME}/cronjobs/vpp_report.pl
#   1      1 1 *   * ${HOME}/cronjobs/cmn_report.pl

# Kontakt-Datenbank
  35   7-22 * *   * ${HOME}/cronjobs/kontakt_db.pl

# Sympa
  33      3 * *   * ${HOME}/cronjobs/sync_sympa.pl

# Active Directory und Exchange
  25     21 * *   * ${HOME}/cronjobs/update_Ngroup_Exchange.pl
   0     10 * *   * ${HOME}/cronjobs/update_inbounds.pl
   0     15 * *   * ${HOME}/cronjobs/update_AD.pl
*/20      * * *   * ($HOME/cronjobs/ad.pl SetMissingPosixGroups; $HOME/cronjobs/ad.pl SynchronizeGidNumberWithPrimaryGroupID) 2>&1
   0      1 * *   * ${HOME}/cronjobs/delete_mail_lists.pl
   0      1 * *   * ${HOME}/cronjobs/delete_contacts.pl

# für eine Silva-Applikation (Benno Luthiger)
   0     18 * *   * ${HOME}/cronjobs/sync_funktionstraeger.pl


# check if all DBMS - Jobs on Oracle are up and running
   0      8 * *   * ${HOME}/cronjobs/check_dbms_jobs.pl

# Spamfilter-Einstellungen synchronisieren
*/15      * * *   * ${HOME}/cronjobs/spamfilter.pl >/dev/null  2>&1 

# LDAPS - Synchronisation
   5      9 * *   * ${HOME}/cronjobs/update_Ngroup_LDAPS.pl
  15      9 * *   * ${HOME}/cronjobs/get_ngroups.pl
  45      9 * *   * ${HOME}/cronjobs/put_ngroups.pl
  35      * * *   * ${HOME}/cronjobs/update_LDAPS.pl

# CQ5 - Synchronisation
  41   7-22 * *   * ${HOME}/cronjobs/update_CQ5.pl
   0      7 * *   7 ${HOME}/cronjobs/update_CQ5_slaves.pl 2>&1

# Message-Tree?
   5      * * *   * ${HOME}/cronjobs/spoolmail_send.pl

################################################################################
# ISG tool

#  20     20 * *  1 ${HOME}/cronjobs/isg_mail_warning.pl

Tabelle SCHEDULE

Aufgaben - Übergabe via interne Tabelle: SCHEDULE.

In diese Tabelle können verschiedene cronjobs ihre Aktionen schreiben und andere cronjobs dazu veranlassen, irgendwelche Aktionen auszuführen. Diesselben cronjobs haben die Möglichkeit, irgendwelche Fehlermeldungen in das ERROR-Feld zu schreiben. Das Logfile wird also direkt in der DB geführt. Der Vorteil einer Tabelle liegt darin, dass man "von aussen" irgendwelche Jobs reinschreiben kann.

Die erfolgreiche Abarbeitung eines Jobs wird mit Datum (JOB_DONE_DATE) und einer Anmerkung (JOB_DONE_BY) eingetragen. Im Fehlerfall wird kein neuer Job eröffnet, sondern eine Fehlermeldung (ERROR) und das Datum des letzen Versuchs (LAST_TRY_DATE) eingetragen. JOB_DONE_DATE bleibt leer. Es wird in keine History über die fehlgeschlagenen Versuche geführt. Die letzte Fehlermeldung eines Jobs bleibt erhalten, auch wenn der Job irgendwann einmal erfolgreich abgearbeitet wird.

Feld Datentyp Beschreibung
SCHEDID NUMBER Interner Zähler
PERSID NUMBER Aktion für welche PDB_PERSON
NPID NUMBER Aktion für welche PERSON
NUID NUMBER Aktion für welchen UNAME. Ist keine NUID angegeben, so wird die PRIMARY_NUID von PERSON verwendet.
OBJECT_CLASS VARCHAR2(255) Welche Tabelle (Objekt) ist betroffen? PERSON, UNAME, SERVICE?
OBJECT_ID NUMBER Welcher Datensatz davon? (NULL, wenn ein neuer Datensatz kreiert werden soll)
ACTION VARCHAR2(255) Was soll ausgeführt werden?
ACTION_DATE DATE Wann soll die Aktion ausgeführt werden?
JOB_CRE_DATE DATE wann wurde dieser Job eingetragen
JOB_CRE_BY VARCHAR2(255) von welchem cronjob wurde diese Aktion "in Auftrag gegeben"?
JOB_DONE_DATE DATE wann wurde diese Aktion erfolgreich ausgeführt?
JOB_DONE_BY VARCHAR2(255) von welchem cronjob wurde diese Aktion (das letze Mal) ausgeführt?
WARNING VARCHAR2(255) Warnungen (z.B. "PERSON existiert bereits")
ERROR VARCHAR2(255) Fehlermeldungen, falls Aktion fehlgeschlagen
LAST_TRY_DATE DATE Datum des letzen Versuchs
REASON VARCHAR2(255) Grund für den Job, z.B. 'Exmatrikulation per 31-DEC-2003' bei SERVICE 1 'limit'

Für ACTION sind folgende Werte zulässig: - create: eine PERSON, einen UNAME kreieren - grant: einen Service granten - limit: einen Service limitieren - lock: einen Service sperren

Wenn man eine Person von Hand überprüfen möchte, muss man dies mit einem kleinen SQL-Insert veranlassen:

INSERT INTO schedule
    (schedid , persid, object_class,
     action, action_date, job_cre_date, job_cre_by)
SELECT seq_id.nextval, persid, 'PERSON',
     'check', sysdate, sysdate, 'Swen von Hand'
FROM DLDB_PERSON where persid in (123465);
 
COMMIT;


schedule_pdb_jobs.pl

arbeitet die PDB Schnittstellen-Tabellen SS_NETHZ_AUTH und SS_NETHZ_DIENST ab und schreibt in die Tabelle SCHEDULE Jobs der folgenden Art:

  • PERSID = xy
  • OBJECT_CLASS = 'PERSON'
  • ACTION = 'check'

Da aus den Schnittstellentabellen oft nicht klar ersichtlich ist, was mit einer Person geschehen soll, z.B. PERSON_NEU und PERSON_LOESCHEN derselben PERSID mit identischem MUT_DAT fasst schedule_pdb.pl die verschiedenen Aufträge zu einem einzigen 'check PERSID xy' zusammen. Was wirklich zu tun ist, wird im cronjob schedule_pdb_check.pl abgearbeitet.

Befristete Personen bekommen den Eintrag OBJECT_CLASS = 'BEFRISTET', ACTION = 'create'.


schedule_pdb_check.pl

Arbeitet alle Jobs der Tabelle SCHEDULE mit den Angaben OBJECT_CLASS = 'PERSON', ACTION='check' ab. Überprüft den ETH-Status und erstellt entsprechende neue Jobs, z.B. PERSON 'create', UNAME 'create' und SERVICE 1 'grant', SERVICE 2 'limit'. Die ganze Intelligenz liegt in diesem cronjob. schedule_pdb_jobs.pl und schedule_execute.pl sind dagegen ohne Intelligenz ausgestattet, d.h. sie führen ihre Jobs einfach aus, ohne nachzufragen.

Besonderes

  • Der Parameter ACTION_DATE legt fest, wann die ACTION ausgeführt werden soll.
  • Personen, User und Services werden in der Regel "sofort" kreiert (ACTION_DATE = 'sysdate')
  • ist die Person eine bestehende ETH-Angehörige (MA, Student, Dozent oder Gast), so bekommen bestehende Services ein neues Ablaufdatum. So kann es sein, dass einem Student alle Services ausser dem nethz-Service ablaufen, weil er ETH-Gast ist.
  • Bestehende Services, welche nicht zum Standard-Paket gehören, werden auf die maximale Anstellung resp. Exmatrikulation beschränkt.
  • Die Services des primären Usernamens werden gemäss der aktuellen Anstellung / Einschreibung angepasst.
  • Die Services der übrigen Usernamen werden zeitlich auf die letzte ETH-Beziehung festgelegt.
  • Die Service-Packages für die jeweilige ETH-Angehörigkeit (Student, Mitarbeiter, Dozent, Gast) werden in der Tabelle SERVICE_PACKAGE gespeichert (durch Leerzeichen getrennte NSIDs)


schedule_execute.pl

Arbeitet die Tabelle SCHEDULE ab und aktualisiert/ergänzt PERSON, UNAME und GRANTED_SERVICE. Arbeitet folgende Jobs ab, ohne nachzufragen:

  • PERSON erstellen
  • UNAME erstellen
  • SERVICE erstellen / limitieren

Besonderes

Ist ein Service schon seit mehr als einem Monat abgelaufen, so wird das Ablaufdatum auf "heute" gesetzt. AFS-Kommandos werden in das File /opt/local/apache/home/w3/cronjobs/schedule_execute.afs_cmds geschrieben SCHEDULE-Jobs, welche fehlschlagen, kriegen einen ERROR Eintrag Die Ausnahme bilden jobs wie PERSON 'create', bei denen

  • keine PERSID definiert ist oder
  • auf der PDB keine Person mit dieser PERSID gefunden werden konnte
Logfile

schedule_execute.pl schreibt ein Logfile unter /home/idn/logs/schedule_execute.log

Im Wesentlichen ist dort der Output der AFS-Kommandos enthalten.


mail_warning.pl

Informiert Personen über ablaufende Services ihrer User und Gäste.

Ablaufschema

  1. Usernamen ausfindig machen, bei denen demnächst Services ablaufen werden
  2. Schauen, ob Person noch Anstellungen / Immatrikulationen hat.
  3. Anstellungs- / Immatrikulations-Info auf alle Services seiner User und Gäste übertragen, sofern
    • LOGIN_UNTIL > (max. Anstellung + DAYS_BEFORE_LOCK) - Service spezfisch.
    • LOCKED_BY_NPID's von Gästen werden überschrieben! (Ausnahme: Services laufen früher ab)
    • Gäste in die Liste der zu warnenden Personen hinzufügen. nicht weiterfahren, falls Person noch Anstellungen / Immatrikulationen hat.
  4. Admins von Gästen ermitteln.
  5. Service-Infos holen und Message zusammenstellen.
  6. Mails verschicken

Wann wird eine Mail verschickt?

Sobald ein Service eines Users innerhalb weniger als 30 Tage abläuft, wird automatisch eine Mail generiert und verschickt. Folgende Bedingungen müssen erfüllt sein:

  1. LOGIN_UNTIL < (heute + 30 Tage)
  2. User wurde noch nicht gewarnt

Die Mail enthält eine Liste aller Services dieses Users. Sobald die Email verschickt wurde, wird für die betroffenen Services das Flag NOTIFIED = 1 gesetzt (Tabelle GRANTED_SERVICE).

Empfänger

Der Empfänger der Mail wird nach folgendem Schema ermittelt:

  1. Mail an «Die» Emailadresse
  2. Falls 1. nicht vorhanden, Mail an Mailaccount des primary Uname
  3. Falls Person ein Gast ist, wird eine Mail cc an den Admin dieses Gastes geschickt

Besonderes

Wenn LOGIN_UNTIL oder DELETE_AFTER geändert werden, wird das Flag NOTIFIED = 0 zurückgesetzt. Der User wird erneut gewarnt, falls der Service erneut abläuft.


update_Ugroups_by_LZ.pl

Aktualisiert die Usergruppen-Zugehörigkeit der primary Uname gemäss den Anstellungen der Personen. Neue Leitzahlen erstellen automatisch neue Usergruppen. Aktualisiert automatisch die Usergruppe student.ethz.ch.

Usergruppe student.ethz.ch

Diese Usergruppe enthält die primary Uname aller "aktuellen" Studenten. Dabei gilt eine Übergangsfrist von 180 Tagen seit Austrittsdatum, damit die Administratoren diese User auch nach dem Austritt nötigenfalls verwalten können. User, die manuell in diese Usergruppe verschoben werden, werden automatisch gelöscht.

Leitzahl-Usergruppen

Die primary Uname der Mitarbeiter werden gemäss ihrer Leitzahl in Leitzahl-Usergruppen verschoben (Name der Usergruppe == Leitzahl). Gleichzeitig wird die übergeordnete Departements-Leitzahl ermittelt und der primary Uname als Mitglied dieser übergeordneten Leitzahl-Usergruppe eingetragen. Der Algorithmus:

  1. Leitzahl der Anstellung ermitteln (OE_NR der Tabelle DLDB_MA_ANSTELLUNG)
  2. User in diese Usergruppe eintragen. Bei Bedarf neue Usergruppe erstellen (z.B. neue Leitzahl)
  3. übergeordnete Leitzahl ermitteln (Tabelle DLDB_ORGSTRUKTUR verwenden)
  4. falls OE_TYP dieser übergeordneten Leitzahl > 30: zurück zu 3.
  5. falls OE_TYP dieser übergeordneten Leitzahl <= 30: User in diese Usergruppe eintragen, bei Bedarf neue Usergruppe erstellen

Hat die Leitzahl der Anstellung einen OE_TYP < 30, so kann keine übergeordnete Leitzahl ermittelt werden (Bsp. Leitzahl 00077, OE_TYP = 26).

Besonderes

Verliert ein Mitarbeiter seine Anstellung oder wechselt innerhalb der ETH die Anstellung, so bleibt seine alte Usergruppen-Zugehörigkeit unverändert. Sie erlischt erst, wenn der User selbst gelöscht wird.


update_inbounds.pl

Beschreibung

Aktualisiert das Flag IS_INBOUND = 1 der Tabelle EMAIL_DOMAIN für alle Email-Domänen, die der Exchange Mailserver hostet. Die inbound-Domänen werden aus dem Active Directory ausgelesen.

Aktualisiert das Flag IS_FILTERED = 1 derselben Tabelle für alle Email-Domänen, für die der ETH-Spamfilter aktiviert ist.


update_Emails_from_PDB.pl

Dieser Job ist obsolet und wird nicht mehr ausgeführt

aktualisiert alle Emails, welche von der PDB registriert wurden.

Welche Emails werden aktualisiert?

Emails mit den Flags TYPE = 1, CLASS = 2 (primäre Email, von PDB registriert) werden aktualisiert. Ist die Email-Domäne als INBOUND = 1 deklariert (d.h. vom Exchange Mailserver gehosted), so wird die Emailadresse nicht aktualisiert. Hat der User einen Mailbox-Service, so wird die Primäre Emailadresse (und ihre Target-Adresse) auf dem Exchange-Server geändert. Die ursprüngliche Adresse wird dabei automatisch als Alias gesetzt. Der Algorithmus:

  1. Alle Emails von DLDB_EMAIL holen (Adresstyp <> 1, <> 4)
  2. Nur OUTBOUND - Domänen behandeln. Falls Domäne INBOUND: Email mit CLASS = 2 aus Tabelle EMAIL löschen, sofern diese nicht dem Mailbox-Service zugeteilt ist (NSID = NULL), da sonst die View (und damit «Die» Emailadresse auf eine alte Leiche zeigt)
  3. Falls PDB-Email als Alias definiert: ok, nächste Email
  4. Falls PDB-Email auf nethz-DB einer anderen NPID zugeteilt ist: LOG-File schreiben, nächste Email
  5. Primary Uname der Person ermitteln
  6. Primary Uname hat Mailbox-Service, Primary-Email ist INBOUND: Email als TYPE = 1, CLASS = 2 speichern
  7. Primary Uname hat Mailbox-Service, Primary-Email ist OUTBOUND: Primäre Emailadresse und Targetadresse ändern
  8. Primary Uname hat Mailbox-Service, Primary-Email ist nicht definiert: Primäre Emailadresse und Targetadresse setzen
  9. Primary Uname hat keinen Mailbox-Service: Email als TYPE = 1, CLASS = 2 speichern.

zu 2: Für alle INBOUND-Adressen übernimmt nethz die Verantwortung. Adressen, die als CLASS = 2 und INBOUND definiert, jedoch keinem Mailbox-Service zugeordnet sind (d.h. NSID ist NULL) werden daher gelöscht.


update_Email_for_Person.pl

aktualisiert «Die» Emailadresse (Feld EMAIL der Tabelle PERSON).

Welche Emails werden aktualisiert?

Es werden nur die Emailadressen der an der ETH aktiven Studenten und Mitarbeiter aktualisiert (IS_STUDENT = 1 oder IS_EMPLOYEE = 1). Verliert die Person seine Emailadresse, so wird «Die» Emailadresse nicht gelöscht - sie bleibt quasi als Kommentar erhalten. Um die aktuelle Emailadresse einer Person zu ermitteln, soll die View EMAIL_FOR_UNAME verwendet werden. update_Email_for_Person verwendet ebenfalls diese View. Der Algorithmus dazu:

  1. Primary UNAME einer Person ermitteln
  2. UNAME muss ENABLED sein
  3. Email ermitteln: (TYPE = 1 und CLASS = 1) XOR (TYPE = 1 und CLASS = 2)

Besonderes

Emailadressen von Gästen und Dozenten werden von diesem cronjob nicht erfasst.


update_Person_from_PDB.pl

aktualisiert die Tabelle PERSON aufgrund der Daten aus der PDB-DB. Aktualisiert einige Attribute im Active Directory (AD). Mehr Infos zu diesen Attributen finden Sie hier.

Was wird aktualisiert?

(Fast) alle Felder der Tabelle PERSON werden aktualisiert, insbesondere Postadresse und die Flags IS_EMPLOYEE, IS_STUDENT, IS_LECTURER, IS_GUEST. Die Emailadresse wird vom cronjob update_Emails_from_PDB.pl behandelt. Für die Aktualisierung der Personendaten werden folgende PDB-Views verwendet:

DLDB_PERSON DLDB_ADRESSE DLDB_MA_ANSTELLUNG DLDB_STUD_IMMATRIK DLDB_EINSCHREIBUNG DLDB_BEZIEHUNG (für Dozenten und Gäste) Dabei werden folgende Felder in der Tabelle PERSON aktualisiert:

FIRSTNAME, FAMILYNAME, TITLE DATE_OF_BIRTH, AHVNR, MATRIKELNR ADDRESS, ADDR_ROW1-3 POSTCODE, CITY, COUNTRY PHONE, FAX IS_STUDENT, STUDENT IS_EMPLOYEE, EMPLOYEE IS_LECTURER, IS_GUEST DEPARTMENT, COMPANY SYNC_STATUS (wird auf 0 gesetzt)

COMPANY und DEPARTMENT

Zur Ermittlung von COMPANY und DEPARTEMENT wird die Prozedur get_company_club_for_persid des Moduls PDB_Person.pm verwendet. Diese beiden Felder werden im AD zwecks Erzeugung von Adresslisten (Global Adress List oder GAL) verwendet.

COMPANY kann folgende Werte annehmen:

ETH Studierende ETH <Departementskürzel>, z.B. ETH D-AGRL ETH Zentrale Organe ETH (ausserh.Dept.Strukt.)

DEPARTMENT kann z.B. folgende Werte annehmen:

Basisdienste (ID) Rektorat Stud. D-UWIS D-UWIS

Algorithmus zur Ermittlung von COMPANY und DEPARTMENT

  1. Student oder Mitarbeiter (wenn eine Person beides ist)?
    • Wenn die Domäne der primären Emailadresse (EMAIL_FOR_UNAME) 'student.ethz.ch' lautet, so ist die Person Student, andernfalls Mitarbeiter.
  2. Studenten
    • COMPANY = ETH Studierende
    • DEPARTMENT = Stud. <Departementskürzel> (aktuellste Einschreibung massgeblich)
  3. Mitarbeiter
    • Leitzahl ist in Tabelle LZ_COMPANY_CLUB -> Werte zurückgeben (für company und department)
      company = ETH Zentrale Organe | ETH (ausserh.Dept.Strukt.)
      department = <CLUB> (gemäss Tabelle)
    • Übergeordnetes Departement ermitteln, Algorithmus siehe update_Ugroups_by_LZ.pl company = ETH <Departementskürzel>
      department = <Departementskürzel>

Im Modul PDB_Person.pm gibt es eine Abbildung Leitzahl -> Departementskürzel

Besonderes

update_Person_from_PDB.pl setzt die Flags ADMIN_NPID = NULL, IS_ANYPERSON = 0 bei Gästen, welche in der Zwischenzeit Student oder Mitarbeiter geworden sind.


update_LDAPS.pl

Aktualisiert alle Personen-Daten im UNIX-LDAP Directory. Es werden diejenigen Personen-Einträge aktualisiert, bei denen das Flag SYNC_STATUS in der Tabelle PERSON in (0,1,4,5) ist.


update_AD.pl

Aktualisiert alle die Personendaten im Active Directory. Analog zum cronjob update_LDAPS.pl werden diejenigen Personen-Einträge aktualisiert, bei denen das Flag SYNC_STATUS in der Tabelle PERSON in (0,2,4,6) ist.

Was wird aktualisiert?

Folgende Attribute im AD werden aktualisiert:

  • title (Anrede, z.B. Frau Prof. Dr.)
  • sn (Nachname)
  • givenName (Vorname)
  • company*
  • department*
  • postalCode (Postleitzahl)
  • streetAddress (mehrzeilig)
  • l (Stadt)
  • co (Länderküzel, z.B. CH)
  • physicalDeliveryOfficeName (Raumnummer, z.B. RZ G6)
  • telephoneNumber
  • facsimileTelephoneNumber
  • wWWHomePage

*) wird nach besonderem Algorithmus ermittelt. siehe update_Person_from_PDB.pl

Das Attribut displayName wird nicht überschrieben. Die Attribute postalCode, streetAddress, l, co, physicalDeliveryOfficeName, telephoneNumber, facsimileTelephoneNumber und wWWHomePage werden nur bei den primären Usernamen von Angestellten (IS_EMPLOYEE = 1) geschrieben. Bei Studenten werden diese Attribute gelöscht.

Besonderes

  • Läuft 1x pro Woche (Sonntags)
  • wird über das Synchronisations-Flag SYNC_STATUS der Tabelle PERSON gesteuert (SYNC_STATUS muss die Werte NULL, 0, 2 oder 4 aufweisen, damit eine Synchronisation erfolgt).
  • ohne Trigger TR_PERSON_UPDATE (welche das Synchronisationsflag setzt) läuft nix.


update_mail_lists.pl

Aktualisiert die Maillisten auf Exchange, welche mit dem «Gruppen verwalten»-Tool erstellt wurden.

Ablauf

  1. Alle Gruppen durchlaufen, welche nach Exchange exportiert werden
  2. Alle Include-Gruppen ebenfalls auf EXPORT_EXCHANGE=1 setzen
  3. Einträge der Tabelle UPDATE_NGROUP_EXCHANGE mit Action=c (Check) durchlaufen
  4. schauen, ob sie noch gebraucht werden (d.h. existiert eine übergeordnete Gruppe, welche nach Exchange exportiert wird)
  5. EXPORT_EXCHANGE=NULL, und Eintrag in UPDATE_NGROUP_EXCHANGE mit Action=d (delete) falls nicht mehr gebraucht.
  6. EXPORT_EXCHANGE=1 falls Gruppe noch gebraucht wird
  7. Alle Einträge der Tabelle UPDATE_NGROUP_EXCHANGE mit Actions=c löschen
  8. Einträge der Tabelle UPDATE_NGROUP_EXCHANGE mit Action=d (Delete) durchlaufen
  9. Einträge löschen (auf Exchange)
  10. Alle Ngroups mit EXPORT_EXCHANGE=1 auf Exchange erstellen, sofern nicht bereits vorhanden
  11. Alle direkten Members dieser Gruppen hinzufügen (über Trigger TR_NGROUP_MEMBER gesteuert)
  12. Alle Untergruppen hinzufügen (NGROUP_INCLUDES). Alle Untergruppen, welche nach Exchange exportiert werden, haben auf der Tabelle NGROUP das Flag EXPORT_EXCHANGE=1 gesetzt.


-- Main.vermeul - 22 May 2006
Topic revision: r6 - 2014-08-12 - vermeul
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback