Figure 1: iProject system operation
The iProject provides a secure, easy-to-use collaborative data workspace.
The iProject is a three-tier client/server application: The client handles display functions, while the server handles security, application logic, and data manipulation. The server interacts with a storage layer consisting of a file server and database. Figure 1 gives a block diagram iProject system operation.
The client runs as an application installed on the user's computer, communicating with the server by sending requests over SSL sockets.
The server runs as a stand-alone Java application, accepting connections from the client, processing the requests, and returning results. Data files are stored using the native filesystem of the server's machine. Other data (e.g. company and user information) are stored in a relational database via JDBC. For convenience, the iProject can be configured to make common file types viewable to users by double-clicking. This is accomplished by setting up a special Display Directory into which the server temporarily copies requested files, so that they can be shown in the client's browser. See Browser File Display Considerations and Configure the Browser File Display Directory.
Figure 1: iProject system operation
System security is an enormous topic and an ongoing task, well beyond the scope of this guide. Briefly, there are five main security tasks related to the iProject.
The components of the iProject do not have to be installed on the same physical machine, as long as they can communicate as described in Figure 1:
/temp).
This can usually be accomplished in several ways.
It is possible to have multiple iProject servers running in front of the same filesystem and database.
This provides scalability by allowing several iProject servers to share the overhead
of request processing and security enforcement, which is a heavier burden than that placed on the
filesystem or database.
This type of configuration will typically include a load-balancing router in front of the iProject servers.
Browser File Display Considerations
Certain types of files are appropriately displayed in a Web browser. These include GIF, JPG, and other image file formats, MPEG animations, and Adobe Acrobat PDF documents. Most browsers can be configured to display specific file types using a specific viewer, and many are preconfigured to display Microsoft Office documents.
These viewing capabilities enhance productivity. The iProject provides viewers for specific technical data types such as LAS. Even in a technical area, however, simple documents, spreadsheets, and the like are common, and it is clearly undesirable to provide internal viewers for every possible file type. Displaying common types using a client's browser allows users to easily view files without having to download and open them in a different application.
This feature can easily be disabled. If enabled, the price of this convenience is a certain security risk, which can fortunately be controlled.
/temp by default) directory.
This would require unauthorized users to guess the name of an exposed document. Since the
filename obfuscation includes randomization, guessing a filename would be extremely difficult.
/temp directory will
encrypt exposed files in transit, preventing interception.
The iProject server has very specific communication requirements, which should be easy to accommodate on the host's firewall and/or proxy.
The more interesting (and almost infinitely varied) problem is that of allowing the iProject client to communicate to the iProject server through the client's firewall. The requirements are complementary to those of the host firewall.
Various companies have various firewall and proxy configurations and procedures. The easiest thing is to do is assign port 443 to the iProject server, since this port is almost always allowed on firewalls and the iProject uses HTTPS tunneling, which should be permitted by most proxies. This is only an issue if the iProject server resides on the same machine as the Web server. In that case, HTTPS (which uses port 443) cannot be used to view exposed files. There are several options:
There are several steps involved in installing the iProject system:
Three supporting programs should be installed and configured before installing the iProject:
TZ
environment variable to one of the values found in /usr/share/zoneinfo.The iProject Installation program installs the iProject system components:
On Windows machines, attach the USB dongle provided with your installation package
before running the installation.
Some versions of Windows will attempt to locate drivers right away.
You may cancel any such effort, as the iProject installation will install the required dongle drivers.
Install the License
The iProject server requires that a special license file, IrLicense.jar,
be present in the bin subdirectory where the iProject is installed
(this directory will also contain the file ircserver.jar).
The license file is provided with your installation package.
Copy it into the bin subdirectory.
Configure the Operating System
You should create an account under which to run the iProject server. This account will need these permissions:
/usr/bin/iproject or C:\Program Files\iProject)
/var/iproject/data or D:\iProject\Data)
/var/www/html/temp or C:\inetpub\wwwroot\temp)
On Linux, there are two system settings related to shared memory that may boost performance:
shmall and shmmax.
Depending on your system, these may be accessible through /etc/sysctl.conf
or /proc/sys/kernel.
These usually have fairly small default values (2,097,152 (2Mb) and 33,554,432 (32Mb) respectively),
and we've found that increasing them to 134,217,728 (128Mb) is helpful.
In /etc/sysctl.conf, add or change the lines:
kernel.shmall = 134217728
kernel.shmmax = 134217728
/proc/sys/kernel you can check the values with
cat /proc/sys/kernel/shmall
cat /proc/sys/kernel/shmmax
echo 134217728 > /proc/sys/kernel/shmall
echo 134217728 > /proc/sys/kernel/shmmax
Configure the iProject Services
The iProject server has several configuration values that influence its operation. Most of these are set to sensible values during installation.
Figure 2: The Database Configuration panel
Start the iProject server by running the launch script generated by the installation program
(iproject_server_launch.sh or iproject_server_launch.bat).
In the Configuration group, check the values:
iProject Daemon Launch Command | ./iproject_daemon_launch.sh
or iproject_daemon_launch.bat |
| Local Server | Arbitrary name for the local server |
| Dongle Server | (Optional) If multiple servers are running on the same dongle, this should be the name assigned to the server which has the dongle. |
Control item
| Daemon Control Port | If the iProject server will be run in daemon mode, set this to the port on which the daemon will listen for instructions from the server control GUI. |
| JDBC Driver | Fully-qualified class name of the JDBC driver |
| Database URL | JDBC-driver-dependent URL of the iProject database |
| Catalog | iProject database catalog; if needed |
| Username | Authorized username for the database, if needed |
| Password | Password of database user, if needed |
Database Schema | Schema for the iProject database, if needed |
| Localization File | LothlorienSql.txt |
| Target Syntax | PostgreSQL if using that database |
| Browser Launch | (Optional) Command that will launch a Web browser |
| Force SSL on LAN | If checked, clients connecting from the same LAN as the server (as determined by the next two settings) are forced to use SSL sockets |
| LAN IP | Representative IP for a computer on the LAN. Usually this will be the IP of the iProject server. |
| LAN Subnet Mask | Mask of the LAN. Usually this will be 255.255.255.0 or 255.255.0.0. |
| PKCS12 or JKS Keystore | Name of keystore file. This is the keystore file containing the SSL certificate that will be used to encrypt iProject sockets. See Dealing with Digital Certificates for further information. |
| Keystore Passphrase | Passphrase for keystore/certificate (must be the same) |
| Keystore Type | PKCS12 (usually) or JKS |
| Minimum Request Wait | Time (millis) to wait between socket connections |
| Maximum Request Wait | Time (millis) to wait for a socket to respond |
| Request Timeout | Time (millis) to wait for a request to be received |
| Test Port | Port server will use to attempt to count number of available sockets |
| Server Ports | Space-separated list of ports on which iProject should listen |
| SMTP Server | Sendmail server |
| Send On Port | Usually 25 |
| Send From | Return address for reports. |
| POP3 Server | POP server, if required for SMTP validation |
| POP3 Port | Usually 110 |
| Username | POP account username, if required for SMTP validation |
| Password | POP account password, if required for SMTP validation |
| Report Cycle | Interval for generating email notification reports |
Press the Start button, and check the Console Output item on the
Status group for any error messages. The configuration values will be saved and
automatically entered the next time the iProject server is started.
Optional Configuration Steps
There are several additional ways to customize the iProject.
These are usually not required, but can be used to tune your iProject installation.
Configure the Data Root Directory
The iProject needs read/write/delete permissions on one directory, under which it will build a directory tree to store data files for projects in the iProject. The iProject accesses this directory using native filesystem calls on its host machine, so this directory must look local (i.e. have a path in the local filesystem). It does not actually need to reside on the iProject server. Under Linux/Unix systems, for example, an NFS mount can be used. Note that for network mounted storage, network performance will usually have an impact on overall performance.
When the directory has been identified (and appropriately connected if necessary), the iProject must be set to use it. Normally this will be set by the installation program, but can be set manually or changed later. On the Database item in the Service Management group, execute the query:
UPDATE Zoo SET anml_value='whatever directory' WHERE anml_name='Elephant'
As described under Browser File Display Considerations,
it can be convenient to allow the iProject to display certain file types using the client's browser.
If this feature is desired, then the iProject server must have write/delete permissions on a directory
(usually /temp) in the Web server's document hierarchy.
If the Web server does not reside on the same machine as the iProject server, then some kind of mounting of this
directory (such as NFS) will be needed.
When the directory has been identified (and appropriately connected if necessary), the iProject must be set to use it. Normally this will be set by the installation program, unless the Web server does not reside on the same machine as the iProject server. On the Database item in the Service Management group, execute the query:
UPDATE Zoo SET anml_value='local path to the display directory' WHERE anml_name='Peacock'
If the Web server runs on a different host than the iProject server, it must be set with
UPDATE Zoo SET anml_value='Web host address' WHERE anml_name='Peahen'
Finally, if a Web directory other than /temp is used, it must be set with
UPDATE Zoo SET anml_value='Web directory' WHERE anml_name='Peachick'
The iProject is preconfigured to direct bug reports to the iReservoir.com issue tracking server, which will usually be appropriate. Bug reports may be entered using any URL, by setting the URL in the iProject. On the Database item in the Service Management group, execute the query:
UPDATE Zoo SET anml_value='desired url' WHERE anml_name='Dog'
The Javascript file /scripts/connection_info.js under the Web root
directory can be used to specify the address and port(s) clients will use to connect to the iProject server.
By default, clients will attempt to connect to the same address as the Web server, on ports
443 2000 20 2001 in that order.
Clients
read this file for connection information.
You should change this if you set a different port list in Server Ports
in the Socket configuration, or if the iProject server is on a different machine
than the Web server.
If you are load-balancing several iProject servers, then the host address should be that of the
load-balancer.
Customize the Web Pages
The iProject installation includes some default Web pages. Please customize these pages to suit your own needs and preferences. The content of any pages installed with the iProject is considered part of the system, so it can be freely copied and adapted to suit your needs.
su -c 'postmaster -i &' postgres &).
Database servers can usually be configured to start automatically at startup.
Daemon (iproject_daemon_launch.sh or iproject_daemon_launch.bat)
When run in daemon mode, the iProject server runs without a window. This is the fastest way to run the server.
GUI (iproject_gui_launch.sh or iproject_gui_launch.bat)
Complementary to daemon mode, GUI mode runs only a window, and sends commands to a daemon (starting one if needed).
Running a GUI window with a deamon is the slowest (because of the overhead of status-reporting sockets).
Window (iproject_server_launch.sh or iproject_server_launch.bat)
In window mode, the iProject server runs both the GUI and services in the same process.
This is a good way to run the server if you want to keep the GUI window open,
since it avoids the overhead of control sockets.
Adding the startup option to the final line of any of the startup scripts
will cause it to launch and immediately start the iProject services.
This can be used to have the iProject start at reboot, but note that the database needs to be running first.
Also, all passwords must be stored in the Configuration
(see Customizing Service Configuration).
Restarting the System Services
If necessary, the iProject server can be restarted without actually shutting it all
the way down. Press the Restart Services button.
Any users who are logged in will not be logged out, but any data transfers in progress will be interrupted.
Stopping the System Services
Press the Shutdown Services button.
Testing the Installation
When the installation and configuration are complete, the general functioning of the system should be tested.
Start the server
(General validation of the server installation and configuration.)
Install the client on a computer that can communicate with the server
(Makes sure that the iProject Web pages were set up correctly, and it's good experience.)
Connect to the server
(Checks network accessibility and connection parameters.)
connection_info.js?
connection_info.js
that of the iProject server (especially if not the same as the Web server)?
Log in as the superuser lupine
(First test of whether the database is installed and populated correctly.)
Open the demo project Waterflood Evaluation
(Further test of the database prepopulation.)
Upload a few image files to a subdirectory
(Confirms that the data storage is configured correctly.)
SELECT dir_id, dir_spec FROM Directory WHERE parent_dir_id=0
dir_spec values represent
full paths to directories on the iProject server.
UPDATE Directory SET dir_spec='correct_path'
WHERE dir_id=id_value_from_listView one of the image files in a browser
(Verifies that
Browser File Display
is configured correctly.)
Download a few files
(Further confirmation that the data storage configuration is correct.)
Check File Not Found and Permission Denied errors as for
Upload a few image files to a subdirectory above.
Log out
(This doesn't really test anything, it's how you end a session.)
pg_dump command.)
Vacuum full analyze; query.)
The iProject server offers several displays providing information on the status of the system.
Figure 3: System Status display
The System Status display indicates free and total memory, and number of threads running.
Figure 4: Console Output display
The Console Output display shows any messages printed by the system. In particular, database errors will be displayed here (as well as in the log).
Figure 5: Service Status display
The Service Status display shows how well (generally, how fast) the system
services are running.
Managing iProject Services
The iProject server provides user interfaces to perform various tasks associated with its services.
Figure 6: Database management interface
The database management interface allows the execution of any SQL query against the database, and provides a cleanup function that instructs the database to clean up deleted rows and freshen indexes.
Figure 7: Storage management interface
The storage management interface allows shared directory "roots" to be specified, which can then be used as starting points for mapping shared data into projects (by project administrators with appropriate permissions).
| ID | Unique ID number assigned by the database |
| Path | Full path to the shared directory root on the iProject server |
| Name | Display name for the shared directory root. For a mapped directory, this should include information about the actual host on which the directory resides. |
| Description | Optional. |
| Subnet Mask |
Optional space-delimited lists of IP addresses and masks from which this shared directory root can be accessed. If present, then this shared directory root (and any subdirectories underneath it) will only be visible on clients connecting from network addresses matching at least one of the specified subnets. This restriction is in addition to any restrictions placed by user roles. |
User the Refresh Add Edit and Delete buttons to manage shared directory "roots". In particular, the Refresh button must be pressed to initialize the list.
Figure 8: Log management interface
The log management interface allows the inspection of the iProject log, including all client requests, and processing errors. Selected events can be exported to a tab-delimited file and deleted.
Figure 9: Permission management interface
The permission management interface allows user sessions to be viewed and invalidated. Selected sessions can be exported to a tab-delimited file (for example, to be imported into Excel to generate usage statistics) and deleted.
The iProject system installs with the superuser lupine defined. The password and user information for this account are set during installation.
The superuser will inevitably be called upon to perform various tasks, some of which are described below.
Creating and Editing Companies
The iProject provides a 'wizard' for creating a new company record. To begin adding a new company, select the Administration... Create New Company menu. The wizard will open and present a screen that looks like the one below, describing the steps involved. Click the Continue button to go on to the next step.
Figure 10: New Company introduction screen
The next screen of the wizard is where you'll enter the company information. The fields are self-explanatory; only Company Name is required.
Figure 11: New Company information screen
The next step is to choose a company administrator. The company administrator has extensive permissions over his/her company and the users and projects assigned to it, including updating company information, creating and updating user information, and full access to projects. See Default Role Permissions for complete details.
Every company should have an administrator, ideally belonging to the company itself. If you create a new account for the company administrator (recommended), the User Login and Password fields are required. See Creating and Editing Users for more information.
Figure 12: New Company administrator screen
The last step is a review step. The wizard creates a report of everything that's about to take place so that you may review it and make any necessary changes before the company is created. This report will show you all of the information you entered about the company in the first step, and who you've assigned (if anyone) as a company administrator. Clicking the Create Company button at this point will create the company and make the appropriate role adjustments for the user you've selected.
Figure 13: New Company review screen
Several standard roles are created with each company:
Company information can be edited by selecting the Administration... Edit Companies... menu. This brings up the Edit Companies Screen.
Figure 14: Edit Companies screen
Creating and Editing Users
The superuser lupine has permissions to create and manage user accounts for all companies. Company administrators and user account managers have permissions to create and manage user accounts for their own company. User account information is edited using the Edit Users screen. To edit user account information, go to the Administration menu and scroll down to Users. A side menu should pop out, and in this menu select Edit Users...
The Edit Users window will look like the one above. The fields are self-explanatory; only User Login is required, but Email must also be specified for the user to receive notifications and automated activity reports.
When changing a password, you'll need to type the password twice: once in the Password field box, and again in the Confirm Password box. Passwords must be a minimum of seven characters long, must contain a mixture of upper and lower case characters, and may include numbers and special characters. You may not use the login name or the person's real name in the password, even if only partially.
Unchecking the Active Account checkbox will deactivate the account and invalidate any sessions the user has active. Be very careful about unchecking this box, especially for you own account. New user accounts created by lupine will be active or inactive according to whether this box is checked or not; those created by company admins or user managers will be active if the iProject license allows more active users, inactive if not. Only the superuser lupine has permissions to activate and deactivate user accounts.
To create a new user, you can either go to the Administration menu,
scroll down to Users then select New User;
or you can click the New... button in the
First select the company for which you wish to assign roles, using the Company drop-list.
Next select the user to whom you wish to assign roles, in the Users list on the left.
Any roles the selected user currently holds will be shown checked in the Roles list on the right.
Normally, selecting a company restricts the Users list to those users belonging to the selected company.
Below the list is the Show All Users checkbox; checking this box will cause the list to show all users
for whom you have permission to assign roles.
Finally, check the roles you wish to assign to the user in the Roles,
and click the Save button.
You can set multiple roles for multiple users and save them all at once, but if you change the selected company
you will lose any changes you've made since the last time you clicked the Save button. Clicking the Refresh button will cause all the screen information to be re-read from the server.
Clicking the Reset will clear any changes since the last Save.
The iProject permission model is fine-grained, meaning that permissions
can be assigned on an item-by-item, user-by-user basis if needed:
If a project participant needs to be able to see one file but not another, that can be
accommodated.
If another participant needs to see many files but only write into a few directories, or even
to update only one specific file, that can also be handled.
To manage the complexity of constantly changing directory structures and file lists, the
iProject permission model is also hereditary.
This means that files, directories, and other items are arranged in a hierarchy, and that
descendants inherit permissions granted or denied on their parents.
This has the side effect that permissions may be granted or denied on an item to which they
do not apply, as long as they apply to one or more of its descendants.
In this hereditary permission model, fine-grained-ness is accomplished by applying the
nearest assigned grant or deny:
If an item has a permission granted or denied, then that setting is applied.
Otherwise, the setting for the nearest ancestor is applied.
If no setting is found for any ancestor, the permission is denied.
An example may clarify the model.
Suppose a user has been assigned permissions as follows:
Then the user would be granted or denied read/write on the files as follows: Note that in the example, the usual file/directory hierarchy is extended to include the
implication that directories descend from or belong to a
project.
This is conceptually correct in the iProject model.
Notice also that a directory descends from its parent directory if it has one,
from its project if not.
The full hierarchy (including such case-wise inheritances) in the iProject is:
The inheritance of permissions means, for example, that once an engineer is assigned
permission to read files in the The final feature in the iProject permission model is that permission assignments are usually
grouped into roles, and these roles are assigned to users, rather than the individual permissions.
Given the necessary complexity of hereditary fine-grained permissions, this is the most efficient
way of assigning permissions; it is also how things work in practice.
The iProject server stores some information related to system startup in an INI file,
More importantly, internal server setup information is stored in the
The The only change that should be made to any of these lines is to add or remove a single
minus " As described in Automatically Starting
the iProject Server, specifying The iProject normally stores data files in a directory hierarchy below a specified
data root directory.
Each project in the iProject system has its own project root directory created
below the data root when the project is constructed.
Directories and files created, modified, and deleted from projects are created, modified, and
deleted below the project root.
If necessary, files in the iProject system may generally be located on the server by starting
from the data root and working down.
The only thing to keep in mind is that spaces, most punctuation, and exotic characters in
iProject file and directory names may be mapped to underscores
" The iProject allows this behavior to be modified in three ways:
Except in the case of shared directories, directories and files in the iProject storage hierarchy
should generally not be modified outside of the iProject system.
For performance reasons, the iProject mirrors some of the filesystem data in its database, and
can become out-of-sync if the filesystem is modified without its knowledge.
The text and icons shown in the iProject client are almost all contained in the
The iProject client automatically selects a set of resources that best matches the locale of
the computer on which it is running.
Currently US English ( When debugging client connection problems, three logs are of interest:
First identify exactly when the user could not connect, and what IP address (or at least
subnet) they were attempting to connect from. Check the session list for that time, and see if
there is a Next check the Web server logs for that time and IP address, looking for failed requests for
JAR files. There shouldn't be, but if there are then the problem is likely to be some kind of
exotic browser pathology - we've seen it in customized versions if Internet Explorer. Look for
bad URLs with missing or extra slashes (" Finally check the firewall log for that time and IP address, looking for dropped packets.
If there are, then your own firewall rules can probably be adjusted to allow the traffic through.
(Various things can happen here: some client networks produce packets that always have IP options
set, some produce new connection packets without the SYN flag, some produce leading packets that
are outright invalid.) If there are none, then the problem is probably in the user's LAN firewall,
and the answer is to check with their network admin.
If an issue does not seem to be addressed anywhere else, please contact iReservoir.com for
assistance. If the issue seems to involve a system malfunction, some information available from
the iProject server may assist in the resolution of the issue. If possible, please:
Call iReservoir.com or email Issue
Issue
Issue
Issue
Issue
Some utilities for PostgreSQL are:
The iProject installs with two "global" roles:
The permission levels in the tables below indicate "how many" items the role grants permission for.
For example, a "Company Admin" role grants "Project...View" permission at the "Company" level,
meaning that a user assigned a "Company Admin" role can view all the projects that belong to that company.
A "Company Admin" role neither grants nor denies permission to view projects belonging to other companies;
it only addresses projects for its own company.
(Permission to view other projects would have to come from some other role.)
Compare this to a "Project Admin" role, which grants "Project...View" permission at the
"Project" level, i.e. it only grants permission to view itself.
Figure 16: New User screen
Assigning Company Roles
The superuser lupine, company administrators, and company user managers have permissions to
assign company-level roles to users using the Company Staff Roles screen.
Open the Administration menu, then select Assign Company Staff Roles.
Figure 17: Company Staff Roles screen
Fine-Grained Access Control
Figure 18: Example permission assignments
File 1
Read
Denied
Denied on this file
Write
Granted
Granted on ancestor Directory A
File 2
Read
Granted
Granted on ancestor Project X
Write
Denied
Denied on this file
File 3
Read
Granted
Granted on ancestor Project X
Write
Granted
Granted on ancestor Directory A
Figure 19: Example permission status
Figure 20: iProject object hierarchy
Engineering directory, he or she will
by default also be able to read files in any subdirectory created underneath it.
The default can be overridden if needed, but in general this will allow work to get done with
minimum headache.
Advanced Topics
INI File Overview
IrStandardServer.INI.
The values entered in the Configuration group of the server screen are
stored in sections
[control],
[database],
[notification],
[permission],
[server],
[smtp],
[socket], and
[sql_localization].
Screen layout information is stored in the
[layout] and
[window] sections.
[logic],
[objects], and
[services] sections.
The [logic] and [objects] sections should
not be modified at all.
The [services] section should not be modified except as described in
the next section.
Customizing Service Configuration
[services] section of the INI file contains configurations
for the services that make up the iProject server.
Each line in this section looks something like
service_name = #start_sequence@service_class$parameter$parameter...
-" after parameter names.
The presence of a minus after a parameter name means that its value will not be stored in the
INI file; this may be desirable for certain passwords, for example.
Note that any parameter value whose name includes password will be
stored in an encrypted form in the INI file, if at all.
Automatic Server Restart
startup on the iProject server
command line causes the server to automatically start its services.
In order for this to work, the values of all configuration parameters must be stored; that is,
no minuses "-" after parameter names.
File System Mapping
_" in the filesystem names (though not in the iProject display),
if required to make a valid filesystem name.
When locating a file or directory, the iProject server constructs a path by starting
from the file or directory itself, then prepending the
UPDATE Directory SET dir_spec='desired_path'
WHERE dir_id=nnn
dir_spec values of parent
directories until it comes to either an absolute path or the project root.
Setting a dir_spec to an absolute path means that all
subdirectories and files in that directory will be searched for under the given path
instead of the project root.
Customizing Client Resources
/bin/IrClient_Resources.jar archive.
To make changes to resources, first make a backup copy of the original, then extract the
contents into a temporary directory (using a tool like WinZip,
or jar -x).
Finally, reconstruct the resource archive using
IrClientStrings.txt,
and change it as desired.
resources
directory.
IrClientStrings.txt and note
the key (to the left of the equals sign).
IrClientIcons.txt, and change
its value to the new image file.
IrClientIcons.txt (the image file names are generally
descriptive of the image, not the function)
resources
directory.
IrClientStrings.txt and note the key.
IrClientIcons.txt with the value of the new
image file name.
and place the new archive in the jar -cf IrClient_Resources.jar resources/bin directory of the Web server
document tree.
Support for Multiple Languages
en_US), Spanish (es),
and Traditional Chinese (zh_TW) resources are available.
US English is used by default for other locales.
Contact iReservoir.com to request additional language resources.
Troubleshooting
Server Problems
SELECT dir_id, dir_spec FROM Directory WHERE parent_dir_id=0
dir_spec values represent
full paths to directories on the iProject server.
UPDATE Directory SET dir_spec='correct_path'
WHERE dir_id=id_value_from_list
for each one that needs correction.
We have not seen this lately, but it might be worthwhile
simply to try restarting the server.
If your database server supports it, try recomputing indexes.
In PostgreSQL, this can be accomplished by executing the query
vacuum full analyze
If that does not solve the problem, try completely recreating the indexes
in the iProject database. For PostgreSQL, we provide a
script for doing this.
In PostgreSQL, we have seen on one occasion a phantom table and several phantom indexes.
The table had the same name as a table in the iProject database, but with differing
capitalization.
The indexes were apparently indexes in the iProject database, but their definitions
had been lost.
Phantom tables can be found in PostgreSQL by issuing a \dt
command in the psql utility, and looking for repeated table names.
One of the repeated tables will be empty, and should be deleted (to specify the table,
use double-quotes around the table name, and match the capitalization exactly).
Phantom indexes can be fixed by completely recreating the indexes using the
script provided.
See PostgreSQL Basics for further information.
Cross-Checking Logs
getPublicKey request from that IP or subnet. There
shouldn't be, but if there is then the problem is likely to be either a firewall/proxy that is
configured not to allow responses to requests, or that responses are being generated with
characteristics (such as IP options) rejected by a firewall.
/") in the path
part.
Obtaining Support From iReservoir.com
support@ireservoir.com.
support@ireservoir.com
with a description of the issue.
Known Issues
Known Server Issues
Known Client Issues
refresh
in the iExplorer window causes the file list to display the contents of the project root directory
(instead of the directory into which data was uploaded).
Dealing with Digital Certificates
All communication between the iProject client and server is conducted over
sockets that encrypt data using an SSL certificate, to
protect data while in transit.
We outline the process of obtaining an SSL certificate using Apache and OpenSSL.
Importing and exporting with Mozilla "fixes" the PKCS12 format so that Java's SSL implementation
can interpret it. Internet Explorer (IE) cannot be used for this purpose instead; importing and exporting
with IE only makes the format worse.
openssl genrsa -des3 -out iproject.key 1024
openssl req -new -key iproject.key -out iproject.csr
Save the encoded certificate text returned by the CA in a file
called
iproject.crt
openssl pkcs12 -export -in iproject.crt -inkey iproject.key -out iproject_openssl.p12 -name iprojectssl -chain -nomaciter -noiter
In Mozilla, go to
Edit ...
Preferences ...
Certificates ...
Manage Certificates... ...
Your Certificates,
Then click Import and select iproject_openssl.p12.
In Mozilla, go back to
Edit ...
Preferences ...
Certificates ...
Manage Certificates... ...
Your Certificates
Then select the certificate you imported, click Backup,
and save the certificate to iproject.p12.
iproject.p12 is now a file that can be specified in the
PKCS12 or JKS Keystore entry of the
Socket service configuration.
PostgreSQL Basics
PostgreSQL is a free, open-source relational database management system (RDBMS).
Visit the PostgreSQL homepage www.postgresql.org for the latest information.
Installing PostgreSQL
The iProject installation CD includes RPMs for PostgreSQL.
They should be installed roughly in the order:
Configuration
This must be an initially empty directory, and it should be on its own dedicated drive.
PostgreSQL requires that the directory owner be postgres:postgres
(the postgres user and group are created by the PostgreSQL installation),
and that the owner has exclusive permissions on the directory.
PGDATA environment variable to point to the
PostgreSQL data directory
initdb -E UNICODE
This should only be done once per PostgreSQL installation.
/usr/share/zoneinfo
This is required for the iProject's email notification feature to function properly.
We have found it helpful to change a few of the default configuration settings.
PostgreSQL saves its settings in a file called postgresql.conf,
which is usually located in the directory pointed to by PGDATA.
The settings we use are:
# CONNECTIONS AND AUTHENTICATION
tcpip_socket = true
max_connections = 50
# RESOURCE USAGE (except WAL)
shared_buffers = 4096
sort_mem = 4096
vacuum_mem = 16384
# WRITE AHEAD LOG
wal_buffers = 16
checkpoint_segments = 8
# LOCK MANAGEMENT
deadlock_timeout = 5000
Creating the iProject Database
postmaster -i &
createdb -E UNICODE iproject
The -E UNICODE option causes strings to be stored in UTF-8 format.
Access Control in PostgreSQL
It is best to have the iProject database service connect to the PostgreSQL server as
a restricted database user, instead of the postgres user.
This entails
We provide a script for this, which creates
a user iprojectuser with password Dorthonion; you should at least
edit the script to change the password.
$PGDATA/pg_hba.conf
If you do not wish to require authentication, you may change the
If the iProject and PostgreSQL servers are running on the same computer,
Add a line like
localiprojectiprojectuserpassword
If the iProject and PostgreSQL servers are running on different computers,
Add a line like
hostiprojectiprojectuseriProject_server_IP_address255.255.255.255passwordpassword
values to trust.
Maintenance
postmaster -i
Starts the database server. The -i option tells it to listen for TCP/IP connections, a
requirement for JDBC access. This is equivalent to tcpip_socket = true
in postgresql.conf.
createdb [-E UNICODE] db_name
Creates a database catalog.
vacuumdb [-z] db_name
Cleans up a database's record allocations.
The -z option causes indexes to be recomputed.
pg_dump [-D] db_name
Dumps a complete restore script for the specified database.
The -D option causes complete
INSERT queries to be created, which makes a larger but more robust script.
dropdb db_name
Deletes a database catalog.
psql db_name [< SQL_script]
Launches a text-based database client.
The [< SQL_script] option causes
SQL commands to be read and executed from a SQL script.
Two useful commands in psql are
\dt and \di,
which display lists of the tables and indexes in the active database.
Any SQL query may be executed in psql by ending the command line
with a semicolon.
Default Role Permissions
and automatically creates some standard roles along with each new company:
Root
I.e., the superuser role. The superuser has permissions to do everything.
Project Creator
All permissions needed to create new projects in the iProject system,
and to make initial user assignments (e.g. assigning a Project Admin).
and project:
Company Admin
All permissions for all objects belonging to a given company.
See the iProject object hierarchy.
Company User Manager
Permissions to manage users and assign roles for a given company, including all its projects.
Note that this does not by itself give permission to assign company users to projects belonging
to another company. To make such assignments, "Project Staff Assignment" permissions
(below) for the project would also be required.
View Company Users
Permission to view all the users in a given company.
The complete set of permissions for each role is listed in the tables below.
In our experience, these roles are the most generally useful ones, and cover almost all the
situations we have encountered.
Project Admin
All permissions for all objects and data belonging to a given project.
See the iProject object hierarchy.
Project Staff Assignment
Permission to assign roles for a given project.
Note that this does not by itself grant permissions on users; permissions on users must
come from another role, such as "Company User Manager" (above).
View Project Team
Permission to view all users assigned to a given project.
This is intended to allow project team members to see the entire project team.
All Data
Read/write permissions on all data for a given project.
Includes general project permissions (such as permission to view the project itself).
(Specific Task Roles)
Permission to view and change status for a given task in a given project.
Includes general project permissions (such as permission to view the project itself),
and read/write permissions on data associated with the task.
(Specific Directory Roles)
Read/write permissions on data in a specific directory in a given project.
Includes general project permissions (such as permission to view the project itself).
One such role is created for each top-level directory in the project.
(Visibility Roles)
Permission to view and create messages with the given visibility (public or private)
in a given project.
Global
Role grants permission on all items of the given type.
Company
Role grants permission on items belonging to a particular company
(and to any projects and users belonging to the company).
User
Role grants permission on items belonging to a particular user
(i.e. the user account itself, and any email reports the user has defined)
Project
Role grants permission on items belonging to a particular project (esp. tasks, directories, and files).
Users also "belong to" a project once they are assigned to it.
Task
Role grants permission on a particular project task (and its files and directories).
Directory
Role grants permission on a particular directory (and its files and subdirectories).
Visibility
Role grants permission on messages with a particular visibility
(message visibilities belong to a particular project, so permission to view
"public" messages in one project does not extend to other projects).
System-Level Roles
Host Roles
Company Roles
Object
Action
Root
Project Creator
Company Admin
Company User Manager
View Company Users
Company
View
Global
Global
Company
