Differences

This shows you the differences between two versions of the page.

--- backendprocesses [2007/10/09 14:25]
faltin
+++ backendprocesses [2011/04/08 14:06]
faltin [Key information]
@@ Line 1: / Line 1: @@
 ====== Back-end processes in NAV ======
-NAV has a number of back-end processes. This document gives an overview, listing key information and
+NAV has a number of back-end processes. This page attempts to give an overview of them.
-detailed description for each process. We also give references to documentation found elsewhere on metaNAV.
+The figure below complements this document. Unfortunately the figure is getting a bit outdated (it hasn't been updated since NAV 3.2):
+  * getDeviceData is now replaced with ipdevpoll
-The following figure complements this document (the NAV 3.3 snmptrapd is not included in the figure):
+  * iptrace does not exist anymore (the job is done by ipdevpoll)
+  * snmptrapd is a new daemon process
 {{architecture1.png?800|The NAV processes}}
@@ Line 24: / Line 24: @@
    * [[backendprocesses#collecting_statistics|cricket]] (includes makecricketConfig, Cricket collector and cleanrrds)
    * [[#eventengine|eventengine]]
-   * [[#getdevicedata|getDeviceData]]
+   * [[#ipdevpoll|ipdevpoll]]
-   * [[#iptrace|iptrace]]
    * [[#logengine|logengine]]
    * [[#mactrace|mactrace]]
@@ Line 39: / Line 38: @@
 ====== Building the network model ======
-===== getDeviceData =====
+===== ipdevpoll =====
 ==== Key information ====
-^ Process name         | getDeviceData  |
+^ Process name         | ipdevpoll |
-^ Alias                | gDD / the snmp data collector  |
 ^ Polls network        | Yes            |
 ^ Brief description    | Collects SNMP data from equipment in the netbox table and stores data regarding the equipment in a number of tables. Does not build topology. |
-^ Depends upon         | Seed data must be filled in the netbox table, either by the Edit Database tool or by the autodiscovery contrib ||
+^ Depends upon         | Seed data must be filled in the netbox table, using the [[seedessentials|Seed Database tool]] |
-^ Updates tables       | netbox, netboxsnmpoid, netboxinfo, device, module, gwport, gwportprefix, prefix, vlan, swport, swportallowedvlan, netbox_vtpvlan |
+^ Updates tables       | netbox, netboxsnmpoid, netboxinfo, device, module, gwportprefix, prefix, vlan, interface, swportallowedvlan |
-^ Run mode             | Daemon process. Thread based. |
+^ Run mode             | Daemon process |
-^ Default scheduling   | Initial data collection for new netboxes is done every 5 minutes. Update polls on existing netboxes is done every 6 hrs. Collection of certain OIDs for the netbox may deviate from this interval; i.e. the moduleMon OID is polled every hour. |
+^ Default scheduling   | Polling is organized into jobs in ''ipdevpoll.conf'', so is job scheduling. |
-^ Config file | getDeviceData.conf |
+^ Config file | ipdevpoll.conf |
-^ Log files | getDeviceData.log og getDeviceData/getDeviceData-stderr.log |
+^ Log files | ipdevpoll.log |
-^ Programming language | Java |
+^ Programming language | Python |
-^ Lines of code        | Approx 8200 |
+^ Further doc          | |
-^ Further doc          | [[http://metanav.uninett.no/static/reports/tigaNAV.pdf|tigaNAV report chapter 5]]|
@@ Line 63: / Line 59: @@
 ==== Details ====
-  * Initial OID classification \\ When gDD detects a new box that has a valid snmp read community (regardless of category), he will start initial OID classifiation. This is done by testing the netbox against all OIDs in the snmpoid table and in turn populating the netboxsnmpoid table. Testing is done based on attributes in snmpoid table, see reference to further doc for details. Frequency will be set based on the snmpoid.defaultfreq.
+  * jobs and plugins \\ All ipdevpoll's work is done by plugins.  Plugins are organized into jobs, and jobs are scheduled for each active IP device individually.
+  * inventory job \\ Polls for inventory information every 6 hours (by default).  Inventory information includes interfaces, serial numbers, modules, VLANs and prefixes.
-  * Plugin-based architecture \\ gDD has a plugin based architecture. Plugins fall into two types; device plugins and data plugins:
+  * profiler job \\ Runs every 5 minutes, profiling devices if deemed necessary.  NAV has an internal list of SNMP OIDs that are tested for compatibility with each device.  This is used to create a sort of profile that says what the device supports - the profile is typically used to produce a Cricket configuration that will collect statistics from proprietary OIDs.
-     * Device plugins collects data with SNMP. Each device plugin is geared towards a particular type of equipment, supporting a particular subset of OIDs. See further doc for details.
+  * logging job \\ Runs every 30 minutes and collects log-like information from devices.  At the time being, only the arp plugin runs, collecting ARP caches from routers.  ARP data is logged to a table, and aids in topology detection and client machine tracking.
-     * Data plugins updates NAVdb with data fed from the device plugins. A particular data plugin is responsible for a particular table (or set of tables) in the database. See further doc for details.
-  * Module monitor \\ The module monitor is a data plugin within gDD. It has the dedicated function of detecting outage of modules in operating netboxes. When a module is detected down a moduleDown event is posted on the event queue (eventq).
-===== iptrace =====
-==== Key information ====
-^ Process name         | iptrace |
-^ Alias                | IP-to-mac collector / arplogger|
-^ Polls network        | Yes |
-^ Brief description    | Collects arp data from routers and stores this information in the arp table. |
-^ Depends upon         | The routers (GW / GSW) must be in the netbox table. To assign prefixes to arp entries, gDD must have done router data collection. |
-^ Updates tables       | arp |
-^ Run mode             | cron |
-^ Default scheduling   | every 30 minutes (0,30 * * * *). No threads |
-^ Config file          | pping.conf |
-^ Log file             | pping.log |
-^ Programming language | Perl|
-^ Lines of code        | Approx 130 lines|
-^ Further doc          | [[http://metanav.uninett.no/static/reports//NAVMe.pdf|NAVMe report ch 4.5.8]] (Norwegian) |
-==== Details ====
-  * iptrace understands proxy arp and will not store arp entries that are "false".
-  * The command line tool [[commandlinetools#navclean.py|navclean.py]] offers a means of deleting old arp (and cam) entries.
@@ Line 108: / Line 74: @@
 ^ Polls network        | Yes |
 ^ Brief description    | Collects mac addresses behind switch table data for all switches (cat GSW, SW, EDGE). The process also checks for spanning tree blocked ports. |
-^ Depends upon         | gDD must have completed the swport tables for the switches. |
+^ Depends upon         | [[#ipdevpoll|ipdevpoll]] must have created the swport tables for the switches. |
 ^ Updates tables       | cam (mac adresses), netboxinfo (CDP neighbors), swp_netbox (the candidate list for the physical topology builder), swportblocked (switch ports that are blocked by spannning for a given vlan). |
 ^ Run mode             | cron |
@@ Line 115: / Line 81: @@
 ^ Log file             | getBoksMacs.log |
 ^ Programming language | Java |
-^ Lines of code        | Approx 1400 |
 ^ Further doc          | [[http://metanav.uninett.no/static/reports/NAVMore.pdf|NAVMore report ch 2.1]] (Norwegian), [[http://metanav.uninett.no/static/reports/tigaNAV.pdf|tigaNAV report ch 5.4.5 and ch 5.5.3]] |
@@ Line 169: / Line 134: @@
 ^ Log file             | networkDiscovery/networkDiscovery-topology.html og networkDiscovery/networkDiscovery-stderr.log   |
 ^ Programming language | Java |
-^ Lines of code        | Approx 1500 (shared with vlan topology builder) |
 ^ Further doc          | [[http://metanav.uninett.no/static/reports/tigaNAV.pdf|tigaNAV report ch 5.5.4]] |
@@ Line 201: / Line 165: @@
 ^ Log file             | networkDiscovery/networkDiscovery-vlan.html og networkDiscovery/networkDiscovery-stderr.log   |
 ^ Programming language | Java |
-^ Lines of code        | See the physical topology builder above |
 ^ Further doc          | [[http://metanav.uninett.no/static/reports/tigaNAV.pdf|tigaNAV report ch 5.5.5]] |
@@ Line 220: / Line 183: @@
 ===== pping =====
@@ Line 234: / Line 198: @@
 ^ Log file             | pping.log   |
 ^ Programming language | Python |
-^ Lines of code        | Approx 4200, shared with servicemon |
+^ Further doc          | See below, based on and translated from [[http://metanav.uninett.no/static/reports/NAVMore.pdf|NAVMore report ch 3.4]] (Norwegian) |
-^ Further doc          | [[http://metanav.uninett.no/static/reports/NAVMore.pdf|NAVMore report ch 3.4]] (Norwegian) |
 ==== Details ====
-FIXME This is Norwegian text - cut and paste from the NAVMore doc. Rewrite.
+pping is a daemon with its own (configurable) scheduling. pping works in parallel which makes each ping sweep very
+efficient. The frequency of each ping sweep is per default 20 seconds. The maximum allowed response time for a host is 5 seconds (per default). A host is declared down on the event queue after four consecutive "no responses" (also configurable). This means
+that it takes between 80 and 99 seconds from a host is down till pping declares it as down.
-pping is a daemon with its own scheduling. In short, pping retrieves in a configurable frequency a
+Please note the [[#eventengine|event engine]] will
-list of IP-addresses to ping (i.e. a list of all IP devices in NAV). pping returns a list
+have a grace period of one minute (configurable) before a "box down warning" is posted on the alert queue, and another three minutes before the box is declared down (also configurable). In summery expect 5-6 minutes before a host is declared down.
-of ping response times, where the value "None" means no answer within the configured timeout
-(defaults to 5 seconds).
-The configuration file ''pping.conf'' is where you can adjust:
+The configuration file ''pping.conf'' lets you adjust the following:
-  * ping frequency
+^parameter ^description ^default |
-  * packet size
+| user | the user that runs the service | navcron |
-  * timeout
+| packet size |size of the icmp packet | 64 byte |
-  * and more
+| check interval | how often you want to run a ping sweep | 20 seconds |
+| timeout |seconds to wait for reply after last ping request is sent | 5 seconds |
+| nrping |number of requests without answer before marking the device as unavailable | 4 |
+| delay | ms between each ping request | 2 ms |
+In addition you can configure debug level, location of log file and location of pid file.
+Note: In order to uniquely identify the icmp echo response packets pping needs to tailor make the packets with its own signature. This delays the overall throughput a bit, but pping can still manage 90-100 hosts per second, which should be sufficient for most needs.
-The ping sweep algorithm is explained below.
-For å ta høyde for at man kan få svar fra et annet interface enn det man
-sender pakken til, er vi nødt til å lage en skreddersydd icmp-pakke til hver
-host. Dette gjør at utsending av pakker tar noe lenger tid enn ønskelig, men
-vi er likevel oppe i en rate på mellom 90-100 hoster/sek.
 === Algorithm - one ping sweep ===
 <code>
-Scriptet går i tre tråder:
+pping has three threads:
-. Tråd 1 genererer og sender ut pakker
+. Thread 1 generates and sends out the icmp packets.
-. Tråd 2 tar imot, sjekker og lagrer pakkene
+. Thread 2 receives echo replies, checks the signature and stores the result to RRD.
-. Hovedtråden står bare og venter på de andre og snurrer på en skråstrek.
+. The main thread does the main scheduling and reports to the event queue.
+Thread 1 works this way:
+  FOR every host DO:
+. Generate an icmp echo packet with: (destination IP, timestamp, signature)
+. Send the icmp echo.
+. Add host to the "Waiting for response" queue.
+. Sleep in the configured ''delay'' ms (default 2 ms). This delay will spread out the response times, which in
+       turn reduces the receive thread queue and will in effect make the measured response time more accurate.
-Tråd 1 virker slik:
+Thread 2 works this way:
-  For hver host:
+  As long as thread 1 is operating and as long as we have hosts in the "Waiting for response" queue, with a
-. Lag en pakke med ping-streng som inneholder: (destinationIP, klokkeslett,programidentifikator)
+  timout of 5 seconds (configurable):
-. Send ut pakken.
+. Check if we have received packets
-. Legg til i ”Venter på svar”
+. Get the data (the icmp reply packet)
-. Sov i 10 millisekunder (hvilket gjør at tråd 1 minimalt kjører i 7.37 sekunder med 737
+. Verify that the packet is to our pid.
-     hoster). Sovingen er viktig for å unngå at alle svar kommer samtidig (hvilket vil gi
+. Split the packet in (destination IP, timestamp, signature)
-     køing på mottakstråden (tråd 2) og dertil unøyaktige responstidstall).
+       If IP is wrong or signature is wrong, discard.
+. If we recognize the IP address on the "Waiting for response" queue, update response time for the host and
+       remove the host from the "Waiting for response" queue.
-Tråd 2 virker slik:
+When thread 2 finishes the sweep is over. If hosts are remaining on the "Waiting for response" queue, we set
-  Så lenge tråd1 fortsatt går eller så lenge vi har noen i svarkøen:
+response time to "None" and increments the "number of consecute no-reply" counter for the host.
-. Se om det er kommet data til socketen. (timeout: 5 sek)
-. Hent data
-. Pakk ut icmp-pakken
-. Sjekk at pakken er til vår pid (trådsikkert, "pid" er lagret av hovedtråden ved oppstart)
-. Split icmp-pakken i (destinationIP, klokkeslett, programidentikator)
-     Om dette ikke går, dump pakken (ikke vår)
-. Sjekk at identifikatoren er lik vår
-. Dersom IP-adressen er en vi har i svarkø, oppdater 'pingtid' for hosten med time.time() – senttime
-. Fjern ifra 'venter på svar'-listen.
-Hvis vi kommer hit har vi timet ut eller så er vi ferdige, så hostene vi har igjen har ikke
+When thread 3 detects that a host has to many no-replies a down event is posted on the event queue.
-svart i tide. Vi setter pingtid None på disse og rapporter til ringbuffer (for grovfiltrering før
-eventkøen).
 </code>
-Pingeren rapporter nede og oppemeldinger til event engine (via eventkøen).
+Note that the response times are recorded to RRD which gives us response time and packet loss data as an extra bonus.
-Event engine vil se nedemeldinger i sammenheng med andre nedemeldinger
-og bruke topologiinformasjon til å avgjøre skyggeforhold. Event engine vil
-også ha robusthetskriterier for å avgjøre om nedetilstanden er en transient.
-Se kap 3.6 for mer.
-For å øke fleksibeliteten ønsker vi også muligheten for å grovfiltrere fra
-pingeren sin side. I pinger.conf kan man angi hvor mange etterfølgende
-pingmålinger som skal gjennomføres før nedemelding sendes til eventkøen.
-Dersom denne verdien for eksempel settes til 4, så vil først 4 etterfølgende
-”None”-svar kvalifisere til nedemelding. Oppemelding vil fortsatt kun kreve
-et ikke-None svar.
-Pingeren får naturlig nok masse responstid- og pakketapsdata. Vi har i
-prosjektet sett på en måte å ta vare på disse dataene. Det er gjort ved at vi
-leverer dataene til RRD. Vi har to målesett, ett for responstid, og ett for
-pakketap. Nøyaktigheten av målingene blir en funksjon av pingfrekvensen.
-Vi ser at det er noe divergerende behov ved å pinge for å stadfeste om en
-enhet er nede versus å pinge for å få gode responstids- og pakketapsdata. Vi
-tror UNINETT sin MPING-løsning er mer optimal i forhold til gode
-statistiske verdier (med poisson fordelt pinging m.m.). Like fullt tror vi at
-pping RRD-verdiene kan gi gode nok data til at driftspersonell får nyttige
-indisier på trege enheter, store pakketap og andre fenomener som registreres
-over tid.
-Vi mangler fortsatt å strukturere alle RRD-målingene inn mot Cricket. Vi
-ser dette i sammenheng med en ny mulig overbygning over RRD som
-potensielt kan supplere Cricket. Dette blir en mulig aktivitet i 2003 (se
-kapittel 4.1.4).
 ===== servicemon =====
@@ Line 338: / Line 281: @@
 ^ Log file             | servicemon.log   |
 ^ Programming language | Python |
-^ Lines of code        | See pping above, shared code base |
+^ Further doc          | See the [[servicemon]] page and/or [[http://metanav.uninett.no/static/reports/NAVMore.pdf|NAVMore report ch 3.5]] (Norwegian) |
-^ Further doc          | [[http://metanav.uninett.no/static/reports/NAVMore.pdf|NAVMore report ch 3.5]] (Norwegian) |
 ==== Details ====
@@ Line 361: / Line 303: @@
 ^ Log file             | thresholdMon.log   |
 ^ Programming language | Python |
-^ Lines of code        | Approx 400 |
 ^ Further doc          | See [[ThresholdMonitor]] |
@@ Line 368: / Line 309: @@
   * See [[ThresholdMonitor]]
-===== moduleMon =====
-==== Key information ====
-^ Process name         | getDeviceData data plugin moduleMon |
-^ Alias                | The module monitor |
-^ Polls network        | Yes |
-^ Brief description    | A plugin to gDD. A dedicated OID is polled. If this is a HP switch, a specific HP OID is used (oidkey hpStackStatsMemberOperStatus), similarly for 3Com (oidkey 3cIfMauType). For other equipment the genereric moduleMon OID is used. For 3com and HP the OID actually tells us if a module is down or not. For the generic test we (in lack of something better) check if an arbitrary ifindex on the module in question responds. If the module has no ports, no check is done.  |
-^ Depends upon         | The switch or router to be processed by gDD with apropriate data in module and gwport/swport. |
-^ Updates tables       | posts moduleMon events on the eventq. Sets in addition the boolean module.up value. |
-^ Run mode             | daemon, a part of gDD. |
-^ Default scheduling   | Depends on the defaultfreq of the moduleMon OID (equivalently for the HP and 3com OIDs) Defaults to 1 hour. |
-^ Config file          | see gDD |
-^ Log file             | see gDD   |
-^ Programming language | Java |
-^ Lines of code        | Part of gDD, see gDD. |
-^ Further doc          | Not much. |
@@ Line 405: / Line 328: @@
 ^ Log file             | eventEngine.log   |
 ^ Programming language | Java |
-^ Lines of code        | Approx 3000 lines |
 ^ Further doc          | [[http://metanav.uninett.no/static/reports/NAVMore.pdf|NAVMore report ch 3.6]] (Norwegian). Updates in [[http://metanav.uninett.no/static/reports/tigaNAV.pdf|tigaNAV report ch 4.3.1]]. |
@@ Line 413: / Line 335: @@
 ===== maintengine =====
@@ Line 419: / Line 343: @@
 ^ Alias                | The maintenance engine |
 ^ Polls network        | No |
-^ Brief description    | Checks the defines maintenance schedules. If start or end of a maintenance period occurs at this run time, the relevant maintenanceEvents are posted on the eventq, one for each netbox/module and/or service in question. |
+^ Brief description    | Checks the defined maintenance schedules. If start or end of a maintenance period occurs at this run time, the relevant maintenanceEvents are posted on the eventq, one for each netbox and/or service in question. |
-^ Depends upon         | NAV users must set up maintenance schedule which in turn is stored in the maintenance tables (emotd, maintenance, emotd_related). |
+^ Depends upon         | NAV users must set up maintenance schedule which in turn is stored in the maintenance tables (maint_task, maint_component). |
-^ Updates tables       | Posts maintenance events on the eventq. Also updates the maintenance.state. |
+^ Updates tables       | Posts maintenance events on the eventq. Also updates the maint_task.state. |
 ^ Run mode             | cron |
 ^ Default scheduling   | Every 5 minutes ( */5 * * * * )|
@@ Line 427: / Line 351: @@
 ^ Log file             | maintengine.log   |
 ^ Programming language | Python |
-^ Lines of code        | Approx 300 |
+^ Further doc          | Old doc: [[http://metanav.uninett.no/static/reports/tigaNAV.pdf|tigaNAV report ch 8]]. The maintenance system was rewritten for NAV 3.1. See [[devel:tasklist2006#t3rewrite_the_message_and_maintenance_tool|here]] for more. |
-^ Further doc          | [[http://metanav.uninett.no/static/reports/tigaNAV.pdf|tigaNAV report ch 8]].|
 ==== Details ====
@@ Line 448: / Line 371: @@
 ^ Config file          | alertengine.cfg |
 ^ Log file             | alertengine.log og alertengine.err.log   |
-^ Programming language | perl |
+^ Programming language | Python |
-^ Lines of code        | Approx 1900 |
 ^ Further doc          | [[http://metanav.uninett.no/static/reports/NAVMore.pdf|NAVMore report ch 3.7 and 3.8]] (Norwegian). |
@@ Line 457: / Line 379: @@
 ===== smsd =====
@@ Line 463: / Line 387: @@
 ^ Alias                | The SMS daemon |
 ^ Polls network        | No |
-^ Brief description    | Checks the sms queue for new messages, formats the messages into one SMS and dispatches it via one or more dispatchers with a general interface. Support for multiple dispatchers are handled by a dispatcher handler layer. |
+^ Brief description    | Checks the navprofiles.smsq table for new messages, formats the messages into one SMS and dispatches it via one or more dispatchers with a general interface. Support for multiple dispatchers are handled by a dispatcher handler layer. |
-^ Depends upon         | alertEngine fills the smsq |
+^ Depends upon         | alertEngine fills the navprofiles.smsq table |
 ^ Updates tables       | Updates the sent and timesent values of navprofiles.smsq |
 ^ Run mode             | Daemon process |
 ^ Default scheduling   | Polls the sms queue every x minutes |
 ^ Config file          | smsd.conf |
-^ Log file             | smsd.log   |
+^ Log file             | smsd.log |
-^ Programming language | Python  in NAV 3.2 (perl in 3.1) |
+^ Programming language | Python (Perl in 3.1) |
-^ Lines of code        | In NAV 3.2: approx 1200 |
+^ Further doc          | subsystem/smsd/README in the NAV sources describes the available dispatchers and more |
-^ Further doc          | - |
+==== Details ====
+=== Usage ===
+As described when given the ''-''''–help'' argument:
+  Usage: smsd [-h] [-c] [-d sec] [-t phone no.]
+    -h, --help            Show this help text
+    -c, --cancel          Cancel (mark as ignored) all unsent messages
+    -d, --delay           Set delay (in seconds) between queue checks
+    -t, --test            Send a test message to <phone no.>
+Especially note the ''-''''-test'' option, which is useful for debugging when experiencing problems with smsd.
+=== Configuration ===
+The configuration file smsd.conf lets you configure the following:
+^ parameter  ^ description                                     ^ default   ^
+| username   | System user the process should try to run as    | navcron   |
+| delay      | Delay in seconds between queue runs             | 30        |
+| autocancel | Automatically cancel all messages older than 'autocancel', 0 to disable. Format like the PostgreSQL interval type, e.g. '1 day 12 hours'. | 0 |
+| loglevel   | Filter level for log messages. Valid options are DEBUG, INFO, WARNING, ERROR, CRITICAL | INFO |
+| mailwarnlevel | Filter level for log messages sent by mail.  | ERROR     |
+| mailserver | Mail server to send log messages via.           | localhost |
+| dispatcherretry | Time, in seconds, before a dispatcher is retried after a failure | 300 |
+| dispatcherN | Dispatchers in prioritized order. Cheapest first, safest last. N should be 1,2,3,... | dispatcher1 defaults to GammuDispatcher |
+In addition, some dispatchers need extra configuration as described in comments in the config file.
-===== The snmptrapd =====
+===== snmptrapd =====
@@ Line 493: / Line 452: @@
 ^ Log file             | snmptrapd.log and snmptraps.log  |
 ^ Programming language | Python   |
-^ Lines of code        | Approx 200 + traphandlers |
 ^ Further doc          | - |
@@ Line 510: / Line 468: @@
 ^ Polls network        | No |
 ^ Brief description    | |
-^ Depends upon         | That gDD has filled the gwport, swport tables (and more...) |
+^ Depends upon         | That ipdevpoll has filled the gwport, swport tables (and more...) |
 ^ Updates tables       | The RRD database (rrd_file and rrd_datasource) |
 ^ Run mode             | cron |
@@ Line 516: / Line 474: @@
 ^ Config file          | None |
 ^ Log file             | cricket-changelog   |
-^ Programming language | perl |
+^ Programming language | python |
-^ Lines of code        | Approx 1600 |
 ^ Further doc          | [[howtoconfigurecricket|How to configure Cricket addons in NAV v3]] |
@@ Line 538: / Line 495: @@
 ^ Log file             | cricket/giga.log og cricket/normal.log   |
 ^ Programming language | not relevant |
-^ Lines of code        | not relevant |
 ^ Further doc          | not relevant |
@@ Line 557: / Line 513: @@
 ^ Log file             | ?   |
 ^ Programming language | Perl |
-^ Lines of code        | Approx 200 |
 ^ Further doc          | - |
@@ Line 583: / Line 538: @@
 ^ Log file             | None   |
 ^ Programming language | Python |
-^ Lines of code        | Approx 350 |
 ^ Further doc          | [[http://metanav.uninett.no/static/reports/NAVMore.pdf|NAVMore report ch 2.4]] (Norwegian). |
@@ Line 605: / Line 559: @@
 ^ Default scheduling   | |
 ^ Programming language | |
-^ Lines of code        | |
 ^ Further doc          | [[Arnold|Arnold]] |

NAV Wiki

User Tools

Site Tools

Differences

Page Tools