The admin modules can be accessed by clicking on the Admin menu item. Your account must have administration permissions to see this menu.
Settings that the end-user will see.
Users - Create and manage users
Projects - Create and manage projects
Reports - Create imaging data reports
Settings that the end-user will not see
NiDB Settings
Informational Links
Backup
Modules
Modalities
Sites
Instances
Mass email
DICOM receiver
Back end are all settings and configuration that keep NiDB running
The NiDB Settings page contains all configuration variables for the system. These variables can be edited on the Settings page, or by editing the nidb.cfg file. The default path for this file should be /nidb/nidb.cfg. The exact location of the config file is specified on the NiDB Settings page.
PHP has default resource limits, which may cause issues with NiDB. Limits are increased during the installation/upgrade of NiDB. The current limits are listed on the bottom of the Settings page as a reference if your NiDB installation is not working as expected.
NiDB replaces the crontab for the nidb account with a list of modules required to run NiDB. This crontab is cleared and re-setup with the default nidb crontab each time NiDB is setup/upgraded. Any items you add to the crontab will be erased during an upgrade and need to be setup again.
At the top of the Settings page, you can specify messages which are displayed system-wide when a user logs in. These can be messages related to planned system down time or other notifications.
NiDB is often run on a network with many other websites such as compute node status, internal Wikis, and project documentation. Links to websites can be specified on the Admin page directly.
Depending on the size or importance of your data, you may want to backup your data in an off-line format rather than simply mirroring the hard drives onto another server. A backup system is available to permanently archive imaging data onto magnetic tape. LTO tapes are written in triplicate to prevent loss of data. Each tape can be stored in a separate location and data integrity ensured with a majority rules approach to data validation.
Backup directory paths are specified in the config file. See the Config variables section.
Data is automatically copied to the backupdir when it is written to the archivedir. Data older than 24 hours is moved from backupdir to backupstagingdir. When backupstagingdir is at least the size of backupsize, then a tape is ready to be written.
Tape 0 lists the current size of the backupstagingdir.
NiDB has several modules that control backend operations. These can be enabled, disabled, put into debug mode, and the logs viewed.
Enabled modules are listed in green. Running modules will list the process id of the instance of the module. Some modules can have multiple instances running, ie multithreaded, while some modules can only run 1 instance. Each running instance is color-coded with green having checked in recently and red having checked in 2 hours.
Each module has lock file(s) stored in /nidb/lock and log files in /nidb/logs
The module manager monitors modules to see if they have crashed, and restarts them if they have. If a module does not checkin within 2 hours (except for the backup module) it is assumed that it has crashed, and the module manager will reset the module by deleting the lock file and removing the database entry.
Each modality requires it's own SQL table. Details of the SQL tables, including number of rows and table size, can be viewed on the modalities page.
Sites are used in various places within NiDB. This section is used when data is collected at multiple sites and stores details about each site.
NiDB has the ability to separate projects into different instances, basically creating project groups, to which access permissions can be applied. For example, a user can be part of certain instances, giving them the opportunity to view projects within that instance if they have permissions. This can be a good way to group projects from a multi-site project.
This will attempt to send an email to every registered email address within the system. It's spam, so use it sparingly.
Front end settings are what the users see. Projects, users, etc.
Access the user administration page from the Admin page. Admin page is only accessible if you are logged in as an administrator
To create a regular user, go to Admin → Users. Click the Add User button. Enter their information, including password and email address. The username can be any field, such as an alphanumeric string, or an email address. If the user is given NiDB admin permissions, then they will be able to add/edit users.
On public servers, or systems where users are allowed to register themselves, they can create an account and verify their email address to fully register the account. The account will then exist, but they will have no permissions to any projects within NiDB. After a user registers, they will appear on the Admin → Users → All Other Users tab. Click the username to edit their project permissions. Note: be careful allowing users to self-register, for obvious reasons.
There are 3 options of where to find users A) users in the current instance (switch instance by clicking the instance list in the upper left menu) B) users not in the current instance C) deleted users
To manage project permissions for users, go to Admin → Users and click on the username you want to manage. The page can change the name, password, email, admin status, if the account is enabled/disabled, and the projects to which the user has permissions. After changing any information on the page, click the Save button at the bottom of the page. See list of user options and settings below.
Data collected in the system must be associated with a subject, and that subject must be enrolled in a project. There is a default project in NiDB called Generic Project, but its preferable to create projects parallel to IRB approved studies.
Projects are listed after clicking on the Admin → Projects menu. Clicking the project allows editing of the project options. Clicking the Create Project button will show the new project form. Fill out the form, or edit the form, using the following descriptions of the options
Reports of imaging studies (often used for billing/accounting purposes on MRI equipment for example) are organized by modality or equipment. Clicking any of the 'year' links will display a calendar for that year with the number of studies per day matching the specified criteria. Clicking the month name will show a report for that month and modality/equipment. Clicking the day will show a report of studies collected on that day.
NiDB will check by default if an account already exists when a user logs in for the first time. If the user exists in NIS, an account will created within NiDB. NIS must be enabled and able to authenticate to the NIS through the NiDB server.
| Item | Meaning |
|---|
| Item | Meaning |
|---|
archivedir
→
backupdir
→
backupstaging
→
LTO tape
automatic
data older than 24hrs is moved
when large enough to fill a tape
Enabled | If checked, then the user can login, otherwise they cannot login |
NiDB Admin | If checked, this user can add/manage users, and various other Admin tasks within NiDB |
Project admin | The user has permissions to add subjects to the project |
Data/PHI/PII modify/view | Honestly, just check them all off |
Instances | To give permissions to a project, the instance that the project is part of must be checked |
Name | Project name, displayed in many places on NiDB |
Project number | Unique number which represents a project number. May be referred to as a 'cost center' |
Use Custom IDs | Certain pages on NiDB will display the primary alternate ID instead of the UID (S1234ABC) if this option is checked |
Instance | Project will be part of this instance |
Principle Investigator | The PI of the project |
Administrator | The admin in charge of the project |
Start/End Dates | Possibly corresponding to the IRB starting and ending dates of the project |
Command line usage of nidb
All modules in NiDB system are run from the nidb command line program. Modules are automated by being started from cron.
nidb can be run manually to test modules and get debugging information. It can also be used when running on a cluster to insert results back into the database. Running nidb without command line parameters will display the usage.
Avaiable modules are: import, export, fileio, mriqa, qc, modulemanager, importuploaded, upload, pipeline, minipipeline, and backup
For example, to run the import module, run as the nidb user
This will output
As with all modules, detailed log files are written to /nidb/logs and are kept for 4 days.
To run nidb from the cluster, for the purpose of inserting results into the database or for checkins while running pipelines, this would be run on the cluster node itself. Access to an nidb.cfg file is necessary to run nidb somewhere other than on the main database server. A second config file /nidb/nidb-cluster.cfg can be copied to the cluster location along with the nidb executable.
To check-in when running a pipeline, use the following
The analysisid is the rowid of the analysis which is bring reported on. Status can include one of the following: started, startedrerun, startedsupplement, processing, completererun, completesupplement, complete. Message can be an string, enclosed in double quotes.
This option counts the byte size of the analysis directory and number of files and updates the analysis details in the main database.
This option checks if the 'complete files' list exists. These files are specified as part of the pipeline definition. If the files exist, the analysis is marked as successfuly complete.
Text, number, and images can be inserted using this command. Examples
